山村商店

【780M向け】llama.cpp Vulkan更新：RDNA2のFlash Attention速度改善と780M向け最適化

ローカルLLMAMDVulkaniGPULLM最適化

目次
  1. 今回の要点
  2. Vulkan RDNA2 Flash Attentionの重大なボトルネック解消とWave32有効化
  3. Vulkan RMS Normの共有メモリ最適化でiGPU帯域幅ボトルネックを緩和
  4. Vulkan Adreno互換コンパイル不具合修正とRADVへの波及
  5. VulkanバックエンドでYaRN切り捨て設定をサポートし長文コンテキスト対応
  6. Vulkan環境でのGPUデバイス順序が推論性能に影響する不具合
  7. 出典

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

今回の要点

  • RDNA2 (RX 6600 XT等) の Flash Attention が大幅に高速化：共有メモリの制限チェックを回避し、Wave32 実行を有効化。
  • Radeon 780M 等の帯域幅制限 GPU で推論速度が向上：RMS Norm の処理を共有メモリ経由に変更し、メモリトラフィックを削減。
  • 長文コンテキスト (YaRN) が Vulkan で利用可能に：切り捨て設定 (truncation config) のサポートが追加され、コンテキスト長の有効活用が可能に。
  • マルチGPU構成時の注意：GPU の接続順序や優先度設定が、プロンプト処理速度 (PP) に深刻な影響を与える不具合が報告されている。

Vulkan RDNA2 Flash Attentionの重大なボトルネック解消とWave32有効化

前提

Flash Attention は、Attention 機構の計算効率を高める手法だが、GPU の共有メモリ (shmem) やレジスタ使用量に厳しい制約がある。特に AMD RDNA2 アーキテクチャでは、ドライバーの仕様チェックが最適化を阻害し、速度低下を招く場合があった。

何が変わったか

llama.cpp において、RDNA2 デバイスにおける Flash Attention のボトルネックを解消する修正が行われた。具体的には、共有メモリのサイズ制限チェックを回避し、ネイティブな Wave32 サブグループ実行を有効化する変更が適用された。これにより、レジスタ圧力の軽減とメモリスパイリングの削減が図られている。

なぜ重要か

RX 6600 XT などの RDNA2 アーキテクチャを搭載する AMD GPU ユーザーにとって、特にシーケンスコンテキストが長い場合 (n ≥ 4500 など) に顕著だった速度低下が解消される。これにより、iGPU でもより長いコンテキストを扱えるようになる。

根拠のリンク

利用者の報告

logankidd315-design 氏は、Windows 環境上の RX 6600 XT (RDNA2) で、Vulkan バックエンド使用時に Yue2 3b などのモデルで大きなコンテキスト処理時の深刻なパフォーマンス低下を報告し、本修正がその原因である特定と解決策を提示した。同氏は、厳格なドライバープロパティチェックの失敗によるキャッシュスラッシングと、大規模コンテキストでのレジスタ圧力による VGPR メモリスパイリングが主要因だと指摘している。

Vulkan RMS Normの共有メモリ最適化でiGPU帯域幅ボトルネックを緩和

前提

RMS Norm (Root Mean Square Layer Normalization) は LLM における正規化処理の一つ。通常、グローバルメモリ (VRAM) とのアクセスが発生するが、共有メモリ (高速だが容量が限られる) を経由することで処理効率を上げられる。

何が変わったか

RMS Norm の部分和計算 (partial sums) を、グローバルメモリではなく共有メモリを通じて行う最適化が Vulkan バックエンドに導入された。これにより、GPU 間のメモリトラフィックが削減される。

なぜ重要か

Radeon 780M などの iGPU は、独立型 GPU に比べてメモリ帯域幅が制限されている。この最適化により、帯域幅がボトルネックになりやすい環境でも、推論速度の向上が期待できる。

根拠のリンク

Vulkan Adreno互換コンパイル不具合修正とRADVへの波及

前提

llama.cpp の Vulkan バックエンドは、Qualcomm Adreno GPU 向けのコンパイル最適化を含んでいる。一部の Adreno GPU では、特定のビット幅のベクターパック/アンパック処理でコンパイル不具合 (miscompile) が発生していた。

何が変わったか

Adreno GPU でのコンパイル不具合を回避するため、大規模なヘッドを持つ場合のスカラー Flash Attention の行数制限 (8行まで) や、8-bit ベクターパック/アンパック処理の回避といった修正が行われた。

なぜ重要か

本来は Adreno 向けの修正だが、同様のコンパイラの問題が AMD の RADV ドライバー環境でも発生する可能性がある。この修正により、RADV 環境における安定性や互換性も間接的に改善する可能性がある。

根拠のリンク

VulkanバックエンドでYaRN切り捨て設定をサポートし長文コンテキスト対応

前提

YaRN (Yet another RoPE extensioN) は、LLM のコンテキスト長を拡張する技術。ただし、無限にコンテキストを延ばすと計算コストが増大するため、重要な情報を保持しつつ不要な部分を切り捨てる (truncation) 設定が有用な場合がある。

何が変わったか

Vulkan、OpenVINO、SYCL、WebGPU、RPC などのバックエンドにおいて、YaRN の切り捨て設定 (truncation config) のサポートが追加された。これにより、Vulkan 環境でもコンテキストの切り捨て制御が可能になった。

なぜ重要か

Radeon 780M などの iGPU ユーザーにとって、長文コンテキストを有効活用しつつ、メモリや計算リソースの制約を管理できるようになる。特に、VRAM が限られる環境での長文処理の柔軟性が向上する。

根拠のリンク

Vulkan環境でのGPUデバイス順序が推論性能に影響する不具合

前提

複数の GPU を搭載した PC では、どの GPU を推論に使用するかを指定する必要がある。Vulkan バックエンドでは、システム内の GPU デバイスの順序や優先度設定が、推論パフォーマンスに影響を与える可能性がある。

何が変わったか

GPU デバイスの順序が、プロンプト処理 (PP: Prompt Processing) のパフォーマンスに深刻な影響を与える不具合が報告されている。特に、メインの GPU 以外をディスプレイ出力用に設定した場合など、意図しない順序でデバイスが選択されると速度が大幅に低下する。

なぜ重要か

マルチ GPU 構成や、統合 GPU と独立 GPU を併用する環境において、意図した GPU が正しく選択されないまま推論が実行されると、パフォーマンスが著しく低下する可能性がある。ユーザーは、デバイス順序や指定方法に注意する必要がある。

根拠のリンク

利用者の報告

AlexGidarakos 氏は、Debian 13 環境で、メインの GPU 以外をプライマリディスプレイアダプタとして設定したところ、Vulkan を使用した Qwen MoE モデルの推論速度が深刻な低下を示したと報告している。この現象は、最新のビルド (b11738) および旧ビルド (v0.2.0) の両方で再現しており、明示的に強い GPU を指定しても、デバイス順序の影響でパフォーマンスが損なわれる可能性がある。

出典

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

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