CUDA 16GB 向けローカル LLM on 山村商店

【CUDA 16GB向け】llama.cpp: 16GB GPU向けKV量子化・Flash-Attention修正・MMQ最適化で推論性能と安定性を向上

Tue, 20 Oct 2026 11:30:01 +0000

llama.cpp は ggml-org が開発する C/C++ の LLM 推論エンジン。GGUF 形式の量子化モデルを CPU/GPU で動かす。

今回の要点

VRAM効率化: Flash-AttentionのKVキャッシュに量子化(q8_0)対応し、16GB GPUでの大規模モデル推論を可能にする。
推論精度の保証: Flash-Attentionの共有メモリ競合(WARハザード)を修正し、出力の正確性を確保した。
処理速度の改善: Stream-Kのブロック制限とWarpアライメントを修正し、量子化行列乗算のオーバーヘッドを低減した。
バグ修正: llama-serverのSWAチェックポイント復元ロジックを修正し、プロンプト混同による誤動作を解消した。
新モデル公開: 16GB VRAMに適合する混合精度量子化モデル「Qwen3.8-Flash-Next GSQ RCO GGUF」が公開された。

Flash-AttentionのKV量子化対応とグラフ起動最適化

llama.cppのCUDA Flash-Attention tile kernelにおいて、KVキャッシュの量子化形式が拡張された。これにより、VRAM使用量が削減され、16GB GPUでもより大きなモデルを扱えるようになる。

具体的には、Valueキャッシュにq8_0、Keyキャッシュにf16を使用する形式がネイティブサポートされた(PR #30792)。これにより、Qwen3.6-35BやQwen3.8-27Bといった大規模モデルを16GB GPUで推論する際のVRAM効率化が図られる。また、NVFP4量子化モデルにおける計算オーバーヘッドを低減するため、小規模キーに対するNVFP4 MMVQ演算でlane-packed rowsが採用された(PR #30788)。BlackwellやRTX 50シリーズの16GBモデルにも関連する最適化である。さらに、NVIDIA GPUのTensor Core (sm_80以降) を搭載する環境において、Q5_K量子化モデルの性能向上のためMMAが利用され、Stream-K fixupが最適化された(PR [cuda-mma-q5])。

長文コンテキスト推論において、CUDAグラフの起動オーバーヘッドを低減するため、グラフ起動をより小さなチャンクに分割する最適化が行われた(PR [cuda-graphs])。これにより、グラフ初期化に伴うペナルティが軽減される。

Flash-Attentionの共有メモリWARハザード修正

Flash-Attentionの実装において、共有メモリ内のデータ競合（Write-After-Read hazard）が修正された。これにより、KVループでの推論結果の正確性が保証される。

従来、KVループは反復間で共有KQバッファを再利用していたが、スコアの書き込みとV蓄積のための読み込みの間にwarp barrierが存在しても、次の反復で上書きする前に同期が取れていなかった(PR #30573)。ループの末尾に ggml_cuda_syncwarp() を追加することで、どのlaneもスロットを上書きする前に読み込みを完了するよう修正された。これは書き込みwarp内の読み込みに限定されるため、warp barrierで十分である。

この修正により、Compute-sanitizerが報告していた800万以上のWAR警告がゼロとなった(PR #30573)。また、3993件の完全なFlash-Attention Ext正確性テストスイートすべてがパスした。RTX 3090 (sm_86) および NVIDIA driver 610.43.03 環境でのテスト結果であり、修正前後で38件の選択された正確性テストもすべてパスしている(PR #30573)。

利用者の報告

RTX 3090 (sm_86) および NVIDIA driver 610.43.03 の環境で、Compute-sanitizerによるWAR警告が修正前8007424件から修正後ゼロ件になったという報告がある。また、3993/3993件の正確性テストがパスしたという報告がある (PR #30573)。

MMQのStream-K制限とWarpアライメント修正

量子化行列乗算（MMQ）におけるStream-Kの実装と、Warpサイズのアライメントが修正された。これにより、メモリアクセスの正しさとブロック制限が守られ、クラッシュやパフォーマンス劣化が防止される。

Stream-Kは、利用可能なK作業ユニット数よりも多くのCUDAブロックを起動できるため、空のブロックが起動オーバーヘッドを追加し、fixupカーネルのバックワードスキャンを長引かせていた(PR #30553)。この問題に対し、MMQグリッドを総出力タイル/Kブロック作業数と総計算反復数で制限する修正が行われた。また、DP4A MMQのタイル高さがWarpサイズ（32）の倍数であることを強制する修正も含まれる(PR [cuda-dp4a])。さらに、wave64デバイスにおいてタイル幅が64で割り切れない場合に発生するバグが修正された(PR [cuda-wave64-fix])。

これらの修正により、量子化行列乗算のメモリアクセスパターンが正しく保証され、NVIDIA GPUでの安定した動作が期待できる。

利用者の報告

RTX 5090 環境において、修正後の公式により test-backend-ops の MUL_MAT および MUL_MAT_ID がパスしたという報告がある (PR #30553)。また、フルモデル測定において、RTX 5090 (1台) のPrefillフェーズで2030.61 tok/s から 2033.75 tok/s (+0.15%)、6台のTGフェーズで215.21 tok/s から 224.79 tok/s (+4.47%) の改善が確認されたという報告がある (PR #30553)。

llama-serverのSWAチェックポイント無効化ロジック修正

llama-serverにおいて、以前の無関係なプロンプトから保存されたSWA（Sliding Window Attention）チェックポイントを誤って復元するバグが修正された。これにより、推論の安定性が向上する。

Flash Attention with sliding window (SWA) を使用するすべてのバックエンドに影響する。修正前、異なるプロンプト処理中に保存されたチェックポイントが、別の文脈で復元されてしまう問題があった (PR #30666)。修正により、A/Bテストケースで失敗していた箇所が正常に動作するようになり、チェックポイントの無効化ロジックが正しく機能するようになった。

利用者の報告

修正前には失敗し、修正後に正常に動作するA/Bテストケースが確認されたという報告がある (PR #30666)。

16GB GPU向け新量子化モデルの公開

16GB VRAMのGPU向けに最適化された混合精度量子化モデルがHugging Faceに公開された。

ISTA-DASLabのQwen3.8-27B-GSQファミリーから派生した「Qwen3.8-Flash-Next GSQ RCO GGUF」が公開された (HF: Qwen3.8-Flash-Next-GSQ-RCO-GGUF)。これは混合精度量子化（IQ3_S 2-part split）を採用しており、gsq、rco、quantization、mixed-precisionのタグが付いている。また、bartowskiにより公開されたInternScience_MLExpert-GGUFでは、Q3_K_Mが16.2GBと16GBをわずかに超える一方、Q3_K_Sが15.2GBで単一GPUに適合する (HF: bartowski/InternScience_MLExpert-GGUF)。

出典

【CUDA 16GB向け】RTX 5090の長文推論遅延修正と、16GB GPUでの超大規模MoE推論実測

Mon, 19 Oct 2026 11:30:01 +0000

今回の要点

バグ修正: RTX 5090等におけるCUDA Flash Attentionの長文prefill遅延（最大40%）が修正された。また、Vulkan環境での文字化けやMTP（多トークン予測）の動作不良も報告されている。
16GB GPUでの超大規模推論: Qwen3.8-Flash-Next (125B) が、RTX 5060 Ti 16GB 1枚や、RTX 5070 12GB + 5060 Ti 16GB の2枚構成で動作し、実用的な速度（50-100 tok/s）で推論可能であることが実測されている。
MoE最適化: llama.cppにおいてMoE推論のキャッシュ機構がSLRU方式に変更され、VRAM不足解消のためのホストRAM expert配置や、推論エンジン（Unsloth等）のメモリ削減技術が強化された。
推論エンジンの動向: vLLM 0.32.0でNVFP4 KVキャッシュ対応、SGLang v0.5.21でCUDA 13対応とMTPサポートが強化された。

CUDA/Vulkan/HEXAGONの主要バグ修正とレジション対応

前提

llama.cppは、GGUF形式の量子化モデルをCPUやGPUで高速に推論するためのC/C++エンジンである。CUDAやVulkanなどのバックエンドを通じて、ユーザーのハードウェア環境に合わせた推論が可能だが、新バージョンやハードウェアの登場に伴い、特定の条件下で不具合が発生することがある。

何が変わったか

今回の更新・修正では、主に以下の不具合が対象となっている。

不具合内容	影響環境	修正状況
CUDA FA stream-kブロック数不整合	RTX 5090 (170 SMs)	修正により速度回復
Vulkan RADV転送キュー文字化け	AMD GPU (Vulkan)	報告中
MTP (多トークン予測) 動作不良	SYCL / Intel Arc	報告中
OpenAI APIツール呼び出しの終了通知欠落	/v1/responses エンドポイント	報告中

特に重要なのは、RTX 5090におけるFlash Attention (FA) パスの遅延問題だ。長文コンテキスト（65K〜131Kトークン）でのprefill処理が、RTX 4090と比較して10〜13%遅くなる現象が発生していた。修正後は、この遅延が解消され、RTX 4090と比較して約37〜40%の高速化が確認されている。

なぜ重要か

16GBクラスのGPUユーザーにとって、長文コンテキストの処理速度は実用性を左右する。また、RTX 5090のような高性能GPUを使用している場合、ソフトウェア側の不具合により本来の性能が発揮されない可能性がある。今回の修正により、長文処理における推論速度の安定性が確保された。

根拠のリンク

利用者の報告

RTX 5090における長文prefillの遅延と修正効果 ユーザー @Nebiforever による報告では、RTX 5090 (170 SMs) において、CUDA 13.4.59、ドライバー 595.91.07、llama.cpp b11674 の環境で、Qwen3.5-9B-Q4_K_Mモデルを用いた長文prefill（-d 65536/131072）がRTX 4090より遅いという現象が確認された。原因は、MMAカーネル（ncols=64, nbatch_fa=32）の実行ブロック数が、stream-kアルゴリズムにおいてRTX 5090のSM数（170）に対して割り切れない値（340ブロック）になっていたことにある。これにより、RTX 4090（128 SMs, 256ブロック）と比較して効率的に処理できなかった。修正後は、この不整合が解消され、短文コンテキストやトークン生成時と同様に、RTX 5090がRTX 4090に対して約20%高速なパフォーマンスを発揮するようになった。 MTP (Multi-Token Prediction) の動作不良 ユーザー @shansen008 は、Ryzen 9 5900XT / Intel Arc Pro B70、SYCLバックエンドの環境で、最新リリースへの更新後、MTP（多トークン予測）が機能しなくなったと報告している。Qwen3.8-27B-UD-Q4_K_XLモデルとmtp-Qwen3.8-27B-Q4_0ドラフトモデルを使用しているが、トークン生成速度が10 tok/s程度に低下し、思考ボックスがガビッジを出力する無限ループに陥る現象が発生した。

Qwen3.8-Flash-Next (125B) の16GB GPU実測と最適化技術

前提

Qwen3.8-Flash-Nextは、125Bパラメータ（アクティブ51B）のMoE（Mixture of Experts）モデルである。通常、このような超大規模モデルは複数のGPUや大量のVRAMを必要とするが、量子化技術や推論エンジンの最適化により、16GBクラスのGPUでも動作可能となってきた。

何が変わったか

コミュニティによる実測では、16GB VRAMのGPU単体、あるいは16GBを含む複数GPU構成で、Qwen3.8-Flash-Nextが実用的な速度で動作している。

環境	推論エンジン	量子化	速度 (tok/s)
RTX 5060 Ti 16GB (1枚)	Strata	Q3	52
RTX 5070 12GB + 5060 Ti 16GB (2枚)	Strata v0.1.45	IQ3_S	50-64 (decode)
RTX 4090 (1枚)	llama.cpp (UD)	IQ3_XXS	86.5 (decode)
RTX 4090 (1枚)	vLLM	FP4	174.8

なぜ重要か

16GB GPUを持つユーザーにとって、MoEモデルは「VRAM不足で動かない」というイメージが強かった。しかし、Qwen3.8-Flash-Nextのようなモデルが、単一の16GB GPUや、16GBを含む混合構成で動作することは、ローカルLLMの利用範囲を大幅に広げる。特に、StrataなどのエンジンがNVIDIAとAMDの混合GPU構成をサポートしたことで、既存のGPUを有効活用した推論環境の構築が可能になった。

根拠のリンク

利用者の報告

RTX 5060 Ti 16GB 単体での動作 ユーザー @Indy_triguy は、RTX 5060 Ti 16GB、DDR4 64GBの環境で、Qwen3.8 Flash Next (Q3量子化) を動作させ、52 tok/s の推論速度を記録した。また、Qwen3.8 27BをSpark環境で併用し、複数エージェントによる256Kコンテキストセッションと、Flash Nextを批評役として使用するハイブリッドな運用も可能であると報告している。 RTX 5070 12GB + 5060 Ti 16GB 混合構成での動作 ユーザー @murasametech は、RTX 5070 12GB と RTX 5060 Ti 16GB の2枚構成（VRAM合計28GB）、RAM 64GB（WSL2に56GB）で、Strata v0.1.45 を使用して Qwen3.8-Flash-Next GSQ-RCO IQ3_S (約84GB) を動作させた。GPUに収まらないモデル部分はRAMとSSDに配置している。実測では、Decodeが約50〜64 tok/s、1.4万トークン入力のPrefillが417〜440 tok/s となった。文章が流れていく速度は実用的であり、待たされる感じはないと評価している。 RTX 4090 における高速推論 ユーザー @PotatoLordsLab は、Dell C4130 (3× V100 16GB + 1× Tesla M10) という複数GPU構成で、Qwen3.8-Flash-Next (NVIDIA FP4) をテストし、MTPドラフト有効時に102.4 tok/s、最良のチャット応答で112.7 tok/s、262Kコンテキストで55.1 tok/s を記録した。

MoE推論の高速化：SLRUキャッシュとホストRAM expert配置

前提

MoE（Mixture of Experts）モデルは、入力に応じて複数の「専門家（Expert）」パラメータを動的に選択して推論を行う。この際、頻繁にアクセスされるExpertを高速に保持するキャッシュ機構が重要となる。また、VRAMが不足する場合、ExpertをホストRAM（CPUメモリ）に配置し、GPUとの間でデータ転送を行う手法も検討されている。

何が変わったか

llama.cppにおいて、MoE用の単純なLRU（Least Recently Used）キャッシュが、50/50に分割されたSLRU（Second Chance LRU）キャッシュに置き換えられた。これは、ガーベジコレクションの世代別GCに似た仕組みで、安定した「古い」セットと、変動の大きい「若い」セットを分離することで、単純LRUと比較して1〜5%の性能向上を実現した。また、ホストRAMにExpertを配置するパイプライン並列化のプルリクエスト（#29963）や、512 ExpertのMTPドナーを256 Expertのアーキテクチャに適応するツール（#30770）も開発されている。

なぜ重要か

16GB GPUユーザーがMoEモデルを扱う際、キャッシュの効率は推論速度に直結する。SLRUキャッシュへの移行により、同じVRAM環境でもより安定した高速推論が可能になる。また、ホストRAMを活用する技術の進展は、VRAM不足による推論失敗を回避する手段として注目される。

根拠のリンク

vLLM/SGLangのNVFP4対応と最新リリース

前提

vLLMとSGLangは、大規模言語モデルの推論を高速化するための主要な推論エンジンである。NVFP4（NVIDIA FP4）は、4ビット浮動小数点量子化の一種で、メモリ使用量を大幅に削減しつつ、推論速度の向上を目指す技術。

何が変わったか

vLLM 0.32.0（2026年10月17日リリース）では、NVFP4 KVキャッシュが正式にサポートされた。これにより、注意機構のヘッドテンソルを4ビットFP精度で保存し、FP8と比較してKVメモリを約4倍削減。A100環境では約3.75倍長いシーケンスを処理可能となった。また、Model Runner V2の導入により、MoE、ハイブリッド注意機構、MTP、マルチ入力などを統一してサポートするようになった。 SGLang v0.5.21では、CUDA 13とTorch 2.11をベースとし、Qwen3.6 NVFP4やQwen3.8-Flash-Nextなどの新モデルサポート、およびMTP（Multi-Token Prediction）対応が強化された。

なぜ重要か

16GB GPUユーザーにとって、VRAMの効率的な使用は必須である。NVFP4 KVキャッシュの導入により、より長いコンテキストやバッチサイズでの推論が可能になる。また、vLLMとSGLangの両方でMTPサポートが強化されたことで、推論速度のさらなる向上が期待できる。

根拠のリンク

Unslothのメモリ削減技術とStudio新機能

前提

Unslothは、ファインチューニングと推論を高速化するためのライブラリ。特に、VRAM使用量の削減と推論速度の向上に注力しており、16GB GPUでの大規模モデル操作を可能にする技術を提供している。

何が変わったか

Unsloth v2026.10.6（2026年10月15日リリース）では、NVIDIA Nemotron 3.5 Boltが24GBメモリで動作可能となった。また、Meta Muse Spark Open (816B) が256GBメモリで動作するよう最適化された。 LoRAトレーニングにおいては、NVFP4、INT4、MXFP4のチェックポイントに対して、元のパックされた重みから直接トレーニングを行うことで、VRAM使用量を削減しつつ精度を保持する技術が導入された。例えば、Qwen3.8-27B-NVFP4の場合、ピークメモリ使用量が72.9 GBから40.2 GBに約44%削減された。 Unsloth Studioでは、llama.cpp RPCプロトコルを使用したGGUFモデルの分散推論（PR#13726）や、REAP Expert Pruning（PR#14130）などの新機能が追加された。

なぜ重要か

16GB GPUユーザーにとって、LoRAトレーニング時のVRAM不足は大きな障壁であった。パックされた重みからの直接トレーニングにより、より大きなモデルや複雑なファインチューニングが、消費メモリを抑えて実行可能になる。また、分散推論機能により、複数マシンを活用した大規模モデルの推論環境構築が容易になる。

根拠のリンク

出典

【CUDA 16GB向け】llama.cpp新PR: 低ビット量子化の高速化、16GB GPUのOOM解消、MTPとGLU最適化

Thu, 15 Oct 2026 20:33:45 +0000

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

llama.cpp は ggml-org が開発する C/C++ の LLM 推論エンジン。GGUF 形式の量子化モデルを CPU/GPU で動かす。

今回の要点

低ビット量子化 (q2_K/q3_K/q6_K) における MMVQ カーネルの高速化により、最大 1.67 倍の速度向上を確認 (PR #30517)。
VRAM 不足 (OOM) 対策として、16GB などの限られたメモリ環境向けに VMM 予約サイズを 32GB から 8GB に削減 (PR #30542)。
MTP (Multi-Token Prediction) 利用時の推論速度低下を招くウォームアップ再実行バグを修正 (PR #30511)。
FFN 演算のオーバーヘッド削減のため、MMQ パスでの GLU 融合を実現 (PR #30489)。

低ビット量子化MMVQカーネル高速化で推論速度向上

llama.cpp では、マルチモーダルベクトル量子化 (MMVQ) を低ビットタイプで実行する際のパフォーマンスが最適化された。これは 60 段階の蒸留ステップで評価された結果、RTX 3090 において q2_K で 1.59 倍、q3_K で 1.67 倍、q6_K で 1.06 倍の速度向上を確認している。RTX PRO 6000、5090、4090 でも 1〜13% の改善が見られた。この最適化は sm_80/86/87/89 (RTX 3080/4080/5060Ti 等) を含むすべての CUDA GPU 対象であり、特に 16GB クラスの GPU に恩恵が大きい。

低ビット量子化モデルを推論する際、速度が大幅に向上するため、RTX 3080 や 4080、5060 Ti などの 16GB VRAM を搭載した環境でも、より高速に推論を実行できるようになる。

根拠: CUDA: faster MMVQ for low-bit types (PR #30517)

CUDA VMM予約サイズ削減で16GB GPUのOOM解消

VRAM が限られた GPU 環境で発生する CUDA out-of-memory (OOM) エラーを解消するため、VMM (Virtual Memory Management) プールの予約サイズが変更された。従来 32GB だった予約サイズが、統合メモリを持つ GPU で 8GB に引き下げられた。これにより、VRAM が限られた 16GB 搭載の RTX カードでも、OOM に陥りにくくなり、安定した動作が期待できる。

VRAM 不足に悩まされていた 16GB GPU ユーザーにとって、メモリ不足による推論失敗が解消される決定版的な改善となる。

根拠: cuda: Lowering VMM pool reservation size to 8 GB on GPUs with combined memory (PR #30542)

MTP推論時のウォームアップ再実行バグ修正

speculative decoding (推論加速技術) の一種である MTP (Multi-Token Prediction) を使用する場合、ターゲットグラフが変更された後にウォームアップが再実行されないバグがあった。この修正により、MTP グラフ変更後のウォームアップ不足が解消され、推論速度の低下や不安定さが改善される。CUDA 環境での speculative decoding 利用時に、より安定したパフォーマンスが得られるようになる。

MTP を利用しているユーザーにとって、推論速度の低下や不安定さが解消され、よりスムーズな推論が可能になる。

根拠: spec: re-run warmup after MTP changes the target graph (PR #30511)

MMQパスでのGLU融合でFFN演算のオーバーヘッド削減

MoE (Mixture of Experts) モデルのデコード速度改善のため、MMQ パスでの GLU (Gated Linear Unit) 融合が実装された。従来、batched (MMQ) パスでは GLU が独立したカーネルとして実行されていたが、SWIGLU/GEGLU/SWIGLU_OAI/SWIGLU_CLAMP が Q8_1 quantize カーネル内で registers に融合された。これにより、FFN 毎の ubatch での write/read が不要になり、MoE (MUL_MAT_ID) を含む FFN 演算のオーバーヘッドが削減される。VRAM 消費も抑制される可能性がある。

MoE モデルを推論する際、FFN 演算のオーバーヘッドが削減されるため、デコード速度が改善される。VRAM 消費も抑制される可能性があるため、16GB GPU での MoE モデル利用にも寄与する。

根拠: llama.cpp PR #30489: fuse GLU into MMQ Q8_1 activation quantization — eliminate extra kernel launch

出典

【CUDA 16GB向け】llama.cppの最新修正：16GB GPU向けMMQ最適化、VRAM節約、MTPバグ回避

Wed, 14 Oct 2026 20:35:25 +0000

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

【CUDA 16GB向け】llama.cpp 10月第2週：MTP推論の安定化、NVFP4カーネル導入、FlashAttention修正

Tue, 13 Oct 2026 20:33:42 +0000

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

【CUDA 16GB向け】16GB GPU環境向け新モデル公開とllama.cppのバグ修正：Qwen3.8、MiniCPM-V 4.7、VRAM過剰確保問題

Sun, 11 Oct 2026 20:33:24 +0000

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

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

Sat, 10 Oct 2026 20:33:27 +0000

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

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

Fri, 09 Oct 2026 20:34:14 +0000

この記事は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)

出典

【CUDA 16GB向け】llama.cpp: 非連続テンソル処理の大幅強化、Blackwell (RTX 50) 対応、Qwen3.8-27B 向け 16GB 最適化

Thu, 08 Oct 2026 20:35:08 +0000

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

【CUDA 16GB向け】llama.cpp: GLM5Next MTP対応、PLaMo-3トークナイザー修正、EmbeddingGemma2サポート

Wed, 07 Oct 2026 20:35:17 +0000

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