Ryzen AI Max+ 395でGemma 4 26Bを動かして分かった、VulkanとROCmの使い分けと落とし穴

きっかけ

Ryzen AI Max+ 395（Radeon 8060S / 40CU）環境に、MoEモデルである「Gemma 4 26B A4B QAT」を導入し、llama.cppでローカル推論のベンチマーク測定を行いました。

普段は何気なく「とりあえず最新ビルドでFlash AttentionをONにすれば最速だろう」と考えがちですが、実際にVulkanとROCm（Lemonadeビルド等）を横並びで比較し、パラメータやコンテキスト長（深さ）を変えて測定してみたところ、直感とは大きく異なる挙動がいくつも見つかりました。

学んだこと

今回のベンチマークから得られた技術的な要点は以下の通りです。

• Vulkanは生成速度（tg）が優秀: 最新ビルド（b11227）のVulkanは生成速度 78.4 t/s を記録。理論帯域（256 GB/s）に対する実効帯域到達率は約67%（約172 GB/s）と、非常に高い効率を出せる。
• VulkanのFlash Attention（FA）はコンテキストが深くなると急減速する: 浅い位置（d0）では爆速（pp512: 1941 t/s）ですが、d32768まで深くなると 126 t/s まで落ち込みます。長文入力ではむしろ fa=off にしたほうが5倍速い（642 t/s）という逆転現象が起きます。
• ROCmは深いコンテキストでの安定感がある: Lemonade版ROCm（b1318）は、32kの深さでも fa=1 でプロンプト処理 701 t/s、生成 50.6 t/s を維持し、長文でのバランスが優れています。
• ROCm特有の地雷設定:
  • mmap=1 にすると生成速度が 25〜30% も低下するため、ROCm環境では mmap=off が必須。
  • KVキャッシュの量子化でKとVの型を不揃い（例: K=f16, V=q8_0）にすると、処理がCPUフォールバックを起こして激重になる。
  • 最新開発版（b1333 / ROCm 10.2系）が必ずしも安定・高速とは限らず、安定版（b1318）の方が優れていた。

自分なりの理解

LLMのローカル実行におけるボトルネックは「プロンプト処理」と「トークン生成」で完全に分離していますが、バックエンドの実装成熟度やアテンション機構（FA）の実装依存によって、コンテキスト長に応じた挙動が全く別物になるという点が非常に興味深かったです。

• 短い対話（〜8kコンテキスト）: Vulkan + fa=on が最適解。プロンプト処理も生成もトップスピードで動作し、最も体感が良い。
• ドキュメント要約などの長文入力（〜32k）: Vulkanを使うならあえて fa=off にするのが正解。FAをONにしたままだと入力処理だけで1分半以上待たされる計算になりますが、OFFなら約30秒で抜けます。
• 長い会話履歴を維持した継続対話: プロンプト処理・生成ともに深さへの耐性が高い ROCm（b1318） + fa=on + mmap=off が総合力で勝る。

「Flash Attention＝常にONにすべき高速化オプション」と思い込んでいましたが、Vulkan実装においては長いシーケンス長に対するタイリングやキャッシュ効率に課題があることが数字としてはっきり見えました。

実践へのつなげ方

用途に合わせて、LM Studioや llama-server の起動オプションを明確に切り替えて運用します。

1. 日常のコーディング支援・チャット（短〜中文）:
   • ランタイム: Vulkan
   • 設定: -fa on -ctk f16 -ctv f16 -b 2048 -ub 1024
   • 手元のAPIサーバー（ポート8081）の標準構成として常駐させる。
2. 長文資料を流し込んでの分析・要約:
   • ランタイム: Vulkan
   • 設定: -fa off -b 2048 -ub 512（FAを意図的に切る）
3. 長大な文脈を持つエージェントタスク:
   • ランタイム: ROCm (lemonade-b1318)
   • 設定: -fa on -ctk f16 -ctv f16 -lm none（mmapを必ずオフにする）

次に試すこと

「Q4_0版のQATモデル」の検証を行います。 今回の UD-Q4_K_XL から、計算カーネルの最適化が最も進んでいる素の Q4_0 に変更することで、演算主導のプロンプト処理および帯域主導の生成速度がどこまで理論上限（117 t/s）に迫れるかを確かめてみます。