山村商店

llama.cppのCUDA関連修正：Volta世代のFlashAttention不具合解消とMoE推論の重大バグ

ローカルLLMCUDA量子化LLM最適化GPU

目次
  1. 今回の要点
  2. Volta (sm_70)でのFlashAttention不具合修正
  3. Qwen3.5 122BがVolta (sm_70)で即クラッシュ
  4. CUDA MoE MMQでillegal memory access不具合
  5. Vulkan MUL_MAT_IDでexpert id重複時に行数消失
  6. Gemma向けDFlashドラフト変換のembedding_scale修正
  7. 出典

今回の要点

  • Volta世代GPUのFlashAttention修正：共有メモリの不足によるクラッシュと、最大バイアス設定時のルーティング不具合が修正された。
  • Qwen3.5 122BのVolta世代での動作：DeltaNetアーキテクチャがVolta (sm_70)環境で初回リクエスト時に即座に停止する不具合が報告されている。
  • MoE推論のメモリアクセス不具合：RTX 5060 Ti 16GB環境において、バッチサイズ512でillegal memory accessが発生するバグが見つかった。
  • VulkanバックエンドのMoE推論欠落：同じexpert IDが複数回出現する際、Vulkanバックエンドで計算結果が欠落する不具合がある。
  • Gemma向けDFlashドラフト変換の修正：embedding_scaleの未書き込みにより精度が低下していた問題が修正された。

Volta (sm_70)でのFlashAttention不具合修正

前提

FlashAttentionはGPUの共有メモリを活用し、高速かつ低メモリ消費で注意機構を計算する手法です。llama.cppはGGUF形式の量子化モデルをCPU/GPUで動かす推論エンジンとして知られています。

何が変わったか

Volta世代のGPU (sm_70)において、FlashAttentionの2つのケースが破綻する問題が修正されました。1つ目の問題は、head size 320と256においてAmpere世代の設定が使用され、共有メモリが不足してクラッシュしていた点です。2つ目の問題は、max_bias != 0.0fの状態で、Qカラム数に基づくパフォーマンス最適化ルーティングが正しく行われず、Voltaでエラーを引き起こしていた点です。これらの問題に対応する設定が追加されました[1]。

なぜ重要か

Volta世代のGPU (Tesla V100など) を使用しているユーザーは、FlashAttentionを有効にした際、共有メモリの不足やルーティングエラーで推論が停止するリスクがありました。今回の修正により、これらの環境でも安定してFlashAttentionを利用できるようになります。

根拠のリンク

利用者の報告

JohannesGaesslerは、テストケースでVolta世代のFlashAttentionが破綻していることを発見し、修正PRを作成しました[2]。

demon851113は、RTX 5070 Ti 16GB環境でのllama.cpp + expert-cache setup (IQ3_XXS) におけるデータを提供しています。コンテキスト32K〜127Kにおいて、QSA有効化によりデコード速度が向上し、リコールテストも全深度で成功しています[3]。

Qwen3.5 122BがVolta (sm_70)で即クラッシュ

前提

Qwen3.5 122B-A10Bは、Gated DeltaNetアーキテクチャを採用した大規模言語モデルです。MoE (Mixture of Experts) 構造を持ち、複数のエキスパートを動的に選択して推論を行います。

何が変わったか

Qwen3.5 122B-A10B GGUFモデル (Q8_0, UD-Q8_K_XL) が、Volta世代のGPU (sm_70) 環境において、初回リクエスト時に即座に停止する不具合が報告されています。prefillの進行が見られないまま、カーネル起動の拒否が発生し、サーバーが終了します[4]。

なぜ重要か

Volta世代のGPU (Tesla V100など) を複数台接続して大規模モデルを推論しようとしているユーザーにとって、初回リクエストで即座に停止するバグは重大な障害です。DeltaNetアーキテクチャがVolta環境で正しく動作しない可能性があり、推論の可用性に直結します。

根拠のリンク

利用者の報告

yudaguaは、6x Tesla V100 32GB (sm_70) 環境で、LM Studio 2.47.0 (llama.cpp b11189, CUDA build) を使用してこの不具合を再現しました。Windows 11, driver 582.78, CUDA 12.4の環境で、--parallel 1 --kv-unifiedオプションでモデルを読み込み、任意のプロンプトを送信すると、サーバーは起動するものの、初回リクエストから約2秒以内に停止します[5]。

ServeurpersoComは、修正PR (#29803) がこの問題に対応していない可能性を指摘しています。Qwen3.5-122Bはフルアテンションが256/256でGQA 16、max_biasがないため、修正対象のケース (DKQ 320, ALiBi routing) とは異なる可能性があります[6]。

JohannesGaesslerは、テストケースでクラッシュしていた問題を修正したが、実際のモデルでまだクラッシュする場合はテストカバレッジを拡張すべきだと述べています[7]。

CUDA MoE MMQでillegal memory access不具合

前提

MoE (Mixture of Experts) モデルは、各トークンに対して複数のエキスパートを動的に選択して推論を行います。llama.cppでは、CUDAバックエンドでMoE推論を行う際、MMQ (Multi-Matrix Multiplication) 演算が使用されます。

何が変わったか

バッチサイズ (ubatch) 512において、CUDA MoE MMQ演算でillegal memory accessが発生する不具合が報告されました。src1のpaddingが、収集されたカラム数ではなくne11を使用していることが原因です[8]。

なぜ重要か

RTX 30/40/5060 Ti 16GBなどの16GB VRAMを持つGPUでMoEモデルを推論する際、バッチサイズ512で推論が停止する重大なバグです。特に、512エキスパート、10エキスパート使用 (per token) のモデル (IQ3_XXS) で再現します。

根拠のリンク

利用者の報告

makefunstuffは、2x NVIDIA GeForce RTX 5060 Ti 16 GB (Blackwell, sm_120) 環境で、llama.cpp version 0.5.0-dev (build 3155, commit 5fc4f3c8c) を使用してこの不具合を再現しました。Linux 7.1.9 (Arch), NVIDIA driver 610.57.04, CUDA 13.3の環境で、ukisai/Swift-1.5-Qwen3.8-Flash-Next-GSQ-RCO-GGUF (IQ3_XXS, 512 experts, 10 used per token) モデルを使用してテストしています[9]。

demon851113は、RTX 5070 Ti 16 GB環境でのllama.cpp + expert-cache setup (IQ3_XXS) におけるデータを提供しています。コンテキスト32K〜127Kにおいて、QSA有効化によりデコード速度が向上し、リコールテストも全深度で成功しています[10]。

Vulkan MUL_MAT_IDでexpert id重複時に行数消失

前提

Vulkanバックエンドは、llama.cppがサポートするGPU推論バックエンドの一つです。MoEモデルでは、各トークンに対して複数のエキスパートが選択され、MUL_MAT_ID演算が使用されます。

何が変わったか

トークンの行に同じexpert IDが複数回出現する場合、VulkanバックエンドのMUL_MAT_ID演算で、そのエキスパートに割り当てられた行の一部のみが計算され、残りの行が欠落する不具合があります。これは、n > 8の場合に発生し、n <= 8の場合はmul_mat_vec_idを経由するため影響を受けません[11]。

なぜ重要か

Vulkanバックエンドを使用しているユーザーがMoEモデルを推論する際、出力が欠落し、推論結果が正しく得られない可能性があります。特に、同じエキスパートが複数回選択されるケースで発生します。

根拠のリンク

利用者の報告

Anjielonは、Vulkan (RADV gfx1151) 環境で、test-backend-ops を使用してこの不具合を再現しました。n_mats=28, n_used=10, n ranging from 9 to 64の条件で、CPUと比較して行が欠落していることを確認しています[12]。

demon851113は、RTX 5070 Ti 16 GB環境でのllama.cpp + expert-cache setup (IQ3_XXS) におけるデータを提供しています。コンテキスト32K〜127Kにおいて、QSA有効化によりデコード速度が向上し、リコールテストも全深度で成功しています[13]。

Gemma向けDFlashドラフト変換のembedding_scale修正

前提

DFlashは、ドラフトモデルとターゲットモデル間でトークン埋め込みを共有し、推論速度を向上させる技術です。Gemmaモデルは、トークン埋め込みを共有する際に、sqrt(hidden size) (約53倍) の乗算処理が必要です。

何が変わったか

Gemmaターゲット向けのDFlashドラフト変換において、dflash.embedding_scale が書き込まれていなかった問題が修正されました。ドラフターはGemmaのトークン埋め込みを共有するため、この乗算処理が必須です。修正により、ドラフターが正しいスケールで埋め込みを処理できるようになり、受容率が向上しました[14]。

なぜ重要か

Gemmaモデル (特にGemma 4 26B-A4Bなど) をDFlashドラフト変換で使用する際、embedding_scaleが未設定だと埋め込みが53倍小さくなり、受容率が低下して推論速度が落ちます。修正により、ドラフト変換の精度と速度が改善されます。

根拠のリンク

出典

【宣伝】SwitchBot 購入はこちらから

SwitchBot公式ページ
クーポン「AF-4903」で5％引き（アフィリエイトクーポンになりますのでご協力お願いします）
割引の詳しい仕組みに関してはこちらのページを参照ください。
製品ごとの特徴・紹介動画は SwitchBot 製品ガイド にまとめています。