Tencent HPCがSGLangに登場、デフォルト推論カーネルに挑戦

Tencent HPCが、3つの最適化されたオペレーターパスと、Hy3のトークンレイテンシを48.8%削減したとの報告を携えて、SGLangのメインブランチに加わった。この貢献により、Tencent HunyuanのHPC-OpsライブラリにあるDynamic Attention、Router GEMM、Fused MoEの実装が、広く使われるオープンソース推論エンジンへ導入される。

この主要な数値は慎重に捉える必要がある。TPOT（time per output token）は、最初のトークンが出力された後に生成トークン間で生じる平均レイテンシを測る指標だ。TencentとSGLangが報告しているのは、あらゆるモデル、GPU、トラフィックパターンに共通する改善ではなく、テストされたHy3構成で最大48.8%の改善である。

それでも、これは孤立したCUDAベンチマークの寄せ集め以上のものだ。SGLangのユーザーは、プライベートフォークを維持することなく、アップストリームのフレームワークを通じてこれらのカーネルにアクセスできる。これによりTencentのオペレーター技術は、既存のSGLang、FlashInfer、CUTLASS、Triton、そしてベンダー支援の推論パスと直接競合することになる。

Tencent HPC、カーネルライブラリからSGLangへ

重要なのは、単に高速なベンチマークが増えたことではなく、配布経路の変化だ。

HPC-Opsは、TencentのHunyuan AI Infrastructureチームが開発したオープンソースの推論オペレーターライブラリである。オペレーターリポジトリは、Attention、GEMM、Mixture-of-Experts計算、サンプリング、正規化、融合通信オペレーションをカバーしている。

オペレーターとは、GPU上で特定のモデルタスクを実行する低レベルの計算ブロックだ。SGLangのようなフレームワークは、こうしたブロックを組み合わせ、モデルリクエストを処理する実行パスを構成する。

アップストリーム統合前は、HPC-Opsに関心を持つチームは、自身のサービング環境内でコンポーネントをインストールし、接続する必要があった。この作業には、互換性テスト、バックエンドの選定、どちらかのプロジェクトが変更された際の継続的な適応が伴った。

SGLangのメインブランチへの統合により、その関係は変わる。フレームワークは、保守されたバックエンドパスを通じて、対応するHy3オペレーションをTencentのカーネルに認識・ディスパッチできる。ユーザーは、この実装を評価するためだけに長期間SGLangのフォークを維持する必要がなくなる。

初期の貢献は、レイテンシに敏感な次の3領域に集中している。

• Dynamic Attentionは、不均一なデコーディング作業をGPUの実行ユニット間に分散する。

• Router GEMMは、MoEエキスパートの選択に使われる精度に敏感な行列乗算を高速化する。

• Fused MoEは、複数のエキスパート処理段階を統合し、カーネル起動とメモリトラフィックを削減する。

それぞれが異なる推論遅延の要因を狙っている。組み合わせることで、長いコンテキストとスパースモデルによって生じる不規則なワークロードに対応する。

Hy3は、両方の問題を併せ持つため、有用なテストケースとなる。TencentはHy3を、エージェント実行、コーディング、長時間の推論向けに設計されたスパースなMixture-of-Expertsモデルだと説明している。そのアーキテクチャはトークンごとにモデルの一部だけを有効化するが、拡大するコンテキストに対するAttentionと、多数のエキスパート間でのルーティングを依然として必要とする。

この組み合わせにより、単純化されたベンチマークで通常支配的となる大規模行列乗算以外にもレイテンシが発生する。オンラインサービングでは、スケジューリング、データ移動、精度変換、ルーティング、小規模なカーネル起動も同等に重要になり得る。

報告されたエンドツーエンドの結果は、テストされたHy3ワークロードでTPOTを最大48.8%削減したというものだ。この数値はプロジェクトの作成者によるベンチマーク環境に基づくものであり、幅広いハードウェア構成で独立再現されたものではない。

この区別は重要である。「最大」は、測定された中で最も良好なケースを示す。すべてのリクエストパターンでの平均的な改善を示すものではない。短く均一なプロンプトを処理するサーバーでは、長さが混在するエージェントセッションを扱うサーバーとは異なる結果になる可能性がある。

HPC-Opsは依然としてハードウェア固有でもある。公開されている要件では、NVIDIAのSM90アーキテクチャ、Python 3.8以降、CUDA 12.8以降が指定されている。ライブラリによれば、そのカーネルは特にNVIDIA H20 GPU向けにチューニングされている。

これは即時の移植性を制限するが、アップストリームで利用可能になった意義を損なうものではない。SGLangは、モデル開発者、インフラチーム、カーネル開発者にとって一般的な統合ポイントになっている。そこに加わることで、Tencentの技術は単独リポジトリが通常受けるよりも現実的なテストにさらされる。

これはvLLMへの同様の統合にも続くものだ。7月には、HPC-OpsのAttentionおよびMoEバックエンドが、第一級の選択肢としてvLLMのメインブランチに加わった。付随するvLLMベンチマークでは、8基のH20 GPU上で初回トークンと出力トークンのレイテンシ低下が報告されている。

したがってSGLangは、Tencentがプロダクション指向のカーネルがTencent自身のインフラを越えて通用するかを検証できる、2つ目の主要なサービングエコシステムとなる。ベンチマークの背後で起きている本当の出来事はそこにある。

Tencent HPCがオンラインモデルサービングで重要な理由

現代の推論性能は、生の行列スループットを最大化するだけでなく、不規則な作業を管理できるかに左右される。

オフラインベンチマークでは、固定されたプロンプト長、予測可能なバッチ、安定したテンソル形状が使われることが多い。プロダクションのトラフィックは異なる。リクエストは継続的に到着し、コンテキストは異なる速度で増え、ユーザーは予測不能なタイミングで生成を停止する。

あるリクエストには16,000トークンのコンテキストが含まれる一方、別のリクエストは1,000トークンで始まったばかりかもしれない。静的なAttentionスケジュールでは、あるGPUブロックに他よりはるかに多くの作業が割り当てられる可能性がある。短いタスクは早期に終了する一方、最も長いタスクがランチ全体の完了時刻を決める。

Dynamic Attentionは、この不均衡を減らそうとする。HPC-Opsは、key-value cacheの作業をより小さなタイルに分割し、現在のワークロードに応じてそれらのタイルを割り当てる。デコーディング中にリクエスト長が変化すると、マッピングも再構築される。

key-value cacheは、モデルが新しいトークンごとに履歴全体を再計算しないよう、以前のAttention状態を保存する。履歴が長くなるほど、読み取り・処理すべきキャッシュデータも増える。

HPC-Opsは、リクエストを均一なタイルに分割し、それらを協調スレッド配列に分散するスケジューラーを説明している。協調スレッド配列、すなわちCTAは、スケジュールされた作業単位を実行するGPUスレッドのグループである。

ライブラリは、選択された可変長テストにおいて、Dynamic Attentionが静的split-kベースラインの最大2.88倍の性能を示したと報告している。より広範なAttentionの結果には、指定された構成におけるFlashInfer、FlashAttention、TensorRT-LLMに対する改善も含まれる。

こうしたオペレーターレベルの数値を、エンドツーエンドのサーバー改善と混同してはならない。より高速なAttentionカーネルが影響するのは、そのオペレーションに費やされる総レイテンシの割合だけだ。リクエストスケジューリング、通信、モデルロード、サンプリング、その他のレイヤーは依然としてパスに残る。

それでも、コンテキストが長くなるにつれてAttentionの重要性は増す。エージェント型アプリケーションは、ツール結果、検索された文書、中間推論をアクティブなセッションへ繰り返し追加する。これはまさに、動的スケジューリングが対象とする不均一なキャッシュ長を生み出す。

コーディングアシスタントは具体例を示す。あるリクエストには小さな関数と短い指示だけが含まれるかもしれない。別のリクエストには、リポジトリマップ、複数のファイル、ビルドログ、会話履歴全体が含まれる可能性がある。

両方のリクエストを1つの連続バッチに入れると利用率は向上するが、Attention作業は不均一になる。静的な分割ポリシーでは、一部のGPUユニットが遊休状態になるか、短いリクエストのために空のチャンクを起動することになる。

動的スケジューリングは、こうしたリクエストをより効率的に共存させようとする。最大の利点は、シーケンス長が大きく異なり、かつサーバーに再均衡化できる十分な並行作業がある場合に現れるはずだ。

これが、単一のスループット数値よりTPOTが重要な理由である。スループットは、全リクエストにわたる集計出力を測る。TPOTは、生成中に個々のユーザーが連続するトークンをどれだけ速く見るかをより直接的に反映する。

対話型エージェントでは、遅いトークン配信が長い応答や繰り返されるツール呼び出しを通じて累積する。TPOTが低下すれば各生成セグメントを短縮でき、その後のツールまたはモデルのステップをより早く開始できる。

この統合は、推論フレームワーク内のデフォルトカーネル選択にも圧力をかける。SGLangはすでに複数のAttentionおよびMoE実装を提供しており、それぞれが異なるモデル、精度、GPU向けに最適化されている。新たなバックエンドは、脆弱な構成ルールを生まずに、それらの選択肢を上回る必要がある。

この競争が運用者に利益をもたらすのは、フレームワークのディスパッチが理解しやすい場合に限られる。インフラチームは、HPC-Opsがいつ有効になるか、どの形状に対応するか、非対応リクエストをどのフォールバックが処理するかを把握する必要がある。

また、自身のトラフィックから得た証拠も必要だ。公開ベンチマークは有望なバックエンドを特定できるが、シーケンス長、バッチサイズ、量子化、並列性、サービスレベル目標のあらゆる組み合わせを再現することはできない。

この貢献を評価するチームは、中央値およびテールTPOT、初回トークンまでの時間、リクエストスループット、GPUメモリ使用量、出力の一貫性を測定すべきである。平均レイテンシだけでは、最も遅いユーザーに影響する停止を見落とし得る。

評価を取り巻く技術知識にも、同じ規律が当てはまる。エンジニアリングチームは、分散したチャットスレッドに頼るのではなく、ベンチマークコマンド、デプロイメントノート、障害分析を検索可能なナレッジベースに保存できる。

Tencent HPCが重要なのは、こうしたチームにテスト可能な、もう1つの保守された実行パスを提供するからだ。その価値は、ローンチチャート上の最大値ではなく、再現可能なサービング改善から生まれる。

Dynamic AttentionとFused MoEは異なるボトルネックを狙う

報告されたHy3の改善は、生成されるすべてのトークンで蓄積する複数の小さな遅延を取り除くことで得られている。

Dynamic AttentionはAttention時の負荷不均衡を狙う。Fused MoEは、モデルがトークンを選択されたエキスパートへルーティングした後の断片化を狙う。Router GEMMはその中間に位置し、エキスパートを割り当てる判断を高速化する。

MoE、すなわちMixture-of-Expertsは、一部の密なニューラル層を、より大規模な専門化されたフィードフォワードネットワーク群で置き換える。ルーターはトークンごとに少数のエキスパートを選択し、トークンごとに実行する計算を抑える。

このスパース性はアクティブな計算を減らすが、不規則性ももたらす。異なるエキスパートが異なる数のトークンを受け取る可能性がある。サーバーはルーティングスコアを計算し、トークンを整理し、複数の小さな行列乗算を実行し、重み付けされた出力を結合しなければならない。

従来の実装では、これらの操作を複数のカーネルに分けることが多い。トークンをエキスパート固有のバッファに集め、行列演算を起動し、活性化を適用し、中間値を量子化し、選択された出力をリダクションする。

分離のたびに、さらに1回の起動と、高帯域幅メモリへの追加アクセスが生じ得る。こうしたコストは個別には小さいが、各エキスパート操作が比較的少数のトークンしか処理しない低バッチのデコーディングでは大きな意味を持つ。

HPC-Opsは、融合FP8 MoEパスを使用する。FP8は8ビット浮動小数点形式であり、より広い形式と比べてメモリトラフィックを削減し、利用可能なTensor Coreスループットを高める。

この融合パスは、ルーティング関連の前処理、ゲートおよび拡張行列乗算、活性化量子化、モデル幅への投影、重み付きリダクションを組み合わせる。Tencentによれば、この実装は、最初に収集済みエキスパートバッファへコピーするのではなく、ルーティングインデックスを通じて元のトークンを読み取る。

この設計は、メモリ移動とカーネル起動間のギャップの両方を取り除くことを目的としている。また、実装がレイテンシを隠蔽する方法も変える。

単一のGPUブロック内でソフトウェア・パイプライニングに大きく依存するのではなく、HPC-Opsは低レイテンシの形状に対して常駐ブロック数を増やす。これによりハードウェア・スケジューラは、他の処理がデータを待っている間にブロック間を切り替えられる。

同ライブラリは、Fused MoEオペレーターについて、テンソル並列では最大1.6倍、エキスパート並列では最大1.5倍高速だと報告している。公開された比較には、SGLang、vLLM Triton、vLLM CUTLASSの実装が含まれる。

テンソル並列は、モデル計算を複数のGPUに分割する。エキスパート並列では、異なるMoEエキスパートを異なるワーカーに配置するため、トークンは選択されたエキスパートを保持するワーカーへ移動する必要がある。

最適な選択は、モデル形状、インターコネクト速度、リクエスト並行性、メモリ制約に依存する。融合されたローカルカーネルでも、分散エキスパート構成で必要となる通信を排除することはできない。

Router GEMMは、より微妙な制約に対処する。GEMMは一般行列乗算を意味し、多くのニューラルネットワーク層の中核となる演算である。

ルーターは低精度のアクティベーションに重みを乗算するが、重みのわずかな数値差がエキスパート選択に影響する場合がある。重みを過度に低精度化するとルーティング判断が変わり、ひいてはモデル出力も変化し得る。

完全なFP32演算は精度を守る一方、現行のTensor Coreは低精度フォーマットで得られるものと同等のFP32スループットを提供しない。単純な実装では、より低速なCUDA Coreによる計算にフォールバックする可能性がある。

HPC-Opsは各FP32重みを2つのBF16コンポーネントに分解する。BF16はFP32の指数範囲を維持しつつ、仮数部のビット数を減らしている。

一方のコンポーネントは重みの上位部分を担う。もう一方はスケーリングされた残差を担い、プロジェクトではスケールを1/256と記載している。その後カーネルは2回のBF16 Tensor Core乗算を実行し、結果を結合する。

2つの計算は1つのカーネル内に留まる。入力移動を共有し、中間アキュムレータをレジスタに保持し、最終結果は1回だけ書き込む。

Tencentは、選択されたルーターおよび状態圧縮の形状において、cuBLAS FP32またはTF32ベースライン比で最大3.22倍の性能を報告している。この主張はテスト済みのオペレーター形状を示すものであり、すべてのGEMMワークロードを対象とするものではない。

この仕組みが重要なのは、低精度ハードウェアのスループットを取り込みながら、ルーティング動作を維持しようとしているためだ。同等のエキスパート選択を伴わない高速化は、本番推論にとって望ましいトレードオフではない。

この精度の問題は、出力検証の詳細が重要である理由でもある。ベンチマークでは実行時間だけでなく、ルーティング判断や最終モデル出力を比較すべきだ。

先行するvLLM統合では、MoE比較において出力品質が一致したと報告された。今回のSGLang統合により、メンテナーやユーザーはフレームワーク実装間の数値的挙動を検証する新たな機会を得る。

3つのオペレーターを合わせると、一貫した実行の仕組みが形成される。Dynamic Attentionがコンテキスト処理を分散し、Router GEMMがスパース計算の行き先を決定し、Fused MoEがより少ない境界でその計算を実行する。

したがって、この改善は、単一のモノリシックなカーネルがほぼ2倍高速化したという主張ではなく、仕組みに関する話である。複数のボトルネックが削減され、その合計価値は各要因が特定のワークロードにどれほど寄与するかに依存する。

48.8%のTPOT改善が証明しないこと

最も強力なベンチマークは検証に値する有力な出発点だが、汎用的な性能保証ではない。

報告された削減率は、TencentのHy3評価およびサポート対象ハードウェアの条件に適用される。この数値も現行ドキュメントも、すべてのSGLangモデルで同じ結果が得られることを示すものではない。

Hy3は、モデル固有のAttention動作、スパース・ルーティング、FP8実行、特定のエキスパート構造を組み合わせている。MoE層を持たない密なモデルは、Fused MoEやRouter GEMMのパスから恩恵を受けられない。

異なる回転位置埋め込み、正規化順序、ヘッド次元、量子化スケール、キャッシュレイアウトを使うモデルでは、統合作業が必要になる場合がある。また、HPC-Opsの一部しか有効化されない可能性もある。

ハードウェアも別の境界を作る。HPC-Ops requirementsは現在、NVIDIA SM90 GPUとCUDA 12.8以降を中心としている。最も強い公開結果はH20に焦点を当てている。

これは、NVIDIA Ampereシステム、Blackwell構成、AMDアクセラレーター、その他のハードウェアが実証範囲外であることを意味する。SGLangは、このバックエンドが現在対象とするより広い環境をサポートしている。

H20上であっても、トラフィック形状によって結果は変わり得る。Dynamic Attentionの利点が最も明確になるのは、バッチに不均一なシーケンス長が含まれる場合だ。一様に短いリクエストでは、スケジューラが是正できる不均衡が少ない。

Fused MoEもバッチサイズに依存する。vLLMチームは、従来のカーネル起動とメモリパスが総時間に占める割合が大きい小・中規模バッチで、最大の改善を報告した。

高い並行性では、より大きな行列演算がGPUを十分効率的に利用し、差が縮小する可能性がある。エキスパート並列が複数デバイスやノードにまたがる場合、通信が支配的になることもある。

したがって48.8%という数値には、完全なベンチマークマトリクスの文脈が必要だ。読者は、プロンプト長、出力長、並行性、テンソル並列サイズ、エキスパート並列サイズ、キャッシュ精度、GPUクロック、ベースライン構成を確認すべきである。

ベースラインの品質は特に重要だ。デフォルトのバックエンドは新規ユーザーにとって妥当な比較対象になり得るが、最適にチューニングされた代替手段を表していない可能性がある。

SGLangのモジュール型エキスパート並列アーキテクチャは、カスタムカーネルと特化バックエンドを可能にする。FlashInfer、DeepGEMM、Triton、CUTLASS、ネイティブSGLangカーネルはいずれも進化を続けているため、比較結果は急速に変わり得る。

統合日も重要である。メインブランチのコードには、安定版リリースがより広範なデプロイメントに届く前に急速な変更が入る。マージ済みのバックエンドでも、パッケージ化、ドキュメント、互換性テスト、運用上の安全策がなお必要な場合がある。

数値精度も独立検証を要する領域である。Router GEMMは、2つのBF16コンポーネントを用いてFP32重み計算を近似する。この設計はFP32レベルの精度を目指すが、下流ユーザーはモデルレベルの挙動をテストすべきだ。

有用な確認項目には、決定的デコーディングでの出力一致、ルーティングインデックスの重複、代表データにおけるパープレキシティ、タスクレベル評価が含まれる。小さな数値差は無害かもしれないが、トークンを異なるエキスパートへ振り向ける可能性もある。

本番環境の信頼性は、数値的一致にとどまらない。カーネルは、境界形状、メモリ圧迫、キャンセル、継続バッチ処理、プレフィックスキャッシュ、変動するシーケンス長を、まれな障害なく処理しなければならない。

オープンソースでのレビューはこうした問題の発見に役立つが、可視性は成熟度と同義ではない。SGLang releasesは、モデルサポート、カーネル、量子化パス、スケジューリング動作がどれほど頻繁に変化しているかを示している。

Tencentは、HPC-Opsがすでに自社環境内で大規模推論をサポートしていると述べている。この経験には意義があるが、外部デプロイメントでは、社内モデル群が一度も使わない組み合わせが露呈することが多い。

保守に関する問題もある。アップストリームのコードはフォークを維持する負担を軽減するが、外部のHPC-Opsパッケージとその互換性マトリクスには、引き続き積極的なオーナーシップが必要である。

ユーザーは、TencentとSGLangが回帰報告にどれほど迅速に対応するかを注視すべきだ。また、継続的インテグレーションがサポート対象のGPU、精度、モデルの組み合わせをカバーしているかも確認すべきである。

これらの制約はいずれも結果を無効にするものではない。結果が実際に何を示しているかを定義するものだ。

TencentとSGLangは、サポート対象のHopperハードウェア上で、アップストリーム・バックエンドに関する強力なモデル固有ベンチマークを提示した。より広い主張には、より広い再現が必要である。

適切な対応は、自動的な採用でも却下でもない。組織固有のサービスレベル目標の下で、既存の最良のバックエンドに対して制御されたテストを実施することだ。

Tencent HPCがデフォルトを変えるかを決める3つのシグナル

次の段階は、採用、再現性、そして1つのモデルと1つのGPUファミリーを超えた拡張に関するものだ。

第1のシグナルは、SGLang内での独立したHy3ベンチマークである。外部事業者は、公開コマンドと完全な構成詳細を用いて、報告されたTPOT改善を再現すべきだ。

有用な再現試験には、中央値およびP99のTPOT、最初のトークンまでの時間、出力スループット、メモリ使用量、リクエスト失敗が含まれる。混在長のワークロードと一様なワークロードの両方をテストすべきである。

報告値に近い範囲での確認は、オペレーター最適化の組み合わせがユーザーに見えるデコーディング遅延を実質的に変えるというTencentの主張を強める。大幅に小さい改善であれば、最大結果が1つのワークロード形状に強く依存していることを示唆する。

第2のシグナルは、Hy3とH20を超えたサポートである。HPC-Opsはすでに、DeepSeek-V3、Hunyuanモデル、Qwen3-235Bに関するオペレーターレベルのベンチマーク範囲を公開している。

フレームワークレベルの統合はより難しい。各モデルは、Attentionレイアウト、正規化順序、量子化、エキスパート・ルーティング、分散実行が異なり得る。

広くデプロイされている別のMoEモデルへの対応は、このバックエンドが狭く最適化されたHy3パスではなく、再利用可能な基盤を提供することを示すだろう。Blackwell対応も、プロジェクトが当初のHopperターゲットを超えて適応できるかを試すことになる。

プロジェクトのロードマップには、より広範な量子化、将来のハードウェア、メガカーネル、低精度通信が挙げられている。メガカーネルは複数の連続する演算を結合し、起動オーバーヘッドと中間メモリトラフィックを削減する。

これらの項目がSGLang統合と公開ベンチマークを伴って実現すれば、Tencent HPCは推論バックエンド群の中でより幅広い競合相手となる。進展が少数のH20構成に留まる場合、有用ではあるが特化型のままとなる。

第3のシグナルは、SGLangユーザーが実際のデプロイメントでこのバックエンドを選択するかどうかである。リポジトリのスター数や単発のマイクロベンチマークは、運用上の採用を示す証拠としては限定的だ。

より有用な兆候には、デプロイメント手順、フレームワークのドキュメント、外部フリートからのバグ報告、互換性テスト、継続的なメンテナー活動が含まれる。安定版リリースへの収録は、メインブランチに存在するだけであることより重要だ。

採用が進めば、競合するカーネルには、混在長スケジューリング、ルーター精度、MoE融合を改善する圧力がかかる。SGLangのメンテナーは、生産的な課題に直面することになる。混乱を招く、あるいは脆弱なデフォルトを生まずに最速のバックエンドを選ぶことだ。

障害報告も同様に有益である。制御されたベンチマークでは隠れた、未対応形状、数値的なエッジケース、パッケージング上の摩擦、運用上の制約を明らかにするだろう。

開発者にとって、直近の問いは実務的だ。新しいバックエンドは、彼らが運用する正確なモデル、GPU、トラフィックパターンにおいてレイテンシを下げるのか。

インフラ購入者にとって、この問いは公開価格比較を必要としない経済的なものだ。TPOTの低下は、利用可能な容量を増やし、対話的な応答速度を改善し得る。ただし、それは信頼性と出力品質が安定している場合に限られる。

AIプロダクトチームにとって、その効果はベンチマークダッシュボードを超え得る。より高速なトークン配信は、コーディングセッション、エージェントループ、文書分析、その他1タスクあたり複数回のモデル呼び出しを行うワークフローを短縮する。

Tencent HPCは、そのオペレーターが現在SGLangのアップストリーム・パスに組み込まれているため、真剣な評価に値する。この統合により、最適化された研究結果と本番テストの間にあった障壁が1つ取り除かれる。

48.8%という数値は、そのテストの始まりであって終わりではない。サポート対象のHopperハードウェア上でHy3を運用するチームは、現在のSGLang構成に対してこのバックエンドを今すぐベンチマークできる。

それ以外の人々は、独立した再現、より広いモデルおよびハードウェアのサポート、持続的なデプロイメントの証拠という3つのシグナルを注視すべきだ。これらが、Tencent HPCが一般的な推論オプションとなるか、あるいは特化されたHy3の利点に留まるかを決定する。