llama.cpp 10月4日〜5日: MoEカーネル修正、Ampere世代の性能劣化報告、4ヘッド向け最適化

今回の要点

• MoEモデル実行時の不正アクセスを修正するPRがマージされ、RTX 30/40/50シリーズでのMoE利用が安定化。
• Ampere世代（RTX 30xx）において、長文コンテキスト時の推論速度が物理限界の約2倍劣化するバグ報告。
• 4ヘッド構成のモデル向けにLightning Indexerが最適化され、prefill性能が向上。
• GLM-5.3-Flashモデルで特定コミット以降VRAM使用量が急増する不具合が報告。

CUDA MMQ MoEカーネルのメモリ不正アクセス修正

llama.cppのCUDAバックエンドでは、MoE（Mixture of Experts）モデル実行時に、専門家の数（n_expert）が物理バッチサイズ（n_ubatch）を大きく上回る場合、一時バッファのサイズ計算ミスにより不正なメモリアクセス（OOB）が発生するバグがありました。この修正はPR #29941として提出され、b11405ビルドにマージされています。 具体的には、MMQカーネル内のq8_1バッファのパディング決定ロジックが、Denseモデル向けの値をMoEモデルでも使用していたことが原因です。MoEモデルではテンソルレイアウトが異なるため、正しい値（src1->ne[2]）を使用するように修正されました。これにより、Qwen3.6-35B-A3Bのような多専門家モデルがRTX 30/40/50シリーズでクラッシュせずに実行可能になります。

利用者の報告

16GB VRAM環境でのMoE利用に関する具体的なデータが報告されています。RTX 5070 Ti 16GB環境において、VRAM expert cacheとMTP draftingを組み合わせたセットアップで、QSA（Quantized Sparse Attention）適用前後の性能比較が行われました。

demon851113氏は、コンテキスト長32K〜127Kの範囲で、QSA適用によりデコード速度が69.5 t/sから78.1 t/s（32K時）へと向上し、リコールテストも全深度で成功したと報告しています。また、プロンプト処理速度は73K〜122Kコンテキストで約550〜575 tok/sであり、-ub 2048は16GBでは収まらないものの、-ub 1024では動作しているとのことです。この環境はUbuntu 24.04、Ryzen 7 7700、DDR5 3600 MT/sです。一方、この報告はMoEカーネルのメモリ不正アクセス修正そのものの検証ではありませんが、16GB GPUでのMoE関連最適化の現状を示す重要なデータポイントとなっています。

Niko1221/Strata#71 (demon851113)

Ampere世代 fattn KVストリーミングの精度・性能問題

Ampereアーキテクチャ（sm86、RTX 30xxシリーズ）を搭載したGPUにおいて、長文コンテキスト時の推論性能が物理的な限界から大きく乖離する現象が報告されています。これはfattn（FlashAttention）カーネルのKVストリーミング実装に関連する問題です。 RTX 3080 20GB（2枚構成）環境で、Qwen3.5-arch 27B NVFP4モデルを用いたテストでは、コンテキスト長が増加するにつれてデコード速度が低下する割合（slope）が、vLLM（FA2/FlashInfer使用）と比較して約2.2〜2.7倍遅いことが確認されました。具体的には、llama.cppでは1K KVトークンあたり約0.2 msのオーバーヘッドが発生するのに対し、vLLMでは約0.085 msでした。短コンテキスト時のステップ時間（約47 ms）には差がないため、この劣化は純粋にコンテキスト長に依存するものです。 この問題は、量子化KV（q8_0/q8_0）またはf16/f16 KV、およびspeculative draft-MTP x3（verify batch 4）という設定で再現しています。バッチサイズ1を超え、量子化KVを使用する場合、常にf16変換パスのコストが発生している可能性も示唆されています。

利用者の報告

Xeoph氏は、RTX 3080 20GB（sm86、-sm tensor）、Windows、llama.cpp b11379、CUDA 13.4、MSVC 19.44の環境で、この性能劣化を定量的に報告しています。モデルはQwen3.5-arch 27B NVFP4（17 full-attn layers with GQA 6, head_dim 256; 48 GDN layers）を使用し、-fa on（tensor splitにより強制）でテストを行いました。短コンテキスト時のステップ時間はvLLMと同等（約47 ms）でしたが、コンテキスト長が増加するにつれてllama.cppの性能が急激に低下し、vLLMとの差が2.2〜2.7倍に拡大しました。ドラフト受容率は一定（約0.5、平均長2.4-2.6）であったため、ドラフト品質の問題ではないと結論づけています。

llama.cpp #29935 (Xeoph)

CUDA Lightning Indexerの4ヘッド向け最適化

4ヘッド構成のモデル（Qwen4Expなど）向けに、CUDA Lightning Indexerの最適化が行われました。この変更はPR #29901として提出され、b11405ビルドにマージされています。 従来、ベクターカーネルは各トークンに対してキーを再読み取りしていましたが、この最適化により、キーを半精度で一度ステージングし、クエリをヘッドごとに読み取る方式に変更されました。これにより、クロススレッドドットプロダクトの再順序付けが不要になり、パフォーマンスが向上します。 RTX PRO 6000でのテストでは、prefill性能が6.4 msから16.4 ms（kv 65536, nb 2048）へと約2.5倍高速化しました。また、qwen4expモデルでの実環境テストでは、PP（prefill）速度が3867 t/sから4038 t/sに向上し、nsysでのインデクサーのGPU時間占有率が9.6%から4.0%に低下しました。この最適化はsm_80以降のGPU（RTX 30/40/50シリーズ）に適用されます。

CUDA FlashAttentionのタイルスケジューリング改善

FlashAttentionのprefill性能を向上させるため、Whole-tileスケジューリングを優先する変更が行われました。これはPR #29435として提出され、b11405ビルドにマージされています。 従来、Ada以降のNVIDIAアーキテクチャではStream-Kが常に選択されていましたが、この変更により、カーネルが効率的にWhole-tileスケジューリングを利用できる場合、それを優先するようになりました。具体的には、以下の条件を満たす場合にWhole-tileが選択されます： 1. 選択されたMMAカーネルに正確に2つの有効な読み込みステージがある 2. タイル効率が75%以上（既存の整数wave効率計算に基づく） この変更は、DGX Sparkでの長文ワークロードで substantial な改善、RTX 5090では小さな改善をもたらしました。sm_70以降のすべてのCUDA GPUに影響します。

GLM-5.3-FlashのVRAM使用量増加バグ報告

GLM-5.3-Flashモデルにおいて、特定のコミット（c2ed48576）以降、VRAM使用量が急増する現象が報告されています。このコミットはPR #27773の一部で、GPU ROHM グラフの再割り当てに関連する修正でした。 RTX 5090環境で、GLM-5.3-Flash-Q5_K_M.ggufモデルを使用した場合、修正前のコミットではコンテキストサイズ307200、-ub 8192で約30GBのVRAM使用でしたが、修正後では同じコンテキストサイズでOOM（Out Of Memory）が発生し、コンテキストサイズを204800に下げて初めて約30GBでロードできました。 この問題は、lazy kpool sizingがllama_memory_hydraのグラフ再割り当てに置き換えられたことに起因する可能性があります。16GB GPUユーザーは、このコミット以降のビルドでGLM-5.3-Flashモデルを使用する際、VRAM使用量に注意が必要です。

利用者の報告

ichivangogh氏は、RTX 5090、512GB RAM、Linux、GNU 15.2.0、llama.cpp 0.5.0-dev (build 11379, commit 1537a0a8b)の環境で、このVRAM使用量の急増を報告しています。モデルはGLM-5.3-Flash-Q5_K_M.gguf（自己量子化）を使用し、CUDA_VISIBLE_DEVICES=0 llama-server -m GLM-5.3-Flash-Q5_K_M.gguf -c 307200 -dev CUDA0 -cmoe -b 8192 -ub 8192 -cram -1 -t 32 --load-mode noneというコマンドでテストを行いました。修正前のコミットでは307200コンテキストで約30GBのVRAM使用でしたが、修正後では同じコンテキストサイズでOOMが発生し、コンテキストサイズを204800に下げて初めて約30GBでロードできました。この問題は、lazy kpool sizingがllama_memory_hydraのグラフ再割り当てに置き換えられたコミット（c2ed48576）以降に発生しています。

llama.cpp #29950 (ichivangogh)

出典

• CUDA: fix MMQ memory fault if n_expert >> n_ubatch (PR #29941)
• Cuda mmq moe oob fix (PR #28383)
• llama.cpp #29935 perf (CUDA): fattn KV streaming on Ampere (sm86) is ~2x off physics at long context
• llama.cpp #29901 cuda: tile the lightning indexer over keys and tokens for 4 heads
• CUDA: tile the lightning indexer over keys and tokens for 4 heads (b11405)
• llama.cpp #29435 CUDA: prefer whole-tile FlashAttention scheduling for efficient two-stage kernels
• CUDA: prefer whole-tile FlashAttention scheduling for efficient two-stage kernels (PR #29435)
• llama.cpp #29950 Eval bug: GLM-5.3-Flash increased VRAM usage after specific commit in PR#27773
• Niko1221/Strata#71 (demon851113)