山村商店

【780M向け】Radeon 780M実測: Vulkanバックエンドの高速化、性能回帰の回避策、Ollamaの検出不具合

目次
  1. 今回の要点
  2. 780M実測: VulkanがHIPを凌駕、Gemma 4 12Bで推論速度比較
  3. Vulkanバックエンド: unified KV cache slots PRによる性能回帰と回避策
  4. Vulkan RDNA3 narrow MMVQパッチで780Mの推論速度が12.2%向上
  5. Ollama: gfx1103検出拒否とVulkanデバイスイヌメレーション不具合
  6. 780M実測ベンチ: Gemma 4 12B (20.9 t/s) と GPT-OSS 20B (UMA活用)
  7. 出典

この記事はAIによって編集・作成されています。

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

今回の要点

  • VulkanがHIPより高速: 780M (gfx1103) 環境で、Gemma 4 12B 等の推論において Vulkan が ROCm/HIP を凌駕する実測データが報告されている。
  • 性能回帰に注意: unified KV cache slots 関連の PR により TTFT/ITL が悪化する回帰が確認されており、回避策の実装が必要。
  • RDNA3 向け最適化: 780M 向けに narrow MMVQ パッチを試験した結果、推論速度が 12.2% 向上した。
  • Ollamaの障害: gfx1103 (780M) の検出拒否や、Vulkan デバイスイヌメレーションの不具合により、Ollama での利用に支障が出ている。
  • 32GB UMA での運用: 32GB RAM 環境において、Vulkan は VRAM と GTT を柔軟に活用し、Gemma 4 12B や GPT-OSS 20B の快適な推論を可能にする。

780M実測: VulkanがHIPを凌駕、Gemma 4 12Bで推論速度比較

AMD 製 iGPU (Radeon 780M / gfx1103) において、llama.cpp の Vulkan バックエンドが従来の ROCm/HIP バックエンドを上回る性能を示す実測データが報告された。これにより、AMD iGPU ユーザーにとって Vulkan が有力な選択肢となり得る。

ozdogar2 による 2026年10月1日〜2日の実測では、Gemma 4 12B (Q4_K_M) を使用し、Vulkan が HIP を上回った。プロンプト処理 (pp512) では Vulkan が 799 t/s、HIP が 736 t/s となり、トークン生成 (tg128) でも Vulkan が 52.1 t/s、HIP が 48.9 t/s と、Vulkan の方が高速であった。第2テストでも Vulkan (1509 t/s / 39.0 t/s) が HIP (1467 t/s / 37.6 t/s) を上回った。これは、ROCm/HIP が AMD GPU で常に最速であるという前提に疑問を投げかける結果である。

この性能差は、gfx1103 (780M) においても Vulkan パスが有効に機能していることを示している。

利用者の報告

780M (RADV, UMA) 環境での報告では、Vulkan バックエンド特有の深刻な性能劣化も確認されている。ystyle 氏は、Arch Linux 環境 (Ryzen 7 7840HS + Radeon 780M) で、Qwen3.5-35B-A3B (UD-Q3_K_XL) とマルチモーダルプロジェクタ (mmproj-F16.gguf) を併用した際、推論速度が約 250 倍低下したと報告している。具体的には、prefill が 0.3 tok/s、decode が 0.1 tok/s となり、プロジェクタをロードしない場合と比較して極端に遅くなった。出力自体は正しく、エラーログも出力されていない。この現象は llama.cpp の公式 Vulkan リリースビルド (b11517) および b10453 で再現している。

  • 環境: Arch Linux, AMD Ryzen 7 7840HS + Radeon 780M (RADV, UMA), 2048 MB VRAM + 24576 MB GTT, 29 GB shared RAM
  • コマンド: 
    llama-server -m Qwen3.5-35B-A3B-UD-Q3_K_XL.gguf \
    --mmproj mmproj-F16.gguf \
    -ngl 99 -c 8192 -np 1
  • 報告: Eval bug: Vulkan + mmproj: ~250x slower generation (投稿者: ystyle)

Vulkanバックエンド: unified KV cache slots PRによる性能回帰と回避策

llama.cpp の Vulkan バックエンドにおいて、unified KV cache slots に関連する PR 導入により、TTFT (First Token Latency) と ITL (Inter-Token Latency) が大幅に悪化する性能回帰が発生している。Mac (Metal) では修正パッチが適用されたが、Vulkan バックエンドには Metal 特有の最適化（完全にマスクされたブロックのスキップ等）が不足しており、gfx1103 環境でも TTFT の悪化が懸念されている。

現在、コマンドラインフラグを用いた回避策が存在するが、根本的な修正は Shader の最適化実装待ちの状態である。この回帰は、AMD Vulkan ユーザーに影響が及ぶ可能性がある。

利用者の報告

前述の ystyle による 780M (RADV, UMA) 環境での報告では、マルチモーダルプロジェクタ使用時の極端な速度低下が確認されており、KV cache の扱いに関連する性能劣化の可能性が示唆されている。また、Windows 11 環境 (AMD Radeon RX 9070 XT) において、Hermes Agent がピン留めしている llama.cpp の Vulkan ビルド (b10964) が、LM Studio 同様の Vulkan ビルドと比較して約 4 倍低速であるという報告もある。Hermes 環境では -ngl 0 (CPU) と -ngl 99 (GPU) でデコード速度に差がなく、GPU オフロードが機能していない可能性がある。

Vulkan RDNA3 narrow MMVQパッチで780Mの推論速度が12.2%向上

780M (gfx1103) 等の RDNA3 アーキテクチャを搭載した AMD iGPU において、narrow MMVQ (Matrix Multiply Vector Quantization) に関連する最適化パッチを試験した結果、推論速度が向上した。Miko997 による実験では、ggemma4-26B-A4B-QAT-Q4_0 モデルを使用し、AMD RDNA3 UMA 環境 (n==1 narrow matrix) でテストを行った。

プロンプト処理 (pp512) は 500 t/s から 502 t/s に、トークン生成 (tg128) は 26.3 t/s から 27.5 t/s (+12.2%) に向上した。tg512 でも 25.2 t/s から 26.2 t/s への改善が確認されている。この最適化は PR 化の可能性があり、RDNA3 ユーザーにとって実用的な高速化手法となり得る。

利用者の報告

780M (RADV, UMA) 環境での報告では、マルチモーダルプロジェクタ使用時の極端な速度低下が確認されている。また、Windows 11 環境 (AMD Radeon RX 9070 XT) において、Hermes Agent がピン留めしている llama.cpp の Vulkan ビルド (b10964) が、LM Studio 同様の Vulkan ビルドと比較して約 4 倍低速であるという報告もある。Hermes 環境では -ngl 0 (CPU) と -ngl 99 (GPU) でデコード速度に差がなく、GPU オフロードが機能していない可能性がある。

Ollama: gfx1103検出拒否とVulkanデバイスイヌメレーション不具合

Ollama において、gfx1103 (780M) の検出拒否問題が継続している (Issue #12071)。GPU バックエンドが gfx1103 を拒否するため、Vulkan 経由でのワークアラウンドが必要となっている。また、Vulkan デバイスイヌメレーションに関する別の不具合 (Issue #14562) により、UMA 搭載の AMD iGPU が認識されない現象も報告されている。これにより、Ollama を利用する 780M ユーザーは、バックエンド選択や環境設定に注意を要する。

利用者の報告

780M (RADV, UMA) 環境での報告では、マルチモーダルプロジェクタ使用時の極端な速度低下が確認されている。また、Windows 11 環境 (AMD Radeon RX 9070 XT) において、Hermes Agent がピン留めしている llama.cpp の Vulkan ビルド (b10964) が、LM Studio 同様の Vulkan ビルドと比較して約 4 倍低速であるという報告もある。Hermes 環境では -ngl 0 (CPU) と -ngl 99 (GPU) でデコード速度に差がなく、GPU オフロードが機能していない可能性がある。

780M実測ベンチ: Gemma 4 12B (20.9 t/s) と GPT-OSS 20B (UMA活用)

32GB RAM を搭載した AMD Ryzen mini PC (Radeon 760M/780M, RADV PHOENIX, gfx1103, UMA) 環境での実測ベンチマークが報告された。Gemma 4 12B (Q4_K_M, 15.85GB) は tg128 で 20.94 t/s を記録し、Llama 8B (Q8_0) は 9.80 t/s であった。Vulkan は CPU よりも大幅に高速であり、特にプロンプト処理 (pp512) では Gemma 4 で 239.04 t/s を記録した。モデルサイズは 32GB UMA に収まり、会話レベルの速度 (~21 tok/s) が実現可能である。

また、GPT-OSS 20B を 780M (gfx1103) で実行する実証では、32GB RAM 環境においてシステムメモリの約半分 (2GB VRAM + ~15GB GTT) を活用して推論が行われた。llama.cpp の Vulkan バックエンドは、Ollama よりも柔軟に GPU を活用できる。Vulkan + Mesa の組み合わせは、AMD iGPU での llama.cpp 推論において ROCm よりも簡易であるとの報告がある。

利用者の報告

780M (RADV, UMA) 環境での報告では、マルチモーダルプロジェクタ使用時の極端な速度低下が確認されている。また、Windows 11 環境 (AMD Radeon RX 9070 XT) において、Hermes Agent がピン留めしている llama.cpp の Vulkan ビルド (b10964) が、LM Studio 同様の Vulkan ビルドと比較して約 4 倍低速であるという報告もある。Hermes 環境では -ngl 0 (CPU) と -ngl 99 (GPU) でデコード速度に差がなく、GPU オフロードが機能していない可能性がある。

出典

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

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