コンピューティング

エージェント型エンタープライズのためのクロスクラウドインフラストラクチャのイノベーション

Fri, 08 May 2026 02:00:00 +0000

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

エージェント型 AI の時代が人間の速度から機械の速度へと運用を加速させていますが、それと同時に、以前のテクノロジーインフラストラクチャに深刻なストレスを与えています。数千もの内部メッセージと複雑なクエリを生成するエージェントが、しかもさらに多くのエージェントを生み出すという新たな現実は、基盤となるシステムを限界に追い込んでいるのです。この状況の中、従来のネットワークやデータベースでは瞬く間に手に負えなくなり、新たなセキュリティ脆弱性が顕在化する可能性があります。

エージェントの時代に AI の可能性を最大限に引き出すには、安全で適応性の高い基盤が必要です。Google ではこれを、エージェント型エンタープライズ向けクロスクラウドインフラストラクチャと呼んでいます。Google は Google Cloud Next ‘26 で、このインフラストラクチャの 4 つの分野における一連の新しいイノベーションを発表します。

最新情報:

Fluid Compute: Google Compute Engine サービスと Kubernetes サービスの連携により、新しいコンピューティング機能とオーケストレーション機能が追加されます。これらの機能は、費用対効果と速度に優れた AI エージェントとエンタープライズワークロードを実現するものです。
安全なクロスクラウド接続: Agent Gateway、Cloud Armor などのツールで、AI エージェント向けの安全で管理されたネットワーキング基盤を簡素化します。この基盤には、クラウド間のエージェントトラフィックのオブザーバビリティも組み込まれています。
統合データレイヤ: スマートストレージ、Knowledge Catalog などのイノベーションで、受動的なデータアーカイブを動的な推論エンジンへと変換します。この推論エンジンが、実行に必要となるコンテキストを AI エージェントに渡します。
デジタル主権: Confidential External Key Management と、Google Distributed Cloud の新機能により、データの保存場所を問わずに Google の最先端のモデルと AI イネーブラーを利用できるようになります。

これら 4 つの分野それぞれの最新ニュースを詳しくご紹介します。

Fluid Compute

エージェントワークロードは動的であり、予測することはできません。このことは、従来のエンタープライズアプリケーションにも AI エージェント自体にも影響を与えます。そこで、Fluid Compute を実現するために、Google Compute Engine サービスと Google Kubernetes サービスが連携して動的にワークロードに適応し、リアルタイムで重みをシフトします。これにより、すべてのお客様にとって、費用対効果と速度に優れた AI エージェントとエンタープライズ向け運用ワークロードの実現が可能になります。

AI Hypercomputer が大規模な AI モデルトレーニング向けの素の処理能力を提供する一方で、Fluid Compute によって運用ワークロードとエージェントのニーズに対応します。エージェントが推論と強化学習へと移行する中、CPU は中心的な役割を取り戻しつつあります。CPU は、エージェントワークフローに必要な「分岐」ロジック、複雑な制御フロー、安全なコード実行サンドボックス（エージェントオーケストレーション、RL、SLM 推論、RAG 向けのサンドボックスなど）において優れた能力を発揮するためです。さらに、CPU はエージェントを安全に実行するために重要となるエージェントの隔離を可能にし、トレーニングで使用される GPU と TPU の並列処理能力を補完します。

Google は、従来のワークロードと AI エージェントを安全かつ大規模に実行できるようにするための新しい CPU ファミリー、GKE 機能、Hyperdisk ブロックストレージ機能を導入しています。

Google C4N シリーズ: このシリーズの VM は、エージェント型 AI の需要によってエンタープライズワークロードの速度が低下しないように、1 秒あたり最大 9,500 万パケットを処理します。これは、他の主要なハイパースケーラーと比べて最大 40% 高速なパフォーマンスです。これにより、セキュリティアプライアンス、ストリーミングメディア、オープンソースデータベースなどの要求の厳しいワークロードで、より小さいインスタンスサイズを使用するとしても、I/O ボトルネックが解消されます。
Hyperdisk Extreme を使用した Google M4N シリーズ: M4N は、エージェント、分析、ミッションクリティカルなデータベースからの膨大なデータ I/O の処理のニーズに対処するために、データパイプラインのボトルネックを解消してオーバープロビジョニングの必要をなくし、業界トップクラスのコアあたりの IOPS とスループットを実現しています。vCPU あたり 26.57 GB の RAM を提供する M4N を使用すれば、ミッションクリティカルなワークロードをより少ないコアでスケールして、優れた費用対効果を実現できます。たとえば、Hyperdisk Extreme を使用した M4N は、主要なハイパースケールクラウドと比較して、Oracle ワークロードの総所有コストを 20% 以上削減します。
GKE Agent Sandbox: このソリューションは、信頼できる gVisor でエージェントを隔離して保護し、クラスタごとに 1 秒あたり最大 300 個のサンドボックスを起動して需要の急増に対応します。GKE Agent Sandbox は、主要なハイパースケールクラウドの間で唯一利用可能なマネージドサンドボックステクノロジーを基盤としています。GKE Agent Sandbox で Google Axion N4A を使用して AI エージェントを実行する場合、競合他社よりも最大 30% 優れたコストパフォーマンスを実現します。

「Wayfair の AI 戦略は、Google Cloud での長年にわたる体系的なインフラストラクチャモダナイゼーションに基づいて構築されています。この戦略には、コアの e コマースエンジンとデータベースをレガシーシステムから移行すること、モノリシックなサービスをクラウドネイティブアーキテクチャに分解すること、データと分析プラットフォームを統合することが含まれています。Gemini Enterprise Agent Platform という基盤があるからこそ、他のすべてが可能になります。現在、カタログの拡充から、お客様が自分にぴったりの家を建てられるよう生成 AI が支援するショッピングエクスペリエンスまで、あらゆるものを Gemini Enterprise Agent Platform によって強化しています。また、私たちはこの同じ基盤を頼りに、AI が単に支援するだけでなく、あらゆる顧客タッチポイントとビジネス全体で積極的に発見、パーソナライズ、コマースを推進するエージェントとなる時代に向けて準備を整えています。」- Wayfair、最高技術責任者、Fiona Tan 氏

最新のコンピューティングイノベーションについては、こちらのブログ記事をご覧ください。

安全なクロスクラウド接続

エージェント型 AI は、予測可能な人間のリクエストを自律的な「推論ループ」に置き換えます。このループでは、エージェントが他のエージェントを呼び出し、そのエージェントが LLM を呼び出すため、コンピューティングとマシン間のトラフィックが急増することになります。こうしたエージェント型へのシフトは、ネットワークの予測可能性と人間以外の ID のセキュリティに関して他には見られない課題をもたらします。エージェント型 AI 向けに最適化されたクロスクラウドネットワークは、さまざまな環境間でデータを移動して、可視性とセキュリティによって従業員、顧客、エージェントをつなげます。クロスクラウドネットワークの新機能は次のとおりです。

Agent Gateway: Gemini Enterprise Agent Platform の「航空管制官」として、企業のエージェントトラフィックを管理およびオーケストレートします。MCP や A2A などのエージェントプロトコルをネイティブに理解し、すべてのエージェントのやり取りを検査して管理します。Google とサードパーティの ID および AI の安全性に関するサービスと連携して、アクセスの検証、攻撃のブロック、機密データの保護を目的とした詳細な検査を可能にし、コアビジネス全体でコンプライアンスを維持します。
Cloud Network Insights: ハイブリッドクラウドとマルチクラウドのインフラストラクチャ全体にわたる幅広い可視性を提供し、トラブルシューティングとネットワーク解決を迅速化します。Google Cloud、AWS、Azure、データセンター、インターネットアプリケーション、エージェントワークロード全体で、エージェント、ネットワーク、ウェブのエンドツーエンドのパフォーマンスを継続的にモニタリングします。Cloud Network Insights は、合成トラフィック分析を使用して、ホップごとのネットワークパスを可視化し、パフォーマンス低下の原因を特定できるよう支援します。また、オペレーションの自律性を高めるために、Cloud Network Insights には Gemini Cloud Assist の AI を活用した分析情報が結合されます。
強化された Cloud Next Generation Firewall（NGFW）と Cloud Armor: AI が生成するポリモーフィックマルウェアやゼロデイエクスプロイトの急増に対処するために、AI を活用した機械の速度での保護を提供します。Cloud NGFW の高度なマルウェアサンドボックスは、AI によって生成された脅威をリアルタイムでその場で防止します。一方、Cloud Armor のマネージドルールは、既知および未知の共通脆弱性識別子（CVE）の両方に対する自動保護を提供します。これらのサービスは Model Armor と連携して、AI エージェントのコミュニケーションのインテントと内容を分析します。

Google がデータセンター内外で AI 向けにネットワーキングを最適化した方法について詳しくは、こちらをご覧ください。

統合データレイヤ

AI エージェントの能力は、アクセスできるデータと与えられたコンテキストによって決まります。構造化データと非構造化データを使用するアプリケーションやプラットフォームが増えていますが、それらのデータを大規模にカタログ化、検索、活用するのは容易なことではなく、それが原因でエージェントの対応が非効率になる可能性があります。このギャップを埋めるためにエージェントに必要となるのは、すべてのデータがまとめられたクエリ可能なナレッジエンジン、つまり統合データレイヤです。これにより、エージェントは正確な情報源を特定してアクセスできるようになります。Next ‘26 では、統合データレイヤを強化する次の機能を取り上げます。

スマートストレージ: このソリューションは、新しいセマンティックインテリジェンスをデータオブジェクトに直接埋め込むことで、ダークデータを AI エージェントとトレーニングのための強力な知識アセットに変換します。自動アノテーション、エンティティ抽出、セマンティック検索などの新しい Google Cloud Storage 機能により、エージェントは必要とする特定のデータが組織全体にわたって存在するスプレッドシート、PDF、その他の非構造化形式のどれに隠されているかどうかにかかわらず、そのデータを瞬時に検出して使用できます。これにより、AI ソリューションの開発とデプロイが大幅にスピードアップします。AI ワークロードを加速するストレージイノベーションについて詳しくは、こちらをご覧ください。
Knowledge Catalog: Knowledge Catalog は、エージェントが最も正確な結果を提供できるように、データエステート全体にわたってビジネスの意味をマッピングし、グラウンディングされた信頼できる情報源を提供します。この基盤により、AI のトレーニングと推論が可能になり、データの移行が不要になります。エージェントは、データがどこにあっても、完全なコンテキストとガバナンスに沿って直接データとやり取りするため、モダナイゼーションが容易になります。

Google の Agentic Data Cloud の一部となっているスマートストレージと Knowledge Catalog により、データを受動的なアーカイブから動的な推論エンジンに変換できます。

「お客様のスマートホームとセキュリティソリューションをよりインテリジェントで便利なものにするためには、AI が不可欠です。Google Cloud のスマートストレージを活用すれば、BigQuery で配信される豊富なメタデータに自動的にアノテーションを付けることができます。データ検出とキュレーションの取り組みを拡大し、加速させたことで、AI 開発プロセスを数か月から数週間に短縮できたと同時に、信頼を築き、全体的な家庭環境を向上させるイノベーションを継続的に提供できるようになりました。」- Vivint、プロダクトおよび AI 担当バイスプレジデント、Brandon Bunker 氏

デジタル主権

エージェントの時代において、管理を犠牲にすることなくイノベーションを加速させようと目指す公共部門や企業のお客様にとって、デジタル主権は基本的な要件です。万能なソリューションというものは存在しません。そのため、Google ではパブリッククラウド、オンプレミス、ハイブリッドなど、あらゆる場所でさまざまなソブリン AI のニーズに対応できるよう、包括的な一連のサービスを設計しました。Google のソブリン AI ポートフォリオの新機能には、次のようなものがあります。

Confidential External Key Management: 組織は Confidential External Key Management を使用して、暗号鍵の完全な未編入領域、管理権、制御権と、暗号鍵を管理するポリシーを維持できます。Confidential External Key Management は、Confidential Compute を活用して、Google Cloud 内の改ざん防止環境で鍵管理エンドポイントをホストします。鍵の保存場所、鍵へのアクセスを許可するユーザー、アクセスを許可する状況は、お客様が管理できます。特権を持つ Google 管理者であっても、承認なしに鍵にアクセスすることはできません。また、承認はいつでも取り消すことができます。自社のデータを自社で管理できるというわけです。
Google Distributed Cloud 上の Gemini: GDC 上の Gemini を使用すると、企業はデータ主権のニーズを満たしながら、機密性の高い環境に Gemini を安全にデプロイできます。デプロイモデルの選択肢には、接続されたハードウェア上のマネージドソフトウェアや、エアギャップのある完全に切断されたソリューションなどがあります。最も制限の厳しい高度なセキュリティ環境であっても、強力な Gemini モデルから高度なコーディング、検索、その他のエージェント機能に至るまでの Google の最先端の AI 機能によるスケーリングが可能になりました。

さらに、すべてのソブリン AI ワークロードを加速および強化できるよう、Google Distributed Cloud では最新世代の AI インフラストラクチャと Gemini モデルを組み合わせたエンドツーエンドの AI スタックをサポートしています。このスタックには以下が含まれます。

NVIDIA Blackwell GPU: NVIDIA Blackwell（NVIDIA HGX B200）および NVIDIA Blackwell Ultra プラットフォーム（NVIDIA HGX B300）GPU は、第 5 世代 NVIDIA NVLink を活用して AI パフォーマンスを加速し、データセンター規模の帯域幅を環境に直接提供します。
新しい VM ファミリー: 新しい A4 ファミリーパッケージは、最も要求の厳しい推論タスクを処理する能力を提供し、ピーク時のコンピューティングを 2.25 倍に向上させます。メモリ最適化 M2 および M3 は、オンプレミスで大規模な ERP とデータ分析のワークロードに必要となる高いメモリ対 vCPU 比を実現します。
ストレージの強化: ゾーンあたりのストレージ容量が 6 倍に増え、パフォーマンスは 10 倍に向上しています。これによりストレージのボトルネックが解消されるため、オンプレミスで AI 推論を実行できます。今や、データインフラストラクチャは AI 推論のスピードで進化しています。

「弊社のお客様は、マルチテナントのリスクを伴わない、高性能なプライベート AI 推論を求めています。Google Distributed Cloud を使用すれば、機密データに関する厳格な要件を満たす、専用の低レイテンシ環境を提供できます。B200 と B300 で Gemini を実行できるため、推論速度を大幅に向上させ、スケーリングに必要となるトークンスループットをお客様に提供できます。」- Cirrascale Cloud Services、CEO / 共同創設者、Dave Driggers 氏

ビジョンを現実にする

以上の製品分野が収束した時点で、インフラストラクチャはエージェント時代に対応する高性能で安全かつ適応性のある基盤へと進化します。Google は単にツールを提供するだけでなく、企業や公共部門が AI とエージェントの力を最大限に活用できるようにするためのアーキテクチャブループリントを提供しています。

AI インフラストラクチャの主要な業界トレンドについて詳しくは、エージェント型 AI 時代のインフラストラクチャの現状に関するレポートをご覧ください。

- コンピューティングプラットフォーム部門プロダクト管理担当バイスプレジデント、Nirav Mehta

- Google Distributed Cloud 担当バイスプレジデント、Muninder Sambi

Cloud TPU と vLLM で LLM 推論を試そう — リソース確保からベンチマークまで

Fri, 01 May 2026 02:00:00 +0000

こんにちは、Google Cloud でインフラ領域を担当している佐藤です。

今回は、Cloud TPU v6e 上で vLLM を使い、大規模言語モデル Qwen3-32B の推論環境を構築する手順をハンズオン形式でお届けします。DWS Flex Start によるリソース確保から、パラメータチューニング、INT8 量子化、ベンチマークまで一通りカバーしています。

最近、大規模言語モデル（LLM）の推論環境への需要が急速に高まっています。しかし、ハイパフォーマンスなインフラをオンデマンドで調達しようとすると、特定の GPU/TPU Type やリージョンによっては「オンデマンドリソースの即時確保が困難」という課題に直面した—そんな経験はありませんか？

本記事では、Google Cloud の Dynamic Workload Scheduler (DWS) Flex Start モードを活用し、待機キュー経由でリソースの確保を効率的に行いつつ、オープンソースの高スループット LLM 推論エンジンである vLLM を用いて、大規模モデルである Qwen3-32B の推論環境を構築する実践的なハンズオン手順をご紹介します。このガイドを通じて、リソース確保からデプロイ、そしてパフォーマンスのベンチマークまでの流れを解説していきましょう。

TPU 確保方法の比較と DWS Flex Start モードの長所

Google Cloud の GPU/TPU リソースを確保する方法にはいくつかの種類があります。それぞれの長所と短所を理解することで、ワークロードに最適な選択が可能になります。

オプション	特徴とユースケース	期間 / 制限
オンデマンド	必要なときに即座にリソースを要求します。空きがあればすぐに利用可能ですが、需要が高い時期や特定のハードウェア（TPU v6e など）ではリソース枯渇により確保できない場合があります。	Min 1 分 / 制限なし
予約	ユーザーが指定した構成で 1 つ以上の VM の容量を確実に確保できます。Compute Engine のコミットメントである CUD (Commited use discounts) を利用して、 1 年や 3 年の期間で割引を適用することもできます。	Min 1 分 / 制限なしCUD 利用時は1 年 / 3 年固定
DWS Flex Start	【本記事の対象】キュー（列）に並んでリソースを待つ方式です。「利用可能になり次第」プロビジョニングされ、一度確保されれば最大 7 日間中断されることなく実行可能です。割引価格が適用されるため、コストパフォーマンスに優れます。即時性は不要ですが、検証やバッチ推論を完了させたい場合に適しています。	Min 1 分 / Max 7 日
スポット	余剰リソースを利用するため非常に安価ですが、いつでも Google 側から停止される可能性があります。耐障害性のあるワークロード向け。	Min 1 分 / Max 24 時間

では、なぜ Flex Start を使うのでしょうか。

オンデマンドや Spot では、「今すぐ使いたいがリソースがない」というエラーが返されることがありますが、DWS Flex Start を使用することで「キュー」にリソース要求が登録されます。バックグラウンドでリソースの空き状況が監視され、確保可能になった瞬間にプロビジョニングが行われるため、張り付いてリソース作成を連打する必要がなく、リソースプロビジョニングの成功率をぐっと上げられるのが大きな長所です。

vLLM と vLLM-TPU の違いとは？

ハンズオンに入る前に、今回利用する vllm-tpu イメージについて補足します。

vLLM（通常版）： 主に NVIDIA GPU (CUDA) や AMD GPU (ROCm) 向けに高度に最適化された LLM 推論エンジンです。PagedAttention というメモリ管理技術により、KV キャッシュの断片化を防ぎ、高いスループットを実現します。
vLLM-TPU： Google のカスタムシリコンである TPU アーキテクチャ上で、vLLM の PagedAttention や最適化技術を動作させるために特化した拡張実装・環境です。内部的には 2 つのモデルレジストリを確認した上でモデルコードを取得・実行します（下図参照）。そして Torchax によって PyTorch モデルコードが JAX として扱われ、TPU 上での最適な推論実行が可能になります。本ハンズオンでは vllm/vllm-tpu の Docker イメージを利用することで、複雑な依存関係やコンパイラの設定を意識することなく、すぐに TPU のパワーを推論に活用できます。

https://vllm.ai/blog/vllm-tpu から引用

ハンズオンガイド

1. TPU リソースのリクエスト (Flex Start)

まず、通常の gcloud compute tpus tpu-vm create ではなく、queued-resources create コマンドを使用します。このコマンドによって、1 章で触れた Flex Start によるリソース調達を自動化することができます。

code_block: <ListValue: [StructValue([('code', 'export TPU_NAME=takashix-tpuv6e\r\nexport ZONE=us-east5-a\r\nexport PROJECT=takashix-tpu\r\nexport QR_ID=takashix-qr-request # e.g. my-qr-request\r\n\r\ngcloud alpha compute tpus queued-resources create $QR_ID \\\r\n --node-id $TPU_NAME \\\r\n --project $PROJECT --zone $ZONE \\\r\n --accelerator-type v6e-4 \\\r\n --runtime-version v2-alpha-tpuv6e \\\r\n --provisioning-model flex-start \\\r\n --max-run-duration 24h'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6591ab9f40>)])]>

コマンドの意味について

--provisioning-model flex-start を指定することで、キューにリソース要求がエンキューされます。--max-run-duration 24h によって、利用開始から 24 時間後に自動的に終了するように設定しています。消し忘れによる課金防止にも役立ちますね。Spot VM で起動したい場合は、コマンドから alpha を外して --spot を指定することで起動できます。

キューに格納したいリソースを上記コマンドで作成した後はステータスに則って調達されます。ステータスの確認には以下のコマンドを実行してください。

code_block: <ListValue: [StructValue([('code', 'gcloud alpha compute tpus queued-resources list --project $PROJECT --zone $ZONE'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6591ab9640>)])]>

STATE が qr-request-spot のように ACTIVE になれば調達完了です。一方で takashix-qr-request のように WAITING_FOR_RESOURCES の場合、まだ調達できておらずリソース確保を待っている状態です。

※調達できない（STATE が Active にならない）場合は代わりに以下のコマンドを実行してください。

code_block: <ListValue: [StructValue([('code', 'gcloud alpha compute tpus queued-resources create $QR_ID \\\r\n --node-id $TPU_NAME \\\r\n --project $PROJECT --zone $ZONE \\\r\n --accelerator-type v6e-4 \\\r\n --runtime-version v2-alpha-tpuv6e \\\r\n --labels=purpose=flex-start'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6591ab9550>)])]>

2. インスタンスへの接続と Docker 環境設定

リソースが「ACTIVE」になったら、SSH 接続して環境を準備しましょう。本ガイドでは Qwen3-32B を利用することを想定し、Hugging Face の Token を設定します。

SSH 接続

code_block: <ListValue: [StructValue([('code', 'gcloud alpha compute tpus tpu-vm ssh $TPU_NAME --project $PROJECT --zone=$ZONE'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6591ab9e80>)])]>

Docker Image の設定

code_block: <ListValue: [StructValue([('code', 'export DOCKER_URI=vllm/vllm-tpu:latest'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6591ab9520>)])]>

Hugging Face Token の設定（<your HF token> はご自身の Token に置き換えてください）

code_block: <ListValue: [StructValue([('code', 'export HF_HOME=/dev/shm\r\nexport HF_TOKEN=<your HF token>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6591ab9cd0>)])]>

3. vLLM サーバーの起動とパラメータ・チューニング

Docker コンテナを --privileged および --net=host で起動します。これは TPU デバイスへの直接アクセスと、ホストの高速なネットワークをコンテナに許可するためです。また --shm-size 100gb を指定して、モデルの重みや共有メモリ領域が不足しないようにしています。

code_block: <ListValue: [StructValue([('code', 'sudo docker run -it --rm --name $USER-vllm --privileged --net=host \\\r\n -v /dev/shm:/dev/shm \\\r\n --shm-size 100gb \\\r\n --entrypoint /bin/bash ${DOCKER_URI}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6591ab9dc0>)])]>

以下のようにイメージのダウンロードが完了したら vLLM サーバーの起動完了です。

上記コマンドにより root@ から始まるプロンプトになっていれば、コンテナ内へのアクセスが成功したことになります。いよいよ vllm serve コマンドでモデルをデプロイしましょう。ここでのパラメータ設定が、推論のパフォーマンス指標であるスループットやレイテンシに大きく影響を与えます。

code_block: <ListValue: [StructValue([('code', 'export MAX_MODEL_LEN=4096\r\nexport TP=4\r\n\r\nvllm serve Qwen/Qwen3-32B \\\r\n --seed 42 \\\r\n --disable-log-requests \\\r\n --gpu-memory-utilization 0.98 \\\r\n --max-num-batched-tokens 2048 \\\r\n --max-num-seqs 256 \\\r\n --tensor-parallel-size $TP \\\r\n --max-model-len $MAX_MODEL_LEN'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6591ab9b50>)])]>

パラメータ	チューニングの解説と影響
--tensor-parallel-size $TP	モデルの重みをいくつの TPU チップに分割して配置するかを指定します。今回は v6e-4 (チップ 4 つ) を利用するため 4 を設定。32B という巨大なモデルを単一チップのメモリ内に載せることは不可能ですが、並列処理によって高速に分散処理が可能になります。
--gpu-memory-utilization	TPU の HBM（High Bandwidth Memory）のうち、どれだけを KV キャッシュ領域等のために予約するかの割合。デフォルト値よりも高い 0.98 まで引き上げることで、より多くのリクエストを同時処理（バッチ化）できるようになり、全体スループットが向上します。ただし、高すぎるとメモリ不足 (OOM) でクラッシュするリスクがあります。
--max-model-len	入力プロンプトと出力トークンの最大合計長。モデル本来の最大コンテキスト長（例: 32k など）をそのまま受け入れる設定にすると大量の KV キャッシュ用メモリを事前確保してしまい、結果的にバッチサイズが小さくなります。ユースケースに合わせて 4096 などに制限することで、同時並行処理数（max-num-seqs）を最大化でき効率的です。
--max-num-seqs / -batched-tokens	一度に処理するシーケンスの最大数とトークンの最大数。これらを増やすと全体のスループット (tok/s) は上がりますが、個々のリクエストのレスポンスタイム（TTFT など）が低下するトレードオフの関係にあります。ユースケースに合わせて調整します。

4. [オプション] INT8 量子化 (W8A8) を用いた Serving

TPU v6e の性能をさらに引き出し、巨大なモデルのメモリ使用量を削減するために、INT8（W8A8）量子化を有効化してモデルをサーブすることが可能です。

vLLM-TPU では内部的に Qwix と呼ばれる JAX 向け量子化ライブラリを使用します。量子化のためのコンフィグファイルはコンテナ内にすでに存在していることがほとんどですが、なかった場合は以下の手順で YAML 形式の設定ファイルを作成し、そのファイルを --additional-config オプションを用いてサーバー起動時に読み込ませてください。

量子化設定ファイル (int8_default.yaml) の作成

code_block: <ListValue: [StructValue([('code', "cat <<EOF > int8_default.yaml\r\nqwix:\r\n rules:\r\n - module_path: '.*'\r\n weight_qtype: 'int8'\r\n act_qtype: 'int8'\r\nEOF"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6591ab9af0>)])]>

INT8 有効化による vLLM サーバーの起動

code_block: <ListValue: [StructValue([('code', 'export MAX_MODEL_LEN=4096\r\nexport TP=4\r\n\r\nvllm serve Qwen/Qwen3-32B \\\r\n --seed 42 \\\r\n --disable-log-requests \\\r\n --gpu-memory-utilization 0.98 \\\r\n --max-num-batched-tokens 2048 \\\r\n --max-num-seqs 256 \\\r\n --tensor-parallel-size $TP \\\r\n --max-model-len $MAX_MODEL_LEN \\\r\n --additional-config=\'{"quantization": "int8_default.yaml"}\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6591ab9040>)])]>

ファイルの意味と量子化の仕組みについて

設定ファイル (int8_default.yaml) の役割: Qwix に対する量子化ルールの定義ファイルです。module_path: '.*' によってモデル内のすべてのレイヤーを対象とし、重み (weight_qtype) と活性化関数 (act_qtype) の双方を int8 フォーマットとして扱うよう指示します。これを W8A8 (Weight 8-bit, Activation 8-bit) 量子化と呼びます。
量子化の方法: vLLMがモデルをロードして XLA コンパイルする際、このルールに基づき動的に計算グラフが書き換えられます。ロードされる FP16/BF16 の重みは TPU メモリである HBM 上で INT8 に圧縮・変換され、推論時にも INT8 の行列積として実行されます。これにより、メモリ帯域のボトルネックが緩和されると同時に、TPU v6e に搭載された強力な INT8 演算器の性能が引き出され、スループットの向上とレイテンシの削減が期待できるでしょう。
利用するモデル: Qwen3-32B-GPTQ-Int8 などの FP8 や INT8 ですでに Weight が保存されたモデルはフォーマットが vllm-tpu でサポートされていない可能性があるため、基本的には BF16 の重みをロードできるように HF 上の Qwen3-32B などのデフォルトモデルを利用して Post-Quantization を行うことを推奨します。

上記の vllm serve コマンドでモデルの serve に成功すると Application startup complete. というメッセージが表示されます。

5. 動作確認とベンチマーク

Step 5.1. API エンドポイントへのテストリクエスト

別のコンソールを開いて VM およびコンテナへ接続し、OpenAI 互換の API エンドポイント経由で推論テストを行いましょう。新しいコンソールの方で環境変数を設定していない場合は、以下のように再度設定を行ってから SSH コマンドを実施してください。

code_block: <ListValue: [StructValue([('code', 'export TPU_NAME=takashix-tpuv6e\r\nexport ZONE=us-east5-a\r\nexport PROJECT=takashix-tpu'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6591ab9490>)])]>

VM への SSH 接続

code_block: <ListValue: [StructValue([('code', 'gcloud compute tpus tpu-vm ssh $TPU_NAME --project $PROJECT --zone=$ZONE'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6591ab9df0>)])]>

コンテナへの接続

code_block: <ListValue: [StructValue([('code', 'sudo docker exec -it $USER-vllm bash'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6591ab9610>)])]>

推論テストの実施

code_block: <ListValue: [StructValue([('code', 'curl http://localhost:8000/v1/completions \\\r\n -H "Content-Type: application/json" \\\r\n -d \'{\r\n "model": "Qwen/Qwen3-32B",\r\n "prompt": "I love the mornings, because ",\r\n "max_tokens": 200,\r\n "temperature": 0\r\n }\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f65911b1fd0>)])]>

以下のようにレスポンスが返ってくれば成功です。

code_block: <ListValue: [StructValue([('code', '{"id":"cmpl-aa8f0d83a90554a0","object":"text_completion","created":1773895036,"model":"Qwen/Qwen3-32B","choices":[{"index":0,"text":"1) I get to see the sun rise and 2) I get to see the sun rise. I know, I know, it\'s the same thing, but I like to think of it as two different reasons. Anyway, I was out there this morning, and I saw the sun rise. It was beautiful. The sky was all pink and orange and yellow, and the sun was just coming up over the horizon. I took a picture of it, but it didn\'t turn out very well. The colors were all washed out, and the sun was just a white blob. I guess that\'s why they say a picture is worth a thousand words. I can\'t even describe how beautiful it was. I was so inspired, I went inside and made a pot of coffee. I used my favorite coffee beans, the ones that are from Ethiopia. They have a really strong flavor, and they make my coffee taste like it\'s from a coffee shop. I added some milk and a little","logprobs":null,"finish_reason":"length","stop_reason":null,"token_ids":null,"prompt_logprobs":null,"prompt_token_ids":null}],"service_tier":null,"system_fingerprint":null,"usage":{"prompt_tokens":7,"total_tokens":207,"completion_tokens":200,"prompt_tokens_details":null},"kv_transfer_params":null}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f65906e2be0>)])]>

Step 5.2. ベンチマークテストの実施

推論サーバーが正しく稼働していることが確認できたら、vLLM に同梱されている公式ベンチマークスクリプトを用いて、本番環境を模した負荷テストを実施しましょう。

code_block: <ListValue: [StructValue([('code', 'export MAX_INPUT_LEN=1800\r\nexport MAX_OUTPUT_LEN=128\r\nexport HF_TOKEN=<your HF token>\r\n\r\ncd /workspace/vllm\r\nvllm bench serve \\\r\n --backend vllm \\\r\n --model "Qwen/Qwen3-32B" \\\r\n --dataset-name random \\\r\n --num-prompts 1000 \\\r\n --random-input-len=$MAX_INPUT_LEN \\\r\n --random-output-len=$MAX_OUTPUT_LEN \\\r\n --seed 100'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f65906e23a0>)])]>

ベンチマークパラメータの意味と影響：

ここでは、1000 個のリクエスト（--num-prompts 1000）を並行してサーバーに投げ込んでいます。--random-input-len と --random-output-len を変えることで、たとえば入力を長くすれば RAG のような prefill 負荷が高いケースを、入出力を同程度にすれば翻訳や対話のような decode 負荷が高いケースを再現できます。

入力トークン長（今回は 1800）を長く設定すると、モデルの Prefill（初回計算）フェーズの負荷が高まり、TTFT（Time To First Token: 最初のトークンが出力されるまでの時間）が増大する傾向があります。逆に、このベンチマーク環境で出力スループットを示す Output token throughput (tok/s) が大きく表示されていれば、TPU の並列計算能力をしっかり引き出せている証拠となります。

ベンチマーク結果の例：

結果 1 - 本ガイド記載のパラメータ通りでのベンチマーク (INT8 量子化なし)

code_block: <ListValue: [StructValue([('code', '============ Serving Benchmark Result ============\r\nSuccessful requests: 1000 \r\nFailed requests: 0 \r\nBenchmark duration (s): 112.72 \r\nTotal input tokens: 1800000 \r\nTotal generated tokens: 128000 \r\nRequest throughput (req/s): 8.87 \r\nOutput token throughput (tok/s): 1135.59 \r\nPeak output token throughput (tok/s): 2965.00 \r\nPeak concurrent requests: 1000.00 \r\nTotal token throughput (tok/s): 17104.85 \r\n---------------Time to First Token----------------\r\nMean TTFT (ms): 54347.41 \r\nMedian TTFT (ms): 54432.95 \r\nP99 TTFT (ms): 108306.56 \r\n-----Time per Output Token (excl. 1st token)------\r\nMean TPOT (ms): 99.48 \r\nMedian TPOT (ms): 104.55 \r\nP99 TPOT (ms): 105.25 \r\n---------------Inter-token Latency----------------\r\nMean ITL (ms): 99.49 \r\nMedian ITL (ms): 113.47 \r\nP99 ITL (ms): 114.83 \r\n=================================================='), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f659c1ecca0>)])]>

結果 2 - 本ガイド記載のパラメータ通りでのベンチマーク (INT8 量子化あり)

code_block: <ListValue: [StructValue([('code', '============ Serving Benchmark Result ============\r\nSuccessful requests: 1000 \r\nFailed requests: 0 \r\nBenchmark duration (s): 99.15 \r\nTotal input tokens: 1800000 \r\nTotal generated tokens: 128000 \r\nRequest throughput (req/s): 10.09 \r\nOutput token throughput (tok/s): 1290.96 \r\nPeak output token throughput (tok/s): 3904.00 \r\nPeak concurrent requests: 1000.00 \r\nTotal token throughput (tok/s): 19445.13 \r\n---------------Time to First Token----------------\r\nMean TTFT (ms): 47918.69 \r\nMedian TTFT (ms): 47875.01 \r\nP99 TTFT (ms): 95451.81 \r\n-----Time per Output Token (excl. 1st token)------\r\nMean TPOT (ms): 97.67 \r\nMedian TPOT (ms): 103.41 \r\nP99 TPOT (ms): 103.56 \r\n---------------Inter-token Latency----------------\r\nMean ITL (ms): 97.68 \r\nMedian ITL (ms): 103.34 \r\nP99 ITL (ms): 104.47 \r\n=================================================='), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f659158a520>)])]>

結果 3 - 非同期スケジューリング有効でのベンチマーク (INT8 量子化あり)

利用コマンド

code_block: <ListValue: [StructValue([('code', 'vllm serve Qwen/Qwen3-32B \\\r\n --seed 42 \\\r\n --disable-log-requests \\\r\n --gpu-memory-utilization 0.98 \\\r\n --max-num-batched-tokens 2048 \\\r\n --max-num-seqs 256 \\\r\n --tensor-parallel-size $TP \\\r\n --max-model-len $MAX_MODEL_LEN \\\r\n --async-scheduling \\\r\n --additional-config=\'{"quantization":"int8_default.yaml"}\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f659c3dc5b0>)])]>

code_block: <ListValue: [StructValue([('code', '============ Serving Benchmark Result ============\r\nSuccessful requests: 1000 \r\nFailed requests: 0 \r\nBenchmark duration (s): 91.67 \r\nTotal input tokens: 1800000 \r\nTotal generated tokens: 128000 \r\nRequest throughput (req/s): 10.91 \r\nOutput token throughput (tok/s): 1396.35 \r\nPeak output token throughput (tok/s): 4689.00 \r\nPeak concurrent requests: 1000.00 \r\nTotal token throughput (tok/s): 21032.45 \r\n---------------Time to First Token----------------\r\nMean TTFT (ms): 44362.33 \r\nMedian TTFT (ms): 44326.34 \r\nP99 TTFT (ms): 88584.15 \r\n-----Time per Output Token (excl. 1st token)------\r\nMean TPOT (ms): 90.71 \r\nMedian TPOT (ms): 96.22 \r\nP99 TPOT (ms): 96.39 \r\n---------------Inter-token Latency----------------\r\nMean ITL (ms): 90.71 \r\nMedian ITL (ms): 96.17 \r\nP99 ITL (ms): 97.31 \r\n=================================================='), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f659c4425b0>)])]>

非同期スケジューリングの有効化 (--async-scheduling)

CPU 側のリクエストスケジューリングと、TPU 側のモデル実行を非同期で行うことで、ホストとデバイス間の待機時間をなくし、スループットを数 % 〜 10 % 程度押し上げる効果が確認されています。

結果の比較

以下の表にそれぞれの条件でのスループットを比較したところ、INT8 での量子化を行い非同期スケジューリングの有効化も併用すると 123 % のパフォーマンス向上がみられました。

Configurations	Mean TTFT (ms)	Total token throughput (tok/s)	TTFTImprovement	Throughput Improvement
INT8 量子化なし	54,347.41	17104.85	100 %	100 %
INT8 量子化あり	47918.69	19445.13	113 %	114 %
INT8 量子化あり + 非同期スケジューリングあり	44,362.33	21032.45	123 %	123 %

Configurations

Mean TTFT (ms)

Total token throughput (tok/s)

TTFTImprovement

Throughput Improvement

INT8 量子化なし

54,347.41

17104.85

100 %

INT8 量子化あり

47918.69

19445.13

113 %

114 %

INT8 量子化あり +

非同期スケジューリングあり

44,362.33

21032.45

123 %

量子化に伴うモデル精度の変化には注意を払う必要がありますが、チューニングを行う際にはぜひ今回利用したオプションもご参照ください。

6. クリーンアップ：リソースの削除

検証が完了したら、余分なコストや Quota の消費を防ぐため、リソースの削除を行います。通常の VM と異なり、キューに格納されたリソースは「SUSPENDED」などの状態に関係なく Quota の割り当てを消費し続けます。今後の別の要求がブロックされるのを防ぐため、明示的に削除コマンドを実行しましょう。

code_block: <ListValue: [StructValue([('code', 'gcloud alpha compute tpus queued-resources delete $QR_ID \\\r\n --zone=${ZONE} --force'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6590acf700>)])]>

Warning: ハンズオン終了後は、上記の queued-resources delete コマンドを実行してください。tpu-vm delete だけではキューのエントリが残り、Quota 消費の原因となる可能性があります。

まとめ

本記事では、TPU v6e 上で DWS Flex Start を活用した効率的なリソース調達と、vLLM を用いた推論環境の構築・評価までの一連の流れをご紹介しました。

他の Model などの Recipe は以下のリポジトリに公開されていますのでご参照ください。

https://github.com/AI-Hypercomputer/tpu-recipes/tree/main/inference/trillium/vLLM

Flex Start の活用によるリソース枯渇状態からのプロビジョニング成功率向上、vllm-tpu コンテナを用いた容易な最適化環境の構築、そして gpu-memory-utilization などのパラメータチューニングによるスループットとレイテンシのバランス調整は、本番環境における大規模モデル運用において非常に重要なノウハウとなります。

ぜひみなさんの LLM ワークロードでも試してみてください。

第 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

コンピューティングの最新情報: コアワークロードとエージェントワークロードのスケーリング

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

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

Google Cloud Next では、エージェントの世界における中核的な汎用ワークロードと AI ワークロードを、より高いパフォーマンスと低コストで実現するための、さまざまなコンピューティング機能を発表します。

その重要性: IT リーダーや開発者は、エージェント型 AI と、ウェブサーバー、データベース、エンタープライズアプリケーションといった日々のカスタマーエクスペリエンスを支える汎用ユースケースとの間で、コンピューティングへの投資とリソースのバランスを取る必要に迫られています。

エージェントはコンピューティングインフラストラクチャに予測不能な負荷をかけることがあり、その需要はしばしば指数関数的に増加します。1 回のユーザーインタラクションであっても、数百もの同時実行（高スループットかつ低レイテンシ）タスクが瞬時に開始される場合があります。一方、汎用ワークロードは、エージェントの世界を支えるために必要なデータを生成して保持します。静的でサイロ化されたインフラストラクチャに依存してこれらのワークロードを実行すると、パフォーマンスのボトルネックや費用の増大を招くおそれがあり、需要の急増に組織として対応できなくなる可能性があります。

世界規模の旅行アプリケーションを例に考えてみましょう。単純なバカンスの検索ひとつで、エージェントによる在庫チェック、動的料金設定モデル、AI によるパーソナライズされた旅行プラン作成といった、膨大なオーケストレーションが即座にトリガーされます。最新のアーキテクチャがなければ、このような需要の急増によってコアとなる予約データベースが過負荷状態になり、業務が停止してしまう可能性があります。

Google は、柔軟なコンピューティング基盤でこの課題に対処します。汎用ワークフローとエージェントワークフローの両方に対応する Google Cloud インフラストラクチャにより、パフォーマンス、容量、スケールをリアルタイムで柔軟に調整することで、双方のワークフローのメリットを最大限に引き出します。この動的な柔軟性は、Google Kubernetes Engine（GKE）の自動オーケストレーションと新たに導入された Agent Sandbox に直接支えられており、安全で分離された実行環境をマシンレベルの速度で即座にプロビジョニングできます。

それでは、Next ‘26 で発表された新しいコンピューティング機能を詳しく見ていきましょう。

AI ワークロードと汎用ワークロードを同時に実行

エージェントによるプランニングや強化学習は、予測不能な自律タスクのバーストを処理するために、きわめて流動性の高いコンピューティングに依存しています。エージェントが生成したコードを分離するために静的インフラストラクチャに依存すると、プロビジョニングに深刻な遅延が生じ、クラウドの予算が大幅に膨らむ可能性があります。適応型のクラウド基盤を導入することで、こうしたボトルネックを解消できます。GKE Agent Sandbox を活用すると、チームは数千もの実行環境を安全に起動できるようになります。これらのスケーラブルなサンドボックスと効率的な Google Axion プロセッサを組み合わせることで、組織は総所有コストを最適化しながら、AI イノベーションを推進できます。

Google Cloud コンピューティングに関する最新リリースと発表の内容は次のとおりです。

Google Axion N4A の一般提供開始: Google 独自のカスタム Arm ベース Axion CPU のアジリティを活用できます。Java アプリケーション、スケールアウトウェブサーバー、スタートアップ / エンタープライズ / パートナーが構築する SaaS など、コスト重視のワークロードにおいて、同等の現行世代 x86 ベース VM と比較して最大 2 倍優れたコストパフォーマンスを実現します。詳しくはこちらをご覧ください。
コストパフォーマンスに優れた Axion N4A を搭載した GKE Agent Sandbox の一般提供開始: GKE Agent Sandbox は、ハイパースケーラーの中で唯一のネイティブサンドボックスサービスとして、スケーラブルで低レイテンシのインフラストラクチャを提供します。パフォーマンスを損なうことなく、エージェントが信頼できないコードやツール呼び出しを安全に実行できるように設計されています。Google Axion を使用すると、費用や選択肢を妥協することなく、最先端のインフラストラクチャ上にエージェントを構築できます。Google Axion N4A インスタンスで実行される GKE Agent Sandbox は、他社主要ハイパースケールクラウドプロバイダと比較して最大 30% 優れたコストパフォーマンスを実現します。GKE Agent Sandbox はこちらからお試しいただけます。
Google 初の Axion ベアメタルインスタンス「Google Axion C4A.metal」のプレビュー版を公開: C4A.metal インスタンスは、ネストされた仮想化に伴うパフォーマンスオーバーヘッドや複雑さを排除し、Android 開発、自動車シミュレーション、CI / CD パイプライン、セキュリティワークロード、カスタムハイパーバイザに対応します。C4A.metal は今年の夏に一般提供開始予定です。詳しくは、こちらをご覧ください。
C4 インスタンスが、すべての構成において Intel Xeon 6（Granite Rapids）のサポートを拡充: ネイティブ FP16 サポートを備えた Intel AMX を活用して、LLM 推論やベクトル検索などの AI ワークロードでスループットの向上、レイテンシの短縮、パフォーマンスの向上を実現します。これにより、他の大手ハイパースケーラーが提供する同等の Intel Xeon 6 ベース VM と比較して、13% 優れたコストパフォーマンスを提供します。C4 VM は、すべての構成で Intel Xeon 6 プロセッサを搭載できます。詳しくはこちらをご覧ください。
フレキシブル CUD の拡張サポートを一般提供開始: フレキシブル確約利用割引により、TCO を最適化しながら、複数のリージョンと VM ファミリーにわたって費用を移行できるようになりました。サポート対象が拡大され、メモリ最適化（M1～M4）VM ファミリーと HPC 最適化（H3、H4D）VM ファミリーに加え、Cloud Run にも対応しています。詳しくはこちらをご覧ください。

お客様からは次のような声が寄せられています。

Unity: Unity は、Unity Vector を使用してリアルタイム AI の費用構造を再定義しています。Unity はオンデマンドの特徴処理ワークロードを Google Axion N4A インスタンスに移行することで、レイテンシを犠牲にすることなく、費用対効果を 20% 改善しました。Unity Vector が需要の増加に対応するためにスケールアップする中でも、N4A インスタンスへの移行により、サステナブルな費用で業界トップクラスのパフォーマンスを提供し続けています。

Deutsche Börse: ドイツを代表する市場インフラストラクチャプロバイダの Deutsche Börse は、最新世代の C4 および C4D インスタンスを含む数十もの基幹金融アプリケーションを Google Compute Engine VM に移行、モダナイズしました。これにより、レイテンシの影響を受けやすい Oracle データベースやポストトレード処理を大規模にサポートするとともに、リリース速度、運用のアジリティ、復元力の向上を実現しました。これにより、日々数百万件に及ぶ金融取引を処理するために必要な一貫したパフォーマンスを実現し、製品化までの時間を 58% 短縮、TCO を 33% 削減しました。

WP Engine: WP Engine は、ミリ秒単位の遅延も許されない数百万件のデジタルエクスペリエンスを支えています。C4D インスタンスと N4D インスタンスで GKE クラスタを実行することで、WP Engine はモバイルデバイス向けに最適化された REST API のレイテンシを最大 60% 削減し、データ量の多いアプリケーションリクエストの処理を最大 51% 高速化しました。

eDreams ODIGEO: eDreams ODIGEO は、ミリ秒単位の差がカスタマーエクスペリエンスを左右する、AI を活用した大規模な旅行プラットフォームを運営しています。同社は、基盤となる Java ベースの e コマースモジュールを GKE から Axion 仮想マシンへ移行しました。これにより、数週間かかっていた手動によるコード最適化が不要になり、コードを一切変更することなく P95 レイテンシを 75% も改善できました。また、従来の x86 インフラストラクチャでは達成できなかったコスト効率で、グローバルサービスをスケールできる価格性能比も実現しました。

Chainguard: 基盤となるソフトウェアビルドシステムで絶対的な分離を重視する Chainguard は、新しい Axion C4A ベアメタルインスタンスをデプロイしました。これにより、パッケージビルドの強固なハイパーバイザセキュリティ境界を確立し、アーキテクチャのパリティを保ったまま開発パイプラインを保護します。さらに、ビルドのパフォーマンスを損なうことなく、堅牢な保護を実現します。

I/O やレイテンシの影響を受けやすいワークロードを同時に実行

AI ワークロードとコアワークロードはいずれも、データの保存、読み取り、移動を単一の高性能なオペレーションとして実行できる機能に依存しています。従来、これらの処理ステージは、vCPU 数に依存するネットワークやストレージの制限によって遅延が生じ、AI モデルが機能するために必要なデータが不足してしまうことがありました。高速データアクセスを実現する Hyperdisk の強化されたパフォーマンスと、一貫した転送を実現する高性能ネットワーキングを活用することで、これらの制約を解消できます。データパイプラインをコンピューティングとは独立してスケールできるようにすることで、AI トレーニングや I/O の影響を受けやすいワークロードは、需要のピーク時でも必要な専用帯域幅を確保でき、安定したパフォーマンスを維持できます。

C4N（プレビュー版）: モバイルアプリの同時リクエストやリアルタイムの在庫更新といった高負荷ネットワークアプリケーションを実行すると、トラフィックのピーク時にボトルネックが発生する可能性があります。C4N は、複雑なパケット処理をオフロードする Titanium アダプタを備えており、業界トップクラスの毎秒 9,500 万パケットというスループットを実現します。他の主要なハイパースケーラーと比較して、高トラフィックネットワークアプリケーションにおいて 40% の性能優位性を発揮します。大規模なデータセットの高速転送を目的に設計された C4N は、VM 間で最大約 400 Gbps の帯域幅を提供し、vCPU あたりの帯域幅が 4 倍に向上しています。また、インターネットゲートウェイを介した下り（外向き）ネットワーク帯域幅は、C4 VM と比較して 8 倍に向上しています。また、Hyperdisk Extreme を搭載した C4N は、25 GiB/秒のブロックストレージスループットと約 100 万 IOPS を達成し、最新のデータベースやエンタープライズ AI アプリケーションに必要な低レイテンシかつ高速のデータアクセスを実現します。C4N プレビュー版へのアクセスはこちらからご登録いただけます。
M4N（プレビュー版）: メモリ使用量の多いデータベースを実行する場合、メモリ速度を確保するためにコンピューティングコア（vCPU）をオーバープロビジョニングする必要があり、ソフトウェアライセンス費用の増加につながります。この問題を解決するために、新しい M4N シリーズを導入しました。Hyperdisk Extreme を搭載した M4N で Oracle ワークロードを実行すると、TCO を 20% 以上削減できます。また、vCPU あたり 26.57 GiB の RAM を活用することで、はるかに少ないコア数でスケールでき、より効率的に Oracle を実行できます。M4N と Hyperdisk Extreme を組み合わせることで、主要ハイパースケーラーのなかでも、ハイメモリインスタンスにおけるコアあたりの IOPS とスループットでトップレベルの性能を発揮します。プレビュー版には、こちらからご登録いただけます。
Z4D の発表: 新しい Z4D インスタンスにより、I/O 集約型のワークロードを最適化し、ネットワークベースのストレージボトルネックを解消します。ノード上で最大 84 TiB の高性能ローカル SSD を直接確保することで、組織は SQL、NoSQL、ベクトルデータベース向けに膨大なデータセットを処理できるようになります。Z4D は、C4N および M4N と同等の、最大 400 Gbps の VM 間帯域幅を提供します。Z4D の仮想マシンとベアメタルインスタンスは、近日中にプレビュー版としてリリースされる予定です。

お客様から寄せられた声をご紹介します。

Ericsson: 5G コアのワークロードは本質的にネットワーク負荷が高く、高スループットのパケット処理と決定論的なレイテンシが求められます。標準的なパブリッククラウドインスタンスでは、大規模環境でこれらを維持するのは容易ではありません。Google Cloud C4N を活用することで、Ericsson On-Demand を支えるネットワークパフォーマンスの最適な選択肢を見つけました。ネットワークに最適化されたコンピューティングに重点を置いた C4N のアーキテクチャにより、Ericsson の 5G Core-as-a-Service は、最近達成した 1 Tbps など、前例のないスループットレベルを実現しながら、顧客が期待するキャリアグレードの信頼性を維持しています。

Teradata: Teradata の Autonomous Knowledge Cloud は、世界最大規模の企業がエンタープライズインテリジェンスを活用し、信頼できるデータを測定可能なビジネス成果へと変換できるようにします。顧客は Teradata を活用し、パフォーマンスと効率が価値を直接左右する、ミッションクリティカルかつ I/O 集約型の分析を大規模に実行しています。C4N インスタンスは、このような要求の厳しいワークロードに適しており、優れたコストパフォーマンスを実現するとともに、より効率的で最適化されたデプロイをサポートします。C4N を利用することで、Teradata は顧客のインサイト獲得を加速し、安心してスケールできる環境を提供します。さらに、データと AI への投資からより大きな成果を引き出せるよう支援します。

厳しいストレージ要件に対応

ウェブサーバー、アプリケーション、データベースなどの基盤となるワークロードには、エージェントの世界が機能するために必要なデータが蓄積されています。この重要な情報を固定的なハードウェア上でサイロ化すると、ボトルネックが発生し、企業のモダナイゼーションが完全に停滞する可能性があります。たとえば、グローバルな小売ブランドがホリデーシーズンのプロモーションを実施しているとします。しかし、従来のハードウェアではエージェント型クエリの急増に処理が追いつかず、在庫データベースがタイムアウトして、顧客のリクエストが破棄されてしまいます。

組織は、データ配信を滞らせないように、vCPU あたりの IOPS とスループットに優れた、トップレベルのパフォーマンスを発揮するデータベースホストを必要としています。これらのアプリケーションを最新のクラウドインフラストラクチャに移行することで、総所有コストと運用スループットが大幅に向上します。戦略的なクラウド移行を通じて、モダナイゼーションを妨げるアーキテクチャ上の障壁を排除し、AI 活用に向けてデータの価値を引き出せます。スループットと容量に左右されやすいワークロード向けの、Fluid Compute の新機能をご紹介します。

Hyperdisk Balanced の改善: Hyperdisk Balanced は、アプリケーションやリレーショナルデータベースなどの汎用ワークロード向けに、高速で効率的なブロックストレージを提供します。Hyperdisk Balanced を使用すると、ボリュームあたり最大 2.4 GiB/秒のスループットと 16 万 IOPS を実現します。これは、他のハイパースケーラーの汎用ブロックストレージサービスを上回る性能であり、平均レイテンシも代替サービスよりも低く抑えられます。Hyperdisk Balanced High Availability を使用すると、SQL Server や PostgreSQL などの高可用性データベースにおいて、ディスク全体のパフォーマンスをアクティブな VM に動的にルーティングすることで、4 倍のパフォーマンス向上を実現できます。これにより、ストレージのオーバープロビジョニングが不要になります。ゼロダウンタイムの暗号鍵のローテーションとインスタントスナップショットの整合性グループを活用することで、より簡単にセキュリティを強化できます。これらの機能により、汎用ワークロードでの TCO 削減、パフォーマンスの向上、ワークロードのレジリエンス強化を実現できます。詳しくはこちらをご覧ください。
Hyperdisk ML のパフォーマンス向上と Hyperdisk Exapools の一般提供: 合計スループットが（1.2 TiB/秒から）2 TiB/秒に向上した Hyperdisk ML は、AI ストレージのボトルネック解消に貢献します。ディスクあたりのスループットが競合製品の 200 倍以上でり、貴重なアクセラレータクラスタをアイドル状態にさせません。これにより、AI コンピューティングの ROI を最大化しながら、次世代のインテリジェントエージェントを支えます。さらに Hyperdisk Exapools は、大規模なトレーニング要件に対応するため、あらゆるハイパースケーラーの中で、AI クラスタあたり最高水準の総合ブロックストレージ性能と容量を提供します。Hyperdisk ML と Hyperdisk Exapools について、詳細をご覧ください。
Z4M の発表: 最大 168 TiB のローカル SSD と最大 400 Gbps のネットワーク帯域幅、RDMA のサポート、ベアメタルシェイプを提供し、分散並列ファイルシステムや大規模な AI / ML ワークロードの実行に対応します。Z4M は Cluster Director と統合され、アクセラレータとコロケーションするオプションを提供することで、データへの高速かつ低レイテンシのアクセスを実現します。Z4M VM とベアメタルインスタンスは、2026 年第 3 四半期にプレビュー版が提供される予定です。

お客様から寄せられた声をご紹介します。

Shopify: ブラックフライデーの週末セール期間中、Shopify は 8,100 万人の購入者に対して 1 億 3,600 万個の荷物を追跡し、146 億ドルを超える取引を処理しました。この処理は、Compute Engine の Z シリーズを基盤とするストレージ上に構築された Shop アプリを使用して行われ、その間、速度や信頼性を損なうことはありませんでした。

HubX: 迅速なモデル読み込みがユーザーエクスペリエンスを左右する、AI 搭載モバイルアプリの膨大なポートフォリオを運用する中で、HubX は GKE に Hyperdisk ML をデプロイし、深刻な I/O ボトルネックを解消しました。この専用ストレージレイヤを活用することで、HubX は数百の同時リーダーをサポートし、トラフィックが急増するピーク時でも Pod の初期化時間を 30 倍に短縮できました。これにより、アイドル状態のアクセラレータにかかる費用を大幅に削減し、複雑な推論ワークロードを想定どおりにスケールできました。

エージェントの時代に対応する流動的なインフラストラクチャ

基盤ワークロードとエージェントが容量やパフォーマンスを奪い合う必要がなくなります。Google Cloud の Fluid Compute を活用することで、ボトルネックを回避し、基盤ワークロードと AI ワークロードの双方が連携して最大限のパフォーマンスを発揮できる、適応型のクラウドインフラストラクチャを実現できます。

準備ができたら、 Google Cloud コンソールにアクセスして、次の大規模プロジェクトに向けて VM をスピンアップしましょう。または、Migration Center の AI 搭載ツールセットを使用して、費用の見積もり、ビジネスケースの作成、モダナイゼーションオプションの評価を行い、移行計画を開始することもできます。

- コンピューティングプラットフォーム部門プロダクト管理担当バイスプレジデント、Nirav Mehta

Google Distributed Cloud の新たなイノベーション

Mon, 27 Apr 2026 02:00:00 +0000

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

このたびの Google Cloud Next において、Gemini と Google の高度な AI スタックをデータの所在地に導入する Google Distributed Cloud（GDC）の新機能を発表いたしました。これにより、AI イノベーションと主権を両立させることが可能になります。これは、「ソブリンネオクラウド」アーキテクチャの触媒として機能します。

GDC を使用すると、Google Cloud をデータセンターやエッジなど、お客様が必要とする場所で利用できるようになります。特定のセキュリティとハードウェアの要件を満たすために、2 つの異なるモデルが用意されています。GDC エアギャップは、最大限のセキュリティとコンプライアンスを確保するために設計された Google 提供の専用ハードウェアで実行される、ネットワークから完全に分離されたデプロイです。GDC 接続では、独自のハードウェアで、Google が管理する統合ソフトウェアライフサイクルを利用できます。

これまで、データに関する厳格な規制と主権の要件を持つ企業や政府機関は、最新の AI 機能を利用できませんでした。唯一の選択肢は、自社でシステムを構築することでしたが、これは複雑で、時間と費用がかかります。GDC はその苦労を解消します。お客様は労力をかけずに、世界クラスの AI イノベーションを独自の環境で実現できます。

GDC は、AI ワークロード向けに最適化されたマネージドインフラストラクチャ、Gemini またはオープンモデルの柔軟な選択肢、費用対効果の高い効率的な推論サービスなど、オンプレミスの完全な AI ソリューションを提供します。この基盤により、データを完全に制御しながら、セキュアな AI エージェントとアプリケーションを構築して実行できます。

GDC の新しいイノベーションがどのように連携して、お客様のソブリン AI ワークロードをサポートするかを見ていきましょう。

マネージド AI インフラストラクチャ

オンプレミスでソブリン AI のニーズをサポートするには、コンピューティング、ストレージ、ネットワーキングの膨大なパフォーマンス要求に対応できるマネージドインフラストラクチャが必要です。オンプレミスの AI ワークロードは動的で予測不可能なため、Google はさまざまな要件で最高のパフォーマンスを実現する、以下の新しいインフラストラクチャイノベーションを導入しています。

NVIDIA Blackwell GPU: 第 5 世代の NVIDIA NVLink を活用してデータセンター規模の帯域幅を自社環境に直接提供する NVIDIA Blackwell（NVIDIA HGX B200）および NVIDIA Blackwell Ultra プラットフォーム（NVIDIA HGX B300）GPU で AI パフォーマンスを加速します。
Google Cloud マシンファミリー: GDC はすでに、汎用ワークロード向けに N2 および N3 マシンファミリーをサポートしていますが、新たに A4 マシンファミリーもサポートするようになりました。A4 マシンファミリーは、ピーク時のコンピューティング能力が 2.25 倍に向上しており、要求の厳しい推論タスクを処理できます。また、メモリ最適化 M2 と M3 マシンファミリーを GDC に導入し、ERP やデータ分析など、より高いメモリ対 vCPU 比率を必要とするワークロードに対応します。
ストレージのスケールとパフォーマンスの強化: GDC は、ゾーンあたり 6 PB のオブジェクトストレージをサポートするようになりました（以前は 1 PB）。これは、以前のストレージ容量の 6 倍です。さらに、ゾーンごとに 30 IOPS/GB（以前は 3 IOPS/GB）を提供するようになってパフォーマンスが 10 倍に向上し、ストレージのボトルネックが最小限に抑えられます。

データセンターの基盤モデル

GDC を使用すると、Google のフラッグシップである Gemini モデルのパワーを自社環境に直接取り込むことができます。最新世代の NVIDIA Blackwell GPU を搭載した独自の境界内でのネイティブデプロイが可能になるため、世界クラスの生成 AI と厳格なデータ主権のギャップを埋めることができます。

このたび、最新の Gemini Flash モデルが、GDC 接続のお客様向けに NVIDIA Blackwell および Blackwell Ultra プラットフォームで（プレビュー版として）利用可能になりました。これにより、GDC エアギャップのお客様向けの既存のサポートが拡充されます。

「Google Distributed Cloud で Gemini をデプロイしたことで、当社のグローバルな製造が大幅に改善されました。最先端の AI をローカルで実行することで、IoT データを分析してリアルタイムの予測メンテナンスと品質管理を実現し、クラウドのレイテンシを回避できます。クラウドのようなアジリティを保持しながら、IP に対する厳格なデータ主権を維持しています。」- Samsung SDS、最高経営責任者、Junhee Lee 氏

AI 推論サービス: Google Distributed Cloud AI ゲートウェイの導入

パフォーマンスを最適化し、インフラストラクチャの複雑さを抽象化するために、ソブリン環境向けの AI ゲートウェイを導入します。このインテリジェントなミドルウェアは、モデルのコントロールプレーンとして機能します。これには、次のような利点があります。

動的リクエストルーティング: 推論リクエストを、ハードコードされたロジックではなく、費用、レイテンシ、精度に基づいて適切な AI モデルに自動的にルーティングします。
インテリジェントなロードバランシング: 推論効率を最適化するためにリクエストをルーティングし、使用率に基づいて GPU を選択します。
割り当て管理: リクエストに優先順位を付け、優先度の高いアプリケーションに必要なスループットを確保し、割り当て管理の目標を達成します。
オブザーバビリティ: すべての推論呼び出しにトレースとロギングが組み込まれており、コンプライアンスが重視される環境での監査可能性を確保できます。

エージェント型 AI アプリケーションとエージェント

エッジで AI を真に運用化するには、組織に基盤モデル以上のものが必要です。それは、エージェント型 AI アーキテクチャ上に構築された、アクションを実行できる自律的でセキュアなエージェントです。ここに、Google Distributed Cloud 向けの新しいソブリンエージェント型 AI アーキテクチャを発表できることを嬉しく思います。Kubernetes 上にサードパーティプロバイダと構築されたこのアーキテクチャにより、エージェントワークフローが、セキュアなお客様の組織の境界内で完全に実行されるようになります。

このエージェントアーキテクチャを使用すると、開発、コーディング、データ分析などのエージェントタスク用の強力な AI エージェントを、セキュアな境界内で構築してデプロイできます。

Google Distributed Cloud で AI をどこでも利用可能に

GDC は、Google やその他のモデルをオンプレミスで、接続された環境でもエアギャップのある環境でもサービングするのに最適なプラットフォームであり、すべてのお客様が主権を損なうことなく AI やエージェントソリューションを活用できるようになります。これらのプロダクトの詳細については、ウェブサイトをご覧ください。ここで説明したイノベーションは、ソブリン AI 時代に必要な柔軟性とセキュリティを提供します。これらのプロダクトの実際の動作をご覧になるには、GDC ブレイクアウトセッションまたは Next ’26 のショーケースにご参加ください。

- Google Distributed Cloud、バイスプレジデント、Muninder Sambi

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 Cloud と NVIDIA が GTC 2026 で業界全体に AI イノベーションを拡大

Tue, 24 Mar 2026 03:00:00 +0000

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

エージェント型 AI の時代により、企業インフラストラクチャのニーズは根本的に変化しています。組織が動的な推論と自律的な実行が可能なシステムを構築するにつれて、基盤となるインフラストラクチャも進化する必要があります。これらのエージェントワークロードを大規模な混合エキスパート（MoE）アーキテクチャとともにスケールするには、細部まで最適化された共同設計のスタックが必要です。

こうした需要に応えるため、Google は AI に最適化された Infrastructure as a Service である Google Cloud AI Hypercomputer を構築しました。これは、パフォーマンスが最適化されたハードウェア、最先端のソフトウェア、オープンフレームワーク、柔軟な使用量モデルを包括的な単一システムに統合したものであり、超低レイテンシ、高スループット、費用対効果の高い推論を実現します。この統合アーキテクチャ内でお客様にさらに多くのオプションを提供するために、Google は NVIDIA とのパートナーシップを拡大しています。

今週開催される NVIDIA GTC 2026 で、Google Cloud と NVIDIA はパートナーシップを拡大し、共同設計した AI インフラストラクチャ基盤を紹介する一連の新しい発表を行います。

インフラストラクチャとハードウェア

NVIDIA RTX Pro™ 6000 Blackwell Server Edition を搭載した Google Cloud G4 VM の勢い
NVIDIA vGPU テクノロジーを使用した、柔軟な分割式 G4 VM のプレビュー版 - NVIDIA RTX Pro™ 6000 Blackwell Server Edition では業界初
NVIDIA Vera Rubin NVL72 プラットフォームのサポート予定

ソフトウェアとプラットフォーム

NVIDIA Dynamo と GKE Inference Gateway のインテグレーション
Vertex AI Training と Model Garden 全体で NVIDIA のサポートを強化

エコシステム

公共部門向け AI スタートアップアクセラレータプログラムの開始

発表内容を詳しく見ていきましょう。

G4 VM で AI ワークロードを高速化

NVIDIA RTX Pro 6000 Blackwell Server エディション GPU を搭載した G4 VM は、高度な空間コンピューティングから完全な AI 開発ライフサイクルまで、さまざまな高パフォーマンスワークロードを強化するために構築されています。たとえば、Otto Group One.O や WPP などの企業は、G4 を使用して物理的に正確なシミュレーションやリアルタイムの 3D レンダリングを大規模に実行しています。

シミュレーション以外にも、G4 はモデルのファインチューニングと推論で優れた性能を発揮し、特に 300 億から 1,000 億以上のパラメータを持つモデルに適しています。4 ビット浮動小数点（FP4）精度と Google のピアツーピア（P2P）通信を活用することで、お客様はモデル提供のスループットの向上とレイテンシの大幅な削減を実現し、リアルタイムのマルチモーダル AI エージェントや応答性の高い生成 AI アプリケーションという新しいクラスを可能にしています。

お客様がすでに G4 VM のパフォーマンスと効率性を活用して、最も要求の厳しいワークロードを高速化させている例をいくつかご紹介します。

「Google Cloud の G4 VM は、膨大な量のフォトリアルなシミュレーションをパイプラインで処理するために必要とされる、スケーラブルな GPU バックボーンを提供してくれます。スループットが 4 倍に向上したことで、ML チームはより迅速にイテレーションを行い、より豊富なデータでトレーニングし、モデルが実環境に導入されるよりかなり前にエッジケースを検証できるようになりました。」– General Motors、AI / ML エンジニアリング担当ディレクター、Sony Mohapatra 氏

「NVIDIA Blackwell を搭載した G4 VM を使用することで、マルチモーダルモデルをさらに進化させられるようになりました。推論の高速化、信頼性の向上、言語を問わない即時応答などです。目標は変わりません。企業規模で機能する音声エージェントを、妥協せずに作成することです。今後も共同で開発を続け、お客様がこのツールをどのように活用されるかを楽しみにしています。」– ElevenLabs、共同創業者、Mati Staniszewski 氏

「Google Cloud G4 VM は、当社のロボット連携レイヤの計算バックボーンを提供し、物流センター全体で自律型フリートをミリ秒単位の精度で同期できるようにします。忠実度の高いデジタルツインで複雑な倉庫環境をシミュレートすることで、サプライチェーン全体を仮想的に最適化してから、ロボットに床を移動させることができます。」 - Otto Group One.O、CEO、Stefan Borsutzky 博士

「G4 VM に移行したところ、Terraform スクリプトを更新するだけで、処理レイテンシが 50% 削減され、スループットが 6 倍に向上しました。運用オーバーヘッドを追加することなく、コアワークロードのパフォーマンスをこれほど向上させることはめったにありません。」– Imgix、エンジニアリング責任者、Alfonso Acosta 氏

分割式 G4 VM の導入

このたび、AI およびグラフィックワークロード向けの非常に効率的で費用対効果の高いエントリーポイントとなる、分割式 G4 VM のプレビュー版がリリースされました。NVIDIA 仮想 GPU（vGPU）テクノロジーを使用したこれらの新しい構成により、NVIDIA RTX PRO 6000 Blackwell Server エディション GPU のパワーを柔軟かつ小規模な単位で活用できるため、アプリケーションの特定の需要に合わせてインフラストラクチャを適切なサイズに調整できます。

「企業は、複雑なエージェント型 AI ワークロードをスケールするために、前例のないほどの柔軟性を必要としています。NVIDIA は Google Cloud とともに、NVIDIA RTX PRO 6000 を搭載した分割式 G4 VM を導入し、お客様が GPU 容量のサイズを適正化して ROI を最大化できるようにしました。Vertex AI 上の NVIDIA NeMo から GKE の NVIDIA Dynamo まで、共同設計されたスタックにより、次世代の推論モデルと MoE モデル向けのオープンで高性能なプラットフォームを提供します。」- NVIDIA、ハイパースケール / HPC 担当バイスプレジデント兼ゼネラルマネージャー、Ian Buck 氏

高度なハードウェアへのアクセスをより細かく制御できるため、分割式 G4 VM はパフォーマンスを犠牲にすることなく、リソース割り当てを最適化してオーバーヘッドを削減できます。特定のニーズに合わせて、追加の GPU スライスサイズから選択できるようになりました。

1/2 GPU: LLM 推論、ロボットセンサーシミュレーション、高忠実度 3D レンダリングなど、より負荷の高いタスクに最適です。
1/4 GPU: 中程度のクリエイティブデザイン、動画のコード変換、リアルタイムのデータ可視化など、主流のワークロード向けに最適化されています。
1/8 GPU: リモートデスクトップ、生産性向上ツール、エントリーレベルのストリーミングサービスなどの軽量アプリケーションに最適です。

これらの柔軟な G4 サイズポートフォリオにより、次のことが可能です。

インフラストラクチャの適切なサイジング: 軽量なリモートデスクトップから集中的なデータ処理まで、GPU 容量をアプリケーションの需要に正確に一致させます。
費用効率を最大化: 特定のタスクに必要な分割 GPU リソースのみを利用して料金を支払うことで、運用オーバーヘッドを削減します。
多様なワークロードをスケール: 高忠実度のクリエイティブデザインやストリーミングから、複雑なロボットシミュレーションやリアルタイム推論まで、幅広いイノベーションを推進します。

これらの部分的な G4 VM は Google Kubernetes Engine（GKE）で管理できるため、開発者は高度なコンテナビンパッキングを使用して、さらに高い費用対効果とリソース使用率を実現できます。Dynamic Workload Scheduler を使用して管理する場合、分割スライスにフォールバックの優先順位を設定できます。これにより、スケジューラが各ワークロードで利用可能な GPU 構成を自動的に検出できるようになるため、取得可能性が大幅に向上します。

「G4 vGPU の柔軟なサイズ設定により、各分子シミュレーションの規模に合わせてコンピューティングリソースを正確に調整できるため、創薬パイプライン全体で最大限の効率を確保できます。このきめ細かい制御により、研究者は固定されたハードウェア構成に制約されることなく、小規模なワークフローと大規模な並列処理の間をシームレスに切り替えられます。」– Schrödinger、EVP、CIO、Shane Brauner 氏

NVIDIA Vera Rubin NVL72 で AI Hypercomputer をスケーリング

NVIDIA との緊密なエンジニアリングパートナーシップを基盤として、Google は NVIDIA Blackwell アーキテクチャの後継である、先日発表された NVIDIA Vera Rubin プラットフォームをサポートできることを誇りに思います。Google は 2026 年下半期に NVIDIA Vera Rubin NVL72 ラック規模システムをいち早く提供するクラウドプロバイダとなる予定です。このシステムを Google の AI Hypercomputer アーキテクチャに統合し、次世代の推論 AI とエージェント型 AI を強化します。

AI インフラストラクチャスタック全体で効率性を実現

Google は、完全にオープンなエコシステムへの取り組みの一環として、Dynamo と GKE Inference Gateway のインテグレーションを発表いたしました。これにより、アプリケーションレイヤとハードウェア全体にわたってモジュール式のオープンソースコントロールプレーンが提供されます。Dynamo と GKE の Inference Gateway を組み合わせることで、チームはインフラストラクチャを正確なニーズに合わせて調整し、アクセラレータから最大限の費用対効果を引き出し、新しい AI モデルの市場投入までの時間を短縮し、デプロイを将来にわたって保証できます。

A4X VM（NVIDIA GB200 NVL72 と Dynamo を搭載）向けの新しい高度なスケーリングレシピを通じて、大規模な MoE アーキテクチャのパフォーマンスを最大化する方法を学ぶことができます。これらの構成は、AI Hypercomputer で AI 推論ワークロードを実行する際に、メモリとインターコネクトのボトルネックを克服する方法を示しています。

また、Dynamic Workload Scheduler を通じてリソースの取得可能性を高めています。A4X および A4X Max（NVIDIA GB300 NVL72 搭載）の Calendar モードと Flex Start、および G4 VM の新しい Flex Start サポートが提供されます。Dynamic Workload Scheduler を使用すると、必要な容量を正確に予約したり、柔軟な開始ウィンドウを使用したりできます。

Google Cloud の長年の顧客である Snap は、主要なデータ処理パイプライン 2 つを NVIDIA L4 Tensor コア GPU を搭載した Google Cloud G2 VM に移行することで、大幅な費用削減を実現しました。これは、GKE 上の Spark と NVIDIA の新しい cuDF ライブラリを活用することで実現しました。cuDF ライブラリは、シャッフルを多用するワークロードの最適化を自動化し、GPU の効率を最大限に高めます。詳しくは、GTC セッション S81678 をご覧ください。

Vertex AI のトレーニングと Model Garden の進化

Google は、Vertex AI トレーニングクラスタの 2 つの主要なインフラストラクチャの進歩により、次世代 AI の需要に対応しています。まず、A4X VM ドメインのサポートにより、Vertex AI のマネージドインフラストラクチャとフレームワーク機能を活用して、NVIDIA GB200 NVL72 ラックスケールシステムで大規模なトレーニングを行うことができます。これらの集中的なワークロードが中断されないようにするため、新しいハードウェアの復元機能により、構成可能な事前対応型の障害検出スキャンを適用できます。これにより、潜在的なハードウェアの問題を特定して軽減し、重要な「ヒーロー」トレーニングの実行が中断されるのを防ぎます。これらの機能により、グッドプットが向上し、数週間にわたるトレーニングジョブが費用のかかる再起動なしで順調に進むようになります。

「私たちは Google および NVIDIA とともに、高性能で一貫性があり、正確で応答性の高い AI エージェントを提供するという、エージェント型エンタープライズの新たな基準を打ち立てています。NVIDIA GB200 NVL72 上の Vertex AI トレーニングクラスタを活用して Agentforce 360 プラットフォームを強化することで、インフラストラクチャのボトルネックを解消し、GPU を完全に飽和状態に保つことができました。この高パフォーマンスで復元力のあるアーキテクチャにより、研究者は大規模なイノベーションに集中でき、最も複雑な推論ワークロードで大きな成果を上げています。」- Salesforce、最高科学責任者、Silvio Savarese 氏

同時に、NVIDIA の Nemotron 3 ファミリーのオープンモデルのサポートにより、Vertex AI Model Garden の範囲を拡大し続けています。たとえば、Nemotron 3 Nano はワンクリックでデプロイできるため、プライベート VPC への統合が簡単です。また、カタログを拡大し、NVIDIA Nemotron 3 Super 120B モデルを追加しました。これにより、高性能な大規模推論にすぐにアクセスできます。これらのモデルの価値を最大限に高めるため、Google は NVIDIA の最新のパフォーマンスライブラリを Vertex AI に直接統合し、NVIDIA TensorRT-LLM で一般的なオープンソースモデルを最適化しました。

公共部門向けの AI スタートアップを支援

エコシステム内の継続的なイノベーションを促進するため、Google Public Sector と NVIDIA は AI スタートアップアクセラレータプログラムを開始します。この 1 年間のイニシアチブでは、公共部門向けのソリューションを構築する、AI に重点を置いた独立系ソフトウェアベンダー（ISV）の選抜されたコホートをサポートします。

参加者は、NVIDIA Inception と Google Cloud の ISV アクセラレータリソースの両方にアクセスできます。GTC で開始され、Google Cloud Next まで続くこの共同プログラムでは、ミッションクリティカルな公共部門アプリケーションをスケールするために必要な、共同設計されたインフラストラクチャ、技術ガイダンス、市場開拓サポートを、新興テクノロジーのリーダーに提供します。プログラムについて詳しくは、お問い合わせフォームにご記入ください。今後、他のコホートも選出され、発表される予定です。

共同エンジニアリングのコラボレーションが AI スタックのあらゆるレイヤを強化

複雑なエージェント型 AI への移行には、単なるコンピューティング能力以上のものが求められます。完全に最適化された共同設計のスタックが必要です。Google は、分割式 G4 インスタンスや今後リリースされる Vera Rubin プラットフォームなどの柔軟なハードウェアを AI Hypercomputer アーキテクチャに統合し、ソフトウェアの緊密な共同エンジニアリングと組み合わせることで、最も野心的な AI ビジョンを現実に変えるために必要なスケール、レジリエンス、効率性を実現します。

GTC に参加されますか？ブース番号 513 にぜひお立ち寄りください。詳細をご覧いただき、Google のチームと直接お話いただけます。Google と NVIDIA のコラボレーションの詳細については、cloud.google.com/NVIDIA をご覧ください。

-AI およびコンピューティングインフラストラクチャ担当バイスプレジデント兼ゼネラルマネージャー、Mark Lohmeyer

H4D VM の一般提供開始: HPC ワークロード向けに卓越したパフォーマンスとスケーリングを実現

Thu, 12 Mar 2026 02:00:00 +0000

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

このたび、第 5 世代 AMD EPYC™ プロセッサを搭載した、最新のハイパフォーマンスコンピューティング（HPC）向け最適化 VM である H4D VM の一般提供を開始しました。H4D VM は、製造、ヘルスケアとライフサイエンス、天気予報、電子設計自動化（EDA）などの業界に、優れたパフォーマンス、スケーラビリティ、価値を提供します。H4D は、Slurm を使用した Cluster Toolkit によるオーケストレーションと、Google Kubernetes Engine（GKE）によるオーケストレーションをサポートしています。どちらのアプローチでも、要求の厳しいワークロードをほぼ瞬時にデプロイしてスケールできます。

Google Cloud の CPU ポートフォリオで、Cloud Remote Direct Memory Access（RDMA）を備えた VM ファミリーが登場するのは今回が初めてです。H4D の RDMA は Titanium ネットワークアダプタ上にあり、シングルノードの H4D パフォーマンスを複数のノードにスケールして、大規模な本番環境ワークロードを高速化できます。

ドメインや規模を問わず、解決までの時間を短縮

第 5 世代 AMD EPYC CPU の高コア密度と、Google の革新的な低レイテンシ Falcon ハードウェアトランスポートを搭載した H4D VM により、これまで以上に迅速なイテレーションと検出が可能になります。

業界標準のベンチマークを複数使用して H4D のパフォーマンスを実証し、さまざまなドメインと問題サイズにおける H4D の能力を示しました。

医療とライフサイエンス

医療とライフサイエンス（HCLS）の研究者にとって、H4D VM は科学的発見に不可欠な複雑な分子シミュレーションを加速します。以前の C2D VM と比較して、H4D VM は 96 VM で LAMMPS（LJ ベンチマーク）を実行する際の速度が最大 4.3 倍向上し、18,000 コアで 95% の並列効率を実現します。創薬では、32 台の VM で GROMACS（water_33m）を使用し、6,000 個のコアで 72% の並列効率を実現して、5.8 倍の高速化を実証しました。H4D はスケーラビリティも向上しており、192 台の VM（約 37,000 コア）で LAMMPS LJ ベンチマークを実行し、92% の並列効率を維持することが実証されました（図 3 を参照）。

製造

製造業では、H4D VM はミッションクリティカルなコンピュータ支援エンジニアリング（CAE）ワークフローのパフォーマンスを大幅に向上させることで、エンジニアが設計サイクルを短縮し、より大規模なシミュレーションを実行して、より迅速にイテレーションできるようにします。複雑な数値流体力学（CFD）シミュレーションを実行した際、以前の C2D VM と比較して、H4D VM は 32 個の VM で Ansys Fluent（F1_RaceCar_140m ベンチマーク）を 85% の並列効率で実行し、4.1 倍の高速化を実現しました。オープンソースの OpenFOAM（Motorbike_100m）を実行した際、C2D と比較して、16 個の VM を使用して 5.2 倍の高速化を実現し、122% の超線形並列効率を達成しました。

HPC のコストパフォーマンスの新たな基準

H4D VM は、優れたパフォーマンスと柔軟な使用量モデルを組み合わせることで、Google Cloud 上の HPC ワークロードに最適なコストパフォーマンスを提供するように設計されています。H4D は Dynamic Workload Scheduler（DWS）をサポートしており、DWS は、ジャストインタイムの容量に対応する Flex Start モードと、予約を保証する Calendar モードでワークフローに適応します。これにより、長期契約なしで、コア時間あたり 3 セントという低料金でコンピューティングを利用できます。前世代の VM と比較したパフォーマンスと費用効率の結果は、図 6 と図 7 に詳しく示されています。

包括的な HPC 管理

H4D VM の大規模で高密度のクラスタを管理、デプロイするには、Google Cloud の Cluster Director を活用できます。Cluster Director は、高度なメンテナンス機能（プレビュー版にこちらから登録できます）と、ターンキーシステムブループリントによる迅速なクラスタデプロイのための Cluster Toolkit を提供します。ジョブとワークロードの管理については、H4D VM は Google Cloud のフルマネージドクラウドネイティブサービスである Batch と統合されており、Batch によってキューイング、スケジューリング、リソースプロビジョニングが処理されます。さらに、DWS もサポートされています。これは、将来の予約のための Calendar モードと、時間制限付きのオンデマンド使用のための Flex Start モードの両方で使用できます。

お客様とパートナー様の声

「Jump Tradingは早期アクセスで H4D プラットフォームをテストしましたが、その結果に非常に感銘を受けました。テストプロセスが成功したことで、H4D が要求の厳しい大量のオペレーションに必要なパフォーマンス、安定性、効率性を備えていることが実証されました。前世代のマシンと比較してコストパフォーマンスが最大 50% 向上しており、現在、Google Cloud 上の重要なグリッドワークロードとの統合を加速させています。」- Jump Trading、最高技術責任者 Alex Davies 氏、HPC Linux エンジニアリング部門、Benjamin Stromski 氏

「特に大規模でコンピューティング負荷の高い分野では、最速のシステムはオンプレミスで構築し、ベアメタルハードウェアで実行するしかないという考え方が根強く残っています。ベアメタルで運用する正当な理由として、「ハイパーバイザ税」といった用語がよく使われます。しかし、私たちが行ったテストでは異なる結果が出ています。Google H4D VM は、当社の財務リスクベンチマークにおいて、同世代の最上位 AMD CPU のベアメタルよりも優れたパフォーマンスを発揮します。」- HMxLabs、CEO、Hamza Mian 氏

「要求の厳しい CAE および製造分野向けにマネージド HPC ソリューションを提供する大手プロバイダとして、H4D プラットフォームに対する当社の評価は、お客様の最大規模で最も密結合なシミュレーションワークロードを処理できる能力に重点を置きました。その結果には非常に感銘を受けました。テストでは、基盤となる RDMA ファブリックが、大規模な並列処理に必要な優れた低レイテンシと高帯域幅のパフォーマンスを発揮することが確認されました。このレベルの相互接続効率は、衝突試験や CFD などの重要な製造シミュレーションを高速化するために不可欠です。H4D は、高スループットのエンジニアリングワークロードの真のアクセラレータであることを自ら証明しました。当社は、エンジニアリング業界における HPC のパフォーマンス上限を再定義する可能性に期待しています。」- TotalCAE、社長、Rodney Mach 氏

「新しい H4D インスタンスは、当社の要求の厳しい次世代の TPU シミュレーションワークロードにとって大きな前進です。C2D と比較して、さまざまな EDA ベンチマークにわたって 30% のパフォーマンス向上を確認しており、H4D の強力なシングルコアパフォーマンスが証明されました。これは、開発サイクルの高速化に直接つながり、エンジニアリングチームがより迅速にイテレーションできるようになります。」- Google Cloud、チップ設計手法テクニカルリード、Trevor Switkowski

今すぐ H4D を体験

H4D は現在、us-central1-a（アイオワ）、europe-west4-b（オランダ）、asia-southeast1-a（シンガポール）でご利用可能で、追加のリージョンも近日中に提供予定です。リージョンとゾーンのページでリージョン別の提供状況をご確認のうえ、Cloud RDMAを活用して、特に要件の厳しい HPC ワークロードをデプロイしてください。

^{上述のベンチマークでは、次の構成が実行されました。LAMMPS バージョン 20250722、GROMACS バージョン 2023.1、OpenFOAM バージョン 2312、Ansys Fluent バージョン 2024R1。すべての実行で IntelMPI 2021.17.2 が使用されました。C2D / C3D / C4D は TCP を使用し、H4D は RXM と SAR_LIMIT=2G で RDMA を使用しました。すべての実行で、各プラットフォームで利用可能な最大 ppn（ノードあたりのプロセス数）を使用しました（C2D、C3D、C4D / H4D でそれぞれ 56、180、192）。Ansys Fluent の実行では、H4D で 168 ppn、C4D で可変 ppn が使用されました。SMT はすべてオフ。コスト比較は、DWS Flex Start 料金の H4D-highmem-192 と、オンデマンド料金の c3d-standard-360 および c2d-standard-112 のシングルノード間で行われました。}

^{並列効率と最適なノード数は、入力サイズと通信パターンに依存するため、ワークロードによって異なります。}

- プロダクトマネージャー、 Aysha Keen

- シニア HPC テクノロジスト、 Felix Schürmann

課金の簡素化と費用削減: 新しい費用ベースの CUD に関する FinOps ガイド

Tue, 24 Feb 2026 02:00:00 +0000

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

クラウド費用の最適化は FinOps における効果的な取り組みの一つであり、確約利用割引（CUD）は依然として極めて有効な手段です。

Google は、2025 年 7 月より新しい費用ベースの CUD モデルのロールアウトを開始し、これにより、費用と節約額が把握しやすくなりました。また、カバレッジが新しい SKU（Cloud Run や H3/M シリーズ VM など）にも拡大され、柔軟性が向上しました。このアップデートは、現在すべてのお客様にご利用いただけます。この新しいモデルが FinOps の実践をどのように簡素化するのか、詳しく見ていきましょう。

1. 費用ベースの CUD データモデルの変更内容

最も重要な変更は、クレジットベースのシステムから、使用量モデルを使用した直接的な割引価格モデルに移行することです。

従来のクレジットモデルでは、1 時間あたりのオンデマンド料金に対してコミットしていました。節約額（実際に実現した費用削減額）を把握するには、オンデマンド料金の全額、コミットメント料金、相殺されるクレジットという 3 つの異なる数値を使用する必要がありました。

1. 従来の計算方法:

$10.00（オンデマンド）+ $5.50（コミットメント料金）- $10.00（クレジット）= $5.50（純費用）
節約額 = $10.00（オンデマンド）- $5.50（純費用）= $4.50

新しい直接的な割引モデルでは、純費用を計算するためにこのような計算を行う必要はありません。割引後の純支出額に直接コミットします。使用量はシンプルに割引された料金で請求されます。

2. 新しい計算方法:

$5.50（割引後の費用）
節約額 = $10.00（オンデマンド）- $5.50（割引後の費用）= $4.50

これにより、純費用を一目で確認できるようになります。節約額の計算も、オンデマンド料金（$10.00）と新しい割引料金（$5.50）を比較するだけで済み、その差が $4.50/時間であることがわかります。

2. 変更前後の節約額を検証する方法

統合された CUD 分析ツールは、移行を監査したり、費用を詳しく分析したりするのに最適なリソースです。新しい費用ベースの CUD モデル用の CUD 分析では、新しいモデルで得られる節約額をすぐに確認できます。また、このツールを使用して、古いモデルと新しいモデルで節約額に違いがあるかどうかを比較検証できます。

節約額の検証手順は以下のとおりです。

1. 移行を実施した日付を特定します。移行日は、請求の概要ページで確認できます。

2. CUD 分析に移動して、移行前後の節約額を検証します。

3. 移行前の費用を定量化する場合:

移行の 1 日前のビューをフィルタします。この例では、2025 年 10 月 26 日です。
CUD プロダクトを選択します（Cloud SQL CUD など）。
この例では、 $69.12 のクレジットを得るために $50.35 の CUD 料金を支払っています。この料金をクレジットから差し引くと、実際に節約できた金額は $18.77 になります。

4. 移行後の費用を検証する場合:

日付を 2025 年 10 月 28 日に変更します。
新しいモデルでは、割引料金を前払いします。ダッシュボードには純費用 $50.35 が反映され、オンデマンド費用 $69.12 と比較した場合の節約額が $18.77 であることが明確にわかります。

さらに、このリリースでは費用レポートのアップデートも行われており、「コスト削減プログラム」が追加されました。これにより、総クレジットではなく、実際の純節約額（上記の例では $18.77）が正確に反映されます。費用レポートで移行前後のデータを比較する際は、コミットメントの全範囲を把握するために、使用量の SKU とコミットメント料金の SKU の両方を必ず含めてください。

3. 新しい CUD 分析の他の機能

新しいモデルのサポートに加えて、新しい CUD 分析ツールでは、CUD のカバレッジと使用状況の可視性が高められています。これにより、最大 30 日間の時間単位のデータ粒度で CUD を分析できるようになりました。1 日の平均値では特定の時間帯に発生する使用率の急上昇が見逃されることが多いため、これは FinOps チームに大きなメリットをもたらします。

CUD 分析: コンピューティングフレキシブル CUD のカバレッジの分析

CUD 分析: CUD 購入ごとに使用状況を可視化

独自のデータ分析ツールを使用する場合は、新しい費用ベースの CUD メタデータのエクスポート を利用することで、費用ベースの CUD をプログラムで管理できます。このエクスポートを使用して、Billing BigQuery Export データセットと結合し、すべてのコミットメントデータに対して詳細なプログラム分析を実行できます。また、CUD 分析ビューから CSV をエクスポートすることで、BigQuery の完全なエクスポートを必要とせずに、すべてのリソースとその料金の元データを確認することもできます。

4. どの程度のコミットメントを購入すべきか

購入するコミットメントを決定するための主要なツールとして、CUD の推奨事項を利用できます。先日強化された、コンピューティングフレキシブル CUD のコミットメントに関する推奨事項では、GKE、Cloud Run、Cloud Run functions、Compute Engine のデータを含めることで、精度を向上させました。さらに、CUD シナリオのモデリングにより、これらの提案をリアルタイムで調整できます。また、カバレッジのしきい値の調整、使用量が不規則な特定の日付の除外、最長 180 日間の分析のルックバックウィンドウの延長などを行うことで、お客様のリスクプロファイルに沿った正確なコミットメントレベルを特定できます。

CUD シナリオのモデリング: 複数のオプションを試して、理想的な CUD 戦略を特定

5. フレキシブル CUD についての関連情報

新しい費用ベースのモデルのリリースにより、フレキシブル CUD と GKE / Cloud Run CUD を組み合わせて使用する場合に影響していたレポートの制限を解消しました。これまでは、Google の分析ツールで特定のクレジットのソースを正確に特定できなかったため、節約額、カバレッジ、使用状況などの KPI 指標に不一致が生じていました。新しい費用ベースの CUD モデルでは、この制限が解消されたため、CUD 分析において Google Cloud サービスごとの正確かつ詳細な節約額を確認できるようになりました。

新しい費用ベースのモデルの利用を開始するには、課金コンソールにアクセスしてください。詳しくは、以下のドキュメントをご覧ください。

- シニアプロダクトマネージャー、Alfonso Hernandez

- シニアプロダクトマネージャー、Rahul Sharma

NVIDIA RTX PRO 6000 により、Cloud Run 上で高性能推論とサーバーレスコンピューティングが融合

Mon, 09 Feb 2026 02:00:00 +0000

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

大規模な推論モデルの実行には、クラスタ管理や VM の手動メンテナンスなど、運用面で大きな負担が伴うことが少なくありません。こうした負担を軽減する方法の一つが、基盤となるインフラストラクチャを意識せずに利用できるサーバーレスのコンピューティングプラットフォームを活用することです。Google はこのたび、Cloud Run で NVIDIA RTX PRO™ 6000 Blackwell Server Edition GPU に対応するハイエンド推論においてサーバーレスの提供を開始いたしました。現在はプレビュー版が提供されており、Gemma 3 27B や Llama 3.1 70B といった大規模モデルも、Cloud Run でおなじみの「デプロイしたらあとは任せる」感覚でデプロイできます。予約は不要。クラスタ管理も不要。必要なのはコードだけです。

強力な GPU プラットフォーム

NVIDIA RTX PRO 6000 Blackwell GPU は、NVIDIA L4 GPU と比べて大幅な性能向上を実現しており、96 GB の vGPU メモリ、1.6 TB/秒の帯域幅に加え、FP4 および FP6 をサポートしています。これにより、基盤となるインフラストラクチャを自ら管理することなく、70B 超のパラメータを持つ大規模モデルを提供できます。Cloud Run では、NVIDIA RTX PRO 6000 Blackwell GPU を Cloud Run サービス、ジョブ、またはワーカープールに、予約不要でオンデマンドにアタッチできます。以下は、NVIDIA RTX PRO 6000 Blackwell GPU を活用してビジネスを加速できる主な活用例です。

生成 AI と推論: FP4 精度をサポートする NVIDIA RTX PRO 6000 Blackwell GPU の高効率な演算性能により、LLM のファインチューニングや推論を高速化できます。これにより、マルチモーダルモデルやテキストから画像を生成するモデルなど、リアルタイム性が求められる生成 AI アプリケーションを構築できます。さらに、Cloud Run サービス上でモデルを実行することで、迅速な起動とスケーリングのメリットも享受できます。インスタンス数が 0 の状態から、GPU ドライバがインストールされた GPU 環境を 5 秒未満で起動可能です。トラフィックが減少してリクエストがなくなると、Cloud Run は GPU インスタンスを自動的に 0 までスケールダウンします。
ファインチューニングとオフライン推論: NVIDIA RTX PRO 6000 Blackwell GPU は、Cloud Run ジョブと組み合わせることで、モデルのファインチューニングに活用できます。第 5 世代 NVIDIA Tensor コアは AI モデルと連携し、レンダリングパイプラインの高速化やコンテンツ制作の効率向上に貢献します。
特定のワークロードに最適化されたスケーリング: GPU 対応のワーカープールを使用することで、GPU ワーカーをきめ細かく制御できます。外部のカスタム指標に基づく動的スケーリングや、複雑でステートフルな処理に対応するための「常時稼働」インスタンスの手動プロビジョニングなど、用途に応じた柔軟なスケーリングを実現できます。

Cloud Run は、プロダクションレディな GPU アクセラレーテッドタスクを、最もシンプルに実行できるよう設計されています。Cloud Run の主な特長は次のとおりです。

柔軟なコンピューティングを備えたマネージド GPU: Cloud Run では、必要な NVIDIA ドライバがあらかじめインストールされているため、インフラストラクチャの準備に煩わされることなく、コードの実装に集中できます。NVIDIA RTX PRO 6000 Blackwell GPU を使用する Cloud Run インスタンスでは、最大 44 vCPU と 176 GB の RAM を構成できます。
本番環境レベルの信頼性: Cloud Run はデフォルトでゾーン冗長性を提供しており、ゾーン停止に耐えるために十分な容量をサービスに確保できます。これは、Cloud Run で GPU を使用した場合にも適用されます。また、ゾーン冗長性をオフにして、ゾーン停止が発生した場合に GPU ワークロードのベストエフォートフェイルオーバーを行うことにすれば、料金を低く抑えられるメリットがあります。
緊密な統合: Cloud Run は、Google Cloud の他のサービスとネイティブに連携します。Cloud Storage バケットをローカルボリュームとしてマウントすることで大規模なモデルの重みを読み込んだり、Identity-Aware Proxy（IAP）を使用して Cloud Run サービス宛てのトラフィックを安全に保護したりすることができます。

使ってみる

NVIDIA RTX PRO 6000 Blackwell GPU は、現在プレビュー版としてオンデマンドで利用可能です。対応リージョンは us-central1 および europe-west4 で、asia-south2 と asia-southeast1 では限定的に提供されています。オープンモデルを実行する最も簡単な方法の一つである Ollama を使用すれば、NVIDIA RTX PRO 6000 GPU を有効化した Cloud Run 上に、次のコマンドで最初のサービスをデプロイできます。

code_block: <ListValue: [StructValue([('code', 'gcloud beta run deploy my-service \\\r\n--image ollama/ollama --port 11434 \\\r\n--cpu 20 --memory 80Gi \\\r\n--gpu-type nvidia-rtx-pro-6000 \\\r\n--no-gpu-zonal-redundancy \\\r\n--region us-central1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6591af3550>)])]>

詳しくは、最新の Cloud Run ドキュメントおよび AI 推論のベストプラクティスをご覧ください。

-シニアプロダクトマネージャー、James Ma

-シニアエンジニアリングマネージャー、Oded Shahar

一般提供が開始された Axion ベースの N4A VM で費用対効果が 2 倍に

Fri, 06 Feb 2026 02:00:00 +0000

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

2026 年 1 月 27 日: N4A の一般提供が開始されました。使用を開始するには、Google Cloud コンソールから N4A をデプロイしてください。

昨今の意思決定者と構築者は、クラウド費用の増加を管理しながら、顧客が求めるパフォーマンスを実現するという課題に絶えず直面しています。スケールアウトマイクロサービスを使用し、増え続けるデータを処理するようにアプリケーションが進化するにつれて、組織は増大する汎用ワークロードをサポートするために、基盤となるインフラストラクチャの効率性を最大限に高める必要があります。

このニーズに応えるため、Google は最新の Axion ベースの仮想マシン（VM）シリーズである N4A を発表しました。現在、Compute Engine、Google Kubernetes Engine（GKE）、Dataproc、Batch でプレビュー版が提供されています。Dataflow やその他のサービスでも近日中にサポートされる予定です。

N4A は、現行の N シリーズ VM の中で最も費用対効果が高く、同等となる現行の x86 ベースの VM と比較して費用対効果が最大 2 倍であり、ワットあたりのパフォーマンスも 80% 優れています。そのため、幅広い汎用ワークロードの総所有コスト（TCO）をさらに最適化しやすくなります。これは、GKE でスケールアウトウェブサーバーとマイクロサービスを実行するクラウドネイティブ企業、バックエンドアプリケーションサーバーや中規模データベースを管理する企業チーム、大規模な CI / CD ビルドファームを運用するエンジニアリング組織で確認されています。

Google Cloud では、オーケストレーターからランタイムまで、スタックのあらゆるレイヤのストレージ、ネットワーキング、ソフトウェアでコンピューティングサービスを共同設計し、優れたシステムレベルのパフォーマンスと費用対効果を実現しています。N4A の画期的な費用対効果を支えているのは、Arm® Neoverse® N3 コンピューティングコアを基盤とする最新世代の Google Axion プロセッサ、Google の動的リソース管理（DRM）テクノロジー、ネットワーキングとストレージの処理をオフロードして CPU を解放する Google Cloud のカスタム設計のハードウェアおよびソフトウェアシステムである Titanium です。Titanium は、Google Cloud の垂直統合型ソフトウェアスタックの一部です。このスタックは、サーバー内のカスタムシリコンから、42 のリージョンを 775 万キロメートルの陸上および海底ファイバーケーブルでつなぐ地球規模のネットワークまで、効率を最大化し、超低レイテンシと高帯域幅をグローバル規模でお客様に提供するように設計されています。

汎用コンピューティングを再定義し、AI 推論を可能にする

N4A は汎用性を重視して設計されており、汎用ワークロードと CPU ベースの AI ワークロードをサポートする一連の機能を備えています。事前定義されたカスタムシェイプで提供され、高 CPU（vCPU あたり 2 GB のメモリ）、標準（vCPU あたり 4 GB）、高メモリ（vCPU あたり 8 GB）の構成で、vCPU は最大 64 個、DDR5 は 512 GB、インスタンスネットワーキングは最大 50 Gbps の帯域幅に対応します。N4A VM は、最新世代の Hyperdisk ストレージオプション（Hyperdisk Balanced、Hyperdisk Throughput、Hyperdisk ML（近日提供予定）など）をサポートしており、インスタンスあたり最大 160,000 IOPS、2.4 GB/秒のスループットを実現します。

N4A は、お客様が日々実行する主要なワークロードを代表する、さまざまな業界標準ベンチマークで優れたパフォーマンスを発揮します。たとえば、現行世代の同等となる x86 ベースの VM と比較して、コンピューティング能力に制約のあるワークロードで最大 105%、スケールアウトウェブサーバーで最大 90%、Java アプリケーションで最大 85%、汎用データベースで最大 20% 優れた費用対効果を実現します。

脚注: 2025 年 10 月現在。パフォーマンスは、一般提供されている同等の最新世代の VM 上で汎用ストレージタイプを使って本番環境として実行された、SPECrate®2017_int_base、SPECjbb2015、MySQL Transactions/minute（RO）、Google 内部 Nginx リバースプロキシベンチマークの推定スコアに基づいています。費用対効果に関する情報は、Google Cloud の公開済みおよび公開予定の正規料金に基づいています。

実際、新しい N4A インスタンスの先行ユーザーの費用対効果は大幅に向上しています。

「ZoomInfo では、効率性が最優先事項である大規模なデータインテリジェンスプラットフォームを運用しています。お客様にタイムリーな分析情報を提供するために不可欠な当社のコアデータ処理パイプラインは、GKE の Dataflow と Java サービスで広範に実行されています。新しい N4A インスタンスのプレビューでは、x86 ベースの同等のインスタンスと比較して、これらの主要なワークロードの費用対効果が 60% 向上していることがわかりました。これにより、プラットフォームをより効率的にスケールし、より高い価値をより迅速にお客様にお届けできるようになりました。」- ZoomInfo、チーフインフラストラクチャアーキテクト、Sergei Koren 氏

「AI 時代のコンピューティング需要を満たすには、パフォーマンス、効率性、柔軟性、スケーラビリティが組織に求められます。これには、Google Cloud とのパートナーシップの中核にある緊密なコラボレーションと共同設計が必要です。N4A は費用対効果を再定義するものであり、お客様は新たなレベルでインフラストラクチャを最適化できます。企業は Arm と Google Cloud を使用して、ワークロードの要件に最適なインフラストラクチャを選択できます。」 - Arm、インフラストラクチャビジネス、サーバーエコシステム開発担当ディレクター、Bhumik Patel 氏

カスタムマシンタイプと Hyperdisk によるきめ細かな制御

Google の N シリーズ VM の大きな強みは、これまでも柔軟性にありましたが、N4A ではその柔軟性をさらに進化させ、Axion ファミリーとして初めて、最も広く利用されている機能の一つであるカスタムマシンタイプ（CMT）を提供します。事前定義された構成にワークロードを合わせるのではなく、N4A の CMT ではアプリケーション固有のニーズに合わせて vCPU とメモリの量を個別に構成できます。インスタンスのサイズを適正化できるため、使用したリソースに対してのみ料金を支払うことになり、無駄を最小限に抑えて TCO を最適化できます。

特定のワークロードにリソースを適合させるというこの原則は、ストレージにも適用されます。N4A VM は、最新世代の Hyperdisk をサポートしており、アプリケーションのニーズに最適なストレージプロファイルを選択できます。

Hyperdisk Balanced: N4A VM あたり最大 160,000 IOPS で、ほとんどの汎用ワークロードに対して最適なパフォーマンスとコストの組み合わせを提供します。
Hyperdisk Throughput: Hadoop や Kafka など、帯域幅を大量に消費する分析ワークロードで最大 2.4 GiBps のスループットを実現し、価値の高い大容量ストレージを提供します。
Hyperdisk ML（一般提供開始）: AI / ML ワークロード専用に構築されており、モデルの重みやデータセットが保存された単一のディスクを最大 32 個の N4A インスタンスに同時にアタッチして、大規模な推論やトレーニングのタスクを実行できます。
Hyperdisk ストレージプール: 容量とパフォーマンスをボリューム単位ではなく、まとめてプロビジョニングできるため、コストを最大 50 %削減しながら管理を簡素化できます。

「Vimeo では、大規模な動画コード変換プラットフォームを効率的に管理するために、長年にわたってカスタムマシンタイプを利用してきました。新しい Axion ベースの N4A インスタンスの初期テストでは非常に有望な結果が得られ、新たなレベルの効率性が実現しています。当社の主要なコード変換ワークロードのパフォーマンスは、同等の x86 VM と比較して 30% 向上しました。これにより、運用モデルを変更することなくユニットエコノミクスを改善し、より収益性の高い方法でサービスを拡大する明確な道筋が示されました。」 - Vimeo、ホスティングおよび配信オペレーション担当シニアディレクター、Joe Peled 氏

お客様の選択肢を広げる Arm ベースの Axion ポートフォリオの拡大

C シリーズ VM は、中規模から大規模のデータベースやインメモリキャッシュなど、一貫して高いパフォーマンスを必要とするワークロード向けに設計されています。価格とパフォーマンスのバランスが良く、柔軟性を備えた N シリーズ VM は、Compute Engine の重要な柱となっており、スケールアウト Java / GKE ワークロードなど、リソースのニーズが変動するワークロードの実行コストを削減できます。2024 年 10 月、Google は初の Axion ベースのマシンシリーズである C4A をリリースしました。N4A の導入によってこの C4A が補完され、ワークロードの正確なニーズに適したさまざまな Google Axion インスタンスを提供できるようになりました。

さらに、GKE は Axion ベースの C4A と N4A のマシンタイプをオーケストレートすることで、費用対効果を大幅に向上させます。また、カスタム ComputeClass でこれらのマシンタイプをプロビジョニングして組み合わせ、ワークロードを適切なハードウェアにマッチさせます。この自動化された異種クラスタ管理により、チームはアプリケーションスタック全体で TCO を最適化できます。

さらに、C4A.metal が Axion ファミリーに加わりました。これは Google Cloud 初の Axion ベアメタルインスタンスで、自動車システム開発、厳格なライセンス要件があるワークロード、Android ソフトウェア開発など、仮想化されていない環境で特殊なアプリケーションを実行するために基盤となる物理サーバーへのアクセスが必要になるユースケースに対応します。C4A.metal はまもなくプレビュー版で利用可能になります。

Axion の導入は、広範な成熟した Arm エコシステムに支えられ、これまで以上に簡単になっています。C4A と N4A を組み合わせることで、パフォーマンスやワークロード固有の要件に妥協することなく、ビジネス運営の総費用を削減できます。

費用最適化と柔軟性に優れた N4A: スケールアウトウェブサーバー、マイクロサービス、コンテナ化されたアプリケーション、オープンソースデータベース、バッチ、データ分析、開発環境、データ準備、AI / ML のテストなど、価格とパフォーマンスのバランスが求められる汎用ワークロード向けに設計されています。
一貫して高いパフォーマンス、予測可能性、制御性を実現する C4A: 中規模から大規模のデータベース、インメモリキャッシュ、費用対効果の高い AI / ML 推論、トラフィックの多いゲームサーバーなど、1 マイクロ秒が重要なワークロードを強化します。ミッションクリティカルなワークロード向けの制御されたメンテナンスエクスペリエンス、最大 100 Gbps のネットワーク帯域幅、次世代の Titanium ローカル SSD ストレージを提供し、一貫したパフォーマンスを実現します。

「Google Cloud の Axion ポートフォリオに移行したことで、重要な競争上の強みを得られました。C4A インスタンス（サプライサイドプラットフォーム（SSP）バックエンドサービスなど）を使用することで、低くて安定したレイテンシを維持しながら、コンピューティング使用量を 20% 削減することができました。さらに、C4A を使用することで、インスタンスサイズに関係なく、ステートフルワークロードに必要な IOPS で Hyperdisk を活用できるようになりました。この柔軟性により、クライアントの広告オークションの落札数を増やしながら、利益率を大幅に改善できています。現在、API リレーサービスなど、最も柔軟性が必要となるいくつかの主要なワークロードを実行して、N4A ファミリーをテストしています。本番環境で実行されている複数のアプリケーションで、以前のインフラストラクチャと比較して CPU の使用量が 15% 減り、コストもさらに削減できました。同時に、必要なワークロード特性を適切なインスタンスでサポートできるようになっています。」 - Rise、クラウドおよびソフトウェアアーキテクト、Or Ben Dahan 氏

今すぐ N4A を使ってみる

N4A は、Google Cloud リージョンの us-central1（アイオワ）、us-east4（バージニア）、us-east1（サウスカロライナ）、us-west1（オレゴン）、asia-southeast1（シンガポール）、europe-west1（ベルギー）、europe-west2（ロンドン）、europe-west3（フランクフルト）、europe-west4（オランダ）でご利用いただけます。今後、さらに多くのリージョンでご利用いただけるようになる予定です。N4A の詳細については、こちらのドキュメントをご覧ください。N4A のデプロイはコンソールから実行できます。

- シニアプロダクトマネージャー、Nate Baum

- グループプロダクトマネージャー、Mo Farhat

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

Fri, 30 Jan 2026 02:00:00 +0000

※この投稿は米国時間 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 にデプロイするために、検証済みのリファレンスアーキテクチャが現在利用可能です。

インフラストラクチャレイヤ: 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 の使用率を最適化します。

Wide Expert Parallelism（WideEP）: 従来の MoE サービングでは、1 つのノード（通常は 8 個の GPU）内でエキスパートをシャード化するため、特定のエキスパートが「稼働」状態になると負荷の不均衡が生じます。Google は、A4X の統合ファブリックを使用して、72 個の GPU を搭載したラック全体にエキスパートを分散します。この WideEP 構成は、大規模なコンピューティングプール全体で負荷を分散することで、バースト性の高いエキスパート活性化パターンを吸収し、単一の GPU がストラグラーになるのを防ぎます。
Deep Expert Parallelism（DeepEP）: WideEP がエキスパートを分散するのに対し、DeepEP は重要な「分離」と「結合」の通信フェーズを最適化します。DeepEP は、割り当てられたエキスパートにトークンをルーティングするために必要な高帯域幅のオールツーオールオペレーションを高速化します。このアプローチにより、大規模な MoE 推論のボトルネックとなる同期オーバーヘッドを最小限に抑えます。
リクエスト処理の分離: Dynamo は、計算依存型のプレフィルフェーズとメモリ依存型のデコードフェーズを分離します。A4X では、スケジューラがラック内の特定の GPU グループをプレフィルに割り当て（Tensor コアの飽和度を最大化）、他の GPU がデコードを処理（メモリ帯域幅の使用率を最大化）することで、リソースの競合を防止できます。
グローバルな KV キャッシュ管理: Dynamo は KV キャッシュの状態のグローバルビューを維持します。そのルーティングロジックは、関連するコンテキストを保持する特定の GPU にリクエストを転送し、冗長な計算とキャッシュの移行を最小限に抑えます。
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

VM OS エージェントの大規模な管理を簡素化: VM Extensions Manager のご紹介

Tue, 20 Jan 2026 01:00:00 +0000

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

IT 管理者であれば、大規模な VM インスタンスフリート全体でオペレーティングシステム（OS）エージェント（Google で拡張機能と呼んでいる機能）を管理するのが複雑で面倒な作業であることをご存じでしょう。実際、拡張機能によって強力なアプリケーションレベルの機能が利用可能になるにもかかわらず、VM フリートで拡張機能ベースのサービスを採用する際にこの運用オーバーヘッドが大きな障壁となる可能性があります。

この問題を解決するため、Google は VM Extensions Manager のプレビュー版を発表しました。これは、Compute Engine API に直接統合された新しい機能で、Google 提供の拡張機能のインストールと管理を簡素化するものです。

VM Extensions Manager はポリシー主導型の一元化されたフレームワークを採用しており、VM インスタンス上の Google Cloud 拡張機能のライフサイクル全体を管理できます。手動スクリプト、起動スクリプト、その他のカスタムソリューションに頼る代わりに、ポリシーを定義することで、既存か新規かにかかわらず、すべての VM インスタンスがポリシーに準拠するように管理可能になります。これにより、運用オーバーヘッドを数か月から数時間に短縮できます。

VM Extensions Manager の使用を開始する方法

VM Extensions Manager は compute.googleapis.com API に直接統合されているため、新しい API を検出したり有効にしたりする必要はなく、数分で使い始めることができます。

1. 拡張機能ポリシーを定義するまず、拡張機能の望ましい状態を指定するポリシーを定義します。

プレビュー版では、プロジェクトレベルでゾーンポリシーを作成できます。このポリシーは、単一の特定のゾーン内にある VM インスタンスを対象とします。

今後数か月以内に、グローバルポリシーと、組織レベルおよびフォルダレベルのポリシーもサポート対象に追加される予定です。これにより、優先順位を使用して柔軟なポリシー階層を構築し、単一のコントロールプレーンから企業フリートの拡張機能を管理できるようになります。

このポリシーは、Google Cloud コンソールから直接作成できます。

Cloud コンソールを使用して VM 拡張機能のポリシーを作成するデモ

2. 拡張機能を選択するポリシーで、管理する Google Cloud 拡張機能を選択します。プレビュー版の VM Extensions Manager では、次のような重要な Google Cloud 拡張機能がサポートされています。

Cloud Ops エージェント（ops-agent）: Compute Engine インスタンスからテレメトリーを収集する主要エージェントです。
SAP 用エージェント（sap-extension）: Google Cloud の SAP 用エージェントは、Compute Engine インスタンスと Bare Metal Solution サーバーで実行される SAP ワークロードのサポートとモニタリングのために Google Cloud が提供しているエージェントです。
コンピューティングワークロード用エージェント（workload-extension）: Compute Engine で実行されているワークロードをモニタリングして評価するために使用できるエージェントです。

今後数か月以内に、拡張機能ベースのサービスがさらに追加される予定です。

拡張機能の特定のバージョンを指定するか、空のまま（デフォルト）にして最新の拡張機能をインストールできます。デフォルトを選択した場合、新しいバージョンのリリースを VM Extensions Manager が自動的に処理するため、ユーザーはすぐに新機能や改善機能にアクセスできます。

3. グローバルポリシーをより細かく制御してロールアウトVM Extensions Manager では、ロールアウトの速度を設定して、グローバルポリシーの変更を複数のゾーンにわたってどのようにデプロイするかを制御することが可能です。ゾーンポリシーではロールアウト速度を設定できず、VM がオンラインになると瞬時に適用されます。

今後数週間以内に、まず gcloud を介してグローバルポリシーのサポートを拡大し、関連情報をドキュメントに反映する予定です。UI の更新は今後数か月以内に行われます。

プレビュー版では、グローバルポリシーで設定するロールアウト速度として次の 2 つから選択可能です。

SLOW（推奨）: 安全性を重視したデフォルトのオプションです。このオプションでは、Wave 間の組み込みの待ち時間を使用して、ゾーンごとのロールアウト（ポリシーの範囲内）をオーケストレートします。これにより、問題のある変更の潜在的な影響範囲を一定期間（デフォルトでは 5 日間）最小限に抑えます。このオプションは標準的なメンテナンスと更新に最適です。
FAST: このオプションでは、Wave 間の待ち時間がなくなり、ゾーンをまたぐフリート全体で変更が可能な限り迅速に行われます。これは、すべてのゾーンのすべての VM に、非常時特権アクセスを必要とする「ブレークグラス」緊急シナリオで重要なセキュリティパッチをデプロイするなど、緊急のユースケースを対象としています。

ポリシーを保存すると、VM Extensions Manager に処理が引き継がれます。基盤となるプログレッシブロールアウトエンジンによって複雑なオーケストレーションが管理され、その進行状況をモニタリングできます。

標準化と管理のための柔軟なシステム

VM Extensions Manager は、VM フリートの拡張機能を標準化し、制御できるように設計されています。今すぐプロジェクトにゾーンポリシーを適用して、拡張機能が正しいゾーンの VM インスタンスに正しくインストールされるようにしましょう。

Compute Engine VM インスタンスの拡張機能ポリシーの定義を開始するには、ドキュメントを読んで最初のポリシーを作成してください。VM フリートの管理を標準化、保護、簡素化するために VM Extension Manager をご活用いただけますと幸いです。

- プロダクトマネージャー Omkar Suram

- CE ディレクター、北米プラットフォームスペシャリスト Mike Columbus

貴社のインフラストラクチャは AI エージェントに対応していますか？

Wed, 14 Jan 2026 00:10:00 +0000

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

編集者注: 本日は、AI インフラストラクチャの TCO（総所有コスト）危機とそれに対処する方法について、IDC の Dave McCarthy 氏にお話を伺います。同氏の分析をお読みください。

AI をめぐる状況は劇的に変化しています。ここ数年、業界はリソースを大量に消費する大規模なプロセスである生成 AI モデルのトレーニングに焦点を絞ってきました。しかし現在、焦点はさらに大きな新しい課題である推論へと急速に移行しつつあります。

推論（トレーニング済みモデルを使用してリアルタイムの予測を行うプロセス）は、もはや AI ライフサイクルの一部ではなくなり、急速に主要なワークロードになりつつあります。IDC が最近 1,300 人を超える全世界の AI 意思決定者を対象に実施したアンケート調査では、推論はすでに AI ワークロードの最大のセグメントとして挙げられ、すべての AI オペレーションの 47% を占めていました。

この高い比率は、実世界のアプリケーションの膨大な数によるものです。モデルは定期的にトレーニングされながら、すべてのユーザークエリ、API 呼び出し、おすすめで推論のために休みなく使用されます。また、こうした推論の急増はハイブリッド環境全体に広がっていることを認識する必要があります。IDC のアンケートの回答者によると、ワークロードの 63% はクラウド内に存在します。クラウドは、常にコンテンツ作成や chatbot などのスケーラブルなアプリケーションの標準であり続けます。一方、ワークロードの 37% はオンプレミスインフラストラクチャにデプロイされます。これは通常、ロボット工学や実世界と直接やり取りするその他のシステムのユースケースに関連しています。

現在、この需要を増大させている新たな要因が、自律型および半自律型の AI エージェントの台頭です。

これらの「エージェントワークフロー」は、AI の新たな論理的な進化の現れです。このワークフローでは、モデルは単一のプロンプトに回答するだけでなく、複雑な複数ステップのタスクを実行します。「パリ旅行の計画を立てて」と指示された AI エージェントは、フライトの検索、ホテルの空室状況の確認、レビューの比較、場所の地図表示など、数十もの互いに関連するオペレーションを実行する必要があります。各ステップは推論オペレーションであり、さまざまなシステム間でオーケストレートする必要がある一連のリクエストを作成します。

こうした需要の急増は、多くの組織で重大な脆弱性を露呈させています。それが AI 効率のギャップです。

エージェントの時代の TCO 危機

AI 効率のギャップとは、AI スタックの理論上のパフォーマンスと実世界のパフォーマンス実績の差異です。このギャップが TCO（総所有コスト）危機を招きます。ギャップの原因はシステム全体の非効率性です。

IDC の調査によると、半数以上（54.3%）の組織が複数の AI フレームワークとハードウェアプラットフォームを使用しています。この柔軟性は有益に思えますが、驚くべき短所があり、92% の組織が効率に悪影響を及ぼしたと報告しています。

最適化されていない異種サービスを寄せ集めた断片的な「パッチワーク」アプローチは、次のような問題を波及的に生じさせます。

回答者の 41.6% がコンピューティング費用の増加を報告: 冗長なプロセスと低い利用率が支出を増加させます。
回答者の 40.4% がエンジニアリングの複雑化を報告: チームは、価値の創造よりも断片的なスタックの管理に多くの時間を費やしています。
回答者の 40.0% がレイテンシの増加を報告: システムの一部（ストレージやネットワーキングなど）のボトルネックにより、アプリケーションの全体的なパフォーマンスが低下します。

根本的な問題は、組織が高価で高性能なアクセラレータの料金を支払っているにもかかわらず、それらを十分に活用できていないことです。IDC のデータによると、浪費されている AI 予算全体の 29% は推論に関連しています。この浪費の直接的な原因は、GPU アイドル時間（回答者の 29.4% が報告）とリソースの非効率的な使用（22.3% が報告）です。

多くの場合、高価なアクセラレータがアイドル状態になるのは、低速なストレージシステムからのデータを待機しているか、アプリケーションサーバーが次のリクエストの準備をしているときです。これは、コンポーネントの障害ではなく、システムレベルの障害です。

この障害は、AI エンジンの原動力となるデータマネジメントに存在する大きな課題によってさらに悪化することがよくあります。アンケート回答者がこのギャップの原因として挙げた主な課題が 3 つあります。47.7% は、データ品質とガバナンスの確保に苦労しています。45.6% は、データストレージ管理と関連コストの課題に取り組んでいます。44.1% は、データクリーニングとデータ準備の複雑さとそれらにかかる時間を挙げています。データパイプラインが高速なアクセラレータに追いつかないと、インフラストラクチャ全体の効率が低下します。

ギャップを埋める方法: 断片化したスタックから統合されたシステムへ

AI エージェントの時代に費用対効果の高いスケーリングを実現するには、個々のコンポーネントについて考えるのをやめ、システムレベルの設計に焦点を当てる必要があります。

たとえば、エージェントワークフローには、タイプが異なる次の 2 つのコンピューティング間の緊密な連携が必要です。

汎用コンピューティング: 運用上のバックボーンです。アプリケーションサーバーを実行し、ワークフローのオーケストレーションとデータの事前処理を行い、モデルに関するすべてのロジックを処理します。
専用アクセラレータ: AI モデル自体を実行する高性能なエンジンです。

断片化した環境では、これら 2 つの要素が非効率的に結び付き、レイテンシが急増します。今後取るべき道は、ソフトウェア、ネットワーキング、ストレージ、コンピューティング（汎用と専用の両方）が単一の包括的なシステムとして機能する最適化されたアーキテクチャです。

この総合的なアプローチは、AI の TCO を管理する唯一のサステナブルな方法です。このアプローチでは、目標を再定義して、単に高速なアクセラレータを購入することから、エンドツーエンドのワークフロー全体の「費用対効果」と「ユニットエコノミクス」を改善することに切り替えます。組織は、ボトルネックを解消し、すべてのリソースの利用率を最大化して初めて、効率のギャップを埋めることができます。この成果を達成するために、組織は積極的に戦略を移行しています。IDC のアンケート調査によると、回答者の 28.9% はモデル最適化手法に優先的に取り組んでおり、26.3% は AI サービスプロバイダとの提携によってこの複雑な移行を乗り切ろうとしています。さらに、25% はチームのスキルアップのためのトレーニングに投資し、AI 投資の価値を高めようとしています。

推論の時代がすでに到来し、その後にエージェントの時代が迫っています。イノベーションの次の波に乗るのは、最も強力なアクセラレータを持つ組織ではなく、効率と統合レベルと費用対効果が最も高いシステムを構築してアクセラレータを強化できる組織でしょう。

Google Cloud からのメッセージ

Google Cloud は、IT リーダーが「推論の時代」への重要な移行を乗り切るお手伝いをするために、この IDC の調査をスポンサーとして後援しました。Google Cloud は、この投稿で取り上げられている「効率のギャップ」（断片化したスタックとアイドル状態のリソースによって生じるギャップ）がサステナブルな費用対効果の主な障壁であることを認識しています。それゆえに、Google は AI Hypercomputer を作成しました。これは、要求の厳しい AI ワークロードで優れたパフォーマンスと効率性を実現できるように設計された統合スーパーコンピュータシステムです。

IDC は、全世界の IT リーダー 1,300 人を対象にアンケート調査を実施し、効率と費用対効果を最大化するために AI スタックをどのように設計しているかを明らかにしました。詳しくは、ホワイトペーパー「The AI Efficiency Gap: From TCO Crisis to Optimized Cost and Performance」（AI 効率のギャップ: TCO 危機を乗り越えてコストとパフォーマンスを最適化）を無料でダウンロードしてご覧ください。

-IDC、クラウドおよびエッジインフラストラクチャサービス、調査担当バイスプレジデント、Dave McCarthy 氏

Cluster Director による AI および HPC クラスタ自動化の一般提供を開始

Thu, 25 Dec 2025 02:00:00 +0000

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

AI トレーニングワークロードとハイパフォーマンスコンピューティング（HPC）ワークロードを支えるインフラストラクチャの複雑さは、チームの作業ペースを低下させる可能性があります。Google Cloud において、世界最大規模の AI 研究チームとの共同作業を重ねる中で、あらゆる場面でそのような状況を目にしています。たとえば、複雑な構成ファイルという障壁にぶつかっている研究者、自社開発スクリプトによる GPU の管理に苦労しているプラットフォームチーム、数週間に及ぶトレーニング実行を阻む予測不能なハードウェア障害に絶えず奮闘している運用管理者などです。物理的なコンピューティングの利用だけでは十分ではありません。最先端の技術を利用するには、ハードウェア障害を克服する信頼性、トポロジを尊重するオーケストレーション、拡大するニーズに適応するライフサイクル管理戦略が必要です。

このたび Google Cloud は、このような要求に応えるべく、Cluster Director の一般提供（GA）を開始し、Cluster Director サポートのプレビュー版（Google Kubernetes Engine（GKE）上の Slurm 向け）をリリースしました。

Cluster Director（GA）は、最新のスーパーコンピューティングの厳しい要件を満たせるように設計されたマネージドインフラストラクチャサービスです。脆弱な DIY ツールの代わりに、トポロジを考慮した堅牢なコントロールプレーンを使用することで、最初のデプロイから 1,000 回目のトレーニング実行に至る Slurm クラスタのライフサイクル全体を処理します。
Google Cloud は、Cluster Director をさらに拡張して、GKE 上の Slurm のサポート（プレビュー版）を提供します。これにより、お客様は高パフォーマンススケジューリングの慣れ親しんだ精度と Kubernetes の自動スケーリングという 2 つの強みを最大限に利用できます。これは、GKE ノードプールを Slurm クラスタの直接的なコンピューティングリソースとして扱い、既存の Slurm ワークフローを変更せずに Kubernetes のパワーでワークロードをスケーリングできるようにすることで実現されます。

Cluster Director の一般提供を開始

Cluster Director は、クラスタライフサイクルの各フェーズで高度な機能を提供します。フェーズには、インフラストラクチャの設計とキャパシティを決定する準備作業（0 日目）、クラスタが自動的にデプロイおよび構成されるデプロイ（1 日目）、パフォーマンス、ヘルス、最適化が継続的にトラッキングされるモニタリング（2 日目）があります。

この包括的なアプローチにより、お客様は詳細な構成が可能なインフラストラクチャのメリットを享受しながら、下位レベルのオペレーションを自動化して、コンピューティングリソースが常に最適化され、信頼性と可用性が確保されている状態を維持できます。

では、これらすべてにかかる費用はどれくらいになるでしょうか？最大のメリットはそこにあります。Cluster Director の使用に追加料金はかかりません。料金は、基盤となる Google Cloud リソース（コンピューティング、ストレージ、ネットワーキング）に対してのみ発生します。

Cluster Director によるデプロイの各フェーズのサポート

0 日目: 準備

通常、クラスタの立ち上げには数週間にわたるプランニング、Terraform のラングリング、ネットワークのデバッグが必要です。Cluster Director は、ワークロード要件に合わせて最適化されたインフラストラクチャトポロジを設計するツールを備えており、「0 日目」の体験を完全に様変わりさせます。

Cluster Director は、0 日目のセットアップを効率化するため、以下を提供します。

リファレンスアーキテクチャ: Google の社内ベストプラクティスを再利用可能なクラスタテンプレートに体系化し、標準化された検証済みのクラスタを数分でスピンアップできるようにしました。これにより、組織内のすべてのチームが同じセキュリティ基準をデプロイに使用し、デフォルトで正しく構成されるインフラストラクチャ上で、ネットワークトポロジやストレージのマウントにデプロイできるようになります。
ガイド付き構成: よく知られているように、オプションが多すぎると構成の停滞を招くことがあります。Cluster Director のコントロールプレーンは、効率化されたセットアップフローを通してお客様をガイドします。お客様がリソースを選択すると、システムによって複雑なバックエンドマッピングが処理されます。これにより、デプロイに先立ってストレージ階層、ネットワークファブリック、コンピューティングシェイプの互換性が確保され、最適化されます。
広範なハードウェアサポート: Cluster Director は、大規模 AI システム向けのフルサポートを提供します。これには、NVIDIA GB200 および GB300 GPU を搭載した Google Cloud の A4X および A4X Max VM や、費用対効果の高いログインノードとデバッグパーティションに適した N2 VM などの多目的 CPU が含まれます。
柔軟な使用オプション: Cluster Director は、重要なトレーニング実行時のキャパシティを確保する予約機能、動的スケーリング用の Dynamic Workload Scheduler Flex-start、低コストの随時実行に適した Spot VM をサポートしており、お客様が希望する調達戦略に合わせて柔軟に調整できます。

「Google Cloud の Cluster Director は、大規模な AI と HPC の環境を管理できるように最適化されており、NVIDIA の高速コンピューティングプラットフォームのパワーとパフォーマンスを補完する役割を果たします。私たちは互いに協力して、次世代のコンピューティングの課題に対処できる簡素化された強力でスケーラブルなソリューションをお客様に提供します。」- NVIDIA、高速コンピューティングプロダクト担当ディレクター、Dave Salvator 氏

1 日目: デプロイ

ハードウェアのデプロイとパフォーマンスの最大化はまったく別物です。1 日目は実行フェーズであり、お客様の構成が完全に動作するクラスタに変換されます。素晴らしいことに、Cluster Director は VM をプロビジョニングするだけでなく、ソフトウェアとハードウェアのコンポーネントが健全な状態にあり、適切にネットワーク化され、最初のワークロードを受け入れる準備ができているかどうかを検証します。

Cluster Director は、高パフォーマンスのデプロイを保証するために、以下を自動化します。

健全性の証明: Cluster Director は、ジョブが GPU に到達する前に、DCGMI 診断や NCCL パフォーマンス検証などの厳格なヘルスチェックスイートを実行し、ネットワーク、ストレージ、アクセラレータの完全性を検証します。
アクセラレータへの継続的なデータ供給: ストレージスループットは、しばしばトレーニング効率を低下させる隠れた要因となります。そのため、Cluster Director はパフォーマンス階層の選択が可能な Google Cloud Managed Lustre を完全にサポートしています。高スループットの並列ストレージをコンピューティングノードに直接接続できるため、GPU がデータ不足になることはありません。
相互接続のパフォーマンスの最大化: スケーリングを最大化するため、Cluster Director はトポロジを考慮したスケジューリングとコンパクトプレースメントポリシーを実装します。システムは、Google のノンブロッキングファブリックで高密度の予約を利用することによって、分散ワークロードを可能な限り最短の物理パスに配置し、テールレイテンシを最小限に抑え、最初から集団通信（NCCL）の速度を最大化します。

2 日目: モニタリング

現実の AI / HPC インフラストラクチャでは、ハードウェアの障害や要件の変更が発生します。柔軟性を欠くクラスタは非効率的です。継続的な「2 日目」の運用フェーズに移行したら、クラスタの健全性を維持し、利用率とパフォーマンスを最大化する必要があります。Cluster Director は、長期的な運用の複雑さに対応できるコントロールプレーンを備えています。このたび導入したのは、2 日目の運用の煩雑な現実に対処できる新しいアクティブクラスタ管理機能です。

新しいアクティブクラスタ管理機能には、以下が含まれます。

トポロジレベルの可視性: 目に見えないものはオーケストレートできません。Cluster Director のオブザーバビリティグラフとトポロジグリッドを使用すると、フリート全体を可視化し、サーマルスロットリングや相互接続に関する問題を特定して、物理的な近接性に基づいてジョブの配置を最適化できます。
ワンクリック修復: ノードが劣化したときに、SSH で接続してデバッグする必要がなくなります。Cluster Director を使用すると、ワンクリックで Google Cloud コンソールから直接、障害が発生したノードを交換できます。システムによってドレイン、破棄、交換が処理され、数分でクラスタが最大キャパシティに戻されます。
適応型インフラストラクチャ: 研究のニーズに変更があったときは、クラスタも変更する必要があります。今後は、アクティブなクラスタを変更できます。つまり、クラスタを破棄したり進行中の作業を中断したりすることなく、ストレージファイルシステムの追加や削除などのアクティビティを即座に行えます。

GKE 上の Slurm 向け Cluster Director サポートのプレビュー版をリリース

イノベーションはオープンな環境で発展します。Kubernetes を構築した Google と、Slurm の開発をバックアップした SchedMD は、世界最先端のコンピューティングを支えるオープンソーステクノロジーを長きにわたって支持してきました。この数年間、NVIDIA と SchedMD は緊密に連携して GPU スケジューリングの最適化に取り組んでいます。その結果、最新の AI に不可欠な基本機能である汎用リソース（GRES）フレームワークやマルチインスタンス GPU（MIG）などのサポートが提供されるようになりました。NVIDIA は SchedMD の買収を通じて、Slurm をベンダーに依存しない標準として発展させる取り組みを強化しました。これは、世界最速のスーパーコンピュータを支えるソフトウェアがオープンかつ高パフォーマンスであり続け、未来の高速コンピューティングに向けて完璧に調整されることを保証するものです。

Google は、この高速コンピューティングの土台に立って、SchedMD との連携を深めつつ、いかにしてクラウドネイティブオーケストレーションと高パフォーマンススケジューリングのギャップを埋めるかという業界の根本的な課題を解決しようとしています。このたび、SchedMD の Slinky サービスを利用した、GKE 上の Slurm 向け Cluster Director サポートのプレビュー版のリリースをお知らせできるのは、Google Cloud にとって大きな喜びです。

このイニシアチブは、インフラストラクチャの世界の 2 つの標準を統合するものです。GKE 上でネイティブ Slurm クラスタを直接実行することで、両方のコミュニティの強みを増幅できます。

研究者の皆様は、sbatch や squeue など、数十年にわたって HPC を定義してきた妥協のない Slurm のインターフェースとバッチ機能を利用できます。
プラットフォームチームの皆様は、自動スケーリング、自己回復、ビンパッキングの機能を備えた GKE がもたらす運用のベロシティを利用できます。

GKE 上の Slurm は、Google と SchedMD の長きにわたるパートナーシップによって強化されており、次世代の AI および HPC ワークロード向けのオープンで強力な統合基盤の構築に役立ちます。今すぐプレビュー版へのアクセスをリクエストしましょう。

今すぐ Cluster Director をお試しください

Cluster Director を使用して AI および HPC クラスタの自動化を開始する準備はできましたか？

エンドツーエンドの機能について詳しくは、ドキュメントをご覧ください。
コンソールで Cluster Director を有効化してください。

-Google Cloud、Cluster Director 担当シニアプロダクトマネージャー、Ilias Katsardis

-Google Cloud、AI インフラストラクチャ担当グループプロダクトマネージャー、Jason Monden

「The Forrester Wave™: AI Infrastructure Solutions, Q4 2025」で Google がリーダーに

Wed, 24 Dec 2025 02:00:00 +0000

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

使用するかどうかはもはや問題ではなく、有望なプロトタイプからビジネス成果を促進する本番環境グレードのサービスにどのようにスケーリングするかが問題になっています。推論の時代において、競争優位性は、世界中のユーザーに役立つ情報を可能な限り低いコストで提供する能力によって決まります。デモから大規模な本番環境へのデプロイに移行する際には、最新の AI ソフトウェアとアクセラレータハードウェアのプラットフォームを提供する統合システムを使用して、インフラストラクチャの運用を簡素化するとともに、費用とアーキテクチャの複雑性を低く抑える必要があります。

先日、Forrester は、13 社のベンダーを評価した The Forrester Wave™: AI Infrastructure Solutions, Q4 2025 レポートを公開しました。Google は、このレポートの調査結果を通じて、こうした主要な課題を解決するという Google の取り組みが認められたと考えています。Google は、「現在のサービス」カテゴリにおいて全ベンダーの中で最高スコアを獲得し、ビジョン、アーキテクチャ、トレーニング、推論、効率性、セキュリティなど、19 の評価基準のうち 16 の基準で最高スコアを記録しました。

レポート全文はこちら: The Forrester Wave™: AI Infrastructure Solutions, Q4 2025

統合システムで価値創出までの時間を短縮

企業は AI を単独で運用するわけではありません。厳格なセキュリティプロトコルを遵守しつつ、さまざまなアプリケーションやデータベースと統合する必要があります。Forrester は、効率性とスケーラビリティの評価基準で Google に最高スコアを付け、Google Cloud の共同設計戦略を評価しました。

「Google は、シリコンとインフラストラクチャの共同設計戦略を追求し、推論効率を向上させる TPU と、より幅広いエコシステムとの互換性を実現する NVIDIA GPU を開発しています。TPU がネットワーキングファブリックと緊密に統合されるように設計することで、大規模な推論で高帯域幅と低レイテンシを実現できます。」

Google は 20 年以上にわたり、Google 検索、YouTube、マップなど、世界最大規模のサービスを運用してきました。これらのサービスは前例のない規模であるため、これまで解決されたことのない問題を解決する必要がありました。必要なプラットフォームとインフラストラクチャを単純に購入することはできず、自社での開発が必要でした。ここから 10 年にわたるシステムレベルの綿密な共同設計の取り組みが始まり、カスタムネットワークファブリックと特別なアクセラレータから最先端のモデルまで、すべてが 1 か所で構築されました。

その結果、統合型スーパーコンピューティングシステムである AI Hypercomputer が誕生し、お客様に大きなメリットをもたらしています。幅広い AI 最適化ハードウェアをサポートしており、スループットの向上、レイテンシの短縮、結果出力までの時間の短縮、TCO の削減など、ワークロードレベルの詳細な目標に合わせて最適化できます。つまりお客様は、Google のカスタム Tensor Processing Unit（TPU）、最新の NVIDIA GPU、またはその両方を使用できます。アクセラレータとネットワーキング、ストレージを緊密に統合したシステムが基盤となり、優れたパフォーマンスと効率性を実現します。Anthropic、Lightricks、LG AI Research などの大手生成 AI 企業が、要求の厳しい AI ワークロードの実行に Google Cloud を使用しているのもそのためです¹。

システムレベルの統合は高速処理の基盤となりますが、運用が複雑になり速度が低下する可能性はあります。製品化までの時間を短縮するために、Google は AI インフラストラクチャをデプロイして管理する複数の方法を提供し、希望のワークフローを問わず、面倒な作業を抽象化します。Google Kubernetes Engine（GKE）Autopilot を通じて、コンテナ化されたアプリケーションの管理を自動化し、LiveX.AI のようなお客様が運用コストを 66% 削減できるよう支援します。同様に、Cluster Director によって Slurm ベース環境のデプロイを簡素化し、LG AI Research のようなお客様がセットアップ時間を 10 日から 1 日未満に短縮できるようにします。

AI の費用と複雑さの管理

Forrester は、料金の柔軟性と透明性の評価基準で Google Cloud に最高スコアを付けました。コンピューティングの価格は、AI インフラストラクチャの費用を算出するための要素の一つにすぎません。全体像を把握するには、開発費用、ダウンタイム、リソースの非効率的な使用も考慮する必要があります。Google は、スタックの各レイヤで選択肢を提供し、企業が求める柔軟性を実現します。

柔軟な利用モデル: Dynamic Workload Scheduler を使用することで、必要なときに必要な容量だけ購入できるため、コンピューティング費用を最大 50% 削減できます。
ロードバランシング: GKE Inference Gateway は、AI 対応ルーティングを使用して各モデルにリクエストを分散することでスループットを向上させます。また、ボトルネックを防止し、サーバーがアイドル状態にならないようにします。
データボトルネックの解消: Anywhere Cache は、コンピューティングと同じ場所にデータを配置することで、読み取りレイテンシを最大 96% 削減し、データの移動によって生じる「統合に伴う負担」を排除します。Anywhere Cache を統合データプラットフォームの BigQuery と併用することで、アクセラレータにデータを供給しつつ、レイテンシと下り（外向き）料金の発生を回避できます。

柔軟性と選択肢による戦略的リスクの軽減

Google は、アクセラレータ、フレームワーク、マルチクラウド環境全体でお客様に選択肢を提供することにも尽力しています。これは Google にとって新しい取り組みではありません。Google は、Kubernetes の開発とオープンソース化を通じて得た豊富な経験から、オープンエコシステムがイノベーションへの近道であり、お客様に最大限の柔軟性を提供できるということを学びました。AI の時代においても、お客様がすでに使用しているツールに積極的に貢献することで、同じ考え方を実践しています。

オープンソースフレームワークとハードウェアのポータビリティ: PyTorch、JAX、Keras などのオープンフレームワークは引き続きサポートされています。また、カスタムシリコンでのワークロードのポータビリティに関する懸念に直接対処するため、vLLM の TPU サポートに投資しました。これにより、デベロッパーは最小限の構成変更だけで TPU と GPU を簡単に切り替える（または両方を使用する）ことができます。
ハイブリッドとマルチクラウドの柔軟性: Google は、アプリケーションの実行場所についても選択肢の提供に取り組んでいます。Google Distributed Cloud は、Google のサービスをオンプレミス、エッジ、クラウドのロケーションに提供します。一方、クロスクラウドネットワークは、お客様の環境と他のクラウド間の高速接続により、アプリケーションとユーザーを安全に接続します。この強力な組み合わせにより、特定の環境に縛られることがなくなります。ワークロードを簡単に移行して統一された管理手法を適用することで、運用を合理化し、ロックインのリスクを軽減できます。

信頼できるシステム

ビジネスモデル全体が AI サービスの可用性に依存している場合、インフラストラクチャの稼働時間は非常に重要です。Google Cloud のグローバルインフラストラクチャは、エンタープライズグレードの信頼性を実現するように設計されています。このアプローチは、サイト信頼性エンジニアリング（SRE）の提唱を始めた Google の歴史に根ざしています。

Google は、世界最大級のプライベートなソフトウェア定義ネットワークを運用しており、世界全体のインターネット下り（外向き）トラフィックの約 25% を処理しています。公共のインターネットに依存するプロバイダとは異なり、Google 独自のファイバーでトラフィックを維持し、速度、信頼性、レイテンシを向上させています。このグローバルバックボーンは、13 ペタビット/秒の帯域幅にスケールする Jupiter データセンターファブリックによって支えられ、前世代よりも 50 倍高い信頼性を実現しています。他のプロバイダと比較すると、その差はさらに大きくなります。最後に、クラスタレベルのフォールトトレランスを向上させるために、弾力性のあるトレーニングや多層チェックポインティングなどの機能を採用しています。これにより、復旧までの時間を最小限に抑えながらも、障害が発生したノードの周辺でクラスタのサイズを動的に変更することで、ジョブを中断することなく続行できます。

構築に安全な基盤

Google のアプローチは、AI を総合的に保護することです。実際、Google Cloud はクラウドセキュリティにおいて業界をリードする実績を維持しています。cloudvulndb.org の独自分析（2024～2025 年）によると、Google のプラットフォームでは、他の 2 つの主要クラウドプロバイダと比較して、重大度「重大」および「高」の脆弱性が最大 70% 低いことが示されています。また、Google は業界で初めて AI / ML Privacy Commitment を公表しました。この取り組みは、Google がお客様のデータを自社のモデルのトレーニングに使用しないことを保証するものです。こうした安全保護対策が講じられているため、Google Cloud の基盤には、Google のサービスを保護するゼロトラストの原則に基づいたセキュリティが組み込まれています。

ハードウェアのルートオブトラスト: Google のカスタム Titan チップは、Titanium アーキテクチャの一部として、検証可能なハードウェアのルートオブトラストを確立します。Google は最近、プライベート AI コンピューティング向けの Titanium Intelligence Enclaves でこれを拡張し、強化かつ分離された暗号化環境で機密データを処理できるようにしました。
組み込みの AI セキュリティ: Security Command Center（SCC）は Google のインフラストラクチャとネイティブに統合されており、アセットの自動検出、セキュリティ問題の防止、最前線の Google Threat Intelligence によるアクティブな脅威の検出を実施し、攻撃者に悪用される前に既知および未知のリスクを検出することで、AI 保護を提供します。
主権ソリューション: データ境界などのソリューションを通じて、お客様が厳格なデータ所在地、運用管理、ソフトウェア主権の要件を満たせるようにします。これに加えて、パートナーが運用する主権管理や、エアギャップのニーズに対応する Google Distributed Cloud などの柔軟なオプションも用意されています。
AI とエージェントのガバナンスのためのプラットフォーム制御: Vertex AI は、企業向けビルダーでモデルやエージェントを大規模にデプロイするために不可欠なガバナンスレイヤを提供します。この信頼は、Google Cloud のデフォルトで保護されたインフラストラクチャに根ざしており、VPC Service Controls（VPC-SC）や顧客管理の暗号鍵（CMEK）などのプラットフォーム制御を使用して環境をサンドボックス化し、機密データを保護します。また、エージェント ID を使用して IAM 権限を細かく管理します。プラットフォームレベルでは、Vertex AI と Agent Builder に Model Armor が統合されており、プロンプトインジェクションやデータの引き出しといったエージェントの新たな脅威に対するランタイム保護を提供します。

継続的な AI イノベーションの実現

光栄なことに、Google は「The Forrester Wave™」レポートでリーダーとして評価されました。数十年にわたる研究開発と、超大規模 AI インフラストラクチャの構築に対する Google のアプローチが認められたのだと考えています。AI の可能性の実現を支援すべく、システムレベルのイノベーションを今後も推進していきます。

レポート全文はこちら: The Forrester Wave™: AI Infrastructure Solutions, Q4 2025

^{1. IDC によるビジネス価値に関するスナップショット（Google Cloud が委託）「The Business Value of Google Cloud AI Hypercomputer」、US53855425、2025 年 10 月}

-AI およびコンピューティングインフラストラクチャ担当バイスプレジデント兼ゼネラルマネージャー Mark Lohmeyer

-Cloud AI 担当バイスプレジデント兼ゼネラルマネージャー Saurabh Tiwary

N4D の一般提供を開始: スケールアウト型ワークロードのコストパフォーマンスが最大 3.5 倍に

Mon, 08 Dec 2025 00:10:00 +0000

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

競争が激しい昨今の環境において、IT リーダーは、アプリケーションのスケールをサポートし、より多くの機能を展開し、高い水準のカスタマーエクスペリエンスを実現するという課題に直面しています。これにより、日常のビジネスオペレーションを支える汎用ワークロードのパフォーマンスと総所有コスト（TCO）の適切なバランスを見つけるという、直接的で複雑な課題が生じます。

このたび、Google Compute Engine の費用最適化された汎用ポートフォリオに新たに加わった N4D マシンシリーズの一般提供が開始されました。N4D は、ウェブサーバーやアプリケーションサーバー、データ分析プラットフォーム、コンテナ化されたマイクロサービスなど、幅広いワークロードに対応する、柔軟で費用対効果の高いソリューションです。

N4D マシンシリーズは、Google の Titanium インフラストラクチャと第 5 世代 AMD EPYC™「Turin」プロセッサを組み合わせたもので、前世代の N2D と比較して、ウェブサービスワークロードのスループットが最大 3.5 倍になります。N4D は、最大 96 個の vCPU と 768 GB の DDR5 メモリ、最大 50 Gbps のネットワーキング帯域幅、Hyperdisk のバランスストレージとスループットストレージを備えた事前定義シェイプを提供します。N4D では、コンピューティングとストレージの両方で、厳格なインスタンスサイズ設定から脱却できます。カスタムマシンタイプを使用して、vCPU の数とメモリ量を正確に個別に構成し、Hyperdisk を使用してディスクストレージのパフォーマンスと容量を調整できます。これにより、コスト削減を総合的に実現できます。最も要求の厳しい汎用ワークロードには、C4D の一貫して高いパフォーマンスに N4D を組み合わせてお使いください。

Google Cloud は、ワークロードに最適化されたインフラストラクチャを提供し、あらゆるタスクに適切なリソースを利用できるようにします。特に、マルチティアオフロードとセキュリティ機能を備えた Titanium は、そのインフラストラクチャの基盤となっています。Titanium はネットワーキングとストレージの処理をオフロードして CPU を解放し、専用の SmartNIC がすべての I/O を管理するため、AMD EPYC コアをアプリケーション専用に確保できます。Titanium は、Google Cloud の垂直統合型スタックの一部です。このスタックは、サーバーのカスタムシリコンから、42 のリージョンにわたって 775 万キロメートルの陸上および海底ファイバーを横断する地球規模のネットワークまで、効率を最大化し、超低レイテンシと高帯域幅を世界規模でお客様に提供するように設計されています。

コストパフォーマンスの新たな基準

N4D マシンシリーズは、前世代の N2D を上回るだけでなく、汎用コンピューティングワークロードで最大 50% 高い費用対効果、Java ワークロードで最大 70% 高い費用対効果 を実現しています。ウェブサービスワークロードの場合、N4D は Titanium と AMD の Turin プロセッサを活用して、驚異的なスループットを実現します。これにより、N2D と比較して最大 3.5 倍の費用対効果が得られ、応答時間が短縮され、エンドユーザーのエクスペリエンス全体が向上します。

2025 年 10 月時点パフォーマンスは、本番環境で実行された SPECrate®2017_int_base、SPECjbb2015、Google 内部 Nginx リバースプロキシベンチマークの推定スコアに基づく。Google Cloud の公開されている正規料金と推定正規料金に基づく費用対効果に関する主張。

「エッジプロキシフリートと社内データパイプラインでは、Google Cloud の N4D インスタンスは N2D と比較して パフォーマンスが 3 ～ 4 倍向上しました。また、当社のベンチマークでは、N4D は同じワークロードを処理する際に、CPU 使用率がごくわずかであるにもかかわらず、一貫性が大幅に向上しています。この価格パフォーマンスの飛躍により、汎用ワークロードを効率的にスケーリングできるようになり、当社が活用しているより具体的な Google コンピューティングプロダクトと並んで、フリートにぴったりと収まります。」 - Chronosphere、技術スタッフメンバー、Matt Schallert 氏

「 スループットが 10% 向上し、費用が最大 50%削減 されたことは、TCO の最適化において大きな成果です。Google Cloud の N4D マシンシリーズで実現したのがまさにそれです。MediaGo にとって、この効率性は非常に重要です。これにより、AI を活用した広告プラットフォームをより費用対効果の高い方法でスケールできるようになり、グローバルパートナーの ROI を最大化するという当社のミッションを直接的にサポートしています。」- MediaGo

「N2D から N4D への移行は、世代を大きく飛躍させるものです。 152 件のテストで 144.14% のパフォーマンス向上は、Google の Titanium が新しい AMD EPYC「Turin」プロセッサの可能性を最大限に引き出したことを証明しています。Google Cloud で最高の費用対効果を求めるお客様にとって、N4D インスタンスは明らかに最良の選択肢です。」- Phoronix、創設者 / 主執筆者、Michael Larabel 氏（調査の全文はこちらをご覧ください）

「新しい N4D インスタンスのリリースにより、Google Cloud は 第 5 世代 AMD EPYC プロセッサをベースとした最も包括的なポートフォリオを提供できるようになり、戦略的パートナーシップにおける重要なマイルストーンを達成しました。N4D マシンシリーズは、AMD CPU の優れたパフォーマンスと Google のカスタムマシンタイプの独自性を組み合わせることで、日常的なワークロードの費用対効果、柔軟性、費用最適化を大幅に向上させます。Google のベンチマークテストでこのことが確認されており、メディアのエンコードとトランスコードのワークロードでは、前世代の N2D マシンシリーズと比較して、パフォーマンスが最大 75% 向上しています。」- AMD、クラウドビジネスグループ担当シニアディレクター Ryan Rodman 氏

C4D マシンシリーズを補完

今年初めには、N4D と同じ基盤プロセッサ上に構築された汎用 C4D マシンシリーズを導入しました。一貫して高いパフォーマンスと、高度なメンテナンスサポート、より大きなシェイプ、次世代の Titanium ローカル SSD などのエンタープライズ機能を備えた C4D は、重要なワークロードに最適です。実際、Silk や Chess.com などのお客様は、前世代と比較して C4D で 40% 以上のパフォーマンス向上を報告しています。

しかし、重要なアプリケーションは、全体像の一部にすぎません。最新のクラウドアーキテクチャでは、柔軟性と費用対効果が重要な無数の汎用ワークロードも実行する必要があります。そのため、C4D を補完するものとして N4D を設計しました。C4D と N4D を併用することで、エンタープライズ機能、パフォーマンス、柔軟性、費用最適化の全範囲が利用可能になり、以下を選択できます。

C4D で一貫したパフォーマンスを実現: これは、最も要求が厳しく、レイテンシの影響を受けやすいアプリケーション向けのソリューションです。最大 200 Gbps のネットワーキング、ローカル SSD のサポート、最大 384 個の vCPU を備えた大型シェイプ、ベアメタルオプションにより、C4D は大規模データベース、高トラフィックの広告サーバーとゲームサーバー、要求の厳しい AI/ML 推論ワークロードに対して、予測可能なハイエンドのパフォーマンスを提供します。
N4D で柔軟な費用最適化: これは、汎用ワークロードの大部分を処理するエンジンです。N4D は、優れた費用対効果、低コスト、柔軟性を備えており、ウェブサーバー、マイクロサービス、開発環境などのアプリケーションの TCO を大幅に削減できます。

このアプローチはすでに実際の成果を上げており、Verve のようなお客様はビジネスを両面から最適化できるようになっています。

「Google の第 4 世代 AMD ポートフォリオにより、収益と費用の両方を同時に最適化できます。C4D は、コア広告サーバーに必要な一貫したピークパフォーマンスを提供します 。C3D より 81% 高速で、これにより、フィルレート（入札とリクエストのマッチングの成功）が向上し、収益が直接的に増加します。一方、 N4D は、GKE を使用したスケールアウトマイクロサービスなどの日常的なワークロードにおいて、N2D の 2 倍のパフォーマンスと費用対効果を実現し、全体的な TCO を削減しながら成長を可能にしています。この「Better Together」戦略により、ミッションクリティカルなサービスには C4D の一貫したピークパフォーマンスを使用し、柔軟で費用対効果の高い N4D を他のすべての場所で使用して TCO を積極的に削減できます。これは、他の場所で単一の VM タイプを使用するだけでは不可能なレベルの最適化です。」- Verve、プリンシパルシステムエンジニア、Pablo Loschi 氏

カスタムマシンタイプと Hyperdisk の利点

カスタムマシンタイプは、Google Cloud の重要な差別化要因であり、事前定義された「標準サイズ」を超えた構成が可能です。ワークロードを無理やり枠に押し込むのではなく、ワークロードのニーズに合わせてインフラストラクチャを調整できるため、費用を節約できます。たとえば、16 個の vCPU と 70 GB の RAM を必要とするメモリ集約型のワークロードは、通常、事前定義された N4D-highmem-16 シェイプに配置されるため、未使用のリソースに対して料金を支払うことになります。CMT を使用すると、正確に 16 vCPU と 70 GB の構成をプロビジョニングできるため、無駄をなくし、最大 17% の費用削減を実現できます。

最大 96 個の vCPU と 768 GB の DDR5 メモリを備えたシェイプで、カスタムマシンタイプと N4D を組み合わせることで、柔軟な vCPU 対メモリ比と拡張メモリのサポートにより、必要なリソースを正確に調整できます。

「Symbotic のビジョンは、規模と効率性を重視して構築された AI 搭載のロボットプラットフォームでグローバルサプライチェーンに革命を起こすことです。そのためには、強力でスケーラブルなインフラストラクチャが必要です。AMD の最新の EPYC プロセッサを搭載した Google Cloud の N4D VM は、まさにそれを実現しました。以前の N2D 世代と比較して パフォーマンスが 40% も大幅に向上 したため、シミュレーションの速度や忠実度を変えることなく、 CPU フットプリントを半分に 削減できました。これらのメリットをカスタムマシンタイプと組み合わせることができる （Google Cloud 独自の機能）ことは、大きな変革をもたらします。これにより、 ワークロードに合わせてインフラストラクチャを正確に構築 し、他のクラウドサービスと比較して TCO を大幅に削減できます。」- Symbotic、（CIO）最高情報責任者、Dan Inbar 氏

このきめ細かい制御と TCO のメリットは、コンピューティングだけでなくストレージにも及びます。カスタムマシンタイプで固定された vCPU とメモリの比率から解放されるのと同様に、Hyperdisk ではストレージのパフォーマンスと容量が分離されるため、容量とパフォーマンスを個別に調整して、ワークロードのブロックストレージ要件に正確に合わせることができます。

Hyperdisk Balanced ボリュームの Hyperdisk ストレージプールにより、この機能がさらに強化されています。これにより、各ボリュームを個別に管理するのではなく、パフォーマンスと容量をまとめてプロビジョニングできます。その結果、管理が簡素化され、効率が向上し、SAN ワークロードのモダナイズが容易になります。これらすべてが、ストレージの TCO を 30 ～ 50% 削減するのに役立ちます。

N4D を今すぐ利用開始

最新の N4D VM シリーズの導入は簡単です。特に、Google Kubernetes Engine（GKE）では、カスタムコンピューティングクラスによって、ワークロードを新しいハードウェアに移行する際の運用上のハードルが解消されます。VM タイプの優先順位付きリストに N4D を追加するだけで、ワークロードに必要なパフォーマンスとスケーリングの柔軟性を確保できます。N4D は現在、us-central1（アイオワ）、us-east1（サウスカロライナ）、us-west1（オレゴン）、us-west4（ラスベガス）、europe-west1（ベルギー）、europe-west4（オランダ）でご利用いただけます。

最新の提供状況については、リージョンとゾーンのページをご確認のうえ、Google Cloud コンソールまたは GKE から最初のインスタンスを今すぐデプロイしてみてください。N4D の詳細については、ドキュメントをご覧ください。

1. 9xx5C-044 - 2025 年 10 月 21 日時点の AMD パフォーマンスラボによるテスト。N4D-standard-16 のスコアと、Ubuntu24.04LTS OS（6.8.0-1021-gcp カーネル、SMT オン）で FFmpeg v6.1.1 ベンチマーク（エンコード 2 回とトランスコード 2 回の平均）を実行した N2D-standard-16 のスコアの比較。

パフォーマンスの向上（N2D に正規化）:

Ffmpeg_raw_vp9 1.76Ffmpeg_h264_vp9 1.76Ffmpeg_raw_h264 1.71Ffmpeg_vp9_h264 1.76FFmpeg 平均 1.75

提示されているクラウドのパフォーマンス結果は、各構成のテスト日に基づいています。結果は、基盤となる構成の変更や、VM とそのリソースの配置、クラウドサービスプロバイダによる最適化、アクセスされたクラウドリージョン、テナント、システムで同時に実行された他のワークロードのタイプなどの他の条件によって異なる場合があります。

-プロダクトマネージャー、Sarthak Sharma

Axion C4A メタルを発表: 特殊なユースケース向けの Arm ベースの Axion インスタンス

Tue, 25 Nov 2025 01:00:00 +0000

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

このたび、Google Axion プロセッサで実行される初のベアメタルインスタンスである C4A メタルが、まもなくプレビュー版として提供されることをお知らせいたします。C4A メタルは、ハードウェアへの直接アクセスと Arm® ネイティブの適合性を必要とする特殊なワークロード向けに設計されています。

Android 開発、自動車シミュレーション、CI/CD パイプライン、セキュリティワークロード、カスタムハイパーバイザなどの環境を実行している組織は、ネストされた仮想化のパフォーマンスオーバーヘッドや複雑さを気にすることなく、Google Cloud でこれらの環境を実行できるようになりました。

他の Axion インスタンスと同様に、C4A メタルインスタンスは標準の Arm アーキテクチャ上に構築されているため、Arm 向けにコンパイルされたアプリケーションとオペレーティングシステムは、クラウド、オンプレミス、エッジ環境間で移植可能なので、開発投資を保護します。C4A メタルは、96 個の vCPU、768 GB の DDR5 メモリ、最大 100 Gbps のネットワーキング帯域幅を提供し、Hyperdisk Balanced、Extreme、Throughput、ML ブロックストレージオプションを含む Google Cloud Hyperdisk を完全にサポートします。

Google Cloud は、ワークロードに最適化されたインフラストラクチャを提供し、あらゆるタスクに適切なリソースを提供します。Google Cloud Axion 仮想マシンファミリーなどの C4A メタルは、Titanium を搭載しています。Titanium は、Google のインフラストラクチャの基盤となる多層オフロードとセキュリティの重要なコンポーネントです。Titanium のカスタム設計された半導体デバイスは、ネットワーキングとストレージの処理をオフロードして CPU の負担を軽減し、専用の SmartNIC がすべての I/O を管理するため、Axion コアはアプリケーションのパフォーマンスだけに確保されます。Titanium は、Google Cloud の垂直統合型ソフトウェアスタックの一部です。このスタックは、サーバー内のカスタム半導体デバイスから、42 のリージョンにまたがる 775 万キロメートルの陸上、海底ファイバーを結ぶ地球規模のネットワークまで、効率を最大化し、超低レイテンシと高帯域幅を全世界でお客様に提供するように設計されています。

自動車ワークロードのアーキテクチャパリティ

自動車業界のお客様は、インフォテインメントや先進運転支援システム（ADAS）などの車載システムで、Arm アーキテクチャのパフォーマンス、効率性、柔軟な設計を活用できます。Axion C4A メタルインスタンスは、テスト環境と本番環境の半導体デバイス間のアーキテクチャのパリティを実現します。これにより、自動車テクノロジープロバイダは、本番環境の電子制御ユニット（ECU）で使用されているのと同じ Arm Neoverse 命令セットアーキテクチャ（ISA）でソフトウェアを検証できます。これにより、最終段階での統合で障害の起こるリスクが大幅に軽減されます。パフォーマンスが重要なタスクにも、物理ハードウェアの一貫した低レイテンシのパフォーマンスで、要求の厳しい仮想ハードウェアインザループ（vHIL）シミュレーションを実行し、テスト結果の信頼性と精度を確保できます。最後に、C4A メタルを使用すると、プロバイダはテストファーム全体を動的にスケーリングし、固定資本支出から柔軟な運用支出に変換することで、物理ラボの制約を超えることができます。

「この AI 定義車両の時代では、ペースの加速とテクノロジーの複雑さのために、ソフトウェア開発に対する従来の線形アプローチを再考せざるを得なくなっています。Google Cloud が Axion C4A メタルを導入したことは、この流れにおける大きな一歩です。テスト環境と物理的な半導体デバイスの間で Arm 上のアーキテクチャの完全なパリティを提供することで、お客様は開発サイクルの加速というメリットを享受でき、さまざまに特化したユースケースで継続的インテグレーションとコンプライアンスを実現できます。」- Arm、自動車ビジネス担当シニアバイスプレジデント兼ゼネラルマネージャー Dipti Vachani 氏

「当社のパートナー様とお客様は、高度な運転支援システムからデジタルコックピットまで、最もミッションクリティカルなシステムに必要な安全性、セキュリティ、信頼性、リアルタイムパフォーマンスを実現するために QNX を利用しています。ソフトウェア定義車両の時代が勢いを増すにつれ、ソフトウェア開発を物理的なハードウェアから切り離すことはもはや単なる選択肢ではなく、大規模なイノベーションに不可欠なものとなっています。Google Cloud の Axion 上の C4A-metal インスタンスのリリースは、強力な ARM ベースのベアメタルプラットフォームの導入であり、自動車エコシステムに革新的なクラウドインフラストラクチャのメリットをもたらすため、当社はこれをテストし、サポートすることを熱望しています。」- QNX、プロダクトおよび戦略担当シニアバイスプレジデント、Grant Courville 氏

「自動車モビリティの未来には、実践と開発において前例のないスピードと精度が求められます。Snapdragon Digital Chassis プラットフォームを活用する自動車メーカーやサプライヤーにとって、クラウド開発環境とテスト環境を車両内の Snapdragon SoC と同等に保つことは、効率と品質を確保するうえで非常に重要です。Google Cloud がこの分野に力を入れていることを嬉しく思います。Axion を搭載した C4A-metal インスタンスの提供は大きな前進であり、自動車エコシステムにクラウド内に物理環境と仮想環境間の真の 1:1 の環境を提供します。この画期的な技術により、統合の課題が大幅に軽減され、検証時間が短縮されるため、パートナー様は AI を活用した機能を大規模で迅速に市場に投入できます。」- Qualcomm Technologies, Inc.、プロダクト管理担当バイスプレジデント、Laxmi Rayapudi 氏

Android 開発でテストと本番環境を一致させる

Android プラットフォームは、ほぼすべてのモバイルデバイスの標準である Arm ベースのプロセッサ向けに構築されています。Android デベロッパーは、C4A メタルを備えた Axion プロセッサのベアメタルインスタンスで開発とテストのパイプラインを実行することで、ネイティブパフォーマンスのメリットを享受できます。これにより、命令ごとの翻訳レイヤの遅延など、エミュレーション管理のオーバーヘッドが排除されます。さらに、Android ビルドツールチェーンと自動テストシステムのレイテンシを大幅に削減し、フィードバックサイクルを短縮できます。また、C4A メタルはネストされた仮想化のパフォーマンスに関する課題も解決するため、スケーラブルな Cuttlefish（Cloud Android）環境に最適なプラットフォームとなります。

これが使えるようになると、開発者は Horizon の今後のリリースで、または Cloud Android Orchestration を直接利用して、スケーラブルな Cuttlefish 環境ファームを C4A メタルインスタンス上にデプロイできます。C4A メタルでは、これらの仮想デバイスを物理ハードウェア上で直接実行できるため、真の継続的テストのために大規模で忠実度の高いテストファームを構築、管理するために必要なパフォーマンスが提供されます。

妥協のないベアメタルアクセス

クラウドサービスとして、C4A メタルでは、物理ハードウェアの調達と管理のライフサイクル全体を予測可能な運用費用に置き換えますので、総所有コストを削減できます。これにより、サーバーの購入に伴う直接的な設備投資が不要になり、ハードウェアのメンテナンス契約、電力、冷却、物理的なデータセンターのスペースに関連する運用コストも不要になります。テストの需要に正確に一致するようにインスタンスをプログラムでプロビジョニングし、またプロビジョニング解除できるため、開発サイクルのピークを待機しているだけの過剰にプロビジョニングされたサーバーフリートに対して料金を支払う必要がなくなります。

Virtual Private Cloud（VPC）内の標準的なコンピューティングリソースとして動作する C4A メタルインスタンスは、仮想マシンと同じセキュリティポリシー、監査ログ、ネットワーク制御を継承して活用します。インスタンスは、ツールチェーンからは物理サーバーのように見えるように設計されており、一般的なモニタリングエージェントとセキュリティエージェントをサポートしているため、既存の Google Cloud 環境と簡単に統合できます。この統合はストレージにも及び、ここではネットワーク接続された Hyperdisk を使用すると、チームが仮想マシンフリートですでに使用しているのと同じスナップショットとサイズ変更ツールを使用して、永続ディスクを管理できます。

「当社のビルドシステムでは、真の分離が最重要事項です。Google Cloud の新しい C4A メタルインスタンスを Axion で実行することで、ビルドのパフォーマンスを損なうことなく、強力なハイパーバイザセキュリティ境界でパッケージビルドを分離できます。」- Chainguard, Inc.、創業者兼 CTO、Matthew Moore 氏

連携のメリット: Axion C シリーズと N シリーズ

Arm ベースの Axion ポートフォリオに C4A メタルが加わったことで、お客様はあらゆるワークロードに適切なインフラストラクチャをマッチングさせ、総所有コストを削減できるようになりました。Axion C4A 仮想マシンは一貫して高いパフォーマンスを発揮できるよう最適化されており、N4A 仮想マシン（現在プレビュー版）は費用対効果と柔軟性を最適化しています。一方、C4A メタルは、非仮想化 Arm 環境を必要とする特殊なアプリケーションによるハードウェアへの直接アクセスという重要なニーズに対応します。

たとえば、Android 開発企業は、ビルドファームに C4A 仮想マシンを使用することで、非常に効率的な CI/CD パイプラインを作成できます。大規模なテストでは、C4A メタルを使用して Cuttlefish 仮想デバイスを物理ハードウェア上で直接実行し、ネストされた仮想化のオーバーヘッドを排除できます。さらに忠実度を高めるために、C4A メタル上で Cuttlefish ハイブリッドデバイスを実行し、物理ハードウェアのシステムイメージを再利用できます。同時に、CI/CD オーケストレーターやアーティファクトリポジトリなどのサポートインフラストラクチャは、費用対効果の高い N4A インスタンスで実行できます。カスタムマシンタイプを使用してリソースを適正なサイズに調整し、運用費用を最小限に抑えることができます。

プレビュー版を近日提供予定

C4A メタルは近日中にプレビュー版がリリースされる予定です。早期アクセスとその他のアップデートに登録するには、こちらのフォームにご記入ください。

-Google Cloud、プロダクトマネージャー Yarden Halperin

コンピューティング

エージェント型エンタープライズのためのクロスクラウド インフラストラクチャのイノベーション

Fluid Compute

安全なクロスクラウド接続

統合データレイヤ

デジタル主権

Cloud TPU と vLLM で LLM 推論を試そう — リソース確保からベンチマークまで

TPU 確保方法の比較と DWS Flex Start モードの長所

vLLM と vLLM-TPU の違いとは？

ハンズオンガイド

1. TPU リソースのリクエスト (Flex Start)

2. インスタンスへの接続と Docker 環境設定

3. vLLM サーバーの起動とパラメータ・チューニング

4. [オプション] INT8 量子化 (W8A8) を用いた Serving

5. 動作確認とベンチマーク

Step 5.1. API エンドポイントへのテストリクエスト

Step 5.2. ベンチマークテストの実施

6. クリーンアップ：リソースの削除

まとめ

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

TPU 8: 特化された設計

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

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

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

TPU 8t と TPU 8i の概要

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

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

今後の対応

コンピューティングの最新情報: コア ワークロードとエージェント ワークロードのスケーリング

AI ワークロードと汎用ワークロードを同時に実行

I/O やレイテンシの影響を受けやすいワークロードを同時に実行

厳しいストレージ要件に対応

エージェントの時代に対応する流動的なインフラストラクチャ

Google Distributed Cloud の新たなイノベーション

マネージド AI インフラストラクチャ

データセンターの基盤モデル

AI 推論サービス: Google Distributed Cloud AI ゲートウェイの導入

エージェント型 AI アプリケーションとエージェント

Google Distributed Cloud で AI をどこでも利用可能に

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ironwood の主な最適化戦略

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

Google Cloud と NVIDIA が GTC 2026 で業界全体に AI イノベーションを拡大

G4 VM で AI ワークロードを高速化

分割式 G4 VM の導入

NVIDIA Vera Rubin NVL72 で AI Hypercomputer をスケーリング

AI インフラストラクチャ スタック全体で効率性を実現

Vertex AI のトレーニングと Model Garden の進化

公共部門向けの AI スタートアップを支援

共同エンジニアリングのコラボレーションが AI スタックのあらゆるレイヤを強化

H4D VM の一般提供開始: HPC ワークロード向けに卓越したパフォーマンスとスケーリングを実現

ドメインや規模を問わず、解決までの時間を短縮

HPC のコスト パフォーマンスの新たな基準

包括的な HPC 管理

お客様とパートナー様の声

今すぐ H4D を体験

課金の簡素化と費用削減: 新しい費用ベースの CUD に関する FinOps ガイド

1. 費用ベースの CUD データモデルの変更内容

2. 変更前後の節約額を検証する方法

3. 新しい CUD 分析の他の機能

4. どの程度のコミットメントを購入すべきか

5. フレキシブル CUD についての関連情報

Save more with expanded coverage for Compute Flex CUDs

エージェント型エンタープライズのためのクロスクラウドインフラストラクチャのイノベーション

コンピューティングの最新情報: コアワークロードとエージェントワークロードのスケーリング

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

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

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

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

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

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

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

AI インフラストラクチャスタック全体で効率性を実現

HPC のコストパフォーマンスの新たな基準

NVIDIA RTX PRO 6000 により、Cloud Run 上で高性能推論とサーバーレスコンピューティングが融合

カスタムマシンタイプと Hyperdisk によるきめ細かな制御

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

サービングレイヤ: NVIDIA Dynamo

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

N4D の一般提供を開始: スケールアウト型ワークロードのコストパフォーマンスが最大 3.5 倍に

コストパフォーマンスの新たな基準

カスタムマシンタイプと Hyperdisk の利点

自動車ワークロードのアーキテクチャパリティ

妥協のないベアメタルアクセス