vLLM × HPC-Ops: 高性能 Attention と MoE バックエンド、Tencent Hunyuan から
vLLM × HPC-Ops: 高性能 Attention と MoE バックエンド、Tencent Hunyuan から
これが重要な理由
本番の LLM サービスは現在、動的で混合長のバッチおよびますます大きくなる MoE モデルを処理しているため、レイテンシーは raw matmul スループットよりも、カーネルがどれだけよく作業をスケジュールしデータを移動するかによって左右されます。HPC‑Ops は負荷分散された Attention と完全に融合された FP8 MoE カーネルを提供し、アイドル SM サイクルを削減し、ステージごとのオーバーヘッドをなくすことで、これらの実際のボトルネックに直接対処します。
HPC-Ops: 本番オペレーターライブラリ、現在は vLLM に組み込まれた
HPC-Ops は Tencent Hunyuan AI Infra チームによって構築されたオープンソースのオペレーターライブラリで、Attention、MoE、GEMM、サンプリング、正規化、および通信‑計算融合に焦点を当て、Hopper GPU 用にネイティブな BF16 と FP8 サポートを提供します。その Attention と MoE カーネルは PR #46020 (Attention) と PR #45924 (MoE) を通じて vLLM にファーストクラスのバックエンドとしてアップストリームされ、ソース変更や長期間フォークを維持する必要はありません。
Attention バックエンド: 動的負荷分散スケジューリング
HPC‑Ops Attention バックエンドは、混合長デコードにおける静的 split‑KV スケジュールによるアイドル時間を、各ステップごとの負荷分散スケジューラによって解消します。このスケジューラは、すべての KV シーケンスを均一な 64 トークン タイルにタイリングし、実際の作業量に基づいて CTAs にタイルを割り当て、すべての SM を飽和状態に保つ永続カーネル グリッドを実行します。これにより、静的 split‑KV スケジュールに比べて最大 2.95× のスピードアップ、および H20 上での混合長デコードにおいて FlashInfer と FlashAttention に対して平均 2.25× の優位性が得られます。
融合された Attention プロローグ (HpcRopeNorm) は、QK‑Norm、RoPE、KV‑cache 書き込み、および FP8 ではクエリの量子化を単一のカーネルに結合し、別々のメモリ境界の起動とそれに伴う HBM ラウンドトリップを排除します。
vLLM との統合は HpcAttentionBackend を通じて行われ、これは vLLM の AttentionBackend 基底クラスを継承し、標準のバックエンド メカニズムを介して登録されます。
MoE バックエンド: 融合された低レイテンシー FP8 MoE パイプライン
HPC‑Ops MoE バックエンドは、従来の MoE パスにおけるステージごとのオーバーヘッドを、ルーティング、Gate‑Up GEMM、活性化/量子化、Down GEMM、およびトップ‑k 重み付きリダクションを単一の実行パイプラインに融合することで除去します。共有メモリ カウント パスを使用して連続したエキスパート範囲を構築し、ルーティング インデックスを介してトークンを直接読み込み、中間結果をレジスタまたは共有メモリに保持し、占有率第一のワープ グループと永続グリッドを採用して、不均一なエキスパート タイルを CTAs に均等に広げます。プログラム依存型起動(Programmatic Dependent Launch)によりカーネル起動を重ね合わせ、バブルを消去します。
このパイプラインは FP8 で実行され、テンソルごとおよびブロックごとのスケーリングを行い、ベースラインの出力品質と一致します。H20 上では、TP8/EP1 で Triton と CUTLASS に対して平均 1.59× のスピードアップ、TP1/EP8 で 1.21× のスピードアップを達成します。
vLLM との統合は HPCExperts を通じて行われ、これは FusedMoEExpertsModular を継承し、標準のバックエンド登録メカニズムを介して登録されます。
vLLM で HPC-Ops バックエンドを使用する
バックエンドを使用するには、まずソースから HPC‑Ops をインストールします:
git clone https://github.com/Tencent/hpc-ops.git
cd hpc-ops
make wheel
python3 -m pip install dist/*.whl
Hy3 (BF16) モデルで Attention バックエンドを有効にする:
vllm serve tencent/Hy3 \
--tensor-parallel-size 8 \
--attention-backend HPC_ATTN
Hy3‑FP8 の場合は KV‑cache データタイプとブロックサイズを追加:
vllm serve tencent/Hy3-FP8 \
--tensor-parallel-size 8 \
--attention-backend HPC_ATTN \
--kv-cache-dtype fp8_e4m3 \
--block-size 64
MoE バックエンドを有効にする(FP8 のみ):
vllm serve tencent/Hy3-FP8 \
--tensor-parallel-size 8 \
--moe-backend hpc
これらのバックエンドは現在、NVIDIA Hopper アーキテクチャ GPU でのみサポートされており、最高のパフォーマンスは H20 で得られます。
H20 上のパフォーマンス
Fused MoE vs Triton / CUTLASS
バッチサイズ 4 から 16384 の範囲で、HPC‑Ops MoE のレイテンシーは Triton と CUTLASS の両方より低いです。TP8/EP1 では平均スピードアップが 1.59×、TP1/EP8 では平均スピードアップが 1.21× で、低レイテンシー デコードに典型的な小~中バッチサイズで最大の利益が得られます。
混合長バッチにおける Attention デコード
動的スケジューリングは静的 split‑KV、FlashInfer、および FlashAttention を上回ります。スピードアップはスキューに応じて増加し、均一な 64×0.5K バッチでは 1.00× から、1×128K + 31×4K の混合では 2.95× まで向上します。テストした分布全体で、FlashInfer/FlashAttention のうち最良のものと比較した平均的な優位性は 2.25× です。
Prefill、Extend、および Decode の形状における Attention
HPC‑Ops Attention のレイテンシーは、ベンチマークされたすべての形状において FlashAttention、Triton、および FlashInfer の最速と同等かそれ以上です(例:q512 prefill で 0.047 ms vs 0.069 ms、8q1s1k デコードで 0.019 ms vs 0.031 ms)。
Hy3 (8× H20) のエンドツーエンド
両方の HPC‑Ops Attention と MoE バックエンドを使用すると、vLLM デフォルト バックエンドと比較して TTFT が約 24%、TPOT が約 17% 削減されます。バッチサイズが増えるにつれて改善が大きくなり、テストした最大バッチサイズでは TTFT 削減が約 30%、TPOT 削減が約 30% に達します。
今後の展開
Tencent Hunyuan チームは、これらのバックエンドをさらに洗練させ、成熟したらアップストリーム作業を続け、ユーザーからのフィードバック、問題、ベンチマークを歓迎しながら vLLM コミュニティと協力を続けていきます。
謝辞
Tencent Hunyuan AI Infra チーム(Sethran Liu、Chase Shao、Shengy Wei、Theo Cheng、Ryann Xue、Lando Jiang、Looper Zhao、Haank Lin、Aiden Ren、Lehua Ding、Chengv Jiang、Steven Kuang、Liqi He、Kipper Gong、Reedlau Liu、Raccoon Liu、Dick Zhu)、Tencent Network Platform Department、vLLM/Inferact 貢献者(Kaichao You、Yongye Zhu、Yifan Qiao)、NVIDIA エンジニア(Yuanhang Sun、Perkz Zheng、Yuxi Chi、Jiang Shao、Jun Gu、Meng Wang、River Liu、Gary Ji、Chandler Zhou)、およびこの作業の基盤となり、ベンチマークとして参照されている広範なオープンソース カーネル コミュニティに感謝します。