DeepSeek-V4.1-Flashを大規模に提供：vLLMがDeepInferと同等の性能を達成し、GB300 NVL72へスケール

要約: NVIDIA GB300 NVL72 ラック 1 台の上で、P/D 分離と Wide-EP を備えた vLLM が DeepSeek-V4.1-Flash を SemiAnalysis AgentX において以下の性能で処理しています。 GPUあたり954Kトークン/秒 ユーザーあたりP90で196 tokens/sのとき、 7.9× 当社のシングルノードでの結果（ 最初の投稿 および 38.96ドル/GPU時間あたり DeepSeekのオフピーク料金で。特殊化されたデコードパスは 826 トークン/秒 単一ユーザー向けの比較では、DeepSeek自身のエンジンであるDeepInferに対し、vLLMのデコードスループットは 6% バッチサイズ8～256の範囲にわたっており、そのプリフィルはDeepInferの公表された曲線に一致します。

その効率性は、vLLMがすでに備えているコンポーネントへの意図的なエンジニアリングによって実現されたものであり、DeepSeekがオープンソース化したカーネルの上に構築されています。この記事では、私たちのパフォーマンス調査を紹介し、各最適化を分解して解説し、学んだ教訓を共有します:

• 汎用エンジンでもモデル特化型のエンジンに匹敵できる
• 最適化の前にモデルを理解する
• 小規模なDEPインスタンスはプリフィルに最適です¹
• Wide-EPデコードはEPLBで良好にスケールする
• NVL72のスケールではCPUのオーバーヘッドが深刻になる
• 特殊化されたデコードパスが低レイテンシを実現する

パフォーマンス概要

図1: NVIDIA GB300 NVL72上のSemiAnalysis AgentX:vLLMのP/D分離とWide-EP(金)は、前述の集約型シングルノードの結果からさらに7.9×のスループット向上を達成する 最初の投稿。スループットにはキャッシュされた入力トークン、キャッシュされていない入力トークン、および出力トークンが含まれます(source).

DeepInferとの比較

DeepInfer は、DeepSeek-V4.1-Flash向けのDeepSeek自身の推論エンジンであり、今週、オフラインエンジンとしてprefillおよびdecodeのカーブを公開する形でリリースされました。このモデルにとって最も関連性の高いリファレンスであるため、私たちの最適化について説明する前に、vLLMがそれに対してどの位置にいるかを示します。

Decode。 DeepSeekのdecode構成（131Kコンテキスト、nextn=3）において、GB200上のvLLMは、バッチサイズ8から256の範囲で、DeepInferの公開結果に対して6%以内のスループットを達成しました（Figure 2）。

図2: 131Kコンテキスト、nextn=3におけるGPUあたりのデコード出力スループットとバッチサイズの関係。GB200上のvLLMとDeepInferの公開結果の比較。DeepInferのREADMEのチャートから読み取った値（ソース).

Prefill（プレフィル）。 DeepInferの公開プレフィル曲線は、EP4DP4に32個の冗長エキスパートと140トークンの有界リプレイを用いたものであり、ハードウェアはチャートに明記されておらず、我々はその値をチャートから読み取った。我々の実行は、GB300上でDEP2を用い、冗長エキスパートなし、128トークンのリプレイ、独自のプロンプトを使用した。セットアップが異なるため、2つの曲線の間隔をエンジン間の高速化として読み取ることはしない。図3が示しているのは、vLLMのDEP2プレフィルが、DeepInferが公開した範囲にわたってDeepSeek自身のエンジンに追随しているということである。

図3: プレフィルスループットと新規トークンの関係。GB300上のvLLM DEP2とDeepInferの公開曲線（EP4DP4、32個の冗長エキスパート、140トークンリプレイ、ハードウェア不記載）の比較。READMEのチャートから読み取った値（ソース).

2つのエンジンの結果が接近するのは、双方向に共通の系譜を持つためである。DeepInferは元々vLLMをベースに構築され、vLLMもまた、MegaAttn、MegaMoE、Mega-mHCを含むDeepSeekのライブラリからのカーネルを継続的に統合し、残りのスタックもそれらを中心に大規模に最適化してきた。DeepInferはオフラインモードで単一モデルを対象とするが、同じvLLMビルドは、このモデルをオンラインで、NVL72ラック全体にわたるP/D分離とWide-EPを用いて提供もしており、それが本記事の残りの部分で測定する内容である。以下のセクションでは、その取り組みについて説明する。

内部構造：速度の源泉

まずモデルを測定する

チューニングに入る前に、我々はまずDeepSeek-V4.1-Flashの効率的なアーキテクチャ設計を定量化することから始めた：

• 小さなKVキャッシュフットプリント。 クロスレイヤーKV共有とFP4圧縮のおかげで、グローバルKVキャッシュはトークンあたりわずか890バイトである（詳細は DeepSeek-V4.1-Flash Technical Report).
• 軽量なアテンション。 レイヤー2、8、14は、フルコンテキストのインデックス作成に2×圧縮を使用する。有界リプレイでは、レイヤー20はすべてのトークンのグローバルKVを書き込むが、インデックス作成とアテンションは最後の128トークンに対してのみ実行し、レイヤー21〜39はそれらのトークンのみを処理する。
• デコードは長コンテキストでもMoEがボトルネックである。 下の図5を参照。DEP4で128Kコンテキスト、ランクあたり64リクエストでデコードした場合、MoEがターゲットステップの62%を占めるのに対し、アテンションとインデクサーを合わせてもわずか13%である。

下の表は、GB300 上での DEP32、ランクあたり 16 リクエスト、リクエストあたり 6 トークン(1 トークンと 5 つの DSpark ドラフトトークン)、すべてのリクエストが同じコンテキスト長という条件でのターゲットモデルのフォワード時間を示しています。128K から 855K への変化では、6.7 倍のコンテキストにもかかわらず、ターゲットモデルのデコードレイテンシの増加はわずか 0.6 ms(+7%)です。

これらの特性が、以降の最適化戦略を形作っています:

• プリフィルは小さな DEP サイズで実行すべきです。 B300 や GB300 上の DEP2 インスタンスでも、多くの同時セッション分のモデルウェイトと KV キャッシュの両方を保持できます。より小さいワールドサイズは DP/EP のロードバランシングを大きく単純化します。
• KV 容量がバッチサイズを制限することはほとんどありません。 KV キャッシュは HBM に余裕を持って収まるため、KV 容量を回避するのではなく、各演算をその計算またはメモリ帯域幅の限界に近づけることができます。これにより、スイープが一貫性を保ち、プリエンプションや KV キャッシュの圧力なしに低ノイズで行えます。
• Wide-EP はデコードに有効です。 MegaMoE のデコードはウェイト読み出しがボトルネックであり、Wide-EP はこの支配的な MoE コストを直接削減します。
• デコードの DP ロードバランシングはより単純です。 このモデルのデコードステップ時間はコンテキスト長にほとんど依存しないため、DP ロードバランシングはランクあたりのリクエスト数による最小負荷方式に単純化できます。
• 合成ワークロードはデコードの代表的な指標として有効です。 平均入力長と出力長を使うことで、エージェンティックなトレース全体を再生せずとも、性能を精度よく推定できます。

測定方法

方法論を過度に複雑にせずに性能を正確に測定することは簡単ではありません。我々はこれを 2 つの問いに分解します。プリフィルまたはデコードのステップはいくらかかるべきか、そして DP と EP の不均衡からどれほどの追加オーバーヘッドが生じるか?

• プリフィルおよびデコードのステップ時間。 vllm bench forward (#61339) は、正確なプリフィルまたはデコードバッチについて、実際の execute_model パスを DP ランクと EP ランクを通じて実行した際のモデルフォワード時間を測定します。これは GPU 時間のみを測定し、クリーンなトレースを得られます。さらに、vLLM の DecodeBenchConnector は、所定の同時実行数におけるエンジンレベルのエンドツーエンドのデコード性能を測定します。GPU のみの時間とサービングのステップ時間の差により、予期しないオーバーヘッドが明らかになります。
• プリフィルの DP 不均衡:ミラー vs. ラグ再生。 エージェンティックなトレースは実行ごとに異なるため、DP の不均衡を切り分けるのは困難です。そのため、我々はすべての DP ランクで同一のリクエストを再生します。 mirror 実行では、すべてのランクが同時にリクエストを受け取ります。 lag 実行では、ランク r 同じリクエストを受け取る r × 5 秒後であるため、ランクはずれたままですが、合計の作業量は同じです。2つの実行の差が DP 不均衡のコストです。
• Decode EP 不均衡: 実ルーティング vs. 均一ルーティング。 各 MoE レイヤーにおいて、balancedness をステップごと、および EPLB のウィンドウ全体にわたる「平均ランク負荷÷最大ランク負荷」として定義します。均衡の基準として、トークンを一様ランダムにルーティングした同じ decode バッチを実行します。この基準にもサンプリングノイズは残ります。DEP32 では GPU あたり 72 リクエストの条件下で、一様ルーティングはターゲット(top-6 ルーティング)で約 0.96、ドラフト(top-3)で 0.94 の balancedness に達します。実ルーティングと一様ルーティングの差がエキスパート均衡化によって回復できる最大値であり、EPLB の実行はその差のどれだけを実際に回復できたかを示します。

Prefill: DEP2 が最も効果的

上述のとおり、prefill には小さな DEP サイズが有利です。同時実行数 256 の AgentX の prefill 専用実行では、DEP4 は DEP2 の GPU あたりスループットの 83%(53.3K 対 64.4K トークン/s)しか達成できませんでした。prefix キャッシュをオフにした mirror 再現と lag 再現は DP 不均衡を示しています。ランクがずれると、DEP4 はスループットの 13.6% を失います。² このことから、私たちは DEP2 をシンプルなデフォルトとしています。

トレースの背後に隠れた最適化

私たちの 最初の投稿 広範なプリフィル最適化を取り上げました。よりクリーンなトレースにより、残りのボトルネック、特にコンテキスト長とともに増大するものを特定できました。たとえば、GB300 GPU 2基では、8Kトークンのプリフィルにかかる時間は 事前の文脈がない場合で87.9 msが、 512Kのキャッシュされたコンテキストで189.4 ms. さらに3つのボトルネックにも対処しました:

SWAの境界付きリプレイでは、すでにレイヤー21〜39を最後の128トークンに制限しています。以前は、レイヤー20は依然としてすべての新規トークンに対してインデクサー計算を実行していました。今回からは、すべての新規トークンのKVを書き込みますが、残りの計算は128トークンのリプレイバッチに対してのみ実行します。これにより、プリフィルのスループットが次の分だけ向上します: 32K新規トークンで19.9%, 4Kでの10.1%から64Kでの23.1%へと利得が増加しています。

Engram は、DP ランク間で共有されるホストテーブルからランダム読み取りを行います。前回の /dev/shm マッピングには64 KBのGPUページが使用されており、頻繁にGPU TLBミスが発生していました。テーブルをホストNUMAのcuMemアロケーションに移動することで2 MBのGPUページが有効になり、プリフィルのスループットがさらに 新しいトークン32Kでの2.8%.

プリフィルインデクサーがDeepSelectを使用して候補ブロックをランク付けするようになり、デコードパスと一致しました。その効果はランク付けされるキーの数が増えるほど大きくなり、プリフィルのスループットがさらに向上します。 新規トークン32Kで15.6% そして64Kでは15.2%。

これらの変更により、全体として〜が改善されます 新しいトークンのプレフィルスループットを35.6～43.9% キャッシュされた128Kのプレフィックスに加えて、4K～64Kの新規トークンにわたって。32Kでは、合算したゲインは 42.5%; 64Kではスループットが 71.2Kから102.5K tokens/s/GPU(+43.9%).

図4：DEP2 で 128K キャッシュヒット後の GPU あたりの新トークンプリフィルスループット。レイヤー20のリプレイ、Engram 2 MB ページ、DeepSelect top-k を一つずつ追加した場合。

デコード: Wide-EP のスケーリングと EPLB によるエキスパートの負荷分散

デコード側では、EPLB を用いた Wide-EP は確立された手法であり、以下で説明されている。 DeepSeekの推論システムの概要. vLLMは両方を以前からサポートしています(我々の 大規模サービングに関する記事を参照)。そして、これらは依然としてうまく機能することを確認しました。このセクションでは、新たな知見と実証的な教訓に焦点を当てます。

Wide-EPのスケーリング

128KコンテキストでGPUあたり64リクエストという条件で、DEP4からDEP32までのデコードのスケーリングを測定しました(EPLB有効、次のセクションを参照)。各ランクが保持するエキスパート数が減るにつれて、ターゲットのMegaMoE時間は13.4 msから6.0 msに低下しましたが、残りの処理時間は約10 msのままでした。その結果、GPUあたりのスループット向上は次第に小さくなりました。DEP32では、ドラフトの通信オーバーヘッドが、より広い並列化の利点を相殺し始めました。

図5:NVIDIA GB200上で128Kコンテキスト・GPUあたり64リクエストの条件で、DEP4からDEP32までのランクごとのデコードステップ時間、およびGPUごとの出力スループット。

EPLB

EPLBに、直近1,000ステップの負荷に基づいて3,000ステップごとにエキスパートを再配置させました。EPLBにより、ターゲットの均衡度は0.35から0.94へ、ドラフトは0.21から0.89へ向上し、一様ルーティングとの差の約97%と93%を回復しました。

図6:GB300 NVL72でのデコード。EPLBなし、ターゲットモデルのみにEPLB、ターゲットとDSparkドラフトの両方にEPLBの3ケース。タブにはステップごとの均衡、DEP32でのステップごとの時間内訳、スループット(3回実行の平均、バーは範囲)を表示します。

これを実現するために2つの変更を行いました。 #62009 は、デコードを停止せずに1秒未満でDEP32全体の再バランスを行うNVLinkベースの symm_mem DEP32全体をデコードを停止することなく1秒未満で再バランス化するバックエンドを導入し、EPLBのレプリカマッピングと負荷記録をMegaMoEカーネルに融合させ(ステップあたり約0.2 msを削減)、さらにデコードループからホスト同期を除去します。 #61395 は、ターゲットとドラフトという異種モデルを対象にEPLBをサポートします。DSparkドラフトはtop-3ルーティングの128のルーティングエキスパートを持つのに対し、ターゲットはtop-6で384のため、EPLBはモデルごとにエキスパート配置と負荷を別々に追跡し、両方を再バランスします。

高速な大規模デコードにおけるCPUオーバーヘッドを克服する

Wide-EPデコードはすべてのレイヤーで全ランクを同期するため、1つの遅いランクがインスタンス全体を停止させます。非同期スケジューリングは小規模ではCPUオーバーヘッドをよく隠蔽しますが、ランク数が増えると2つの点でこれが難しくなります。GPUステップが短くなりCPU処理の余裕が減ること、そして1つのランクが遅れを取る可能性が高くなることです。

実際、最適化されていないDEP32はGPU実行が1.1 ms速いにもかかわらず、DEP16より遅く動作すること(ステップあたり17.57 ms 対 13.84 ms)を観察しました。下の表は、見つかったすべての原因を影響の大きい順に並べたものです。各効果は異なるセットアップに由来するため、各行にそれぞれの値を示します。

低レイテンシ:小バッチ向けの特殊化デコードパス

さらに、DeepSeek-V4.1-Flash 向けの低レイテンシカーネルサポートを拡張しました(#61868 および #61869)。これは、私たちの 前回の記事での取り組みを継続するものです。実際のAgentXセッションにおいて、特殊化デコードパスは4基のB300 GPU上で単一ユーザーあたりP90 826トークン/秒に到達し、標準デコードパス(575)より44%高速です。

図7:4基のB300 GPU上でTP4によるSemiAnalysis AgentXの同時実行数1、8、16での、変更前と変更後の比較 InferenceX #4332 が特殊化デコードパスに切り替えた後。

謝辞

私たちは DeepSeek に感謝します。DeepSeek-V4.1-Flashとその最適化カーネルをオープンソースとして公開・共有し、本作業の基盤を提供してくださったこと、またDeepInferとその性能結果を公開し、学び比較する優れたリファレンスを提供してくださったことに感謝します。また、 SemiAnalysis にはAgentXベンチマークプラットフォームと多くのご支援に感謝します。

特に感謝申し上げます Pei Li、Hanjie Qiu、Lisa Wang、Yaoyao Ding、Rohit Nagraj、Xin Li から NVIDIA ,パフォーマンス最適化における緊密な協力、vLLMおよびDynamoにわたる継続的なサポート、そしてAgentX提出物への支援に感謝します。また、以下の方々にも感謝します。 Canlin Guo から vLLM コミュニティ 価値あるプリフィル最適化に対して。

この研究は以下の方々が主導しました: Inferact.

脚注

1. DEPn 「はデータ並列アテンションに、さらにエキスパート並列化を組み合わせたものであり、」 n GPU向け。ターゲットフォワード(target forward)は、各デコードステップでメインモデルの完全なフォワードパスを実行し、ドラフトトークンを検証して出力を生成します。ドラフトフォワード(draft forward)は、DSparkドラフトモデルの完全なフォワードパスを実行し、次のステップ用のトークンを提案します。 ↩

2. 以前のビルドで測定。この不均衡のコストは、カーネルではなくDEPサイズの特性である。 ↩