コンテンツに移動
ネットワーキング

Google のスケールアウト AI データセンター ファブリック、Virgo Network のご紹介

2026年4月22日
https://storage.googleapis.com/gweb-cloudblog-publish/images/GCN26_102_BlogHeader_2436x1200_Opt_2_Dark.max-2500x2500.jpg
Benny Siman-Tov

Senior Director Product Management

Arjun Singh

Engineering Fellow, Google Cloud

Try Gemini Enterprise Business Edition today

The front door to AI in the workplace

Try now

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

AI 時代には、物理的なクラウド アーキテクチャを根本から見直す必要があります。特にネットワーキングはその中心です。基盤モデルのパラメータ数が指数関数的に増加するなか、従来の汎用ネットワークは限界に近づいています。今後 10 年の ML を支えるために、Google は「キャンパス全体を 1 台のコンピュータとして捉える」という考え方に基づく、新たなメガスケール AI データセンター ファブリック Virgo Network を設計しました。これは Google の AI Hypercomputer を支える基盤でもあります。

従来型のネットワーク設計では、最新の AI が求める要件の一部に対応しきれません。

  1. 大規模化: トレーニング需要はすでに単一データセンターの電力や設置スペースの限界を超えており、複数のデータセンターをまたぐ統合ドメインが必要になっています。

  2. 帯域幅需要の急増: 基盤モデルのトレーニングはネットワーク依存度が非常に高いため、アクセラレータ 1 基あたりに必要な帯域幅はここ数年で大幅に増加しています。その結果、旧来のアーキテクチャではスループット不足や輻輳がボトルネックになっています。

  3. 同期バースト: ミリ秒単位で発生する激しいトラフィック スパイク(図 1)は、ネットワーク バッファに大きな負荷をかけます。その結果、たった 1 つの「処理の遅い」ノードがクラスタ全体の性能を抑えてしまうことがあります。

  4. 低レイテンシ: ML サービングでは、リアルタイム推論を実現するために、高速かつ安定した応答時間が求められます。そのため、厳格なレイテンシ制御がアーキテクチャ設計上の重要な要件になります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_Sub-millisecond_line-rate_bursts_of_an_A.max-1700x1700.png

図 1: AI トレーニング ワークロードで発生するサブミリ秒のラインレート バースト

データセンター ネットワークの再構築

AI 時代の要求に応えるには、汎用的なネットワーク設計から脱却し、フラットで低レイテンシな専用ネットワーク アーキテクチャへと大きく転換する必要があります。こうした固有のスケール要件とレイテンシ要件に対応するため、Google は north-south トラフィックには実績のある Jupiter ネットワークを活用し、east-west 通信には新たなファブリックを導入しました。その結果、3 つの異なる専用レイヤで構成されるアーキテクチャが、1 つの統合コンピューティング ドメインとして機能します。

  1. スケールアップ ドメイン: 単一 Pod 内のアクセラレータ間で、密接に連携した通信を行うために設計された、高帯域幅 / 低レイテンシの相互接続ファブリック。

  2. スケールアウト アクセラレータ ファブリック(East-West): Pod をまたいだ大規模な水平スケーリングに最適化された、アクセラレータ間の専用 RDMA(Remote Direct Memory Access)ファブリック。このレイヤは、決定論的なレイテンシと高い耐障害性を実現するよう設計されており、ML ワークロードに高い「実効スループット」を提供します。

  3. Jupiter フロントエンド ネットワーク(north-south): 分散ストレージや汎用コンピューティング リソースに対して、高速かつ信頼性の高いアクセスを提供する大容量ファブリック。これにより、データアクセスがトレーニングやサービング ワークロードのボトルネックになるのを防ぎます。また、非常に大規模なトレーニング実行に向けて、複数サイトにまたがるスケーリングにも使用されます。

このようにアーキテクチャを分離することで、次のような重要な戦略的メリットが得られます。

  1. 独立した進化: 各ネットワーク ドメインを個別に進化およびアップグレードできるため、システム全体への影響を抑えながら、イノベーションのサイクルを加速できます。

  2. 専用のスケールアウト帯域幅: ノンブロッキング ネットワークにより、重要なトレーニング タスクに必要な大規模なバイセクション帯域幅をアクセラレータに提供できます。

  3. ML とネットワークの協調設計: ネットワークは、ML アクセラレータの各世代に合わせて並行して設計されるため、対応するハードウェアに最適化されたファブリックを実現できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_Data_center_network_architecture.max-1500x1500.png

図 2: データセンター ネットワークのアーキテクチャ

Virgo Network の紹介: メガスケール データセンター ファブリック

Virgo Network は、現代の AI ワークロードが求める極めて厳しい要件に応えるために設計されたスケールアウト ファブリックです。1 台のスイッチでより多くのポートを扱える高ラディックス スイッチを採用することでネットワーク階層を削減し、フラットな 2 層構成のノンブロッキング トポロジを実現しています。これにより、従来のデータセンター ネットワークと比べてネットワーク階層が最小限に抑えられ、レイテンシを大幅に低減できます。さらに、アクセラレータを接続するために、独立した制御ドメインを備えたマルチプレーン設計を採用しています(図 3)。アクセラレータ ラックは、コンピューティング サービスやストレージ サービスにアクセスするため、Jupiter の north-south ファブリックにも接続されます。こうしたシンプルで最適化されたアーキテクチャにより、分散トレーニングとサービングの両方に必要な、巨大なバイセクション帯域幅と、予測可能な低レイテンシを実現しています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_Megascale_data_center_fabric_Virgo_Netwo.max-1600x1600.png

図 3: メガスケール データセンター ファブリック(Virgo Network)

Virgo Network は、Google の次世代アクセラレータ設計を支える基盤であり、次のような利点があります。

  • 大規模なファブリック スケール: Virgo Network は、単一ファブリック内で 134,000 個のチップ(TPU 8t)を接続し、最大 47 ペタビット/秒のノンブロッキング バイセクション帯域幅を実現できます。

  • 世代をまたぐ性能向上: 前世代と比べて、アクセラレータ(TPU 8t)あたり最大 4 倍の帯域幅を提供し、各チップの性能を最大限に引き出します。

  • 予測可能な低レイテンシ: TPU における無負荷時のファブリック レイテンシを前世代比で 40% 低減し、レイテンシの影響を受けやすい AI ワークロードでも、より安定して予測しやすいパフォーマンスを実現します。

大規模環境における信頼性の向上

数十万個のチップを支えるシステムでは、ハードウェア障害は避けられません。しかも、1 つの不良コンポーネントが同期型のトレーニング ジョブ全体に影響を及ぼす可能性があるため、この規模では信頼性の確保が最重要課題の一つになります。ワークロードの実効スループットを最大化するため、Google は Virgo Network のアーキテクチャを、障害の切り分け、高度な可観測性、そしてハングやストラグラーへの迅速な対処を中心に設計しました。

この規模では、システム全体のレジリエンスを支える強固なネットワーク基盤が欠かせません。Virgo Network は、独立したスイッチング プレーンを組み込むことで高い障害分離性を実現し、局所的なハードウェア障害によってクラスタ全体の実効スループットが損なわれないよう保護します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_How_fail-stop_and_fail-slow_impact_MTTR.max-1600x1600.png

図 4: fail-stop と fail-slow が MTTR に与える影響

この基盤の上で、Google はソフトウェアとオーケストレーション スタックも最適化し、主に次の 2 つの領域を通じて、平均中断間隔(MTBI)の最大化と平均復旧時間(MTTR)の最小化を図っています。

  • オブザーバビリティ: この規模で信頼性を確保するには、高精度な可視化が不可欠です。Google はサブミリ秒単位のテレメトリーを利用してネットワーク システムをモニタリングしています。このきめ細かな可視性により、一時的な輻輳の検知、バッファ管理の最適化、さらにハードウェアとソフトウェアのスタック全体にまたがる性能低下の根本原因の特定が可能になります。

  • ストラグラーとハングの検出: 性能が低下しているノード(ストラグラー)や、応答が完全に停止したノード(ハング)を特定するには、先回りしたモニタリングが不可欠です。自動化されたストラグラー検出と、新たに追加されたハング検出によって、こうしたボトルネックを迅速に特定し、トレーニング ジョブを加速させるとともに、局所的な性能低下の影響から保護します。

AI Hypercomputer の基盤

Virgo Network は、現代の AI ワークロードが求める厳しい要件に対応するために専用設計された、新しいスケールアウト型データセンターネットワークです。このフラットでマルチプレーンなアーキテクチャにより、Pod をまたいでアクセラレータを 1 つのコンピューティング ドメインに統合し、従来型ネットワークの帯域幅やスケーラビリティの限界を克服します。さらに、ハードウェア レベルで高い障害分離性を実現することで、Virgo Network はシステム全体のレジリエンスを支える基盤となり、同期型ワークロードを局所的なハードウェア障害から守ります。

最終的に、Virgo Network は、エージェント型 AI の時代を加速させるために必要なスケール、予測可能なレイテンシ、そして高い信頼性を提供します。AI の未来を支えるインフラストラクチャの構築についてさらに詳しく知りたい方は、 AI インフラストラクチャ ソリューションのページ技術ドキュメントをご覧いただくか、Google Cloud Next の専用ブレイクアウト セッションにご参加ください。

- プロダクト管理担当シニア ディレクター、Benny Siman-Tov

- エンジニアリング フェロー、Arjun Singh

投稿先