山村商店

【CUDA 16GB向け】llama.cpp CUDA カーネルの65535制限突破、MMQ境界外読み込み修正、MUSAビルド失敗解消

目次
  1. 今回の要点
  2. CUDAカーネルの65535制限突破と非連続テンソル対応
  3. CUDA MMQの境界外読み込み修正とホスト設定の整合性確保
  4. DFlashの出力ヘッド共有修正とNVFP4量子化対応
  5. MUSA共有メモリバグ修正とVulkan環境の安定化
  6. Top-Kアルゴリズム改善とCCCLバージョンガード修正
  7. 出典

この記事はAIによって編集・作成されています。

今回の要点

  • 65535行/スライスを超える大規模テンソルや非連続データでクラッシュしていたCUDAカーネル（PAD、NORM、ROLL）が修正された。
  • MMQ（Multi-Query）演算におけるホスト設定の不一致と境界外読み込み（Out-of-bounds）バグが修正され、安定性が向上した。
  • MUSA環境における共有メモリ不足によるビルド失敗と、Vulkan環境におけるIntel GPUやAMD GPU固有のバグが解消された。
  • Top-Kアルゴリズムの選択ロジックが改善され、CCCLバージョンガードのバグ修正により将来のビルド互換性が確保された。
  • Blackwell世代向けNVFP4量子化対応とDFlashの出力ヘッド共有バグ修正が行われた。

CUDAカーネルの65535制限突破と非連続テンソル対応

llama.cppのCUDAバックエンドでは、カーネル起動時のグリッドサイズ（gridDim）の制限により、特定の形状のテンソル処理時にエラーが発生する問題が修正されました。

何が変わったか

CUDAの制限により、カーネル起動時のグリッドサイズ（gridDim.y, gridDim.z）は最大65535までという制約がありました。これにより、65535行を超えるPAD（パディング）処理や、65535チャンネルを超える正規化（NORM/RMS_NORM/L2_NORM）処理を行うと、`invalid configuration argument` により推論が中止されていました。

今回の修正では、以下のカーネルがループ処理に対応し、制限を突破しました。
– PADカーネル（PR #30147）
– 正規化系カーネル（PR #28175）
– 非連続テンソル対応ROLLカーネル（PR #29547）

なぜ重要か

大規模なモデルや長いコンテキストを扱う際、テンソルの形状が65535を超えることがあります。これらがCPUバックエンドでは正常に処理できていたものが、CUDAではクラッシュしていたため、16GB GPUユーザーにとって推論の安定性が大きく向上します。

根拠のリンク

– [PR #30147: CUDA : looped PAD kernel for more than 65535 rows or slices](https://github.com/ggml-org/llama.cpp/pull/30147)
– [PR #28175: fix norm family kernels when ne[2]/ne[3] exceed grid dim limits](https://github.com/ggml-org/llama.cpp/pull/28175)
– [PR #29547: Use byte strides for roll to allow non-contiguous ROLL](https://github.com/ggml-org/llama.cpp/pull/29547)

利用者の報告

pskrunner14 氏は、PADカーネルの修正について、65535行を超えるテンソルで `invalid configuration argument` が発生していた事象が、ループ処理により解決されたことを報告しています。
– [PR #30147 コメント](https://github.com/ggml-org/llama.cpp/pull/30147)

edenfunf 氏は、正規化カーネルの修正について、RTX 5070 + CUDA 13.3の環境でテストが行われ、65535チャンネルを超えるケースで正常に動作することを確認しています。
– [PR #28175 コメント](https://github.com/ggml-org/llama.cpp/pull/28175)

Xeoph 氏は、Ampereアーキテクチャ（RTX 3080）での長文コンテキスト処理において、llama.cppの処理速度がvLLMと比べて約2.2〜2.7倍遅いという報告をしています。これはコンテキスト長が増加するにつれて速度が低下する傾向（約0.2 ms/1K KV tokens）によるもので、Draft Acceptanceの品質とは無関係であることが確認されています。
– [Issue #29935](https://github.com/ggml-org/llama.cpp/issues/29935)

CUDA MMQの境界外読み込み修正とホスト設定の整合性確保

何が変わったか

MMQ（Multi-Query）演算において、ホスト側とデバイス側の設定が不一致になるバグと、境界外読み込み（Out-of-bounds reads）が発生するバグが修正されました。

なぜ重要か

設定の不一致や境界外読み込みは、推論結果の破損やクラッシュの原因となります。特にMMQはメモリ効率の高い推論方式であるため、安定動作の確保は重要です。

根拠のリンク

– [PR #30168: pass src1 precision to host MMQ config helpers](https://github.com/ggml-org/llama.cpp/pull/30168)
– [PR #29953: fix MMQ out-of-bounds reads](https://github.com/ggml-org/llama.cpp/pull/29953)

利用者の報告

ynankani 氏は、ホスト側のMMQヘルパー関数に `src1` の精度を渡すことで、ホストとデバイスの設定選択を一致させる修正を行っています。
– [PR #30168 コメント](https://github.com/ggml-org/llama.cpp/pull/30168)

DFlashの出力ヘッド共有修正とNVFP4量子化対応

何が変わったか

DFlash（Dequant Flash Attention）において、出力ヘッドの共有バグが修正されました。また、Blackwellアーキテクチャ向けにNVFP4量子化のサポートが追加されました。

なぜ重要か

DFlashのバグ修正により、推論の正確性が向上します。NVFP4量子化のサポートにより、Blackwell世代GPU（RTX 5090等）でのメモリ効率と推論速度の向上が期待できます。

根拠のリンク

– [PR #30111: fix DFlash output head sharing](https://github.com/ggml-org/llama.cpp/pull/30111)
– [PR #23572: permit quantizing into NVFP4 (Blackwell PP +40%)](https://github.com/ggml-org/llama.cpp/pull/23572)
– [PR #30202: dequant quantized kv on-the-fly for mma kernel](https://github.com/ggml-org/llama.cpp/pull/30202)

利用者の報告

Xeoph 氏は、NVFP4量子化モデル（qwen3.5-arch 27B）をRTX 3080で動作させた際、長文コンテキストでの処理速度低下について報告しています。これはDFlashの修正とは直接関係ありませんが、NVFP4量子化環境での実測値として参考になります。
– [Issue #29935](https://github.com/ggml-org/llama.cpp/issues/29935)

MUSA共有メモリバグ修正とVulkan環境の安定化

何が変わったか

MUSA（Moore Threads GPU）環境において、共有メモリ不足によるビルド失敗が解消されました。また、Vulkan環境におけるIntel GPUとAMD GPU固有のバグが修正されました。

なぜ重要か

MUSAユーザーにとってビルド失敗は重大な問題でしたが、デフォルトアーキテクチャの見直しにより解決しました。Vulkanユーザーにとっても、Intel ArcやAMD Radeon Proでの推論安定性が向上します。

根拠のリンク

– [PR #30203: musa: drop mp_21 from the default architectures](https://github.com/ggml-org/llama.cpp/pull/30203)
– [PR #30167: musa: Fix for FWHT shared memory bug](https://github.com/ggml-org/llama.cpp/pull/30167)
– [Issue #30175: Eval bug: Nondeterministic FA prefill with Qwen 3.5 9B on RDNA3](https://github.com/ggml-org/llama.cpp/issues/30175)
– [Issue #30171: ggml-cuda: GGML_OP_NORM returns all-NaN rows for some constant inputs](https://github.com/ggml-org/llama.cpp/issues/30171)
– [Issue #30166: Vulkan: FLASH_ATTN_EXT wrong results on MoltenVK 1.4.2 + AMD RDNA1](https://github.com/ggml-org/llama.cpp/issues/30166)
– [Issue #30162: Vulkan: add_rms_fusion is disabled for all Intel devices by a vendor gate – re-enable on Xe2](https://github.com/ggml-org/llama.cpp/issues/30162)

利用者の報告

Googulator 氏は、RDNA3（RX 7900 XT/7800 XT）環境でQwen 3.5 9Bを推論する際、ビルドb10905以降、非決定性（ nondeterministic ）な出力が発生する問題を報告しています。RDNA4（RX 9070 XT）では発生しません。
– [Issue #30175](https://github.com/ggml-org/llama.cpp/issues/30175)

builtin-pb 氏は、CUDAの `norm_f32` カーネルにおいて、定数入力に対してNaNを返すバグを報告しています。これは分散計算の1パス処理で、平均が分散に対して大きい場合、分散が負の値に丸まり、`rsqrtf` がNaNを返すことが原因です。CPUバックエンドは2パス処理でこれを回避しています。
– [Issue #30171](https://github.com/ggml-org/llama.cpp/issues/30171)

TentionLin 氏は、Apple + AMD（RDNA1）環境でMoltenVK 1.4.2を使用する際、ヘッドサイズがサブグループサイズの倍数でない場合、`FLASH_ATTN_EXT` が誤った結果を返す問題を報告しています。
– [Issue #30166](https://github.com/ggml-org/llama.cpp/issues/30166)

TentionLin 氏は、Intel Arc B580（Xe2）環境でVulkanの `add_rms_fusion` を再有効化し、`test-backend-ops` で19047チェックが正常に通過したことを報告しています。
– [Issue #30162](https://github.com/ggml-org/llama.cpp/issues/30162)

Top-Kアルゴリズム改善とCCCLバージョンガード修正

何が変わったか

Top-Kアルゴリズムの選択ロジックが改善され、特定の条件下での精度低下が修正されました。また、CCCL（CUDA C++ Core Libraries）のバージョンガードが修正され、メジャーバージョンアップ時の互換性が確保されました。

なぜ重要か

Top-Kの精度向上により、推論の品質が安定します。CCCLのバージョンガード修正により、将来のCUDAツールキットアップグレード時にビルドが失敗したり、パフォーマンスが低下したりするリスクが回避できます。

根拠のリンク

– [PR #28713: improve top-k algorithm selection](https://github.com/ggml-org/llama.cpp/pull/28713)
– [PR #29453: fix CCCL version guard breaking on major version rollover](https://github.com/ggml-org/llama.cpp/pull/29453)

出典

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

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