Containers & Kubernetes

ZenteiQ、llm-d を搭載した GKE Inference Gateway でバッチ推論のスループットを 4 倍に拡大

Thu, 29 Oct 2026 01:00:00 +0000

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

今回は、Indian Institute of Science（IISc）からスピンアウトした AI スタートアップである ZenteiQ についてご紹介します。IndiaAI Mission の対象企業として選出された同社は、自国主導の科学基盤モデルをゼロから構築することを目指しています。物理法則、支配方程式、数値ソルバーを理解するモデルを事前トレーニングするため、ZenteiQ は、複数のモデルファミリーにわたって動作し、検証済みのデータセットをトレーニング実行にフィードする、大規模なバッチ合成データ生成パイプラインを設計、構築しました。Google Kubernetes Engine（GKE）と GKE Inference Gateway を活用して、ZenteiQ はパイプライン内に推論ルーティングレイヤを構築し、推論の総スループットを 4.07 倍に拡大するとともに、1 日あたりの出力をアクセラレータ 1,000 個あたり 14 億 7,000 万トークンから 59 億 7,000 万トークンに増加させました。 - Google Cloud、プロダクトマネージャー、Fisayo Feyisetan

主にウェブ上のテキストやコードを使用してトレーニングされた汎用言語モデルとは異なり、科学基盤モデルは、熱力学、計算流体力学、電磁気学などの分野にわたる複雑な物理システム、数学的支配方程式、数値ソルバーを理解する必要があります。ZenteiQ では、シミュレーション出力を解釈し、方程式の定式化を評価し、物理法則に従って段階的に数学的導出を行う、自国主導の科学基盤モデルをゼロから構築しています。

支配方程式の大規模なデータセットを使用してモデルを事前トレーニングするには、数千億もの推論トークンが必要です。ZenteiQ では、キュレートされた科学文献やシミュレーションデータセットに加え、独自に設計、実装したバッチ型合成データ生成パイプラインも利用しています。このパイプラインは、候補となる導出やソルバー検証問題を生成、評価、フィルタしてから、MaxText の事前トレーニングジョブにフィードします。

ZenteiQ は演算リソースの割り当てを固定して運用しているため、アクセラレータがトレーニングデータの生成と検証に 1 時間費やすごとに、事前トレーニングに使える時間が 1 時間減少します。データ生成に遅れが生じると、事前トレーニング用に予約されたマルチホストアクセラレータクラスタは、データセット待ちのアイドル状態になります。

データ生成が事前トレーニングの遅れにつながるケース

データの生成速度を最大化するため、パイプラインでは、ワーカー Pod でのプロンプトの準備と、マルチノードアクセラレータプールにおける vLLM でのモデルサービングを分離しています。各バッチは 4 つの段階を経て処理されます。科学的なシードコンセプトのプロンプトバッチへの拡張、生成モデルによる推論トレース候補の生成、評価モデルによる回答のスコアリング、別のモデルファミリーによるガードレールチェックを実行した後、検証済みのデータセットを事前トレーニング用にパッケージ化します。

当初、これらのモデルプールは Kubernetes 上で運用され、推論エンドポイント間で標準的な ClusterIP によるラウンドロビン方式のロードバランシングが行われていました。90 億パラメータおよび 350 億パラメータというモデルスケジュールに対応できるようパイプラインをスケールアップしたところ、2 つのルーティングボトルネックが発生し、データセットの作成が遅れ始めました。

不均一なエンジンキュー: アップストリームのワーカー Pod は、シードコンセプトを複雑さやレスポンス長が大きく異なるプロンプトへと展開します。標準的なラウンドロビン方式のロードバランシングでは、vLLM のエンジンキュー状況を可視化できないため、近くのノードに余力があるにもかかわらず、長い推論トレースの処理ですでにビジー状態になっているサービング Pod に新たなリクエストを送り続けていました。
冗長なプレフィックス計算: 生成バッチ内のプロンプトでは、指示コンテキストやタスク仕様の約 70～80% が共通しています。ラウンドロビン方式のルーティングでは、同じ指示を含むリクエストが異なるサービングインスタンスに分散されるため、各 Pod はアクセラレータメモリ内のウォームキャッシュを再利用できず、同じ共有プロンプトプレフィックスをゼロから再計算しなければなりませんでした。

不均一なキューと冗長なプレフィル作業が重なることで、1 回の実行における生成スループットが最大半分まで変動し、データセットの作成が長引き、スケジュールされていた事前トレーニングの開始が遅れてしまいました。そのため、研究者にモデル開発を中断させてカスタム推論スケジューラを構築、保守させることなく、vLLM キューの深さやプロンプトキャッシュをリアルタイムで把握できるルーティングが必要でした。

llm-d を搭載した GKE Inference Gateway による基盤構築

ZenteiQ ではすでにデータの準備と MaxText の事前トレーニングジョブを GKE で実行しているため、チームは同じ Kubernetes プラットフォーム上でデータ生成とモデルトレーニングを管理できます。Google Cloud からの推奨事項に従い、基盤となる科学的手法やパイプライン設計を変更することなくルーティングのボトルネックを解消できるよう、オープンソースの llm-d 分散推論フレームワークを搭載した GKE Inference Gateway を、vLLM アクセラレータプールの前にデプロイしました。

このパイプラインでは、ワーカー Pod が Cloud Storage から科学的なシードドキュメントやドメイン分類体系を取得し、それらをマルチステッププロンプトのバッチへと展開します。これらのバッチは、すべてのモデルファミリーおよびサービングノード間のトラフィックを管理する、単一の GKE Inference Gateway デプロイを経由して処理されます。

モデル階層ごとに独立したルーティングを維持するのではなく、生成リクエスト、評価クエリ、ガードレールチェックを、同じゲートウェイ経由でそれぞれのモデルプールにルーティングします。候補となる回答が評価とガードレールチェックに合格すると、ワーカー Pod が検証済みデータセットの重複排除とパッケージ化を行い、GKE 上のダウンストリームの MaxText 事前トレーニングジョブで直接使用できるようにします。

GKE Inference Gateway は、検証済みデータセットを MaxText の事前トレーニングにフィードする前に、vLLM を実行しているマルチノードアクセラレータプール全体に、バッチ生成、評価、ガードレールの各リクエストをルーティングします。

ラウンドロビン方式から負荷とキャッシュを考慮したルーティングへ

GKE Inference Gateway と llm-d を導入すると、ルーティングの決定には、静的なラウンドロビン方式のローテーションではなく、vLLM インスタンスからのリアルタイムのサービングシグナルが使用されます。GKE Inference Gateway は、vLLM エンドポイント全体のリアルタイムのキュー深度や Key-Value（KV）キャッシュの使用率を継続的にモニタリングします。サービングノードが長い方程式の導出のデコード処理でビジー状態になっている場合、ゲートウェイは受信リクエストを処理能力に余力のあるノードにルーティングします。そのため、近くのノードがアイドル状態であるにもかかわらず、ビジー状態のワーカーの後ろに負荷の高いプロンプトが溜まることはなくなります。

同時に、ゲートウェイは、科学的指示が一致するリクエストを、そのプレフィックスの KV キャッシュがアクセラレータメモリ内ですでにウォーム状態にあるサービングノードにルーティングします。各プロンプトの 70～80% は指示コンテキストが共通していますが、生成される推論の軌跡はリクエストごとに異なります。プレフィックスキャッシュの局所性とキューのリアルタイムバランシングを組み合わせることで、Pod は単一のレプリカに過負荷をかけることなく、繰り返しのプレフィル作業をスキップできるようになります。

スループットの向上とトレーニング実行の予測可能性

llm-d を搭載した GKE Inference Gateway を導入したことで、データ生成パイプラインの処理速度と予測可能性が向上しました。本番環境クラスタ全体で、インテリジェントルーティングにより以下が実現しました。

フリートのスループットが 4 倍に向上: アクセラレータ 1,000 個あたりの総スループットが毎秒 16,964 トークンから 69,114 トークンに急増し、1 日あたりの出力が 14 億 7,000 万トークンから約 60 億トークンに増加しました。
個々のモデルプール全体で 3.5～5.5 倍のパフォーマンス向上: リアルタイムのキューバランシングにより、各実行を通じてサービングノードの負荷が均等に保たれ、時間のかかる推論導出に起因する実行中の速度低下が防止されました。
プレフィックスキャッシュヒット率が 14 パーセントポイント向上: 科学的指示が一致するプロンプトをウォームキャッシュにルーティングすることで、各リクエストが独自の導出に分岐する前に、冗長なプレフィル作業を回避しました。

研究チームとインフラストラクチャチームにとって、最も重要な成果はスケジュールの予測可能性でした。1 日の出力が 4 倍になったことで、検証済みデータセットが時間どおりに準備され、データ生成を待つことなく、マルチホストの事前トレーニングがスケジュールどおりに開始されるようになりました。

ZenteiQ における物理 AI の今後の展開

科学基盤モデルを 90 億パラメータから 350 億パラメータ以上へとスケールアップするにあたり、トレーニング後の強化学習（RL）と自動数値ソルバー評価ループにも、これと同じ GKE Inference Gateway と llm-d ルーティング設定を使用する予定です。マルチターンロールアウトでは、各ターンが前のターンのコンテキストに基づいて構築されるため、キューのリアルタイムバランシングとウォームプレフィックスキャッシュへの依存度がさらに高くなります。

これらの機能を独自のワークロードで試すには、GKE Inference Gateway のドキュメントと、オープンソースの llm-d プロジェクトをご覧ください。また、Gemini プラットフォームチームが GKE Inference Gateway を使用してレイテンシを 35% 抑えた方法もご確認ください。

- ZenteiQ、創業者、Sashikumaar Ganesan 教授

- Google Kubernetes Engine、プロダクトマネージャー、Fisayo Feyisetan

AI インフラストラクチャとオーケストレーションに関する最新情報

Tue, 20 Oct 2026 02:00:00 +0000

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

9 月はスケーラビリティ月間です。世界がエージェントフリートの急増に備えるなか、Google はそのニーズに迅速かつ適切に対応できるように AI インフラストラクチャとオーケストレーションサービスを強化するとともに、ワークロードの分離とセキュリティを維持し、コストを抑えています。今回の記事では、Google Cloud のコンピューティング、ネットワーク、ストレージ、オーケストレーションのサービス全体でこれらの機能強化がどのように現れているかに加えて、お客様が Google Cloud AI インフラストラクチャを使用する新しい方法、Google の戦略に対するサードパーティの業界検証をご紹介します。

プロダクト、テクノロジー、ツールに関する最新情報

Google Kubernetes Engine の更新: GKE チームはプラットフォームのスケーラビリティの向上に全力を注いでいます。9 月には、さまざまな形や規模で改善が行われました。

新機能: エージェントワークロードに、より高密度の実行ランタイムが必要ですか？新しいオープンソースの GKE Agent Substrate は、標準的なコンテナランタイムよりも 10 倍高い密度で数百万のサンドボックスを実行できるように設計されています。また Agent Substrate は、ネイティブのゼロトラストカーネルとネットワーク分離により、1 秒あたり 500 回を超える一時停止 / 再開アクティベーションを実行しながら、500 ミリ秒未満での再開オペレーションを実現します。
プロダクトの最新情報: GKE にゼロへのスケーリング機能が組み込まれました。ワークロードをスケールダウンするために複雑なコンポーネントを構成する必要はありません。AutoscalingMetric を使用した HPA と KEP-2021 のサポートにより、その作業はすぐに自動的に行われます。詳細については、こちらのブログ記事をお読みください。
プロダクトの最新情報: さらに、GKE HPA（前述の AutoscalingMetric を使用）では、標準指標に加えてカスタム PromQL 指標に基づいてスケールアップとスケールダウンを行えるようになりました。これにより、ビジネスにとって意味のある独自の条件に従ってワークロードをトリガーできます。詳しくはこちらをご覧ください。
新機能: もう一つのスケーラビリティ機能は GKE Pod スナップショットです。これは、CPU や GPU のメモリを含むワークロードの実行状態を保存し、オンデマンドで復元できるようにするものです。内部テストによると、GKE Pod スナップショットにより、AI 推論の起動時間を最大 89% 短縮できます。詳しくはこちらをご覧ください。
新しい移行ツール: 最後に、コンテナワークロードを AWS EKS から GKE に移行したいと考えていたものの、困難で摩擦の多いエンジニアリング作業を恐れていた方のために、GKE エージェント型移行をリリースしました。これは、不安定なアドホックプロンプトに代わり、決定論的なガードレールで保護された AI 支援移行パイプラインを提供する専用のエージェントプラグインです。エージェントスキルとローカルの Model Context Protocol（MCP）サーバーを組み合わせた設計になっており、AI を使用して複雑な AWS EKS IaC と Kubernetes マニフェストを GKE ランディングゾーンに直接変換します。オンボーディングガイドを確認して利用を開始しましょう。
機能の更新: 強化学習（RL）と評価のワークロードは非常に複雑です。標準的なエージェント RL ループでは、LLM ポリシーが GPU 上でコードスニペットなどのアクションを生成し、分離された CPU サンドボックス内で実行して報酬シグナルを観察します。しかし、このループをスケールアップして数万の並列ロールアウトをサポートしようとすると、アクセラレータのアイドル状態、イメージのカーディナリティ、コントロールプレーンの飽和など、インフラストラクチャのボトルネックが発生します。そこで、RL 向けに最適化された GKE Agent Sandbox に加えて、Agent Sandbox RL オーケストレーション SDK、一般的な RL ジムやハーネスとのネイティブ連携機能を開発しました。すべて一般提供が開始されています。詳しくはこちらをご覧ください。

ストレージの最新情報: AI は大量のデータをトレーニングして作成します。そのデータは、ブロックストレージシステム、ファイルシステム、オブジェクトストア、データベースのいずれかに保存する必要があります。この重要なレイヤがエージェントの要求に対応できるよう、ストレージポートフォリオの強化を発表しました。

プロダクトの最新情報: Filestore エージェントボリュームは、エージェントワークロード向けに高パフォーマンスで柔軟な永続ファイルストレージを提供します。GKE Agent Substrate および GKE Agent Sandbox との緊密なインテグレーションにより、Filestore エージェントボリュームは、分離された専用ファイルワークスペースを GKE Agent Sandbox にミリ秒単位で自動的に割り当て、アタッチします。プレビュー版へのアクセスはこちらからリクエストできます。
新しいプロダクト: 生成 AI と RAG のデータレイヤ（Milvus、Pinecone、Qdrant、Vespa、Redis、インメモリコンテキストキャッシュなど）を実行している場合は、M4N ファミリーの VMをご覧ください。一般提供が開始されたこれらの VM は、主要なハイパースケーラーの中でコアあたりの IOPS とスループットが最高です。M4N インスタンスは、Google Cloud のカスタム Titanium オフロードアーキテクチャおよび Hyperdisk Extreme と組み合わせることで、ホストあたり合計で最大 25,000 MiB/秒（25 GiB/秒）のストレージスループットと最大 100 万 IOPS を実現します。
新しいプロダクト: もう一つの新しい Compute Engine プロダクトである Z4D の一般提供が開始され、AI / ML のトレーニングおよび推論ワークロード向けの強力なストレージソリューションとしてご利用いただけるようになりました。ベアメタルインスタンスとして構成すると、Z4D はエージェント型マイクロ VM に必要な大容量のローカル SSD（LSSD）と低レイテンシの両方を提供するため、ホストごとに数千の分離されたサンドボックスをネイティブのパフォーマンスと効率で実行できます。Z4D マシンの詳細はこちらでご確認ください。
プロダクトの最新情報: 現在の AI トレーニングや推論のパイプラインは、ほとんどのストレージ管理システムが対応できないほどのスピードでデータを作成するため、ストレージ資産を把握しようとするチームにとって課題となっています。Storage Intelligence アドバイザーの新バージョンでは、「バケットには何が入っているか？」という疑問の答えが簡単にわかり、予期しない変更をすばやく特定できます。さらに、強化されたバッチオペレーションにより、バケット全体にわたる一括変更、たとえば、ストレージクラスの移動、古いデータや一時データの一括削除、メタデータ、タグ付け、保持、暗号化の変更の適用などを自動化できます。Storage Intelligence アドバイザーの最新情報については、こちらをご覧ください。
新しいプロダクト: 最後に、AlloyDB for PostgreSQL の新バージョンは、Google の先駆的なインフラストラクチャである Colossus 分散ファイルシステムと Jupiter ネットワークを統合し、エージェントの時代における妥協のない新しいデータベースアーキテクチャを実現します。

実践ガイドとハウツー

ハウツー: 世界中に分散している GPU と TPU を、単一のエントリポイントの背後にある単一のプールとして動作させたいとお考えの場合は、こちらのブログ記事でその方法をご確認いただけます。エッジでは、マルチクラスタ GKE Inference Gateway が、グローバルなマルチリージョントラフィック分配と高可用性を担います。その下では、LLM-d ルーターが、使用率を高く維持するための複雑なメモリ認識型スケジューリングアルゴリズムを処理します。このアーキテクチャは、ランタイム、モデル、アクセラレータに依存しないように意図的に設計されており、テストでは、マルチクラスタ GKE Inference Gateway を介してトラフィックをルーティングしたところ、オーバーヘッドは 1% 未満でした。
ガイド: AI モデルのトレーニングや推論に TPU 上の GKE を使用されているか、使用される予定ですか？巨大な大規模言語モデル（LLM）のトレーニングや、高スループットの推論サービングの実行には、Cloud TPU や Cloud GPU などの特殊な AI ハードウェアへの多額の投資が必要です。費用対効果を最大化するには、GKE のワークロードライフサイクル指標を理解する必要があります。この詳細なガイドでは、不透明なクラスタの動作を実用的なテレメトリーに変換する方法を説明します。

お客様とパートナーに関する最新情報

GKE のお客様: ゲームのスタートアップである SeaVerse がマルチテナントワークロードに GKE Agent Sandbox を利用している理由と、このプラットフォームによってインフラストラクチャ費用を 60% 削減できた経緯をご覧ください。

調査、レポート、詳細解説

また、Google は Gartner と Forrester の 3 つの主要なアナリストレポートでリーダーに選出され、プロダクトまたは戦略のいずれかで最高スコアを獲得しました。

Google、「The Forrester Wave™: Public Cloud Platforms, Q3 2026」でリーダーに選出: クラウドプロバイダの中で最高の総合スコアを獲得しました。
Google、2026 年 Gartner® Magic Quadrant™ で戦略的クラウドプラットフォームサービス部門のリーダーに選出: 評価対象となったすべてのベンダーの中で、「ビジョンの完全性」において最高評価を獲得しました。
Google、2026 年 Gartner Magic Quadrant でコンテナ管理部門のリーダーに選出: 評価対象となった全ベンダーの中で「実行能力」において最高評価を獲得しました。
Google Cloud は、世界中の GPU プロバイダの信頼性、パフォーマンス、サポート、料金、セキュリティを評価する最新の SemiAnalysis ClusterMax 3.0 レポートでゴールド評価を獲得しました。詳しくは、レポート全文をご覧ください。

2026 年 8 月

プロダクト、テクノロジー、ツールに関する最新情報

プロダクトの最新情報: Filestore は Google Cloud がファーストパーティとして提供するセキュアでスケーラブルな NFS ファイルサービスであり、AI やエージェントワークフロー向けのストレージプラットフォームとして人気を集めています。このたび、Google の基盤となる分散ストレージシステムである Colossus 上に直接構築された新しいバックエンドストレージレイヤが追加され、これらのタスクにさらに適したサービスとなりました。この新しいバックエンドでは、ストレージ容量とは別に IOPS をプロビジョニングでき、GKE と緊密に統合されています。AI 環境では、いわゆるエージェントスウォーム（多数のエージェントからなる大規模なグループで、共通のデータセットに対して読み取りと書き込みを行う必要がある）を、パフォーマンスを低下させることなく処理できます。詳しくは、ブログ投稿をご覧ください。
新機能: gVisor サンドボックスを GKE 上の分散 Ray クラスタで利用できるようになりました。Anyscale との提携により、gVisor を分散 Ray クラスタに直接組み込むことができる、Ray 向けの試験運用版ライブラリを導入しました。gVisor は Google のオープンソースアプリケーションカーネルであり、通常のコンテナよりも強力な分離機能を持ち、起動時間が短く、メモリオーバーヘッドが少ない軽量な環境を提供します。GKE でこれらのサンドボックス機能を試すには、Ray サンドボックスユーザーガイドをご覧ください。
プロダクトの最新情報: 費用はあまりかけたくないけれど、パーソナル AI エージェントを実行するための高性能で使いやすいインフラストラクチャをお探しという方に朗報です。新しい Cloud Run インスタンスは、Cloud Run 上の専用のシングルトンコンピューティングランタイムであり、エージェントがアイドル状態になってもシャットダウンされません。さらに、1 個の vCPU と 1 GiB のメモリを備えた Cloud Run インスタンスを 30 日間連続で実行しても、費用は 5.70 ドルしかかかりません。

実践ガイド、ドキュメント、ハウツー

入門ガイド: Model Context Protocol（MCP）に関する最新情報: 2026-07-28 仕様で、プロトコルコアは「完全にステートレスになりました。handshake はなくなり、initialize / initialized handshake（SEP-2575）と論理的な Mcp-Session-Id ヘッダー（SEP-2567）は完全に削除されました。代わりに、すべてのリクエストが自己記述型で独立したものになりました。」最新の MCP 仕様の変更点と、さらに重要なその実装方法について詳しくは、こちらの Google for Developers のブログ記事をご覧ください。
ガイド: 従来のネットワークロードバランシング手法では、リアルタイム AI システムをうまく扱いきれない場合があります。「バックエンドは、今までのように個別のリクエストを処理するのではなく、継続的なライブ双方向ストリームを管理する必要があります。音声チャンク、文字起こし、モデル出力、合成音声が同時にやり取りされる、絶え間ないストリームを処理するからです。」ここにユーザーへの対応が追加されると、状況はさらに悪化します。「サーバーは、現在処理中の音声生成を即座に停止して、コンテキストを更新し、場合によっては新しいツールをトリガーして、別の回答の作成を開始する必要があります。また、これを接続を切断することなく行わなくてはなりません。」AI 時代における負荷管理の新しいアプローチについては、セッション対応のロードバランシングによるリアルタイム AI エージェントのスケーリングをご覧ください。
ハウツー: さまざまな GPU アクセラレータが混在する場合でも、GKE 上に弾力性のあるスケーラブルな LLM 推論プラットフォームを構築する方法を学びます。ここで提案するアーキテクチャでは、Capacity Advisor と Compute Advisor に加え、Run:ai Model Streamer や、並列ダウンロード機能を備えた GCSFuse などの高性能ストレージを組み合わせて使用します。詳しくは、こちらをご覧ください。
ドキュメント: GPU や TPU を搭載したホストの問題は、ライブマイグレーションを使用して更新することができないためにメンテナンスが困難であることです。この新しいドキュメントページでは、トレーニングワークロードと推論ワークロードのダウンタイムをどれだけ許容できるかに応じて、アクセラレータ搭載ホストを更新する方法を説明します。
ドキュメント: Advanced Compute Images（ACI）は AI / ML および HPC インフラストラクチャ用の標準化されたイメージスタックであり、独自のカスタムイメージを手動で構築する必要はありません。この新しいドキュメントページでは、Google Cloud CLI、コンソール、または SchedMD の Slurm ワークロードマネージャーを使用して ACI イメージを作成する方法を説明します。
ガイド: AI ワークロードは、設計の難しさ、リソース消費の激しさ、そしてバースト性があることで知られています。これらはスケーリングのボトルネックを招くだけでなく、十分に活用されない（または誤用される）コンピューティングリソースを大量に発生させる原因にもなります。新しいブログ投稿では、Google Cloud で動的な容量管理を実現する 3 つの主な方法について説明します。その 3 つの方法は以下のとおりです。1）計画的なダウンタイムに備えて容量をスケジュールする、2）計画外のダウンタイムに備えて自動フォールバック容量を確保しておく、3）GKE のコアオーケストレーション機能を利用してリソース割り当てを自動化する。

お客様とパートナーに関する最新情報

ビジネスオーケストレーションソフトウェアプロバイダの UiPath は、急激に変動するワークロードに対処し、費用の予測可能性を高めたいと考えていました。これを実現するために、同社は分離された複数のクラスタで構成されていたインフラストラクチャを再設計し、トレーニング用の A3 VM インスタンス（NVIDIA H100 GPU）と推論用の G4 VM インスタンス（NVIDIA RTX PRO 6000 Blackwell Server Edition GPU）の両方を含む共有 Google Cloud GPU フリートへと移行しました。同社のアーキテクチャについて詳しくは、こちらをご覧ください。
AI 開発の加速に注力する最先端の AI 研究所である Mirendil は、モデルの事前トレーニングとトレーニング後のアプリケーションをサポートするために、TPU と NVIDIA GPU の両方を備えた AI Hypercomputer を使用することを発表しました。
小売業向け CRM プロバイダの Replenit は、BigQuery、Gemini Enterprise Agent Platform、Cloud TPU で実行するオープンソースの Gemma モデルを使用して、Google Cloud で AI 意思決定エンジンを構築しました。同社では、この組み合わせにより、以前のクラウドプロバイダと比較してパイプライン費用が 90% 削減されたとしています。詳しくは、事例紹介の全文をご覧ください。
Malachyte は、Bigtable、Managed Service for Apache Kafka、Pub/Sub、Compute Engine、そして GKE を基盤として、AI を活用した e コマースレコメンデーションプラットフォームを構築しました。こちらのブログ記事で、これらがどのように連携するかをご覧ください。

2026 年 7 月

プロダクト、テクノロジー、ツールに関する最新情報

プロダクトの最新情報: Google Cloud Managed Lustre の一般提供が開始されました。4 種類のパフォーマンスティアがあり、容量 1 TiB あたり 125 MB/秒、250 MB/秒、500 MB/秒、1,000 MB/秒のスループットを選択できます。ストレージ容量は最大 8 PB までスケールアップ可能です。Managed Lustre ソリューションは DDN の EXAScaler を活用しており、DDN が数十年にわたって培ってきた高パフォーマンスストレージ界をリードする技術と、Google Cloud のクラウドインフラストラクチャに関する専門知識を組み合わせています。
プロダクトの最新情報: C4N ネットワーク / ストレージ最適化 VM の一般提供を開始しました。C4N は、データ転送のボトルネックを解消するために構築された、Google 初のネットワークとブロックストレージに最適化された VM シリーズです。第 5 世代 Intel Xeon スケーラブルプロセッサを搭載し、Google の Titanium オフロードハードウェア上に構築された C4N は、400 Gbps のネットワーク帯域幅と 9,500 万パケット/秒（95 MPPS）の処理速度を実現します。また、Hyperdisk Extreme と組み合わせた場合のブロックストレージスループットは最大 25 GiB/秒に達します。
新機能: GKE Dataplane V2 が、ネットワークポリシー適用下で最大 15,000 ノードまでサポートできるようになりました（一般提供）。これにより、標準の GKE クラスタ上で、ネットワークポリシーの適用を完全に維持したまま、最大 15,000 ノードまでのスケールアップが可能になります。大企業や AI / ML を活用するお客様の膨大なインフラストラクチャニーズに対応する機能です。
新機能: llm-d が協調型タイムスライスに対応しました。強化学習（RL）ワークロードで、独立した RL ジョブを共有の物理ハードウェアにインターリーブして実行できるようになりました。これにより、モデルの収束や精度に影響を与えることなく、アクセラレータの総デューティサイクルをベースラインの約 40% から最大 70% まで引き上げることが可能です。
新しい AI セキュリティツール: GKE 上の AI サプライチェーンの保護、AI ワークロードの安全なデプロイ、シャドー AI の削減をお考えですか？Google は k8s-aibom をオープンソース化しました。これは、コンテナクラスタを継続的にモニタリングして、実行中の AI ランタイム（vLLM や Triton など）を自動的に検出し、標準的な CycloneDX Machine Learning 部品構成表（ML-BOM）を生成する、軽量で特権を必要としない Kubernetes コントローラです。k8s-aibom プロジェクトをチェックして、ぜひ開発にご参加ください。

実践ガイドとハウツー

入門ガイド: 7 月 27 日、Google は Moonshot AI の 2.8 兆パラメータのオープンウェイトモデルである Kimi K3 の「Day 0 サポート」を発表しました。モデルのウェイト公開と同時にサポートを開始し、即日の利用を可能にしました。Model Garden、カスタムオーケストレーション、llm-d レシピを使用した GKE など、選択したデプロイ手法に合わせて Google Cloud で Kimi K3 を評価して試験運用するための詳細な手順をこのガイドでご確認いただけます。
入門ガイド: Google Kubernetes Engine（GKE）マネージド DRANET は、GPU と TPU の両方に対応しています。この実装を使用するための構成には、標準クラスタ（ユーザーが完全に制御可能）や Autopilot クラスタ（Google によって複雑な構成が自動的に行われる）など、いくつか選択肢があります。詳細については、ハンズオンラボ TPU を使用する GKE Autopilot クラスタ、GKE マネージド DRANET、Gemma 4 でご確認いただけます。
入門ガイド: GPU ではなく TPU で Ray を実行する方法を学べます。全 2 回シリーズのパート 1 では、TPU スライスについて説明します（ヒント: Ray は TPU スライスを、スケジュール設定可能なアクセラレータの一種として認識します）。続くパート 2 では、Ray のさまざまな AI ライブラリについて説明します。
入門ガイド: 新しいマイクロベンチマークスイートを使用して、サンプルワークロードにおける TPU の性能を評価します。このスイートを活用することで、デバイスが理論上のパフォーマンス仕様を達成しているかを正確に測定できるほか、特定の性能ギャップやアーキテクチャ固有のボトルネックを特定することも可能です。詳細はこちらでご確認いただけます。
入門ガイド: 予算を圧迫することなく、エージェントをスケールしましょう。GKE Agent Sandbox と Pod スナップショットを活用して固定のコンピューティングリソース内でより多くのエージェントを安全に集約する方法を、GKE オーケストレーションの観点から解説します。パフォーマンス重視かコスト重視かを問わず、エージェントの効率を最大化するための適切な最適化方法を解説します。
技術ブループリント: Ironwood における Mistral 3 Large 推論の最適化について詳細に解説します。こちらのブログ記事では、Google のあるチームが Google の Ironwood（TPU v7x）で Mistral 3 Large MoE モデルの推論を最適化し、パフォーマンスを 1.5 倍向上させた方法について説明しています。具体的には、ハイブリッドシャーディングの導入、線形 VPU 合計からツリーリダクションへの置き換え、GMM / MLA カーネルの最適化、非同期スケジューリングの採用によって、これを実現しました。その結果、ベンチマーク精度を維持したまま、スループットを最大 48% 向上させるという成果を収めました。ブログの全文はこちらでご覧ください。

調査、レポート、詳細解説

レポート: Google は、初めて発表された GartnerⓇ Magic Quadrant™ の AI インフラストラクチャ部門において、リーダーに選出され、「実行能力」で最高位、「ビジョンの完全性」で最も先進的との評価を獲得しました。Gartner は、Google 独自の拡張可能なコンピューティング、統合された AI Hypercomputer アーキテクチャ、AI コンピューティング容量の規模を主な強みとして挙げています。レポートはこちらからダウンロードしてお読みいただけます。
レポート: Google は先ごろ、「AI インフラストラクチャの現状」レポートの作成にあたり、1,400 人を超える IT 部門の上級リーダーを対象に調査を実施しました。その結果、AI に対する構想とインフラストラクチャの実態との隔たりが広がっているという明確な傾向が浮かび上がりました。実際、83% の組織が、本番運用に対応できるエージェント型 AI を支えるには、インフラストラクチャのアップグレードが必要だと回答しています。この調査について紹介したブログ記事では、エージェント型アプリケーションがシステムに求める要件に合わせてインフラストラクチャを整備することで、試験導入から本番運用への移行を進めやすくなることを説明しています。

2026 年 6 月

プロダクト、テクノロジー、ツールに関する最新情報

プロダクトの最新情報: AI で使用される機密データの保護は、先進的でセキュアなクラウドインフラストラクチャを実現するうえで欠かせない要素です。Confidential Computing は、ハードウェアベースの高信頼実行環境（TEE）で使用中のデータを暗号で保護し、データの完全性を検証可能にする技術です。このたびこの技術が、NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載したアクセラレータ最適化型 G4 マシンシリーズで提供開始されました。Confidential G4 VMs と Confidential G4 GKE Nodes をぜひ使ってみてください。
デベロッパー向けリソース: 新設された TPU デベロッパーハブは、モデルの作成者、最適化担当者、デベロッパーが Google Cloud TPU のパフォーマンスを最大限に引き出す方法を学ぶための場所です。詳細については、こちらのブログ記事をご覧ください。
新プロダクト: 新しい OpenTelemetry ベースの TPU AI テレメトリーコレクタエージェントを使用して、AI ワークロードをスケールしましょう。このたび初めて、高忠実度の TPU ハードウェアテレメトリーを、Google Cloud Monitoring、Google Managed Prometheus、または独自のセルフホスト型 Grafana スタックにルーティングできるようになりました。

実践ガイドとハウツー

入門ガイド: TPU、Cloud Storage FUSE、動的リソース割り当て（DRA）を使用して、GKE Inference Gateway で実行される AI 推論ワークロードで高可用性を実現する方法を学べます。こちらのブログ記事で概要を紹介しています。また、技術的な詳細についてはハンズオン Codelab でご確認いただけます。
入門ガイド: Model Context Protocol（MCP）を使用して、AI エージェントを Cloud Storage の非構造化データに接続できることをご存じですか？こちらのブログ記事では 3 つのお客様事例に基づく導入のメリットと、具体的な実装方法を解説しています。フルマネージドサービスにすべきか、詳細なカスタマイズと管理が可能なセルフマネージドローカルサーバーにすべきかを判断する方法もご紹介しています。

調査、レポート、詳細解説

レポート: 第三者機関によるベンチマークレポートにおいて、GKE Inference Gateway は他社の主要マネージド Kubernetes サービスを凌駕するパフォーマンスを記録しました。具体的には、スループットは 15.7% 高く、待ち時間は 92.8% 短く、トークン間のレイテンシは 62.6% 低いという結果でした。このパフォーマンスの鍵は、接頭辞キャッシュの使用にあります。長く繰り返し使用されるプロンプトの接頭辞に対応する KV キャッシュ（アクティベーション状態）を保存することで、LLM のパフォーマンスを最適化しています。詳しくは、こちらのブログ記事をご覧ください。
アーキテクチャの詳細解説: 今回は TPU と GKE におけるコールドスタート問題を深堀りし、Run:ai Model Streamer がどのようにその状況を変えられるかについて解説します。

お客様とパートナーに関する最新情報

お客様の成功事例: Pager Health は、GKE、BigQuery、Cloud SQL、Gemini Enterprise Agent Platform を活用して運用の断片化を解消し、人々の生活に大きな変化をもたらすシンプルかつパーソナライズされた医療体験を米国で展開しています。
お客様の成功事例: カスタマーレビュープラットフォームの Trustpilot は、A100 GPU 搭載のコスト最適化済み A2 VM 上で Dataflow と Gemini Enterprise Agent Platform を活用して、大規模なストリーミングパイプラインを構築しました。ファインチューニングされた Gemma モデルや、同プラットフォームが管理する最適化版 vLLM を採用しています。

2026 年 5 月

プロダクト、テクノロジー、ツールに関する最新情報

プロダクトの最新情報: GKE Agent Sandbox の一般提供が開始されました。
新しいオープンソースプロジェクト: Agent Substrate は、エージェントインフラストラクチャの密度を限界まで高めることを目指す、新しいオープンソースプロジェクトです。
新機能: Google AI Edge Portal は、オンデバイス ML を大規模にテストしてベンチマーク評価するためのソリューションです。このたび、オンデバイス LLM のベンチマークとデバッグに対応しました。詳しくはこちらをご覧ください。
プロダクトの詳細解説: AI ワークロード向けの新しい高性能ストレージサービスファミリーである Cloud Storage Rapid について詳しく説明しました。リリース時点でご利用いただけるサービスには、高パフォーマンスのゾーンオブジェクトストレージサービスである Rapid Bucket（旧称: Rapid Storage）と、オンデマンドで読み取りを高速化して既存バケットのワークロードのコンピューティングとデータをコロケーションする Rapid Cache（旧称: Anywhere Cache）が含まれます。

調査、レポート、詳細解説

アーキテクチャの詳細解説: Google グローバルインフラストラクチャ担当バイスプレジデントの Bikash Koley とエンジニアリングフェローの Arjun Singh が、AI ワークロードがネットワークインフラストラクチャにもたらす課題の概要を説明し、AI ワークロードをより適切にサポートするためにデータセンターファブリック、WAN、グローバルネットワークに施した大幅な機能強化をご紹介します。
アーキテクチャの詳細解説: TPU で最先端の AI モデルを開発するために、インスタンスレベルの信頼性モデルを廃止し、新しいクラスタレベルの信頼性モデルを公開しました。

お客様とパートナーに関する最新情報

お客様の成功事例: ビジュアルメディアプロバイダの Imgix は、NVIDIA RTX PRO 6000 Blackwell GPU 搭載の G4 VM を備えた AI Hypercomputer を活用して、80 億を超える画像や動画を配信しています。

- Google Cloud ブログ編集者、Alex Barrett

GKE CPU 起動ブースト: オーバープロビジョニングなしでアプリの起動を高速化

Fri, 16 Oct 2026 01:00:00 +0000

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

トラフィックの急増に対応してマイクロサービスを起動する場合でも、新しいソフトウェアリリースをデプロイする場合でも、アプリケーションレプリカをスケールアップする場合でも、Google Kubernetes Engine（GKE）で実行されるアプリケーションの高速で応答性の高いユーザーエクスペリエンスを維持するには、Pod の起動時間が重要です

しかし、プラットフォームエンジニアと開発者は、アプリケーションが起動時に定常状態の運用時よりも大幅に多くの CPU パワーを必要とすることが多いという、根強いジレンマに直面しています。通常の定常状態の使用量に合わせて CPU リクエストをサイジングすると、起動時に CPU スロットリングが発生し、コールドスタートの遅延や、readiness プローブのタイムアウトにつながる可能性があります。逆に、短時間の起動バーストに対応するためにベースライン CPU リクエストをオーバープロビジョニングすると、貴重なコンピューティングリソースが無駄になり、インフラストラクチャの費用が膨らみます。

このたび、GKE 向け CPU 起動ブーストのプレビュー版をリリースいたしました。GKE の VerticalPodAutoscaler（VPA）に直接統合された CPU 起動ブーストは、初期化中にコンテナの CPU 割り当てを動的に引き上げ、アプリケーションの準備が整うとシームレスにベースラインの定常状態レベルにスケールバックします。コンテナを再起動する必要はありません。

仕組み: Kubernetes のインプレース Pod サイズ変更

これまで、Pod のリソースリクエストや上限を変更するには、Pod を削除して再作成する必要がありました。このように影響の大きいプロセスは、コンテナの再起動、キャッシュの無効化、そしてノードの再スケジューリングによるオーバーヘッドを引き起こしていました。

これを解決するために、CPU 起動ブーストは Kubernetes のインプレース Pod サイズ変更（IPPR）を基盤としています。

KEP-1287 として管理されている IPPR は、動的なインプレースリソースミューテーションを導入しました。Kubernetes 1.27 でアルファ版として導入され、v1.33 でベータ版に昇格、v1.35 で一般提供（GA）となった IPPR を使用すると、Kubernetes コントロールプレーンと kubelet が、コンテナプロセスを再起動することなく、実行中の Pod のコンテナ CPU とメモリのリクエストを更新できます。

GKE は、VPA 内の IPPR を活用して、Pod のアドミッション時に起動時の CPU ブーストを適用し、準備完了後にスムーズに引き下げます。

CPU 起動ブーストの仕組み（Pod ライフサイクルの概要）

CPU 起動ブーストは、次の 3 つのフェーズで動作します。

アドミッションフェーズ: Pod をデプロイすると、VPA アドミッション Webhook が作成リクエストをインターセプトします。ポリシー（2 倍の乗数や +2 vCPU など）に基づいて引き上げられた CPU リクエストを計算し、追跡アノテーションとともに Pod 仕様に挿入します。
起動フェーズ: Pod がスケジュールされ、ブーストされた CPU 割り当てで初期化されます。アプリケーションは、CPU スロットリングを発生させることなく、クラスの読み込み、JIT コンパイル、モジュールの解析を最高速度で完了します。
ブースト解除フェーズ: Pod の readinessProbe が成功すると（さらに、構成された durationSeconds のクールダウン遅延が経過すると）、VPA アップデータはインプレースサイズ変更リクエストを発行します。コンテナは中断されることなく実行を続け、CPU リクエストはベースラインレベルに戻ります。

前提条件と提供状況

CPU 起動ブーストは、GKE でプレビュー版として提供されています。

GKE バージョン: Standard クラスタと Autopilot クラスタのバージョン 1.36.0-gke.4447000 以降。
クラスタモード: GKE Autopilot でネイティブに有効（VPA はデフォルトで有効）。GKE Standard では、垂直 Pod 自動スケーリング（VPA）が有効になっていることを確認するだけです。
ワークロードのサポート: Deployment や StatefulSet などの標準の Kubernetes コントローラと連携します。

スタートガイド: CPU 起動ブーストを構成する

CPU 起動ブーストの構成は、VerticalPodAutoscaler マニフェストに startupBoost セクションを追加するだけです。

例 1: 固定定常状態での Pod レベルのブースト（`updateMode: "Off"`）

定常状態の CPU リクエストをマニフェスト定義にロックしたまま、起動ブーストのみに VPA を使用する場合は、updateMode を "Off" に設定します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: "autoscaling.k8s.io/v1"\r\nkind: VerticalPodAutoscaler\r\nmetadata:\r\n name: java-app-startup-boost\r\n namespace: default\r\nspec:\r\n targetRef:\r\n apiVersion: "apps/v1"\r\n kind: Deployment\r\n name: java-app\r\n updatePolicy:\r\n updateMode: "Off"\r\n startupBoost:\r\n cpu:\r\n type: "Factor"\r\n factor: 2\r\n durationSeconds: 10'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1d419790>)])]>

この例では、GKE は起動時にコンテナの CPU リクエストを 2 倍にし、readiness プローブに合格してから 10 秒間、ブーストされた割り当てを維持した後、ベースラインにスケールバックします。

例 2: 起動ブーストと継続的な VPA 自動スケーリングの組み合わせ

GKE で起動時に CPU をブーストし、起動後に定常状態のリソースを継続的に最適化する場合は、updateMode を "InPlaceOrRecreate" に設定します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: "autoscaling.k8s.io/v1"\r\nkind: VerticalPodAutoscaler\r\nmetadata:\r\n name: nodejs-app-vpa\r\n namespace: default\r\nspec:\r\n targetRef:\r\n apiVersion: "apps/v1"\r\n kind: Deployment\r\n name: nodejs-service\r\n updatePolicy:\r\n updateMode: "InPlaceOrRecreate"\r\n startupBoost:\r\n cpu:\r\n type: "Factor"\r\n factor: 3\r\n durationSeconds: 15'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1d419c90>)])]>

例 3: コンテナレベルでのきめ細かいブースト

起動時に追加の CPU を必要としないサイドカー（ロギングエージェントやサービスメッシュプロキシなど）を実行する Pod の場合は、特定のアプリコンテナをターゲットにします。

code_block: <ListValue: [StructValue([('code', 'apiVersion: "autoscaling.k8s.io/v1"\r\nkind: VerticalPodAutoscaler\r\nmetadata:\r\n name: app-container-boost\r\nspec:\r\n targetRef:\r\n apiVersion: "apps/v1"\r\n kind: Deployment\r\n name: API-gateway\r\n updatePolicy:\r\n updateMode: "Off"\r\n resourcePolicy:\r\n containerPolicies:\r\n - containerName: "web-app"\r\n mode: "Off"\r\n startupBoost:\r\n cpu:\r\n type: "Quantity"\r\n quantity: "2"\r\n durationSeconds: 5'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1d41a6d0>)])]>

クラスタでの起動ブーストの確認

kubectl を使用して、GKE が起動ブーストを適用してダウンスケールしたことを確認できます。

1. Pod アノテーションを検査する: vpaCpuStartupBoost トラッキングアノテーションを確認します。

code_block: <ListValue: [StructValue([('code', 'kubectl get pod <POD_NAME> -o yaml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1d59f510>)])]>

元のベースラインとブーストされた CPU リクエストを示すアノテーションを探します。

2. インプレースサイズ変更イベントをモニタリングする: readiness の後、GKE が CPU リクエストをベースラインにスケールダウンしたことを確認します。

code_block: <ListValue: [StructValue([('code', 'kubectl get events --field-selector reason=InPlaceResizedByVPA'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1d2cea90>)])]>

reason=InPlaceResizedByVPA のイベントは、起動後のインプレースダウンスケーリングが成功したことを示しています。

本番環境ワークロードのベストプラクティス

HorizontalPodAutoscaler（HPA）との組み合わせ: CPU 起動ブーストと HPA を併用する場合は、堅牢な readinessProbe を定義し、durationSeconds を短く（例: 0 秒～10 秒）設定します。これにより、HPA が初期化時の CPU スパイクを定常状態の高負荷と誤って解釈するのを防ぎます。
GKE Capacity Buffers API でトラフィックの急増に対応: 大規模な起動オーバーヘッドを削減することで、より少ないノードでワークロードの密度を高め、全体的な使用率を向上させることができます。厳格な SLO を維持しながら、最小限の運用オーバーヘッドでトラフィックの急増を吸収するために、GKE Capacity Buffers API の導入を検討してください。
GKE Autopilot のリソース比率: GKE Autopilot では、Pod が有効な CPU とメモリの比率を維持する必要があります。起動時にブーストされた CPU 比率に対応できるよう、ベースラインのメモリ割り当てを確保します。

使ってみる

CPU 起動ブーストは、GKE ユーザーに両方のメリットをもたらします。Java、Node.js、Python などの CPU 負荷の高いワークロードのコールドスタートを高速化すると同時に、リソース効率を最大化してクラウド費用を削減します。

GKE ワークロードを高速化させるには、以下のリソースをご活用ください。

GKE CPU 起動ブーストのドキュメントを確認する。
GKE での垂直 Pod 自動スケーリングの詳細を確認する。
GKE 1.36.0-gke.4447000 以降を実行している GKE Standard クラスタまたは Autopilot クラスタで、CPU 起動ブーストをお試しください。

- Cloud デベロッパーアドボケイト、Abdel Sghiouar

- クラウドプロダクトマネージャー、Jakub Pawełczak

AI21、AI Hypercomputer の導入により AI ワークロードの起動時間を 83% 短縮

Wed, 14 Oct 2026 02:50:00 +0000

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

編集者注: AI21 Labs は、基盤モデル、特に Jamba ファミリーの構築で長年の実績を持つ世界有数の AI ラボであり、現在は特化型 LLM とエージェント最適化テクノロジーに注力しています。Google Cloud AI Hypercomputer の導入により、AI21 は優先度の高いジョブの待ち時間を 72 時間から 12 時間へと短縮し、手動によるスケジューリング介入を週 20 回からゼロへと削減しました。

AI21 は、企業が最先端の品質でエージェントを効率的に実行できるようにする基盤モデルとエージェント最適化プロダクトを構築しています。Jamba ファミリーを含む AI21 の言語モデルとエージェント最適化プロダクトスイートは、AI21 独自のワークロードをはじめとする、要求の厳しい本番環境ワークロードを稼働させています。そこで、これらを大規模なスケールで稼働させるために Google Cloud AI Hypercomputer を選択しました。

モデルトレーニングの稼働率を高く維持するには、インフラストラクチャ、オーケストレーション、使用量モデル全体で共同設計された、パフォーマンスとスケーラビリティに優れた環境が必要でした。モデルのトレーニングは、共有の Google Kubernetes Engine（GKE）クラスタの 1 つで実行され、数千の Google Cloud A3（NVIDIA H100 Tensor Core GPU 搭載）インスタンスと A3 Ultra（NVIDIA H200 Tensor Core GPU 搭載）インスタンスをプールしています。これにより、どのチームも、割り当てられた一部のキャパシティに制限されることなく、フリートの全キャパシティを活用できます。このクラスタは、Jamba ファミリー以外のモデルやエージェント最適化ワークロードのトレーニングにも使用されています。このアプローチによって使用率は高く維持されますが、その反面、スケジューリングは困難になります。

高使用率クラスタの行き詰まり

オーケストレーションに GKE を活用する前は、Slack で手動でキャパシティを調整していました。トレーニング実行のためのキャパシティが必要な場合は、#gpu-resources に投稿して、うまくいくことを祈るしかありませんでした。

クラスタに余裕があるときは、これで問題ありませんでした。使用率が 100% 近くに張り付くと、機能しなくなりました。これこそが、予約済みのコンピューティングフリートに求められる稼働状態であるにもかかわらず、です。

やがて、すべてのリクエストが交渉の対象となりました。チームリーダーは、コンピューティングリソースの割り当てを巡る争いの仲裁に時間を費やしていました。優先度の高いジョブ、つまりクラスタの半分以上を一度に必要とし、モデルプロジェクトのクリティカルパスとして機能する大規模なマルチノードトレーニング実行は、十分な連続した空きキャパシティが確保できるまで最大 72 時間ブロックされる可能性がありました。

図 1: #gpu-resources での典型的な 1 日。手動リクエスト、アドホックな調整、返信を待つ研究者。

リソースの不足は 2 つの異なる問題を生み出しましたが、それらを別々の問題として認識するまでには時間がかかりました。1 つ目は競合です。次にコンピューティングリソースにアクセスできるユーザーを決定する必要があり、これは交渉によって解決しました。2 つ目は断片化です。技術的には空きキャパシティがあるものの、大きなジョブで使用するには小さすぎる断片に分散している状態であり、これはいくら交渉しても解決できないビンパッキング問題でした。

図 2: GPU の断片化。4 つのノードに 1+1+4+2 として分散された 8 つの空き GPU では、8 GPU のワークロードを収めることができません。

理論上は十分な空きキャパシティがある場合でも、それが複数のマシンに分散していて、大きなジョブを実際に実行するにはチャンクが小さすぎることもありました。オールオアナッシングアドミッションがなければ、クラスタはデッドロックに陥り、誰かが手動で介入するまで、マシンは有用な作業を行わずにリソースを保持することになります。

現状がうまくいっていないことは明らかで、もっと良いものが必要でした。

適切なスケジューラの選択

当社では、Apache YuniKorn、Volcano、Kueue など、いくつかのオープンソースバッチスケジューラを検討しました。YuniKorn は、当社のすべてのユースケースをカバーしていませんでした。Volcano は機能が豊富でしたが、当社の環境に統合するには、Kubernetes スケジューラのコアコンポーネントを置き換える必要がありました。

シンプルさと統合のしやすさが、Kueue を採用する決め手となりました。標準の Kubernetes で動作し、コアコンポーネントを置き換える必要がなく、ジョブ仕様を書き直す必要もありませんでした。

Kueue と、GKE を通じた AI Hypercomputer の柔軟でオープンな運用を組み合わせたことも、成功に貢献しました。GKE を利用しているのは、コンピューティング負荷の高い AI ワークロードを適切に制御できるからです。GPU ハードウェアとドライバに直接アクセスできる一方で、生のインスタンスを自社で管理するオーバーヘッドは発生しません。Kueue は、Spot VM や Dynamic Workload Scheduler などの Google Cloud のキャパシティタイプを含め、GKE とネイティブに統合されているため、予約されたキャパシティが満杯になると、ジョブが滞ることなく、同じスケジューリングロジックが自動的に拡張可能なキャパシティにアクセスできます。

オープンソースとのフィードバックループの確立

Kueue の導入は、単なるプロセスの変更以上のものとなりました。Google Cloud と提携しているため、当社には専任のテクニカルアカウントマネージャーがついています。その担当者が、AI21 を Kueue チームのデザインパートナーに推薦する好機だと考えてくれました。そうすれば、単なるユーザーにとどまらず、本番環境における実際の要件を提供する存在として、ツールの今後の方向性を形作るのに貢献できます。

このパートナーシップから最初に生まれたものの一つが、Kueue チームと共有した要件ドキュメントです。このドキュメントには、まだ存在していなかった、必要とする動作が記載されていました。それは、通常は公平なスケジューリングに付随するプリエンプションを行うことなく、マルチノードジョブに対してチーム間で公平なアドミッション順序を実現することです。Kueue チームは、この機能を実際に開発してくれました。Admission Fair Sharing（AFS）は、すでに実行されているジョブを中断することなく、これまで使用したキャパシティが少ないチームを優先するようにアドミッションキューを並べ替えます。同じ頃、トポロジを考慮したスケジューリングも有効にしました。この既存の機能により、Kueue は物理クラスタのレイアウトを認識できるため、単一ノードに収まらないジョブを、実行する場所がないまま配置するのではなく、受け入れを拒否できます。

当社にとって、これはオープンソースのフィードバックループの最良の形です。本番環境での使用を通じて実際の要件が明らかになり、それが Kueue に直接フィードバックされます。

同じフリートで、よりスムーズに

Slack の #gpu-resources チャンネルはアーカイブされました。デバッグ pod、マルチノードトレーニング実行、推論デプロイなど、あらゆるワークロードがキューに登録され、優先順位が付けられ、自動的にスケジュールされます。効果はすぐに表れました。手動による介入は、週に約 20 回からゼロに減少しました。以前は最大 72 時間待機していた優先度の高いジョブの待ち時間が、今では 12 時間に短縮されました。クラスタ全体の断片化は 15% から 8% に減少し、「ゾンビジョブ」の問題（ワークロードが部分的に受け入れられ、実行する場所がない）は解消されました。

これによって総費用が変わることはありませんでした。当社では、予約済みフリートを意図的に 100% に近い稼働率で運用しているため、純粋な支出額そのものは、もともと最適化の対象ではありませんでした。変わったのは、従業員が何に時間を費やすかです。チームリーダーはコンピューティングに関する争いを仲裁する必要がなくなり、研究者は Slack での返信を待つ必要がなくなりました。これにより、誰もがより多くのテストを実施し、より迅速に反復処理を行えるようになります。

- AI21、テクノロジーおよびアーキテクチャ担当バイスプレジデント、Barak Peleg 氏

- AI21、DevOps エンジニア、Asaf Ben-Tovim 氏

GKE の弾力性がさらに向上: ゼロへのスケーリング、費用削減、ワークロードの応答性維持

Fri, 09 Oct 2026 02:00:00 +0000

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

真の弾力性は、クラウドネイティブエンジニアリングの究極の目標として長年追求されてきました。Kubernetes はリソース管理に革命をもたらしましたが、散発的に実行されるワークロード（バッチプロセッサ、イベントドリブンワーカー、開発環境など）は、処理を待機している間もコンピューティングリソースを消費するため、費用の増加を招きます。

Google Kubernetes Engine（GKE）1.37 では、ゼロへのスケールダウンとゼロからのスケールアップをネイティブに実現することで、この問題に正面から取り組んでいます。新しい一連の機能を使用すると、ワークロードを完全にゼロレプリカにスケールダウンして、リソースの消費を停止できます。同時に、需要が戻ったときには、GKE のキャパシティバッファでこれらのワークロードを迅速かつ簡単に再起動できるため、インフラストラクチャの無駄を減らすことができます。これは単に費用を削減するだけでなく、常時稼働のインフラストラクチャの費用をワークロードの準備状況から切り離すことにもつながります。

進化: HPA ベースのゼロへのスケーリングと KEDA

長年にわたり、Kubernetes Event-Driven Autoscaling（KEDA）というオプションの Kubernetes コンポーネントが、ゼロへのスケーリングの定番ソリューションでした。KEDA は強力ですが、環境が複雑になります。

機能	GKE のゼロへのスケーリング	KEDA ベースの設定
運用上のトイル	マネージドサービス。追加のコンポーネントは不要。	`ScaledObject` CRD とオペレーターの管理が必要。
構成	ネイティブなHPA と CRD（最小限の YAML）。	大規模なフリートでは、YAML が 10,000 行を超えることもあります。
レイテンシ	内部化された信号経路により、反応時間を短縮します。	ポーリング間隔とホップ数により、コールドスタートの遅延が増加します。

ゼロへのスケーリングを GKE コントロールプレーンに直接組み込むことで、アドオンオペレーターや数千行の構成が不要になります。ロジックは「サイドカー管理」からワークロードのネイティブ属性に移行します。

仕組み: AutoscalingMetric と KEP-2021 を使用した HPA

GKE 内でゼロにスケールする鍵は、2 つの重要なコンポーネントの統合にあります。

AutoscalingMetric を使用した HPA: これは、Google Cloud Managed Service for Prometheus からの外部シグナルの直接読み取りをサポートするマネージド指標シグナルパイプラインです。AutoscalingMetric を使用した HorizontalPodAutoscaler（HPA）は、Pub/Sub、Cloud Monitoring、ロードバランサのシグナルからオートスケーラーに指標を送信するための、統合された高パフォーマンスのパスを提供します。アダプターの煩雑さを伴わずに済みます。
KEP-2021: HPA で minReplicas: 0 を可能にする Kubernetes Enhancement Proposal

に基づいて構築されたこのメカニズムにより、指標がしきい値を下回ると、HPA はすべての Pod を停止できます。また、指標が保留中の作業を示したらすぐに、HPA が Deployment を「起動」できるようにします。

最初の「ゼロへのスケーリング」ワークロードの構成

ネイティブなゼロへのスケーリングを実装するには、指標定義と HPA という 2 つの主要なオブジェクトが必要です。次の例では、Pub/Sub サブスクリプションの未配信メッセージ数に基づいてワーカーをスケーリングします。

指標のソースを定義する

AutoscalingMetric CRD を使用して、外部の Cloud Monitoring 指標をクラスタにマッピングします。

code_block: <ListValue: [StructValue([('code', 'apiVersion: autoscaling.gke.io/v1beta1\r\nkind: AutoscalingMetric\r\nmetadata:\r\n name: my-autoscalingmetric\r\nspec:\r\n metrics:\r\n - promql:\r\n name: pubsub-undelivered\r\n query: >\r\n {\r\n "pubsub.googleapis.com/subscription/num_undelivered_messages",\r\n subscription_id="my-subscription"\r\n }'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1d3ef550>)])]>

minReplicas: 0 を使用して HPA を構成する

HPA で指標を参照し、最小レプリカ数を明示的にゼロに設定します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: autoscaling/v2\r\nkind: HorizontalPodAutoscaler\r\nmetadata:\r\n name: worker-hpa\r\nspec:\r\n scaleTargetRef:\r\n apiVersion: apps/v1\r\n kind: Deployment\r\n name: worker-deployment\r\n minReplicas: 0\r\n maxReplicas: 50\r\n metrics:\r\n - type: External\r\n pods:\r\n metric:\r\n name: autoscaling.gke.io|my-autoscalingmetric|pubsub-undelivered\r\n target:\r\n type: AverageValue\r\n averageValue: 10'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1d2d5890>)])]>

これで、外部指標に基づいてワークロードをゼロにスケールダウンしたり、ゼロからスケールアップしたりできるようになりました。

ゼロへのスケーリング機能は、Cloud Monitoring からの外部指標を GKE でサポートすることで実現しています。AutoscalingMetric カスタムリソースを拡張することで、複雑なサードパーティアダプタを使用せずに、Google Managed Service for Prometheus から指標をクエリできるようになりました。これにより、レイテンシが短縮され、セキュリティが簡素化されます。また、ネイティブな「ゼロへのスケーリング」ワークロードを構成するための重要な基盤となります。このインテグレーションについて詳しくは、GKE での外部指標のネイティブサポートに関するブログ投稿をご覧ください。

キャパシティバッファによる起動レイテンシの管理

ゼロからのスケーリングにおける最大の課題は、いわゆるコールドスタートです。これは、GKE がノードをプロビジョニングし、コンテナがそれを pull して起動するまでにかかる時間です。そこで役立つのが GKE キャパシティバッファです。

キャパシティバッファは、プールされたウォーム状態のキャパシティとして機能します。GKE は、ゼロにスケールできる複数のワークロードで共有できる少量のウォームコンピューティングリソースを維持することで、HPA が 0 から 1 にジャンプしたときに、Pod がすぐに要求できるリソースを確保します。これにより、新しい GKE ノードがスピンアップするまでの 60～90 秒の待ち時間がなくなり、起動レイテンシが数分から瞬時に短縮されます。その間、ワークロードの費用はゼロに抑えられます。

キャパシティバッファには、アクティブとスタンバイの 2 種類があります。小さなアクティブバッファは、ゼロにスケールされた数百のワークロードに対応できます。各ワークロードがレプリカを維持するのではなく、アクティブバッファがクラスタ全体にサービスを提供するワイルドカードキャパシティとして機能します。スタンバイバッファはアクティブバッファに比べて大幅に低コストで、サイズが大きくなるため、クラスタで持続的な負荷が発生した場合にアクティブバッファを迅速に補充できます。これらを併用することで、即時のスケーリングを実現しながら、低コストも維持できます。

今後について

Google は、GKE の弾力性に関するロードマップを継続的に拡大しています。たとえば、開発環境を午後 8 時にゼロにスケールダウンし、午前 7 時にスケールアップするとします。繰り返し発生するスケーリングをより細かく制御する方法に注目し、ゼロへのスケーリングの時間枠を事前に定義できるようにしましょう。

ゼロへのスケーリングを今すぐ始めましょう

アイドル状態のリソースに料金を支払う時代は終わりを迎えようとしています。イベントドリブンなワークロードや散発的なワークロードに対して GKE のネイティブなゼロへのスケール機能を有効にすることで、起動パフォーマンスを犠牲にすることなく費用を削減できます。ゼロへのスケールを開始するには、次の手順を行います。

アイドル期間を伴う、需要が変動するワークロードを特定します。
AutoscalingMetric を構成し、minReplicas をゼロに設定します。
クラスタまたはワークロードにキャパシティバッファを追加して、応答時間を短縮します。

詳細は、HPA を使用した GKE ワークロードのゼロへのスケールダウンとゼロからのスケールアップに関するドキュメントをご覧ください。

- Google Kubernetes Engine、プロダクトマネージャー、Eyal Yablonka

- Google Kubernetes Engine、シニアソフトウェアエンジニア、Scott Funkenhauser

45 倍高速な GKE Agent Sandbox でエージェント型 RL と評価研究を加速

Fri, 09 Oct 2026 01:00:00 +0000

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

最先端の AI ラボが大規模な並列ロールアウトでエージェント型強化学習（RL）と評価をスケールアップしようとすると、必然的にボトルネックに直面します。高価な GPU クラスタがアイドル状態になり、CPU サンドボックスのコールドスタートに数分かかるうえ、数千件に及ぶ数ギガバイト規模の SWE-bench スタイルのイメージの pull とスケジューリングのバックログが発生するのです。これは、研究を知らぬ間に遅らせ、トレーニング予算を浪費してしまう、サンドボックスインフラストラクチャの問題です。

この根本的なインフラストラクチャのボトルネックを解決するため、Google はこのたび、RL 向けに最適化された GKE Agent Sandbox と Agent Sandbox RL オーケストレーション SDK、そして一般的な RL ジムやハーネスとのネイティブ連携の一般提供を開始いたしました。

最新 AI のためのオペレーティングシステムとして、Kubernetes は大規模な GPU / TPU トレーニングクラスタと分散推論を強化するよう進化してきました。現在、Kubernetes は、AI コンピューティングの次のフロンティアである「エージェント」を牽引しようとしています。ただし、静的なワークロードとは異なり、エージェント型ワークロードは急速に進化するため、インフラストラクチャも同じ速度で進化しなければなりません。そこで、Google は RL 研究者が何を必要としているかを推測するのではなく、Kubernetes 自体をパフォーマンスベンチマークと評価に基づく自動研究および検証ループに組み込みました。また、SWE-bench のような負荷の高いエージェント型ベンチマークを使用して、意図的に自社のクラスタに過酷な負荷をかけてダウンさせるストレステストを実施しました。etcd のタイムアウトから GPU のアイドル時間の急増まで、表面化したすべてのボトルネックを開発サイクルにフィードバックし、GKE の基本的な構成要素を改良しました。

その結果、以下のような特徴を備えた、エージェント型 RL と評価ワークロードに特化したサンドボックスレイヤが構築されました。

最初のコマンド実行までの時間を 10～45 倍高速化: GKE は、サンドボックス環境を 45～85 秒ではなく 1～9 秒でスピンアップできるため、高価な GPU を常にフル稼働させることができます。
テールレイテンシを短縮: サンドボックスの最悪の場合の待ち時間を 7.5 分から 10 秒未満に短縮しました。
コントロールプレーンのチャーンを 3 分の 1 に削減: RL のトレーニングステップごとに大量のロールアウトが一斉にトリガーされ、数千ものサンドボックスが一度にリクエストされます。SDK では、Pod を削除して再作成するのではなく、ロールアウト間で再利用するインプレースリサイクル戦略が採用されています。これにより、作成される Pod の数が 3 分の 1 に減り、チャーンが発生しても、安定した Kubernetes API サーバーを維持できます。

この新しいプリミティブにより、AI ラボやエージェントネイティブのスタートアップは、大規模なエージェント型 RL のトラジェクトリと評価を同時かつ確実に実行できるようになり、アクセラレータのアイドル時間を最小限に抑え、研究のスピードを大幅に加速させることができます。

現実世界におけるエージェント型 RL インフラストラクチャの課題

ソリューションについて説明する前にまず、エージェント型 RL がインフラストラクチャに大きな負担をかける理由を正確に把握しておきましょう。標準的なエージェント型 RL ループでは、LLM ポリシーが GPU 上でコードスニペットなどのアクションを生成し、隔離された CPU サンドボックス内で実行して報酬シグナルを観察します。しかし、このループをスケールアップして数万件の並列ロールアウトをサポートしようとすると、以下の 3 つの重大なインフラストラクチャのボトルネックが発生します。

アクセラレータのアイドルコスト、すなわち最初のコマンド実行までの時間（TTFC）とテールレイテンシの罠: エージェント型 RL はバッチワークロードです。同期型の RL ステップでは、バッチ内で最も処理の遅いサンドボックスの準備が整うまでトレーニングを進めることができません。CPU サンドボックスを起動する際、プロビジョニング、イメージの pull、初期起動スクリプトの実行に数分かかれば、高価なアクセラレータの容量が無駄になってしまいます。
膨大なイメージカーディナリティ: 標準的なコンテナのキャッシュ保存は、少数の静的なベースイメージを前提としています。しかし、エージェント型 RL では、一つひとつのタスク（SWE-bench や R2E-Gym にある数千の GitHub リポジトリなど）に、完全に異なる OCI コンテナイメージが必要となることが少なくありません。実行ごとに数千もの一意の大型イメージを管理すると、イメージの pull における深刻なボトルネックや、ストレージフリクションが生じる可能性があります。
コントロールプレーンの飽和: バースト性の高いバッチワークロードであるエージェント型 RL は通常、バッチサイズのイメージタスクと、タスクごとに複数のロールアウト（タスクごとに 4、8、16 回のロールアウトなど）を実行するため、すでに大量にあるイメージ数が極限まで増加してしまいます。たとえば、テストに使用した一般公開データセットの一つには、4,578 件の R2E イメージが含まれています。イメージごとにロールアウトを 4 回行うと仮定すると、18,312 個のタスクが発生し、18,312 個のサンドボックスが同時に必要となります。標準の Kubernetes コントロールプレーンは、このようなバースト負荷が生じるとパフォーマンスが大幅に低下します。1 分間に数万ものエフェメラル Pod の作成と削除を頻繁に繰り返すと、API サーバーのキューのボトルネックや Pod の状態エラーが発生し、ノード障害の誤判定によるエビクションがトリガーされます。

これらは机上の空論ではありません。最新のエージェントをトレーニングする最先端の AI ラボにとって、これらは日常的な現実なのです。

RL 向けに最適化された GKE Agent Sandbox

コード実行サンドボックスをファンアウトするため、Google は比較的小規模なクラスタを構築しました。このクラスタは、GKE イメージストリーミングが有効な 10 ノードの gVisor サンドボックスプール、Agent Sandbox コントローラ、ウォーム Pod を要求するクラスタ内 SDK ドライバで構成されています。そこでは、多数のイメージや高いカーディナリティなど、さまざまな戦略や設定をテストしました。

インフラストラクチャレイヤ

GKE Agent Sandbox は、エージェントをセキュアに実行するためのオープンな Kubernetes プリミティブです。事前に初期化された正常な環境を維持することで、コールドスタートのオーバーヘッドを排除する、組み込みの SandboxWarmPool 機能を備えています。SandboxWarmPool を GKE Image Streaming と連携させることにより、数千もの大規模なイメージ（1.2 GB 超）を使用する場合でも、高いイメージカーディナリティを必要とする RL ワークロードと評価ワークロードを効果的にサポートすると同時に、応答性の高いエージェント型トレーニングに必要な非常に低い TTFC を実現します。そのスナップショット、一時停止、再開機能により、エラー回復のためのチェックポイント設定や、複数のトレイルを探索するエージェントの並列分岐ロジックのサンドボックスフォークをサポートします。

この GKE プリミティブは、最先端の AI ラボである Mistral AI のエージェント型 RL トレーニングインフラストラクチャですでに活用されています。

「強化学習の限界を押し広げるには、予測不可能な需要に対応できるよう即座にスケールできるインフラストラクチャが必要です。RL 向けの高性能な GKE Agent Sandbox を活用することにより、クラスタ全体で数十万ものセキュアな環境をシームレスにオーケストレートし、単一のクラスタ上で 3 万を超えるサンドボックスの急増にも対応できるようになりました。このサンドボックスは、モデルのトレーニングとイテレーションのサイクルを加速させるために必要な、信頼性の高い基盤を提供してくれます。」- Mistral AI、リサーチエンジニア、Jean-Malo Delignon 氏

オーケストレーション SDK と RL ツールの連携

研究者が Kubernetes YAML を記述したり、カスタムデーモンをコンテナイメージに埋め込んだりしなくてもこの機能を活用できるよう、Google は Agent Sandbox RL オーケストレーション SDK を構築しました。この SDK は、特定の評価や RL トレーニングパターンに合わせて調整された、差し替え可能なウォームプーリング戦略を備えた、シンプルで非同期な Python API を提供します。また、Gymnasium、NVIDIA NeMo Gym、OpenHands などの RL ツールとのネイティブ連携も構築しており、今後さらに追加される予定です。

ベンチマーク: アイドル状態のアクセラレータのロスを削減

このベンチマークは、10 ノードの gVisor サンドボックスプール上で 2 つのワークロードに対して実施しました。1 つは 500 イメージの SWE-bench 環境、もう 1 つはローカルディスクに収まらない 4,578 イメージから成る、より負荷の高い R2E コーパスです。

1. TTFC とテールレイテンシ: 10～45 倍高速化

主要な指標	重要である理由	標準の K8s Pod ベースライン	GKE Agent Sandbox SDK	ベンチマークの向上
TTFC、平均	GPU のアイドル時間を左右する	44～85 秒（平均）	1.1～8.8 秒（平均）	10 倍高速
テールレイテンシ - 最大 TTFC（最悪のケース）	バッチのボトルネックになる	7.5 分（450 秒）	10 秒未満	45 倍高速

同時実行数は、500 のタスクとサンドボックスから、最大 18,312（4,578 件の R2E イメージ × 4 回のロールアウト）に及びました。このパフォーマンス向上は、すべての設定で一貫して確認されました。

これまでの流れ: コントローラ、SDK、RL フリートに計測機能を組み込み、固定された 10 ノードを上限として数百回の比較実行を行いました。その成果のほぼすべては、以下の 2 つの変更によりもたらされました。

イメージのハイドレーションをクリティカルパスから除外。カーディナリティの高いコーパスはローカルディスクの容量をはるかに超えるため、トレーニング中にコールドイメージを pull すると、I/O の競合や数分に及ぶテールレイテンシが発生します。SDK がノード全体にわたるイメージの配置を計画し、 GKE イメージストリーミングと事前のウォームプーリングが残りの処理を行います。これにより、ロールアウトが要求する前にハイドレーションが完了します。
コントロールプレーンのペースを調整。同時実行数の多いロールアウトは、API サーバーのサンダリングハードをトリガーします。Agent Sandbox Controller v1.0.0 では、ウォームプールの補充速度を制限するレート制御が追加され、バースト中も etcd と API サーバーの安定性が維持されます。

これらの数値の根拠となる調整項目、ベンチマーク実行基盤、負荷テストはすべて、agent-sandbox-rl の例に含まれています。この例では、人が読める形式のレポートと JSON レポートが出力されるため、ご自身のクラスタで比較を再現できます。

2. マルチトラジェクトリロールアウト中のコントロールプレーンと Pod のライフサイクルチャーンが 3 分の 1 に減少

主要な指標	重要である理由	標準の K8s Pod ベースライン	GKE Agent Sandbox SDK	ベンチマークの向上
コントロールプレーンのチャーン（4,578 イメージ × 4 回のロールアウト実行）	コントロールプレーンが飽和	18,312	5,869	チャーンが 3.1 分の 1 に減少

標準の Kubernetes では、トラジェクトリのステップごとに Pod が再作成されます。タスクが 18,312 個ともなると、スケジューリングのオーバーヘッドが増大し、ディスク I/O が無駄になるだけでなく、大規模なテストでは、無限のガベージコレクションループがトリガーされました。SDK のインプレース recycle 戦略では、Pod を存続させ、ロールアウトエピソード間で Pod 内の git reset とリポジトリチェックアウトを実行します。Pod の作成は 3.1 分の 1 に減少し、コントロールプレーンはバースト中も安定しています。

トレードオフ

事前に環境をウォームアップしておくと、安価な CPU とバックグラウンドのクラスタ処理時間を消費することにはなりますが、イメージストリーミングとレディネスチェックがクリティカルパスに影響することがなくなります。RL フリートにとって、これは単純なトレードオフです。アクセラレータのアイドル時間という高価なリソースを、このアプローチにより排除できます。

大規模なトレーニングでは、ある 1 つの細かな点が重要になります。SDK は、失敗したサンドボックスをすべてカウントし、黙って破棄するのではなく、再試行可能なエラーとして返します。追跡されない破棄は、単にロールアウトが失われるだけでなく、報酬バイアスを引き起こします。

ご利用開始

今すぐ構築する: Agent Sandbox リポジトリまたは Agent Sandbox RL リポジトリを参照し、Python SDK や、Gymnasium、NVIDIA NeMo Gym、OpenHands などの RL ツール向けネイティブ連携をご確認ください。
アクセラレータの使用率をさらに高める: llm-d 協調型タイムスライスリポジトリとスナップショットエージェントガイドを参照し、独立した RL ジョブを共有の物理ハードウェア上で動的にインターリーブする方法をご確認ください。
詳細を確認する: GKE Agent Sandbox を使用してセキュアな実行環境をデプロイする方法については、公式ドキュメントをご覧ください。

- プロダクトマネージャー、Tinsley Shi

- スタッフソフトウェアエンジニア、テクニカルリード、Tomer Glottmann

マルチクラスタ GKE Inference Gateway で 1% 未満のオーバーヘッドでグローバル AI ルーティングを実現

Fri, 09 Oct 2026 00:00:00 +0000

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

AI インフラストラクチャの需要はかつてないほど高まっています。世界的なアクセラレータ不足により、エンジニアリングチームが 1 つのデータセンターだけで必要なコンピューティング容量をすべて確保できることはほとんどありません。容量はあちこちのクラスタから、それも多くの場合、海を隔てた場所から確保されます。同時に、ワークロードはより多くの容量を必要とするようになっています。昨今の長時間実行されるエージェントワークロードは、10 万～80 万以上のトークンのコンテキストウィンドウを持つことが多く、前の世代の AI トラフィックよりもはるかに速いペースでアクセラレータメモリを消費します。

このような環境では、「1 ドルあたりのインテリジェンス」を最大化することが目標となります。しかし、断片化され、適切に負荷分散されていないインフラストラクチャでは、この要求に応えることは困難です。高価なアクセラレータがアイドル状態のまま放置される一方で、別の場所ではリクエストが処理待ちのキューに滞留してしまう、といった事態を招きかねません。

このギャップを埋めるために、Google は、世界中に分散した容量を単一のエントリポイントの背後にある単一のプールのように動作させる、階層型ルーティングアーキテクチャを構築しました。エッジでは、マルチクラスタ GKE Inference Gateway が、グローバルなマルチリージョントラフィック分配と高可用性を担います。その下では、LLM-d ルーターが、使用率を高く維持する複雑なメモリ認識型スケジューリングアルゴリズムを処理します。

このアーキテクチャは、ランタイム、モデル、アクセラレータに依存しないように設計されており、サービングフレームワーク、モデルファミリー、GPU または TPU ハードウェアを問わず機能します。単なる抽象論ではなく、具体的な成果を示すために、Google は最近、米国と欧州に分散した 17,000 のコンピューティングノードで構成されるマルチリージョン GKE デプロイ全体において、本番環境レベルのグローバルなリクエストルーティングを大規模に処理する際のベンチマーク評価を実施しました。このデプロイでは、SGLang を使用して、主要な Mixture of Experts（MoE）基盤モデルをサービングしました。

結果: 3 つのクラスタにスケールすることで、多数のクライアントが同時にアクセスする高負荷な状況でも、99.9% の成功率を維持しつつ、ほぼ線形のスループット向上を達成しました。さらに、マルチクラスタ GKE Inference Gateway を介してトラフィックをルーティングすると、オーバーヘッドが 1% 未満に抑えられ、直接的なローカルクラスタ呼び出しのスループットの 99.5% を実現しました。

その仕組み、ベンチマークの結果の詳細、分散推論デプロイにおける意義について、以下で詳しく説明します。

3 つのリージョン、1 つのエンドポイント

デプロイは、us-east5（構成クラスタ）、us-west8、europe-west4 の 3 つの地理的リージョンにある 3 つの GKE クラスタにまたがっていました。しかし、クライアントの観点からは、そのような地理的な要素は存在しません。リクエストは単一のグローバル仮想 IP に到達し、ゲートウェイがリアルタイムで、各リクエストをどのクラスタで処理するかを決定します。

その決定を盲目的なものではなく、スマートなものにするのがテレメトリーです。ネットワーク層における従来のラウンドロビンルーティングに代わり、マルチクラスタロードバランサは、アプリケーションのリアルタイムのシグナルに基づいてトラフィックをルーティングするように構成されています。具体的には、Endpoint Picker Proxy（EPP）が、基盤となる推論エンジンによってネイティブに公開される KV キャッシュトークン使用率を読み取り、ロードバランサの指標として出力します。ロードバランサは、この出力された指標に基づいてリージョンが過負荷状態になっていることを確認すると、トラフィックを次の正常なリージョンに転送します。

マルチクラスタ GKE Inference Gateway トポロジ。構成クラスタはルーティング構成を保持しますが、リクエストパスの外側に配置されています。各ターゲットクラスタは独自の EPP を実行し、KV キャッシュの使用率をロードバランサに報告します。

これがトレードオフのすべてです。グローバルロードバランシングのすべてのメリットを、実質的に無料で利用できます。

リージョン間の線形スケーリング

さらに大きな試練は、スケーリングです。テストでは、すべてのクライアントリクエストを単一のリージョン（us-east5）から送信しつつ、フリートを 1 つのクラスタから米国と欧州にまたがる 3 つのクラスタへと拡大しました。これにより、Gateway には大きな負荷がかかることになります。これほど離れた距離間で負荷を効率的に分散できなければ、ハードウェアを追加してもスループットは横ばいになってしまいます。

代わりに、スループットは容量とほぼ完全に比例して増加しました。

フリートトポロジ	リクエストのスループット	トークンのスループット	成功率
1 クラスタ（us-east5-a）	0.72 リクエスト/秒	2,898 トークン/秒	99.87%
2 クラスタ（+ us-west8-a）	1.40 リクエスト/秒	6,380 トークン/秒	99.95%
3 クラスタ（+ europe-west4- b）	2.10 リクエスト/秒	8,457 トークン/秒	99.90%

That’s the whole trade-off. All the benefits of global load balancing, essentially for free.

Linear scaling across regions

A bigger test is scale. In our test, growing the fleet from one cluster to three, spanning the US and Europe, while every client request originated from a single region (us-east5), put real pressure on the Gateway: If it couldn’t distribute load efficiently across those distances, throughput would flatten as hardware was added.

Instead, throughput multiplied almost exactly in line with capacity:

Fleet topology	Request throughput	Token throughput	Success rate
1 cluster (us-east5-a)	0.72 req/s	2,898 tok/s	99.87%
2 clusters (+ us-west8-a)	1.40 req/s	6,380 tok/s	99.95%
3 clusters (+ europe-west4- b)	2.10 req/s	8,457 tok/s	99.90%

3 つのクラスタにスケールすることで、多数のクライアントが同時にアクセスする高負荷な状況でも、99.9% の成功率を維持しつつ、ほぼ線形のスループット向上を達成しました。

メモリを考慮したルーティングの動作

ラウンドロビンロードバランシングは、すべてのリクエストを均等に扱うため、LLM のサービングには適しません。まったくもって、不向きです。重いプロンプトは GPU コンピューティングコアを飽和させ、長文の生成はメモリ帯域幅を圧迫し、コンテキストの長い会話は VRAM を静かに消費し続け、最終的にエンジンが新しいリクエストをスケジュールできなくなってしまいます。

ここでは、メモリ帯域幅への負荷は、このデプロイで採用されたルーティングシグナルに起因していました。Inference Engine ネイティブのトークン使用量指標を Gateway の KV キャッシュシグナルにマッピングすることで、ルーティングプレーンは 17,000 におよぶフリート全体のメモリ負荷をリアルタイムに把握できるようになりました。（ワークロードに応じて、キューの深さや実行中の同時実行数など、他のシグナルに基づいてルーティングすることもできます）。

本実際の運用負荷がかかる中、プライマリリージョンが高帯域幅メモリ（HBM）の上限に近づくと、Gateway はクラスタの KV キャッシュ使用率がしきい値である 40% を超えた瞬間に飽和状態を検出し、即座に、オーバーフローを次の正常なリージョンへと自動的にルーティングし始めました。オペレーターの介入は必要ありませんでした。複数リージョンでの運用に伴う複雑さを、ユーザーが意識する必要はまったくありませんでした。

価値の提供

この GKE Inference Gateway の構成は、リアルタイムの KV キャッシュ使用率に基づいてトラフィックをルーティングすることにより、世界中に分散したコンピューティング容量を 1 つの統合エンジンに効果的にプールします。このデプロイでは、3 つのグローバルリージョンでほぼ線形のスループット向上が実現し、ルーティングのオーバーヘッドは実質的にゼロでした。

これは、資本を無駄にすることなく、フリートに追加するすべてのアクセラレータからほぼ完璧に比例するパフォーマンスを引き出し、「1 ドルあたりのインテリジェンス」を最大化することに直結します。

チームへの影響

独自の分散推論デプロイを計画している場合、この取り組みから得られた 5 つの教訓が参考になります。

よりスマートなロードバランシングは、それ自体が価値を生み出します。ラウンドロビンルーティングでは、メモリやコンピューティングの負荷を把握できないため、高価な GPU 容量を無駄にしてしまいます。リアルタイムのアプリケーションシグナルに基づくルーティングにより、断片化されたリージョンクラスタが 1 つの効率的なフリートに統合されます。これにより、ハードウェアが遊休状態になるのを防ぎ、希少なコンピューティングリソースの利用率を 90%以上に高めることができます。
エージェントワークロードがボトルネックを変化させます。極めて大きなコンテキストウィンドウを持つ長時間実行型のエージェントは、コンピューティングリソースが限界に達するずっと前にメモリを使い果たしてしまいます。ルーティングレイヤがメモリ負荷を認識できない場合、VRAM が満杯になったノードの陰に、まだ余裕のあるコンピューティング容量が取り残されてしまいます。KV キャッシュの使用率を最優先のルーティングシグナルにします。
AI トラフィックがウェブ時代の前提を覆します。従来のロードバランサは 1 秒未満のトランザクション向けにチューニングされていますが、LLM リクエストは数分間実行されることがあります。AI 規模のレイテンシを考慮して、接続上限とタイムアウトを早期に計画してください。そうしないと、本番環境で接続が中断される可能性があります。
ルーティングレイヤは、ネイティブのサービングパターンと統合する必要があります。分散 LLM エンジンには、特定の Pod のみがトラフィックを処理できるマスターワーカートポロジがあります。Gateway を LeaderWorkerSet（LWS）などのネイティブな Kubernetes 構造と組み合わせることで、グローバルルーティングはローカル Pod トポロジをそのまま考慮した制御を行い、チームがカスタムプロキシインフラストラクチャを構築する必要がなくなります。
大規模な基盤モデルの構築には、オープンでポータブルなスタックが最適です。業界最先端の規模で運用しているチームは、容量の断片化という最も深刻な課題に直面しています。そのため、空き容量があるリージョンならどこであっても、コンピューティングリソースを探し回ることを余儀なくされています。GKE 上の LLM-d のようなオープンでポータブルな推論スタックを使用すると、単一のクラスタ、リージョン、または独自のインフラストラクチャにサービングアーキテクチャを固定することなく、空き容量がどこにあっても吸収できます。

次のステップ

分散アクセラレータの効率を最大化し、マルチクラスタ GKE Inference Gateway でグローバルなクロスリージョンロードバランシングを設定する準備はできましたか？

自分でデプロイする: マルチクラスタ GKE Inference Gateway を設定する。
アーキテクチャを理解する: マルチクラスタ GKE Inference Gateway について。
この投稿で紹介したクロスリージョンスピルオーバーの動作については、弾力性のあるクロスリージョン高可用性についてと弾力性のあるクロスリージョン高可用性を構成するをご覧ください。

- Google Kubernetes Engine、プロダクトマネージャー、Fisayo Feyisetan

- Google Kubernetes Engine、ソフトウェアエンジニア、Sina Chavoshi

Google、2026 年 Gartner Magic Quadrant でコンテナ管理部門のリーダーに選出

Mon, 05 Oct 2026 01:00:00 +0000

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

Gartner は 2026 年の Gartner® Magic Quadrant™ で、「ビジョンの完全性と実行能力」に基づき、Google を 4 年連続でコンテナ管理のリーダーとして認定しました。Google は、評価対象となった全ベンダーの中で実行能力において最も高い評価を得ています。これは、パフォーマンスと効率の両面で高度に最適化されたコンテナプラットフォームを提供するという Google のミッションの成功を証明するものと考えています。Google は、次世代の AI アプリケーションやエージェントアプリケーションなど、特に要求が厳しく複雑なワークロードを大規模に構築、実行できるよう、世界中のお客様を支援しています。

Magic Quadrant に付随する 2026 Gartner Critical Capabilities for Container Management レポート（2026 年の Gartner のコンテナ管理の重要機能に関するレポート）によると、Google Cloud は、すべてのユースケース（新しいクラウドネイティブなアプリケーション、コンテナ化された既存のアプリケーション、AI トレーニング、AI 推論、エッジアプリケーション、ハイブリッドアプリケーション）において第 1 位にランクインしました。

Gartner は、「Kubernetes を使用する新規の AI デプロイは、2025 年には 30% 未満だったが、2028 年までに 95% になる」と予測しています1。コンテナは昨今の特に革新的なアプリやビジネスを推進し、エージェントの時代にビジネスを変革するお客様が求めるインフラストラクチャを提供します。

Google Cloud は、2014 年に Kubernetes を導入し、2015 年に世界初のマネージド Kubernetes サービスである Google Kubernetes Engine（GKE）をリリースしたことで、業界全体のクラウドネイティブ革命を主導しました。それ以来、コンテナプラットフォームと、活気に満ちた革新的な Kubernetes エコシステムに対する Google の取り組みは、さらに強化され、深まっています。GKE とともに、Google のサーバーレスコンテナプラットフォームである GKE Autopilot と Cloud Run により、運用コストが大幅に削減され、デベロッパーは優れたコンテナ化アプリをこれまで以上に迅速に提供できるようになります。

エンタープライズ AI の急速な普及を受け、Google は AI 時代に向けてインフラストラクチャ管理を再定義しました。2026 年、Google はこれまでに、GKE と Cloud Run を、自律型 AI システム、大規模な推論ワークロード、セキュアなランタイム分離向けに設計された、エージェントネイティブな高性能プラットフォームに移行するために、幅広い基盤の改善を導入しています。最先端の AI トレーニング、AI スタートアップの立ち上げ、企業の AI 変革の主導など、あらゆるニーズに対応するコンテナプラットフォームをご用意しています。重要なポイントは次のとおりです。

AI インフラストラクチャで優れたパフォーマンスと効率を実現

GKE 予測レイテンシブースト: GKE Inference Gateway に組み込まれたこの ML 駆動型機能は、静的な構成ではなく容量認識ルーティングを使用して、最初のトークンまでの時間（TTFT）を最大 70% 短縮します。
GKE の自動 KV キャッシュストレージ階層化: KV キャッシュデータを RAM、ローカル SSD、Cloud Storage 間で自動的に移動します。これにより、メモリのボトルネックが軽減され、RAM へのオフロードによって TTFT が 40% 短縮され、大規模なプロンプトコンテキストではローカル SSD によってスループットが 70% 向上します。[1]
GKE によるコンテナとモデルの起動の高速化: GKE ノードのスピンアップ時間が最短で 4 分の 1 に短縮され、Pod の起動速度が最大 80% 向上しました。さらに、ネイティブの Run:ai Model Streamer のインテグレーションにより、重いモデルを Cloud Storage から 5 倍速く pull できます。
Cloud Run のオンデマンドサーバーレス GPU のゼロへのスケーリング: Cloud Run は NVIDIA RTX PRO 6000 Blackwell GPU をサポートしているため、チームは 700 億以上のパラメータがあるモデルをオンデマンドでサービングできます。サービスは、ゼロの状態から、完全にプロビジョニングされた GPU（すべてのドライバがプリインストール済み）に 5 秒未満で移行できます。アクティブな推論やファインチューニングの実行が完了すると、Cloud Run はインスタンスを自動的にゼロの状態にスケールダウンし、アイドル状態のインフラストラクチャ費用を排除します。

エージェントインフラストラクチャのセキュリティとスケールに対応する Kubernetes の進化

GKE Agent Substrate: オープンソースでセキュアバイデフォルトのエージェント実行ランタイムである Agent Substrate は、標準的なコンテナランタイムよりも 10 倍高い密度で数百万のサンドボックスを実行できるように設計されています。自律型エージェントの時代に向けて専用設計された Substrate は、ネイティブのゼロトラストカーネルとネットワーク分離により、1 秒あたり 500 回を超える一時停止 / 再開アクティベーションを実行しながら、500 ミリ秒未満での再開オペレーションを実現します。Agent Substrate は、あらゆる Kubernetes インフラストラクチャで動作し、GKE 向けに最適化されたオープンソースソリューションとして提供されます。
GKE Agent Sandbox: gVisor カーネル分離テクノロジーを基盤とする Agent Sandbox は、信頼できないマルチエージェント AI のコード実行からホスト環境を分離します。セキュアな実行を大規模に実現し、1 秒未満のレイテンシで 1 秒あたり最大 300 個のサンドボックスを処理します。また、Axion プロセッサで実行した場合、同等のハイパースケーラークラウドプロバイダと比較して最大 30% 優れたコストパフォーマンスを実現します。
GKE Dataplane V2 のスケーラビリティの上限: アクティブな NetworkPolicy を実装する GKE クラスタのアーキテクチャ上の容量上限が、クラスタあたり 7,500 ノードから 15,000 ノードに倍増し、大企業や AI を活用するお客様の膨大なインフラストラクチャニーズに対応します。
GKE のインテントベースの自動スケーリング: GKE は、基本的なハードウェア指標だけでなく、アプリケーションインテントとカスタム指標を使用して、ネイティブに水平自動スケーリングできるようになりました。これにより、リソース割り当ての反応時間が 25 秒からわずか 5 秒に短縮されます。
Filestore エージェントボリューム: NFS マウントをミリ秒単位でアタッチ / デタッチする新しいサービス。エージェントをほぼ瞬時に開始 / 再開できるほか、ネイティブの Read-Write-Many（RWX）アクセスと POSIX 準拠のファイルロックにより、書き込みの競合を発生させることなく、安全なマルチエージェントコラボレーションを実現します。

サーバーレスコンテナによる次世代のデベロッパーエクスペリエンス

Cloud Run は、標準的なウェブ API のホスティング、負荷の高いバッチデータジョブの実行、非同期メッセージキューの処理、複雑な AI エージェントのデプロイなどをすべて、比類のないデベロッパーエクスペリエンスと最大限のエンジニアリング速度を実現する単一の統合されたサーバーレスモデルで処理します。

Google AI Studio でのワンクリックプロトタイピング: フルスタックアプリケーションを直接構築してデプロイできる Google AI Studio は、迅速なプロトタイピングやテストに最適な環境となっています。ワンクリックで、バイブコーディングされたアプリケーションを即座にパッケージ化して Cloud Run に公開できます。
Cloud Run インスタンス: この新しいプリミティブは、Cloud Storage ボリュームマウントを統合した、個別にアドレス指定可能な長時間実行のシングルトンリソースを管理します。これにより、OpenClaw のような常駐型のバックグラウンドエージェントを費用対効果よくデプロイできるようになります。Cloud Run インスタンスは、ベースラインの共有 CPU 構成の料金が、予測しやすい月額約 5.70 ドルの定額料金（1 つの vCPU と 1 GiB の RAM の場合）からとなっており、従来の VM の無駄なアイドル費用や運用上のオーバーヘッドを回避しながら、常時稼働の VM のようなエクスペリエンスを提供します。
Cloud Run サンドボックス: 500 ミリ秒未満でスピンアップするハードウェア的に隔離された環境で、信頼性の低いモデル生成コードを安全に実行し、ホストシステムを不正アクセスから保護します。

次のステップ

Google は、コンテナプラットフォームのパフォーマンス、セキュリティ、スケールを新たな高みへと引き上げながら、オープンな環境で未来を築き続けています。ぜひ、Agent Sandbox と Agent Substrate を今すぐお試しください。お客様やパートナー様とともに、エージェントインフラストラクチャの未来を築いていけることを楽しみにしています。学習を続けるには、以下のリソースをご覧ください。

2026 年 Gartner® Magic Quadrant™ のコンテナ管理部門を無料でダウンロードできます。
GKE で Agent Sandbox をお試しください。
Agent Sandbox のオープンソースコミュニティに参加して協力しましょう。
Agent Substrate をご確認ください。
11 月 9～12 日にソルトレイクシティで開催される KubeCon North America 2026 にご参加ください。1 日早く到着して 11 月 9 日の GKE Day にも参加すると、より一層お楽しみいただけます。
Google が 2026 年 Gartner® Magic Quadrant™ でクラウドネイティブアプリケーションプラットフォーム部門のリーダーにも選出された理由をご確認ください。
cloud.run で、サーバーレスアプリケーションの未来を築きましょう。

^{1. Gartner レポート: Critical Capabilities for Container Management、2026 年 9 月 8 日}

^{Gartner、Magic Quadrant のコンテナ管理部門、Dennis Smith 他、2026 年 9 月 2 日Gartner、Critical Capabilities for Container Management、Tony Iams、Wataru Katsurashima、Lucas Albuquerque、Dennis Smith、Bhuvie Chhabra、2026 年 9 月 8 日。Gartner および Magic Quadrant は、Gartner, Inc. および / またはその関係会社の商標です。免責事項: Gartner は、発行物に掲載されている特定の企業、ベンダー、製品、サービスを推奨するものではありません。また、最高の格付けまたはその他の評価を得たベンダーのみを選択するように助言するものでもありません。Gartner の発行物は、Gartner のビジネスおよびテクノロジーインサイト組織の見解を表したものであり、事実を表現したものではありません。Gartner は、明示または黙示を問わず、商品性や特定の目的への適合性を含め、本出版物に関連したいかなる保証も行いません。}

ガバナンスが組み込まれた、AI 支援による EKS から GKE への移行を実現する GKE エージェント型移行の概要

Fri, 02 Oct 2026 02:00:00 +0000

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

最も重要な AI 駆動型ワークロードを実行するために、Google Kubernetes Engine（GKE）を標準として採用する企業が増えています。高スループットのデータアクセスを実現する Cloud Storage FUSE から、カスタムコンピューティングクラス（CCC）や高度な GPU スライス法まで、GKE は最新のアプリケーションに必要なスケールと効率性を備えています。

しかし、複雑な Kubernetes 環境を AWS EKS から GKE に移行することは、従来、エンジニアリング上の大きな課題であり、多大な手間を伴うものでした。プラットフォームチームは、複雑な Infrastructure as Code（IaC）を手動で分析し、クラウド固有のアーキテクチャの違いを把握して、カスタム変換スクリプトを構築する必要があります。

エンジニアリングチームは、汎用 LLM を使用してコード変換のドラフトを作成することをよく試みていますが、アドホックなプロンプトはすぐに運用上の落とし穴になる可能性があります。未加工のモデルは、存在しないリソースプロパティのハルシネーションを起こしたり、重要なネットワーク構成や ID 構成を欠落させたり、相互に依存するファイル間でコンテキストを失ったりします。プラットフォームエンジニアがモデルエラーを監査、解決、デバッグするために費やす時間は、当初得られるはずだったスピード向上効果を相殺し、手作業による労力と予測不可能性を生み出します。

このたび、Google は GKE エージェント型移行のオープンソースリリースを発表いたしました。これは、不安定なアドホックプロンプトに代わり、決定論的なガードレールで保護された AI 支援移行パイプラインを提供する専用のエージェントプラグインです。

「大企業のお客様にとって、クラウドのモダナイゼーションにおける最大の障壁は、実行リスクと予測不可能性です。コンテキストを失い、構成をハルシネーションする未加工のチャットプロンプトとは異なり、Google の GKE エージェント型移行は、生成 AI のスピードと、企業が必要とする決定論的なガードレール（構造化された状態の永続性、プラットフォームチームとアプリチーム間のマルチペルソナ境界、交渉の余地のない人間の承認ゲート）の両方を備えてます。これにより、当社のグローバルエンジニアリング部門は、コンパイラ並みの精度で検証可能な移行ファクトリーを手に入れることができ、デリバリーリスクを大幅に削減できました。- Persistent、EVP、Rahul Shrivastava 氏

インフラストラクチャの移行に伴う課題

インフラストラクチャの移行プロセスについてお客様と話すとき、ガバナンスに関するいくつかの課題をよく耳にします。

自動化の信頼ギャップ: Kubernetes 構成を手動でリファクタリングすると、非常に時間がかかることがあります。しかし、汎用的な AI コーディングアシスタントを使用すると、許容できないリスクが生じます。標準的な LLM は、インフラストラクチャコードをハルシネーションしたり、非推奨の API フィールドを使用したり、重要なセキュリティルールを省略したりすることがあります。「ほぼ正しい」コードを生成しても、ボトルネックがコードの作成からデバッグに移行するにすぎません。
ライブクラスタの可変性の危険性（ClickOps）: 従来の移行ツールは多くの場合、ライブクラスタに直接接続し、API 呼び出しを介してデプロイします。これにより、組織の Git リポジトリ（信頼できる情報源）がバイパスされて、CI / CD パイプラインが中断され、ロールバックが非常に困難になります。
サイロ化されたハンドオフのボトルネック: 移行は多くの場合、複数週にわたる長期的な作業となります。プラットフォームエンジニアがランディングゾーンを構築し、アプリケーションデベロッパーがワークロードを移行します。標準的な AI ツールを使うと、引き継ぎ時にコンテキストが失われます。
断片化されたツールチェーン: Velero などのバックアップツールは障害復旧には優れていますが、AWS 固有の構成（ALB など）をそのままキャプチャするため、Google Cloud 向けには変換されません。一方、リバースエンジニアリングツールは、デベロッパーの本来の論理的な意図を排除したフラットな構成を生成します。

GKE エージェント型移行の概要

GKE エージェント型移行は、LLM の推論機能と厳格で決定論的なツールを組み合わせることで、これらの課題に対処します。エージェントスキルとローカルの Model Context Protocol（MCP）サーバーを組み合わせた設計になっており、AI を使用して複雑な AWS EKS IaC と Kubernetes マニフェストを、自動化された pull リクエスト経由で GKE ランディングゾーンに直接変換します。

GKE エージェント型移行の特徴となっている主な機能は次のとおりです。

1. ハイブリッド検証 - LLM で生成し、決定論的に検証。危険な IaC ハルシネーションに対処するため、LLM ワーカーが Terraform と Kubernetes YAML の複雑な作成を処理し、サーバーが Workload Identity アノテーションやイメージレジストリなどの正確なマッピングのために決定論的な変換を実行します。重要なのは、AI が生成したこれらの変換は、ユーザーに提示される前に、厳格な決定論的検証（terraform validate、Kubernetes マニフェストコントラクトなど）にかけられることです。このアプローチは、ハルシネーションに対する安全性を維持しつつ、あらゆる操作を人間参加型（HITL）の承認によって制限するのに役立ちます。

2. GitOps ネイティブの PR ワークフロー: プラグインがライブクラスタに変更を直接適用することはありません。代わりに、信頼できる情報源を読み取り、ターゲット状態を生成して、pull リクエストを開きます。これにより、すべての変更が標準の人間参加型（HITL）CI / CD 審査プロセスをとおして処理されるようになります。「ClickOps」は不要です。

3. 変換と転送の分離を保護: プラグインは、アーキテクチャ変換の面倒なロジックを自動化しますが、ステートフルデータを意図的に転送しません。最も機密性の高いアセットを保護するため、プラグインは、専用の SLA に裏付けられたツール（Google Cloud の Database Migration Service や Storage Transfer Service など）の使用をチームに指示する、コンテキストに応じたランブックを生成します。

4. マルチペルソナの状態管理: 移行はチームが行う取り組みです。プラグインは、長時間実行される移行状態を保持します。これにより、保護された非同期のハンドオフが可能になります。プラットフォームエンジニアがベースラインのランディングゾーンを確立し、アプリデベロッパーは各自のマシンからワークスペースに個別にアクセスして、権限が分離されたフォルダ内で個々のワークロードを変換します。

仕組み: 移行のライフサイクル

内部的には、GKE エージェント型移行は実行可能関数の移行状態グラフを利用し、チェーンに沿ってコンテキストを体系的に渡します。オープンソースのエージェントプラグインとしてパッケージ化されているため、カスタム CLI バイナリをインストールする必要も、中央のコントロールプレーンを管理する必要もありません。チームは既存の開発ハーネスを通じてコラボレーションし、検証済みの pull リクエストと実用的なランブックをソースリポジトリに直接配信できます。これには、次のような利点があります。

EKS リポジトリの念入りな検出: プラグインは、ソース Git リポジトリのクローンを作成するか、EKS クラスタのライブスキャンを実行し、ソースマニフェストをプログラムによりインデックスに登録して、依存関係をマッピングし、インベントリを構築します。
評価とブロッカーガバナンス: アーキテクチャの非互換性を特定する準備状況レポートを生成します。設計を開始する前に、すべてのブロッカーにオーナーと解決目標日を割り当てる必要があります。プラットフォームエンジニアは、変換を開始する前に移行の境界を承認します。
ランディングゾーンの設計: プラグインは、プラットフォームの明示的な決定（GKE Autopilot か GKE Standard かなど）に基づいて、基本的な Google Cloud Terraform モジュール（VPC、サブネット、GKE クラスタ、組織のポリシー）をスキャフォールディングします。
AI を活用したクラウド変換: プラグインは、AWS IRSA から Workload Identity への変換、ALB Ingress から Gateway API へのマッピング、Karpenter ノードクレームから GKE ノード自動プロビジョニング（NAP）またはカスタムコンピューティングクラス（CCC）への変換など、独自の移行を処理します。
オフライン検証: 生成されたモジュールとマニフェストは、オフラインでコンパイルされ、検証されます（terraform validate、マニフェスト構造のチェック、出力コントラクト）。
デプロイ（pull リクエスト経由）: 最終的な構成がローカルで検証され、レビューのために PR が開かれます。

使ってみる

GKE エージェント型移行は、クラウド移行を、まとまりのないリファクタリング作業から、予測可能で AI が支援する、レビュー可能な GitOps ワークフローへと変革します。GKE への移行を加速させる準備は整いましたか？

GitHub の GKE エージェント型移行リポジトリにスターを付け、クローンを作成してみましょう。
オンボーディングガイドを読み、サンプルの EKS リポジトリに対してプラグインを実行しましょう。
Google Cloud コミュニティに参加して、フィードバックの共有、質問、投稿を行ってください。

- GKE プロダクトマネージャー、Sunny Hwang

- GKE エンジニアリングマネージャー、Hamed Seifoddini

Agent Substrate は GKE にて高密度でスケーラブルな信頼できるインフラストラクチャを提供します

Fri, 25 Sep 2026 02:00:00 +0000

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

本日は、Google Kubernetes Engine（GKE）で Agent Substrate が利用可能になったことをお知らせします。Agent Substrate は、オープンソースかつセキュアバイデフォルトのエージェント実行ランタイムであり、標準的なコンテナランタイムよりも 10 倍高い密度で数百万のサンドボックスを実行できるように設計されています。自律型エージェントの時代に向けて専用設計された Substrate は、ネイティブのゼロトラストカーネルとネットワーク分離により、1 秒あたり 500 回を超える一時停止 / 再開アクティベーションを実行しながら、500 ミリ秒未満での再開オペレーションを実現します。

Agent Substrate は、あらゆる Kubernetes インフラストラクチャで動作し、GKE 向けに最適化されたオープンソースソリューションとして提供されます。最先端の AI チームはすでに Agent Substrate を活用しています。Hermes Agent の開発チームである Nous Research は、Agent Substrate を基盤とした開発を積極的に進めています。Hermes は現在、生産性、コーディング、CLI、個人向けエージェントの OpenRouter 使用量において、世界第 1 位の AI エージェントにランクされています。

ローカルから 100 万エージェント規模へ

デベロッパーはすでに Antigravity、Claude Code、Codex、OpenClaw、Hermes などのハーネスをローカルで実行していますが、それと、コード生成、ツールとの連携、自動実行を行う数十万の長期実行エージェントを同時に稼働させることとでは、根本的に異なります。そして、これこそが既存のアーキテクチャでは対応が極めて難しい課題となっています。

エージェントプラットフォームをローカルプロトタイプから大規模なエージェントの実行にスケールすると、インフラストラクチャの制約が根本的に変化します。これには、次のようなものが含まれます。

不透明な信頼境界: モデルは任意のコードをその場で生成して実行できます。カーネルレベルの分離と動的なネットワーク制御がなければ、人間の目に触れたことのない信頼できないコードを実行することは、ホストエスケープや認証情報の窃盗、データの流出といったリスクを伴います。
ツールアクセスの障壁: エージェントがコマンドラインツール、ヘッドレスブラウザ、ファイルシステムワークスペースを呼び出すには、フル機能のコンピュータ環境が必要です。これらを安全に実行するには、高速かつ容易でなければなりません。
大規模なバースト: エージェントハーネス、ベンチマーク、強化学習のロールアウトにより、1 分間に数千のサンドボックスが生成されることがあります。汎用スケジューラはこうしたチャーンに対応しきれず、また、コンテナイメージが繰り返し解凍されることで、深刻なディスク競合が発生する恐れがあります。
アイドル状態のコンピューティング: 自律型エージェントは、モデルの推論、ツールの応答、人間のフィードバックを待つ間、ほとんどの時間を休止状態で過ごします。アイドル状態のコンテナに専用の CPU と RAM を予約すると、貴重なリソースが無駄になります。

エージェント専用に構築された基盤

プラットフォームチームがこれらの課題にぶつかったとき、彼らは受け入れがたいトレードオフを迫られます。それは、「制御と分離を犠牲にする」か、それとも「VM の高レイテンシと非効率性に目をつぶる」か、という選択です。Google は、チームがどちらか一方を選択する必要はないと考えています。

Agent Substrate は、エージェントの実行をマシン管理から切り離すことで、この問題を回避します。クラウドネイティブな Kubernetes インフラストラクチャ上に構築された Agent Substrate は、エージェントワークロード専用に設計された新しい実行レイヤを提供します。

この基盤の上で、実行レイヤがサンドボックス化されたエージェント環境のライフサイクルを直接管理し、以下の機能を提供します。

デフォルトでのセキュリティ確保: ハードウェアで分離された Cloud Hypervisor microVM または gVisor サンドボックスを採用。さらに、きめ細かいネットワークポリシーを適用する Egress プロキシを組み合わせ、エージェントの手の届かない場所で認証情報を安全に挿入することで、認証情報の窃盗を防止します。
1 秒未満で起動: コンテナの起動遅延を排除。オンデマンドで、事前にウォームアップされたワーカーに対して、アクティブ化したエージェントをミリ秒単位で即座にディスパッチします。
高効率: アイドル状態のアクターは数百ミリ秒で一時停止され、スケジュールが解除されるため、コンピューティングリソースが解放されます。
オープンソースでポータブル: あらゆるコンピューティング環境のあらゆる Kubernetes クラスタで実行でき、Claude Code、OpenClaw、Hermes などのあらゆるエージェントフレームワークやハーネスと連携します。

アーキテクチャの基本原則

Agent Substrate がこれらの課題を解決する上での指針として、以下の4つのコア・アーキテクチャ原則を掲げています。

1. カーネルとネットワークのレベルで、デフォルトで保護

AI エージェントは、信頼できないコードやターミナルコマンドを生成、実行することをコア機能としています。共有サーバー上でそうしたコードを実行することは、共有カーネルまたはネットワークレベルで、ブレイクアウトや意図しないデータ漏洩を引き起こす重大なリスクを伴います。

Agent Substrate は、ホストカーネルとネットワークレイヤの両方で、デフォルトで安全な状態を維持します。チームは、完全な Linux カーネル互換性を提供するハードウェア分離された Cloud Hypervisor microVM か、さらにオーバーヘッドの低いカーネル分離を提供する gVisor サンドボックスのいずれかを選択できます。Agent Substrate の統合ゲートウェイは、すべての Egress リクエストと Ingress リクエストを管理し、ネットワークアクセスをきめ細かく拡張可能な方法で制御できるようにします。

2. 低レイテンシのアクティベーション用に構築されたコントロールプレーンとデータプレーン

分離された環境で長時間実行されるエージェントワークロードの密度を最適化するには、レイテンシを極限まで抑え、一時停止および再開のオペレーションを極めて高い頻度で実行できる、専用設計のコントロールプレーンとデータプレーンが必要です。Agent Substrate は、最小限のレイテンシでデータアウェアスケジューリングを処理する専用のコントロールプレーンを導入しています。一方、データプレーンは、事前にウォームアップされたワーカー上で 1 秒あたり数百件の一時停止 / 再開オペレーションを直接処理し、環境の準備にかかるオーバーヘッドを削減します。スナップショットは、永続的な状態を維持するためにローカルディスクと Google Cloud Storage に書き込まれます。サンドボックス環境は 500 ミリ秒未満で以前の状態に再開でき、アイドル状態になるとすぐに再び一時停止できます。

3. 高密度かつアクティブ時のみのコンピューティングエコノミクス

エージェントは、ほとんどの時間をモデルの推論、ツールの応答、ユーザー入力の待機に費やします。アイドル状態のコンテナのために物理 CPU と RAM を予約することは、高価で希少な容量をロックすることになり、エージェントフリートを大規模に実行できなくなる恐れがあります。

Agent Substrate は、エージェントが一時停止した瞬間にリソースを解放できます。ゲストハイパーバイザの状態をローカルディスクと Cloud Storage にスナップショットとして保存し、そのまま維持しながら、RAM と CPU を解放して他のエージェントを実行できるようにします。次のターンまたはツール呼び出しが到着すると、Agent Substrate はスナップショットとして保存したセッションをミリ秒単位で再開します。このゼロアイドルモデルでは、ホストあたり 1,000 を超える休止状態のエージェントを収容でき、従来のコンピューティングよりも 10 倍高いコンピューティング密度を実現します。ターン間で共有ファイルシステムを必要とするワークロードの場合、オプションの Filestore エージェントボリュームコントローラが永続的な NFS ストレージを提供します。詳細については後述します。

4. 基盤としての Kubernetes: スケールと信頼性

標準 VM 上にカスタムサンドボックスオーケストレーターを構築すると、チームはノードの復元、自動スケーリング、マルチゾーンスケジューリング、ネットワークポリシーといった、煩雑な運用ツールのメンテナンスを余儀なくされます。しかし、1 秒に満たないツール呼び出しを標準の Kubernetes Pod ライフサイクル経由でルーティングすると、リクエストごとに数秒の遅延が発生してしまいます。

Agent Substrate は、両方のアプローチを組み合わせています。高頻度の一時停止 / 再開は、専用設計されたデータプレーンを介してローカルワーカー上で直接実行されます。一方、Kubernetes はマシンを管理し、自己修復ノード、フリートの自動スケーリング、クラスタの信頼性を制御するとともに、ワーカー Pod 自体のライフサイクルを司ります。標準の Pod セマンティクスを必要とするワークロードでは、Agent Sandbox やカーネル分離 Pod などの既存のプリミティブが引き続き並行して動作します。

Google Cloud インフラストラクチャ向けに最適化

100 万エージェント規模を実現できるエージェントプラットフォームを構築するには、適切な基盤となるコンピューティングとストレージのインフラストラクチャが必要です。GKE 上の Agent Substrate は、カスタム ComputeClass を使用して、スポットプールやオンデマンドプールを含む、さまざまなシェイプやファミリーにわたるマシンプールを動的に管理することで、マシンの入手可能性と柔軟性を最大化します。これには、Google のカスタム Arm ベースプロセッサである Google Axion のネイティブサポートが含まれます。Google Axion は、競合するクラウドサービスと比較して、サンドボックスワークロードのコストパフォーマンスを最大 30% 向上させます。ステートフルなワークスペースの場合、GKE 上の Agent Substrate を Filestore エージェントボリュームとオプションで統合できます。これは、NFS マウントをミリ秒単位でアタッチ / デタッチする新しいサービスで、エージェントをほぼ瞬時に開始 / 再開できます。また、ネイティブの Read-Write-Many（RWX）アクセスと POSIX 準拠のファイルロックにより、書き込みの競合なしに安全なマルチエージェントコラボレーションを実現します。

スケーラブルな基盤上にエージェントプラットフォームを構築

本番環境向けのエージェントアプリケーションを構築する際、強固なセキュリティ、低レイテンシ、運用規模のいずれかを犠牲にする必要はありません。

Nous Research は、OpenRouter において使用量世界第 1 位を誇る AI エージェントである Hermes を開発しています。Hermes は、生産性、コーディング、個人向け、CLI エージェントでも第 1 位にランクされています。Nous Research は、Agent Substrate の初期設計パートナーとして、エージェントワークロードが導入する分離と ID の要件をランタイムがどのように処理するかを評価しています。

「Hermes Enterprise は、お客様が既存のインフラストラクチャにデプロイできるようにすると同時に、エージェントごとの分離と拡張可能なアクセス制御を処理できるように構築されています。Agent Substrate は、プラットフォームレイヤでこの両方に対処しつつ、貴重なコンピューティングリソースの消費も抑えます。Agent Substrate を使用した経験から、エージェントワークロードの増加に合わせてアーキテクチャを効率的にスケールできると確信しています。」 - Nous Research、最高ビジネス責任者、Hervé Bizira 氏

Agent Substrate は、Kubernetes のマシンの復元力、自己修復ノード、宣言型管理を、カーネル分離、アクティブ時のみのコンピューティング、1 秒未満の実行のために構築されたエージェントネイティブのデータプレーンと組み合わせることで、エンジニアリングチームに確実な拡張への道筋を提供します。

Agent Substrate はオープンソースであり、GKE をご利用のすべてのお客様が非本番環境ワークロードで利用できます。本番環境向けの一般提供サポートは、許可リストを通じてご利用いただけます。GKE クラスタにデプロイするには、GKE 上の Agent Substrate に関するドキュメントをご覧ください。詳細については、Agent Substrate について、またはオープンソースリポジトリをご覧ください。

- エンジニアリング担当バイスプレジデント、Alex Zakonov

- エンジニア、Tim Hockin

分散 Ray クラスタに gVisor サンドボックスを導入

Fri, 04 Sep 2026 11:20:00 +0000

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

強化学習（RL）のエコシステムでは、複雑なトレーニング後のワークフローを支える統合コンピューティングランタイムとして、Ray の採用が急速に進んでいます。Google Cloud のお客様も、マルチモーダルデータパイプラインから最先端の RL まで、さまざまなワークロードに Ray を活用しています。しかし、エージェントモデルと推論モデルが進化するにつれて、重大な課題が浮き彫りになってきています。それは、動的なロールアウト、コード生成、マルチターンのツール操作を安全に実行するために、安全で分離されたサンドボックスを大規模にオーケストレートすることです。このたび、Anyscale とのパートナーシップによる Ray の試験運用版ライブラリを導入いたします。このライブラリは、Google で開発中のエージェント型 AI テクノロジーを活用して、ネイティブで高性能なサンドボックス環境を分散 Ray クラスタに直接提供するものです。

Ray プリミティブとしてのサンドボックス

Ray は、トレーニング後のワークロードをオーケストレートするための標準的なランタイムとして定着しています。veRL、NeMo-RL、SLIME、MILES、SkyRL などのフレームワークは、すでに Ray を使用して分散トレーナー、推論エンジン、ロールアウトワーカーなどのコンポーネントを調整しています。

Ray サンドボックスの設計において重要な目標としたのは、隔離された実行のために新たな抽象化を導入するのではなく、既存の Ray プログラミングモデルに自然に馴染む形にすることです。サンドボックスは、Ray が管理する他のリソースと共通する特性を多く備えています。具体的には、マシンへの配置や、リソースの割り当て、作成と破棄、障害からの復旧、周囲のワークロードに応じたスケーリングなど、他のリソースと同様の管理が求められます。こうした背景から、各ハイレベルサンドボックスを Ray アクターとして表現する手法を採用しました。

Ray スケジューラは、どのノードでサンドボックスを実行するかを決定し、対応する CPU とメモリリソースを予約します。サンドボックスアクターが自身のライフサイクルを管理する一方で、gVisor はそのノード上で隔離された実行環境を提供します。

Ray 2.58 以降では、フレームワークの作成者と研究者は、他のワークロードで使い慣れた Ray API やパターンをそのまま使用して、サンドボックス環境を管理できます。以下にその例を示します。

code_block: <ListValue: [StructValue([('code', 'import ray\r\nfrom ray.experimental import sandbox\r\n\r\nray.init()\r\n# Create a gVisor sandbox environment and return an actor handle for a proxy actor\r\nsb = sandbox.create(\r\n cpu=1.0,\r\n memory="512Mi",\r\n image="python:3.12-slim"\r\n)\r\n# Execute code inside the sandbox\r\nresult = ray.get(sb.exec.remote("python -c \'import sys; print(sys.version)\'"))\r\nprint(result.stdout)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1d2c6cd0>)])]>

これにより、OCI 互換イメージから gVisor サンドボックスが作成され、Ray アクターのハンドルが返されます。exec の呼び出しは通常の Ray アクター呼び出しと同じであるため、サンドボックスはクラスタ内のどこにでも配置できます。作成されたアクターは、オペレーションを gVisor に転送するプロキシです。

サンドボックス API は、エージェント型ワークロードに必要な基本的なライフサイクル管理に対応しています。

OCI コンテナイメージから環境を作成する
CPU とメモリの上限を設定する
環境変数、作業ディレクトリ、ネットワーキングを構成する
コマンドを実行する
ファイルの読み取り、書き込み、アップロード、ダウンロードを行う
サンドボックスの状態を検査する
環境を終了または削除する

さらに詳細な制御が必要な場合は、SandboxRuntime を使用してローカルの gVisor サンドボックスを直接操作できます。これにより、gVisor に引き渡す前の OCI 仕様をユーザー側で編集できるようになります。この API を使用してアクター内にローカルサンドボックスのプールを構築する方法を以下に示します。

code_block: <ListValue: [StructValue([('code', 'import ray\r\nfrom ray.experimental.sandbox.runtime import SandboxRuntime\r\n\r\n@ray.remote\r\nclass SandboxPool:\r\n def __init__(self, size: int = 3, image: str = "python:3.10-slim"):\r\n self.runtime = SandboxRuntime()\r\n self.sandboxes = [\r\n self.runtime.create(image=image, memory="512Mi")\r\n for _ in range(size)\r\n ]\r\n\r\n def run_command(self, index: int, command: str):\r\n return self.runtime.exec(self.sandboxes[index], command)\r\n\r\n def close(self):\r\n for sb_id in self.sandboxes:\r\n self.runtime.delete(sb_id)\r\n\r\n# Deploy an actor managing a pool of local sandboxes\r\npool = SandboxPool.remote(size=3)\r\nresult = ray.get(pool.run_command.remote(0, "python3 -c \'print(\\"Hello from pool!\\")\'"))\r\nprint(result.stdout)\r\nray.get(pool.close.remote())'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1d5a9410>)])]>

gVisor を選ぶ理由

モデルが生成したコードを実行する際は、その環境内のコードを「信頼できないもの」として扱う必要があります。Ray サンドボックスは、Google のオープンソースアプリケーションカーネルである gVisor を初期サンドボックスランタイムとして使用します。gVisor は、Linux システムコールインターフェースの大部分をユーザー空間に実装し、ワークロードとホストカーネルの間に、さらなる分離境界を追加します。OCI 互換で、標準のコンテナイメージをそのまま利用でき、Docker デーモンやホスト Docker ソケットをサンドボックスに公開する必要もありません。

この組み合わせは、エージェント型ワークロードに非常に適しています。環境を動的に作成できるほど軽量に保ちながら、生成されたコードを通常のコンテナで直接実行するよりも強力な隔離環境を実現できるからです。gVisor は 1 秒未満の高速起動と低メモリオーバーヘッドを両立しているため、サンドボックスを粒度の細かい分散リソースとして柔軟に活用できます。

Ray の今後のバージョンでは、Agent Substrate や Kata Containers といった他のサンドボックスランタイムにもサポートを拡大していく予定です。

GKE で Ray サンドボックスを試す

Ray サンドボックスの詳細は、Ray のドキュメントでご確認いただけます。GKE でこれらのサンドボックス機能を試すには、Ray サンドボックスのユーザーガイドをご参照ください。フィードバックやアイデアがございましたら、GitHub の issue でディスカッションにぜひご参加ください。強化学習における Ray の未来を一緒に考えていきましょう。

- Google、スタッフソフトウェアエンジニア、 Andrew Sy Kim

- Anyscale、最高技術責任者、Philipp Moritz 氏

GKE の ClusterNetworkPolicy: マイクロサービスの制御と自律性のバランスを取る

Mon, 24 Aug 2026 01:00:00 +0000

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

マルチテナントの Kubernetes 環境におけるネットワークセキュリティの管理では、通常、2 つの異なるニーズのバランスを取ることが求められます。デベロッパーがマイクロサービス間で円滑な通信を確保したいと考える一方で、プラットフォームおよびセキュリティチームは、コンプライアンスの維持、ラテラルムーブメントの防止、そしてクラスタ全体のガードレールの確立を確実に行わなければなりません。

従来、これには標準の Kubernetes NetworkPolicy が主なツールとして使われてきました。標準の NetworkPolicy は、単一の名前空間を分離するには効果的ですが、そのスコープは個々の名前空間に厳密に限定されており、デベロッパーのセルフサービスを前提とした設計になっています。クラスタ管理者がグローバルなセキュリティ強化のために使用しようとすると、ポリシーの競合や運用上の課題が生じる可能性があります。

この問題に対処するため、Google は Kubernetes SIG-Policy ワーキンググループ（WG）が開発したオープンソース標準である ClusterNetworkPolicy（CNP）を Google Kubernetes Engine（GKE）に導入しました。大規模環境を想定して設計された CNP は、クラスタ全体のリソースです。これにより、管理者はネットワークセキュリティを一元管理できるようになり、グローバルセキュリティの担当者が、一貫性のあるバイパスできないポリシーを実装するための仕組みを提供します。

CNP の技術的な詳細、一般的なユースケース、ポリシーの例、利用開始方法について、以下をご覧ください。

ティアによるポリシーの構造化

ClusterNetworkPolicy のコア機能は、その階層的なティアシステムです。CNP は、フラットで競合するピアルールを同時に調整しようとするのではなく、決定論的なトップダウンの評価階層を確立します。

管理者ティア: 最も優先度の高いレベル。ここでのルールは、他のあらゆるポリシーよりも先に適用されます。
ネットワークポリシーティア: 標準の名前空間レベル。デベロッパーが個々のアプリケーションポリシーを管理します。
ベースラインティア: 最も優先順位が低く、他のどのポリシーも適用されない場合のクラスタのデフォルト動作を規定します。これは、名前空間スコープのポリシーを使用でオーバーライドできます。

このティア構造により、ネットワークセキュリティを組織の役割と整合させることができます。標準のロールベースアクセス制御（RBAC）を使用すると、管理者ティアを管理してコンプライアンス要件を適用できます。一方、プラットフォームチームはベースラインティアを使用して、クラスタ全体にデフォルトの「すべて拒否」ゼロトラスト体制を設定できます。同時に、デベロッパーはコアセキュリティ要件をオーバーライドすることなく、自身のアプリケーションに対して標準ネットワークポリシーを定義できます。

この決定論的なトップダウンの評価方法により、異なるチームのポリシー間の競合が解消されます。管理者ティアでは、明示的な Pass アクションが導入されています。これにより、セキュリティチームはグローバルルールに照らしてトラフィックを検査し、最終的な許可または拒否の決定をデベロッパーの名前空間ポリシーに委任できるため、中央での統制と分散管理の両立が容易になります。

一般的なネットワークセキュリティシナリオ

このティアアーキテクチャは、複雑なセキュリティ要件を一元化されたルールへと落とし込みます。ClusterNetworkPolicy が有効な解決策となる一般的なシナリオをいくつか紹介します。

機密性の高いワークロードの分離: 管理者ティアのグローバル拒否ルールを適用して、支払い処理やコンプライアンスデータに使用される名前空間など、特定の名前空間をクラスタの他の部分から分離できます。このアクションは、放っておくとこれらの環境をさらしてしまう恐れのある、制限の緩いデベロッパーポリシーをオーバーライドします。
コアサービスの保護: 内部運用に支障をきたすような構成を防ぐため、管理者は kube-dns などの重要なサービスに対して、管理者ティアのグローバル許可ルールを作成できます。これにより、名前空間ポリシーに構成ミスがあっても、これらのサービスへのアクセスを維持できます。
外部への下り（外向き）の管理: IP アドレス範囲のマッチングを利用することで、下り（外向き）トラフィックをクラスタレベルで制御できます。この機能を使用すると、企業イントラネットや外部 IP 範囲へのアクセスを明示的に制限または許可できるため、不正なデータの持ち出しに対する安全対策として機能します。

シナリオの例

一般的な企業の要件を考えてみましょう。すべての名前空間にわたるアプリケーションワークロードは、中央のプラットフォームインフラストラクチャ（共有認証サービスやテレメトリーサービスなど）へのアクセスが許可されている必要がありますが、その一方で、機密性の高い環境（制限付きの Vault 名前空間など）へのアクセスは厳格に禁止されます。その一方で、通常のマイクロサービス間のトラフィックは、デベロッパーが管理する名前空間スコープのポリシーに委ねられます。

ClusterNetworkPolicy を使えば、これを簡単に実現できます。プラットフォーム管理者は、管理者ティアのガードレールを次のように一元的に定義するだけです。

code_block: <ListValue: [StructValue([('code', 'apiVersion: policy.networking.k8s.io/v1alpha2\r\nkind: ClusterNetworkPolicy\r\nmetadata:\r\n name: platform-isolation-guardrail\r\nspec:\r\n tier: Admin\r\n priority: 10\r\n subject:\r\n # Target all application tenant namespaces, excluding system and core infrastructure\r\n namespaces:\r\n matchExpressions:\r\n - key: kubernetes.io/metadata.name\r\n operator: NotIn\r\n values: ["kube-system", "shared-services", "restricted-vault"]\r\n egress:\r\n # 1. Mandate access to central shared platform services\r\n - name: allow-shared-services\r\n action: Accept\r\n to:\r\n - namespaces:\r\n matchLabels:\r\n kubernetes.io/metadata.name: shared-services\r\n\r\n # 2. Enforce strict block on accessing the restricted vault namespace\r\n - name: block-restricted-vault\r\n action: Deny\r\n to:\r\n - namespaces:\r\n matchLabels:\r\n kubernetes.io/metadata.name: restricted-vault\r\n\r\n # 3. Explicitly delegate all remaining traffic to developer namespace policies\r\n - name: delegate-remaining-egress\r\n action: Pass\r\n to:\r\n - namespaces: {}\r\n - networks:\r\n - 0.0.0.0/0\r\n - ::/0'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1d278690>)])]>

オープンソース基盤の拡張

Google は、この機能を独自の拡張機能として構築するのではなく、Kubernetes コミュニティと協力して ClusterNetworkPolicy API（policy.networking.k8s.io）を設計し、名前空間スコープの NetworkPolicy API（networking.k8s.io）と明確に区別しました。さらに、Cilium コミュニティと緊密に連携して、API の実装を構築しました。

GKE はオープンソース標準に基づいて構築されているため、セキュリティ構成をさまざまな環境に移植することが可能です。ClusterNetworkPolicy API は、ティアの選択をネイティブにサポートしているため、明確で決定論的なポリシー評価が可能です。このアプローチにより、管理者は堅牢なセキュリティガードレールを適用しながら、開発チームが必要とする運用上の柔軟性を維持できます。

GKE の ClusterNetworkPolicy は、ワークロードのネットワークセキュリティを強化し、運用を名前空間スコープのルールから、クラスタ全体にわたる統合されたガバナンスに移行します。現在は、バージョン 1.36 以降でプレビューとして利用可能です。詳細と利用開始方法については、以下をご覧ください。

- グループプロダクトマネージャー、Srini Jasti

- ソフトウェアエンジニア、Blaz Zupan

少ないリソースでより多くの成果を上げる: GKE でエージェントあたりの費用を 75% 削減する方法

Fri, 07 Aug 2026 02:00:00 +0000

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

昨今のエージェントの時代において、最新のクラウドアプリケーションは、単なる受動的なツールの集合体から、幅広いタスクにわたって推論、計画、実践する自律的なデジタルワーカーのフリートへと進化しています。

このような環境を設計するプラットフォームエンジニアリングチームにとって、最も簡単なアプローチは、仮想マシン（VM）上で動作する OpenClaw や Hermes などのオープンソースフレームワークにエージェントをデプロイすることです。しかし、それらのワークロードが本番環境に移行し、追加のユーザーやユースケースをサポートするためにスケールするにつれ、チームはすぐに重大な課題に直面します。AI エージェントはバースト的に動作する傾向があり、しばらくの間はリクエストを積極的に処理したりコードを実行したりしますが、その後はユーザー入力や外部トリガーを待つ間、長期間の非アクティブ状態になります。静的なコンピューティング割り当てに依存している場合、アイドル状態のエージェントであっても貴重な CPU とメモリを消費し続けます。

問題となるのは、信頼性、スケーラビリティ、効率性を損なうことなく、固定されたコンピューティングフットプリントに、いかに多くのエージェントを安全に詰め込むかということです。

その答えは、初期段階からオーケストレーションをアーキテクチャ全体の一部として組み込むことです。オーケストレーションにより、ユニットエコノミクスとスケーラビリティ、使いやすさ、信頼性を初日から大幅に向上させることができます。Google Kubernetes Engine（GKE）は、高度なオーケストレーション機能を提供します。コンピューティング能力を最大限に活用できるよう、Google は、固定の Google Compute Engine VM インスタンス（n2-standard-48）で実行される単一の GKE ノードに、パフォーマンス低下や繰り返しの障害を発生させずに搭載できる AI エージェントの最大数をテストしました。OpenClaw プロファイルを使用して、段階的な最適化を適用し、エージェントワークロードを大規模に実行するうえでオーケストレーションが果たす重要な役割を実証しました。詳細については、以下をお読みください。

ベースライン: microVM で OpenClaw を実行する

信頼できないマルチエージェントワークロードをセキュアに実行するには、強力な分離が必要です。一般的なアプローチとして、Kubernetes デプロイメント上の専用マイクロ VM（Kata コンテナなど）内で各エージェントを実行する方法があります。これにより、ハードウェアレベルでの強力な分離が実現します。

この方法では必要なセキュリティ境界は確保できますが、すぐにスケーリングの限界に直面します。各マイクロ VM には、メモリと CPU リソースを消費する独自のゲストオペレーティングシステムが必要であるため、実際のエージェントで使用できる実際のリソースが制限されます。このベースラインシナリオでは、標準の GKE ノードで OpenClaw エージェントが 61 個に達した時点でスケーリングの限界に達し、信頼性が低下してワークロードのヘルスチェックが定期的に失敗するようになりました。

最適化 1: GKE Agent Sandbox で密度を向上する

この問題に対処するため、同じエージェントワークロードをマイクロ VM から GKE Agent Sandbox に移行しました。GKE Agent Sandbox は、エージェントの実行におけるセキュリティとパフォーマンスの要件に特化して設計された Kubernetes プリミティブです。

GKE Agent Sandbox は、重いゲストオペレーティングシステムに依存するのではなく、オープンソースの安全なコンテナサンドボックスである gVisor を活用します。gVisor は、ユーザー空間カーネル（Sentry）を使用してシステムコールをインターセプトし、フィルタリングします。これにより、標準の Kubernetes コンテナの軽量なフットプリントを維持しながら、信頼できないコードの実行に対して本番環境レベルの安全な分離が提供されます。

オーバーヘッドが削減されたことでサンドボックス自体の効率が向上し、障害が発生する前に同じ VM 内に 88 個の OpenClaw エージェントをデプロイできるようになりました。これは、信頼性の高いセキュリティ境界を維持しつつ、同じ固定容量で実行できるエージェントの数が 44% 増加したことを意味します。

そのため、5 月に GKE Agent Sandbox の一般提供が開始してから、4 週間足らずで使用量が 7 倍以上に増加したのも不思議ではありません。

重要なポイント: Google のテストでは、OpenClaw タイプのエージェントを GKE Agent Sandbox に移行することで、vCPU あたりのエージェント数を 40% 以上増やし、エージェントあたりの費用を 30% 以上削減しながら、パフォーマンスプロファイルはほぼ同じ水準を維持できました。

最適化 2: オーケストレーションの価値

GKE Agent Sandbox はアクティブなワークロードを最適化しますが、アイドル状態の AI エージェントの問題を解決するには、ワークロードオーケストレーションをエージェントアーキテクチャの中心に据える必要があります。

アイドル状態のエージェントをバックグラウンドで実行し続けるのではなく、GKE Pod スナップショットを使用して永続ストレージにチェックポイント（固定）することで、物理 CPU とメモリリソースをクラスタに解放できます。新しいタスクトリガーが到着すると、軽量の Kubernetes コントローラまたはイベントゲートウェイがリクエストをインターセプトし、スナップショットからエージェントを再開するよう GKE にシグナルを送信します。この処理はミリ秒単位で行われます。

このパターンにより、ワークロードの動作に基づいて物理的なコンピューティングリソースを確実にオーバーサブスクライブできるため、同じノードにより多くのエージェントを配置できます。ただし、オーバーサブスクリプションは万能なアプローチではなく、いくつかのトレードオフが伴います。AI エージェントごとにレイテンシ要件と実行モデルが異なるためです。すべてのエージェントを同じように扱うと、レイテンシによってユーザーエクスペリエンスが低下するか、VM のオーバープロビジョニングによってプロジェクトが破綻することになります。

GKE を使用すると、さまざまなタイプのエージェントやユースケースに合わせてカスタマイズされたデプロイをサポートするエージェントプラットフォームを運用できます。各デプロイは、独自のパフォーマンスと費用の要件に合わせてファインチューニングされます。

GKE は、レイテンシの感度とリソース密度のバランスを取りながら、エージェントワークロードのさまざまな動作をサポートします。

以下に、パフォーマンス要件が大きく異なるエージェントワークロードの例を紹介します。

リアルタイムのコーディングアシスタント（レイテンシの影響を受けやすい）: 開発者向けの直接エージェントには、1 秒未満の起動時間（1 秒未満）が求められ、キューイングは一切許容されません。GKE は、GKE Pod スナップショットと Agent Sandbox ウォームプールを組み合わせることで、ほぼ瞬時に実行できる、ウォームアップ済みの分離されたサンドボックスを維持します。
自律型チームメイト （バランス型）: インタラクティブなバックグラウンドエージェントは、平均的な起動時間（数秒）を許容できます。GKE の一時停止と再開の機能により、これらのエージェントはオンデマンドで復元されるため、アイドル状態の間にコンピューティングリソースを消費することはありません。
ヘッドレスバックグラウンドエージェント（レイテンシ許容型）: 毎日スケジュール設定される調査や分析の cron ジョブは、キューの遅延を許容できます。クラスタ容量が利用可能になるまで 1 時間待ってこれらのジョブを実行しても、ビジネスの成果が損なわれることはありません。このようなエージェントのコストを抑えるには、最大のリソースオーバーサブスクリプションを使用します。

つまり、GKE では、クラスタ全体で単一の戦略を強制するのではなく、ノードプールとワークロード構成全体で異なる動作を同時にサポートできます。

「Thundering Herd」問題、つまり、エージェントが一斉に起動し、同時にコンピューティングを要求する状況を想定してください。GKE では、Agent Sandbox ウォームプールや一時停止と再開などの機能を使用して、特定の要件（パフォーマンス重視かコスト重視か）に基づいて、コスト削減の可能性とパフォーマンス保証とのバランスをチューニングできるようになっています。

パフォーマンス重視: 大規模で突発的なトラフィックの急増時にも、1 秒未満のパフォーマンスを保証する必要があるユースケースの場合は、Agent Sandbox のウォームプールを使用してバッファをプロビジョニングできます。この構成では、同じノードで 133 個の OpenClaw エージェントを実行できました。
コスト重視: レイテンシを許容できるワークロードや、段階的に実行できるワークロードでは、オーバースクリプション率を高くすることでノード密度を大幅に高めることができます。この構成では、起動時間を 5 秒未満に抑えながら、同じノードで 274 個のエージェント（ベースラインの 3 倍以上）を実行できました。

重要なポイント: GKE Agent Sandbox と GKE の一時停止および再開機能を組み合わせることで、アイドル状態のエージェントを固定し、固定のコンピューティング容量をオーバーサブスクライブできます。アクティビティが断続的に発生するエージェントの場合、エージェント密度が最大 3.5 倍になり、エージェントあたりのコストが最大 75% 削減されます。

予算を増やさずにエージェントをスケールさせる

エージェントをスケールしても、インフラストラクチャの予算を比例してスケールする必要はありません。例が示すように、適切なプラットフォーム機能を採用し、最初からオーケストレーションを考慮することで、コンピューティング容量から得られる価値を劇的に変えることができます。GKE を使用すると、積極的なコスト削減を優先する場合でも、パフォーマンスを最適化する場合でも、インフラストラクチャをビジネス目標に容易に合わせることができます。

そして、これはまだ始まりにすぎません。Google Cloud は、エージェントの時代の要求に対応できるよう、常に新しいイノベーションを推進しています。コンピューティング容量をさらに有効活用する準備はできていますか？GKE Agent Sandbox に関するドキュメントで、GKE がチームのイノベーションをより迅速かつ低コストで実現するのにどのように役立つかをご覧ください。

- プロダクトマネージャー、Drake Williams

- エンジニアリングマネージャー、Steven Linde

アイドル状態のアクセラレータを最小限に抑える: llm-d での協調型タイムスライスによるネイティブ RL ジョブのインターリーブ

Mon, 03 Aug 2026 02:20:00 +0000

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

大規模言語モデル（LLM）のトレーニング後の強化学習（RL）において、その背後にある数学は妥協が許されないことで知られています。最先端の AI ラボでは、Group Relative Policy Optimization（GRPO）などの RL のトレーニング後のアルゴリズムを使用して推論モデルやコーディングモデルの限界を押し広げるなか、アーキテクチャやインフラストラクチャの厳しい制約に日常的に直面しています。業界の関心の多くは、依然としてアクセラレータの物理容量の獲得に集中していますが、複数の RL ジョブを実行し、モデルをより高いレベルのインテリジェンスに引き上げるために必要な高速性を実現するには、インフラストラクチャの効率も同様に重要です。大規模な分散 RL では、同期サンプリングとトレーニングが厳密に順次フェーズとして実行されるため、トレーナーとサンプラーのリソースが交互にアイドル状態になるため、深刻なリソースボトルネックが発生します。一方、非同期アーキテクチャではこれらのフェーズを重複させようとしますが、トレーナーは、次のサイクルを開始する前に特定の軌跡バッチが完了するのを待つ間、頻繁にアイドル状態になります。

本日は、この構造的な無駄を解消するソリューションとして、llm-d プロジェクトによる協調型タイムスライスをご紹介します。ロールアウトのサンプリングや勾配トレーニングといった個別の RL ステップを、スケジュール可能な動的エンティティとして扱うことで、独立した RL ジョブを共有物理ハードウェアにインターリーブできます。初期ベンチマークでは、このプラットフォームレベルの多重化により、モデルの収束や精度に影響を与えることなく、アクセラレータの集計デューティサイクルがベースラインの約 40% から最大 70% まで向上することが示されています。これにより、時間の経過とともに発生するコンピューティングの無駄がなくなるため、コストパフォーマンスが向上し、TCO の大幅な削減が実現します。

同期設定の場合、プラットフォームはサンプラーとトレーナーの両方をインターリーブして、交互に生じるアイドル時間を最小限に抑えます。一方、非同期ワークロードはタイムスライスを利用して、RL トレーナーのイテレーション間に生じる断片的なアイドル時間を動的に回収して再利用します。

このブログ記事では、このタイムスライスソリューションについて、技術フロー、現在のリリース、今後のロードマップを詳しく説明します。

RL インフラストラクチャの効率化のための llm-d（全体像）

Google は当初から、大規模な RL のトレーニング後にインフラストラクチャに深刻なボトルネックが生じることを予測し、RL ワークロードにおけるインフラストラクチャの非効率性を解消することに取り組んできました。

そのなかで、アクセラレータのアイドル時間をなくすことを重視し、推論、エージェント、RL ワークロード向けの高度にコンポーズ可能なインフラストラクチャスタックに llm-d を組み込みました。RL 向け llm-d スタックには、次のような特徴があります。

スループット重視の推論 （llm-d-router）: RL ワークロード全体にデプロイされ、成熟した、本番環境でテスト済みのエンジンです。ロールアウト生成スループットを最大化してパイプライン常にフル稼働させることに重点を置いています。
高ベロシティの Agent Sandbox （レシピ）: 大規模かつ高密度な環境での検証済みで、ロールアウトの生成と評価中に、安全な 1 秒未満でのツール使用と分離されたコード実行を実現します。Agent Sandbox は、報酬シグナルの生成のための高速インテークマニホールドとして機能し、タイムスライスされた NVIDIA GPU がリソース不足になるような、サンドボックスがレイテンシのボトルネックにならないように設計されています。
コアパイプラインプリミティブ: 重み転送の信頼性と速度の問題に対処するため、Google は Weight Propagation Interface（WPI）を構築するとともに、RL の全体的なオブザーバビリティと信頼性の向上に注力しています。

RL ループにおける効率性の課題

分散型 RL トレーニングの後の運用は、生成（ロールアウトのサンプリング）と最適化（勾配の更新）を交互に繰り返す、断片的で継続的なサイクルとして機能します。従来のクラウドインフラストラクチャは、継続的で安定した状態のワークロード向けに設計されているため、標準の Kubernetes クラスタでは、この交互のリズムに適応できません。

この構造的なケイデンスは、運用が大規模になると、次の 2 つのような大きなシステム上の非効率性を生み出します。

アイドル状態のアクセラレータ: 各フェーズは順次発生するため、GPU クラスタはライフサイクルの 40～60% の間にわたって、完全にアイドル状態（使用率 0%）になります。トレーナーはサンプリングロールアウトが完了するまでアイドル状態で待機し、サンプラーは勾配の更新と重みの分散中にアイドル状態で待機します。これは、年間で数百万ドル規模の資本の無駄につながる可能性があります。
コンテキストのロックイン: RL トレーニングとサンプラーは、NVIDIA CUDA コンテキストとすべてのデバイスメモリを常駐させておく必要があるため、アイドル状態のフェーズでも、ランタイム全体にわたってアクセラレータの割り当てを保持し続けます。標準的なスケジューラでは、これらの Pod を稼働中の RL ループのフェーズレベルでの状態が交互に変化することに合わせるのではなく、静的でサイロ化された割り当てとして扱います。そのため、非アクティブなフェーズでも貴重なハードウェアがロックされたままになります。

重要なのは、これが単なる同期 RL の問題ではないということです。非同期バリアントでは生成とトレーニングが重複して行われますが、アイドル時間を完全に軽減するわけではありません。生成は RL ループ固有のボトルネックであり、ロールアウトデータが蓄積されるのを待っている間、トレーナーアクセラレータは依然としてリソース不足に陥ります。非同期ジョブがポリシーに沿って実行されるほど、こうしたアイドル状態の時間は増大します。生成とトレーニングのずれを制限するバウンドステイルネスにより、新しいロールアウトの準備が整っていない場合はパイプラインが停止するからです。

協調型タイムスライス（RL ジョブのインターリーブ）のメリット

RL ジョブ中にアクセラレータがアイドル状態になるのを防ぐために、llm-d プロジェクトの協調型タイムスライスでは、ハードウェアがアップストリームフェーズを待機するのではなく、インフラストラクチャが独立した RL ジョブを共有ハードウェアブロックに動的にインターリーブできます。これにより、基盤となるモデルの収束や精度を変更することなく、アクセラレータの総使用率を向上させることができます。

同期 RL のフェーズ境界でジョブ A がアイドル状態になると（または非同期 RL で新しいロールアウトデータ待ちでジョブ A が停止すると）、インフラストラクチャは物理アクセラレータをタイムスライスし、ジョブ B のアクティブなサンプリングフェーズまたはトレーニングフェーズに切り替えます。内部的にこの切り替えは、チェックポイント / 復元として扱われます。ジョブ A のデバイス状態全体がアクセラレータメモリからホスト DRAM にチェックポイントされ、代わりにジョブ B の以前に保存された状態が復元されます。アクセラレータを占有するジョブの状態は常に 1 つだけであるため、フレームワークレベルの干渉やメモリ不足（OOM）障害を発生させることなく、ステップを安全に切り替えることができます。

タイムスライス: アーキテクチャの概要

タイムスライスシステムアーキテクチャは、ワークロードスコープ（アプリケーションロジック）、クラスタスコープ（調整）、ノードスコープ（ハードウェア管理）の 3 つのレイヤで構成されています。

ワークロードスコープのレイヤ（アプリケーションランタイム）ユーザーのコードが実行される場所で、トレーニングループ、推論サーバー、RL フレームワークなどがあります。新たに追加されたのは、タイムスライスクライアントライブラリで、タイムスライスオーケストレーターで 2 つの gRPC API を公開します。1 つはアクセラレータへの排他的アクセスをリクエストする acquire() で、もう 1 つはそれを解放する yield() です。ユーザーは、アクセラレータに触れるフェーズをこれらの呼び出しでラップし、オーケストレータにフェーズの境界を通知します。ML フレームワーク（PyTorch FSDP、vLLM など）や、CUDA コンテキスト、アクセラレータメモリ割り当てなど、他はすべて変更なしで実行されます。

クラスタスコープのレイヤ（制御およびオーケストレーションプレーン）このレイヤは、どのジョブがいつアクセラレータにアクセスできるかを決定します。同じ物理アクセラレータを共有するジョブ（例: 同じ GPU ノードセットでインターリーブする 2 つの RL ジョブ）は、1 つのグループに配置されます。タイムスライスオーケストレーターは、グループごとにロックキューを維持します。ロックキューは、そのグループのアクセラレータへの排他的アクセスを待機しているジョブの順序付きリストです。キューの先頭のジョブのみがロックを保持してハードウェア上で実行され、他のすべてのジョブは acquire() 呼び出しでブロックされた状態で待機します。実行中のジョブが yield() を呼び出すと、オーケストレーターはロックをキュー内の次のジョブに渡し、グループ内のすべてのノードで協調的なコンテキスト切り替えをトリガーします。将来的には、ワークロード配置オプティマイザーがワークロードフェーズパターンをプロファイリングし、互いに補完的なアイドルフェーズのジョブを自動的にペアリングできるようになるため、ユーザーがジョブのグループ化を明示的に指定する必要はなくなります。

ノードスコープレイヤ（ハードウェアとデータプレーンの分離）このレイヤは、各アクセラレータノードでチェックポイントと復元の切り替えを実行します。特権 DaemonSet であるスナップショットエージェントは、オーケストレーターから指示を受け取り、それをハードウェアレベルのオペレーションに変換します。具体的には、アクセラレータプロセスを一時停止し、デバイスの状態をホスト DRAM にシリアル化して、ジョブがアクセスを再開したときに復元します。このエージェントは、プラグイン可能なバックエンドインターフェースを中心に構築されており、最初の実装として cuda-checkpoint が使用されています（今後さらに追加される予定です）。今後のバックエンドでは、より高速なスナップショットメカニズムや、デバイスの状態全体ではなく LoRA アダプタなどの特定のメモリアドレスをオフロードするなどの、より選択的なアプローチが導入される見込みです。エージェント自体は、ベアメタル環境と Slurm 環境向けに Kubernetes の外部でスタンドアロンで動作するように設計されています。

フロー: 全体像

ワークロードが現在のアクセラレータフェーズを終了すると、そのタイムスライスクライアントライブラリはタイムスライスオーケストレーターに対して yield() を呼び出し、アクセスを解放します。オーケストレーターは、グループ内の各ノードのスナップショットエージェントに指示を送信して、コンテキストの切り替えを開始します。エージェントは、譲歩するワークロードのプロセスをフリーズし、そのデバイスの状態をアクセラレータメモリからホスト DRAM に移動します。

アクセラレータが解放されると、オーケストレーターはキューで待機している次のワークロードにグループロックを付与します。それらのノード上のスナップショットエージェントに対して、そのワークロードの以前に保存された状態をホスト DRAM からアクセラレータメモリに復元するよう指示し、その後、ワークロードの保留中の acquire() 呼び出しのブロックを解除します。ワークロードは、コンテナの再起動やフレームワークの再初期化、ストレージからのモデル再読み込みを行うことなく、中断したところから正確に実行を再開します。

譲歩したワークロードは、ホスト DRAM でウォーム状態を維持します。オーケストレータが再びロックを許可すると、スナップショットエージェントは同じ切り替えを逆方向に実行します。

開発者エクスペリエンス（クライアントサイド）研究者は、低レベルの CUDA コンテキスト切り替えやカスタムスケジューリングループに煩わされることなく、コアモデリングロジックに集中したいと考えています。RL ジョブのオーケストレーションに Ray や同様のプラットフォームを使用している場合、タイムスライスを使用してもクライアント側への影響は最小限に抑えられます。実際、プラットフォームレベルでトレーニングジョブとサンプリングジョブを別々にキューイングしている場合は、クライアント側にはまったく影響が及ばない可能性があります。

code_block: <ListValue: [StructValue([('code', 'from timeslice import TimeSliceOrchestratorClient\r\n\r\norchestrator = TimeSliceOrchestratorClient(target="orchestrator:50051")\r\n\r\n@orchestrator.on_accelerators(group_id="trainer-group")\r\ndef train_phase(model, trajectories):\r\n return model.update(trajectories)\r\n\r\n@orchestrator.on_accelerators(group_id="sampler-group")\r\ndef generate_phase(model, prompts):\r\n return model.generate(prompts)\r\n\r\n# Standard sequential loop — interleaved with other jobs under the hood\r\nfor epoch in range(EPOCHS):\r\n trajectories = generate_phase(policy, dataset)\r\n rewards = compute_rewards(trajectories)\r\n train_phase(policy, rewards)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1e8df550>)])]>

現在のリリースと今後の見通し

このたび、タイムスライスのフルスタック（スナップショットエージェント、アクセラレータオーケストレーター、Python クライアントライブラリ）をリリースいたしました。各スタックには、RL ワークロードにタイムスライスを統合するためのユーザーガイドが付属しています。

ロードマップの主なハイライトは次のとおりです。

レイテンシと状態の最適化: より高速なチェックポイント / 復元バックエンドでスナップショットエージェントを拡張し、コンテキスト切り替えのオーバーヘッドを最小限に抑えます。また、アプリケーション対応のバックエンドを使用して、特定のメモリ領域をスナップショットします（例: モデルの重み全体ではなく、LoRA アダプタを切り替え）。
自動スケジューリングとオンボーディング: 実行中のプロセスをプロファイリングし、タイムスライス可能な構造を特定して、ジョブの配置を動的に処理する自動スケジューラを導入します。
ハードウェア間の互換性: データプレーンのサポートを GPU から TPU やカスタムアクセラレータアーキテクチャに拡張します。

使ってみる

堅牢で高度に最適化された RL インフラストラクチャを構築するには、これらのワークロードを大規模に実行するエンジニアや研究者との緊密な連携が不可欠です。

現在課題となっている、トレーニング後のパイプラインでの GPU 使用率の低さ、同期による停止、複雑なスケジューリングロジックは、タイムスライスで解決できます。まずは以下のリソースをご確認いただき、ぜひフィードバックをお寄せください。

これらのユーザーガイドを使用して、RL の実行中にタイムスライスをお試しください。
RL 生成フェーズ中のサンプリングスループットを向上させるには、llm-d-router（Kubernetes ネイティブ）または RL スケジューラ（Python ライブラリ）のユーザーガイドをお試しください。
Weight Propagation Interface のリポジトリをご覧ください。
llm-d Slack の #sig-rl チャンネルでディスカッションにご参加ください。
リファレンス実装、ベンチマーク、エッジケースを共有して、この手法の改善にご協力ください。

このブログ投稿の執筆に協力してくれた Dolev Ish Am と Bogdan Berce に感謝します。

- シニアプロダクトマネージャー、Poonam Lamba

- ソフトウェアエンジニア、Aishu Kamal

GKE における AI サプライチェーンの保護: 自動 AI BOM 対応 k8s-aibom のご紹介

Wed, 29 Jul 2026 01:00:00 +0000

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

セキュリティチームは、シャドー AI にどのように対応すべきでしょうか？デベロッパーが正式に登録せずにデプロイしたワークロードは、多くの場合、従来のセキュリティスキャナを回避できます。特権 DaemonSet、カーネルレベルのアクセス、Pod 仕様の手動編集を求めることで、開発を遅らせて安定性を損なうことに組織が消極的であるためです。

この行き詰まりを打開するため、Google はこのたび k8s-aibom をオープンソース化いたしました。この特権なしの軽量 Kubernetes コントローラは、クラスタ API とコンテナ環境を継続的にモニタリングして、実行中の AI ランタイム（vLLM や Triton など）を自動的に検出し、標準的な CycloneDX Machine Learning Bill of Materials（ML-BOM）を生成します。

k8s-aibom は、ワークロードが正式に登録されているかどうかに関係なく、ランタイム実行から直接、監査に適した可視性を自動的に確保し、デベロッパーに統合の負担をかけることなく AI プロジェクトをパイロットから本番環境に安全に移行できるようチームを支援します。

負担のないアーキテクチャ

k8s-aibom は、総合的な可視性に関する CISO の要件と、クラスタの安定性に関する SRE の要件の両方を尊重するようにゼロから設計されています。k8s-aibom-system Namespace に、特権なしの単一の Deployment としてデプロイされます。デベロッパー側の負担はゼロです。サイドカー、eBPF カーネルモジュール、特権 DaemonSet は不要で、既存のデベロッパー Pod 仕様を変更する必要もありません。

k8s-aibom は AI ワークロードを監視し、BOM を生成します。

検出パイプラインは、次の 4 つの明確な段階を経て実行されます。

クラスタワークロードのスクレイピング: コントローラは、クラスタ全体で KServe リソース、Deployment、StatefulSet、DaemonSet、Job を継続的にモニタリングします。
AI スタックの特定: 高度なパターンマッチングにより、コンテナイメージ、環境変数、コマンドライン引数を検査して、サービングランタイム（vLLM、Triton Inference Server、TGI、Ollama）、自律型エージェントフレームワーク（LangChain、AutoGen、CrewAI）、ベクトルデータベースと RAG ストア（Milvus、Qdrant、pgvector）、分散トレーニングジョブと評価ハーネスを検出します。
標準的なマニフェストの生成: コントローラは、検出されたアーティファクトを正式な OWASP CycloneDX 1.6 Machine Learning Bill of Materials（ML-BOM）ドキュメントにコンパイルします。
シンクへのエクスポート: コントローラは、生成された ML-BOM をクラスタ内の AIBOM カスタムリソース（CR）のカスタムリソースステータス（status.bomDocument）に直接アタッチし、Google Cloud Storage バケットや外部 Webhook エンドポイントなどのオプションの外部シンクにルーティングします。

アプリケーションチームが、Pod 仕様の変更、サイドカーコンテナの挿入、継続的インテグレーションと継続的デリバリー（CI / CD）のパイプラインの変更を行う必要はありません。さらに、k8s-aibom は Kubernetes クラスタの状態を純粋な関数入力として扱うため、同一のクラスタ入力からは、バイト単位で同一の ML-BOM ドキュメントが生成されます。この決定論的プロパティを持つ k8s-aibom は、GitOps ワークフローに最適です。これにより、サイト信頼性エンジニア（SRE）は、AI の依存関係がドリフトしたときに正確な差分を実行し、精密な変更検出アラートをトリガーできます。

既存の AIBOM ツールでカバーできない領域

多くの AI BOM ソリューションはビルド時スキャナを備えており、保存されているアーティファクトから BOM を生成します。これらのツールを使用すると、デプロイする予定だったコードを追跡できます。

商用 AI セキュリティプラットフォームは、クラウドネイティブなポスチャー管理によって可視化できる範囲を拡大しますが、通常はベンダー固有のデータモデルを中心に形成された外部スキャンによってこれを実現します。こうしたツールで、コンプライアンスレビュー担当者、セキュリティ運用（SecOps）チーム、プラットフォームエンジニアが、現在何が実行されているか、どこに接続しているか、アサーションを検証するにはどうすればよいかを把握できることはほとんどありません。

Google は k8s-aibom を、このギャップを埋めるための専用ツールとして構築しました。k8s-aibom は、アーティファクトのスキャンではなく、ライブクラスタの観測から BOM を生成し、ベンダー独自の形式ではなく、より広範な OWASP および Open Source Security Foundation（OpenSSF）サプライチェーンエコシステムと統合する標準準拠の CycloneDX 1.6 ML-BOM を出力します。また、準拠する Kubernetes クラスタで特権なしのコントローラとして実行されるため、既存のビルド時およびポスチャー管理ツールの代わりとなるのではなく、これらを補完するものとなります。

信頼度モデル: 意図と推論の分離

コンプライアンス監査担当者や SecOps エンジニアにとって、未加工のテレメトリーがノイズになることがよくあります。標準的なモニタリングツールは、コンテナが実行中であることを示しますが、AI モデルがプラットフォームエンジニアによって明示的に構成されたのか、実行時に自律スクリプトによって動的に抽出されたのかを証明することはできません。k8s-aibom は、その決定論的な信頼度モデルによってこの曖昧さを解消し、検出されたアセットを明確な階層に分類します。

宣言: ワークロード構成で、顧客またはデベロッパーによって明示的に定義された（例: --model meta-llama/Llama-2-7b など、明示的に渡されたコンテナ引数）。「宣言」の信頼度検出は、人間の明確な意図を表します。
推論: コンテナイメージ、環境変数、実行プロファイルの詳細な検査を通じて、コントローラのパターンマッチングエンジンによって自律的に導出された（例: ^vllm/.* コンテナ署名の特定）。
未解決: アクティブな AI の存在が検出されたが、正確なモデルパラメータ、重み、バージョンを決定論的に確立できないワークロードに適用される。「未解決」の信頼度検出の場合、対象を絞ったセキュリティレビュー向けにワークロードに即座にフラグが付けられます。

この構造化された分類により、コンプライアンスレビュー担当者は、明示的なエンジニアリングの意図と機械の推論を即座に分離し、監査中に揺るぎない信頼の連鎖を確立できます。

不変性と最小権限: 監査に適したセキュリティモデルの構築

侵害されたノードや権限が昇格された管理者によってログや指標が変更、削除、改ざんされる可能性があるため、監査担当者は標準的なオブザーバビリティテレメトリーに対して依然として強い懐疑心を抱いています。k8s-aibom は、厳格な最小権限の分離とデータの不変性をベースにした、監査に適した証拠トレイルを確立します。

このコントローラは、最小限の Identity and Access Management（IAM）Workload Identity にバインドされた専用の Kubernetes サービスアカウントの下で動作します。BOM レコードを外部ストレージシンクに書き込む権限を持つ唯一の ID として機能し、roles/storage.objectCreator 権限のみを必要とします。

Google Cloud Storage の外部シンクの実装では、最も厳格な監査基準と証拠基準を満たすために、オブジェクト作成時に DoesNotExist 事前条件が適用されます。ML-BOM が Cloud Storage バケットに書き込まれると、オブジェクトは暗号化され、変更できなくなります。

侵害されたクラスタアクターや不正なワークロードによって、サイレントに上書き、変更、または遡及的に改ざんされることはありません。SecOps チームは、規制当局に提出された過去の監査ログが、クラスタ実行の変更不可能な記録であることを絶対的に保証できます。

ガバナンス体制の整備の促進: グローバルな規制フレームワークへのマッピング

k8s-aibom は、標準化された CycloneDX 1.6 ML-BOM の生成を自動化することで、低レベルの Kubernetes ランタイム状態と高レベルのガバナンスフレームワークのギャップを直接的に埋めます。また、主要な国際基準に不可欠な基礎的実証データを提供することで、停滞していた GKE AI のデプロイの道を切り拓きます。

EU AI 規則: 組織が第 12 条（継続的なトレーサビリティのための自動ロギングと記録保持）と第 50 条（AI システムの透明性義務）に準拠できるように設計されています。このツールは、サービングランタイムとエージェントスタックを自動的にカタログ化することで、コンプライアンス監査中に必要となる可能性のある技術的証拠の収集を簡素化します。
NIST AI リスク管理フレームワーク（AI RMF）: ガバナンス、マッピング、測定、管理の各機能を実現する、継続的かつ実証的なアセットの可視性がもたらされ、コンプライアンスワークフローを、純粋な手動チェックから、より自動化されたアセットインベントリトラッキングへと移行できます。
ISO/IEC 42001: AI マネジメントシステムのアセットの検出と追跡に関するコンプライアンスの取り組みをサポートし、インベントリの検証における手動のスプレッドシート入力や定期的なスナップショット監査への依存度を低下させます。

ご利用にあたって

k8s-aibom は、CISO、ガバナンス、リスク、コンプライアンスの各チーム、SecOps チーム、プラットフォームエンジニア、デベロッパーに影響を与えるシャドー AI の多面的な問題の軽減に役立つ数少ない技術ソリューションの一つです。

このコントローラの詳細とカスタムリソース定義について、またオープンソースの k8s-aibom プロジェクトにご協力いただける場合は、k8s-aibom GitHub リポジトリをご覧ください。

- グループプロダクトマネージャー、Glen Messenger

GKE で Ray Serve LLM をスケーリング: デベロッパーエクスペリエンスを損なうことなくパフォーマンスを向上

Thu, 09 Jul 2026 00:00:00 +0000

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

LLM 推論とモデルサービングを求めるデベロッパーは、Anyscale が構築した、デベロッパーに優しい Python ネイティブの API を備えたスケーラブルなモデルサービングライブラリである Ray Serve をよく利用します。デベロッパーは、Google Kubernetes Engine（GKE）と組み合わせることで、初期のモデル開発からオンラインの本番環境でのサービングまで、要求の厳しい LLM サービングのユースケース向けに最適化された強力な統合プラットフォームを利用できます。

この柔軟性と機能セットは、以前はパフォーマンスの低下を伴うものでした。しかし現在は、Anyscale とのパートナーシップにより、Ray Serve で最大 5 倍高いスループットと 8 分の 1 のレイテンシを実現しており、使いやすさを犠牲にすることなく、最先端の分散推論の高まる需要と厳格なパフォーマンス要件を満たしています。

ボトルネックなしで推論をスケーリング

共同エンジニアリングパートナーシップを通じて、Ray Serve LLM のパフォーマンス特性を大幅に向上させる 3 つの主要なアーキテクチャ最適化手法を導入しています。

Ray Serve HAProxy インテグレーション: Ray Serve に HAProxy が組み込まれ、内部リクエストのルーティングとロードバランシングを管理できるようになりました。このセットアップにより、プロキシのオーバーヘッドが大幅に削減され、トラフィックが多い場合でも Python ランタイムが飽和状態になるのを防ぐことができます。
直接トークンストリーミングアーキテクチャ: このアーキテクチャでは、初期リクエストパスと戻りストリームが分離されます。トークンは個々のモデルレプリカからプロキシに直接ストリーミングされ、ストリーミングデータパスの Ingress ルーターを完全にバイパスしてレイテンシを短縮します。
vLLM 用の v2 Ray エグゼキュータバックエンド: vLLM 用に改良された Ray バックエンドは、Ray をデータプレーンから移動して非同期スケジューリングを可能にします。これにより、コードパスがネイティブの vLLM エグゼキュータと統合され、パフォーマンスのギャップが解消され、Ray ユーザーが最新のエンジンレベルの最適化を利用できるようになります。

GKE でのパフォーマンスのベンチマーク

また、Anyscale と協力して、NVIDIA HGX B200 システムを搭載した Google Cloud A4 VM など、次世代 AI ハードウェアを利用する GKE クラスタで、更新された Ray Serve LLM のベンチマークを実施しました。オーケストレーションとルーティングによって生じるボトルネックを特定するために、小規模で効率的なモデルである Gemma 4 E2B を実行することにしました。ベンチマークでは、新しい Ray Serve LLM を以前のパフォーマンスと比較したほか、Ray エグゼキュータを使用したプレーンな vLLM セットアップとも比較しました。

これらの技術的強化により、パフォーマンスに大きな影響がもたらされ、以前の Ray Serve 構成と比較して、スループットが最大 5 倍高く、レイテンシが 8 分の 1 になっています。

改善された Ray Serve LLM は、8 つのレプリカを持つサービングクラスタで目覚ましい改善を実証し、以前のパフォーマンスをはるかに上回るスケーリングパターンと、vLLM をネイティブに実行した場合と同等のパフォーマンスを示しましたが、Ray がもたらす柔軟性はありませんでした。

同時ユーザー数が増加するなかで、Ray は 99 パーセンタイルの最初のトークンまでの時間を短く維持しながら、スループットをスケールアップできるようになりました。これは以前は難しかったことです。今では、LLM の実務担当者が、Kubernetes で本番環境レベルのパフォーマンスを実現するために、Ray の豊富な機能とエコシステムを犠牲にする必要はなくなりました。

Ray Serve に GKE を選ぶ理由

GKE は、これらのソフトウェアの最適化を最大限に活かすための基盤となるインフラストラクチャを提供します。GKE 用の Ray オペレーターアドオンを使用すると、自動水平スケーリング、モニタリング、マルチクラスタスケーリング、組み込みのフォールトトレランスなど、Google Cloud AI アクセラレータ全体でターンキーデプロイが実現します。GKE は、分散された物理ハードウェアのオーケストレーションの複雑な部分を抽象化するため、チームは Ray を使用してモデルとアプリケーションロジックの改良に集中できます。

GKE で Ray Serve LLM を試す

デベロッパーの皆様には、最新の Ray リリース（2.56 以降）でこれらの機能強化を試して、GKE での高パフォーマンス LLM サービングの未来を体験することをおすすめします。

詳細については、以下のリソースをご確認ください。

- Google、ソフトウェアエンジニア、Spencer Peterson

- Anyscale、ソフトウェアエンジニア、Seiji Eicher 氏

レポート: GKE Inference Gateway が AI 応答を最大 92% 高速化

Wed, 17 Jun 2026 01:30:00 +0000

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

生成 AI が試験運用から大規模な本番環境へと移行するにつれ、インフラストラクチャの効率が決定的な差別化要因になります。インフラストラクチャを最大限に活用し、コストのかかるアクセラレータのアイドル時間を最小限に抑える方法の一つが、Google Kubernetes Engine（GKE）Inference Gateway の活用です。GKE Inference Gateway は、リアルタイムのモデルサーバー指標に基づいて、生成 AI ワークロードをインテリジェントにルーティングします。

従来の単純なラウンドロビン方式のロードバランシングでは、アクセラレータでのコストのかかる再計算が頻繁に発生し、ユーザーレイテンシが急増することがあります。これに対し、GKE Gateway のネイティブ拡張機能である GKE Inference Gateway は、接頭辞キャッシュやモデル対応ルーティングなどの高度な機能を活用します。すぐに処理できる状態にある適切なアクセラレータにリクエストを確実に送ることで、GKE は大規模言語モデル（LLM）のサービング方法を変革し、優れたハードウェア使用率と極めて高速な応答時間を実現します。

実際、独立したベンチマークレポートによると、GKE Inference Gateway は、次に優れたマネージド Kubernetes サービスと比べて、スループットが 15.7% 高く、待機時間が 92.8% 短く、トークン間レイテンシが 62.6% 低いという結果を示しています。このパフォーマンスにより、LLM ベースのアプリケーションは、低速で高コストなものから、高速で本番環境対応のものへと変わります。

このパフォーマンスは、GKE Inference Gateway を使用した Snap の経験とも一致しています。

「Snap では、大規模で高性能な推論を実現するため、本番環境の AI インフラストラクチャに llm-d を統合しています。接頭辞キャッシュ対応ルーティングを採用することで、最大 75～80% の接頭辞キャッシュヒット率を達成しました。llm-d がオープンソースであることにより、Envoy ベースのサービスメッシュとシームレスに統合できる点を高く評価しています。」- Snap Inc.、ソフトウェアエンジニアリング担当シニアマネージャー、Vinay Kola 氏

このブログ投稿では、GKE Inference Gateway の接頭辞キャッシュについて、例を交えながら詳しく見ていきます。また、ベンチマーク結果の詳細もご紹介します。それでは詳しく見ていきましょう。

低レイテンシ AI の秘訣: 接頭辞キャッシュ

接頭辞キャッシュは、長く繰り返し使用されるプロンプトの接頭辞に対応する KV キャッシュ（アクティベーション状態）を保存することで、LLM のパフォーマンスを最適化します。連続するユーザーリクエストで、同じシステム指示、コンテキスト、ドキュメントが共有される場合、モデルはそれらのトークンの再処理を完全にスキップできます。GKE Inference Gateway は、受信リクエストの接頭辞を読み取り、そのデータをすでにメモリに保持している特定の Pod と照合します。これにより、GPU や TPU にかかる「思考」のコストを排除し、負荷の高い推論ループをほぼ瞬時の回答へと変えることができます。

ユースケース 1: 検索拡張生成（RAG）を使用したドキュメントとコードベースの Q&A

大規模なエンタープライズリポジトリをクエリする場合、RAG を使用してドキュメントセット全体を静的接頭辞としてキャッシュに固定することで、レイテンシを追加することなく、LLM の回答を根拠に基づいたものにできます。

GKE Inference Gateway は、ユーザーから質問があるたびに、数千行に及ぶ API リファレンスや社内 Wiki を LLM に再度読み込ませるのではなく、その特定のコンテキストがすでに KV キャッシュに保持されている Pod にクエリをルーティングします。これにより、LLM はユーザーの短い動的な質問のみを計算すればよく、コストの高いドキュメントの再評価を完全に回避できます。

code_block: <ListValue: [StructValue([('code', '[静的接頭辞 - キャッシュに保持] あなたは技術ドキュメントを専門とする AI アシスタントです。以下は、このソフトウェアプラットフォームの完全な API ドキュメントです。このコンテキストを使用して、ユーザーの質問に正確に回答してください。ドキュメント内に回答が見つからない場合は、「提供されたコンテキストでは見つかりません」と答えてください。\r\n\u200b\r\n<documentation> [10,000 語以上の API リファレンスドキュメント、エンドポイント、エラーコードなど] </documentation>\r\n\u200b\r\n[動的接尾辞 - リクエストごとに変化] ユーザーの質問: Python SDK を使用して 429 レート制限エラーを処理するにはどうすればよいですか？'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1d407550>)])]>

ユースケース 2: マルチターンチャット

接頭辞キャッシュを使用すると、コンピューティングコストを累積的に増やすことなく、数千もの同時セッションにわたってカスタマーサービスのやり取りを維持できます。これは、固定のシステムペルソナと中核的なビジネスルールを LLM サーバーに直接キャッシュ保存することで実現できます。

エンタープライズチャットアーキテクチャでは、基本となるシステムプロンプトと参照テーブルが、数百万件の顧客インタラクション全体で完全に同一のまま維持されます。GKE Inference Gateway は、コンテキスト対応ルーティングを使用してこうしたマルチターンの会話を処理し、繰り返し発生するトークン処理をバイパスします。これにより、トラフィックのピーク時でも chatbot は極めて高い応答性を維持できます。

code_block: <ListValue: [StructValue([('code', '[静的接頭辞 - キャッシュに保持]\r\n- システムペルソナ: あなたは、ABC Banking Solutions の親切で共感力があり、コンプライアンスに準拠した仮想アシスタント「FinBot」です。次のルールを厳守してください。1. 具体的な投資助言は決して提供しないでください。2. ユーザーが当座預金口座について質問しているのか、貯蓄口座について質問しているのかを必ず確認してください。3. 回答は 3 文以内にしてください。4. ユーザーが怒っている場合は、人間のマネージャーにつなぐことを提案してください。\r\n\u200b\r\n2026 年 5 月時点の金利表は次のとおりです。\r\n- 貯蓄口座: 年利 4.2%\r\n- 当座預金口座: 年利 0.5%\r\n- CD（12 か月）: 年利 5.1%\r\n\u200b\r\n[動的接尾辞 - リクエストごとに変化] ユーザー: 10,000 ドルを 1 年間預けた場合、いくら受け取れるのか知りたいのですが。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1d407310>)])]>

GKE は他のマネージド Kubernetes ソリューションを上回るパフォーマンスを発揮

こうしたアーキテクチャ上の利点を検証するため、Principled Technologies は先日、GKE Inference Gateway を搭載した GKE と、従来のラウンドロビン方式の HTTP ロードバランシングを使用する標準的なサードパーティのマネージド Kubernetes サービスを比較した、独立したベンチマークレポートを公開しました。

同一のハードウェア（8 基の NVIDIA A100 40GB GPU）を使用し、Llama 3.1 8B Instruct の共有接頭辞ワークロードでテストした結果、2 つの Kubernetes サービスの間に大きなパフォーマンス差があることが明らかになりました。GKE は単に優位性を示しただけでなく、次の 3 つの重要な指標すべてにおいて推論効率のあり方を大きく変えました。

スループットの向上: 1 秒あたりに処理されるトークン数が 15.7% 増加し、リクエスト処理能力を高めることができます。また、同じワークロードに必要なハードウェアを削減することも可能です。
最初のトークンまでの時間（TTFT）の大幅な短縮: 待機時間が 92.8% 短縮され、インタラクティブなシナリオで、応答が始まるまでの体感時間を大幅に短縮できます。
トークン間レイテンシ（ITL）の低減: 62.6% の低減により、最初のトークン以降のトークンストリーミングがよりスムーズかつ高速になります。

図 3: 共有接頭辞のユースケースにおける Llama 3.1-8B Instruct LLM での、GKE Inference Gateway を使用した GKE とサードパーティのマネージド Kubernetes サービスの平均レイテンシ（出力トークンあたりの正規化時間）。どちらのソリューションも同じハードウェアを使用しました。出典: Principled Technologies

	GKE	サードパーティのマネージド Kubernetes サービス	GKE の利点
平均出力トークンスループット	7,169.21 出力トークン/秒	6,042.05 出力トークン/秒	出力トークンスループットが 15.7% 向上
最初のトークンまでの平均時間（TTFT）	188.36 ミリ秒	2624.73 ミリ秒	TTFT が 92.8% 短縮
平均トークン間レイテンシ（ITL）	30.20 ミリ秒	81.03 ミリ秒	ITL が 62.6% 低減

図 4: GKE Inference Gateway を使用した GKE は、標準的な HTTP ロードバランサを使用するサードパーティのマネージド Kubernetes サービスと比較して、優れた AI 推論パフォーマンスを実現しました。

生成 AI 推論ワークロードを加速させる準備はできていますか？

リアルタイムのカスタマーサポートエージェント、動的なコーディングアシスタント、サブ秒単位の不正検出モデルなどの推論ワークロードをデプロイする場合、インフラストラクチャのレイテンシがユーザーエクスペリエンスを左右します。GKE Inference Gateway は、共有プロンプトの接頭辞がアクティブキャッシュにほぼ 100% ヒットするようにすることで、LLM を低速で高コストな推論エンジンから高速で資本効率に優れた本番環境対応の強力な基盤へと変えます。

GKE Inference Gateway が生成 AI ワークロードにもたらすパフォーマンス上の優位性を確認してみませんか？ベンチマークレポートの全文はこちらからご覧いただけます。また、詳細については、こちらの解説動画をご覧ください。

Principled Technologies のシニアパフォーマンスアーキテクトである Dan Sullivan 氏に感謝いたします。

- ソフトウェアエンジニア、Bob Tian

- アウトバウンドプロダクトマネージャー、Susan Wu

GKE スタンバイバッファの概要: 予算を抑えながらノードの起動時間を短縮

Fri, 12 Jun 2026 01:00:00 +0000

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

アプリケーションオーナーやプラットフォームエンジニアは、長い間、難しい選択を迫られてきました。それは、オーバープロビジョニングに過剰な費用をかけて迅速な起動を保証するか、費用を最小限に抑える代わりに起動に時間がかかる「コールドスタート」に耐えるか、という選択です。

このたび、この問題を解決するソリューションとして、Google Kubernetes Engine スタンバイバッファの提供を開始いたします。これは、今年初めにリリースした GKE アクティブバッファを基盤としています。GKE アクティブバッファは、Kubernetes CapacityBuffers API のネイティブバージョンであり、すぐに利用できる容量を簡単にプロビジョニングすることでトラフィックの急増に対処できるほか、新しい Pod の起動にかかるレイテンシをほぼゼロにすることができます。しかし、アクティブバッファには、パフォーマンスと費用のトレードオフが生じるという課題が依然として存在していました。新しい GKE スタンバイバッファは、GKE クラスタ用に低コストの一時停止された容量バッファを維持することで、この課題を解決します。GKE スタンバイバッファを利用すると、費用オーバーヘッドを 1 桁台前半という無視できるレベルに抑えつつ、ワークロードのスケジューリングをほぼ即座に実現できます。これは、汎用ワークロード、エージェント型ワークロード、その中間的なものなど、あらゆる種類のワークロードに有用です。

トラフィック負荷が同一の場合、スタンバイバッファのないクラスタではレイテンシが急激に上昇し、P50、P95、P99 の各指標が 4～6分で推移しました。一方、スタンバイバッファのあるクラスタでは、P50 レイテンシはわずか数秒に抑えられ、P95 と P99 の指標は一時的に 1 分まで上昇したものの、すぐに数秒へと正常化しました。どちらの構成も割り当て可能なコアコストはほぼ同じであり、バッファリング方式の方がはるかに効率的でした。

問題: 高いコストとレイテンシ

従来、標準的な Kubernetes による自動スケーリングは効果的ではありましたが、処理速度が遅いという課題がありました。トラフィックの急増やバッチジョブが発生すると、クラスタのオートスケーラーが新しいノードをプロビジョニングする必要があるため、Pod は保留状態になります。この遅延を防ぐには、HorizontalPodAutoscaler（HPA）のしきい値を下げる、あるいは、Balloon Pod で管理するといった、費用のかかる煩雑な回避策に頼るしかありませんでした。

Balloon Pod の管理は運用が複雑であり、正しく機能させるには、優先度クラスやリソースリクエストを手動で構成し、継続的にメンテナンスする必要がある。
HPA のしきい値を下げると、ノードプールのサイズに比例して空き（無駄な）スペースが増加する。

GKE のアクティブバッファとスタンバイバッファの両方を利用すると、容量を宣言的に定義できるようになるため、こうした煩雑で運用上の負担が大きい回避策は不要になります。

さらに、GKE スタンバイバッファでは、ノードの状態がディスクに保存されるためインフラストラクチャ費用を削減できます。これにより、コンピューティングとメモリの費用を削減して、永続ディスクと IP アドレスの費用のみを維持できます。また、アクティブバッファと組み合わせることで、オーバープロビジョニングと同等のパフォーマンスを実現しながら、非常に手頃な価格で、ほぼ瞬時の Pod スケジューリングが可能になります。

GKE キャパシティバッファの概要 - 低レイテンシの Pod スケジューリングを実現するネイティブ Kubernetes の方法

アクティブバッファとスタンバイバッファの連携

すべての GKE キャパシティバッファは、YouTube などのプラットフォームにおける動画ストリーミングと同様の原理で動作します。GKE は、差し迫った需要に先立って利用可能な容量をプロアクティブにプロビジョニングおよび管理することで（動画コンテンツの事前ダウンロードのように）、必要なときにリソースを確実に利用できるようにします。

今回のリリースにより、この 2 種類のキャパシティバッファを連携できるようになりました。

アクティブバッファ: クラスタオートスケーラーが、既存のクラスタノード上で事前定義された数の Pod に対応する十分な容量を確保し、必要に応じて追加のノードをプロビジョニングします。レイテンシの影響を受けやすいワークロードの容量を確保する場合は、このすぐに使用できるバッファを選択します。
スタンバイバッファ: ノードは事前にプロビジョニングされ、Kubernetes DaemonSet などの必要なコンポーネントで完全に初期化されます。イメージをプリロードする時間が確保されますが、その後は一時停止されます。その間、基盤となるコンピューティング容量は解放されて費用が節約されます。需要が急増すると、これらのノードは新しいノードを作成するよりも 2～3 倍速く再開され、コールドスタートと常時利用可能な容量とのギャップを埋めます。

アクティブバッファは、スタンバイバッファが再開されるまでの初期の需要急増をカバーします。システムは、スタンバイバッファからアクティブバッファへの補充を優先します。スタンバイバッファは負荷の増加に対応し、ノードのコールドスタートによる遅延を防ぎます。スタンバイバッファが補充されると、まず構成可能な時間だけアクティブ状態になり、その後一時停止されます。これにより、トラフィック負荷が持続している間、アクティブな容量が増加します。

初期ベンチマーク

Google のテストでは、スタンバイバッファを使用することで、完全なオーバープロビジョニングと比較して最大 90% の費用削減を実現しつつ、Agent Sandbox のスケジュール設定のレイテンシを 1 秒未満に抑えることができました。

ビジネスニーズに合わせて最適化

多くの企業は、業務を合理化しながらリソース消費を最適化するという絶え間ないプレッシャーにさらされています。Google は、散発的に急増するワークロードの管理には、よりスマートなツールが必要であることを認識し、スタンバイバッファを早急に提供できるよう取り組んできました。エージェント、バッチジョブ、CI/CD パイプライン、ゲームサーバー、急激に変動するワークロードなどの実行に、GKE のキャパシティバッファを使用することで、パフォーマンスと費用のバランスを動的に調整できるほか、トラフィックの急増に対する「保険」を、高額な保険料を支払うことなく定義できます。GKE スタンバイバッファを使用すると、以下のことが可能になります。

コールドスタートの回避: スタンバイバッファによって一時停止されたノードは、新しいノードをプロビジョニングする場合に比べて 2～3 倍速く再開されるため、トラフィックの急増時や持続的な負荷の下での Pod スケジューリングレイテンシが短縮されます。
費用削減: スタンバイバッファでは基盤となる VM が一時停止状態になるため、アクティブ容量に比べて大幅に低コストです。コンピューティング時間全体ではなく、ストレージと IP アドレスの費用を支払うことになります。
宣言型コントロールの実現: 複雑な Balloon Pod による回避策を、シンプルでネイティブな宣言型 CapacityBuffers API に置き換えます。必要な容量を明示的に指定するだけで、残りの処理は GKE に任せることができます。

「GKE スタンバイキャパシティバッファを使用することで、非常に手頃な価格で、準備完了までの時間を数分から 30 秒に短縮できました。」
- Unico、チーフアーキテクト、Pedro Spagiari 氏

- Unico、チーフアーキテクト、Pedro Spagiari 氏

使ってみる

パフォーマンス向上と費用削減に向けて踏み出しましょう。

まず、クラスタに CapacityBuffer リソースを定義し、目標とするバッファサイズを指定します。
持続的な負荷に対する Pod スケジューリングレイテンシを短縮し、予測不可能な即時の容量ニーズに対応できるよう、スタンバイバッファとアクティブバッファのバランスを取ります。

例として、カスタム ComputeClass を使用しながら Deployment のバッファを構成する方法を見てみましょう。

基本設定

まず、基本設定として Namespace を作成します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: v1\r\nkind: Namespace\r\nmetadata:\r\n name: my-namespace'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1ec88450>)])]>

次に、カスタム ComputeClass を作成します（省略可）。

code_block: <ListValue: [StructValue([('code', 'apiVersion: cloud.google.com/v1\r\nkind: ComputeClass\r\nmetadata:\r\n name: my-ccc\r\n namespace: my-namespace\r\nspec:\r\n # バッファもこれらの優先順位に従って作成される\r\n priorities:\r\n - machineFamily: n4\r\n - machineFamily: n4d\r\n - machineFamily: c4\r\n - machineFamily: c4d\r\n nodePoolAutoCreation:\r\n enabled: true'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1ec8ae50>)])]>

バッファユニットのサイズを定義する

PodTemplate をバッファユニットのサイズの基準として使用できます。また、特定の Deployment や scale subResource を定義する任意のオブジェクトに対してバッファを作成することもできます。

code_block: <ListValue: [StructValue([('code', '# バッファの 1 ユニットに対するリソース要件を定義する\r\napiVersion: v1\r\nkind: PodTemplate\r\nmetadata:\r\n name: my-buffer-unit-template\r\n namespace: my-namespace\r\ntemplate:\r\n spec:\r\n terminationGracePeriodSeconds: 0\r\n tolerations:\r\n # 省略可: バッファ Pod が任意のノードに配置されるようにする\r\n - key: "node-role.kubernetes.io/master"\r\n operator: "Exists"\r\n effect: "NoSchedule"\r\n containers:\r\n - name: buffer-container\r\n image: registry.k8s.io/pause:3.9\r\n resources:\r\n requests:\r\n cpu: "1"\r\n memory: "1Gi"\r\n limits:\r\n cpu: "1"\r\n memory: "1Gi"\r\n # 省略可: カスタム ComputeClass でバッファを使用する / \r\n # GKE がプロビジョニングするノードのプロパティを制御する\r\n nodeSelector:\r\n cloud.google.com/compute-class: my-ccc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1ec8a1d0>)])]>

バッファを作成する

最後に、PodTemplate を参照して CapacityBuffer オブジェクトを作成します。ここでは、50 個の CPU と 50 GB の RAM のスタンバイバッファを作成します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: autoscaling.x-k8s.io/v1beta1\r\nkind: CapacityBuffer\r\nmetadata:\r\n name: my-standby-buffer-resource-limits\r\n namespace: my-namespace\r\n annotations:\r\n # 省略可: バッファノードが一時停止されるまでの時間\r\n # デフォルトは 5 分\r\n buffer.gke.io/standby-capacity-init-time: "5m"\r\n # 省略可: スタンバイバッファが再作成されるまでの時間\r\n # デフォルトは 1 日、「never」にすると更新されない\r\n buffer.gke.io/standby-capacity-refresh-frequency: "1d"\r\nspec:\r\n podTemplateRef:\r\n name: my-buffer-unit-template\r\n # 望ましい状態はスタンバイバッファが 20 ユニット\r\n # スタンバイバッファが使用されると新しいバッファが作成される\r\n limits:\r\n cpu: "50"\r\n memory: "50Gi"\r\n provisioningStrategy: "buffer.gke.io/standby-capacity"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1ec8bc90>)])]>

（省略可）アクティブバッファの例: 5 個の CPU と 5 GB の RAM

code_block: <ListValue: [StructValue([('code', 'apiVersion: autoscaling.x-k8s.io/v1beta1\r\nkind: CapacityBuffer\r\nmetadata:\r\n name: my-active-buffer-resource-limits\r\n namespace: my-namespace\r\nspec:\r\n podTemplateRef:\r\n name: my-buffer-unit-template\r\n # 望ましい状態はアクティブバッファが 2 ユニット\r\n # アクティブバッファが使用されると新しいバッファが作成される\r\n limits:\r\n cpu: "5"\r\n memory: "5Gi"\r\n provisioningStrategy: "buffer.x-k8s.io/active-capacity"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1ec8bf90>)])]>

最後に、上記のオブジェクトをクラスタに適用します。これで設定は完了です。

バッファによって予約されたスペースでスケジュールできる既存および将来の Deployment は、Pod スケジューリングレイテンシの短縮によるメリットを享受できます。

バッファをテストする

以下の方法でバッファのステータスを確認できます。Kubernetes では、一時停止されたノードは Suspended という条件で識別できます。

code_block: <ListValue: [StructValue([('code', 'kubectl get nodes -o custom-columns=\'NAME:.metadata.name,SUSPENDED:.status.conditions[?(@.type=="Suspended")].status\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1ec88850>)])]>

以下のような出力が表示されるので、スタンバイバッファが一時停止されるまで待ちます。

code_block: <ListValue: [StructValue([('code', 'NAME SUSPENDED\r\ngke-my-cluster-nap-n4-standard-8-k960-...-ffbx False # ノードが再開されました。\r\ngke-my-cluster-nap-n4-standard-4-k960-...-h2x4 <none> # ノードは一時停止されませんでした。\r\ngke-my-cluster-nap-n4d-standard-8-1cip-...-74jf True # ノードは一時停止されています。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1dbddcd0>)])]>

バッファをテストするには、Deployment を作成してスケールします。

code_block: <ListValue: [StructValue([('code', 'apiVersion: apps/v1\r\nkind: Deployment\r\nmetadata:\r\n name: my-deployment\r\n namespace: my-namespace\r\nspec:\r\n replicas: 1\r\n selector:\r\n matchLabels:\r\n app: my-deployment\r\n template:\r\n metadata:\r\n labels:\r\n app: my-deployment\r\n spec:\r\n containers:\r\n - name: busybox\r\n image: busybox\r\n command: ["sleep", "inf"]\r\n resources:\r\n requests:\r\n cpu: "500m"\r\n memory: "500Mi"\r\n # 省略可: カスタム ComputeClass でバッファを使用する /\r\n # GKE がプロビジョニングするノードのプロパティを制御する\r\n nodeSelector:\r\n cloud.google.com/compute-class: my-ccc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbf1dbde110>)])]>

この Deployment を 2 つのレプリカにスケーリングすると、それらはアクティブバッファに割り当てられ、即座にスケジューリングされます。その後、アクティブバッファは、スタンバイバッファからすぐに補充されます。同時に、スタンバイバッファは新しいノードのプロビジョニングを開始します。

この Deployment をさらに 50 個のレプリカにスケールすると、ノードが再開されたときに、すべてのレプリカがスタンバイバッファにスケジュールされます。スタンバイバッファを補充するためにプロビジョニングされた新しいノードは、短時間だけアクティブバッファとして機能し、一時的にスタンバイ能力を増強します。したがって、この間に、この Deployment を 100 個のレプリカにさらにスケールすると、新しいレプリカが即座にスケジューリングされるメリットをより実感できるかもしれません。

GKE スタンバイバッファのベストプラクティス

GKE スタンバイバッファを使用する際は、以下の点を考慮してください。

想定される負荷の増加を十分にカバーできるサイズのスタンバイバッファを定義し、コールドスタート時でもバックグラウンドでバッファが補充されるようにします。十分なサイズのスタンバイバッファがあれば、Pod のスケジューリングにおける最大レイテンシを、ノードの再開にかかる時間（約 30 秒）まで短縮できます。
バッファが使用され始め、補充されると、新しいバッファノードは一時停止する前に、まずアクティブ状態になります。これにより、負荷が長期間続く間、アクティブな容量を増やすことができます。
アプリケーションで可能な限り低い Pod スケジューリングレイテンシが必要な場合は、スタンバイバッファのノードが再開できるまでに発生すると想定される、初期のトラフィック急増をカバーするのに十分なアクティブバッファサイズを定義します。システムは、スタンバイバッファを消費することでアクティブバッファの補充を優先します。十分なサイズのアクティブバッファとスタンバイバッファを確保することで、オーバープロビジョニングに比べて大幅な低コストを実現できるほか、Pod スケジューリングレイテンシも短縮できます。
ワークロードに適した結果が得られるまで、さまざまなバッファサイズを試すことを推奨します。

参考までに、パフォーマンス目標を達成するために必要なバッファサイズを見積もることができるシミュレータをご用意しました。https://github.com/gke-labs/buffers-simulator から入手してご利用ください。

まとめ

GKE のアクティブバッファとスタンバイバッファは、ウォーム状態とスタンバイ状態のキャパシティバッファを維持することで、低レイテンシかつ費用対効果の高いワークロードスケーリングを実現するネイティブなソリューションです。低速なノードのコールドスタートを回避することで、パフォーマンスが重要なアプリケーションにおいて突発的なトラフィックの急増に対処できるようになります。また、Balloon Pod のような複雑な手動の回避策を、シンプルで宣言的な API に置き換えることができるほか、固定、割合ベース、またはリソース上限ベースのバッファリング戦略によって、ピーク時のオーバープロビジョニングを行うことなく、費用対効果の高い方法で厳格なサービスレベル目標を維持できます。

スタンバイバッファは、バージョン 1.36.0-gke.2253000 以降を実行している GKE クラスタで利用できます。バッファの使用を開始するには、こちらのドキュメントをご覧ください。

- Google Kubernetes Engine、プロダクトマネージャー、Eyal Yablonka

- Google Kubernetes Engine、スタッフソフトウェアエンジニア、Konrad Kurdej

GKE 上の Agent Sandbox の一般提供開始のお知らせと Agent Substrate のご紹介

Fri, 29 May 2026 03:00:00 +0000

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

AI は、単純なチャットインターフェースから、関数呼び出し、コード実行、持続的なターミナル使用が可能な自律型エージェントへと短期間で変化しました。しかし、これらの機能を安全にオーケストレートするには、エージェントにインテリジェンスだけでなく、コードを実行するための堅牢かつ安全でスケーラビリティに優れたコンピューティング環境も必要となります。

2025 年 11 月の KubeCon NA で GKE Agent Sandbox のプレビュー版を発表後、コミュニティでの導入は急速に進みました。Google Kubernetes Engine（GKE）上のサンドボックス数は 5 か月足らずで 16 倍以上に増加しました。

Google の主要なお客様である Langchain と Lovable をはじめ、その他多くのお客様が、数百万のエージェントを迅速に本番環境にデプロイしています。Agent Sandbox は、その発表以来、新しいプロジェクトから、安定した API を備えた成熟したプロダクトへと急速に進化しました。この安定性により、現在はより広範なエージェントエコシステムへの統合が促進され、重要なインフラストラクチャレイヤとして機能するようになっています。

この投稿では、この勢いをさらに加速させる次の 2 点についてお知らせします。

GKE Agent Sandbox の一般提供開始。これは、エージェントワークロードのための安全でスケーラブルな基盤となります。
新しいオープンソースプロジェクト、Agent Substrate のご紹介。これはエージェントインフラストラクチャの密度を限界まで高めることを目的としたものです。

安全で低レイテンシの実行を大規模に実現する

Agent Sandbox は、Kubernetes 上に構築されたオープンソースのクラウドネイティブな実行環境であり、AI エージェント固有のニーズに特化して設計されています。ビルダーが独自のインフラストラクチャ上で、信頼できないロジックを、業界最高水準のスピードと効率性で安全かつ確実に実行できるよう支援する基盤のインフラストラクチャを提供します。

今回のリリースでは、最新のエージェントワークロードの主な要件に対応します。

Pod スナップショットでアイドル状態のコンピューティングを削減: エージェントは、バースト性の高い短いサイクルの後に長いアイドル期間が続くことがよくあります。GKE Agent Sandbox は、エージェントの実行を続けるために貴重なコンピューティングリソースを無駄にしないために、Pod スナップショットと統合してアイドル状態のエージェントワークロードを一時停止し、リクエストに応じて数秒で再開します。
低レイテンシのサンドボックスプロビジョニング: リクエストごとに新しいサンドボックスインスタンスを初期化していると、数秒のコールドスタートレイテンシが不必要に発生します。GKE Agent Sandbox には、ウォームプールが統合された Sandbox API が採用されています。Agent Sandbox API に統合されたこのウォームプールにより、GKE はクラスタごとに 1 秒あたり 300 個のサンドボックスを 1 秒未満のレイテンシで割り当てることができ、割り当ての 90% が 200 ミリ秒以内に完了します。
費用対効果の高いウォームプール: GKE Agent Sandbox のウォームプールでは、サンドボックスの起動レイテンシを最小限に抑えるために、事前プロビジョニングされたレプリカが常に準備されています。サンドボックスウォームプールの維持費用を最小限に抑えるため、Agent Sandbox はスタンバイ容量バッファ（一時停止された VM）と統合され、一時停止されたサンドボックスのコールドプールから、わずかな費用で迅速にウォームプールを補充できるようになっています。
堅牢なセキュリティと分離: Agent Sandbox は gVisor とデフォルト拒否の Kubernetes ネットワークポリシーにネイティブに対応しています。Agent Sandbox は、Kata Containers などのオープンソースサンドボックス用のプラグ可能なインターフェースを提供しているため、ユーザーはカーネルの分離をカスタマイズできます。

コンピューティングの需要が高まり続けるなか、このリリースにより、お客様は幅広い Google Cloud コンピューティングオプションを利用できるようになります。GKE Agent Sandbox は、Axion プロセッサで実行した場合、同等のハイパースケーラークラウドプロバイダと比較して最大 30% 優れたコストパフォーマンスを実現します。

エージェントインフラストラクチャにおける次の革新的な一歩: エージェント型ワークロードは、数千万から数億のインスタンス数にスケールアップしながら、それと同時に、人間による操作、イベント、トリガーを待ってアイドル状態になることが増えています。こうしたワークロードでは、引き続きカーネルとネットワークの強力な分離が求められるため、高密度なスケジューリングが課題となっています。このレベルのスケールと迅速な一時停止と再開への対応により、Kubernetes コントロールプレーンは限界に達しています。そのため、Google は、超大規模エージェントのパフォーマンスと密度に関するニーズに対応することを目的とした新しいオープンソースプロジェクトである Agent Substrate をスタートさせました。

Agent Substrate は、準備されたコンピューティング容量（もちろん Kubernetes で実行）にリアルタイムでエージェントを移動させたり、そこから別の場所に移動させたりする新しいレベルの抽象化を採用しています。Agent Substrate は、Agent Sandbox のコアとなる安全なランタイム機能とスナップショット機能を、Kubernetes の一部の制限を回避するように設計された最小限のコントロールプレーンと組み合わせるもので、それ以外の部分は変わりません。

これにより、Agent Substrate はクリティカルパスを最適化して、より高いスケールと効率でレイテンシを低減できます。標準の Kubernetes は数千の長時間実行サービスを処理するように最適化されていますが、Agent Substrate は、標準のコントロールプレーンでは処理しきれない、数百万に及ぶ 1 秒未満のツール呼び出し向けに設計されています。Agent、Agent Harnesses、そして新しい Agent Executor プロジェクトを含む Agent Runtime に最適な基盤となります。

Agent Substrate の目標は、より迅速な移動と、より大きなスケールのために、あらゆる可能性を模索することです。このレベルのスケールと効率性を実現するには、現在のコンピューティングインフラストラクチャの限界を押し広げる必要があり、あらゆる可能性を検討する必要があります。その一つとして、スケジューラの中核にデータの局所性を組み込み、エージェントの状態とスケジューリングを連携させて、オーバーヘッドをミリ秒単位で可能な限り削減する取り組みがあります。

オープンな環境で未来を築く

Kubernetes の初期には、同様の課題に取り組む多様なコントリビューターからのフィードバックと視点が、プロジェクトを成功に導くために不可欠でした。エージェントインフラストラクチャも同様の転換点にあると Google は考えています。これから、徹底的にオープンで共同的なイノベーションの威力を再現し、エージェントインフラストラクチャの未来を共に築いていきたいと願っています。オープンな環境で Agent Substrate プロジェクトを始動させることで、コミュニティの皆様に、この重要な次世代のインフラストラクチャの設計と構築へのご協力をお願いしたいと思います。

使ってみる

自律型エージェントの未来に向けて、スタックの重要なレイヤの構築を継続できることを嬉しく思います。ぜひ Agent Sandbox をワークロードにご活用ください。また、オープンソースコミュニティに参加して、エージェントネイティブインフラストラクチャの次のフェーズとなる Agent Substrate でコラボレーションしましょう。

GKE で Agent Sandbox を試す
Agent Sandbox のオープンソースコミュニティに参加して協力する
Agent Substrate を確認する

- GKE プロダクトマネージャー Brandon Royal

- GKE ソフトウェアエンジニア Tim Hockin

GKE のノード起動が高速化され、コールドスタートレイテンシが解消

Wed, 20 May 2026 01:00:00 +0000

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

このたび、クラウドインフラストラクチャにおける最も厄介な問題の一つであるコールドスタートレイテンシを解決する Google Kubernetes Engine（GKE）の重要なアップデートをリリースしました。GKE の以前のバージョンと比べると、対象となるノードの起動時間が最大 4 倍高速になるため、お客様は迅速かつ効率的にプロビジョニングができます。設定の切り替えや、構成ファイルへのパッチ適用は必要ありません。インフラストラクチャのプロビジョニング方法がアーキテクチャ上でアップグレードされるため、何も操作を行わなくてもノードが高速で起動します。これは、クラウド運用のアジリティと費用効率の向上に直結し、AI 推論用のモデルの迅速なデプロイから、アクセラレータノードと汎用ノードの動的なスケーリングまで、幅広いユースケースに大きく影響します。

今回取り組んだ問題:「コールドスタート」の負担

ご存じのように、需要が変動するワークロード、特に AI 推論やバッチ処理を実行している場合、新しいノードのスピンアップを待つのは苦痛です。需要が急増すると、オートスケーラーがノードをリクエストします。その後、しばらく待ちます。この待機時間と、それによってユーザーに生じるレイテンシを回避するために、多くのチームは「万が一に備えて」高価なノードを稼働させ続ける、オーバープロビジョニングに頼っています。この場合、起動の遅延に対する保険として、アイドル状態のコンピューティングに対して料金を支払うことになります。この保険は、希少なアクセラレータの場合に特に高額になります。

解決策: ノードプロビジョニングの完全な再構築

この問題に対処するため、VM と GKE ノードのプロビジョニングロジックを再構築しました。大まかに言うと、インテリジェントなコンピューティングバッファ、特別に設計された高速起動の仮想マシン、VM を再起動せずに即座にサイズ変更できる新しいコントロールプレーンアーキテクチャを組み合わせて使用しています。技術的な詳細は複雑ですが、お客様にとってのメリットはシンプルです。GKE クラスタのスケーリングが本質的に高速かつ効率的になり、貴重なリソースを必要な場所にシフトできるようになりました。

影響

オーバープロビジョニングの削減: ノードがより高速でオンラインになるため、オートスケーラーのリアルタイムでの対応を信頼でき、アイドル状態のノードのバッファを維持する必要がなくなります。
AI 推論の改善: GPU で実行されるモデルの場合、ノードのプロビジョニングが高速化されることで、リクエストの急増からモデル提供のトラフィックまでの時間が短縮されます。
「運用」のオーバーヘッドなし: これは自動的に機能し、利用するために Terraform ファイルや YAML ファイルを変更する必要はありません。

対象

現在、プロビジョニングの高速化は、以下のハードウェアを使用して GKE Autopilot で実行されるワークロード（Standard クラスタ内で実行される Autopilot ワークロードを含む）でご利用いただけます。

以下を含むその他のマシンにも近日中に展開される予定です。今後の情報にご注目ください。

試す方法

対象のインスタンスタイプで GKE Autopilot をすでにご利用の場合は、この改善にお気づきかもしれません。

GKE Standard クラスタを実行している場合は、クラスタ全体を移行することなく、これらのワークロードに Autopilot をご利用いただけます。Pod で Autopilot ComputeClass を指定するだけで、Pod は Standard ノードと共存しながら、この起動速度を継承します。

高速起動ノードに関する技術ドキュメントの全文はこちらをご覧ください。

次のステップ

以下のリソースで、これらの新たな改善点を活用してワークロードの応答性を向上させる方法をご確認ください。

- Google Cloud、プロダクトマネージャー、Eyal Yablonka

- Google Cloud、プリンシパルソフトウェアエンジニア、Karen Aleksanyan

Containers & Kubernetes

ZenteiQ、llm-d を搭載した GKE Inference Gateway でバッチ推論のスループットを 4 倍に拡大

AI インフラストラクチャとオーケストレーションに関する最新情報

プロダクト、テクノロジー、ツールに関する最新情報

実践ガイドとハウツー

お客様とパートナーに関する最新情報

調査、レポート、詳細解説

2026 年 8 月

プロダクト、テクノロジー、ツールに関する最新情報

実践ガイド、ドキュメント、ハウツー

お客様とパートナーに関する最新情報

2026 年 7 月

プロダクト、テクノロジー、ツールに関する最新情報

実践ガイドとハウツー

調査、レポート、詳細解説

2026 年 6 月

プロダクト、テクノロジー、ツールに関する最新情報

実践ガイドとハウツー

調査、レポート、詳細解説

お客様とパートナーに関する最新情報

2026 年 5 月

プロダクト、テクノロジー、ツールに関する最新情報

調査、レポート、詳細解説

お客様とパートナーに関する最新情報

GKE CPU 起動ブースト: オーバープロビジョニングなしでアプリの起動を高速化

最新のアプリケーションが起動時に追加の CPU を必要とする理由

仕組み: Kubernetes のインプレース Pod サイズ変更

CPU 起動ブーストの仕組み（Pod ライフサイクルの概要）

前提条件と提供状況

スタートガイド: CPU 起動ブーストを構成する

例 1: 固定定常状態での Pod レベルのブースト（updateMode: "Off"）

例 2: 起動ブーストと継続的な VPA 自動スケーリングの組み合わせ

クラスタでの起動ブーストの確認

本番環境ワークロードのベスト プラクティス

使ってみる

AI21、AI Hypercomputer の導入により AI ワークロードの起動時間を 83% 短縮

高使用率クラスタの行き詰まり

適切なスケジューラの選択

オープンソースとのフィードバックループの確立

同じフリートで、よりスムーズに

GKE の弾力性がさらに向上: ゼロへのスケーリング、費用削減、ワークロードの応答性維持

進化: HPA ベースのゼロへのスケーリングと KEDA

仕組み: AutoscalingMetric と KEP-2021 を使用した HPA

最初の「ゼロへのスケーリング」ワークロードの構成

キャパシティ バッファによる起動レイテンシの管理

今後について

ゼロへのスケーリングを今すぐ始めましょう

45 倍高速な GKE Agent Sandbox でエージェント型 RL と評価研究を加速

現実世界におけるエージェント型 RL インフラストラクチャの課題

RL 向けに最適化された GKE Agent Sandbox

ベンチマーク: アイドル状態のアクセラレータのロスを削減

トレードオフ

ご利用開始

マルチクラスタ GKE Inference Gateway で 1% 未満のオーバーヘッドでグローバル AI ルーティングを実現

3 つのリージョン、1 つのエンドポイント

リージョン間の線形スケーリング

Linear scaling across regions

メモリを考慮したルーティングの動作

価値の提供

チームへの影響

次のステップ

Google、2026 年 Gartner Magic Quadrant でコンテナ管理部門のリーダーに選出

AI インフラストラクチャで優れたパフォーマンスと効率を実現

エージェント インフラストラクチャのセキュリティとスケールに対応する Kubernetes の進化

サーバーレス コンテナによる次世代のデベロッパー エクスペリエンス

次のステップ

ガバナンスが組み込まれた、AI 支援による EKS から GKE への移行を実現する GKE エージェント型移行の概要

インフラストラクチャの移行に伴う課題

GKE エージェント型移行の概要

仕組み: 移行のライフサイクル

使ってみる

Agent Substrate は GKE にて高密度でスケーラブルな信頼できるインフラストラクチャを提供します

ローカルから 100 万エージェント規模へ

エージェント専用に構築された基盤

アーキテクチャの基本原則

Google Cloud インフラストラクチャ向けに最適化

スケーラブルな基盤上にエージェント プラットフォームを構築

分散 Ray クラスタに gVisor サンドボックスを導入

Ray プリミティブとしてのサンドボックス

gVisor を選ぶ理由

例 1: 固定定常状態での Pod レベルのブースト（`updateMode: "Off"`）

本番環境ワークロードのベストプラクティス

キャパシティバッファによる起動レイテンシの管理

エージェントインフラストラクチャのセキュリティとスケールに対応する Kubernetes の進化

サーバーレスコンテナによる次世代のデベロッパーエクスペリエンス

スケーラブルな基盤上にエージェントプラットフォームを構築

一般的なネットワークセキュリティシナリオ

GKE における AI サプライチェーンの保護: 自動 AI BOM 対応 k8s-aibom のご紹介

不変性と最小権限: 監査に適したセキュリティモデルの構築

GKE で Ray Serve LLM をスケーリング: デベロッパーエクスペリエンスを損なうことなくパフォーマンスを向上

GKE スタンバイバッファの概要: 予算を抑えながらノードの起動時間を短縮

GKE キャパシティバッファの概要 - 低レイテンシの Pod スケジューリングを実現するネイティブ Kubernetes の方法

アクティブバッファとスタンバイバッファの連携

GKE スタンバイバッファのベストプラクティス

GKE のノード起動が高速化され、コールドスタートレイテンシが解消

今回取り組んだ問題:「コールドスタート」の負担

解決策: ノードプロビジョニングの完全な再構築