【780M向け】Radeon 780MのVulkan推論を安定・高速化するメモリ整合性修正とRDNA3最適化
目次
この記事はAIによって編集・作成されています。
llama.cpp は ggml-org が開発する C/C++ の LLM 推論エンジン。Vulkan バックエンドで AMD iGPU でも動く。
今回の要点
- Radeon 780M (gfx1103) 等の UMA 環境で必須のメモリ整合性修正が複数マージされた (PR #30438, #30468, #30487)
- gpu-visible host memory への複数デバイス同時アクセスが可能になり、データ破損が解消された
- RDNA3/RDNA4 向けに小規模 GEMM の split-K 選択が最適化され、推論速度が向上した (PR #30146)
- Linux 環境で llama-server がスタックオーバーフローしてクラッシュする不具合が修正された (PR #30243)
- Intel Arc B580 向けに bf16 活性化と Xe2 対応が拡充されたが、Xe2 では coopmat FA のスカラフォールバックが報告されている
Vulkan UMA環境のメモリ破損・バリア不具合修正とgpu-visible host memory改善
Unified Memory Architecture (UMA) では GPU と CPU が同じ物理メモリを共有するため、GPU からの書き込み結果を CPU が読み取る際に、メモリバリアを明示的に指定しないとデータが壊れる、あるいは読み取りタイミングが競合する問題が発生しやすい。今回の修正群は、この UMA 環境におけるメモリ整合性を根本的に改善するものである。
具体的には、gpu-visible host memory への複数デバイスからのアクセスを許可する修正 (PR #30468) と、GPU 書き込みからホスト書き込みへのメモリバリアを追加する修正 (PR #30438) が行われた。これにより、gfx1103 (Radeon 780M) 環境での一時的メモリ割り当て失敗対策 (PR #30487) や、FA dequant パスにおける結合 K+V f16 scratch サイズのチェックによるメモリオーバーフロー対策も同時に適用された。これらの修正は、AMD UMA iGPU ユーザーにとってデータ破損を防ぐための必須レベルの改善である。
- vulkan: fix scratch size in Vulkan (PR #30487)
- vulkan: allow multiple devices to access gpu-visible host memory (#29741)
- vulkan: Add missing memory barrier for GPU write -> host write on UMA (PR #30438)
- vulkan: fix gpu-visible host memory issues (#30468)
利用者の報告
ystyle は、Arch Linux 上の Radeon 780M (RADV, UMA) 環境で、Qwen3.5-35B-A3B の UD-Q3_K_XL 量子化モデルにプロジェクトタ (mmproj) を読み込ませた際、生成速度が約 250 倍低下する現象を報告している。環境は 2048 MB VRAM + 24576 MB GTT、29 GB 共有 RAM であり、コマンドは以下の通り。
llama-server -m Qwen3.5-35B-A3B-UD-Q3_K_XL.gguf \
--mmproj mmproj-F16.gguf \
-ngl 99 -c 8192 -np 1
この環境では、出力自体は正しく、ログにエラーも出ないものの、prefill が約 0.3 tok/s、decode が約 0.1 tok/s という極端な低速化が発生していた。一方、同じプロジェクトタでも IQ3_XXS 量子化モデルでは同様の現象は確認されていない。この報告は、今回のメモリ整合性修正が適用される前の環境 (b11517, b10453) における問題であり、修正後の動作が期待される。
Vulkan SWA推論の速度倍増バグとtop_k関連クラッシュ対策
llama.cpp のサーバー機能において、Linux 環境で特定のモデル (d1-omni, kev) を扱う際、std::regex_replace を使用した特殊トークンのエスケープ処理が原因でスタックオーバーフローが発生し、サーバーがクラッシュする不具合が報告された。これは、libstdc++ の正規表現エンジンが再帰的な呼び出しを行うため、長い文字列に対して HTTP スレッドの 8 MB スタックが溢れることが原因である。macOS (libc++) では影響を受けない。
この問題は、正規表現の代わりにループ処理を行う server_decision_escape_special_tokens() 関数に置き換えることで修正された (PR #30243)。これにより、長いプロンプトや状態文字列を含むリクエストでも、サーバーが安定して動作するようになった。また、Vulkan 環境における SWA (Sliding Window Attention) 推論関連の速度低下や、n_ubatch 512 指定時の GPU リングハング (Issue #28807, #28808) も、この期間に報告・調査の対象となった。
- llama.cpp #30243 server : escape the special tokens without std::regex
- [Issue] Eval bug: Vulkan CONCAT (SSM conv input) hangs the GPU ring on gfx1010 / Navi 10
- [Issue] Eval bug: Vulkan n_ubatch 512 hangs the GPU ring on gfx1010 / Navi 10 (384 is fine)
利用者の報告
ykhrustalev による修正 PR では、Linux 環境で d1-omni モデルを扱う際に state フィールドに 30,000 文字の文字列を含む JSON を送信すると、llama-server がクラッシュすることが再現手順と共に報告されている。修正後は、正規表現を使わないループ処理に置き換えられ、同様のリクエストでも正常に処理される。
RDNA3/4向け小規模GEMMのsplit-K選択最適化で推論速度向上
RDNA3 (Radeon 780M) および RDNA4 アーキテクチャ向けに、小規模な行列積 (GEMM) 演算における split-K の選択アルゴリズムが最適化された (PR #30146)。従来、ヒューリスティックが正しく機能せず、split-K を適用しない、またはグリッド長が短すぎる設定になっていたが、Wave-aware な選択に改めることで、より効率的な並列処理が可能になった。これにより、780M 環境での推論速度に直結する改善が期待される。
また、プーリングウィンドウが大きい場合の pool_2d 演算の最適化 (commit 77c4540) も行われており、画像処理やマルチモーダルモデルの推論においてパフォーマンス向上が図られている。
- vulkan: improve small-n split-K selection on RDNA3/RDNA4 (PR #30146)
- vulkan: Optimize pool_2d when the pooling window is large (#30119)
利用者の報告
この最適化に関連する具体的なベンチマーク結果の報告は、今回の IR には含まれていない。しかし、polter-dev は、Strix Halo 8060S (gfx1151) 環境で llama.cpp の Vulkan ビルドを用いて gpt-oss-20b をサーブする際、ROCm 対応が不十分なため llama.cpp モードの追加を提案しており、RDNA3/4 環境における llama.cpp の重要性が高まっていることを示している。
Vulkanでbf16活性化サポートとIntel Arc Pro B65/B70対応
Vulkan バックエンドにおいて、bf16 活性化 (mul_mat activations) のサポートが追加された (PR #29069)。これにより、bf16 形式の活性化関数を用いるモデルの推論が、より効率的に実行可能になる。また、Intel Arc Pro B65 および B70 シリーズ向けのシェーダー数定義 (PR #30431) が行われ、これらの新アーキテクチャへの対応が拡充された。
さらに、f16 蓄積のための FMA パッキング (commit 0f701c8) や、CM2 量子化ブロックサイズにおけるスイッチ処理の回避 (commit 08ffba2) などの低レベル最適化も実施されている。32 ビットプラットフォームにおけるバッファログの修正 (commit b2f036c) も行われており、環境依存の不具合が解消された。
- llama.cpp #29069 vulkan: support mulmat bf16 activations
- [PR] vulkan: Define the shader count for Intel Arc Pro B65
Intel Xe2(B580)でcoopmat FAがスカラFallbackする問題
Intel Arc B580 (Xe2) 環境において、coopmat Flash Attention (FA) がスカラ演算に静かにフォールバックする問題が報告された (Issue #30503)。ドライバーが 8x16x16 の coopmat 形式のみを公開しているのに対し、llama.cpp は 16x16x16 を要求するため、cm1 シェーダーが選択されず、性能が低下する。gemma-4-E4B Q4_0 モデルでのベンチマークでは、修正前の stock master で 896 t/s に対し、修正版 (8x16x16 を許可) では 2731 t/s と約 3 倍の速度向上が確認されている。
また、Intel Arc B580 環境で #30145 (rms_norm workgroup count overflow 修正) が含まれるビルドでは、prefill 速度が約 3% 低下する現象も報告されている (Issue #30381)。
- llama.cpp #30503 vulkan: coopmat FA silently falls back to scalar on Intel Xe2 (driver advertises only 8x16x16)
- llama.cpp #30381 vulkan: #30145 (rms_norm wg-count fix) costs ~3% pp512 on Intel Arc B580
利用者の報告
dosermen は、Intel Arc B580 (ドライバー 32.0.101.9033) 環境で、coopmat FA がスカラフォールバックすることで推論速度が大幅に低下することを報告している。修正案として、shape_ok が 16x16x16 または 8x16x16 のいずれかを許可し、パイプライン作成時に失敗した場合は警告を出力してフォールバックするランタイムプローブを行うことが提案されている。
出典
- https://github.com/ggml-org/llama.cpp/pull/30487
- https://github.com/ggml-org/llama.cpp/commit/e0bcaccbe50a773c8addec49bbfc8b7ba953c63b
- https://github.com/ggml-org/llama.cpp/pull/30438
- https://github.com/ggml-org/llama.cpp/pull/30468
- https://github.com/ggml-org/llama.cpp/pull/30243
- https://github.com/ggml-org/llama.cpp/issues/28807
- https://github.com/ggml-org/llama.cpp/issues/28808
- https://github.com/ggml-org/llama.cpp/pull/30146
- https://github.com/ggml-org/llama.cpp/commit/77c4540ce4667f4577753fe034a3a8042f510b8f
- https://github.com/ggml-org/llama.cpp/pull/29069
- https://github.com/ggml-org/llama.cpp/pull/30431
- https://github.com/ggml-org/llama.cpp/issues/30503
- https://github.com/ggml-org/llama.cpp/issues/30381
- https://github.com/ggml-org/llama.cpp/issues/30230
- https://github.com/BillyMRX1/hearthwork/issues/2
- https://github.com/polter-dev/societysim/issues/253
SwitchBot公式ページ
クーポン「AF-4903」で5%引き(アフィリエイトクーポンになりますのでご協力お願いします)
割引の詳しい仕組みに関してはこちらのページを参照ください。