Google Cloud A4X（GB200）と NVIDIA Dynamo を使用した WideEP Mixture-of-Experts 推論のスケーリング

※この投稿は米国時間 2026 年 1 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

組織が標準的な LLM から DeepSeek-R1 のような大規模な Mixture-of-Experts（MoE）アーキテクチャに移行するにつれて、主な制約は、物理的な計算密度から通信レイテンシとメモリ帯域幅へと変化しました。Google はこのたび、エージェント型 AI 時代におけるインフラストラクチャのボトルネックの解消を目指して設計された 2 つの新しい検証済みレシピをリリースいたしました。これらの新しいレシピは、NVIDIA GB200 NVL72 と NVIDIA Dynamo を搭載した A4X マシンシリーズ上のスループットとレイテンシの両方を最適化するための明確な手順を提供します。これは、2025 年 9 月に公開した A3 Ultra（NVIDIA H200）VM 上の分散型推論のリファレンス アーキテクチャを拡張したものです。

Google Cloud の AI インフラストラクチャの多層スケーラビリティと A4X のラックスケールのアクセラレーションを組み合わせることで、両者の利点を AI インフラストラクチャにもたらします。これらのレシピは、動的リソース割り当て（DRA）や推論ゲートウェイなどの重要な推論インフラストラクチャへの投資を含む、Google Cloud と NVIDIA の間の広範なコラボレーションの一環をなすものです。

更新されたリファレンス アーキテクチャの一部を以下にご紹介します。

• インフラストラクチャ: NVIDIA GB200 NVL72 を搭載した Google Cloud の A4X マシンシリーズで、第 5 世代の NVIDIA NVLink で接続された 72 個の GPU による単一の計算ドメインを構築します。

• サービング アーキテクチャ: NVIDIA Dynamo は分散ランタイムとして機能し、ラックスケールのファブリック全体で KV キャッシュの状態とカーネル スケジューリングを管理します。

• パフォーマンス: 8K / 1K の入力シーケンス長（ISL）/ 出力シーケンス長（OSL）の場合、スループット最適化構成では合計 6,000 トークン/秒/GPU 超のスループット、レイテンシ最適化構成では 10 ミリ秒のトークン間レイテンシ（ITL）を達成しました。

• デプロイ: Google Kubernetes Engine（GKE）をオーケストレーションに使用してこのスタックを Google Cloud にデプロイするために、検証済みのリファレンス アーキテクチャが現在利用可能です。

最新の推論スタック

エクサスケールのパフォーマンスを実現するには、推論をモノリシックなワークロードとして扱うことはできません。そのためには、特定の目標スループットとレイテンシに合わせて各レイヤが最適化されたモジュール型アーキテクチャが必要です。AI Hypercomputer の推論スタックは、以下の 3 つの異なるレイヤで構成されています。

1. インフラストラクチャ レイヤ: 物理的なコンピューティング、ネットワーキング、ストレージ ファブリック（例: A4X）。

2. サービング レイヤ: 特定のモデル アーキテクチャと最適化された実行カーネル（例: NVIDIA Dynamo、NVIDIA TensorRT-LLM、Pax）と、リクエスト スケジューリング、KV キャッシュの状態、分散コーディネーションを管理するランタイム環境。

3. オーケストレーション レイヤ: リソースのライフサイクル管理、スケーリング、フォールト トレランスのためのコントロール プレーン（例: Kubernetes）。

以下で詳述するリファレンス アーキテクチャでは、NVIDIA エコシステム向けに設計されたこのスタックの高パフォーマンス インスタンス化に焦点を当てています。インフラストラクチャ レイヤの A4X と、モデル サービング レイヤの NVIDIA Dynamo を組み合わせ、GKE でオーケストレートします。

インフラストラクチャ レイヤ: A4X ラックスケール アーキテクチャ

2025 年 2 月の A4X のリリースに関するお知らせで、スケジューラが利用できるトポロジを根本的に変化させる GB200 NVL72 アーキテクチャを実装することで A4X VM が帯域幅の制約をどのように解消したかについて説明しました。

NVLink ドメインがサーバー シャーシ（通常は 8 個の GPU）にバインドされていた旧世代とは異なり、A4X は統合ファブリックを提供します。このファブリックは、以下の特徴を備えています。

• 72 個の NVIDIA Blackwell GPU が NVLink Switch システムで相互接続され、統合共有メモリを備えた 1 つの巨大な GPU として動作します。

• 130 TB/秒の総帯域幅により、オンボード メモリへのアクセスに匹敵するレイテンシ プロファイル（72 個の GPU x 1.8 TB/秒/GPU）でオールツーオール通信が可能です。

• NVFP4 のネイティブ サポート: Blackwell Tensor Core は 4 ビット浮動小数点の適合率をサポートし、互換性のあるモデルレイヤの 8 ビット浮動小数点と比較してスループットを実質的に 2 倍にします。このベンチマークでは、以前に公開された結果と同じ構成で比較できるよう、8 ビット浮動小数点の適合率スケーリングを使用しました。

サービング レイヤ: NVIDIA Dynamo

この規模のハードウェアには、同期オーバーヘッドを発生させることなく分散状態を管理できるランタイムが必要です。NVIDIA Dynamo は、この分散推論ランタイムとして機能します。単純なモデル提供にとどまらず、基盤となるインフラストラクチャ全体で推論リクエストの複雑なライフサイクルを調整します。

サービング レイヤは、次のメカニズムを通じて A4X の使用率を最適化します。

1. Wide Expert Parallelism（WideEP）: 従来の MoE サービングでは、1 つのノード（通常は 8 個の GPU）内でエキスパートをシャード化するため、特定のエキスパートが「稼働」状態になると負荷の不均衡が生じます。Google は、A4X の統合ファブリックを使用して、72 個の GPU を搭載したラック全体にエキスパートを分散します。この WideEP 構成は、大規模なコンピューティング プール全体で負荷を分散することで、バースト性の高いエキスパート活性化パターンを吸収し、単一の GPU がストラグラーになるのを防ぎます。

2. Deep Expert Parallelism（DeepEP）: WideEP がエキスパートを分散するのに対し、DeepEP は重要な「分離」と「結合」の通信フェーズを最適化します。DeepEP は、割り当てられたエキスパートにトークンをルーティングするために必要な高帯域幅のオールツーオール オペレーションを高速化します。このアプローチにより、大規模な MoE 推論のボトルネックとなる同期オーバーヘッドを最小限に抑えます。

3. リクエスト処理の分離: Dynamo は、計算依存型のプレフィル フェーズとメモリ依存型のデコード フェーズを分離します。A4X では、スケジューラがラック内の特定の GPU グループをプレフィルに割り当て（Tensor コアの飽和度を最大化）、他の GPU がデコードを処理（メモリ帯域幅の使用率を最大化）することで、リソースの競合を防止できます。

4. グローバルな KV キャッシュ管理: Dynamo は KV キャッシュの状態のグローバル ビューを維持します。そのルーティング ロジックは、関連するコンテキストを保持する特定の GPU にリクエストを転送し、冗長な計算とキャッシュの移行を最小限に抑えます。

5. JIT カーネルの最適化: ランタイムは NVIDIA Blackwell 固有のカーネルを活用し、生成フェーズでジャストインタイムのオペレーション融合を実行してメモリアクセス オーバーヘッドを削減します。

オーケストレーション レイヤ: ソフトウェアとハードウェアのマッピング

A4X が物理的なファブリックを提供し、Dynamo がランタイム ロジックを提供する一方で、オーケストレーション レイヤはソフトウェア要件をハードウェア トポロジにマッピングする役割を担います。GB200 NVL72 のようなラックスケール アーキテクチャでは、コンテナ オーケストレーションは標準的なスケジューリングを超えて進化する必要があります。オーケストレーターが物理的な NVLink ドメインを明示的に認識できるようにすることで、プラットフォームのパフォーマンスを最大限に引き出し、ワークロードを最適な場所に配置できるようになります。

GKE は、次のメカニズムを通じて、ハードウェアとソフトウェアの整合性を確保します。

1. ラックレベルのアトミック スケジューリング: GB200 NVL72 では、「コンピューティングの単位」は単一の GPU や単一のノードではなく、ラック全体が高速コンピューティングの新たな基本的構成要素となります。Google は、特定のアフィニティ設定で GKE 容量予約を使用しています。これは、高密度なデプロイを保証する A4X インフラストラクチャの予約済みブロックを対象としています。この予約を使用することで、GKE は、Dynamo インスタンスを構成するすべての Pod が、NVLink ドメインを確立するために必要な特定の物理的に連続したラック ハードウェアに配置されるようにします。これにより、WideEP と DeepEP に必要なハード トポロジ保証が提供されます。

2. GCS FUSE による低レイテンシのモデル読み込み: 大規模な MoE モデルのサービングには、テラバイト単位の重みを高帯域幅メモリ（HBM）に読み込む必要があります。ローカル ディスクに重みをダウンロードする従来のアプローチでは、許容できない「コールド スタート」のレイテンシが発生します。GCS FUSE CSI ドライバを活用して、モデルの重みを Google Cloud Storage からローカル ファイル システムとして直接マウントします。これにより、Dynamo ランタイムはモデルを「遅延読み込み」し、データチャンクをオンデマンドで GPU メモリに直接ストリーミングできます。このアプローチでは事前ダウンロードのフェーズが不要になるため、新しい推論レプリカの準備が完了するまでの時間が大幅に短縮され、トラフィックの急増に対応した自動スケーリングがより迅速に行えるようになります。

3. カーネル バイパス ネットワーキング（GPUDirect RDMA）: A4X の合計 130 TB/秒の帯域幅を最大化するには、ネットワーキング スタックで CPU と I/O の関与を最小限に抑える必要があります。Titanium ネットワーク アダプタで GPUDirect RDMA を有効にするように GKE クラスタを構成します。特定の NCCL トポロジ構成を挿入し、コンテナで IPC_LOCK 機能を有効にすることで、アプリケーションが OS カーネルをバイパスし、GPU とネットワーク インターフェース間でダイレクト メモリ アクセス（DMA）オペレーションを実行できるようにします。この構成では、データパス管理から NVIDIA Grace CPU がオフロードされるため、高スループットのトークン生成時にネットワーク I/O がボトルネックになることはありません。

パフォーマンスの検証

2 つの異なる最適化目標で SGLang を使用して DeepSeek-R1（8 ビットの浮動小数点形式）で 8K / 1K ワークロードのスケーリング特性を評価したところ、次のことがわかりました。

1. スループットを最適化した構成

• 設定: DeepEP を使用する 72 個の GPU。5 ワーカー（TP8）の 10 個のプレフィル ノードと、1 ワーカー（TP32）の 8 個のデコード ノード。

• 結果: 6,000 超の合計トークン/秒/GPU（1,500 出力トークン/秒/GPU）を維持しました。これは、InferenceMAX が公開したパフォーマンス（ソース）と一致します。

2. レイテンシ最適化の構成

• 設定: DeepEP を使用しない 8 個の GPU（2 つのノード）。1 つのプレフィル ノードと 1 つのプレフィル ワーカー（TP4）、1 つのデコード ノードと 1 つのデコード ワーカー（TP4）。

• 結果: 同時実行数 4 で、中央値 10 ミリ秒のトークン間レイテンシ（ITL）を維持しました。これは、InferenceMAX が公開しているパフォーマンス（ソース）と一致します。

今後の対応

モデルが静的なチャット インターフェースから複雑なマルチターンの推論エージェントへと進化するにつれて、推論インフラストラクチャの要件は変化し続けます。Google は、AI 推論スタックの 3 つのレイヤすべてに投資してこれらの需要に対応しており、ベンチマークとレシピを積極的に更新、リリースしています。

• インフラストラクチャ レイヤ: 最近リリースされた A4X Max は、単一の 72 GPU ラック構成の NVIDIA GB300 NVL72 をベースとしており、A4X と比較して 1.5 倍の NVFP4 FLOP、1.5 倍の GPU メモリ、2 倍のネットワーク帯域幅を実現します。

• サービング レイヤ: Google は、KV Block Manager と Google Cloud リモート ストレージのペアリング、Dynamo 指標の Cloud Monitoring ダッシュボードへの取り込みによるオブザーバビリティの強化、GKE カスタム コンピューティング クラス（CCC）の活用による容量と可用性の向上、FP4 適合率による新しいベースラインの設定など、NVIDIA Dynamo のコンポーネントとのより深い統合を積極的に検討しています。

• オーケストレーション: llm-d の明確なパスで確立された設計パターンに準拠し、インテリジェントな推論スケジューリング コンポーネントである推論ゲートウェイなど、追加の最適化をこれらのテストに組み込む予定です。Google は、高度なトラフィック オーケストレーションのための集中型メカニズムを提供することを目指しています。このメカニズムは、ワークロードがサービング レイヤのランタイムに到達する前に、リクエストの優先順位付け、キューイング、マルチモデル ルーティングを処理します。

大規模な MoE モデルをデプロイする場合でも、次世代の推論エージェントを設計する場合でも、このスタックは、最先端の研究を本番環境で実現するために必要なエクサスケールの基盤を提供します。

使ってみる

Google は、お客様の AI ワークロード向けに、最もオープンで柔軟かつ高性能なインフラストラクチャを提供することに取り組んでいます。インテリジェントなルーティングとスケーリングから最新の NVIDIA AI インフラストラクチャまで、NVIDIA Dynamo スイートを完全にサポートすることで、LLM の大規模なサービングを可能にするプロダクション レディな完全ソリューションを提供します。

A4X マシンクラスの 2 つの具体的なレシピでデプロイ リポジトリを更新しました。

• スループット最適化のレシピ - DeepEP を使用した 72 個の GPU

• レイテンシ最適化のレシピ - DeepEP を使用しない 8 個の GPU

皆様がどのようなものを構築されるか楽しみにしております。

-プロダクト マネージャー、Sean Horgan

-ソフトウェア エンジニア、Ling Lin