AMD Ryzen 内蔵GPU (Radeon 780M) でVulkan LLMを動かす最新動向：性能崖・電力問題・ROCmの出力不具合

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

今回の要点

• Vulkan MoE推論の性能崖：n_tokens=9 でスループットが急減するバグが修正された。Mesa 26.1.4 でドライバー安定性も向上。
• AMD iGPUの電力管理回帰：Ollama 0.32.10以降でVulkanパスが失敗する報告、Strix Halo環境では常時最大クロック化による電力消費増大の報告。
• ROCm出力不具合：Strix Halo (gfx1151) で4kトークン超の長文プロンプト時にROCmバックエンドのみ出力が破綻する。
• Vulkan最適化の蓄積：F32行列読込やSparse Flash Attention、MoEタイル選択など、AMD iGPU向けVulkan最適化が複数PRで取り込まれている。

Vulkan MoEバッチ推論の性能崖とMesa 26.1.4安定化

前提

MoE (Mixture of Experts) モデルは複数の専門家ネットワークを持ち、入力に応じて必要な部分のみを推論するアーキテクチャ。バッチ推論では複数の入力を同時に処理するが、トークン数によって処理効率が急変する現象が報告されている。

何が変わったか

Qwen3-Coder-Next 30B-A3B (512 experts, top-10, Q4_K_XL) を AMD Strix Halo iGPU (gfx1151) で推論した際、n_tokens=9 でバッチデコードのスループットが急減する性能崖が確認された。この 8-token 閾値に関するバグが MMV dispatch で修正された llama.cpp Issue #25356。また、Mesa 26.1.4 では RADV (AMD Vulkan) 向けの UBO (Uniform Buffer Object) 境界チェックバグ修正、taskmesh sync バグ修正、RDNA 3 ハードウェアのスタッター改善が含まれ、Vulkan 仕様が 1.4.354 に更新された。780M (RDNA3/gfx1103) ユーザーには安定性向上が期待される。

なぜ重要か

MoE モデルを Vulkan で動かす際、特定のトークン数で推論速度が急減する問題が解消され、より安定したパフォーマンスが期待できる。ドライバー側の修正により、RDNA 3 以降の iGPU でも推論の安定性が向上する。

根拠のリンク

• Vulkan: batched decode throughput cliff at n_tokens=9 on many-expert MoE
• Mesa 26.1.4: RADV/NVK fixes — UBO bounds, taskmesh sync, Vulkan 1.4.354

利用者の報告

Vmarcelo49 は RX 9070 XT 16 GB (CachyOS) で llama.cpp:server-vulkan b11176 と llama.cpp:server-rocm b10884 を比較した。65536 コンテキストでは Vulkan が 43.7 tok/s (prefill 700.8 t/s) で、ROCm の 33.5 tok/s (prefill 714.1 t/s) を上回った。131072 コンテキストでも Vulkan の 37.4 tok/s は ROCm を上回る結果となった。

ronwal は macOS (MoltenVK) で AMD Radeon RX 6800 XT (RDNA2) を使用した際、llama-server がデフォルトの 4 サーバースロットで ~70 トークン超のプロンプト時に ErrorDeviceLost でクラッシュする問題を報告。--parallel 1 で回避可能。

peertubehubgit は Ubuntu 24.04.5 LTS (ROCm 10.0.0, Mesa 25.2.8) で AMD Radeon RX 6750 XT (gfx1031) と Radeon AI PRO R9700 (gfx1201) を使用し、Vulkan デバイスとして認識されていることを確認。

AMD iGPUの常時最大クロック化とOllama Vulkan回帰

前提

Ollama は LLM を簡単に実行するためのフレームワーク。AMD iGPU では Vulkan バックエンド経由で推論を行うが、バージョンアップに伴い動作に問題が生じる報告がある。

何が変わったか

Ollama 0.32.10 以降、AMD Radeon 780M で Vulkan パスが大規模なモデル割り当て時に失敗する回帰が発生した。回避策として OLLAMA_VULKAN=0 と OLLAMA_IGPU_ENABLE=0 を設定し CPU にフォールバックする方法が示された ollama Issue #17748。また、AMD Strix Halo (gfx1151) では 2 つ以上のモデルを常駐させると GPU がアイドル時でも最大クロック (~25W) で動作し続ける問題が報告された ollama Issue #18038。モデルを 1 つに限定するとアイドル時の電力消費は正常に戻る。

なぜ重要か

780M ユーザーは Ollama 0.32.10 以降、Vulkan 経由での大規模モデル実行が失敗する可能性がある。また、Strix Halo ユーザーは複数のモデルを同時に使うと電力消費が増大し、冷却負荷が高まる。

根拠のリンク

• AMD Radeon 780M Vulkan regression in Ollama >=0.32.10
• AMD Strix Halo (gfx1151): keeping ≥2 models resident pins GPU at max clock

利用者の報告

Vmarcelo49 は RX 9070 XT 16 GB で Vulkan バックエンドが 128K コンテキストをロードできるのに対し、ROCm イメージは OOM (Out of Memory) で失敗することを報告。Vulkan の方がメモリ効率が良好なケースがある。

giovannimanzoni は Ryzen 9 9950X3D (CPU) と RTX PRO 4000 Blackwell (CUDA/Vulkan) で 141 回のテストを実施。Vulkan 構成 (4B Q8_0) も含め、CUDA と比較して同様の結果を得たと報告。

peertubehubgit は Ubuntu 24.04.5 LTS で ROCm 10.0.0 と Mesa 25.2.8 を使用し、Vulkan デバイスとして AMD GPU が認識されていることを確認。

ronwal は macOS (MoltenVK) で AMD Radeon RX 6800 XT を使用し、llama-server がデフォルトの 4 サーバースロットで ~70 トークン超のプロンプト時に ErrorDeviceLost でクラッシュする問題を報告。--parallel 1 で回避可能。

Strix Halo (gfx1151)のROCm出力不具合

前提

ROCm は AMD の GPU 計算プラットフォーム。llama.cpp や Ollama は ROCm バックエンド経由で AMD GPU を利用する。

何が変わったか

Strix Halo (gfx1151) で ROCm バックエンドを使用時、~4k トークン超のプロンプトで出力が正しく生成されない不具合が確認された。同じマシンで Vulkan バックエンドと CPU バックエンドは正常に動作した ollama Issue #17958。

なぜ重要か

Strix Halo ユーザーは長文プロンプトを扱う際、ROCm バックエンドではなく Vulkan または CPU バックエンドを使用する必要がある。

根拠のリンク

• ROCm backend returns wrong output for prompts >4k tokens on gfx1151

利用者の報告

Vmarcelo49 は RX 9070 XT 16 GB で Vulkan バックエンドが 128K コンテキストをロードできるのに対し、ROCm イメージは OOM (Out of Memory) で失敗することを報告。Vulkan の方がメモリ効率が良好なケースがある。

giovannimanzoni は Ryzen 9 9950X3D (CPU) と RTX PRO 4000 Blackwell (CUDA/Vulkan) で 141 回のテストを実施。Vulkan 構成 (4B Q8_0) も含め、CUDA と比較して同様の結果を得たと報告。

peertubehubgit は Ubuntu 24.04.5 LTS で ROCm 10.0.0 と Mesa 25.2.8 を使用し、Vulkan デバイスとして AMD GPU が認識されていることを確認。

ronwal は macOS (MoltenVK) で AMD Radeon RX 6800 XT を使用し、llama-server がデフォルトの 4 サーバースロットで ~70 トークン超のプロンプト時に ErrorDeviceLost でクラッシュする問題を報告。--parallel 1 で回避可能。

Vulkan F32行列読込最適化とSparse Flash Attention

前提

F32 (32ビット浮動小数点) 行列の読込最適化や、量子化 K/V キャッシュ向けの Sparse Flash Attention は、長文コンテキスト処理におけるメモリ使用量と推論速度に影響する。

何が変わったか

llama.cpp PR #29254 で、Vulkan バックエンドの F32 A 行列読込が 2 要素ずつ (2-aligned 時) に最適化された。Intel GPU 向けだが、gfx1103 などの Vulkan 互換ハードでも同様の最適化が効く可能性がある。llama.cpp PR #29639 では、量子化 K/V キャッシュ向け Sparse Flash Attention が Vulkan バックエンドに追加された。AMD iGPU (780M) は UMA 制約で K/V メモリの節約が特に重要で、長文プロンプト時の 32GB UMA 占有率低下に直結する可能性が高い。

なぜ重要か

長文コンテキストを扱う際、メモリ使用量が削減され、推論速度が向上する可能性がある。特に UMA 環境では K/V キャッシュの節約が重要。

根拠のリンク

• llama.cpp #29254 vulkan: Load F32 A matrix 2 at a time when its 2-aligned
• llama.cpp #29639 vulkan: sparse flash attention for quantized K/V

Vulkan MoE推論のタイル選択最適化

前提

MoE 推論では、タイルサイズを動的に選択することでパフォーマンスを最適化する。

何が変わったか

llama.cpp commit 94a0ae3e で、Vulkan の MoE mat_mul_id でタイルサイズを MoE 特性に合わせて動的選択する最適化が取り込まれた。AMD iGPU の MoE 推論パフォーマンス改善が期待される。

なぜ重要か

MoE モデルを Vulkan で動かす際、より効率的な推論が可能になる。

根拠のリンク

• llama.cpp 94a0ae3e vulkan: MOE aware mat_mul_id tile selection

出典

• Vulkan: batched decode throughput cliff at n_tokens=9 on many-expert MoE
• Mesa 26.1.4: RADV/NVK fixes — UBO bounds, taskmesh sync, Vulkan 1.4.354
• AMD Radeon 780M Vulkan regression in Ollama >=0.32.10
• AMD Strix Halo (gfx1151): keeping ≥2 models resident pins GPU at max clock
• ROCm backend returns wrong output for prompts >4k tokens on gfx1151
• llama.cpp #29254 vulkan: Load F32 A matrix 2 at a time when its 2-aligned
• llama.cpp #29639 vulkan: sparse flash attention for quantized K/V
• llama.cpp 94a0ae3e vulkan: MOE aware mat_mul_id tile selection
• Proposal: an `amd-vulkan` backend for AMD cards
• First Linux + NVIDIA run: RTX PRO 4000 Blackwell (CUDA, Vulkan) and Ryzen 9 9950X3D CPU-only numbers
• 2 AMD GPU (gfx103X,gfx120X), lemonade backends install llamacpp:rocm defaults to gfx103X / GPU: 0
• Eval bug: Vulkan/MoltenVK + AMD discrete GPU: ErrorDeviceLost with the default 4 server slots and prompts above ~70 tokens; --parallel 1 fixes it