【CUDA 16GB向け】llama.cpp: 並列推論の急減、Vulkanリーク、NVFP4/MSVC修正

今回の要点

• RTX 5060 Ti 16GB環境で、コンテキスト262144かつ並列4以上時のデコード速度が約5倍に急減する重大な不具合を確認
• AMD GPU (Vulkan) でメモリ確保失敗が累積し、再起動まで復旧しないドライバー側のリーク現象が発生
• Windows (MSVC) ビルド環境でGPUとCPUの計算結果が一致しない「round」関数の不具合が修正された
• Pascal世代 (sm_60) GPU向けにMMVQ演算が最適化され、NVFP4量子化モデルの読み込み対応が追加された
• Gemma 4やMistral Small 4で、CUDA利用時の推論失敗やJSON出力のバグが報告されている

llama.cpp: 並列推論時のデコードスループット急減バグとVulkan VRAMリーク

前提

llama.cppはggml-orgが開発するC/C++のLLM推論エンジンで、GGUF形式の量子化モデルをCPUやGPUで動作させる。llama-serverを用いて複数のリクエストを並列処理する際、コンテキストサイズと並列度（n_parallel）の組み合わせによってパフォーマンスが変動する。

何が変わったか

RTX 5060 Ti 16GB (CUDA 13.1) 環境において、コンテキストサイズ262144、並列度4以上でデコードスループットが急減する現象が報告された。並列度2では正常な速度（約39.8 t/s）だが、4にすると約3.6 t/s、8にすると約1.65 t/sにまで低下する。メモリ使用量は正常動作時とほぼ同等（KV 8704 MiB）であり、メモリ不足ではない。

なぜ重要か

16GB GPUユーザーが長文コンテキストを扱う際、並列処理を有効化すると著しく性能が劣化する。これにより、マルチユーザー環境やバッチ処理での実用性が損なわれる。

根拠のリンク

• llama.cpp #30276: Performance cliff: c=262144 with n_parallel>=4 collapses decode throughput

利用者の報告

@coolinger2019-wq はRTX 5060 Ti 16GB、Bonsai-2 27B (GGUF type 142 / PQ2_0, 7.2 GB) の環境で、コンテキスト262144・並列4でデコード速度が3.6–3.9 t/sに急減し、並列8では1.65 t/sになったと報告している。メモリ使用量は正常時と同等であり、メモリ不足ではないと指摘している。

@green-real はRTX 3070 Ti (WSL2) および RTX 3090 (Linux) で、`–cache-idle-slots` 有効時にアイドルスロットの保存処理で他リクエストが最大5.4秒待機する現象を確認した。`–kvu` (unified KV) 使用時、インターリーブKVにより23,256回のブロック呼び出しが発生し、スループットが低下する。

@groundbreakersonline はASUS ROG Flow Z13 (Ryzen AI Max 390, Radeon 8050S, Vulkan) で、メモリ確保失敗が累積し、再起動まで復旧しないドライバー側のリーク現象を確認した。Gemma4 26B-A4B Q4_K_M (15.63 GiB) で再現する。

@user はIntel Arc A770 16 GB (DG2) で、MUL_MAT_ID演算が小バッチ時にハングし、VK_ERROR_DEVICE_LOSTを発生させる現象を確認した。Laguna-XS-2.1-APEX-I-Mini.gguf (256-expert MoE) で再現。

llama.cpp: NVFP4変換対応とPascal/Vulkan向けMMVQ最適化

前提

llama.cppは新しい量子化フォーマットや旧世代GPU向けに最適化を進めている。NVFP4はNVIDIAの新しい量子化形式で、MMVQはPascal世代 (sm_60) GPU向けの演算最適化手法。

何が変わったか

Pascal世代 (sm_60) GPU向けに、MUL_MAT_ID演算でMMVQを常に使用するように最適化された。NVFP4量子化モデルのコンバート対応が追加された。

なぜ重要か

Pascal世代GPUユーザーの推論速度が向上する。NVFP4モデルの利用が可能になる。

根拠のリンク

• llama.cpp #27828: cuda: always use MMVQ for MUL_MAT_ID on sm_60
• llama.cpp #28636: Convert: Support conversion to gguf for compressed-tensor mixed-precision NVFP4 checkpoint

llama.cpp: MSVC環境での計算精度修正とSSM_SCANの冗長コピー削除

前提

Windows環境でMSVCコンパイラを使用する場合、GPUとCPUの計算結果が一致しない問題があった。SSM_SCAN演算後の冗長なコピー処理が削除された。

何が変わったか

MSVC環境でround(x)関数がGPUとCPUで異なる結果を返す不具合が修正された。SSM_SCAN演算後の冗長なコピーが削除され、推論速度が向上した。

なぜ重要か

Windowsユーザーの計算精度が保証される。推論速度が向上する。

根拠のリンク

• llama.cpp #30229: CUDA: fix round issue, under MSVC the CPU and GPU agree
• llama.cpp #29807: CUDA: Remove redundant CUDA copies after SSM_SCAN

llama.cpp: 多モーダル(MTMD)入力対応とMTP推論状態の保存修正

前提

llama.cppは多モーダル入力 (MTMD) に対応し、MTP (Multi-Token Prediction) 推論の信頼性を向上させている。

何が変わったか

MTP headsがMTMD入力を適切に処理できるようになり、画像入力時の受容率が向上した。MTP推論状態の保存・復元が修正された。

なぜ重要か

画像入力モデルの精度が向上する。MTP推論の信頼性が確保される。

根拠のリンク

• llama.cpp #30257: spec: properly handle mtmd input for mtp
• llama.cpp #30259: mtmd: add build_inp_attn_mask

llama.cpp: Gemma 4/Mistral Small 4のCUDA/JSONバグ修正

前提

Gemma 4やMistral Small 4などのモデルで、CUDA利用時の推論失敗やJSON出力のバグが報告されている。

何が変わったか

Gemma 4でJSONスキーマ指定時に思考チャンネルが許可されるバグが報告された。Mistral Small 4でCUDA expert down-projectionsがCPUフォールバックする現象が報告された。

なぜ重要か

主要モデルの推論失敗やCPUフォールバックを回避できる。

根拠のリンク

• llama.cpp #30256: Eval bug: Gemma 4 – json_schema grammar allows a thought channel although enable_thinking is false
• llama.cpp #30224: Eval bug: Mistral Small 4 CUDA expert down-projections fall back to CPU despite 37/37 layers offloaded

利用者の報告

@fenvarien はRTX 3060 Ti 8 GB (CUDA) で、Gemma 4のJSONスキーマ指定時に思考チャンネルが許可されるバグを確認した。`enable_thinking: false` 指定にもかかわらず `reasoning_content` が生成される。

@NickF93 はRTX 3090 (CUDA) で、Mistral Small 4のCUDA expert down-projectionsがCPUフォールバックする現象を確認した。37/37層オフロード指定にもかかわらず、FP32ソースのCUDA拒否によりCPUフォールバックする。

@Xeoph は2x RTX 3080 20GB (sm86) で、fattn KV streamingの長文コンテキスト時スループットがvLLMの2.2-2.7倍遅いと報告している。qwen3.5-arch 27B NVFP4モデルで再現。

出典

• https://github.com/ggml-org/llama.cpp/issues/30276
• https://github.com/ggml-org/llama.cpp/issues/30252
• https://github.com/ggml-org/llama.cpp/issues/30251
• https://github.com/ggml-org/llama.cpp/issues/30240
• https://github.com/ggml-org/llama.cpp/pull/27828
• https://github.com/ggml-org/llama.cpp/pull/28636
• https://github.com/ggml-org/llama.cpp/pull/30229
• https://github.com/ggml-org/llama.cpp/pull/29807
• https://github.com/ggml-org/llama.cpp/pull/30257
• https://github.com/ggml-org/llama.cpp/pull/30259
• https://github.com/ggml-org/llama.cpp/issues/30256
• https://github.com/ggml-org/llama.cpp/issues/30224
• https://github.com/ggml-org/llama.cpp/issues/29935