RDNA4 の prefill 性能低下、Vulkan ハング、Intel Arc の極端な低速化：llama.cpp Vulkan 関連の深刻な不具合報告

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

今回の要点

• RDNA4 (RX 9070 XT) で prefill 性能が 12% 低下：PR #29182 が原因。Revert で解消。
• Vulkan fence wait が GPU フォルト時に永久にブロック：ドライバー側で device loss が検知されない場合にスレッドがハングする。
• Strix Halo (gfx1151) で Qwen4exp モデルの初期化がハング：ROCm/HIP 環境で発生し、mmap や CPU-MoE 設定でも再現。
• Intel Arc Pro B50 で decode 時の MUL_MAT_VEC が 5〜7 倍遅い：単体テストでは正常だが、モデル内では極端に低速化する。
• Vulkan MoE ルーティングで expert id 重複時に行が消失：n > 8 の条件で MUL_MAT_ID の計算結果が破綻する。

Vulkan RDNA4 (RX 9070 XT) で prefill 性能が 12% 低下

Vulkan バックエンドにおける MoE モデルの処理効率を改善するはずの PR #29182 (MoE-aware mul_mat_id tile selection) が、RDNA4 アーキテクチャ搭載の GPU で逆効果となっている。

この変更により、AMD Radeon RX 9070 XT (RADV GFX1201, RDNA4) 環境において、プロンプト処理 (prefill) の性能が最大 12% 低下した。トークン生成 (decode) への影響はないが、長いプロンプトの処理速度に直結する重大な回帰バグである。この問題は Mesa 26.0.8 および kernel 7.0.0-31 環境で確認されており、RDNA4 を搭載するすべての GPU ユーザーに影響が及ぶ。

この不具合の根拠は以下の Issue で報告されている。

• Vulkan: ~12% prefill regression on RDNA4 (RX 9070 XT) since #29182 (Issue #29892)

利用者の報告

• Linux + NVIDIA RTX PRO 4000 Blackwell 環境において、CUDA および Vulkan（4B Q8_0）で計 141 回のランが完了し、Windows 版と同等の回答が得られた。 giovannimanzoni

利用者の報告

@aliensnoop 氏は、Ryzen 7 7700X と RX 9070 XT (RADV GFX1201) を用いた環境で、Qwen3.6-35B-A3B モデル (unsloth UD-IQ3_S, 256 experts, top-8) においてこの現象を再現した。以下のコマンドでベンチマークを行った結果、変更前のビルドでは 2148〜2154 t/s だった性能が、変更後 (bed0a8566) では 1899 t/s に低下した。また、変更前の親コミット (da89bb3cc) に revert することで性能が完全に回復したことを確認している。

GGML_VK_VISIBLE_DEVICES=0 llama-bench -m Qwen3.6-35B-A3B-UD-IQ3_S.gguf -ngl 99 -fa 1 --n-cpu-moe 0 -b 4096 -ub 1024 -d 48000 -p 2048 -n 0 -r 5

環境：Linux (Ubuntu 26.04), Mesa 26.0.8, kernel 7.0.0-31-generic, Ryzen 7 7700X, RX 9070 XT

Vulkan fence wait が GPU フォルト時に永久にブロックする不具合

Vulkan の同期プリミティブである fence の待機処理において、GPU 側でフォルトが発生した際にドライバーが正常にエラーを報告しない場合、llama.cpp 側のスレッドが永久にブロックする不具合が報告された。

通常、GPU フォルト発生時は `VK_ERROR_DEVICE_LOST` 等のエラーが返却され、アプリケーション側でリカバリー処理や終了処理が行われる。しかし、ドライバー側で device loss が検知されず `VK_NOT_READY` が返り続ける場合、`ggml_vk_wait_for_fence` 内のループから脱出できず、スレッドが 100% の CPU リソースを消費し続ける状態 (スピン) に陥る。これにより、推論処理全体がハングし、プロセスの回復が不可能になる。

この不具合の根拠は以下の Issue で報告されている。

• Eval bug: ggml-vulkan ggml_vk_wait_for_fence spins forever on GPU fault (Issue #29926)

利用者の報告

@yotamleo 氏は、Linux 7.2 および NVIDIA RTX 4090 (driver 615.71.09, open kernel module) の環境で、ランキング文脈のデコード中に `NVRM: Xid 109 CTX SWITCH TIMEOUT` が発生した際、この不具合に遭遇した。オーバークロックおよびアンダーボルト設定で再現し、標準クロックでは 5 回の試行で再現しなかった。フォルト発生後、`llama_decode` 内のスレッドが永久にスピンし、`ggml-vulkan.cpp` 内の `getFenceStatus` ループから脱出できなくなった。

環境：Linux 7.2, NVIDIA RTX 4090, driver 615.71.09 (open kernel module), llama.cpp b10361 (node-llama-cpp 3.20.0 Vulkan prebuilt)

Vulkan/HIP で Qwen4exp 読み込み時にサーバーが初期化でハング

ROCm/HIP バックエンドにおいて、Strix Halo (gfx1151) 環境で Qwen4exp アーキテクチャの超大規模 MoE モデルを読み込む際、サーバーの初期化処理でハングする不具合が報告された。

この問題は、`--load-mode mmap` または `--cpu-moe` オプションを指定した場合に発生し、単一スレッドがスピンし続ける状態になる。入出力 (I/O) も発生しないため、ディスクやメモリ帯域のボトルネックではなく、計算または同期処理のデッドロックが疑われている。この問題は、関連する修正コミット (#29825) を含む最新のビルドでも解消されていない。

この不具合の根拠は以下の Issue で報告されている。

• HIP/ROCm: llama-server hangs at init (single-thread spin, no I/O) on qwen4exp / Strix Halo gfx1151

利用者の報告

@heisejufeng 氏は、AMD Strix Halo iGPU (gfx1151) を搭載した環境で、`unsloth/Qwen3.8-Flash-Next-GGUF` (UD-Q4_K_XL, 4 shards, ~106 GB total) モデルの読み込み時にこの現象を確認した。ROCm 7.2.2 および unified memory 128 GiB の環境で、`--spec-type draft-mtp` 有無に関わらず再現した。同一ハードウェアにおいて、他の設定やモデルでは正常に動作することから、Qwen4exp アーキテクチャと Strix Halo (gfx1151) の組み合わせに起因する問題と見られる。

環境：Ubuntu 24.04.5, kernel 7.0.0-31-generic, AMD Strix Halo iGPU (gfx1151), ROCm 7.2.2, unified memory 128 GiB

Vulkan MoE ルーティングで expert id 重複時に行が消失するバグ

Vulkan バックエンドにおける MoE (Mixture of Experts) モデルのルーティング処理で、同一トークン行内に同じ expert id が複数出現する場合、計算結果の行 (rows) が消失するバグが報告された。

このバグは、MUL_MAT_ID 演算において expert id の重複を正しく処理できていないことに起因する。特に、処理対象の行数 (n) が 8 を超える場合に顕著に発生し、MoE モデルの出力品質や正答性を損なう根本的な計算エラーとなる。この問題は、Vulkan 経由で MoE モデルを実行するすべてのユーザーに影響する可能性がある。

この不具合の根拠は以下の Issue で報告されている。

• vulkan: MUL_MAT_ID loses rows when expert id appears more than once (Issue)

利用者の報告

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

Intel Arc Pro B50 で Vulkan decode MUL_MAT_VEC が極端に低速

Intel Arc Pro B50 (Intel Arc Pro GPU) を用いた Vulkan 環境において、モデル内でのデコード処理時 (decode) に実行される MUL_MAT_VEC 演算が、単体テスト時と比較して 5〜7 倍も低速化する現象が報告された。

この問題は、同一デバイス、同一ビルド、同一形状の演算であっても、モデルグラフ内での実行時と単体テスト (`test-backend-ops perf`) 時で性能に大きな差が出ることを示している。Intel Arc ユーザーにとって、推論速度に 5〜7 倍の差が出る重大なパフォーマンス問題である。

この不具合の根拠は以下の Issue で報告されている。

• Vulkan: decode MUL_MAT_VEC ~5-7x slower in-model than isolated on Arc Pro B50 (Issue #29908)

利用者の報告

@HenryInter 氏は、Windows 環境 (MSVC 2026 14.5, Visual Studio 2026) および Arc Pro B50 を用いた環境で、Qwen3.8-27B (qwen35 hybrid attention/SSM, GSQ-RCO IQ3_XXS) モデルにおいてこの現象を確認した。モデル全体のデコード速度は約 10.1 t/s (tg128, 約 99 ms/token) であり、単体テストでは正常な性能が得られる演算でも、モデル内では極端に低速化した。

llama-bench -m D:\Models\Qwen3.8-27B-GSQ-RCO-IQ3_XXS.gguf -ngl 99
GGML_VK_PERF_LOGGER=1 GGML_VK_PERF_LOGGER_CONCURRENT=1 llama-cli -m D:\Models\Qwen3.8-27B-GSQ-RCO-IQ3_XXS.gguf -ngl 99 -c 4096 -n 48 -p "test"

環境：Windows, MSVC 2026 14.5, Intel Arc Pro B50, llama.cpp version 2999 (9a9394a)

出典

• Vulkan: ~12% prefill regression on RDNA4 (RX 9070 XT) since #29182 (Issue #29892)
• Eval bug: ggml-vulkan ggml_vk_wait_for_fence spins forever on GPU fault (Issue #29926)
• HIP/ROCm: llama-server hangs at init (single-thread spin, no I/O) on qwen4exp / Strix Halo gfx1151
• vulkan: MUL_MAT_ID loses rows when expert id appears more than once (Issue)
• Vulkan: decode MUL_MAT_VEC ~5-7x slower in-model than isolated on Arc Pro B50 (Issue #29908)