山村商店

【780M向け】llama.cpp Vulkanバックエンドの重大な性能劣化と780M環境での必須設定

ローカルLLMAMDVulkaniGPULLM最適化

目次
  1. 今回の要点
  2. Vulkan draft-MTP推論の大幅性能劣化とMellum2/Vulkan崩壊
  3. 780M必須設定：mmap回避とMoE/Vulkanクラッシュ対策
  4. Vulkan Q4_0高速化とQwenモデル用Tiled-Transpose最適化
  5. 780M実測ベンチ：Qwen3.6 35B 19.7t/s、Gemma 4 26B 25t/s
  6. Vulkanデバッグラベル追加とGPUメモリ関連バグ修正
  7. 出典

今回の要点

  • Vulkan draft-MTP推論の大幅性能劣化: 最新のVulkanバックエンド変更により、推論速度が最大6倍低下する回帰（regression）が報告されている。
  • 780M環境での必須ワークアラウンド: AMD Radeon 780M (gfx1103) ユーザーは、ROCmの代わりにVulkan (RADV PHOENIX) を使用し、VRAM認識を回避する設定が推奨される。
  • MoE推論時のクラッシュ対策: MoE（Mixture of Experts）モデルのVulkan推論では、キャッシュ設定の調整が必要であり、未調整だとロード時にクラッシュする。
  • Qwenモデルの最適化: Qwen系モデル利用時のVulkan推論速度を改善する高速化パッチが進行中。

Vulkan draft-MTP推論の大幅性能劣化とMellum2/Vulkan崩壊

今回の話題を理解するには、llama.cppにおける「draft-MTP（Multi-Token Prediction）」という推論モードの仕組みを知る必要がある。これは、モデルが生成した複数の候補トークンを一度に検証することで推論速度を向上させる技術であり、AMD iGPUユーザーにとって高速化の要となる機能だ。

しかし、最近のVulkanバックエンド変更により、このdraft-MTP推論において深刻な性能劣化が発生している。具体的には、デコード処理が約4倍、プリフィル処理が約6倍も遅くなったという報告が上がっている。これは、ターゲット計算バッファがGTT（Graphics Translation Table）に再割り当てされたことが原因とみられている。

この問題は、Vulkanを使用するすべてのAMDユーザーに影響する。特に、複数のGPUデバイスがシステムに存在する環境や、大きなコンテキストサイズ（例: 196608）を指定して推論を行う場合、スループットがメモリの帯域幅レベルまで低下する。ただし、コンテキストサイズを小さく（例: 8192）設定すれば、この劣化は発生しないという特性も確認されている。

この問題の根拠は、以下のGitHub Issueで報告されている。

利用者の報告

この性能劣化は、複数の環境で再現・検証されている。

  • snick525 による報告: AMD Radeon AI PRO R9700 (RDNA4) 2枚構成、Linux 7.2.5、Mesa RADV 26.2.2の環境で、v0.7.0のVulkanバックエンド使用時にdraft-MTP推論が大幅に遅くなったと報告。Issue #30688
  • cennac による報告: 複数のVulkanデバイスが_visible_ なシステムで、大きなコンテキスト（-c 196608）と推論デコード（ngram-map + draft-mtp）を使用すると、スループットが約3倍低下すると報告。_GGML_VK_VISIBLE_DEVICES_ で計算用GPUのみを指定することで回復を確認。Issue #30695
  • tczank による報告: AMD RX 7900 XTX (RDNA3) 環境で、masterブランチと9月26日のビルドを比較し、draft-MTPパスが約10〜13%遅くなったと報告。キャッシュ再利用（_--cache-reuse_）を有効にすると、さらに受容率の不安定さも確認。Issue #30638

780M必須設定：mmap回避とMoE/Vulkanクラッシュ対策

AMD Ryzen 内蔵GPU（Radeon 780M / gfx1103）を使用する場合、ROCmバックエンドは正式サポート外であり、クラッシュやパフォーマンス問題を引き起こしやすい。そのため、Vulkanバックエンド（Mesa RADV PHOENIX）への切り替えが推奨される。これにより、VRAM認識の問題を回避し、より安定した動作が期待できる。

また、MoE（Mixture of Experts）モデルをVulkanで推論する場合、_--moe-cache-mib_ などのキャッシュ設定を誤ると、モデルロード時にクラッシュする可能性がある。これは、キャッシュスロットのサイズ計算がバックエンドの制限を超えてしまい、GPUメモリ割り当てに失敗することが原因とみられている。

この問題は、以下のGitHub Issueで報告されている。

利用者の報告

MoE推論時のクラッシュは、以下の環境で報告されている。

  • TheColetrain による報告: Windows 11、AMD Radeon RX 6900 XT (gfx1030)、公式Windows x64 Vulkanリリースzip使用。_--moe-cache-mib 8000_ を指定してQwen3.6-35B-A3Bモデルをロードしようとすると、_pre-allocated tensor_ に関するエラーでクラッシュ。Issue #30697
  • qiyuhuating による報告: 上記クラッシュの原因として、MoEキャッシュスロットのサイズ計算がバックエンドの制限を超えている可能性を指摘。キャッシュ容量を保守的に減らすことで解決する可能性がある。Issue #30697 Comment

Vulkan Q4_0高速化とQwenモデル用Tiled-Transpose最適化

Qwen系モデル（Qwen 3.5/4など）をVulkanで推論する場合、Tiled-Transpose Concatシェーダーの最適化により、推論速度が改善される可能性がある。また、Q4_0量子化KVキャッシュに対する高速なデクアンタイズ・トランスポーズパスも追加されており、特に古いGPU（GCN1など）でのパフォーマンス向上が期待できる。

これらの改善は、以下のGitHub Pull Requestで進行中。

780M実測ベンチ：Qwen3.6 35B 19.7t/s、Gemma 4 26B 25t/s

2026年10月15日時点での780M（Vulkanバックエンド）の実測ベンチマークによると、Qwen3.6 35B A3B（Q8_0）で約19.7 t/s、Gemma 4 26B-A4B（Q4_K_M）で約25 t/sの生成速度が記録されている。また、MoEモデルをCPUで推論する場合、DenseモデルをGPUで推論するよりも高速になる場合があるため、環境に応じた最適な設定が求められる。

詳細なベンチマークデータは、以下のサイトで確認できる。

Vulkanデバッグラベル追加とGPUメモリ関連バグ修正

Vulkanバックエンドのプロファイリング環境が改善されている。コマンドバッファにデバッグラベルが追加され、GPUプロファイリングツールでの解析が容易になった。また、整数Dot Productのバグ修正や、スクラッチバッファシステムの導入により、デクアンタイズ処理の速度向上が期待できる。

関連するPull Requestは以下の通り。

出典

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

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