 | Threadripper Pro 上に 4 x R9700 のシステムがありますが、vLLM での GPU パフォーマンスにはこれまでずっと満足できていませんでした。そこで、試した新しいモデルはどれでも llama-benchy でベンチマークするようにして、さまざまなサイズやアーキテクチャのモデルが自分の環境でどう比較されるかをより正確に把握できるようにしました。私がテストしたすべてのモデルで、コンテキストが 64k トークンあたりで壁にぶつかりました。TTFT、TG、PP のどれも、長いコンテキスト長ではうまくいかず（すぐに破綻して）しまいます。 そこで先週末、AMD なら CDNA 上でこの問題は解決済みだろうと思い、RunPod から MI300X をレンタルしてみました。Qwen3.6-27B-FP8 で vLLM を起動しているとき、vLLM が AITER の attention バックエンドの代わりに ROCm Attention を選んでいるのに気づき、これは変だと思ったのですが、そのままベンチマーク実行を続けました。llama-benchy を 1 回回した後、MI300X でも長いコンテキスト長で私の R9700 と同じ問題が起きていることが分かりました。>64k のコンテキストでは TG/s が 1 桁台まで落ちます。そこで、MI300X で vLLM を動かす AMD の runbook を探したところ、AITer の attention メカニズムは、明示的に有効化する必要がある env var の背後にゲートされていることが分かりました。この新しい情報を得て、vLLM にパッチを当てて AITER と gfx1201 をサポートする再挑戦に戻りました。 私はすでに、R9700 向けに FP8 対応を入れたパッチ済みの vLLM を持っています。これは AITER の Triton カーネルの上に構築したものです。最初に AITER サポートを組み込むときにいくつか問題があったため、FP8 を動かすために Triton カーネル以外はすべて無効化しました。AITER と vLLM へのパッチの多くは、gfx1201 をブロックしているゲートを取り除くこと、または gfx1201 をどこか MI350X（私の理解では MI350X と RDNA4 は FP8 を同じ、もしくは非常に似た方法で実装しているため、RDNA4 でも MI350X の一部カーネルが使える）として扱うように追加すること、のどちらかです。私のテストはすべて Qwen3.6 27B まわりで行いました。このモデルが、ようやく自宅環境で SOTA にかなり近い性能を出してくれるからです。Qwen3.6 はハイブリッド アーキテクチャなので、期待される TILE_SIZE の不一致により AITER Unified Attention がクラッシュし続けました。AITer は kv ブロックサイズが 2 のべき乗であることしかサポートしない、というような事情があるようです。 これまで見つけた主なデメリット（と呼べるかどうかはさておき）は、FP16/BF16 の KV キャッシュしか動かせないことです。Qwen3.6 ファミリーではキャッシュのフットプリントがすでにとても小さいので、キャッシュを量子化する必要がないとはいえ、試してみるときには覚えておくべき点です。 私は、レンタルした私の R9700 と MI300X に対する Qwen3.6 のベンチマーク結果の一部を添付しました。AITER Attention でテストするために、runpod から MI300X を再度レンタルしようとしましたが、ここ数日で空きがなかったためできませんでした。pre-aiter のベンチマークがないことについてすみません。調査・トラブルシューティングの途中で、そのベンチマークを上書きしてしまったようです。Qwen3.6 35B の元々のベンチマークも添付します。さらに、MTP を有効化し、トークン数を 3 に設定したベンチマークも添付しました。私が確認できた範囲では、単一の並行実行（single concurrency）では実質的に無料の性能（つまりオーバーヘッドがほとんどない）です。並行実行数 2 で高いコンテキスト長になると、TG の性能は高いコンテキスト深度でかなりはっきりと低下します。llama-benchy の実行では、各コンテキスト深度に対して TG128 と PP2048 を使っています。 [link] [comments] |
複数のR9700でvLLMを動かしている人は、AITER Unified Attention対応のパッチが必要
Reddit r/LocalLLaMA / 2026/4/28
💬 オピニオンDeveloper Stack & InfrastructureSignals & Early TrendsTools & Practical Usage
要点
- 著者は、Threadripper Pro上のRadeon R9700（4-GPU）環境と、AMDのMI300X環境のいずれでも、長いコンテキストでvLLMの性能が伸びず、約64kトークンを超えるとスループットが大きく低下すると報告しています。
- 彼らは、vLLM/ROCm上でAITERのattentionバックエンドが環境変数によるゲートの裏に隠れており、明示的に有効化・パッチ適用しないと長コンテキストで詰まることを見つけました。
- gfx1201向けにAITER Unified Attentionの対応をvLLM側でパッチしたところ、Qwen3.6-27B-FP8のテストでは長コンテキスト挙動が改善したとしていますが、対応アーキテクチャの統合が重要だと述べています。
- 重要な制約として、現状はFP16/BF16のKVキャッシュのみ対応で（FP8 KVキャッシュは不可）、またQwen3.6のハイブリッド構成ではTILE_SIZEやKVブロックサイズの期待値不一致によりUnified Attentionがクラッシュすることがある、と注意しています。
- 全体として、この投稿は複数のAMD GPUでvLLMを運用する限られたユーザーを想定しており、gfx1201のゲート解除やMI350X/RDNA4で近いカーネルを流用するための具体的な修正方針を示しています。
