TPUs

TPU 上で兆単位のパラメータを扱うモデルのクラスタレベルの信頼性

Thu, 04 Jun 2026 00:00:00 +0000

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

フロンティア AI モデルにより、コンピューティングの単位が大きく変化しています。数兆パラメータ規模の AI トレーニングでは、数千もの相互接続されたコンポーネントが、産業規模のデプロイメントでオーケストレートされ、単一の巨大なエンティティとして動作する必要があります。

同様に、信頼性に関しては、インフラストラクチャの総合的な可用性が重要です。しかし、これまで 20 年近くにわたり、インスタンスレベルの信頼性がクラウドの標準になっていました。インスタンスレベルの信頼性は、マイクロサービスと水平方向にスケーラブルなアプリケーション向けに設計されており、独立した小さなユニットの集合としてインフラストラクチャを扱います。このモデルは、大規模な AI ワークロードには根本的に不十分です。

Google は、信頼性をインスタンスレベルからクラスタレベルのモデルに移行する必要があると考えています。

Google は 10 年以上にわたり、Tensor Processing Unit（TPU）クラスタを大規模に運用し、最新の AI ワークロードのアーキテクチャ要件を満たす信頼性を実現してきました。このブログ記事では、Superpod レベルでの集合的なパフォーマンスに焦点を当てた、Google Cloud TPU のクラスタレベルの信頼性フレームワークをご紹介します。このフレームワークは、Google 社内で世界最先端の AI モデルを構築するために使用しているものです。現在、本番環境で使用している TPU の運用標準であり、先日発表された第 8 世代 TPU のアーキテクチャのブループリントとして機能しています。

AI スーパーコンピュータの信頼性

TPU の Superpod では、数千個のチップがキューブ（64 個の TPU）に編成されています。高速チップ間相互接続（ICI）リンクがキューブ内のすべてのチップを接続し、動的に構成可能な光回路スイッチ（OCS）ネットワークがすべてのキューブを接続して Superpod を形成しています。

システム全体のトレーニングの進行のためには、Superpod 内で完全に正常なキューブの数を最大化する必要があります。AI モデルのパフォーマンスは高帯域幅で低レイテンシの通信に依存するため、あるユニットがトレーニングの進行に貢献するには、キューブ内のすべてのチップと ICI リンクが動作可能な状態にある必要があります。こうしたアーキテクチャの現実を踏まえ、Google のクラスタレベルのフレームワークは、業界がインスタンスレベルの信頼性から大規模な可用性へと移行し、この AI 時代にどのように信頼性を実現できるかを定義するのに役立ちます。

詳細: 大規模な可用性の計算

インスタンスレベルの信頼性モデルは多くの場合、決定的ですが、産業規模の AI デプロイメントでは、数千個のチップにわたる確率的アプローチが必要です。従来の設定では、単一のチップの平均故障間隔（MTBF）を追跡していたかもしれません。しかし、フロンティア AI の規模では、コンポーネントの数が増えるにつれてクラスタレベルの MTBF が急激に低下します。

スケーリングによって信頼性がどれほど早く損なわれるかを可視化するには、マルコフの不等式のような単純な上限を確認できます。

障害が発生したキューブ数を X と定義した場合、マルコフの不等式からわかることは、クラスタサイズとともに予想される障害数 E[X] が増加したときに、システム的なアーキテクチャの変更なしでは、厳格な障害の基準を下回る確率を保証することが、ますます困難になるということです。

マルコフの不等式は、大規模なリスクについて有用な経験則を提供しますが、Google は、大規模な可用性を、クラスタの総合的な健全性の二項分布を使用してモデル化しています。n 個の独立したユニット（キューブ）から構成される Superpod で、k 個以上のキューブが完全に動作し、相互接続される確率を、n 個の独立した試行の成功の累積分布として定義します。トレーニングの生産性において 95% の信頼区間を確保するには、次の式で k を求めます。

ここで、n は Superpod 内の合計キューブ数を表し、p はキューブレベルの総合的な可用性を表します。

このモデルにより、インスタンスレベルのモデルが、大規模トレーニングの実際のパフォーマンス要件を反映するトポロジ対応フレームワークに置き換わります。このため、より大きなコンピューティングブロックが正常な状態で接続され、継続的なトレーニングの進行を促進できるようになります。

ML の生産性向上

グッドプット指標は、ML 生産性の主要な尺度です。信頼性における Google の新しい標準は、グッドプットの決定的な基盤を提供し、要求の厳しいヒーロージョブでこの指標を最大化するように設計されています。これにより、最先端の研究に必要な大規模なインフラストラクチャが単一のエンティティとして機能することが可能となります。

このモデルは、大規模なトレーニング実行にリソースのフルセットを利用できるようにすることで、3 つのグッドプット指標の一つであるスケジューリンググッドプットで高い値を実現します。このインフラストラクチャレベルの可用性とソフトウェアスタックを組み合わせることで、全体的なグッドプットを向上させることができます。Google は、次の 3 層から構成される信頼性モデルを通じてこれを実現しています。

インフラストラクチャ: TPU Superpod が、必要な規模を物理的に利用可能にして接続するための容量フットプリントを提供します。
フレームワーク: JAX と Pathways がレジリエンスを提供します。障害が発生したノードを再構成またはホットスワップして、完全な再起動を必要とせずに前進を維持します。
アプリケーション: 自動チェックポイントやマルチティアチェックポイントなどのフォールトトレランスメカニズムにより、トレーニングの状態が保持されるため、障害が発生した場合に失われる進行分を最小限に抑えることができます。

次世代の AI ブレークスルーを実現

クラスタレベルの信頼性モデルは、AI 時代の新しい標準の始まりを示しています。今後は、AI スーパーコンピュータが、イノベーションのための信頼できる産業規模のエンジンとなるでしょう。Google は、その信頼性に対するスタンスを、フロンティアモデルのニーズに合わせることで、次世代の AI ブレークスルーをより迅速で、より信頼性が高く、より予測可能なものにしています。TPU の詳細を確認して利用を開始するには、こちらをクリックしてください。

- シニアスタッフソフトウェアエンジニア、Akshay Vasudev

- グループプロダクトマネージャー、Mohan Pichika

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

Thu, 30 Apr 2026 01:40:00 +0000

※この投稿は米国時間 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 のスループットを倍増させています。パラメータあたりのビット数を減らすことで、プラットフォームでのエネルギー消費量の多いデータ移動が最小限に抑えられ、コンピューティングのピーク使用率に対応するローカルハードウェアバッファに、より大きなモデルレイヤを収められるようになります。

図 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 は単一のクラスタの枠を超えて分散トレーニングをスケールできるようにしています。具体的には、JAX と Pathways を組み合わせることで、単一のトレーニングクラスタ内で 100 万個を超える TPU チップに対してスケーリングを提供できるようになりました。Virgo Network では、1 つのファブリックで 134,000 個以上の TPU 8t チップをリンクして、最大 47 ペタビット/秒のノンブロッキング二分割帯域幅を使用できます。この場合のファブリックは、160 万エクサフロップスを超える演算能力を、ほぼ線形なスケーリング性能で提供します。

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

ストレージアクセスの高速化: TPU 8t には TPUDirect RDMA と TPUDirect 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 倍高速化されます。

図 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 キャッシュを完全にシリコン上でホストできるため、ロングコンテキストのデコード中に発生するコアのアイドル時間を大幅に短縮できます。

図 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% 短縮します。

図 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 はデータがポッド経由で到着するのを待機する必要がなくなります。

図 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

Google AI インフラストラクチャの次なる展開：エージェンティック時代に向けたスケーリング

Thu, 23 Apr 2026 02:00:00 +0000

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

AI は、質問に答える段階から、高度な推論を行い、タスクを実行する段階へと進化しています。今日のエージェンティック時代を牽引する企業には、これらの新しい要件に合わせて設計、最適化されたコンピューティングインフラストラクチャが必要です。本日、Google Cloud Next ‘26 において、イノベーションの加速、魅力的なユーザー体験と顧客体験の提供、そしてコストとエネルギー効率の最適化を大規模に実現する、新しい AI インフラストラクチャ機能を発表します。

エージェンティックインテリジェンスへの移行

エージェンティック時代では、たった一つの意図が連鎖反応を引き起こします。チャットとは異なり、主要な AI エージェントは目標を具体的なタスクへと分解し、専門化されたエージェント群がリアルタイムで連携し、状態を保持し、強化学習を用いて成果を出します。

このプロセスは、インタラクションごとのインテリジェンスを拡張させる一方、従来のアーキテクチャではコストの急増やパフォーマンスのボトルネックなしには対応できない複雑性をもたらします。効率的かつ効果的にスケールするには、断片化したコンポーネントや技術を手動で統合する段階から脱却しなければなりません。スマートで高速かつ、スケーラブルでコスト効率に優れたエージェンティック体験を提供するには、専用ハードウェア、オープンソフトウェア、柔軟な利用モデルにまたがる統一されたインフラストラクチャスタックが必要です。

Google の AI Hypercomputer は、エージェンティック時代のために構築され、これらの新しい要件を満たすように設計された AI 最適化インフラストラクチャです。これは、Google のフラッグシップモデルである Gemini、コンシューマー向け AI サービス、およびエンタープライズ向け AI ソリューションを支える基盤と同じものです。本日、以下を含む AI インフラストラクチャポートフォリオの大幅な拡張を発表します。

TPU 8t および TPU 8i：第 8 世代 TPU
A5X ベアメタルインスタンス：NVIDIA Vera Rubin NVL72 を搭載
Axion N4A VM：カスタム Arm ベース CPU「Axion」を搭載
Google Compute Engine 第 4 世代 VM：Intel および AMD の x86 ベース CPU を搭載
Virgo ネットワーク：AI ワークロード向けの革新的なデータセンターファブリック
Google Cloud Managed Lustre：高パフォーマンスな並列ファイルシステム
Z4M VM：大容量のローカル SSD ストレージと、オープンな並列ファイルシステム向け RDMA を搭載
専用 KV キャッシュ：スケーラブルなストレージサブシステム
ネイティブ PyTorch：TPU をサポート
Google Kubernetes Engine (GKE) の新機能：エージェントネイティブなワークロード運用に対応

これらの機能を組み合わせることで、モデルや複雑なエージェンティックワークフローの開発を促進し、イノベーションを加速させ、有用でレスポンシブなサービスを顧客に提供しつつ、大規模なコスト削減と責任あるエネルギー利用を実現します。

詳細をご紹介します。

エージェンティック AI 向けに構築された第 8 世代 TPU システム

本日、エージェンティック時代に特化して設計された第 8 世代 Tensor Processing Unit（TPU）を発表します。今回初めて、用途の異なる 2 つのチップと専用システムが登場します。

TPU 8t は、高スループットの AI ワークロード向けに設計されたトレーニングの原動力です。AI 開発の規模を再定義し、前世代よりも 3 倍近く高い演算性能を提供することで、大規模モデルのトレーニング時間を短縮します。単一のスーパーポッドに 9,600 個のチップを搭載し、121 エクサフロップスの演算能力と 2 ペタバイトの共有メモリを高速な ICI（チップ間相互接続）でつなぎます。大規模なコンピューティングプール、統合メモリ、そして 2 倍になった ICI 帯域幅により、最も複雑なモデルでもほぼ線形のスケーリングと最大限のシステム利用率を実現します。Pathways と JAX によってオーケストレーションされた単一クラスター内の 100 万以上の TPU チップのパワーで、数ヶ月かかっていたトレーニングを数週間に短縮できます。

TPU 8i は、推論と強化学習（RL）のための革新的な推論システムであり、エージェンティックワークフローや Mixture of Experts（MoE）モデルに必要な超低遅延を実現します。オンチップ SRAM を 384 MB に 3 倍増、高帯域幅メモリ（HBM）を 288 GB に増強し、大規模な KV キャッシュを完全にシリコン上に保持することで「メモリの壁」を打破しました。これにより、TPU 8i は前世代と比較して推論の価格パフォーマンスを 80% 向上させ、高速でインタラクティブなユーザー体験をコスト効率よく実現します。

TPU 8t および TPU 8i は、まもなく Google Cloud のお客様に提供予定です。アーキテクチャの詳細については、こちらをご覧ください。

NVIDIA Vera Rubin プラットフォームを搭載した A5X

私たちは、一つの手法がすべてに適合するわけではないことを理解しています。お客様ごとにワークロードや要件、ユースケースは異なります。そのため、Google は NVIDIA と深く連携し、最新の GPU プラットフォームを Google Cloud 上で信頼性と拡張性の高いサービスとして提供しています。本年後半に利用可能になる次世代の NVIDIA Vera Rubin プラットフォームに基づいたインスタンスは、いち早く提供予定です。

また、Open Compute Project を通じて、オープンソースの Falcon ネットワークプロトコルを NVIDIA と共同開発しており、信頼性の高いトランスポートプロトコルの限界に挑んでいます。A5X には Falcon の革新的なコンセプトが数多く実装される予定です。

例えば、Thinking Machine Labs は Google の NVIDIA ベースのインフラストラクチャを活用して、特化型のユースケースに向けたフロンティアモデルの強化学習やファインチューニングを行うオープンプラットフォーム「Tinker」を構築しています。Google の AI Hypercomputer を使用することで、トレーニングとサービングの両方において 2 倍以上の高速化を実現しています。

Axion、Intel、AMD によるエージェンティックロジックと強化学習の推進

GPU や TPU は AI モデルのトレーニングやサービングに優れていますが、コア AI モデルを取り巻く複雑なロジック、ツール呼び出し、フィードバックループを処理するには、高パフォーマンスな CPU ベースのサービスで補完する必要があります。新しい Axion 搭載 N4A CPU インスタンスは、これらのエージェントランタイムに対して優れたコストパフォーマンスを提供します。実際、Google Axion N4A を搭載した GKE Agent Sandbox は、他のハイパースケーラー上のエージェントワークロードと比較して、最大 30% 優れた価格パフォーマンスを実現します。

この効率性は、Intel および AMD の最新 x86 インスタンスを搭載した第 4 世代 Compute Engine VM ファミリーを含む、Google のポートフォリオ全体に及んでいます。これらは、RL の報酬計算、エージェント運用、ネストされた可視化など、幅広い RL タスク向けに最適化されており、あらゆる AI ワークロードに対して最適な機能を提供します。

データセンタースケールアウトファブリックのための Virgo ネットワーク

AI Hypercomputer の一部である Virgo ネットワークは、大規模な AI ワークロードの厳しい要件を満たすよう設計されています。前世代の 4 倍の帯域幅を持つコラプスドファブリックアーキテクチャにより、「スケーリングにかかるオーバーヘッド」を排除し、驚異的なピーク演算能力を提供します。この性能により、最も野心的な AI ワークロードもほぼ線形の効率でスケールできます。

Virgo ネットワークと TPU 8t を使用することで、一つのデータセンター内で 134,000 個の TPU を単一のファブリックに接続し、複数の拠点にわたって 100 万個以上の TPU を学習クラスターとして接続することが可能です。これにより、世界中に分散したインフラを、実質的に一つのシームレスなスーパーコンピュータへと変革できます。

また、Virgo ネットワークを A5X（NVIDIA Vera Rubin NVL72 搭載）にも提供し、一つのデータセンターで最大 80,000 GPU、複数の拠点にまたがって最大 960,000 GPU をサポートします。

ストレージ：データボトルネックの最小化

大規模なコンピューティングクラスタの効果は、データを供給するストレージシステムの性能に依存します。コンピューティングの高速化に伴い、ストレージがボトルネックにならないよう、以下の 4 つの主要な進歩を提供します。

トレーニングと推論の加速：Google Cloud Managed Lustre は 10 TB/s の帯域幅を実現しています。これは昨年比で 10 倍の向上、他のハイパースケーラーと比較して最大 20 倍高速化しています。また、容量を 80 ペタバイトまで拡張しました。これらの進歩は、新しい C4NX インスタンスと Hyperdisk Exapools によって実現しています。
遅延の最小化：Managed Lustre は、新しい TPUDirect および RDMA を活用し、データがホストをバイパスしてアクセラレータへ直接移動することを可能にしています。この処理オーバーヘッドを排除することで、AI エージェントはユーザーが求めるほぼ瞬時の速度で応答できるようになります。
トレーニングのピーク稼働率を維持：Google Cloud Storage の Rapid Buckets は、ミリ秒以下の遅延と毎秒 2,000 万オペレーションにより、オブジェクトストレージを刷新します。これにより、大規模なトレーニングのチェックポイントとリカバリをほぼ瞬時に実行、アクセラレータの稼働率を 95% 以上に維持できるようになり、トレーニングサイクルを加速させると同時に、貴重な TPU や GPU のコスト効率も向上します。
カスタムソリューションの構築： ストレージソリューションを独自に構築したい ISV や組織向けに、Vast Data や Sycomp といった信頼性の高い並列ファイルシステムを統合したいお客様向けに特別設計した Z4M インスタンスをリリースします。各 Z4M インスタンスは最大 168 TiB のローカル SSD 容量まで拡張可能で、数千台規模の RDMA クラスタに展開できます。

これらの新しいストレージオプションは包括的なストレージポートフォリオを提供し、AI Hypercomputer スタックの圧倒的なパワーを、各ユースケースに最適なストレージサービスとともに提供します。

GKE：エージェントネイティブワークロードの運用

エージェンティック時代において、インテリジェンスはスケールできる速度に影響されます。そこで、GKE をエージェントネイティブなワークロードのための主要なオーケストレーションエンジンへと進化させました。

スタック全体でのレイテンシ削減

レスポンシブなエージェンティック応答をサポートするために、起動およびスケールアウトプロセスのあらゆる瞬間を最適化しています。需要の急増へのインフラストラクチャの対応を合理化することで、GKE はユーザーがシステムに関与した瞬間にエージェントが準備できていることを保証します。GKE の新機能は以下の通りです。

ノードおよびポッド起動の高速化：GKE ノードの起動は最大 4 倍高速化、ポッドの起動時間は最大 80% 短縮されました。
迅速なモデルロード：run:AI Model Streamer と Google Cloud Storage の Rapid Cache を活用することで、モデルの読み込み速度が 5 倍向上し、従来のストレージのボトルネックが解消されます。

AI 搭載の Inference Gateway によるインテリジェントなルーティング

昨年公開した GKE Inference Gateway を基盤として、「AI のための AI」で大規模なサービングにおける複雑な課題を解決しています。

Inference Gateway の新しい予測型レイテンシブーストは、従来のヒューリスティックな推測を、機械学習によるリアルタイムのキャパシティを考慮したルーティングに置き換えます。このインテリジェントな運用により、手動でのチューニングなしに、Time-to-First-Token（TTFT）の遅延を 70% 以上削減します。企業にとって、より自然な音声会話や、さまざまなユースケースにおけるスムーズでリアルタイムなインタラクションに直結します。

Inference Gateway は、Cloud Native Computing Foundation（CNCF）のサンドボックスプロジェクトとして承認された、Kubernetes ネイティブの高パフォーマンスな分散 LLM 推論フレームワークである llm-d と共にデプロイ可能です。Google Cloud は、Red Hat、IBM Research、CoreWeave、NVIDIA と共に llm-d の創設メンバーであることを誇りに思っています。私たちは、「あらゆるモデル、あらゆるアクセラレータ、あらゆるクラウド」という、業界を定義する明確なビジョンのもとに団結しています。

AI ライフサイクル全体を支えるオープンソフトウェアエコシステム

ハードウェアは、共同設計されたソフトウェアにより、その潜在能力を発揮します。AI Hypercomputer は、JAX、PyTorch、vLLM などの業界で人気なフレームワークに対してネイティブかつ最適化されたサポートを提供することで、エンジニアの開発スピードを高速化します。このオープンなソフトウェアレイヤーが開発とデプロイの間の摩擦を軽減し、市場投入までの時間の短縮とリソース効率の向上を実現します。

現在、一部のお客様を対象に、TPU 向けのネイティブ PyTorch サポート「TorchTPU」のプレビュー版で提供しています。TorchTPU を使用すると、Eager Mode などのネイティブ PyTorch 機能を完全にサポートしながら、モデルをそのままの形で TPU 上で実行できます。これに TPU 上での vLLM の強固なサポートを組み合わせることで、「オープン性とお客様の選択肢を常に重視して構築する」ことにコミットしています。

エージェンティックな成長のための基盤

エージェンティック時代において、迅速かつコスト効率よくイノベーションを実現するには、パフォーマンスと選択肢を妥協しない統合システムが必要です。それこそが AI Hypercomputer が提供するものです。シリコンからソフトウェアまですべてのレイヤーを共同設計することで、統合の負担を取り除き、お客様のチームがビジネスの推進に集中できるようにします。

AI Hypercomputer は、Google のハイレベルサービスのエコシステム全体を支える強力な基盤としても機能します。この統合されたスタックは、Gemini Enterprise から Gemini Enterprise Agent Platform まで、あらゆるサービスを支えており、これらすべてのインフラストラクチャのイノベーションが直接的なビジネス価値へと変換されることを保証します。サーバーレストレーニングサービスや新しい Managed RL API などのフルマネージドサービスを活用することで、AI Hypercomputer の圧倒的なパフォーマンス向上を適用して独自のビジネスロジックで Gemini をカスタマイズし、高度なエージェントベースのソリューションを実現できます。

この更新および拡張された AI プラットフォームを使って、皆様が次に何を構築されるのか、非常に楽しみにしています。

AI インフラストラクチャの効率: Ironwood TPU で炭素効率が 3.7 倍向上

Mon, 20 Apr 2026 01:00:00 +0000

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

Google は、AI インフラストラクチャが環境に与える影響について透明性を確保することに尽力しており、チップの製造からデータセンターでのチップの稼働まで、チップのライフサイクル全体における排出量の指標を公開しています。このたび、Google は第 7 世代 TPU である Ironwood の指標を更新します。Ironwood は、前世代のパフォーマンス最適化 TPU である TPU v5p と比較して、コンピューティング二酸化炭素排出原単位（CCI）が約 3.7 倍改善されています1。

つまり、AI が追加のコンピューティングリソースの需要を促進しているのは事実ですが、AI ハードウェアを最適化するための Google の継続的な取り組みは、AI ワークロードのエネルギー消費量と排出量の改善に役立っています。

AI アクセラレータの効率を測定: コンピューティング二酸化炭素排出原単位（CCI）

AI ワークロードの環境への影響を管理するために、Google は AI アクセラレータハードウェアのコンピューティング二酸化炭素排出原単位（CCI）をモニタリングしています。CCI は、An Introduction to Life-Cycle Emissions of Artificial Intelligence Hardware2 で、利用される浮動小数点演算ごとに排出される CO2 換算量（CO2e / FLOP）の推定値として定義されています。この指標は、製造、輸送、データセンターの建設に関連する体化排出量（スコープ 3）と、データセンターでのチップの運用に関連する運用排出量（スコープ 1 と 2）の両方を含めることで、チップレベルの全体像を提供します。

Ironwood のメリット: 高パフォーマンス、低フットプリント

Google の TPU CCI は、チップの世代ごとに改善され続けています。2026 年 1 月に測定された実証データによると、Ironwood は TPU v5p と比較して CCI が 3.7 倍も改善されています。これにより、TPU v4 と比較して TPU v5p の CCI が 1.2 倍向上し、Google のパフォーマンス最適化された TPU アーキテクチャの継続的な炭素効率の最適化が実証されています。

この効率性の向上は、マシンのエネルギー消費量と製造時の排出量の増加に比べて、TPU の世代間のコンピューティングパフォーマンスの向上が大きかったことによるものです。実際、TPU v5p から Ironwood までの全世代にわたるフリート全体の測定では、利用できる FLOP 数が 5 倍向上しています3。CCI の式（CO2e / FLOP）のパフォーマンス分母が排出量よりも速くスケールされるため、新しいチップごとに 1 オペレーションあたりの純炭素コストが大幅に低下します。

^{図 1: 2026 年 1 月のワークロードにおいて、Google のパフォーマンス最適化 TPU コホートで測定された Ironwood の CCI 改善の加速4}

Google の TPU フリートの運用効率がさらに向上

TPU CCI 指標が更新されたことで、2025 年に公開された測定値との直接比較も可能にしました。具体的には、2024 年 10 月から 2026 年 1 月にかけて、Google の汎用 TPU コホートは、以前の報告よりも効率的に動作しました。

TPU v5e では、15 か月間で CCI の合計が 43% 削減され、228 gCO2e / EFLOP になりました。これは、平均使用率が 72% 増加したことによるものです。
第 6 世代の TPU である Trillium では、同じ期間に CCI の合計が 20% 削減され、排出原単位は 125 gCO2e / EFLOP になりました。

^{図 2: Google の汎用 TPU コホートは、2024 年 10 月から 2026 年 1 月までの同じ TPU 世代におけるデプロイ効率の向上を示しています5。}

これらの結果は、Google が AI インフラストラクチャの炭素効率を継続的に改善していることを示しています。AI に対する大規模な需要により、大量の電力が必要とされ、その量は増え続けていますが、Google のイノベーションにより、消費電力の単位あたりで大幅に高いコンピューティングパフォーマンスを実現できるようになりました。

エネルギーと排出量をパフォーマンスから切り離す

これらの改善は、何に起因すると考えられるでしょうか。Ironwood のハードウェアの基本性能に加え、Google のインフラストラクチャ全体にわたるソフトウェアとシステムレベルの綿密な最適化によって、CCI の向上はさらに促進されています。

ソフトウェアの効率（MoE）: Mixture of Experts（MoE）などのスパースアーキテクチャが広く採用されることで、必要なパラメータにのみ計算がルーティングされます。これにより、モデルの容量や品質を犠牲にすることなく、推論やトレーニングのステップごとに必要なアクティブな FLOP を大幅に削減できます。
低精度演算（FP8）: 8 ビット浮動小数点（FP8）形式を多用することで、16 ビット形式と比較して、コンピューティングスループットを 2 倍に高め、メモリ帯域幅の要件を半分に削減しています。これは、数学演算あたりのエネルギーコストを指数関数的に削減しながら、出力品質を維持できることを示しています。
ワークロードのミックスとインテリジェントなスケジューリング: 高度なフリートオーケストレーションにより、インフラストラクチャ全体でワークロードのミックスが継続的にバランス調整されます。タスクをインテリジェントにスケジューリングすることで、継続的な使用率を高く保ち、デューティサイクルを最適化し、アイドル電力消費による二酸化炭素排出量を最小限に抑えます。

Google Cloud でサステナブルにスケーリング

AI の発展には、二酸化炭素排出量を同程度に急増させることなく、指数関数的にスケールできるインフラストラクチャが必要です。TPU v5p から Ironwood で炭素効率が 3.7 倍向上したことは、ハードウェアとソフトウェアの慎重な共同設計を通じて、エネルギーと環境フットプリントの増加を最小限に抑えながら、より高いコンピューティング密度を実現できることを示しています。Ironwood の詳細と利用方法については、こちらのフォームからご登録ください。

^{1. 2025 年 8 月の技術レポートで公開された手法に従い、2026 年 1 月時点の Google の各世代の TPU を対象として、TPU ハードウェアのライフサイクル全体の排出量を特定時点のスナップショットとして定量化しました。この調査の機能単位は、データセンターにデプロイされた 1 台の AI コンピュータです。これには、1 つのホストトレイ（つまり、コンピューティングサーバー）に接続された 1 つ以上のアクセラレータトレイ（TPU を含む）が含まれます。トレイ以外の周辺コンポーネント（ラック、棚、ネットワーク機器など）と補助的なコンピューティングリソースおよびストレージリソースは、体化排出量と運用排出量の計算から除外されます。データセンターの冷却に使用される電力は、運用排出量に含まれます。ワークロード実行の電力消費に伴う運用上の排出量を推定するために、TPU フリート全体のマシン電力データを観測して 1 か月分のサンプルを用意し、Google の 2024 年のフリート全体の二酸化炭素排出原単位の平均を適用しました。製造、輸送、廃棄に由来する体化排出量を推定するために、ハードウェアのライフサイクル評価を実施しました。データセンターの建設に伴う排出量は、Google が開示した 2024 年の温室効果ガス排出量に基づき推定されました。これらの調査結果は、モデルレベルの排出量を表しているわけではありません。また、AI に関連する Google の排出を完全に定量化したものでもありません。TPU のロケーションに応じて、特定のワークロードに対応する CCI の結果が変わる可能性があります。2. この論文の共同執筆者の Ian Schneider、Hui Xu、Stephan Benecke、Parthasarathy Ranganathan、Cooper Elsworth に対して、これらの結果を可能にするために多大な協力をしてくれたことに、著者一同から感謝を申し上げたいと思います。3. この比較では、2026 年 1 月に Google のフリートにデプロイされた TPU v5p チップと Ironwood チップの間で利用される FLOPS（BF16）を考慮しています。この傾向は、v5p（459 FLOPS）と Ironwood（2,307 FLOPS）の間のピーク FLOPS（BF16）の改善と一致しています。4. GHG プロトコルは、運用排出量について 2 つの会計基準を提供しています。ここで示す結果は、カーボンフリーエネルギーの購入による影響を含む、市場ベースの排出量を考慮したものです。カーボンフリーエネルギーの購入を除外するロケーションベースの会計では、運用 CCI はそれぞれ 793、712、195 gCO2e/EFLOP に上昇します。CCI の改善の割合は同程度で、Ironwood の体化 CCI は合計 CCI の 23% から 8% に減少します。5. さまざまな TPU 使用率で公平に比較できるように、この分析では 2025 年 8 月の技術レポートの傾向スコア加重手法を再現し、2026 年 1 月の結果を 2025 年に公開された結果と比較しています。この統計手法では、デューティサイクルの変動を調整して、特定の期間における TPU の比較のバランスを取ります。この経験的な手法により、計算された CCI の時間的期間間の変動が小さくなり、グローバルインフラストラクチャ全体での実際のエネルギー消費量とハードウェア使用率の変動が反映されます。}

- Google シニアデータサイエンティスト、Keguo（Tim）Huang

- Google 上級エンジニア、David Patterson

Ironwood TPU を使用したトレーニングに関するデベロッパーガイド

Mon, 30 Mar 2026 02:10:00 +0000

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

数兆単位のパラメータを扱う AI モデルへの移行により、演算リソースの需要が急激に高まり、従来のインフラストラクチャの限界が試されています。第 7 世代の Ironwood TPU は、Google がカスタム設計した AI インフラストラクチャです。チップ間相互接続（ICI）、光回路スイッチ（OCS）、データセンターネットワーク（DCN）、および大規模な集約型高帯域幅メモリ（HBM）容量を組み合わせることで、最大 9,216 個のチップを格納できる Pod に対応する包括的なシステムとしてスケールできるように設計されています。さらに、Ironwood はハードウェアアーキテクチャとソフトウェアの統合された共同設計を特徴としており、コンパイラ中心の XLA、および Pallas や Mosaic などの Python ネイティブカーネルといったイノベーションが導入されています。組織はこれらの機能を組み合わせることで、高度なフロンティアモデルをトレーニングおよび提供する能力を大幅に高め、AI ライフサイクル全体を最適化し、高いパフォーマンスを維持できます。

この技術概要では、Ironwood ハードウェア上でのトレーニング効率の向上と、卓越したパフォーマンスの実現を目指して設計された、JAX および MaxText エコシステムにおける具体的な手法とツールについて説明します。

Ironwood の主な最適化戦略

1. MaxText によるネイティブ FP8 の活用

Ironwood は、行列乗算ユニット（MXU）で 8 ビット浮動小数点（FP8）をネイティブにサポートする最初の TPU 世代です。重み、アクティベーション、勾配に FP8 精度を利用することで、ユーザーは理論上、スループットを Brain Floating Point 16（BF16）の 2 倍に高められます。FP8 レシピを正しく構成すると、モデルの品質を損なうことなく効率を向上させることができます。

これらの FP8 トレーニングレシピを実装するには、Qwix ライブラリから始めます。この機能は、MaxText 構成内で関連するフラグを指定すると有効になります。,

詳しくは、Google デベロッパーフォーラムのブログ投稿 Ironwood での FP8 トレーニングの最適化についてをご覧ください。

2. Tokamax カーネルによる加速

Tokamax は、TPU 向けに最適化された高パフォーマンスの JAX カーネルのライブラリです。これらのカーネルは、次のメカニズムを通じて特定のボトルネックを軽減するように設計されています。

Splash Attention: このメカニズムは、標準的なアテンションプロセスに内在する I/O の制限に対処します。オンチップ SRAM 内で計算を維持することで、メモリ帯域幅が制約になることが多い長いコンテキストの処理に特に効果を発揮します。
Megablox グループ化行列乗算（GMM）: これは、混合エキスパート（MoE）モデルでよく見られる「不規則な」なテンソルを管理します。GMM を利用すると、システムは非効率的なパディングを回避し、MXU の使用率を高められます。
カーネルチューニング: Tokamax ライブラリには、ハイパーパラメータを最適化するためのユーティリティが含まれています。これらのツールを使用すると、Ironwood TPU の特定のメモリ階層に合わせて、タイルサイズやその他の構成を調整できます。

3. SparseCore への集団のオフロード

Ironwood の第 4 世代 SparseCore は、不規則なメモリアクセスパターンを管理するために特別に設計されたプロセッサです。ユーザーは、特定の XLA フラグを使用して、All-Gather や Reduce-Scatter などの集団通信演算を SparseCore に直接オフロードできます。

このオフロードメカニズムにより、TensorCore を主要なモデル計算に専念させながら、通信タスクを並行して実行できます。このような機能の重複は、通信のレイテンシを隠し、MXU へのデータスループットを一定に保つための重要な戦略です。

4. VMEM 上でのメモリパイプラインのファインチューニング

TPU メモリアーキテクチャの重要な部分である VMEM は、カーネルのパフォーマンスを最適化するように設計された高速なオンチップ SRAM です。現在の演算と将来の重みのプリフェッチの間で VMEM の割り当てを調整することで、実行速度を全体的に向上させることができます。たとえば、現在のスコープ用に予約されている VMEM を増やすと、カーネルで使用されるタイルサイズを大きくすることができます。これにより、潜在的なメモリストールが解消され、カーネルのパフォーマンスが向上します。

TPU メモリアーキテクチャの詳細については、TPU パイプラインをご覧ください。

5. 最適なシャーディング戦略の選択

最後に、MaxText は、すべての TPU で利用できるさまざまな並列処理手法をサポートしています。最適な選択は、モデルサイズ、アーキテクチャ（Dense や MoE）、シーケンス長によって異なります。適切なシャーディング戦略を選択すると、モデルのパフォーマンスを高められます。

完全にシャーディングされたデータ並列処理（FSDP）: これは、単一チップのメモリ容量を超える大規模モデルをトレーニングする場合に推奨される戦略です。FSDP は、モデルの重み、勾配、オプティマイザの状態を複数のチップにシャーディングします。デバイスごとのバッチサイズを増やし、より多くの演算を導入することで、All-Gather 演算のレイテンシを隠し、効率を向上させることができます。
テンソル並列処理（TP）: 個々のテンソルをシャーディングします。Ironwood は演算密度が高いため、モデルの次元が極めて大きい場合に TP が最大の効果を発揮します。TP を 2 分割して活用すると、Ironwood のデュアルチップレット設計における高速なダイ間相互接続を利用できます。
エキスパート並列処理（EP）: MoE モデルでエキスパートをデバイス間で分散するのに役立ちます。
コンテキスト並列処理（CP）: 非常に長いシーケンスに必要で、シーケンスの次元に沿ってアクティベーションをシャーディングします。
ハイブリッドアプローチ: 大規模な実行で演算、メモリ、通信のバランスを取るには、戦略の組み合わせが必要になる場合が多いです。

上述の 2～5 の手法について詳しくは、デベロッパーフォーラムの投稿 Optimizing Frontier Model Training on TPU v7x Ironwood（TPU v7x Ironwood でのフロンティアモデルトレーニングの最適化）をご覧ください。

Ironwood のメリット: システムレベルのパフォーマンス

これらの最適化手法と、高速の 3D トーラスチップ間相互接続（ICI）や大容量 HBM などの Ironwood のアーキテクチャ上の強みを組み合わせることで、フロンティアモデルのトレーニング向け高性能プラットフォームが実現します。ハードウェア、コンパイラ（XLA）、フレームワーク（JAX、MaxText）間の緊密な共同設計により、AI インフラストラクチャから最大限のパフォーマンスを引き出すことができます。

AI の取り組みを加速させる準備は整いましたか？以下のリソースで、各最適化手法について詳しく確認できます。

関連情報

このブログ投稿に協力してくれた Hina Jajoo と Amanda Liang に感謝します。

- プロダクト戦略およびオペレーション担当、Lillian Yu

- Google TPU 担当プロダクトマネージャー、Liat Berry

初の推論に特化した Google TPU「Ironwood」を発表

Wed, 09 Apr 2025 03:00:00 +0000

Google Cloud は本日、Google Cloud Next 25 で、第 7 世代の Tensor Processing Unit (TPU) 「Ironwood」を発表しました。Ironwood は、これまでで最もパフォーマンスが高く、スケーラブルなカスタム AI アクセラレータであり、初めて推論に特化し設計された TPU です。TPU は 10 年以上にわたり、Google の最も要求の厳しい AI トレーニングとサービス提供のワークロードを支え、Google Cloud のお客様にも同様のメリットを提供してきました。Ironwood は、これまでで最も強力で高性能、かつエネルギー効率に優れた TPU であり、大規模な思考および推論 AI モデル専用に設計されています。

Ironwood は、AI 開発と進歩を推進するインフラストラクチャにおける重要な局面を示しています。人間による解釈のためにリアルタイム情報を提供する「応答型」のAI モデルから、洞察と解釈を「積極的に」生成するモデルへの移行を表しているのです。当社はこれを「推論の時代」と呼んでおり、AI エージェントは積極的にデータ取得と生成を行い、データのみならず洞察と回答を協同的に提供します。

Ironwood は、次世代の生成 AI と、その膨大な計算および通信要件をサポートするために構築されました。最大 9,216 個の液冷チップを画期的なチップ間相互接続（ICI）ネットワークに接続でき、約 10 MW まで拡張可能です。これは、最も要求の厳しい AI ワークロード向けにハードウェアとソフトウェアを最適化した、Google Cloud AI ハイパーコンピュータアーキテクチャの新しいコンポーネントの 1 つです。Ironwood により、開発者は Google の Pathways ソフトウェアスタックを活用して、数万個の Ironwood TPU を組み合わせたコンピューティング能力を確実かつ簡単に利用できます。

これらのイノベーションがどのように連携して、比類のないパフォーマンス、コスト、電力効率で、最も要求の厳しいトレーニングおよびサービス提供のワークロードに対応するかを詳しく紹介します。

Ironwood で推論の時代を強化

Ironwood は、大規模言語モデル（LLM）、Mixture of Experts（MoE）、高度な推論タスクを含む「思考モデル」の複雑な計算とコミュニケーション要求を円滑に管理できるように設計されています。これらのモデルには、大規模な並列処理と効率的なメモリアクセスが必要です。特に Ironwood は、大規模なテンソル操作を実行しながら、チップ上のデータ移動とレイテンシを最小限に抑えます。最先端の思考モデルの計算要求は、単一のチップの能力をはるかに超えています。Ironwood TPU は、完全な TPU ポッド規模で連携、および同期されたコミュニケーションをサポートするために、低レイテンシ、高帯域幅の ICI ネットワークを備えています。

Google Cloud のお客様には、AI ワークロードの需要に基づいて、256 チップ構成と 9,216 チップ構成の 2 つのサイズで提供されます。

Ironwood は 1 ポッドあたり 9,216 個のチップ、合計 42.5 エクサフロップスに拡張することで、世界最大のスーパーコンピュータである El Capitan（1 ポッドあたりわずか 1.7 エクサフロップス）の 24 倍以上の計算能力をサポートします。また、超大規模高密度 LLM やトレーニングと推論のための思考能力を持つ MoE モデルなど、最も要求の厳しい AI ワークロードに必要な大規模な並列処理能力を提供します。各チップは、ピーク時で 4,614 TFLOPs のコンピュートを持っています。これは AI 能力の画期的な飛躍を表しています。Ironwood のメモリとネットワークアーキテクチャにより、適切なデータが常に利用可能となり、この大規模なスケールで最高のパフォーマンスがサポートされます。
Ironwood には、高度なランキングや推奨ワークロードで一般的な超大規模なエンベディングを処理する専用アクセラレータである、強化された SparseCore も搭載しています。拡張された SparseCore サポートにより、従来の AI 領域を超え、金融や科学の分野など、より広範囲のワークロードを加速できます。

Google DeepMind が開発した Google 独自の機械学習ランタイムである Pathways は、複数の TPU チップ間で効率的な分散コンピューティングを可能にします。Google Cloud 上の Pathways により、単一の Ironwood Pod を超えた移行が容易になり、数十万個の Ironwood チップを組み合わせて生成 AI コンピューティングの最前線を急速に進化させることができます。

図1. Google 初の外部から利用可能な TPU である TPU v2 との比較に基づく、合計 FP8 ピークフロップスパフォーマンスの向上。

図2. 最新世代の Ironwood を含む Cloud TPU 製品の 3D トーラス版の技術仕様の比較。FP8 ピーク TFlops は v4 および v5p ではエミュレートで実現されますが、Ironwood ではネイティブにサポートされます。

Ironwood の主な特徴

Google Cloud は、最先端の研究をサポートする AI コンピューティングを 10 年以上にわたり提供してきた唯一のハイパースケーラーであり、Gmail や検索など、毎日数十億人のユーザーに提供される地球規模のサービスにシームレスに統合されています。こうした専門知識はすべて、Ironwood の能力が中核となっています。主な特徴は以下のとおりです。

電力効率に重点を置きつつパフォーマンスを大幅に向上し、AI ワークロードをよりコスト効率よく実行します。Ironwood は、2024 年に発表した Google の第 6 世代 TPU である Trillium と比較して 2 倍の消費電力あたりのパフォーマンスを発揮します。AI 機能を提供する上で、利用可能な電力が制約の 1 つとなっている現在、お客様のワークロードに対して 1 ワットあたりの能力を大幅に向上させています。当社の高度な液冷ソリューションと最適化されたチップ設計により、継続的な高負荷の AI ワークロード下でも、標準的な空冷の最大 2 倍のパフォーマンスを安定して維持できます。実際、Ironwood は 2018 年の初代の TPU と比べて電力効率が約 30 倍優れています。
高帯域幅メモリ（HBM）容量が大幅に増加しました。Ironwood はTrillium の 6 倍となる 1 チップあたり 192 GBのメモリ容量を提供します。これにより、より大きなモデルとデータセットの処理が可能になり、頻繁なデータ転送の必要性が減り、パフォーマンスが向上します。
HBM 帯域幅が大幅に向上し、Trillium の 4.5 倍の 1 チップあたり 7.2 Tbps を実現します。この高帯域幅により、現代の AI で一般的なメモリ集約型のワークロードにとって重要な、高速データアクセスが保証されます。
チップ間相互接続（ICI）帯域幅を強化しました。双方向で 1.2 Tbps に増加、Trillium の 1.5 倍となりました。チップ間の通信が高速化され、大規模な分散トレーニングと推論の効率化が促進されます。

図3. 初代の Cloud TPU v2 と比較した Google の TPU 電力効率の向上。チップパッケージあたりの熱設計電力 1 ワットあたりに提供されるピーク FP8 フロップスによって測定されます。

Ironwood で将来の AI 需要を解決

Ironwood は、計算能力の向上、メモリ容量の拡大、ICI ネットワークの進歩、信頼性の向上により、推論の時代における独自のブレークスルーを実現します。これらの画期的な進歩に加え、ほぼ 2 倍に向上した電力効率により、最も要求の厳しいお客様においても、コンピューティング需要の急増に対応しながら、最高のパフォーマンスと最小のレイテンシでトレーニングとワークロード処理を実行できるようになります。現在、Gemini 2.5 やノーベル賞を受賞した AlphaFold などの主要な思考モデルはすべて TPU 上で実行されています。Ironwood は、今年後半にご利用いただけるようになる予定です。Ironwood により、当社の開発者や Google Cloud のお客様によって生み出される AI ブレークスルーを楽しみにしています。

Google、大規模モデルトレーニングにおける Cloud TPU v4 Pod の実力を実証

Fri, 10 Dec 2021 05:00:00 +0000

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

最近、数十億または数兆ものパラメータを持つモデルが機械学習の機能と精度において目覚ましい進化を遂げています。たとえば、Google の LaMDA モデルは、多岐にわたるトピックについてユーザーと自由に流れるような会話を繰り広げることができます。機械学習の研究とプロダクト開発を行うコミュニティの間では、大規模モデルを活用した画期的な機能の提供に大きな関心が寄せられています。これら大規模モデルは高い演算能力を必要としており、それに伴ってモデルトレーニングプロセスの効率改善により焦点を当てる必要が生じています。そして、ベンチマーキングは効率向上のために ML システムコミュニティをまとめるための重要な手段です。

最近終了した MLPerf v1.1 Training ラウンド1 で、Google は Open 部門に 2 つの大規模言語モデルベンチマークを提出しました。1 つは 4,800 億のパラメータ、2 つ目は 2,000 億のパラメータを持つものです。提出したベンチマークでは、一般公開されているインフラストラクチャを使用しました。たとえば、Cloud TPU v4 Pod スライスやオープンソースの Lingvo モデリングフレームワークです。

従来、この規模のトレーニングモデルは、何千万、もしくは何億ドルといったごく一部の企業しか払えないコストがかかるスーパーコンピュータを必要とすることが常でした。お客様はこれと同じ成果を、オンプレミスシステムのインストールや維持にまつわる費用を負担することなく、エクサフロップ級の処理能力を持つ Cloud TPU v4 Pod を使って得ることができます。

大規模モデルベンチマーク

Google が Open 部門に提出したのは、TensorFlow を使った、パラメータ 4,800 億の高密度 Transformer ベースのエンコーダのみのベンチマークと、パラメータ 2,000 億の JAX ベンチマークです。これらのモデルは、MLPerf の BERT モデルと類似したアーキテクチャを持ちますが、ディメンションがさらに大きく、レイヤ数も多くなっています。提出したベンチマークでは、2 つの異種フレームワークにまたがった大規模モデルのスケーラビリティと TPU の高パフォーマンスが実証されました。特筆すべきは、スタック Transformer アーキテクチャを持つこれらのベンチマークが、演算特性の面で他の大規模言語モデルにほぼ匹敵するものであったことです。

図 1: Google の MLPerf 1.1 提出ベンチマークで使用したエンコーダのみモデルのアーキテクチャ

Google の 2 つの提出結果は、それぞれ 2,048 個のチップと 1,024 個のチップの TPU v4 Pod スライスでベンチマークを実施して得られたものです。エンドツーエンドのトレーニング時間は、4,800 億のパラメータモデルで約 55 時間、2,000 億のパラメータモデルで約 40 時間を達成できました。それぞれの実行での演算効率は 63% を達成しました（使用したシステムのピーク FLOP に対するモデルの浮動小数点演算とコンパイラ再実体化の割合として計算2）。

大規模モデルトレーニング向け次世代 ML インフラストラクチャ

このような素晴らしい結果を残すには、いくつかの最先端テクノロジーが必要でした。まず、各 TPU v4 チップの演算能力は TPU v3 チップの 2 倍超（最大 275 ピーク TFLOPS）です。2 つ目は、典型的な GPU ベースの大規模トレーニングシステムと比べてチップあたり 10 倍の帯域幅を実現する超高速の相互接続によって、4,096 個の TPU v4 チップがまとめて Cloud TPU v4 Pod にネットワーク接続されます。大規模モデルでは通信が非常に頻繁に行われ、ローカルの演算がネットワーク全体で通信されるリモートの演算結果に依存することが多々あります。TPU v4 の超高速相互接続は、ネットワークのレイテンシと輻輳を取り除くことで、大規模モデルの演算効率に非常に大きな影響を与えます。

図 2: Google の Cloud TPU v4 Pod の一部。それぞれが 1 エクサフロップ/秒の演算能力を発揮できる。

Google の提出結果で示されたパフォーマンス値には XLA 線形代数コンパイラが大きな役割を果たしています。また、Lingvo フレームワークも活用されています。XLA は最適化を透過的に実施します。たとえば、ML モデルの構成要素を形成する演算グラフの多くの GSPMD ベースの自動並列化があります。また、XLA では演算と通信をオーバーラップさせることによって、レイテンシの削減も可能です。Google の 2 つの提出結果は、TensorFlow と JAX の 2 つのフレームワークにまたがる Google のソフトウェアスタックの汎用性とパフォーマンスを実証しました。

MLPerf の大規模モデル

Google が提出したベンチマークは、ML の研究や本番環境でますます重要性を高めているものの、MLPerf の Closed 部門ベンチマークスイートでは現在評価できないクラスのモデルが持つ可能性を表すものです。

これらのモデルをベンチマークスイートに加えることが次の重要なステップであり、これによって、大規模モデルが提示するスケーラビリティの課題に焦点を当てるよう ML システムコミュニティに働きかけることができると Google は信じています。

Google の提出結果では、業界最高水準である 63% の演算効率が認められました。演算効率が高いとトレーニングの処理速度が上がり、実験の速度も向上します。すなわち、Google の Cloud TPU をお使いのお客様にとって、コスト削減に直結します。

TensorFlow、PyTorch、JAX を使った Cloud TPU の活用方法について詳しくは、Cloud TPU ホームページとドキュメントをご覧ください。

^{1. MLPerf の名前とロゴは、米国および他の国々における MLCommons Association の商標です。権利はすべて同組織が有しており、無断使用は固く禁じられています。詳しくは、www.mlcommons.org にアクセスしてください。
2. 演算効率とエンドツーエンドのトレーニング時間は公式の MLPerf 指標ではありません。}

- プロダクトマネージャー Aarush Selvan

- TPU テクニカルプログラムマネージャー Pankaj Kanwar

PyTorch / XLA が Cloud TPU で一般提供開始

Thu, 08 Oct 2020 02:00:00 +0000

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

PyTorch 機械学習（ML）フレームワークは、その柔軟性と使いやすさで ML コミュニティで人気があり、これを Google Cloud でサポートできることをうれしく思います。このたび、Cloud TPU の PyTorch / XLA サポートが一般提供されるようなったことをお知らせします。具体的には、PyTorch ユーザーは、十分にサポートされ安定した PyTorch 統合を使用して、大規模で低コストの Cloud TPU ハードウェアアクセラレータにアクセスできます。

PyTorch / XLA は、PyTorch の直感的な API と XLA 線形代数コンパイラの長所を組み合わせたもので、CPU、GPU、Cloud TPU Pod を含む Cloud TPU をターゲットにすることができます。PyTorch / XLA は、最小限の変更でほとんどの標準的な PyTorch プログラムを実行し、CPU にフォールバックして TPU で現時点では未対応の操作を実行します。PyTorch / XLA が生成する詳細なレポートを活用して、PyTorch ユーザーはボトルネックを発見し、Cloud TPU でより効率的に実行するようにプログラムを適応させることができます。

マサチューセッツ工科大学（MIT）の博士号候補者である Jonathan Frankle 氏は、次のように述べています。「PyTorch / XLA により、PyTorch ワークフローにほとんど変更を加えることなく Cloud TPU で数千ものテストを実施できました。PyTorch / XLA は、PyTorch の使いやすさ、TPU のスピードと費用対効果という、それぞれの長所を兼ね備えています。」同氏は、ICLR 2019 で Best Paper Award を受賞した画期的な論文「宝くじ仮説: 訓練できるまばらなニューラルネットワークを見つけること」に関連する最新の研究を PyTorch / XLA を使ってスケールアップしています。

アレン人工知能研究所（AI2）では最近、複数のプロジェクトにわたって Cloud TPU で PyTorch / XLA を使用しています。AI2 の研究者である Matthew Peters 氏は現在、PyTorch / XLA を使用して、言語理解能力を向上させるために最先端の言語モデルに視覚的なコンポーネントを追加する方法を研究しています。同氏は次のように述べています。「PyTorch / XLA はまだ新しいテクノロジーですが、すでに PyTorch に投資して機械学習モデルをトレーニングしている組織に前途多望な新しいプラットフォームを提供します。」

PyTorch / XLA のご利用開始にあたって、Google Cloud は、広く使用されているディープラーニングモデルと関連チュートリアルで構成され、ますます増え続けるオープンソースの実装をサポートしています。ここでは、ResNet-50、Fairseq Transformer、Fairseq RoBERTa、そして、DLRM のチュートリアルをご紹介します。また、ML モデルの継続的なテストを容易にするオープンソースツールを開発しており、PyTorch Lightning チームや Hugging Face チームがこのフレームワークを使用して Cloud TPU で独自のテストを実施できるように支援してきました（こちらは PyTorch Lightning チームの関連するブログ投稿です）。

上記リンク先のチュートリアルを確認して、Colab を介してブラウザで PyTorch / XLA を試し、PyTorch / XLA の GitHub リポジトリに問題や pull リクエストを投稿してください。また、PyTorch 1.6 とともに PyTorch / XLA がプリインストールされた新しいディープラーニング VM（DLVM）イメージもリリースしました。ここでは、この新しい DLVM イメージをすぐに使い始める手順について説明します。

サンプルコードを含む PyTorch / XLA の技術情報については、PyTorch Medium の公式サイトに掲載されている関連記事をぜひお読みください。

-Cloud AI プロダクト管理ディレクター Craig Wiley

Cloud TPU について

Thu, 21 May 2020 00:00:00 +0000

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

編集者注: Yufeng Guo は AI テクノロジーを専門とするデベロッパーアドボケイトです。

実行するワークロードの種類にかかわらず、Google はより優れた計算能力を常に模索しています。汎用プロセッサでは、物理法則という厳しい限界にすぐに直面してしまいます。しかも、機械学習で実現しようとしていることは複雑化の一途をたどるばかりで、高いコンピューティング能力が求められています。

こうした特定の用途向けに計算能力が必要になったことがきっかけで、最初の Tensor Processing Unit（TPU）が誕生しました。Google 独自の TPU は機械学習ワークロードに取り組むために設計されており、Google Cloud のお客様にもご利用いただけるようになっています。TPU とは何か、なぜ TPU が構築されたのかについての理解を深めていくことで、より優れた機械学習アーキテクチャやソフトウェアシステムを設計し、今後さらに複雑な問題に取り組むことができます。

この動画シリーズは 2 部構成で、専用の AI チップの原点と、TPU が AI の課題に特化している理由について紹介します。

最初の動画では、TPU の歴史とハードウェアについて説明します。Google が、翻訳、フォト、検索などの AI ワークロード向けのアプリケーション固有の集積回路（ASIC）を開発した理由について学ぶことができます。また、TPU アーキテクチャと、CPU や GPU との違いについても取り上げています。

次に説明するのは、Google Cloud を通じて一般提供されている TPU v2 と v3 の詳細です。Cloud TPU Pod での多数の接続など、パフォーマンス機能の詳細を学ぶことができます。この動画では、基本的なベンチマークの例や、TensorFlow 2.0 や Keras API によるユーザビリティの新たな改善点についても説明しています。

Cloud TPU や料金について詳しくはウェブサイトをご覧ください。使用開始方法についてはドキュメントをご確認ください。また、Google の Kaggle コミュニティで TPU を使用して複数の言語にわたって悪質なコメントを特定するゲーム（第 2 回戦）に参加することもできます。 AI に関する一般的な情報についての詳細は、YouTube の AI Adventures シリーズをご覧ください。

- By Google Cloud Platform デベロッパーアドボケイト Yufeng Guo