vLLMコミュニティがRDNA向けのタイリング調整を提案、W7900の埋め込み処理スループットが実測で約17～19%向上

vLLMコミュニティは9月22日、AMD RDNA GPU向けのアテンションカーネルの調整案を提示した。1回に処理するキーバリューブロックを小さくすることで、Radeon Pro W7900を使った埋め込みサービスのテストでは、スループットが約17～19%向上した。現在公開されているのは性能改善の提案であり、正式リリースで提供済みの高速化とみなすことはできない。[コミュニティのテスト](https://github.com/vllm-project/vllm/issues/58060)

技術的な着眼点は、行列のタイリング方法にある。vLLM 0.28.0の公開コードでは、クエリ方向とキーバリュー方向で同じブロックサイズを使い、スレッドグループ数はアテンションヘッドの次元数に応じて決めている。提案では、キーバリュー方向のブロックサイズだけを32に縮小し、ほかの起動パラメータは維持する。これにより調整対象を単一のカーネルに絞れるが、ブロックの縮小によって共有メモリへの負荷が軽減されるかどうかについては、ハードウェアのプロファイリングによる裏付けがまだ不足している。[カーネルのコード](https://docs.vllm.ai/en/v0.28.0/api/vllm/v1/attention/ops/triton_prefill_attention/)、[提案の説明](https://github.com/vllm-project/vllm/issues/58060)

テストはGPU1枚、BF16、定格クロックで実施された。W7900とR9700のカーネル高速化倍率の中央値は、それぞれ約2.6倍、約2.3倍だった。一方、後者のサービス全体のスループット向上は約3～5%にとどまり、カーネルの速度向上をそのままリクエスト処理性能に換算できないことが示された。提案者も、適用範囲を埋め込みとリランキングで使用するアテンションの処理経路に明確に限定しており、テキスト生成は対象に含めていない。[テスト条件と結果](https://github.com/vllm-project/vllm/issues/58060)

再現にあたっては、モデルの設定も重要になる。サービスのテストに使われたGTE-Qwen2-1.5Bは非因果アテンションを使う設定になっており、この提案の用途に合致する。モデル名にQwenが含まれていても、一般的な自己回帰デコードの処理経路を使うとは限らない。エンジニアは実際に読み込まれた設定とバックエンドを確認したうえで、性能を比較すべきだ。出力をベクトルに変更しただけでは、同じ処理経路で計算されていることの証明にはならない。[モデル設定](https://huggingface.co/Alibaba-NLP/gte-Qwen2-1.5B-instruct/blob/main/config.json)

vLLMのドキュメントでは、埋め込みや分類などのタスクをpoolingモデルに分類しており、対応するインターフェースを通じてベクトルやスコアを取得できる。また、これらのサポートがTransformersを直接使う場合より高速であることを保証するものではないとも注意を促している。そのため、RAGシステムでこの調整を評価する際には、アテンションカーネルだけを見るのではなく、検索処理全体のレイテンシーも比較する必要がある。[公式ドキュメント](https://docs.vllm.ai/en/latest/models/pooling_models/)

現時点のエンドツーエンドのデータは、各アーキテクチャにつきGPU1枚から得られたものに限られる。半精度のFP16、複数GPU、ほかのRDNAモデルは未検証であり、検索指標にも小幅な変動がある。[既知の制約](https://github.com/vllm-project/vllm/issues/58060) 今後注目すべきなのは、上流へのパッチ、独立した再検証、繁体字中国語コーパスでのランキングの一貫性だ。特に、短いクエリ、長い文書、多数の同時リクエストではボトルネックが異なる可能性があり、平均スループットに加えて、テールレイテンシーや失敗したリクエストの記録も残すべきだ。こうした検証を通じて初めて、推論時間の短縮がカスタムカーネルの保守コストに見合うかどうかを判断できる。