【780M向け】Radeon 780MのTTFTを数倍改善、長文推論のクラッシュも修正されたllama.cpp Vulkanバックエンドの最新動向

llama.cpp は ggml-org が開発する C/C++ の LLM 推論エンジン。Vulkan バックエンドで AMD iGPU でも動く。

今回の要点

• チェックポイント読み込みの高速化：VRAMキャッシュ未設定時の初回応答遅延（TTFT）が大幅に改善された。
• 長文推論のクラッシュ修正：Flash Attention 使用時の VRAM 超過エラーが報告され、修正に向けた議論が進んでいる。
• 推論精度と安定性の向上：int8 量子化モデルにおける計算不整合の修正や、RMS Norm などの最適化が適用された。
• 環境依存の初期化問題：古い Vulkan ローダー環境でのクラッシュ対策がマージされた。

Vulkan iGPUのチェックポイント読み込み高速化

Vulkanバックエンドにおいて、モデルファイル（チェックポイント）の読み込み処理が最適化されました。これにより、VRAMキャッシュが未設定の場合でも、初回のトークン生成までの時間（TTFT）が大幅に短縮されます。

Phoronixベンチマークでの調査結果によると、メモリがキャッシュされていない状態での読み込みが低速な原因を特定し、CPUからのメモリコピー（memcpy）に代わってGPU側での読み込み処理を行うように変更されました。これにより、ROCmとの性能差が縮まりました。

Radeon 8060S、Qwen3.5-4B UD-Q4_K_XL、Lemonadeベンチマークプロンプトでの計測結果です。初回実行において、修正前の600-1024ミリ秒から95-286ミリ秒へ、繰り返し実行でも290から42へと劇的な改善が見られました。llama.cpp #30049 vulkan: fix amd iGPU slow checkpoint read

利用者の報告

Radeon 780M (gfx1103) 環境において、GLM-4.7-Flash Q4_K_MモデルでVulkanバックエンドを使用時、コンテキストが長くなるとトークン生成速度が低下する現象が報告されています。この問題はFlash Attentionの最適化により改善が期待されます。Skimmenthal13

Windows 11上のAMD RDNA4 GPU (RX 9070 XT) 環境では、Hermes Agentがピン留めするllama.cppのVulkanビルドが、LM StudioのVulkanビルドと比較して約4倍低速であるという報告があります。GPUオフロード（-ngl 99）がCPU実行（-ngl 0）と同等の速度しか出ない状態でした。thevaprroomops-cmyk

AMDユーザーはROCm (HIP) またはVulkanを通じてllama.cppを実行できますが、カードやドライバーによって速度が異なるため、両方のビルドを併設して切り替えられる仕組みが提案されています。BillyMRX1

AMD GPUをtrending-local-llmsのインデックスで正式にサポートする取り組みが進んでおり、消費電力8〜48GB VRAMのRadeonカードやiGPUが日常的にGGUFモデルを動作させている実測値が記録されるようになっています。andyholst

Vulkan FA量子化KV再量化のmaxBufferSize超過

Flash Attentionと量子化KVキャッシュを併用する際、長いコンテキストで推論を行うと、必要な一時バッファのサイズがデバイスの最大確保可能サイズ（maxBufferSize）を超え、推論が失敗するバグが報告されました。

この問題は、KVエントリ数が1,048,576を超えた直後に発生し、要求された割り当てサイズが期待されるF16 K+Vスクラッチサイズと正確に一致することが確認されています。長文プロンプトを扱うユーザーにとって重大な障害となります。

llama.cpp #30048 Vulkan: FA quantized-KV dequant scratch can exceed maxBufferSize at long context

利用者の報告

Windows環境、AMD Radeon 8060S / Ryzen AI Max+ 395 (Strix Halo)、Qwen3.5-2B-GGUF:UD-Q4_K_XLモデルで、コンテキストサイズを2,097,152に設定して推論実行時、上記のバグが再現しました。ariera-j

前述のRadeon 780M環境でも、Flash Attention使用中にトークン生成速度が低下する報告があり、コンテキスト長と推論速度の相関において同様の課題が指摘されています。Skimmenthal13

Vulkan RMS Normのサブグループ削減最適化

RMS Norm演算において、サブグループ削減（subgroup reductions）を活用した最適化が適用されました。これにより、正規化処理の計算効率が向上し、推論速度の改善が期待されます。

[PR#29882] vulkan: rms norm optimization using subgroup reductions

Vulkan CM1 int8 MMQのWG Denoms不整合修正

int8量子化モデルにおけるMMQ（Matrix Multiply Quantized）演算で、ワークグループディノミネータ（wg denoms）の設定がfp16用の値を使用していた不具合が修正されました。これにより、BN（ブロックサイズ）が異なる場合のタイル分割が正常に行われ、推論精度と安定性が向上します。

特に、fp16 mmqのチューニング値とint8 large warptileのBNが一致しない環境で、列の計算が欠落するバグが修正されました。int8量子化モデルを使用するユーザーにとって、正確な推論結果を得るための重要な修正です。

llama.cpp #30058 vulkan: cm1 int8 mmq uses fp16 mmq wg denoms (tile split breaks when BN differs)

利用者の報告

Intel Arc B580環境でint8を有効化した際、test-backend-opsで41件のMUL_MAT失敗が発生し、N > 128のケースでエラーが拡大する現象が確認されました。また、128トークンを超えるプロンプトでガベージ生成が発生していました。dosermen

前述のAMD環境においても、Flash Attentionや量子化KVキャッシュの使用時におけるパフォーマンス課題が報告されており、今回の修正が推論品質の向上に寄与すると考えられます。Skimmenthal13

VulkanローダーのvkEnumerateInstanceVersion nullチェック

VulkanローダーがvkEnumerateInstanceVersion関数を保持していない場合（例：Android 8.1の1.0ローダー）、バックエンド初期化時にヌルポインタを呼び出してクラッシュする問題が修正されました。バージョン1.2未満のローダーとして扱われるようになりました。

llama.cpp #29872 vulkan : check for null vkEnumerateInstanceVersion

出典

• llama.cpp #30049 vulkan: fix amd iGPU slow checkpoint read
• llama.cpp #30048 Vulkan: FA quantized-KV dequant scratch can exceed maxBufferSize at long context
• [PR#29882] vulkan: rms norm optimization using subgroup reductions
• llama.cpp #30058 vulkan: cm1 int8 mmq uses fp16 mmq wg denoms (tile split breaks when BN differs)
• llama.cpp #29872 vulkan : check for null vkEnumerateInstanceVersion
• Feature Request: vulkan: group heads in flash attention when they don’t fit in a tile
• [Bug]: Pinned llama.cpp Vulkan build is ~4x slower than LM Studio’s Vulkan build on the same Windows AMD GPU (RX 9070 XT)
• Runtimes: pick the llama.cpp engine (CUDA/ROCm/Vulkan/SYCL/Metal/CPU), recommended by default, with safe updates
• Add AMD (ROCm/Vulkan) as a first-class backend: contract, search, classifier, README table, engine registry, tests