メインコンテンツにスキップ

Google Cloud「The Future of AI Infrastructure」解説：常時稼働エージェントを支えるTPU・ソフトウェア・実行基盤

AIインフラ
Google Cloudは2026年11月9日のライブ配信「The Future of AI Infrastructure」で、AIインフラの設計目標を「1回の質問に答える推論」から「24時間365日動き続けるエージェント」へ切り…
作者

obelos

公開

2026年11月13日

更新日

2026年11月13日

要点

Google Cloudは2026年11月9日のライブ配信「The Future of AI Infrastructure」で、AIインフラの設計目標を「1回の質問に答える推論」から「24時間365日動き続けるエージェント」へ切り替えたことを、ハードウェア・ソフトウェア・実行基盤の3層で示した。

  1. ハードウェア：第8世代TPUは、学習用のTPU 8t、推論用のTPU 8iに、機密推論用のTPU 8txと長大コンテキスト用のTPU 8i Maxを加えた4システム構成になった。
  2. ソフトウェア：PyTorchをTPUで直接動かすTorchTPU、vLLM／SGLangのTPU対応、KVキャッシュを意識してリクエストを振り分けるllm-dにより、GPU向けに書いたコードをTPUへ移しやすくしている。
  3. 実行基盤：エージェント1体ごとに専用microVMを割り当て、待機中は止めて状態ごと再開するAgent Compute Engineと、そのOSS版にあたるAgent Substrate（CNCFへ寄贈）を用意した。

登壇者はAmin Vahdat（Google SVP／AI・インフラ担当チーフテクノロジスト）、Mark Lohmeyer（Google Cloud VP／AI・コンピューティングインフラ担当GM）ほか。

The Future of AI Infrastructure

1. 前提の変化：リクエスト・レスポンスからエージェントへ

これまでのLLMサービングは、ユーザーがプロンプトを送り、モデルが応答を返して終わる形が中心だった。インフラはこの1往復のレイテンシとスループットを最適化してきた。

エージェントは動き方が違う。目標を受け取ると自分でサブタスクに分解し、ツールやAPIを呼び出し、結果を見て次の手を決める。この繰り返しが数時間から数日続く。1つの依頼の裏で並列のサブエージェントが動き、それぞれが状態を持つ。

講演では次の数字が示された。

指標 講演で示された値 補足
エージェント関連トラフィック 過去1年で7,800%超の増加 Google側の計測値
AI処理に占める推論の割合 50〜70% 学習より推論の比重が大きくなっている
世界のトークン需要 2030年に現在の24倍 Goldman Sachs Researchの予測（2026年比、月120京トークン）と同じ値

この変化がインフラに求めるものは3つある。

  • 推論の低遅延と高スループット：エージェントは1タスクで何十回もモデルを呼ぶため、1回あたりの遅延が積み上がる。
  • 長いコンテキストの保持：会話履歴、ツールの実行結果、読み込んだ文書がすべてコンテキストに入るため、KVキャッシュが大きくなる。
  • 待ち時間の扱い：エージェントは外部APIや人間の承認を待つ時間が長い。待っている間もアクセラレーターやVMを確保し続けると、資源が無駄になる。

以降の発表は、この3つにそれぞれ対応している。

2. 第8世代TPU：用途別の4システム

Googleは2026年4月のGoogle Cloud Next ’26で、TPUを初めて学習用と推論用の2チップに分けた。11月9日の発表で、同じシリコンを使った2システムが追加された。新しいチップを起こしたのではなく、既存チップのパッケージとホスト構成を変えたものである。

システム 用途 構成 Googleが示した性能
TPU 8t 大規模学習 学習用チップ。スーパーポッドで121 ExaFLOPS 前世代Ironwood比で学習の価格性能最大2.7倍
TPU 8i 低遅延推論・エージェント HBM 288GB、オンチップSRAM 384MB Ironwood比で推論の価格性能最大80%向上
TPU 8tx（11月追加） 機密推論・小規模学習 TPU 8tと同じシリコン＋第5世代AMD EPYCホスト。ハードウェアレベルの機密コンピューティング TPU 8t比で最大2倍の低遅延、暗号化による性能低下はほぼゼロ
TPU 8i Max（11月追加） 長大コンテキスト推論 TPU 8iチップ2基を1パッケージに統合 TPU 8i比で演算性能・SRAM・HBM帯域がそれぞれ2倍、ラック占有面積は同じ

TPU 8tx：アクセラレーターまで機密コンピューティングを広げる

機密コンピューティングは、処理中のデータをメモリ上でも暗号化し、クラウド事業者を含む外部から読めないようにする技術である。これまではCPU側（AMD SEV-SNPやIntel TDX）が中心で、GPUではNVIDIAのConfidential Computingがある。TPU 8txは、この保護をTPUまで広げた最初のCloud TPUとされる。データとモデルの重みを、処理中もハードウェアで隔離する。

想定顧客は、規制業種の企業や政府機関である。自社の機密データでフロンティアモデルや独自モデル、エージェントを動かしたいが、平文のままクラウドに置けないという要件に対応する。

ホストCPUにGoogle自社のArm系CPU（Axion）ではなくAMD EPYCを採用した点が特徴である。AMDのセキュリティプロセッサのファームウェアは、Googleのセキュリティチームが過去に詳細レビューしており、その実績が採用理由とされている。

TPU 8i Max：コンテキストを切り詰めずに処理する

エージェントや長文書の処理では、コンテキストが長くなるほどKVキャッシュがHBMを圧迫する。収まらない分は切り捨てるか、遅い外部メモリへ退避するしかない。TPU 8i Maxは2チップを1パッケージにまとめ、SRAMとHBM帯域を倍にして、長いコンテキストをチップ上に保持したまま推論できるようにしている。

TPU 8txとTPU 8i Maxについて、Googleは提供時期・価格・リージョンを公表していない。Bloombergは2027年の提供と報じている。

3. Project Suncatcher：宇宙でのTPU実証

Project Suncatcherは、太陽光発電の衛星群にTPUを載せ、宇宙で機械学習の計算を行う研究プロジェクトである。地上のデータセンターは電力と冷却が制約になるが、太陽同期軌道ではほぼ常に太陽光を受けられる。

  • 2026年10月1日、Planet社と共同開発したプロトタイプ衛星をSpaceXのTransporter-18で打ち上げた。
  • 衛星には4基のTPUを搭載し、Cloud TPU v6e-4スライス相当の計算能力を持つ。太陽電池は約1kW。
  • TPUは約15分単位で稼働し、軌道上でGeminiモデルを動かして性能を計測している。講演ではこれを軌道上推論の「Hello World」と表現した。
  • 地上試験では、Trillium（TPU v6e）に67MeVの陽子線を照射し、想定軌道線量を大きく超えても致命的な故障がないことを確認している。
  • 2027年には2機を追加し、衛星間の光通信を検証する計画である。

製品化の発表ではなく、研究段階の実証である。

4. ソフトウェアスタック：既存コードのままTPUを使う

TPUの普及を妨げてきた最大の要因は、ソフトウェアの移行コストだった。多くの開発者はPyTorchとNVIDIA GPU前提でコードを書いており、TPUを使うにはJAXに書き換えるか、制約の多いPyTorch/XLAを使う必要があった。Google Cloudはこの障壁を下げる取り組みを並べた。

TorchTPU

TorchTPUは、GoogleとMetaのPyTorchチームが共同開発した、TPU向けのネイティブPyTorchバックエンドである。2026年10月20日のPyTorch ConferenceでOSSとして公開された。

  • PyTorchの「PrivateUse1」インターフェースで実装し、通常のPyTorchテンソルがそのままTPU上で動く。
  • デバイス指定を「tpu」に変えるだけで、学習ループのロジックを書き換えずに実行できることを目標にしている。
  • Eager実行を優先し、性能を詰めたい場合はtorch.compile経由でグラフ全体をXLAでコンパイルできる。
  • DDP、FSDPv2などの分散学習に対応する。報道では、最大8,192チップ規模でQwen 3 8Bを学習した際のMFU（モデルFLOPs使用率）が52%とされている。

PyTorch/XLAはソースコードに手を入れてコンパイル範囲を指定する必要があり、コンパイル時間も長かった。TorchTPUはこの問題を解消するために、バックエンドとして作り直したものである。

vLLM／SGLangのTPU対応

OSSの推論エンジンであるvLLMとSGLangについて、TPUのネイティブサポートを標準で提供する。GPU向けに組んだ推論サービングの構成を、エンジンを変えずにTPUへ移せる。

llm-dとGKE Inference Gateway

講演で「LLMD」と呼ばれていたのは、Kubernetes向けの分散推論フレームワークllm-dである。CNCF Sandboxプロジェクトで、2026年10月に1.0がリリースされた。vLLMなどの推論エンジンの前段に立ち、どのレプリカにリクエストを送るかを決める。

通常のロードバランサーはラウンドロビンで振り分けるため、同じ前置き（システムプロンプトや会話履歴）を持つリクエストが別々のレプリカに行き、そのたびにプリフィル（入力部分の計算）をやり直す。llm-dは次の仕組みでこれを避ける。

  • プレフィックスキャッシュ対応ルーティング：リクエストの先頭部分をハッシュ化し、その部分のKVキャッシュを持っている可能性が高いレプリカへ送る。
  • 負荷を考慮したルーティング：KVキャッシュ使用率、キューの長さ、処理中リクエスト数を合わせて評価する。
  • 階層型KVキャッシュ：HBMに収まらないKVキャッシュをホストメモリやストレージへ退避し、再利用する。
  • プリフィル／デコード分離：計算特性の違う2段階を別ノードに分ける。

エージェントは同じコンテキストを何度も送り直すため、この最適化の効果が大きい。Googleの発表では、Ironwood上のコーディング用途で、プレフィックス対応ルーティングとホストメモリ退避により、TTFT（最初のトークンが返るまでの時間）の中央値を85%以上短縮し、スループットを2.4倍にした。Vertex AI（現Gemini platform）では、プレフィックスキャッシュのヒット率が35%から70%に上がった。

GKE Inference Gatewayは、このllm-dのルーティング機能をマネージドで提供するものである。

NVIDIA GPUの選択肢

Google CloudはTPUと並行してNVIDIA GPUも提供しており、用途に応じて選べる。

インスタンス GPU
A4 NVIDIA HGX B200
A4X NVIDIA GB200 NVL72
A4X Max NVIDIA GB300 NVL72
A5X（ベアメタル） NVIDIA Vera Rubin NVL72。2026年11月GA予定
G4（分割利用） NVIDIA RTX PRO 6000 Blackwell Server Edition

A5Xは単一サイトで最大8万基、複数サイトで最大96万基のRubin GPUまで拡張できる構成とされている。

5. Agent Compute EngineとAgent Substrate

エージェントの実行環境として、Google Cloudは2つを用意した。2026年10月22日のAGNTCon + MCPConで発表されたものである。

項目 Agent Compute Engine Agent Substrate
位置づけ Google Cloudのマネージドサービス GKE（Kubernetes）上で動くOSSの実行ランタイム
隔離方式 エージェントごとにハードウェア隔離されたmicroVM（Cloud Hypervisor） microVMまたはgVisorを選択
提供状況 プレビューは今後数か月以内（料金未発表） 1.0がGKEでGA。CNCFへ寄贈

マルチレイヤーの隔離

Agent Compute Engineは、エージェント1体ごとに専用のmicroVMを割り当てる。microVMはCloud Hypervisorで動き、それぞれが独自のゲストカーネルを持つ。ゲストカーネルはホストから分離されているため、エージェントが任意のコードを実行しても、他のエージェントやホストに影響が及びにくい。起動時の信頼性確認には、Google独自のTitanチップとTitaniumを使う。

この基盤は、もともとGemini、Antigravity、Googleのモデル学習パイプラインの社内インフラとして作られたものである。

待機中は止め、状態ごと再開する

エージェントは、外部APIの応答や人間の承認を待つ時間が長い。Agent Compute Engineでは、ツールを実行したあとモデルが考えている間や、返答を待っている間に、サンドボックスがホストへ待機を通知する。その時点の作業メモリとディスクの状態をチェックポイントとして保存し、ホスト資源をほぼゼロまで解放する。次のツール呼び出しが来たら、保存した状態から素早く再開する。

Agent Substrateについて、Googleは次の値を公表している。

  • 起動：1秒未満。20万体の検証で毎秒500件の起動を維持
  • 一時停止・再開の遅延：500ミリ秒未満
  • 密度：従来比で最大10倍

OSやライブラリは全microVMで共有し、書き換えた部分だけを複製するCopy-on-Write方式でメモリを節約する。1つのスナップショットから数千のエージェントを並列にフォークする使い方も想定している。

ゼロシークレット設計

サンドボックスの中には、OAuthのリフレッシュトークンやサービスアカウント鍵などの永続的な資格情報を置かない。クラウドのメタデータサーバーにもアクセスできず、仮想NICやデフォルトゲートウェイもない。外部への通信はvirtio-vsock経由でプロキシを通り、Agent Gatewayへ向かう。

Agent Gatewayは、外向きのリクエストについてユーザーの委譲、エージェントID、ノードIDを検証し、エグレスポリシーとDLPルールを評価する。通信がゲートウェイを出る時点で本来の資格情報に差し替えるため、サンドボックスは最後まで資格情報を見ない。ゲストOSでroot権限を奪われても、盗める秘密が中にないという設計である。

CNCFへの寄贈

Googleは2026年11月、Agent Substrate、gVisor、OpenRLの3プロジェクトをCNCF（Cloud Native Computing Foundation）へSandboxとして寄贈すると発表した。Googleはこれを、2015〜2016年にKubernetesをCNCFへ寄贈したときになぞらえている。Kubernetesがコンテナのスケジューリングを標準化したように、Agent Substrateはステートフルなエージェントのスケジューリングを標準化することを狙っている。

提供状況のまとめ

発表内容 状態（2026年11月13日時点）
TPU 8t／TPU 8i 2026年4月発表、年内提供予定
TPU 8tx／TPU 8i Max 2026年11月9日発表、提供時期・価格は未発表
Project Suncatcher プロトタイプ衛星が軌道上で稼働中（研究段階）
TorchTPU OSSとしてGitHubで公開済み
llm-d 1.0リリース済み（CNCF Sandbox）
Agent Compute Engine プレビューは今後数か月以内
Agent Substrate 1.0がGKEでGA、CNCFへ寄贈
A5X（Vera Rubin NVL72） 2026年11月GA予定

記事中の性能値は、特記のない限りGoogle・NVIDIAが公表した値で、第三者による検証は済んでいない。

参考

次に読む