コンテンツに移動
コンピューティング

第 8 世代 TPU の内幕: アーキテクチャの詳細

2026年4月30日
https://storage.googleapis.com/gweb-cloudblog-publish/images/eighth-generation_TPU.max-2000x2000.jpg
Diwakar Gupta

Distinguished Engineer, Google Cloud

Sabastian Mugazambi

Group Product Manager, Google Cloud

Try Gemini Enterprise Business Edition today

The front door to AI in the workplace

Try now

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

Google の TPU 設計理念では、常にスケーラビリティ、信頼性、効率性という 3 つの柱が中心に据えられてきました。AI モデルが高密度大規模言語モデル(LLM)から大規模な混合エキスパート(MoE)や推論重視のアーキテクチャへと進化するにつれて、ハードウェアは 1 秒あたりの浮動小数点演算(FLOPS)を増やすだけでなく、最新のワークロードに固有の演算強度に対応できるように進化する必要に迫られています。

エージェント型 AI の台頭により、長いコンテキスト ウィンドウと複雑な逐次ロジックを処理できるインフラストラクチャが必要になっています。同時に、現在のデータ アーキテクチャの次に必要となる進化として「世界モデル」が登場しています。つまり新しいエージェントは、リスクを伴う試行錯誤ではなく「想像力」を通じて、将来のシナリオをシミュレートし、結果を予測し、学習するものとなっています。第 8 世代 TPU(TPU 8t と TPU 8i)は、上述の課題に対する Google の答えです。すべてのワークロードが、トレーニングの最初のトークンからマルチターン推論チェーンの最終ステップまで可能な限り最も効率的なパスで実行されるようにします。TPU 8t と TPU 8i は Google DeepMind の Genie 3 のような世界モデルを効率的にトレーニングしてサービングできるように構築されているため、数百万のエージェントが多様なシミュレーション環境で推論をトレーニングして改良していくことができます。

TPU 8: 特化された設計

事前トレーニング、トレーニング後、リアルタイム サービングのインフラストラクチャ要件はそれぞれ異なることを踏まえ、第 8 世代 TPU では TPU 8t と TPU 8i という 2 つの異なるシステムを導入しています。これらの新しいシステムは、AI Hypercomputer という、ハードウェア、ソフトウェア、ネットワーキングを 1 つに統合して AI ライフサイクル全体を強化する Google Cloud のスーパーコンピューティング アーキテクチャの重要なコンポーネントになります。TPU 8t と TPU 8i のどちらのシステムも、Google AI スタックのコア DNA を共有して、AI ライフサイクル全体をサポートしますが、それぞれが対処するボトルネックと、効率の最適化を図る開発の段階は異なります。これに加え、第 8 世代 TPU システム全体に Arm ベースの Axion CPU ヘッダーを統合し、データ準備のレイテンシによって発生するホストのボトルネックを解消しました。Axion は、複雑なデータの前処理とオーケストレーションを処理するためのコンピューティング ヘッドルームを提供するため、TPU は常にフィードされた状態に維持されて、停止することがありません。

TPU 8t: 事前トレーニングの原動力

大規模な事前トレーニングとエンベディングを多用するワークロード向けに最適化された TPU 8t は、実績のある 3D トーラス型ネットワーク トポロジを、1 つの Superpod で 9,600 個のチップというさらに大きなスケールで活用しています。TPU 8t は、トレーニングがスケジュールどおりに実行されるように、数百規模の Superpod 全体にわたって最大限のスループットを実現するように設計されています。

TPU 8t は、前世代の TPU と比較して次のような点で進化しています。

  • SparseCore の利用: TPU 8t の中核となっている SparseCore は、エンベディング検索の不規則なメモリアクセス パターンを処理するために設計された専用のアクセラレータです。行列乗算ユニット(MXU)が行列演算を処理する一方で、SparseCore はデータ依存の all-gather 演算を他の集団演算とともにオフロードして、汎用チップでよく問題となるゼロ演算におけるボトルネックを回避します。

  • VPU / MXU のオーバーラップとバランスの取れたスケーリング: TPU 8t は、プロビジョニングされた FLOP の使用率を最大化するように設計されています。このアーキテクチャは、よりバランスの取れた Vector Processing Unit(VPU)のスケーリングを実装することで、ベクトル演算の時間を最小限に抑えます。これにより、量子化、softmax、レイヤ正規化を MXU での行列乗算と効果的に重ねられるようになるため、チップは順次ベクトルタスクを待つことなく、常にビジー状態を維持します。

  • ネイティブ FP4: TPU 8t では、メモリ帯域幅のボトルネックを克服するためにネイティブ 4 ビット浮動小数点(FP4)を導入しています。FP4 の導入により、低精度の量子化でも大規模モデルの精度を維持しながら MXU のスループットを倍増させています。パラメータあたりのビット数を減らすことで、プラットフォームでのエネルギー消費量の多いデータ移動が最小限に抑えられ、コンピューティングのピーク使用率に対応するローカル ハードウェア バッファに、より大きなモデルレイヤを収められるようになります。

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

図 1: TPU 8t ASIC のブロック図

  • Virgo Network トポロジと最大 4 倍のデータセンター ネットワークの増加: TPU 8t の膨大なデータ要件をサポートするために、Virgo Network を導入しました。この新しいネットワーキング アーキテクチャにより、データセンター ネットワーク(DCN)を介した TPU 8t トレーニングでの DCN 帯域幅が最大 4 倍に増加しています。Virgo Network は、最新の AI ワークロードに伴う極めて厳しい要件に対応するように設計されたスケールアウト ファブリックです。Virgo Network は高基数スイッチを基盤としているため、スイッチあたりのポート数を増やしてネットワーク レイヤの数を削減できます。このことから、Virgo Network ではフラットな 2 レイヤのノンブロッキング トポロジを採用しています。このようにネットワーク階層を最小限に抑えることで、従来のデータセンター ネットワークと比べ、レイテンシが大幅に短縮されます。Virgo Network の特徴となっているのは、独立した複数の制御ドメインで TPU 8t チップを接続する、マルチプレーン設計です。コンピューティング サービスとストレージ サービスにアクセスするために、TPU 8t ラックは Jupiter の North-South ファブリックにも接続されます。この合理化されたアーキテクチャは、世界最大のトレーニング クラスタを、しかも高可用性を確保した状態で実現するために必要となる、大規模な二分割帯域幅と確定的低レイテンシを提供します。

前世代比で、チップ間相互接続(ICI)のスケールアップ帯域幅が 2 倍、スケールアウト DCN 帯域幅が最大 4 倍の TPU 8t は、データ ボトルネックを大幅に削減します。さらに、フロンティア モデルの開発を加速するために、Google は単一のクラスタの枠を超えて分散トレーニングをスケールできるようにしています。具体的には、JAXPathways を組み合わせることで、単一のトレーニング クラスタ内で 100 万個を超える TPU チップに対してスケーリングを提供できるようになりました。Virgo Network では、1 つのファブリックで 134,000 個以上の TPU 8t チップをリンクして、最大 47 ペタビット/秒のノンブロッキング二分割帯域幅を使用できます。この場合のファブリックは、160 万エクサフロップスを超える演算能力を、ほぼ線形なスケーリング性能で提供します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_TPU_8t_rack_level_connectivity_to_Virgo_.max-2000x2000.png

図 2: TPU 8t ラックレベルでの Virgo ファブリックへの接続

  • ストレージ アクセスの高速化: TPU 8t には TPUDirect RDMATPUDirect Storage を導入しています。TPUDirect RDMA を使用すると、ホスト CPU と DRAM をバイパスして、TPU のメモリ(HBM)とネットワーク インターフェース カード(NIC)の間でデータを直接転送できます。これにより、レイテンシとホストシステムのボトルネックが低減されて、TPU 間通信の有効帯域幅が増加します。同様に、TPUDirect Storage は CPU ホストのボトルネックを回避するために、TPU と 10T Lustre などの高速マネージド ストレージ間の直接メモリアクセスを可能にします。したがって、大量のデータを転送する場合は帯域幅が実質的に倍増します。このアーキテクチャでは、シリコンがトレーニング データをラインレートで取り込めることから、大規模なマルチモーダル データセットを処理する場合でも。MXU は完全に飽和した状態に維持されます。

数百ペタバイトのデータセットを直接シリコンにルーティングするために Managed Lustre 10T と TPUDirect Storage を組み合わせることで、TPU 8t はデータ取り込みのボトルネックによって発生するトレーニングの遅延を防ぎます。これにより、第 7 世代の Ironwood TPU でトレーニングする場合と比較して、ストレージ アクセスが 10 倍高速化されます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_rq0yjyX.max-2000x2000.png

図 3: 上の図は、TPUDirect Storage を使用しない場合のデータ転送パスを示しています。下の図は、TPUDirect Storage を使用した場合の 2 つの TPU 8t チップ間の TPU 8t データ転送と、Managed Lustre 10T ストレージを使用した TPUDirect Storage を示しています。

TPU 8i: サンプリングとサービングのスペシャリスト

トレーニング後の高度な並列推論向けに最適化された TPU 8i は、Google の最高水準のオンチップ SRAM、新しい Collectives Acceleration Engine(CAE)と、Boardfly と呼ばれる、サービングに最適化されたネットワーク トポロジを使用して設計されています。

  • 大容量のオンチップ SRAM: 前世代比で 3 倍のオンチップ SRAM を搭載した TPU 8i は、より大きな KV キャッシュを完全にシリコン上でホストできるため、ロングコンテキストのデコード中に発生するコアのアイドル時間を大幅に短縮できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_v1_nUZDsJM.max-1800x1800.png

図 4: TPU 8i ASIC のブロック図

  • Collectives Acceleration Engine(CAE): TPU 8i は サンプリングのボトルネックを解消するために CAE を使用します。CAE は、特に自己回帰デコードと「chain-of-thought」処理で必要となる集約ステップと同期ステップを加速して、コア全体の結果をほぼゼロのレイテンシで集約します。各 TPU 8i チップには、コアダイ上に 2 つの Tensor Core(TC)と、チップレット ダイ上に 1 つの CAE があります。これらは、前世代の Ironwood TPU で使用されているコアダイ上の 4 つの SparseCore(SC)に代わるものです。TPU 8i は、専用の CAE を統合することで、集団演算のオンチップ レイテンシをさらに 5 分の 1 に短縮しています。集団演算あたりのレイテンシが短縮されるということは、待機時間が短縮されることを意味します。これは、数百万のエージェントを同時に実行するために必要なスループットの向上に直接つながります。

  • Boardfly ICI トポロジ: 3D トーラスでは、数千個のチップを接続して 1 つの集合体として使用できますが、大規模なメッシュではチップ間のホップ数が多くなり、全対全レイテンシが高くなります。8i では、複数のチップが全結合ボードで接続され、こうしたボードがグループに集約されるという仕組みを変更しました。高基数設計を採用して、最大 1,152 個のチップを接続することで、ネットワーク直径と、データパケットがシステムを通過するために必要なホップ数を削減しています。全対全通信(MoE モデルと推論モデルの中核)に必要となるホップ数を大幅に削減する Boardfly は、通信集約型のワークロードのレイテンシを最大 50% 短縮します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/5_I1mUzjb.max-1300x1300.png

図 5: TPU 8i の階層的な Boardfly トポロジ。4 つの全結合チップを構成要素とし、8 枚のボードで構成される全結合グループへと拡張。これらのグループ 36 個を全結合することで、1 つの TPU 8i ポッドを構成

Boardfly は次の要素で構成されており、そのトポロジは本質的に階層型です。

  • 構成要素(BB): 各トレイは内部 ICI リンクを使用して 4 チップからなるリングを形成し、より広範なネットワーキングに対応するための 16 個の外部接続を提供します。

  • グループ(G): 8 枚のボードが銅線ケーブルで全結合されて、ローカル グループが作成されます。グループ内の通信には、利用可能な外部リンクのうち 11 個が使用されます。

  • Pod 構造: 最終的なアーキテクチャは、光回路スイッチ(OCS)を介してリンクされた 36 のグループ(最大 1,024 個のアクティブなチップ)にスケールします。どのチップ間の通信でも、最大レイテンシは 7 ホップ分となります。

詳細: Boardfly とトーラスの数学

TPU 8i でトーラスから移行している理由は、突き詰めるところ、ネットワーク直径にあります。

3D トーラスでノードが配置されるグリッドでは、各次元がリングのように折り返されます。8 x 8 x 16(1,024 チップ)構成で最も遠いチップに到達するには、パケットが各リングの半分の距離を移動する必要があります。

3D トーラス = 8/2(X)+ 8/2(Y)+ 16/2(Z)= 16 ホップ

トーラスは、高密度なトレーニングに通常伴う隣接ノード間の通信には非常に効率的ですが、全対全の通信パターンではレイテンシが犠牲になります。推論モデルと MoE の時代では、トークンをルーティングするために、どのチップも他のいずれかのチップと通信する可能性があるため、ホップ数が重要になります。

Boardfly の高基数トポロジは、Dragonfly トポロジの原則にヒントを得たものです。Google はボードのグループ間を直接結ぶ長距離の光リンクの数を増やすという方法で、ネットワークをフラット化しています。同じ 1,024 チップの Pod の場合、Boardfly はネットワーク直径を 16 ホップからわずか 7 ホップにまで削減します。

ネットワーク直径が 56% 縮小するということは、テール レイテンシが短縮されることに直接つながるため、TPU 8i CAE はデータがポッド経由で到着するのを待機する必要がなくなります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/6_Qu7H2lI.max-1300x1300.png

図 6: TPU 8i Pod の光回路スイッチを介した最大 7 ホップの ICI ネットワーク直径の視覚的表現

TPU 8t と TPU 8i の概要

機能

TPU 8t

TPU 8i

主なワークロード

大規模な事前トレーニング

サンプリング、サービング、推論

ネットワーク トポロジ

3D トーラス

Boardfly 

専用チップの機能

SparseCore(エンベディング)と LLM デコーダ エンジン

CAE(Collectives Acceleration Engine)

HBM 容量

216 GB

288 GB

オンチップ SRAM(Vmem)

128 MB

384 MB

ピーク FP4 PFLOPS

12.6

10.1

HBM 帯域幅

6,528 GB/秒

8,601 GB/秒(TPU 8t の約 1.3 倍)

CPU ヘッダー

Arm Axion

Arm Axion

ソフトウェアの有効化: パフォーマンス重視の AI スタック

ハードウェアの性能は、それを動かすソフトウェアの性能に左右されます。第 8 世代の TPU は、第 7 世代の Ironwood TPU で Google が先駆けて開発したパフォーマンス重視のスタックを基盤に構築されています。このスタックは、高レベルのフレームワークの抽象化を犠牲にすることなく、カスタム カーネルを容易に開発できるように設計されたものです。このスタックには以下が含まれます。

  • Pallas と Mosaic: Google は、Python でハードウェア対応のカーネルを記述できる Pallas というカスタム カーネル言語に対するトップクラスのサポートを提供しています。これにより、TPU 8i CAE と TPU 8t SparseCore のパフォーマンスを最大限に引き出すことができます。

  • ネイティブな PyTorch エクスペリエンス: このたび、TPU のネイティブな PyTorch サポートのプレビュー版が公開されました。現在 PyTorch でモデルを構築してサービングしている場合は、これまで以上に簡単に TPU の使用を開始できます。お客様が利用しているネイティブ機能(イーガーモードなど)を完全にサポートした状態で、既存のモデルをそのまま Google の TPU に移行できます。

  • ポータビリティ: Ironwood で実行される JAX、PyTorch、Keras のコードは、第 8 世代の TPU にスケールします。XLA(Accelerated Linear Algebra)は、Broadly トポロジと CAE 同期の複雑な変換を舞台裏で処理するため、ユーザーは相互接続ではなくモデルに注力できます。

世代を重ねるごとにパフォーマンスが大幅に向上しています

ハードウェアとソフトウェアを共同設計するという Google の取り組みは、引き続き成果を上げています。第 7 世代の Ironwood TPU と比較して、第 8 世代の TPU では次のような大きな改善が見られます。

  • トレーニングの費用対効果: 大規模なトレーニングにおける TPU 8t の 1 ドルあたりのパフォーマンスは、Ironwood TPU のパフォーマンスの最大 2.7 倍です。

  • 推論の費用対効果: 特に大規模な MoE モデルの低レイテンシ ターゲットにおける TPU 8i の 1 ドルあたりのパフォーマンスは、Ironwood TPU と比べると、最大 80% 向上します。

  • エネルギー効率: どちらのチップでも、ワットあたりのパフォーマンスが最大 2 倍向上しています。次世代 AI をサステナブルにスケーリングするうえで、これら 2 つのチップは不可欠と言えます。

今後の対応

Google Cloud のお客様がイノベーションの新たな波を切り開けるよう、Google は TPU 8t と TPU 8i を、AI ライフサイクルの多面的な将来の需要に合わせてカスタマイズされた 2 つの異なる専用システムとして開発しました。TPU 8t と 8i はそれぞれ、最も要求の厳しいトレーニング ワークロード専用、サービングワークロード専用に構築されており、AI Hypercomputer のソフトウェア スタック(JAX、PyTorch、vLLM、XLA、Pathways)と完全に統合されています。Google DeepMind との緊密なコラボレーションにより、目的に特化してゼロから再設計された第 8 世代の TPU は、卓越したコスト パフォーマンスと電力効率を実現します。

第 8 世代アーキテクチャのモジュール性は、将来に向けた明確な、かつ固有のロードマップを可能にします。コンピューティング環境の大きな変化にはインフラストラクチャのブレークスルーが必要でしたが、エージェントの時代も同じです。継続的なフィードバック ループ内で計画、実行、学習を行う推論エージェントは、元々従来のトレーニングやトランザクション推論用に最適化されているハードウェアでは、最高の効率で動作できません。その動作強度は根本的に異なるからです。第 8 世代の TPU インフラストラクチャは、こうした固有の要件に真っ向から対処できるように進化しています。

第 8 世代 TPU ファミリーについて、以下の方法で詳細をご確認ください。

- Google Cloud、上級エンジニア、Diwakar Gupta

- Google Cloud、グループ プロダクト マネージャー、Sabastian Mugazambi

投稿先