山村商店

llama.cpp Vulkan 修正: FlashAttention OOB 障害解消と RDNA1/AMD 系性能回帰の報告

ローカルLLMAMDVulkaniGPULLM最適化

目次
  1. 今回の要点
  2. FlashAttention 共有メモリ OOB 書き込み修正 (DeviceLost 対策)
  3. RDNA1 (gfx1010) でプロンプト処理速度が約 45% 低下する不具合
  4. Gemma-4 系モデルで Vulkan デコード速度が 5% 低下する回帰
  5. Qwen4exp QSA インデックスがビジョン有効時に OOM を引き起こす
  6. Mali-G925 で cooperative_matrix 有効化がプロンプト処理を 2.4 倍遅くする
  7. 出典

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

今回の要点

  • FlashAttention 共有メモリ OOB 修正: RADV/GFX 系 GPU の DeviceLost 障害を修正する重要パッチがマージされた。
  • RDNA1 (gfx1010) のプロンプト処理速度低下: RX 5700 XT 等でプロンプト処理速度が約 45% 低下する回帰が報告されている。
  • Gemma-4 系モデルのデコード速度低下: Vulkan 環境で Gemma-4 系モデルのデコード速度が 5% 低下する回帰が確認された。
  • Qwen4exp の VRAM 爆発: ビジョン有効時に QSA インデックスが OOM を引き起こす不具合が報告された。

FlashAttention 共有メモリ OOB 書き込み修正 (DeviceLost 対策)

Vulkan FlashAttention の共有メモリ (shmem) における境界外書き込み (Out-of-Bounds, OOB) 問題が修正された。この不具合は Nvidia の DeviceLost クラッシュを引き起こす原因となっていたが、AMD の RADV ドライバーや GFX シリーズの GPU にも影響が及ぶ可能性があり、780M や Strix Halo における潜在的なデータ破損も防止される。この修正により、RADV/GFX 系 GPU で発生していた DeviceLost 障害が解消される。

この修正は llama.cpp の PR #29988 として 2026-10-05 にマージされた。これにより、Vulkan GPU 消失エラー (vk::Queue::submit: ErrorDeviceLost) が発生していた環境で、推論が正常に動作するようになる。特に Linux + GNU 16.2.1 の環境で確認されていたエラーが修正対象となる。

利用者の報告

Skimmenthal13 氏は、Radeon 780M (gfx1103) + RADV (Mesa 26.2.4) + CachyOS (kernel 7.2.8) の環境で、GLM-4.7-Flash Q4_K_M モデル使用時にコンテキストが長くなるとトークン生成速度が低下する問題を経験している。この問題は FlashAttention の実装に関連する可能性があり、今回の OOB 修正が速度低下の根本原因の解決につながる可能性がある。

RDNA1 (gfx1010) でプロンプト処理速度が約 45% 低下する不具合

RDNA1 アーキテクチャ (gfx1010) を持つ GPU、例えば RX 5700 XT 8GB において、プロンプト処理 (PP) 速度が約 45% 低下する回帰が報告された。v0.6.0 (build b11429) と比較的古いビルド (b10455) を比較すると、PP 速度が 269.7 tok/s から 151.6 tok/s に低下している。トークン生成 (TG) 速度は 44.5 tok/s から 44.3 tok/s とほぼ変化がない。

この回帰は、GDN-hybrid モデル (Qwen3.5-9B hybrid fine-tune) で確認されており、コンテキストサイズやスレッドブロックサイズの変更では改善しない。また、公式リリースバイナリと自己ビルドバイナリ (GGML_VULKAN_USE_COOPMAT=OFF) の両方で再現しているため、Vulkan バックエンドの特定の実装に起因する可能性が高い。

利用者の報告

unfallen-314 氏は、Windows 10 19045 上で RX 5700 XT 8GB (gfx1010) を使用し、Qwen3.5-9B hybrid fine-tune (Q4_K_M) で `-fa on -ctk q4_0 -ctv q4_0 -ngl 99` の設定でテストを行った。その結果、b11429 (v0.6.0) では PP 速度が 151.6 tok/s となり、b10455 の 269.7 tok/s から約 45% 低下した。4 回の制御されたラウンドで再現を確認しており、コンテキストサイズやスレッドブロックサイズの変更では改善しないことを報告している。

Gemma-4 系モデルで Vulkan デコード速度が 5% 低下する回帰

Vulkan バックエンドにおいて、Gemma-4 系モデル (Gemma-4-E4B 7.5B Q4_0) のデコード速度が 5% 低下する回帰が報告された。この回帰は、embd + raw tokens のバッチ処理をサポートするコミット (0bb496db, PR #29622) 以降に発生している。Intel Arc B580 (Xe2) でのテストでは、デコード速度が 90.7 t/s から 86.2 t/s に低下し、プロンプト処理は 3.8% 向上している。

この回帰は Vulkan パスに限定されており、Qwen3-14B モデルでは影響がない。これは、Gemma-4 系のアーキテクチャ特有の問題、あるいは Vulkan 実装の特定パスにおける非効率性によるものと考えられる。

利用者の報告

dosermen 氏は、Intel Arc B580 (Xe2) + Windows 11 + MinGW build の環境で、Gemma-4-E4B (7.5B, Q4_0) を使用し、`llama-bench -p 512 -n 128 -r 3 -t 14 -ub 512 -fa auto` の設定でテストを行った。その結果、コミット 0bb496db 以降でデコード速度が 5.0% 低下し、プロンプト処理は 3.8% 向上した。61 コミットのバイセクションにより、0bb496db が唯一の候補であると特定している。また、Qwen3-14B モデルでは同じ境界で速度変化がないことを報告している。

Qwen4exp QSA インデックスがビジョン有効時に OOM を引き起こす

Qwen4exp モデルにおいて、ビジョン (画像) が有効になると、QSA (Sparse Attention) インデックスが OOM (Out of Memory) を引き起こす不具合が報告された。これは、マルチモーダル (M-RoPE 2D-positioned) 画像が長寿命の KV キャッシュに入ると、qwen4exp のスパースアテンションインデックスが安価なブロック粒度の選択から、O(n_kv × ubatch_size) の f32 テンソルを生成するパスにフォールバックするため、VRAM を爆発的に消費する。

この問題は、長コンテキスト (~160k トークン) と非自明な ubatch サイズの組み合わせで発生し、`cudaMalloc failed: out of memory` エラーを引き起こす。また、QSA kpool (row=2) によりインデックスキャッシュが 2 倍になり、デバイスごとにミラーリングされるため、`-sm tensor` 設定下で GPU ごとに約 400 MiB の VRAM を余計に消費する。

利用者の報告

chrisjohnson 氏は、pwilkin/llama.cpp@strix-halo (ROCm/Strix Halo) 環境で、2 つの実際のプロダクションクラッシュと意図的な再現テストにより、ビジョン有効時の OOM 問題を報告している。画像が KV キャッシュに残っている限り、この条件はクリアされず、会話の残り全体でクラッシュが再発する。また、gordan-bobic 氏は、Linux 環境で Qwen3.8-Flash-Next モデルを使用し、`-sm tensor` 設定下で GPU ごとに約 400 MiB の VRAM が余計に消費されることを報告している。

Mali-G925 で cooperative_matrix 有効化がプロンプト処理を 2.4 倍遅くする

Mali-G925 (Immortalis MC12) を持つデバイスにおいて、cooperative_matrix (coopmat) を有効化するとプロンプト処理 (PP) 速度が約 2.4 倍遅くなる不具合が報告された。`GGML_VK_DISABLE_COOPMAT=1` を設定することで、pp512 が 53.3 t/s から 125.8 t/s に向上し、デコード速度 (36.4 → 36.6 t/s) は変化がない。これは、coopmat `mul_mm` バリアントが共有メモリ検証により拒否され、より遅いパスにフォールバックしているためと考えられる。

利用者の報告

bizhonggeng 氏は、Android 16 + MediaTek Dimensity 9400 (MT6991) + Mali-G925-Immortalis MC12 の環境で、Qwen3.5-0.8B-Q4_K_M.gguf モデルを使用して A/B テストを行った。その結果、coopmat 有効時は pp512 が 53.3 t/s だったが、`GGML_VK_DISABLE_COOPMAT=1` 設定で 125.8 t/s に向上した。デコード速度は 36.4 t/s から 36.6 t/s とほぼ変化なかった。Mali は `maxComputeSharedMemorySize = 32768` (32 KB) を報告しており、coopmat `mul_mm` バリアントが共有メモリ検証により拒否され、より遅いパスにフォールバックしている可能性があると推測している。

出典

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

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