騰訊混元が vLLM に HPC オプス対応

TL;DR

Tencent Hunyuan AI インフラチームが開発した生産環境向けオペレータライブラリ「HPC-Ops」の Attention カーネルと MoE カーネルが、vLLM の main ブランチで正式なバックエンドとして採用されました（Attention PR #46020、MoE PR #45924）。両方とも NVIDIA の Hopper アーキテクチャ向けに最適化されており、特に H20 での性能が際立っています。

• Attention: ステップごとの負荷分散型デコードスケジューラと、RoPE・QK-Norm・KV-write を融合したプロローグを実装。混合長のデコードでは、静的な split-KV スケジュールと比較して最大 2.95 倍、FlashInfer や FlashAttention と比較しても平均で 2.25 倍の性能向上を達成しました。

• MoE: 完全融合型の低レイテンシ FP8 MoE パイプライン。TP8/EP1 の構成では平均 1.59 倍、TP1/EP8 では 1.21 倍の高速化を実現し、出力品質は同等を維持しています。

Hy3 クラスター上で 8 台の H20 を使用したエンドツーエンドテストでは、デフォルトバックエンドと比較して TTFT（Time to First Token）が約 24%、TPOT（Tokens Per Output Token）が約 17% 短縮されました。

両方のバックエンドは vLLM の標準インターフェースを通じて既存のシステムに組み込むことが可能で、ソースコードの変更や長期にわたるフォーク不要です。

本記事では、HPC-Ops の概要と、これら 2 つのバックエンドがどのように設計・統合されたか、そして H20 上での実際の性能について解説します。

Why This Matters

生成 AI の本番環境における LLM サービングは、かつてカーネルが最適化していた均一で単一のバッチ処理とはもはや似ていません。実際のトラフィックは動的で長さが混在しており、モデルは MoE（Mixture of Experts）化が進みコンテキスト長も長期化しています。さらにエージェントワークロードの増加により、これらの負荷はさらに高まっています。この規模になると、レイテンシの多くは純粋な行列乗算スループットだけでなく、カーネルが GPU 上でいかに効率的に作業をスケジューリングし、ステージ間でデータを移動できるかによって決定されます。

アテンションデコードでは、固定された split-KV スケジュールにより、混合バッチ内の最長リクエストで処理が停止し、短いリクエスト側では計算リソースが遊んでしまう問題があります。MoE においては、各エキスパートごとの GEMM（行列乗算）は小規模であるため、従来のパイプラインではトークンを各エキスパート用バッファに集約する必要があり、各ステージで起動オーバーヘッドが発生します。さらに中間データを HBM（High Bandwidth Memory）間を移動させるコストもかかります。

vLLM はすでにコミュニティに対して高速かつ柔軟なサービングエンジンを提供していますが、残された課題は、アテンションと MoE のカーネルがいかにこの複雑で現実的なトラフィックを吸収できるかにあります。HPC-Ops が目指す正是にこれです。これは Tencent の大規模本番環境で堅牢化されたオペレータライブラリであり、Hy3 を運用する際と同じカーネルが、vLLM においてファーストクラスの「Attention Backend」と「MoE Backend」として取り込まれました。

Hy3 シリーズモデルについて

Hy3 は、エージェント実行、コーディング、長期推論を目的とした Tencent Hunyuan の Mixture-of-Experts モデルです。295B パラメータのうち 21B をアクティブに使用することで、そのサイズクラスにおいて最強クラスのエージェント能力を実現し、オープンソースのフラッグシップモデル（2〜3 倍大きいもの）にも匹敵します。さらに、多回対話での信頼性を高めるために幻覚を大幅に削減しています。

内部構造では、192 のエキスパートとトップ 8 ルーティング、GQA アテンション（64 ヘッド、8 KV ヘッド、ヘッド次元 128）、256K のコンテキストウィンドウ、および推測デコーディング用の 3.8B MTP レイヤーを採用しています。モデルは BF16 と FP8（Hy3-FP8）で提供されます。

本記事ではモデルそのものについて語るのではなく、それを支えるカーネルに焦点を当てます。これらについては後ほど詳しく解説します。

HPC-Ops: vLLM に統合されたプロダクション向けオペレータライブラリ

HPC-Ops は、Tencent Hunyuan AI Infra チームによって構築・維持されている、LLM 推論向けのオープンソースオペレータライブラリです。実際のサービスにおけるレイテンシとスループットを支配するホットパスに注力しており、アテンション、MoE、GEMM、サンプリング、正規化、通信と計算の融合などをカバーしています。ネイティブで BF16 と FP8 をサポートし、推論フレームワークへ簡単に組み込めるクリーンな Python API を提供します。

これらのカーネルは、Tencent 自社の大規模プロダクション環境における Hunyuan のサービス実績によって実証済みです。今回のリリースでは、その中から 2 つが vLLM に正式にバックエンドとして統合されました。

解決策：ステップごとの負荷分散デコード・スケジューラ

HPC-Ops アテンションバックエンドは、固定グリッドに代わり、バッチの実際の長さ分布に適応するフラットで永続的な設計を採用しています。この仕組みは3つの段階で構築されています。

• 割り当て (Assign)：軽量なアサインカーネルが、すべての KV シーケンスを均一な 64 トークン分のタイルに分割します。全ヘッドと全リクエストにおけるタイル総数を利用可能な CTAs（Compute Thread Arrays）の数で割ることで、各 CTA の予算（バケットサイズ）を決定します。タイルは「ヘッド優先・バッチ従属」の順序で走査され、CTA バケットに順次充填されます。ある CTA のバケットがいっぱいになると、その後のタイルは次の CTA に溢れ出します。この結果、長いシーケンスはその長さに比例して複数の CTA に分割される一方、短いシーケンスはわずかなタイルしか寄与せず、特定の CTA を独占することはありません。また、各 CTA には最小限の作業負荷下限が設定されており、総作業量が小さい場合でも過度な分割を防ぎます。これにより、チャンク数を管理可能な範囲に保ちつつ、後段の結合コストがスケジューリングによる恩恵を上回ることを防いでいます。生成されたタスマップはデコードステップごとに一度計算され、そのステップ内のすべてのトランスフォーマー層で再利用されるため、オーバーヘッドはほぼゼロまで均等化されます。

計算と結合。永続的なカーネルグリッドが実行され、各 CTA は割り当てられたタスクビンに対してループ処理を行います。各 CTA はタスクリプタを取得し、そのチャンクに対するアテンションを計算して、部分出力と log-sum-exp を分割バッファに書き込みます。その後、ターミネーターを検出するまで次のタスクへ進みます。グリッドが永続的であるため、タスク間の再起動オーバーヘッドや波ごとのアイドルギャップは発生せず、すべての SM がカーネル実行期間中飽和状態を維持します。

最終的に軽量な結合カーネルが各 (head, request) ペアのチャンク数を参照し、チャンクごとの部分結果を集約して、最終的な BF16 出力を生成します。

この仕組みにより、シーケンス長の分布がどれだけ偏っていても、すべての CTA がほぼ等しい負荷を負い、ほぼ同時に完了します。静的スケジューリングに固有なロングテールによるストールは解消され、以前はアイドル待機のために浪費されていた GPU サイクルを有効な計算に変換できます。

融合アテンションのプロローグ

アテンション演算を実行する前に、各レイヤーでは通常、QK-Norm、RoPE、KV キャッシュへの書き込みを別々のメモリーバウンドステップとして実行します。FP8 の場合、クエリの量子化も追加されます。HPC-Ops はこれらを単一のオペレーション（HpcRopeNorm）に融合させます。融合された QKV 投影から始まり、モデルが必要とする順序で QK-Norm と RoPE を適用し（Hy3 では RoPE の前に正規化）、K と V をそのままページキャッシュへ書き込みます。FP8 の場合、トークンごと・ヘッドごとの FP8 クエリとそのスケール値を出力するため、アテンションカーネルが再量子化する必要がありません。この 1 つのカーネルが、各レイヤーのアテンション序盤で行われていた別々の起動と HBM への往復通信を置き換えます。これはプレフィルとデコードの両方で適用されます。

vLLM との統合

HPC-Ops のアテンション API は、FlashAttention や FlashInfer などの既存バックエンドと共に、ネイティブなアテンションバックエンドとして vLLM に組み込まれています。具体的には、HpcAttentionBackend が vLLM の AttentionBackend ベースクラスを継承し、標準的なバックエンド登録メカニズムを通じて登録されます。

MoE バックエンド：融合され低遅延な FP8 MoE パイプライン

課題：小規模なエキスパート GEMM とその周辺オーバーヘッド

MoE の推論には、大きく分けて 2 つの運用モードが存在します。スループットが高くバッチサイズが大きい場合は、エキスパートごとの GEMM（行列積）計算量が膨大になり、計算リソースがボトルネックとなります。このケースでは既存の実装でも十分に機能します。

一方、低遅延のデコード処理は全く逆の状況です。各エキスパートに割り当てられるトークンはわずかな数しかなく、GEMM は小規模かつメモリアクセスがボトルネックになります。大規模な行列積向けに最適化されたカーネルでは、こうした形状のデータでは GPU の性能を十分に引き出せません。さらに、各エキスパートが生み出すタイル数がステップごとに変動するため、GPU 全体にこれらの小さなタイルを均等に分散させることが困難です。

GEMM 自体の問題に加え、従来の MoE パイプラインも課題を抱えています。通常の MoE 処理は、トークンのルーティング、各エキスパート用バッファへの集約、Gate-Up GEMM、活性化関数と量子化、Down GEMM、そしてトップ k の重み付けによる還元（トークン位置へ戻す）という、別々のカーネルが連鎖する構成です。このプロセスでは、行列積が始まる前に HBM 上に集約されたトークンのテンソルが一時的に確保され、各工程で独立したカーネル起動と中間データの HBM への往復が発生します。GEMM が小規模になるデコード処理においては、これらのオーバーヘッドが GEMM 自体の計算コストに加算されてしまいます。

解決策：融合された FP8 MoE パイプライン

HPC-Ops の MoE バックエンドは、MoE パス全体を再設計しました。トークンのルーティングとインデックス前処理、Gate-Up GEMM、活性化関数と量子化、Down GEMM、そしてトップ k 重み付け還元を一つのコンパクトな実行パスに融合させることで、多段階設計に伴う冗長なオーバーヘッドを排除しています。

ルーティングとインデックス構築では、共有メモリを用いたカウント処理でトークンを専門家ごとに割り当て、各専門家の出力範囲を連続的に確保します。これにより、大規模なトークンルーティングにおけるグローバル原子演算の負荷を大幅に削減し、GEMM が直接参照するルーティングインデックスとタイルごとのタスクリストを構築します。

Gate-Up GEMM では、ルーティングインデックスを通じて元のトークンを直接読み込み、独立した Gather ステップをスキップします。その上で、活性化処理と FP8 量子化は融合されたカーネルとして実行され、その出力は Down GEMM が直接参照します。

ワープの専門化に頼らず、まず Occupancy を最優先するアプローチを採用しています。データ転送と計算の両方を単一のワープグループが担当し、メモリレイテンシの隠蔽を CTA 内のソフトウェアパイプラインから、CTA 間のハードウェアスケジューリングへと移行させます。これにより、SM あたりの残存 CTA 数を増やすことに成功しました。また、すべての SM を常に稼働させるために起動された永続グリッドがタスクリストを消費し、小さく不均一な専門家ごとのタイル群を CTAs に均等に分散させます。

PDL（Programmatic Dependent Launch）によるステージングでは、各カーネルの起動を直前のカーネルの末尾と重畳させることで、ステージ間のアイドル時間を完全に排除します。これは最終的な top-k 加重還元に至るまで適用され、必要に応じて共有専門家の出力もこの処理に統合可能です。

これらの仕組みにより、中間データや起動処理がクリティカルパスから外れ、専門家ごとの計算は FP8 で実行されます。テンソル全体とブロック単位のスケーリングを併用しながらも、ベースラインモデルと同等の出力品質を維持しています。

vLLM との統合

HPC-Ops の融合 MoE API は、DeepGEMM や Triton といった既存のバックエンドと同様に、vLLM のネイティブな MoE バックエンドとして統合されています。具体的には、HPCExperts クラスは vLLM の FusedMoEExpertsModular ベースクラスを継承し、標準的なバックエンド登録メカニズムを通じて登録されます。

vLLM での HPC-Ops バックエンドの利用

このガイドでは、vLLM で HPC-Ops のバックエンド（Attention および MoE）を有効にする方法を説明します。

インストール

始める前に、ソースコードから HPC-Ops をインストールしてください。

git clone https://github.com/Tencent/hpc-ops.git
cd hpc-ops

# Build and install the wheel package
make wheel
python3 -m pip install dist/*.whl

クイックスタート

現在の HPC-Ops Attention バックエンドは、Hy3 シリーズのモデルのみをサポートしています。

HPC-Ops Attention バックエンドを使用して標準的な Hy3 モデルの vLLM サーバーを起動するには、以下のコマンドを実行してください。

vllm serve tencent/Hy3 \
    --tensor-parallel-size 8 \
    --attention-backend HPC_ATTN

Hy3-FP8 モデルを使用する場合は、いくつかの追加オプションが必要です。

vllm serve tencent/Hy3-FP8 \
    --tensor-parallel-size 8 \
    --attention-backend HPC_ATTN \
    --kv-cache-dtype fp8_e4m3 \
    --block-size 64

ヒント: カスタムモデルで HPC-Ops アテンションバックエンドを有効にするには、モデルの forward メソッド内の rope_norm を HpcRopeNorm に置き換えてください。参考として PR #46020 をご覧ください。

HPC-Ops MoE バックエンドは、FP8 モデルのみをサポートしています。

vLLM サーバーを HPC-Ops MoE バックエンドで起動するには、以下を実行してください。

vllm serve tencent/Hy3-FP8 \
    --tensor-parallel-size 8 \
    --moe-backend hpc

ハードウェアサポート

HPC-Ops バックエンドは現在、NVIDIA ホッパーアーキテクチャの GPU のみでサポートされており、特に H20 で最高のパフォーマンスを発揮します。

H20 上のパフォーマンス

Fused MoE: HPC-Ops vs Triton / CUTLASS

Hy3 モデル構成において、HPC-Ops MoE バックエンドを Triton および CUTLASS の各バックエンドと比較ベンチマークしました。TP8 / EP1 と TP1 / EP8 の両設定で評価した結果、バッチサイズ全体での平均では、HPC-Ops は最良のベースライン比に対して TP8 / EP1 で 1.59 倍、TP1 / EP8 で 1.21 倍高速でした。特に低遅延デコードを支配する小〜中規模のバッチサイズにおいて、最も大きな性能向上が確認されています。

表 1: バッチサイズごとの FusedMoE レイテンシ（µs）※TP8 / EP1 設定（エキスパート重みを 8 ランクにシャード）

表 2：TP1 / EP8（専門家が 8 ランクにシャードされている）におけるバッチサイズごとの FusedMoE のレイテンシ（µs）

異なる長さのバッチにおけるデコード：動的スケジューリングと静的スケジューリング

アテンションバックエンドの最大の成果は、異なる長さのリクエストが混在するバッチでのデコード性能です。スケジューラの効果を明確にするため、FP8 デコードを均一な KV 長から極端に偏った分布までスweep し、HPC-Ops の動的スケジューリングを、静的な分割-KV スケジュール、FlashInfer、そして FlashAttention と比較しました。

この優位性は、データの偏りが大きくなるほど顕著になります。小さな均一バッチでは性能が拮抗する程度ですが、1 件の 128K KV 長リクエストと 31 件の 4K KV 長リクエストを混合したケースでは、最大で 2.95 倍の速度差となりました。これらのケース全体を通じて、動的スケジューリングは FlashInfer と FlashAttention の最良の結果と比較して平均 2.25 倍高速でした。

Table 3: KV 長分布ごとのデコードレイテンシ（ms）

Attention: HPC-Ops vs FlashAttention / Triton / FlashInfer

vLLM のアテンションベンチマークを用いて、prefill、extend、decode の各形状において、HPC-Ops アテンションバックエンドを FlashAttention、Triton、FlashInfer と比較しました。これらの形状全体を通じて、HPC-Ops はほぼすべてのケースで 3 つのライバルと同等か、あるいは最速のものよりも高速であることが確認されています。

表 4：アテンションレイテンシ（ms）— FlashAttention、Triton、FlashInferとの比較

End-to-end: Hy3 on 8× H20

最後に、HPC-Ops の MoE およびアテンションバックエンドを搭載した Hy3 モデルの、8 枚の NVIDIA H20 GPU を用いたエンドツーエンド（E2E）性能を、vLLM のデフォルトバックエンドと比較評価しました。すべてのテストケースにおいて、HPC-Ops バックエンドは vLLM デフォルトバックエンドを一貫して上回り、TTFT と TPOT の両方で大幅な短縮を実現しています。平均すると TTFT は約 24%、TPOT は約 17% 低下し、最大のバッチサイズでは TPOT が約 30% 改善しました。

Table 5: TPOT across different batch sizes (output length = 4K)

表 6：異なるバッチサイズにおける TTFT の比較（入力長=8k、チャンク付きプリフィルとプレフィックスキャッシュを無効化）

表 7：異なる入力長における TTFT（バッチサイズ=16、チャンク付きプリフィル無効化、プレフィックスキャッシュ無効化）

今後の展望

これは、vLLM コミュニティとの長期的な協力関係の始まりに過ぎません。今後は vLLM のメンテナーやコントリビューターと連携し、これらの機能をさらに改善・拡張するとともに、成熟した機能は本家プロジェクトへアップストリーム（上流）していきます。フィードバック、不具合報告、ベンチマーク結果のご提供を歓迎します。オープンで高パフォーマンスな推論の構築に向けて、一緒に取り組んでいくことを楽しみにしています。

謝辞

これらのバックエンドを vLLM に実装するためにチームを超えて協力してくれた多くの人々に感謝いたします：

• Tencent Hunyuan AI Infra — HPC-Ops 向けのアテンションと MoE（Mixture of Experts）カーネルの構築・最適化を行い、vLLM のバックエンドとして貢献したチーム。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 — 通信最適化における緊密な協力に貢献した部署。Xuan Zhang, Haoran Zhao, Yuanyuan Gong, Yadong Liu, Jinzhu Wang, Yinben Xia, Xiang Li, Quan Wen, Zekun He。

• 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。

また、本稿が基盤としている広範なオープンソースカーネルコミュニティにも感謝いたします。具体的には、NVIDIA の CUTLASS/CuTe、TensorRT-LLM、FlashInfer、FlashAttention、Triton などが含まれます。