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

llama.cpp は ggml-org が開発する C/C++ の LLM 推論エンジン。GGUF 形式の量子化モデルを CPU/GPU で動かす。今回の更新では、16GB VRAM の GPU を持つユーザーにとって特に重要な、推論速度の向上と新世代 GPU への対応、そして大規模モデルの動作指針が複数同時に提供されています。

今回の要点

• CUDA: 非連続テンソルと任意ストライド演算のサポート拡大 — MTP や Speculative Decode で必須の処理が正式サポートされ、VRAM 効率と互換性が向上
• Blackwell (RTX 50) 対応と CUDA 12.8 での量子化高速化修正 — RTX 50 シリーズのネイティブビルド対応と、Blackwell 環境での遅延バグ修正
• Qwen3.8-27B: 16GB GPU 向け量子化ガイドと実測 — 16GB VRAM 環境で Qwen3.8-27B を動作させるための最適な量子化形式と VRAM 使用量の具体的な指針
• GDN カーネルの Warp 効率化と FlashAttention のレース条件修正 — GDN カーネルの並列効率向上と、FlashAttention における特定条件でのレース条件バグ修正

CUDA: 非連続テンソルと任意ストライド演算のサポート拡大

前提

llama.cpp では、推論エンジン内部でテンソル（多次元配列）を扱う際、メモリ上の配置が連続していない（非連続）場合や、ストライド（要素間の隔たり）が標準的でない場合に、処理が正しく行えない、あるいはコピー処理を挟む必要がありました。

何が変わったか

PR #29781 により、CUDA 環境における単一演算（unary ops）で、F16、F32、BF16 形式の任意の 4 次元ストライドと非連続テンソルが正式にサポートされました。これにより、MTP（Multi-Token Prediction）や Speculative Decode といった、非連続なメモリレイアウトを必要とする高度な推論手法が、CUDA でもスムーズに動作するようになりました。また、PR #28851 により非連続 SUM テンソルのサポートも CPU と CUDA で追加されています。さらに、PR #30102 では、65535 行を超えるパディング処理における 16 ビット制限のバグが修正されました。

なぜ重要か

16GB VRAM の GPU を持つユーザーにとって、VRAM を効率的に使いながら高速な推論を行うためには、Speculative Decode などの手法が不可欠です。今回の変更により、これらの手法で必須となる非連続テンソル処理が CUDA で正式サポートされ、VRAM 効率と互換性が向上しました。

根拠のリンク

• llama.cpp #29781 cuda : support arbitrary striding for unary ops on f16, f32, and bf16
• ggml: non-contiguous SUM support (CPU, CUDA) (#28851)
• CUDA : fix PAD for more than 65535 rows or slices

利用者の報告

saady789 による検証では、`test-backend-ops -b CUDA -o UNARY` コマンドを用いて、連続入力（v=0）と非連続入力の両方でテストが行われ、任意のストライドと非連続テンソルが正しく処理されることが確認されました。この変更により、従来の 1D カーネル（高速だが連続入力のみ対応）と、新しいストライド対応カーネル（ややオーバーヘッドがあるが柔軟性が高い）が適切に使い分けられるようになり、標準的な連続入力の場合でもスループットの低下は生じないと報告されています。

一方、Xeoph による RTX 3080 20GB (sm86) での報告では、長文コンテキストでの推論速度が vLLM と比較して 2.2〜2.7 倍遅いという課題が指摘されています。これは、Speculative Decode のドラフト品質ではなく、コンテキスト長に対するステップ時間の増加（約 0.2 ms / 1K KV tokens）に起因すると分析されています。今回の非連続テンソルサポートが、このコンテキスト依存性の改善に寄与する可能性があります。

Blackwell (RTX 50) 対応と CUDA 12.8 での量子化高速化修正

前提

llama.cpp は、CUDA のアーキテクチャ（SM）ごとに最適化されたカーネルをビルドします。新しい GPU がリリースされた場合、対応するアーキテクチャのコードが含まれていないと、正しく動作しないか、非常に低速になる可能性があります。

何が変わったか

PR #30099 により、CUDA 12.9 以降の環境で、RTX 50 シリーズ（Blackwell, SM103）の SASS（マシンコード）が非ネイティブビルドにも含まれるようになりました。これにより、RTX 50 シリーズの GPU を持つユーザーは、llama.cpp をネイティブにビルドせずに、かつ最適化された状態で利用できるようになりました。また、PR #30077 により、Blackwell 環境で CUDA 12.8 を使用する場合に発生していた、q4_0/q5_0 量子化の V デ量子化処理の遅延バグが修正されました。

なぜ重要か

RTX 50 シリーズの GPU を持つユーザーにとって、最新の llama.cpp をスムーズに利用できるようになり、特に量子化モデルの推論速度が向上しました。16GB VRAM の GPU を持つユーザーも、将来の GPU アップグレードを見据えて、Blackwell 対応の進捗を確認しておくことが重要です。

根拠のリンク

• CUDA: add SM103 SASS to non-native builds (#30099)
• CUDA: fix slow q4_0/q5_0 V dequantization on Blackwell with CUDA 12.8

利用者の報告

この話題に関する具体的なユーザー報告は、IR には含まれていません。

Qwen3.8-27B: 16GB GPU 向け量子化ガイドと実測

前提

27B パラメータのモデルを 16GB VRAM の GPU で動かす場合、量子化（モデルの重みを圧縮すること）が必須となります。量子化の形式によって、VRAM 使用量と推論速度、そして精度が変化します。

何が変わったか

16GB VRAM の GPU で Qwen3.8-27B を動作させるための具体的な量子化形式と VRAM 使用量が報告されています。Hugging Face の jayPark777/Qwen3.8-27B-Axon-MLQT は、3-Trit 0-SKIP MLQT 量子化で 6.43 GB、12GB/16GB GPU で 100% 収まり、RTX 3060 12GB で 55.19 tok/s、パープレキシティ保持率 99.2% を達成しています。また、localmodelwatch.tsuchitsuchi.com によるガイドでは、IQ4_XS 量子化（13.3 GB）が 16GB GPU でコンテキストの余裕を持って動作すると報告されています。ハイブリッドアテンション（4 KV ヘッド）を使用することで、f16 量子化でも 262K コンテキストで約 16GB の VRAM 使用に抑えられるとされています。

なぜ重要か

16GB VRAM の GPU を持つユーザーにとって、27B パラメータのモデルを動作させるための具体的な指針が得られました。特に、IQ4_XS や MLQT といった新しい量子化形式により、VRAM を効率的に使いながら高精度な推論が可能になります。

根拠のリンク

• Qwen3.8-27B Axon MLQT: 6.43GB, fits 16GB GPU, 55 tok/s on RTX 3060 12GB
• Qwen3.8-27B 16GB VRAM guide: IQ4_XS (13.3GB) fits 16GB with context headroom

利用者の報告

@superalesha による RTX 3090 12GB での報告では、Mirai S Qwen3.8-27B（2.4 bits per weight、11 GB ファイル）を llama.cpp で動作させ、262,144 コンテキストで 69.9 tok/s、VRAM ピーク 11.7 GB を達成しました。また、abliteration 技術を用いて有害なプロンプトへの反応を 0 にすることも、推論速度への影響をほぼなくして実現したと報告されています。この報告は 12GB GPU でのものですが、16GB GPU を持つユーザーにとって、より大きなコンテキストや高速な推論が期待できる指針となります。

GDN カーネルの Warp 効率化と FlashAttention のレース条件修正

前提

GDN（Gated Dynamic Network）カーネルは、再帰的なニューラルネットワークの推論を高速化するための CUDA カーネルです。FlashAttention は、Attention 機構の計算を効率的に行うためのアルゴリズムです。これらのカーネルの最適化とバグ修正は、推論速度と正確性に直結します。

何が変わったか

PR #30087 により、GDN カーネルで 1 Warp 当たり 2 列だった状態カラムの割り当てが 4 列に変更されました。これにより、SHFL（Warp 内でのデータシャッフル）命令が 2.5 倍減少し、トークンごとのループやアドレス計算が 2 列分で amortized されるため、効率が向上しました。また、PR #30103 により、FlashAttention の `flash_attn_ext_f16_process_tile` 関数において、`nbatch_combine != DKQ/2` の条件で発生していたレース条件バグが修正されました。

なぜ重要か

GDN カーネルの効率化により、GDN を使用するモデル（例：GLM-5.3-Flash）のプレフィル速度が向上しました。FlashAttention のレース条件修正により、特定条件下での推論結果の正確性が保証されました。16GB VRAM の GPU を持つユーザーも、これらの最適化により、より高速で正確な推論が可能になります。

根拠のリンク

• llama.cpp #30087 ggml-cuda: assign four GDN state columns per warp
• CUDA/HIP: fix race in flash_attn_ext_f16_process_tile (#30103)

利用者の報告

ServeurpersoCom による RTX PRO 6000 Blackwell での報告では、GLM-5.3-Flash (UD-IQ1_S) を `-fa on`、`q8_0 KV`、`-ub 2048` の設定でテストした結果、GDN カーネル自体のプレフィル呼び出し時間が 2.6 ms から 1.5 ms に短縮され、モデル全体のプレフィル速度で約 4% の向上が見られたと報告されています。デコード速度への影響はほぼないとのことです。また、数値的な正確性についても、マスターブランチとの KLD が同等であり、`test-backend-ops` もパスしていることが確認されました。

出典

• llama.cpp #29781 cuda : support arbitrary striding for unary ops on f16, f32, and bf16
• ggml: non-contiguous SUM support (CPU, CUDA) (#28851)
• CUDA : fix PAD for more than 65535 rows or slices
• CUDA: add SM103 SASS to non-native builds (#30099)
• CUDA: fix slow q4_0/q5_0 V dequantization on Blackwell with CUDA 12.8
• Qwen3.8-27B Axon MLQT: 6.43GB, fits 16GB GPU, 55 tok/s on RTX 3060 12GB
• Qwen3.8-27B 16GB VRAM guide: IQ4_XS (13.3GB) fits 16GB with context headroom
• llama.cpp #30087 ggml-cuda: assign four GDN state columns per warp
• CUDA/HIP: fix race in flash_attn_ext_f16_process_tile (#30103)
• saady789 の報告
• Xeoph の報告
• @superalesha の報告
• ServeurpersoCom の報告