Containers & Kubernetes

レポート: 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 0x7fed0adeb4c0>)])]>

ユースケース 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 0x7fed0adebe50>)])]>

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 0x7fed0aee7610>)])]>

次に、カスタム 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 0x7fed0af46460>)])]>

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

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 0x7fed0af467c0>)])]>

バッファを作成する

最後に、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 0x7fed0acc2220>)])]>

（省略可）アクティブバッファの例: 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 0x7fed0b3577c0>)])]>

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

バッファによって予約されたスペースでスケジュールできる既存および将来の 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 0x7fed08de6be0>)])]>

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

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 0x7fed08de62b0>)])]>

バッファをテストするには、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 0x7fed08de6760>)])]>

この 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

Next ‘26 で発表された GKE の新機能

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

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

今週開催の Google Cloud Next ‘26 では、Google Kubernetes Engine（GKE）の進化についてご紹介しています。GKE は、特に要求が厳しく複雑なワークロードや、次世代の AI アプリケーションとエージェントアプリケーションに対して、優れたパフォーマンス、効率性、セキュリティ、スケーラビリティを提供します。

重要である理由: Kubernetes は AI 時代のオペレーティングシステムとして急速に普及しており、GKE は現在、最大規模のフロンティアモデルの構築企業を含む、プラットフォーム上の上位 50 社すべてのお客様の AI ワークロードを支えています。エンタープライズ AI は急速に普及しています。わずか数か月で、マルチエージェント AI ワークフローの数が 327% も急増しました。同時に、組織の 66% が生成 AI アプリやエージェントの強化に Kubernetes を利用しています。

自律型エージェントが大規模に運用されるこの新しい時代には、インフラストラクチャの管理方法に根本的な変革が求められています。これは、ステートレスアプリケーションからステートフルアプリケーションへの移行よりも要求の厳しい変革です。

新機能:

GKE Agent Sandbox: 安全でスケーラビリティが高く、低レイテンシのエージェントインフラストラクチャ
GKE ハイパークラスタ: Google Cloud リージョン全体で数百万のアクセラレータを管理する、単一の適合 GKE コントロールプレーン
推論パフォーマンスの向上: GKE Inference Gateway と KV キャッシュ管理の基盤となる機能強化
強化学習（RL）の強化機能: アクセラレータ使用率をスロットリングするボトルネックを解消するネイティブ機能
カスタム指標に基づくスケーリング: CPU とメモリ以外のトリガーに基づくインテントベースの自動スケーリングをサポート

GKE に関するこれらのお知らせについて詳しく説明します。

GKE Agent Sandbox: エージェント時代を加速

AI が単純な会話型チャットボットから、エコシステム全体へのプロアクティブで自律的なエージェントへと進化するにつれて、基盤となるインフラストラクチャは、従業員と連携して複雑なタスクを計画、評価、実行するために数百または数千のエージェントを処理できるように適応していく必要があります。大規模なインフラストラクチャでは、パフォーマンス、応答性、厳格なセキュリティが不可欠です。

このたび Google は、業界有数のスケーラビリティと低レイテンシを誇る AI エージェントインフラストラクチャである GKE Agent Sandbox を発表しました。Gemini の保護と同じ gVisor カーネル分離テクノロジーで構築された Agent Sandbox を使用すると、パフォーマンスを犠牲にすることなく、信頼できないコード、ツール、エージェント全体を安全に実行できます。GKE は、完全に分離されたエージェントに対して、1 秒あたり 300 個のサンドボックス、1 秒未満のレイテンシ、Axion で実行した場合の他のハイパースケールクラウドと比較して最大 30% 優れた費用対効果を実現し、業界をリードするスピードと効率性を提供します。

Lovable を使用すると、誰でもアプリやウェブサイトを構築できます。毎日ビルダーによって 20 万件以上の新しいプロジェクトが作成されています。Lovable では、起動の速さとスケーリングの速さ、そして安全な分離が可能なことから、これらの AI 生成アプリケーションを GKE Agent Sandbox で実行しています。

「GKE の最先端のサンドボックス機能により、1 秒あたり数百個の安全なサンドボックスに確実にスケーリングできるため、予測不能な膨大な需要が発生した場合でも、ビルダーをシームレスに支援できます」- Lovable、共同創業者 Fabian Hedin 氏

GKE ハイパークラスタがスケーラビリティの上限を再定義

基盤となる AI モデルが指数関数的に成長し、アクセラレータの需要が高い状態が続いているため、組織は Kubernetes コンピューティングインフラストラクチャを数百の切断されたクラスタに分割する手段をとっており、これは、運用上の大きな負担につながる可能性があります。この問題を解決するために、Google は GKE ハイパークラスタの限定公開 GA を発表します。これにより、複数の Google Cloud リージョンにまたがる 256,000 個のノードに分散された 100 万個のチップを、Kubernetes に準拠した単一の GKE コントロールプレーンで管理できるようになります。GKE ハイパークラスタを使用すると、広範囲に分散されたインフラストラクチャが、複数の地理的場所にまたがる単一の統合された容量の予備となります。

セキュリティを損なうことなくグローバルにスケーリングするために、GKE ハイパークラスタは Google の Titanium Intelligence Enclave を利用しています。これは、プライベート AI コンピューティングを提供するソフトウェア強化型のセキュリティエンジンです。この「管理者権限なし」モデルは、ハードウェア証明済みの Pod レベルの分離を提供するため、独自のモデルの重みとプロンプトは、プラットフォーム管理者とインフラストラクチャレイヤから暗号的にシールされたままになります。

最先端の推論を強化

最先端の推論を実現するには、数か月にわたる複雑なパフォーマンスチューニングが必要です。この手間を軽減するために、GKE では TPU と GPU 全体で「SOTA までの時間」をわずか数分に短縮しました。これを実現するために、以下の新機能を提供しています。

GKE Inference Gateway の ML を活用した予測レイテンシブースト。ヒューリスティックな推測をリアルタイムの容量を考慮したルーティングに置き換えることで、最初のトークンまでの時間（TTFT）のレイテンシを最大 70% 削減できます。手動によるチューニングは必要ありません。
RAM、ローカル SSD、GCS/Lustre 間での自動 KV キャッシュストレージティアリングにより、長いコンテキストのメモリボトルネックが解消されます。KV キャッシュを RAM にオフロードすると、システムプロンプトの長さが 10,000 の場合、TTFT が 40% 以上短縮され、スループットが 50% 向上しました。KV キャッシュをローカル SSD にオフロードすると、システムプロンプトの長さが 50,000 の場合、スループットがほぼ 70% 向上しました。これらのベンチマークについて詳しくは、llm-d Offloading Prefix Cache to Shared Storage guide をご覧ください。

レイヤ化されたコンポーズ可能なスイートの一部として構築されたこれらの新しい GKE 機能は、現在公式の CNCF サンドボックスプロジェクトである llm-d を活用しています。最大限の柔軟性を実現するため、Google は NVIDIA と緊密に連携して Dynamo をシームレスに統合し、大規模な混合エキスパート（MoE）モデルをスケーリングできるようにしました。どのツールを選択しても、GKE は、あらゆる最先端の AI ワークロードを安全に実行するために必要な、高度に最適化された柔軟なインフラストラクチャを提供します。これには、新しく発表された Gemma 4 の高度なエージェント機能も含まれます。

RL コンピューティングのボトルネックの解消

強化学習（RL）は AI コンピューティング需要の重要な推進力であり、RL ジョブにはサンプリング、報酬、トレーニングの順次処理が含まれます。これらの RL ステップの間では GPU および TPU アクセラレータがアイドル状態になる可能性があります。RL を効率化するために、新しい GKE 機能をプレビュー版として追加しています。

RL スケジューラは「ストラグラー効果」とバッチ間のテールレイテンシを解決し、インテリジェントなルーティングによってスループットを最大化します。
RL Sandbox は、ツール呼び出しと報酬評価のためにカーネルレベルの分離を提供し、ミリ秒単位でプロビジョニングします。RL サンプリングと報酬のステップとの統合は簡単です。
RL のオブザーバビリティと信頼性のダッシュボードは、RL ループ全体のトラブルシューティングと最適化を即座に、すぐに使える状態で実行するために必要な詳細な可視性を提供します。

GKE レシピの RL、特に Verl と NeMo RL の実装をご確認ください。

カスタム指標に基づくインテントベースの自動スケーリング

従来、アプリケーションの健全性に基づいて AI ワークロードをスケーリングするには、「カスタム指標税」が課せられていました。基本的なコンピューティングやメモリ使用率以外の要素に基づいてシステムをスケーリングするには、組織は複雑なモニタリングシステムと IAM ロールを管理する必要があります。これにより、運用上のリスクが生じます。外部のオブザーバビリティスタックに障害が発生すると、自動スケーリングも機能しなくなります。

インテントベースの自動スケーリングでは、GKE の HorizontalPodAutoscaler（HPA）のネイティブなカスタム指標サポート により、このオーバーヘッドが解消されます。このエージェントレスアーキテクチャは、Pod から直接指標を取得することで外部依存関係を回避し、信頼性を高めながらコストを削減します。重要なのは、反応時間が 25 秒からわずか 5 秒に短縮されたことです。これは、インフラストラクチャの弾力性がほぼ瞬時に発揮されることを意味し、パフォーマンスが 5 倍向上しています。

新しいワークロード、変わらないミッション

GKE は 10 年以上にわたり、スケーラブルなインフラストラクチャの標準を確立してきました。エージェント AI と自律型 AI の時代を迎えても、Google の使命は変わりません。それは、運用上の摩擦を排除し、お客様がイノベーションに集中できるようにすることです。Next '26 で発表する機能（GKE ハイパークラスタ、Agent Sandbox、超高速推論、インテントベースの自動スケーリングなど）は、意欲的な AI ワークロードを成功させるために必要な、安全で効率的かつ強力なエンジンを提供します。AI ワークロードに GKE を使用する方法について詳しくは、GKE Inference Quickstart をご覧ください。

- オーケストレーションおよび Kubernetes プロダクト管理担当シニアディレクター Drew Bradstock

- GKE グループプロダクトマネージャー Gari Singh

Envoy: エージェント型 AI ネットワーキングのための将来を見据えた基盤

Fri, 17 Apr 2026 01:30:00 +0000

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

昨今のエージェント型 AI 環境では、ネットワークに新たな責任が課せられています。

従来のアプリケーションスタックでは、ネットワークは主にサービス間でリクエストを移動するものでした。しかし、最近のホワイトペーパー Cloud Infrastructure in the Agent-Native Era で説明されているように、エージェントシステムでは、モデル呼び出し、ツール呼び出し、エージェント間のやり取り、エージェントができることを定義するポリシーの決定の間にネットワークが位置します。多様なフレームワーク上に構築されることが多いエージェントが急速に普及しているため、すべてのエージェントパスにわたってガバナンスとセキュリティを一貫して大規模に適用する必要があります。これを実現するには、適用レイヤがアプリケーションレベルから基盤となるインフラストラクチャに移行する必要があります。つまり、ネットワークはもはや盲目的なトランスポートレイヤとして機能することはできず、より多くのことを理解し、より適切に適用を行い、より迅速に適応する必要があります。この移行において役立つのが Envoy です。

Envoy は、高パフォーマンスの分散プロキシおよびユニバーサルデータプレーンとして、大規模なスケーリングに対応するように構築されています。Google Cloud を含む要求の厳しいエンタープライズ環境で信頼されており、単一サービスのデプロイから、上り（内向き）、下り（外向き）、サイドカーの各パターンを使用した複雑なサービスメッシュまで、あらゆるものをサポートします。Envoy は、優れた拡張性、堅牢なポリシー統合、運用上の成熟度により、プロトコルが急速に変化し、制御が不十分な場合のコストが高くなる時代に特に適しています。エージェント型 AI を構築するチームにとって、Envoy は単なるコンセプトではなく、実用的でプロダクションレディな基盤です。

エージェント型 AI がネットワーキングの問題を変える

エージェントワークロードは依然としてトランスポートとして HTTP を使用することが多いですが、従来の HTTP 仲介役が依存する前提の一部には従いません。Model Context Protocol（MCP）や Agent2agent（A2A）などのプロトコルは、HTTP 上で JSON-RPC または gRPC を使用し、標準の HTTP リクエスト / レスポンスセマンティクスに加えて、クライアントとサーバーがそれぞれの機能を交換する MCP 初期化などのプロトコルレベルのフェーズを追加します。仲介役が適応する必要がある、エージェントシステムの主な側面は次のとおりです。

企業ガバナンスの多様な要件。主な課題は、安全性、セキュリティ、データプライバシー、規制遵守に関する、企業にとって譲れない幅広い要件を満たすことです。これらのニーズは、標準的なネットワークポリシーの枠を超えることが多く、内部システムとの緊密な統合、カスタムロジック、新しい組織ルールや外部規制に迅速に適応する能力が必要になります。そのため、企業が独自のガバナンスモデルを組み込める、拡張性の高いフレームワークが求められます。
ポリシー属性は、ヘッダーではなくメッセージ本文内に存在する。パスやヘッダーなどのポリシー入力に簡単にアクセスできる従来のウェブトラフィックとは異なり、エージェントプロトコルでは、重要な属性（モデル名、ツール呼び出し、リソース ID など）が JSON-RPC または gRPC ペイロードの奥深くに埋もれていることがよくあります。このため、仲介役はメッセージの内容を解析して理解し、コンテキストに応じたポリシーを適用できる必要があります。
多様で進化するプロトコルの特性に対応する。エージェントのプロトコルは一様ではありません。Streamable HTTP を使用する MCP のような一部のプロトコルでは、（Mcp-Session-Id などを使用した）分散プロキシ全体でのセッション管理が必要となるステートフルなインタラクションが導入されることもあります。このような多様な動作をサポートする必要性と、将来のプロトコルのイノベーションにより、本質的に適応性と拡張性に優れたネットワーキング基盤の必要性が高まっています。

これらの要因により、企業は単なる接続性以上のものを必要としています。ネットワークは、前述した重要なガバナンスのニーズを満たす中心的な役割を果たす必要があります。これには、プロトコルとエージェントの動作の急速な進化に対応しながら、一元化されたセキュリティ、包括的な監査可能性、きめ細かいポリシーの適用、動的なガードレールなどの機能を提供することが含まれます。簡単に言えば、エージェント型 AI はネットワークを単なるトランジットパスから重要な制御ポイントに変えます。

Envoy がこの移行に対応できる理由

Envoy は、以下の 3 つの理由から、エージェント型 AI ネットワーキングに最適です。

実証済み。Envoy は、セキュリティが重要な大規模環境で企業がすでに利用しており、新世代のトラフィック管理とポリシー適用を支える信頼できるプラットフォームとなっています。
拡張可能。Envoy は、ネイティブフィルタ、Rust モジュール、WebAssembly（Wasm）モジュール、外部処理パターンを通じて拡張できます。これにより、プラットフォームチームは、エコシステムが変化するたびにネットワーキングレイヤを再構築することなく、新しいプロトコルを採用できるようになります。
今すぐ運用に役立つ。Envoy はすでに、コントロールプレーンのゲートウェイ、適用ポイント、オブザーバビリティレイヤ、統合サーフェスとして機能しています。そのため、標準が定着するのを待たずに今すぐ移行する必要がある組織にとって、実用的な選択肢となります。

Envoy は、以下の中核的な強みを基盤として、エージェントネットワーキングに特有のニーズを満たすアーキテクチャの進歩を遂げています。

1. Envoy はエージェントトラフィックを理解する

エージェントネットワーキングの最初の要件はシンプルです。ゲートウェイはエージェントが実際に何をしようとしているのかを理解する必要があるということです。

ただし、これはそれほど簡単ではありません。MCP、A2A、OpenAI スタイルの API などのプロトコルでは、重要なポリシーシグナルがリクエスト本文内に存在することがあります。従来の HTTP プロキシは、本文を不透明なバイトストリームとして扱うように最適化されています。この設計は効率的ですが、プロキシで適用できることが制限されます。JSON メッセージを使用するプロトコルの場合、プロキシはポリシーの適用に必要な属性値を見つけるために、リクエスト本文全体をバッファリングする必要がある場合があります。特に、それらの属性が JSON メッセージの末尾にある場合はその必要性が高まります。使用されたトークンに基づくレート制限など、生成 AI プロトコルに固有のビジネスロジックでも、サーバーのレスポンスの解析が必要になる場合があります。

これに対処するために、Envoy は、HTTP で伝送されるプロトコルメッセージをデフレーミングし、有用な属性をフィルタチェーンの残りの部分に公開します。生成 AI プロトコルの拡張性モデルは、次の 2 つの目標を指針としています。

RBAC（ロールベースアクセス制御）やトレーサーなど、生成 AI プロトコルにそのまま対応する既存の HTTP 拡張機能を簡単に再利用できる。
デベロッパーが HTTP や JSON エンベロープを処理する必要がなく、生成 AI のビジネスロジックに集中できるように、生成 AI 固有の拡張機能用のデフレーミングされたメッセージに簡単にアクセスできる。

これらの目標に基づき、生成 AI プロトコルの新しい拡張機能は、依然として HTTP 拡張機能として構築され、HTTP フィルタチェーンで構成されます。これにより、OAuth や mTLS 認証などの HTTP ネイティブのビジネスロジックと生成 AI プロトコルのロジックを 1 つのチェーンで混在させる柔軟性が得られます。デフレーミング拡張機能は、HTTP で伝送されるプロトコルメッセージを解析し、抽出された属性、さらには解析されたメッセージ全体を含むアンビエントコンテキストを、既知のフィルタ状態とメタデータ値を介してダウンストリームの拡張機能に提供します。

Envoy では、すべてのポリシーコンポーネントが JSON エンベロープやプロトコル固有のメッセージ形式を独自に解析することを強制するのではなく、これらの属性を構造化されたメタデータとして利用できるようにします。ゲートウェイがプロトコルメッセージをデフレーミングすると、ext_authz や RBAC などの既存の Envoy 拡張機能がプロトコルプロパティを読み取り、MCP のツール名、A2A のメッセージ属性、OpenAI のモデル名などのプロトコル固有の属性を使用してポリシーを評価できます。

アクセスログには、モニタリングと監査を強化するためのメッセージ属性を含めることができます。プロトコル属性は Common Expression Language（CEL）ランタイムでも使用できるため、RBAC や複合拡張機能で複雑なポリシー式を簡単に作成できます。

バッファリングとメモリ管理Envoy は、HTTP リクエストをプロキシする際にできるだけ少ないメモリを使用するように設計されています。しかし、エージェントプロトコルの解析には、特に拡張機能でメッセージ全体をメモリに格納する必要がある場合、変動する量のバッファ領域が必要になることがあります。特に、信頼できないトラフィックが存在する場合は、拡張機能でより大きなバッファを使用できる柔軟性と、メモリ枯渇からの適切な保護のバランスを取る必要があります。

これを実現するために、Envoy ではリクエストごとにバッファサイズを制限できるようになりました。リクエストデータを保持するバッファもオーバーロードマネージャーと統合されているため、アイドルタイムアウトの短縮や、長期間にわたって最も多くのメモリを消費するリクエストのリセットなど、メモリ不足時のあらゆる保護アクションが可能になります。これらの変更により、Envoy はリソース効率を損なうことなく、生成 AI プロトコルのゲートウェイおよびポリシー適用ポイントとして機能できるようになっています。

2. Envoy は重要な事項に関するポリシーを適用する

トラフィックを理解することは、ゲートウェイがそれに基づいて動作できる場合にのみ役立ちます。

エージェントシステムでは、ポリシーはエージェントがアクセスできるサービスだけでなく、エージェントが呼び出せるツール、使用できるモデル、提示する ID、消費できる量、追加の制御が必要な出力の種類も規定するものです。これらは、単純なレイヤ 4 またはパスベースの制御よりも価値の高い決定であり、エージェントが企業に代わって行動することを許可する場合に、企業が重視する種類の制御です。

この点において Envoy は、トランスポートレベルのセキュリティとアプリケーション対応のポリシー適用を組み合わせることができるため、優れています。チームは、mTLS と SPIFFE ID でワークロードを認証し、RBAC、外部認証、外部処理、アクセスロギング、CEL ベースのポリシー式を使用してプロトコル固有のルールを適用できます。

この機能は、プラットフォームチームがエージェントの開発と適用を切り離せるため、非常に重要です。デベロッパーは有用なエージェントの構築に集中でき、オペレーターはツール、モデル、プロトコルが変化し続けても、ネットワークレイヤで一貫したゼロトラスト体制を維持できます。このゼロトラストの分離の好例は、「エージェントの背後にユーザーがいる」重要なシナリオ、つまり AI エージェントが人間のユーザーに代わってタスクを実行する必要がある場合です。従来、ユーザーの認証情報をアプリケーションに直接渡すことは、重大なセキュリティリスクをもたらします。エージェントが侵害されたり、プロンプトインジェクションによって操作されたりした場合、攻撃者は認証情報を抜き取ったり、不正使用したりできるためです。ID 管理を Envoy にオフロードすることで、プロキシはインフラストラクチャレイヤでユーザー委任トークンをアウトバウンドリクエストに自動的に挿入できます。エージェントが機密性の高い認証情報を直接保持することはないため、侵害されたエージェントがトークンを不正使用したり漏洩させたりするリスクは完全に排除され、アクションはユーザーの実際の権限に厳密にバインドされたままになります。

ケーススタディ: エージェントを特定の GitHub MCP ツールに制限するGitHub の問題をトリアージするエージェントを考えてみましょう。

GitHub MCP サーバーは数十のツールを公開している可能性がありますが、エージェントに必要なのは、list_issues、get_issue、get_issue_comments など、ごく一部の読み取り専用のツールのみである場合があります。ほとんどの企業にとって、この違いは重要です。有用なエージェントが、無制限のエージェントに自動的に変わるべきではありません。

MCP サーバーの前に Envoy を配置することで、ゲートウェイは mTLS handshake 中に SPIFFE を使用してエージェントの ID を検証し、デフレーミングフィルタを介して MCP メッセージを解析し、リクエストされたメソッドとツール名を抽出して、その特定のエージェント ID に対して承認されたツール呼び出しのみを許可するポリシーを適用できます。RBAC は、MCP デフレーミングフィルタによって作成されたメタデータを使用して、MCP メッセージ内のメソッドとツール名をチェックします。

code_block: <ListValue: [StructValue([('code', 'envoy.filters.http.rbac:\r\n "@type": type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBACPerRoute\r\n rbac:\r\n rules:\r\n policies:\r\n github-issue-reader-policy:\r\n permissions:\r\n - and_rules:\r\n rules:\r\n - sourced_metadata:\r\n metadata_matcher:\r\n filter: envoy.http.filters.mcp\r\n path: [{ key: "method" }]\r\n value: { string_match: { exact: "tools/call" } }\r\n - sourced_metadata:\r\n metadata_matcher:\r\n filter: envoy.http.filters.mcp\r\n path: [{ key: "params" }, { key: "name" }]\r\n value:\r\n or_match:\r\n value_matchers:\r\n - string_match: { exact: "list_issues" }\r\n - string_match: { exact: "get_issue" }\r\n - string_match: { exact: "get_issue_comments" }\r\n principals:\r\n - authenticated:\r\n principal_name:\r\n exact: "spiffe://cluster.local/ns/github-agents/sa/issue-triage-agent"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fed087bceb0>)])]>

この真の価値は、ポリシーがトラフィックに近い場所で、一元的に、エージェントの実際の動作に合った条件で適用されるという点です。

静的ルールの枠を超えて: 外部認証

RBAC ルールを使用して表現できない複雑なコンプライアンスポリシーは、ext_authz プロトコルを使用して外部認証サービスに実装できます。Envoy は、ext_authz RPC のコンテキストで、HTTP ヘッダーとともに MCP メッセージ属性を提供します。また、ピア証明書からエージェントの SPIFFE ID を転送することもできます。

code_block: <ListValue: [StructValue([('code', 'http_filters:\r\n - name: envoy.filters.http.ext_authz\r\n typed_config:\r\n "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz\r\n grpc_service:\r\n envoy_grpc:\r\n cluster_name: auth_service_cluster\r\n include_peer_certificate: true\r\n metadata_context_namespaces:\r\n - envoy.http.filters.mcp'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fed087bc280>)])]>

これにより、エージェントや MCP サーバーがポリシーレイヤを認識する必要なく、エージェント ID、MCP メソッド、ツール名、その他のプロトコル属性の完全な組み合わせに基づいて、外部サービスが認証の決定を行うことができます。

プロトコルネイティブのエラーレスポンス

Envoy がリクエストを拒否した場合、返されるエラーは呼び出し元のエージェントにとって意味のあるものである必要があります。MCP トラフィックの場合、Envoy は local_reply_config を使用して、HTTP エラーコードを適切な JSON-RPC エラーレスポンスにマッピングできます。たとえば、403 Forbidden は、isError: true および人間が読めるメッセージを含む JSON-RPC レスポンスにマッピングできます。これにより、エージェントは不透明な HTTP ステータスコードではなく、プロトコルに適した拒否を受け取ることができます。

3. Envoy はステートフルなエージェントのインタラクションを大規模にサポートする

エージェントトラフィックのすべてがステートレスであるわけではありません。MCP の Streamable HTTP など、一部のプロトコルはセッション指向の動作に依存する場合があります。特に、トラフィックが複数のゲートウェイインスタンスを通過してスケーラビリティと復元力を実現する場合、仲介役にとって新たな課題が生じます。MCP セッションは、そのセッションを確立したサーバーにエージェントを効果的にバインドします。すべての仲介役は、受信 MCP 接続を正しいサーバーに転送するために、このことを認識する必要があります。

1 つのバックエンドでセッションが確立された場合、その会話における後のリクエストは正しい宛先に到達する必要があります。単一プロキシのデプロイでは簡単そうに聞こえますが、水平方向にスケールされたシステムでは、複数の Envoy インスタンスが同じエージェントからの異なるリクエストを処理する場合があり、より複雑になります。

パススルーゲートウェイ

よりシンプルなパススルーモードでは、Envoy はダウンストリーム接続ごとに 1 つのアップストリーム接続を確立します。主な用途は、外部 MCP サーバーに対するクライアントの認可、RBAC、レート制限、認証など、一元化されたポリシーの適用です。仲介役の間で転送されるセッション状態には、最初の HTTP 接続でセッションを確立したサーバーのアドレスのみが含まれる必要があります。これにより、セッション関連のすべてのリクエストがそのサーバーに送信されます。

異なる Envoy インスタンス間でのセッション状態の転送は、MCP サーバーから提供された MCP セッション ID に、エンコードされたセッション状態を追加することで実現されます。Envoy は、リクエストを宛先 MCP サーバーに転送する前に、セッション ID からセッション状態の接尾辞を削除します。このセッションの永続性は、Envoy の envoy.http.stateful_session.envelope 拡張機能を構成することで有効になります。

集約ゲートウェイ

集約モードでは、Envoy は複数のバックエンド MCP サーバーの機能、ツール、リソースを集約することで、単一の MCP サーバーとして機能します。これにより、ポリシーが適用されるだけでなく、エージェントの構成が簡素化され、複数の MCP サーバーのポリシー適用が統合されます。

このモードでのセッション管理はより複雑になります。セッション状態に、ツールとリソースから、それらをアドバタイズしたサーバーアドレスとセッション ID へのマッピングも含まれる必要があるためです。Envoy がエージェントに提供するセッション ID は、ツールやリソースが認識される前に作成され、マッピングはその後、Envoy とバックエンド MCP サーバー間の MCP 初期化フェーズが完了した後に確立される必要があります。

現在 Envoy で実装されているアプローチの一つは、ツールやリソースの名前と、その配信元サーバーの識別子およびセッション ID を組み合わせるというものです。通常、正確なツール名やリソース名はエージェントにとって意味がなく、この追加の来歴情報を伝えることができます。変更されていないツール名やリソース名が必要な場合は、マッピングのない Envoy インスタンスを使用し、特定のツールを呼び出す前に tools/list コマンドを発行してマッピングを再作成するというアプローチもあります。このアプローチは、レイテンシと引き換えに、MCP セッションの外部グローバルストアをデプロイする複雑さが伴います。現在、ユーザーからのフィードバックに基づいて計画中です。

これは、Envoy が単純なトラフィック転送にとどまらないことを意味するため重要です。これにより、Envoy は、実際のエージェントワークフロー（複数のリクエスト、ツール、バックエンドにわたるものを含む）の信頼できる仲介役として機能できます。

4. Envoy はエージェントの検出をサポートする

Envoy は、既知の AgentCard エンドポイントを介した A2A プロトコルとエージェントの検出のサポートを追加しています。エージェント機能が記載された JSON ドキュメントである AgentCard は、スキル、認証要件、サービスエンドポイントをアドバタイズすることで、検出とマルチエージェントの調整を可能にします。AgentCard は、直接レスポンス構成を介して静的にプロビジョニングすることも、xDS API または ext_proc API を介して一元化されたエージェントレジストリサーバーから取得することもできます。A2A の実装とエージェントの検出の詳細は、今後のブログ投稿で公開する予定です。

5. Envoy はエージェントネットワーキングの課題に対する包括的なソリューション

Envoy は、要求の厳しいデプロイで MCP プロトコルのポリシー適用が可能になった基盤と同じ基盤を基に、OpenAI と、エージェントプロトコルの RESTful HTTP API へのコード変換のサポートを追加しています。このコード変換機能により、生成 AI エージェントと既存の RESTful アプリケーションの統合が簡素化されます。また、OpenAPI ベースのアプリケーションがすぐにサポートされ、動的モジュールまたは Wasm 拡張機能を通じてカスタムオプションを利用できます。Envoy は、コード変換に加えて、割り当て管理などの高度なポリシー適用、生成 AI システムの OpenTelemetry セマンティック規則に準拠した包括的なテレメトリー、安全なエージェント運用を実現する統合ガードレールなど、本番環境への対応に不可欠な領域で強化されています。

安全なエージェントのためのガードレール

投資対象となる次の重要な分野は、すべてのエージェントトラフィックのガードレールの一元管理と適用です。現在、ポリシー適用ポイントを外部のガードレールと統合するには、特注の実装が必要ですが、この問題領域は標準化の機が熟しています。

コントロールプレーンがこれを運用可能にする

ゲートウェイは、ソリューション全体の一部にすぎません。このポリシー管理とロールアウトを大規模に実現するにあたり、xDS プロトコル（ユニバーサルデータプレーン API とも呼ばれる）を使用してデータプレーンを動的に構成するために別のコントロールプレーンが必要になります。

そこで重要になるのがコントロールプレーンです。Cloud Service Mesh は、Envoy AI Gateway や kube-agentic-networking などのオープンソースプロジェクトとともに、Envoy をデータプレーンとして使用しながら、オペレーターがエージェントワークロードのポリシーをより高いレベルで定義、管理できるようにします。

この組み合わせは強力です。Envoy はトラフィックパスに適用機能と拡張性を提供し、コントロールプレーンはチームがその機能を一貫してデプロイするために必要な運用モデルを提供します。

このソリューションが重要な理由

エージェントシステムや生成 AI プロトコル（MCP、A2A、OpenAI など）への移行に伴い、ネットワーク仲介役の進化が求められています。Envoy が主に対応する複雑な課題は次のとおりです。

プロトコルの詳細な検査。プロトコルデフレーミング拡張機能は、HTTP リクエストの本文からポリシーに関連する属性（ツール名、モデル名、リソースパス）を抽出し、従来のプロキシでは不透明なバイトストリームしか確認できなかった状況で正確なポリシー適用を可能にします。
きめ細かいポリシーの適用。これらの内部属性を公開することで、RBAC や ext_authz などの既存の Envoy 拡張機能は、プロトコル固有の基準に基づいてポリシーを評価できます。これにより、ネットワークオペレーターは、統一されたゼロトラストのセキュリティポスチャーを適用し、エージェントが特定のツールやリソースのアクセスポリシーに準拠するようにできます。
ステートフルなトランスポート管理。Envoy は、MCP で使用される Streamable HTTP トランスポートのセッション状態の管理をサポートしており、仲介役のフリート全体でも、パススルーゲートウェイモードと集約ゲートウェイモードの両方で堅牢なデプロイを可能にします。

エージェント型 AI プロトコルはまだ初期段階にあり、プロトコルの状況は今後も進化し続けます。まさにそのために、ネットワーキングレイヤには適応性が必要なのです。新しいエージェントフレームワーク、トランスポートパターン、ツールプロトコルが普及するたびに、企業がセキュリティとトラフィックのインフラストラクチャを再構築する必要はありません。制御を犠牲にすることなく変化を吸収できる基盤が必要です。

Envoy は、本番環境での実証済みの成熟度、高度な拡張性、エージェントワークロードのプロトコル認識の向上という、一度に持ち合わせることが難しい 3 つの特性を兼ね備えています。Envoy をエージェントゲートウェイとして活用することで、組織はセキュリティとポリシーの適用をエージェント開発コードから切り離すことができます。

これにより、Envoy は AI トラフィックを処理するプロキシ以上の存在になり、エージェント型 AI ネットワーキングの未来を見据えた基盤となります。

^{このブログ記事の共同執筆者である、Google のソフトウェアエンジニア Boteng Yao、Google のソフトウェアエンジニア Tianyu Xia、Google のシニアプロダクトマネージャー Sisira Narayana に感謝します。}

- Google、スタッフソフトウェアエンジニア、Yan Avlasov

- Tetrate、プロダクトおよびプロダクトマーケティングマネージャー、Erica Hughberg 氏

新しい GKE Cloud Storage FUSE プロファイルにより、AI ストレージの構成における当て推量が不要に

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

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

AI / ML の世界では、データはトレーニングと推論のワークロードに欠かせない要素です。Google Kubernetes Engine（GKE）ユーザーは、Cloud Storage FUSE を使用して Google Cloud Storage に保存されているデータに高いパフォーマンスでスケーラブルにアクセスできます。しかし、Cloud Storage FUSE のパフォーマンスを最大限に引き出すのは複雑な場合がある、というお客様の声が寄せられていました。

このたび、GKE Cloud Storage FUSE プロファイルが導入されました。この新機能は、運用オーバーヘッドを最小限に抑えながら、パフォーマンス調整を自動化し、AI / ML ワークロード（トレーニング、チェックポイント、推論）のデータアクセスを高速化するように設計されています。特定のワークロードのニーズに合わせて調整されたこれらのプロファイルを使用すると、Cloud Storage FUSE の高いパフォーマンスをすぐに活用できます。

導入前（手動調整）

code_block: <ListValue: [StructValue([('code', 'apiVersion: v1\r\nkind: PersistentVolume\r\nmetadata:\r\n name: serving-bucket-pv\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n capacity:\r\n storage: 64Gi\r\n persistentVolumeReclaimPolicy: Retain\r\n storageClassName: ""\r\n claimRef:\r\n name: serving-bucket-pvc\r\n mountOptions:\r\n - implicit-dirs\r\n - metadata-cache:ttl-secs:-1\r\n - metadata-cache:stat-cache-max-size-mb:-1\r\n - metadata-cache:type-cache-max-size-mb:-1\r\n - file-cache:max-size-mb:-1\r\n - file-cache:cache-file-for-range-read:true\r\n - file-system:kernel-list-cache-ttl-secs:-1\r\n - file-cache:enable-parallel-downloads:true\r\n - read_ahead_kb=1024\r\n csi:\r\n driver: gcsfuse.csi.storage.gke.io\r\n volumeHandle: BUCKET_NAME\r\n volumeAttributes:\r\n skipCSIBucketAccessCheck: "true"\r\n gcsfuseMetadataPrefetchOnMount: "true"\r\n---\r\napiVersion: v1\r\nkind: PersistentVolumeClaim\r\nmetadata:\r\n name: serving-bucket-pvc\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n resources:\r\n requests:\r\n storage: 64Gi\r\n volumeName: serving-bucket-pv\r\n storageClassName: ""\r\n–--\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n name: gcs-fuse-csi-example-pod\r\n annotations:\r\n gke-gcsfuse/volumes: "true"\r\nspec:\r\n containers:\r\n # Your workload container spec\r\n ...\r\n volumeMounts:\r\n - name: serving-bucket-vol\r\n mountPath: /serving-data\r\n readOnly: true\r\n serviceAccountName: KSA_NAME \r\n volumes:\r\n - name: gke-gcsfuse-cache # gcsfuse file cache backed by RAM Disk\r\n emptyDir:\r\n medium: Memory \r\n - name: serving-bucket-vol\r\n persistentVolumeClaim:\r\n claimName: serving-bucket-pvc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fed08acce20>)])]>

導入後（Cloud Storage FUSE のマウントオプション、CSI 構成、ファイルキャッシュメディアが自動的に構成されます）

code_block: <ListValue: [StructValue([('code', 'apiVersion: v1\r\nkind: PersistentVolume\r\nmetadata:\r\n name: serving-bucket-pv\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n capacity:\r\n storage: 64Gi\r\n persistentVolumeReclaimPolicy: Retain\r\n storageClassName: gcsfusecsi-serving\r\n claimRef:\r\n name: serving-bucket-pvc\r\n csi:\r\n driver: gcsfuse.csi.storage.gke.io\r\n volumeHandle: BUCKET_NAME\r\n---\r\napiVersion: v1\r\nkind: PersistentVolumeClaim\r\nmetadata:\r\n name: serving-bucket-pvc\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n resources:\r\n requests:\r\n storage: 64Gi\r\n volumeName: serving-bucket-pv\r\n storageClassName: gcsfusecsi-serving\r\n–--\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n name: gcs-fuse-csi-example-pod\r\n annotations:\r\n gke-gcsfuse/volumes: "true"\r\nspec:\r\n containers:\r\n # Your workload container spec\r\n ...\r\n volumeMounts:\r\n - name: serving-bucket-vol\r\n mountPath: /serving-data\r\n readOnly: true\r\n serviceAccountName: KSA_NAME \r\n volumes: \r\n - name: serving-bucket-vol\r\n persistentVolumeClaim:\r\n claimName: serving-bucket-pvc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fed08acc550>)])]>

Cloud Storage FUSE の最適化に伴う課題

高パフォーマンスのワークロード向けに Cloud Storage FUSE を最適化することは、多次元的な問題です。従来、ユーザーは数十ページに及ぶ手動構成ガイドを読み解く必要がありました。AI / ML の進化に伴い、Cloud Storage FUSE の機能も強化され、ワークロードを高速化するための新しいマウントオプションが利用できるようになりました。設定が「適切」かどうかは静的なものではなく、さまざまな動的要因に大きく左右されるものでした。

バケットの特性: データセットの合計サイズとオブジェクトの数は、メタデータとファイルキャッシュの要件に大きく影響します。
インフラストラクチャの多様性: GPU、TPU、汎用コンピューティングのいずれを使用するかによって、最適な構成は異なります。
ノードリソース: Cloud Storage への費用のかかるラウンドトリップを最小限に抑えるためにローカルにキャッシュ保存できるデータの量は、利用可能な RAM とローカル SSD の容量によって決まります。
ワークロードパターン: トレーニングワークロード（大規模データセットの高スループット読み取り）では、チェックポイントワークロード（バースト性が高い、高スループット書き込み）やサービングワークロード（レイテンシの影響を受けやすいモデルの読み込み）とは異なる調整が必要です。

実際、多くのお客様は、Cloud Storage FUSE の設定が最適化されていないか、誤って構成されているために、利用可能なパフォーマンスを十分に活用できていないか、信頼性の問題（Pod のメモリ不足による強制終了など）に直面しています。

GKE 向け Cloud Storage FUSE プロファイルの概要

GKE Cloud Storage FUSE プロファイルは、特定の AI / ML パターンに合わせてカスタマイズされた、事前定義された動的管理の StorageClass を使用して、この複雑さを簡素化します。数十ものマウントオプションを手動で調整する必要はなく、ワークロードのタイプに一致するプロファイルを選択するだけでかまいません。

これらのプロファイルは、階層化されたモデルで機能します。Cloud Storage FUSE の基本的なベストプラクティスをベースに、GKE 固有のインテリジェンスレイヤを追加します。プロファイルを使用して Pod をデプロイすると、GKE は自動的に次の処理を行います。

バケット（または特定のディレクトリ）をスキャンして、そのサイズとオブジェクト数を把握します。
ターゲットノードを分析して、利用可能な RAM、ローカル SSD、アクセラレータタイプを確認します。
最適なキャッシュサイズを計算し、最適なバッキングメディア（RAM またはローカル SSD）を自動的に選択します。

リリース時には、次の 3 つの主要なプロファイルが用意されています。

gcsfusecsi-training: GPU と TPU にデータを供給し続ける高スループットの読み取りに最適化されています。
gcsfusecsi-serving: モデルの読み込みと推論に最適化され、自動化された Rapid Cache 統合が可能です。
gcsfusecsi-checkpointing: 数ギガバイトの大きなチェックポイントファイルを高速かつ確実に書き込むように最適化されています。

GKE Cloud Storage FUSE プロファイルを使用すると、次のようなメリットがあります。

調整の簡素化: 複雑でエラーが発生しやすい手動構成が、3 つのシンプルな専用 StorageClass に置き換えられます。
リソースを認識した動的な最適化: CSI ドライバは、リアルタイムの環境シグナルに基づいてキャッシュサイズを自動的に調整するため、ノードの安定性を損なうことなくパフォーマンスを最大化できます。
読み取りパフォーマンスの向上: サービングプロファイルは Rapid Cache を自動的にトリガーし、データをコンピューティングの近くに配置して、コールドスタートモデルの読み込みを高速化します。
きめ細かなパフォーマンス分析情報: 構造化されたログを通じて自動調整の決定を可視化し、特定のキャッシュサイズとメディアが Pod に対して選択された理由を正確に把握できます。

GKE Cloud Storage FUSE プロファイルの推論プロファイルを使用することで、TPU（480 GB）上の Qwen3-235B-A22B ワークロードのモデル読み込み時間を 39 時間からわずか 14 分に短縮できました。これにより、お客様は Cloud Storage FUSE GCSFuse をすぐに使用して最大限のメリットを得ることができます。

GKE で Cloud Storage FUSE プロファイルを使用する方法

まず、Cloud Storage FUSE CSI ドライバが有効になっている GKE バージョン 1.35.1-gke.1616000 以降がクラスタで実行されていることを確認します。

1. StorageClass を特定する

GKE には、プロファイルベースの StorageClass がプリインストールされています。次のコマンドで確認できます。

code_block: <ListValue: [StructValue([('code', 'kubectl get sc -l gke-gcsfuse/profile=true'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fed08accfd0>)])]>

2. PV と PVC を作成する

PersistentVolume を作成する際、Cloud Storage バケットを参照するようにします。GKE は、最適な構成を判断するためにバケットスキャンを自動的に開始します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: v1\r\nkind: PersistentVolume\r\nmetadata:\r\n name: gcs-pv\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n capacity:\r\n storage: 5Gi\r\n persistentVolumeReclaimPolicy: Retain \r\n storageClassName: gcsfusecsi-training\r\n mountOptions:\r\n - only-dir=my-ml-dataset-subdirectory # Optional\r\n csi:\r\n driver: gcsfuse.csi.storage.gke.io\r\n volumeHandle: my-ml-dataset-bucket\r\n---\r\napiVersion: v1\r\nkind: PersistentVolumeClaim\r\nmetadata:\r\n name: gcs-pvc\r\nspec:\r\n accessModes:\r\n - ReadWriteMany\r\n resources:\r\n requests:\r\n storage: 5Gi\r\n storageClassName: gcsfusecsi-training\r\n volumeName: gcs-pv'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fed08acc7c0>)])]>

3. デプロイを作成する

PersistentVolumeClaim（PVC）がバインドされたら、他のボリュームと同様に Deployment で使用するだけです。GKE は、ハードウェアとデータセットに必要となる正確な設定でボリュームをマウントします。

code_block: <ListValue: [StructValue([('code', 'apiVersion: apps/v1\r\nkind: Deployment\r\nmetadata:\r\n name: my-deployment\r\nspec:\r\n replicas: 3\r\n selector:\r\n matchLabels:\r\n app: my-app\r\n template:\r\n metadata:\r\n labels:\r\n app: my-app\r\n annotations:\r\n gke-gcsfuse/volumes: "true"\r\n spec:\r\n serviceAccountName: my-ksa\r\n containers:\r\n - name: my-container\r\n image: busybox\r\n volumeMounts:\r\n - name: my-gcs-volume\r\n mountPath: "/data"\r\n volumes:\r\n - name: my-gcs-volume\r\n persistentVolumeClaim:\r\n claimName: gcs-pvc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fed08accbe0>)])]>

デプロイ後、CSI ドライバは、GPU や TPU、メモリ、ローカル SSD、バケットまたはサブディレクトリのサイズ、サイドカーのリソース上限など、ノードのリソースに基づいて最適なキャッシュサイズとマウントオプションを自動的に計算します。

使ってみる

GKE Cloud Storage FUSE プロファイルを使用すると、高パフォーマンスなクラウドストレージを構成する際に当て推量が不要になります。手動の「ノブ調整」からワークロードを認識する自動プロファイルに移行することで、ストレージスループットのデバッグに費やす時間を減らし、次世代の AI の構築に多くの時間を費やすことができます。

ぜひご利用ください。GKE Cloud Storage FUSE プロファイルは、バージョン 1.35.1-gke.1616000 で一般提供されています。AI / ML ワークロード向けに GKE で Cloud Storage FUSE プロファイルを構成する方法については、公式ドキュメントをご覧ください。

- エンジニアリングマネージャー、Nishtha Jain

- ソフトウェアエンジニア、Uriel Guzmán-Mendoza

GKE Inference Gateway を使用して、同じインフラストラクチャでリアルタイム推論と非同期推論を実行する

Tue, 14 Apr 2026 01:00:00 +0000

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

AI ワークロードが実験的なプロトタイプから本番環境グレードのサービスに移行するのに伴い、それらをサポートするインフラストラクチャは、利用率のギャップが拡大するという課題に直面しています。昨今の企業は通常、同時実行性が高く、低レイテンシのリアルタイムリクエストに対応するシステムを構築するか、高スループットの「非同期」処理用に最適化するかという二者択一を迫られています。

Kubernetes 環境では、従来、これらの要件には、サイロ化された別々の GPU および TPU アクセラレータクラスタによって対応してきました。リアルタイムトラフィックは、バーストを処理するためにオーバープロビジョニングされるため、オフピーク時には大幅なアイドル容量が発生する可能性があります。一方、非同期タスクは多くの場合、セカンダリクラスタに追いやられるため、ソフトウェアスタックが複雑化し、リソース管理が断片化します。

AI サービングワークロードの場合、Google Kubernetes Engine（GKE）は、推論パターンの全範囲に対応する統合プラットフォームである GKE Inference Gateway を使用して、この「費用とパフォーマンス」のトレードオフに対処します。Google は OSS ファーストのアプローチを活用することで、アクセラレータの容量を単一の流動的なリソースプールとして扱うスタックを開発しました。これにより、決定論的なレイテンシと高スループットの両方を必要とするワークロードに対応できます。

この投稿では、最新の AI サービスを推進する 2 つの主要な推論パターンと、それぞれのパターンにおける問題および現在利用可能なソリューションについて説明します。このブログ記事を最後までお読みいただくと、GKE が GKE Inference Gateway を介してこれらのパターンにどのように対応するかについておわかりいただけます。

2 つの推論パターン: リアルタイムと非同期

このブログ記事では、リアルタイムと非同期という 2 種類の AI 推論ワークロードを取り上げます。リアルタイム推論の場合、これらは優先度の高い同期リクエストです。たとえば、お客様が LLM からの即時レスポンスを待っている、chatbot とのやり取りなどです。一方、小売業におけるインデックス登録や商品分類のドキュメント化などの非同期トラフィックでは、通常、レイテンシが許容されます。つまり、トラフィックはキューに入れられ、遅延して処理されることがよくあります。

1. リアルタイム推論: レイテンシの影響を受けやすい 0 秒のリクエスト

優先度の高い同期トラフィックの場合、レイテンシが最も重要な指標となります。しかし、従来のロードバランシングでは、高レイテンシを示す KV キャッシュ使用率などのアクセラレータ固有の指標が無視されることが多いため、パフォーマンスを最適化できません。

ソリューション: GKE Inference Gateway

この問題のソリューションは、Inference Gateway です。Inference Gateway は、リアルタイムの指標（KV キャッシュのステータスなど）に基づいてモデルサーバーのパフォーマンスを予測し、レイテンシを考慮したスケジューリングを実行して、最初のトークンまでの時間を最小限に抑えます。これにより、キューイングの遅延も減り、負荷が高い場合でも一貫したパフォーマンスを確保できます。

2. 非同期（ニアリアルタイム）推論: 0 分のレイテンシ

レイテンシが許容されるタスクは、ミリ秒単位の要件ではなく、分単位のサービスレベル目標（SLO）で動作します。従来のセットアップでは、リアルタイムトラフィックとのリソース競合を防ぐために、これらのリクエストを別々の専用インフラストラクチャで実行することがよくありました。この静的なパーティショニングは、利用の断片化とハードウェア費用の膨張につながる可能性があります。さらに、カスタムビルドの非同期ポーラーは、通常、同じアクセラレータにワークロードを多重化するために必要な高度なスケジューリングロジックを備えていないため、エンジニアは 2 つの異なる複雑なソフトウェアスタックを管理する必要があります。

ソリューション: 非同期プロセッサエージェント + Inference Gateway

Inference Gateway を Cloud Pub/Sub と統合する「プラグアンドプレイ」アーキテクチャ。バッチ処理エージェントは、構成されたトピックからリクエストを pull し、それらを「削除可能な」トラフィックとして Inference Gateway にルーティングします。システムはバッチタスクを「フィラー」として扱い、リアルタイムの急増の合間にアイドル状態のアクセラレータ（GPU / TPU）の容量を使用します。これにより、リソースの断片化が最小限に抑えられ、ハードウェア費用を削減できます。

主な機能:

リアルタイムトラフィックのサポート: リアルタイム推論トラフィックは Inference Gateway によって処理されます。
永続的なメッセージング: Pub/Sub を介して信頼性の高いリクエスト処理が行われます。
インテリジェントな再試行: キューの深さのリアルタイムモニタリングに基づいて、キューアーキテクチャに組み込まれた構成可能な再試行ロジックを活用します。
厳密な優先順位: ゲートウェイレベルでは、リアルタイムトラフィックがバッチトラフィックよりも常に優先されます。
緊密な統合: ユーザーは Pub/Sub トピックを「プラグイン」するだけで、エージェントが共有アクセラレータプールへのルーティングロジックを処理します。

図 1 : リアルタイム推論トラフィックと非同期推論トラフィックを解決するための統合アーキテクチャの概要。

上の図に示されているリクエストフローは次のとおりです。

ユーザーがリアルタイムリクエストを送信します。Inference Gateway はまずそのリクエストのスケジュール作成をします。
ユーザーは、構成された Pub/Sub トピックを介して非同期推論リクエストをパブリッシュできます。
非同期プロセッサが、利用可能な容量に基づいてキューから読み取りを行います。
非同期プロセッサは、同じアクセラレータ（GPU / TPU）リソースを利用して、Inference Gateway を介してリクエストをルーティングします。リアルタイムリクエストが優先されます。非同期リクエストは、コンピューティングサイクルで未使用のアクセラレータに割り当てられます（上の図を参照）。
非同期プロセッサは、レスポンスを出力トピックに書き込みます。
ユーザーは、レスポンストピックから非同期リクエストのレスポンスを取得します。

これらのリアルタイムワークロードと非同期ワークロードを共有アクセラレータに統合することで、GKE は「費用とパフォーマンス」のパラドックスを解決します。脆弱なカスタムキューポーラーを管理したり、使用率の低いクラスタを個別に維持したりする必要はもうありません。さらに、これらの作業はすべてオープンソースで可能です。つまり、複数のクラウドや環境でこれらのプロダクトを使用できます。

統合ワークロードの実例

共有インフラストラクチャでリアルタイムワークロードと非同期ワークロードを実行するというアイデアは、理論的には素晴らしいものですが、実際にはどのように機能するのでしょうか。優先度の高いリアルタイムワークロードとレイテンシが許容されるバッチリクエストを統合リソースプール内で同時に処理する有効性を分析したところ、有望な結果が得られました。

リアルタイムトラフィックは、予測不能な急増が特徴です。低レイテンシの回答を維持するには、ピーク時にプールの容量の 100% をリアルタイムトラフィックに使用できるようにする必要があります。一方、レイテンシが許容されるタスクは、容量が使用可能になるまで保留状態のままにする必要があります。

最初のテストで、管理されていない多重化のリスクが明らかになりました。優先度が低く、レイテンシが許容されるリクエストが、非同期プロセッサエージェントを使用せずに Inference Gateway に直接送信された場合、リソースの競合によりメッセージの 99% が削除されました。しかし、非同期プロセッサを使用した場合、レイテンシが許容されるリクエストの 100% が利用可能なサイクル中に処理されました。

図 2: リアルタイムトラフィック + レイテンシが許容されるバッチトラフィックで使用率が向上することを示しています。

次のステップ

同じインフラストラクチャでリアルタイム AI ワークロードとバッチ AI ワークロードの両方を実行することに関心をお持ちの場合は、最初に、Inference Gateway を使用した非同期推論のクイックスタートガイドをご覧ください。GitHub で OSS プロジェクトに参加して、この取り組みに貢献することもできます。開発の次の段階では、期限を考慮したスケジューリングに重点を置き、ユーザーがバッチ完了期間に「ソフトリミット」を設定できるようにすることで、フィラートラフィックとリアルタイムの需要のバランスをシステムが取る方法をさらに最適化します。この重要な取り組みでコミュニティと連携できることを楽しみにしています。

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

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

AI 時代のオープンプラットフォーム: GKE、エージェント、OSS のイノベーションを KubeCon EU 2026 で披露

Tue, 07 Apr 2026 01:00:00 +0000

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

今週、クラウドネイティブのコミュニティがアムステルダムに集まり、Kubecon + Cloudnativecon Europe が開催されます。Google は、オープンソースの Kubernetes エコシステムとGoogle Kubernetes Engine（GKE）を支援するために取り組んでいる活動の一部をご紹介します。これには、クラスタの運用モード間の壁を打ち破ることから、Kubernetes を AI エージェントや Ray を実行するための最適な場所にすることまで、Google が現在展開しているさまざまな取り組みが含まれます。

Autopilot をすべてのお客様に

5 年前、Google は、スケーリングとインフラストラクチャ管理を大幅に簡素化できるフルマネージドの GKE エクスペリエンスである GKE Autopilot を発表しました。以前は、GKE Autopilot モードと Standard モードのどちらを選択するかという判断は、クラスタ作成時の「分岐点」でした。たとえば、Standard モードで開始した後に Autopilot に切り替えたい場合は、まったく新しいクラスタを作成する必要がありました。そのため、厳格なノードレベルの制御が必要なワークロードと、シームレスで手間のかからないスケーリングが必要なワークロードが混在することになり、こうしたクラスタを管理する組織には大きな負担となっていました。

新しい GKE では、すべてのクラスタで Autopilot を利用できるようになりました。Autopilot コンピューティングクラスが Standard クラスタでも利用可能になったことで、ワークロードごとにいつでも Autopilot を有効にできます。GKE Autopilot の Container-Optimized Compute Platform（COCP）は、必要なときに必要な容量を最適な価格とパフォーマンスで提供するほか、ニアリアルタイムで垂直方向および水平方向にスケーラブルなコンピューティング環境を実現できます。

これに加え、お客様のインフラストラクチャプロビジョニングを推進するコアコンポーネントの一つである GKE クラスタオートスケーラーをオープンソース化することも発表します。Google の目標は、OSS コミュニティが活用でき、基盤を構築できる、ベンダーに依存しないプラットフォームを提供することです。

CNCF Kubernetes AI Conformance に向けて

この業界が大規模な AI へと移行する中、標準化は極めて重要です。昨年 Google は、Kubernetes コミュニティとともに、クラスタの相互運用性とポータビリティの標準を確立することで Kubernetes 上の AI / ML を簡素化する CNCF Kubernetes AI Conformance プログラムを立ち上げました。このたび、GKE が AI 適合プラットフォームとして認定されたことで、モデルや AI ツールを環境間で移行できるようになりました。

今後の Kubernetes v1.36 リリースに向けて、AI Conformance コミュニティは、AI サービングの進化するニーズに対応するために、高度な推論 Ingress、分離型サービング、高性能ネットワーキングという 3 つの新しい要件を提案しています。Google Cloud は、GKE Inference Gateway、llm-d、DRANET を通じて、これらの新たなコミュニティ規約をサポートすることに尽力しています。

Model Context Protocol: エージェントインターフェース

昨年 Google は、AI エージェントと Kubernetes との連携を効率化するために、オープンソースの GKE Model Context Protocol（MCP）サーバーを発表しました。これは、標準化されたインターフェースを提供することで、明確に定義された機能を通じて、ワークロード、クラスタ、リソースをエージェントが管理、分析、モニタリングできるようにするものです。これらの機能を公開することで、MCP サーバーは Gemini CLI や Antigravity などのさまざまな AI クライアントの統合を容易にするほか、Kubernetes エコシステムの管理の自動化を促進し、よりインテリジェントなものにします。

AI インフラストラクチャとしての Kubernetes

llm-d は正式に CNCF サンドボックスプロジェクトとなり、Kubernetes を最先端の AI インフラストラクチャに進化させるための大きな一歩を踏み出しました。2025 年 5 月に Red Hat や NVIDIA といった業界リーダーとの共同プロジェクトとして立ち上げられた llm-d は、特定のハードウェアやベンダーに依存しないように設計された Kubernetes ネイティブの分散推論フレームワークです。

このプロジェクトでは、推論を考慮したトラフィック管理、マルチノードレプリカのネイティブオーケストレーション、階層型 KV キャッシュオフロードの高度な状態管理について、well-lit paths（明確なパス）を導入することで、複雑な AI オーケストレーションの課題に対処します。クラウドネイティブなオーケストレーションと最先端の AI 研究のギャップを埋めることで、llm-d は高性能 AI サービングを広く普及させ、さまざまなアクセラレータの推論性能に関するオープンで再現可能なベンチマークを確立します。Google は、llm-d に関して CNCF AI Conformance プログラムと連携することで、分散型サービングなどの重要な機能をエコシステム全体で相互運用できるようにする予定です。llm-d について詳しくは、こちらのブログ記事をご覧ください。

DRA はリソース管理の新たな標準です

Kubernetes が誕生した頃は、変化するものは CPU とメモリだけであり、クラウドは無限に伸縮できると考えられていました。現在では、当然ながら、ハードウェアは専門化され、多様化しています。動的リソース割り当て（DRA）は、独自のハードウェアを標準形式で記述するための業界標準ソリューションであり、これにより、上位レベルのワークロードやスケジューラは、リソースに関する低レベルの詳細情報にアクセスすることなく、リソースを最適化できます。このたび、オープンソースでリリースすることを発表しました、TPU 用の DRA ドライバは、AI ワークロードのポータビリティを Kubernetes エコシステムにもたらすうえで重要なマイルストーンとなります。Google と NVIDIA は、統一されたリソース管理標準を確立するための共同の取り組みとして、OSS Kubernetes での DRA の設計と実装について緊密に連携しています。Google は、今回のリリースを、NVIDIA DRA ドライバの寄贈と合わせて発表できることを誇りに思います。これは、GKE のマネージド機能としてすでに利用可能なネットワーキング用の DRA ドライバである DRANET に加えて使用できます。

エージェントの波に対応: 推論とエージェント

エージェント AI の波が押し寄せています。Google は、エージェントの実行に最適なプラットフォームは Kubernetes であると確信しています。LLM が生成したコードを実行し、AI エージェントと安心してやり取りするには、高度な分離、起動時間の短縮、専用のインフラストラクチャが必要です。

Google は、これを実現するために、オープンソースの推論技術に多大な投資を行っています。たとえば、gVisor 対応のセキュアな分離を実現する Kubernetes Agent Sandbox や、ワークロードをメモリスナップショットから復元することで起動レイテンシを大幅に改善する GKE Pod Snapshots などのイノベーションを活用することで、Kubernetes 上のエージェント AI の標準を確立したうえで、GKE で実行されるエージェントのパフォーマンスやコンピューティング効率を高めています。

Kubernetes 上の Ray: TPU と優れたオブザーバビリティ

Ray は、要求の厳しい AI ワークロードをスケールするための標準になりつつあり、Kubernetes は Ray の実行に最適な環境であると Google は考えています。最近まで、公式のアクセラレータサポートは NVIDIA GPU に限定されていましたが、このたび、Anyscale と Google による完全なサポートを備えた Ray v2.55 の TPU を発表しました。

これまで、Kubernetes 上の Ray では、ジョブに関する過去のデータにアクセスできなかったため、デバッグやパフォーマンスの最適化が困難でしたが、この問題を解決するために、RayJob の完了または終了後に問題をデバッグする機能を導入しました。これを実現する Ray History Server は、Kuberay を使用して実行中の RayJob からログ、状態、指標を設定して永続化し、Ray ダッシュボードにそれらを再現できます。Ray History Server（アルファ版）は今すぐお試しいただけます。

ブースにお立ち寄りください

次世代の AI 推論のスケールアップ、高度に分離されたエージェントワークフローのデプロイ、クラスタ全体のコンピューティング容量の最適化など、どのような場合でも、Google は Kubernetes と GKE を究極のプラットフォームにすることに尽力し、お客様を成功に導きます。

KubeCon Europe に参加される方は、ぜひ Google Cloud ブース（#310）にお立ち寄りください。上述の発表について詳しくご説明するほか、セッション、ライトニングトーク、ハンズオンラボ、デモをご覧いただけます。また、テキストベースの冒険ゲームで楽しく競い合うイベントもご用意しています。Kubernetes の未来に乾杯！

- シニアクラウドデベロッパーアドボケイト、Abdel Sghiouar

- GKE プロダクト管理担当ディレクター、Allan Naim

AI インフラストラクチャとしての Kubernetes: Google Cloud、llm-d、CNCF

Fri, 03 Apr 2026 01:00:00 +0000

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

Google Cloud は、大規模な基盤モデルのビルダーや AI ネイティブ企業の膨大なニーズに応えることを、当社の AI インフラストラクチャ戦略の最優先事項としています。生成 AI の利用がミッションクリティカルな本番環境へと移行する中、このようなイノベーターは、複雑なオーケストレーションの課題を克服し、エージェント主導の未来を推進できる、動的かつ絶え間なく効率的なインフラストラクチャを必要としています。

こうした状況を鑑み、このたび、llm-d が Cloud Native Computing Foundation（CNCF）のサンドボックスプロジェクトとして正式に承認されたことを大変嬉しく思います。Google Cloud は、Red Hat、IBM Research、CoreWeave、NVIDIA とともに、llm-d の創設メンバーとして貢献できることを誇りに思います。私たちは、業界を定義する明確なビジョン「あらゆるモデル、あらゆるアクセラレータ、あらゆるクラウド」の下に団結しています。

この貢献は、オープンソースのイノベーションにおける Google の長年のリーダーシップを裏付けるものです。私たちはまた、Linux Foundation の信頼できる管理の下、分散 AI 推論の未来が、閉ざされた環境ではなくオープンスタンダードに基づいて構築されるよう支援しています。これにより、基盤モデルのビルダーは、ベンダーに縛られることなくモデルをグローバルにデプロイできるという確信を得られるとともに、これらのオープンテクノロジーの実装を高度に最適化したうえで Google Cloud で直接行えるようになります。

推論のための Kubernetes の強化

Kubernetes は、オーケストレーションの業界標準として揺るぎない地位を確立しています。強固な基盤を提供しますが、元々は、LLM 推論のために構築されたものではなく、高度にステートフルで動的な要求には対応できませんでした。GKE Inference Gateway は、こうした新しいタイプのワークロードに対応するために Kubernetes を進化させたもので、単純なロードバランシングをはるかに超えるネイティブ API を提供します。このゲートウェイの内部では、スケジューリングインテリジェンスのために llm-d Endpoint Picker（EPP）を活用しています。このシステムでは、ルーティングの決定を llm-d に委任することで、リアルタイムの KV キャッシュヒット率、処理中のリクエスト数、インスタンスキューの深さを考慮した多目的ポリシーを適用し、各リクエストを処理に最適なバックエンドにルーティングします。

大規模に運用する基盤モデルのビルダーにとって、こうしたモデル対応のルーティングがもたらす現実世界への影響は画期的です。最近、Google の Vertex AI チームは本番環境でこのアーキテクチャを検証し、脆弱なカスタムスケジューラに依存することなく、予測が非常に難しいトラフィックを処理できることを証明しました。Qwen Coder を使用したコンテキストを多用するコーディングタスクでは、最初のトークンまでの時間（TTFT）のレイテンシが 35% 以上短縮されました。また、研究目的に DeepSeek を使用してバースト性が高く確率的なチャットワークロードを処理した場合には、P95 テールレイテンシが 52% 改善され、深刻な負荷変動を効果的に吸収できました。特に重要なのは、このゲートウェイのルーティングインテリジェンスにより、Vertex AI の接頭辞キャッシュヒット率が 35% から 70% に倍増したことであり、これにより、再計算のオーバーヘッドとトークンあたりの費用が大幅に削減されました。

インテリジェントなルーティングに加えて、マルチノード AI デプロイをオーケストレートするには、堅牢な基盤となるプリミティブが必要です。そのため、Google では Kubernetes LeaderWorkerSet（LWS）API の開発を主導しています。LWS により、llm-d は広範なエキスパート並列処理をオーケストレートし、計算負荷の高いプリフィルフェーズとメモリ負荷の高いデコードフェーズを、個別にスケーリング可能な Pod に分離できます。業界で広く採用されている LWS は、今では、急速に拡大する本番環境の AI ワークロードのフットプリントをオーケストレートし、グローバル規模で TPU と GPU の大規模なフリートを管理しています。このオーケストレーションを補完するものとして、Google は最近、Cloud TPU 向けに vLLM をネイティブに拡張しました。PyTorch と JAX の統合バックエンドに加え、Ragged Paged Attention v3 などの革新的な機能を備えたこのインテグレーションにより、昨年初めにリリースした最初のバージョンと比較して、スループットが最大 5 倍向上しました。Google Cloud TPU や NVIDIA GPU のどちらでスケールする場合でも、これらの進歩により、最先端の AI サービングが高度に最適化され、アクセラレータに依存しない機能として維持されます。

次世代の AI インフラストラクチャを共同で構築

究極の AI インフラストラクチャを構築するには、クラウドネイティブな Kubernetes オーケストレーションと最先端の AI 研究との間のギャップを埋める必要があります。本番環境レベルの生成 AI への移行には、信頼性と透明性を備えたエンジンが必要であり、可能性の限界を押し広げる AI / ML リーダーとの緊密なコラボレーションも求められます。

私たちは、Linux Foundation、CNCF、PyTorch Foundation、その他のオープンソースコミュニティとともに、次世代の AI インフラストラクチャを構築できることを大変嬉しく思っています。「well-lit paths」（現実的な負荷の下でエンドツーエンドにテストされた、実証済みで再現可能なブループリント）を確立することで、高性能な AI がオープンで誰もがアクセスできるエコシステムとして発展し、境界のないイノベーションを促進できるようにしています。

AI 推論のオープンな未来を一緒に形作りましょう。大規模基盤モデルのビルダー、AI ネイティブ企業、プラットフォームエンジニア、AI 研究者の皆様の参加を心よりお待ちしております。

「well-lit paths」を確認する: llm-d ガイドを参照し、ご自身のインフラストラクチャに SOTA 推論スタックを今すぐデプロイしましょう。
詳細: 公式ウェブサイト（https://llm-d.ai/）をご覧ください。
ご協力のお願い: Slack のコミュニティに参加し、GitHub リポジトリ（https://github.com/llm-d/）での活動にご協力ください。

llm-d の CNCF サンドボックスプロジェクトへの参加をお待ちしております。皆様とともにこのエンジンを発展させていくことを楽しみにしています。

- プロダクトマネージャー、Sean Horgan

- シニアクラウドデベロッパーアドボケイト、Abdel Sghiouar

DRA: 動的リソース割り当てが切り開く Kubernetes デバイス管理の新時代

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

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

大規模言語モデル（LLM）の爆発的な普及により、GPU や TPU などの高性能アクセラレータの需要が高まっています。組織が AI 機能を拡大させる中で、コンピューティングリソースの不足が主要なボトルネックとして浮上することがあります。すべての GPU と TPU のサイクルを効率的に管理することは、もはや推奨事項ではなく、運用上の必要事項となっています。

Kubernetes は、企業が LLM を実行する際の事実上の標準プラットフォームになりつつあります。今週開催された KubeCon Europe において、NVIDIA は GPU 用の動的リソース割り当て（DRA）ドライバを、Google は Tensor Processing Unit（TPU）用の DRA ドライバをそれぞれ Kubernetes コミュニティに寄贈しました。このことは、より広範なコミュニティの育成とイノベーションの加速を実現し、Kubernetes が最新のクラウド環境に対応して AI ワークロードのポータビリティを向上させることにつながります。DRA は Google Kubernetes Engine（GKE）でも一般提供されています。このブログ記事の残りの部分では DRA について掘り下げ、DRA が構築された理由、DRA でできること、DRA の使用方法について説明します。

静的なインフラストラクチャからの脱却

長年にわたり、ハードウェアアクセラレータを使用するには、Kubernetes のデバイスプラグインフレームワークを利用するのが標準的な方法でした。ただし、デバイスプラグインでは、ハードウェア要件を単純な整数（例: gpu: 1）としてしか表現できないため、フラクショナル GPU は使用できません。これでは、現代の複雑なワークロードに求められる微妙できめ細かな調整を行うには不十分です。また、デバイスプラグインでは、Pod のスケジューリングに先立って、クラスタにアクセラレータを事前プロビジョニングさせておく必要があります。

Kubernetes におけるリソース管理の新標準である DRA は Kubernetes OSS 1.34 で「安定版」のステータスに昇格しました。DRA は、ハードウェアの処理方法において、静的な割り当てから柔軟なリクエストベースのモデルへの移行というパラダイムシフトを体現しています。これにより、次のような課題が解決されます。

手動によるノードの固定が不要: デバイスプラグインフレームワークでは、アプリオペレーターは、特定のハードウェアを搭載したノードを自分で調べてから、nodeSelector またはアフィニティを使用して、Pod がそのノードに配置されるようにする必要がありました。DRA は、スケジューラが特定のハードウェア機能をネイティブに認識できるようにすることで、このプロセスを自動化します。リクエストに基づいてワークロードに適したノードを検出するため、ユーザーがクラスタのトポロジをマッピングする必要はありません。
柔軟なパラメータ化: デバイスプラグインの「全か無か」のアプローチとは異なり、DRA では、ResourceClaim を使用して、最小 VRAM 量、特定のハードウェアモデル、相互接続要件などの特定の要件を定義できます。これにより、高価なハードウェアをよりきめ細かく効率的に使用できます。
DeviceClass を介したハードウェアの抽象化: DRA は、ハードウェアの「ブループリント」として機能する DeviceClass を導入します。プラットフォーム管理者は、デベロッパーが名前でリクエストするクラス（例: high-memory-gpu や low-latency-fpga）を定義できます。これにより、基盤となるハードウェアアドレスからワークロードのニーズが切り離されます。これは、スケジューラがワークロードの要件と利用可能なハードウェアインベントリのマッチングを行うことを可能にします。

詳細解説: DRA の仕組み

DRA の中核をなすのは ResourceSlice と ResourceClaim です。これら 2 つの主要な構成要素は、ハードウェアインベントリとワークロード要件を分離します。これらは、Kube-scheduler が適切な意思決定を行い、より柔軟なリソースプールを実現するために使用する入力です。

ResourceSlice: 可用性の記述

ResourceSlice API は、基盤となるハードウェアの機能と属性をリソースドライバがクラスタに公開するために使用されます。デバイスプラグインが単純なラベルを使用することでデバイスの詳細を覆い隠しがちであるのと対照的に、ResourceSlice は利用可能なアセットを忠実に記述します。これにより、ドライバは各デバイスに関する以下のような詳細情報を報告できます。

容量: 合計メモリ、コア数、または特殊なコンピューティング単位数
属性: アーキテクチャ、バージョン、PCIe ルートコンプレックスまたは NUMA ノード

ResourceClaim: 要件の定義

ResourceClaim API を使用すると、AI エンジニアはアプリケーションを正常に実行するために必要なものを正確に定義できます。ResourceSlice API がデバイスの詳細を公開するため、開発者は一般的なリクエストにとどまらず、次の項目に基づく要件の指定を行うことができます。

属性ベースの選択: 特定のモデルを指定する代わりに、ユーザーは「40 GB 以上の VRAM を備えた GPU」という風にリクエストできます。
複雑な制約: DRA はデバイス間の制約をサポートします。たとえば、ハイパフォーマンスコンピューティングジョブでは、レイテンシを最小限に抑え、スループットを最大化するために、GPU と NIC の両方が同じ PCIe ルートコンプレックスに接続されているという要件のもとに、GPU と NIC をリクエストできます。

能力ベースのアプローチによるスマートなスケジュール設定

DRA は、「何」（ResourceClaim）を「どこ」（ResourceSlice）から切り離すことで、デバイスのマッチングの負担をユーザーから Kube-scheduler に移します。

以前までは、ユーザーは適切なハードウェアに Pod を配置するために、手動のノードセレクタや taint に頼らざるを得ないことがほとんどでした。DRA を使用すると、スケジューラはデバイスの属性とクラスタのトポロジを全体的な視点から把握できるようになります。これにより、より「流動的な」リソースプールが可能になります。スケジューラは、利用可能なすべてのスライスをクレームの特定の基準に基づいて評価し、静的なラベルではなく実際のハードウェアの可用性に基づいて配置を最適化できます。

この能力ベースのアプローチによって利用可能なハードウェアのうち最適なものにワークロードを確実に割り当てられるようになり、リソース使用率とアプリケーションパフォーマンスの両方が向上します。

DRA の動作を確認するには、Google デベロッパーフォーラムのこちらのブログ記事をご覧ください。このブログ記事では、環境設定、GKE クラスタの作成、ドライバのインストール、レプリカのスケーリングなど、カスタム ComputeClass を使用して GPU をスケールする方法を紹介しています。

1.35 のリリースでは、AI / ML ワークロードと最新のユースケースの新しい標準を確立するために、Kubernetes AI Conformance プログラムが作成されました。DRA のサポートは、この新しい基準の要となるため、最初の必須要件として特定されました。

ぜひお試しください

Kubernetes ワークロードがより複雑でミッションクリティカルになるにつれて、柔軟でインテリジェントかつ使いやすいリソース管理の実現が重要になっています。GKE の DRA は、要求の厳しい動的な環境でハードウェアリソースを最適化する際に手作業や当て推量に頼る必要性を排除します。DRA の詳細と利用方法については、以下のリソースをご覧ください。

- シニアソフトウェアエンジニア、Morten Torkildsen

- シニアプロダクトマネージャー、Bo Fu

マルチクラスタ GKE Inference Gateway のご紹介: 世界中で AI ワークロードをスケール

Wed, 25 Mar 2026 03:00:00 +0000

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

AI の世界は急速に変化しており、モデルのサービングを大規模かつ確実に行う必要性も高まっています。このたび、マルチクラスタ GKE Inference Gateway のプレビュー版がリリースされましたのでお知らせいたします。これにより、複数の Google Kubernetes Engine（GKE）クラスタにわたり（異なる Google Cloud リージョンにまたがる場合も含め）、AI / ML 推論ワークロードのスケーラビリティ、復元力、効率性を強化できます。

GKE Gateway API の拡張機能として構築されたマルチクラスタ Inference Gateway は、マルチクラスタ Gateway の機能を活用して、特に要求の厳しい AI アプリケーション向けに、モデル対応のインテリジェントなロードバランシングを提供します。

AI 推論にマルチクラスタを使用する理由

AI モデルの複雑性が増し、ユーザーのグローバル化が進むにつれて、単一クラスタのデプロイでは次のような課題に直面する可能性があります。

可用性のリスク: リージョンの停止やクラスタのメンテナンスがサービスに影響を及ぼす可能性があります。
スケーラビリティの上限: 単一のクラスタまたはリージョン内で、ハードウェアの上限（GPU / TPU）に達してしまいます。
リソースのサイロ化: あるクラスタで十分に活用されていないアクセラレータ容量を別のクラスタで使用できません。
レイテンシ: サービスを提供しているクラスタから離れているユーザーはレイテンシが高くなる可能性があります。

マルチクラスタ GKE Inference Gateway は、これらの課題に正面から取り組み、次のようなさまざまな機能とメリットを提供します。

信頼性とフォールトトレランスの強化: 異なるリージョン間を含め、複数の GKE クラスタにわたってトラフィックをインテリジェントにルーティングします。1 つのクラスタまたはリージョンで問題が発生した場合、トラフィックは自動的に再ルーティングされ、ダウンタイムが最小限に抑えられます。
スケーラビリティの向上とリソース使用量の最適化: さまざまなクラスタから GPU / TPU リソースをプールして活用できます。単一クラスタの容量を超えてバーストすることで需要の急増に対応し、利用可能なアクセラレータをフリート全体で効率的に活用できます。
グローバルに最適化されたモデル対応のルーティング: Inference Gateway は、高度なシグナルを使用してスマートなルーティング判断を下すことができます。GCPBackendPolicy を使用して、リアルタイムのカスタム指標（モデルサーバーの KV キャッシュ使用率指標など）に基づいてロードバランシングを構成できるので、最適なバックエンドインスタンスにリクエストが送信されるようになります。処理中リクエストの制限など、他のモードもサポートされています。
運用の簡素化: モデルを複数の「ターゲットクラスタ」で実行しながら、専用の GKE「構成クラスタ」で 1 つの Inference Gateway 構成を使用して、グローバルに分散された AI サービスへのトラフィックを管理できます。

仕組み

GKE Inference Gateway には、InferencePool と InferenceObjective という 2 つの基本リソースがあります。InferencePool は、同じコンピューティングハードウェア（GPU や TPU など）とモデル構成を共有する Pod のリソースグループとして機能し、スケーラブルで高可用性のサービングを実現します。InferenceObjective は、特定のモデル名を定義し、サービングの優先順位を割り当てます。これにより、Inference Gateway はトラフィックをインテリジェントにルーティングし、レイテンシの影響を受けやすいタスクと緊急性の低いワークロードを多重化できます。

このリリースでは、Kubernetes カスタムリソースを使用して、分散推論サービスが管理されます。各「ターゲットクラスタ」の InferencePool リソースは、モデルサーバーのバックエンドをグループ化します。これらのバックエンドはエクスポートされ、「構成クラスタ」で GCPInferencePoolImport リソースとして表示されます。構成クラスタ内の標準の Gateway リソースと HTTPRoute リソースは、エントリポイントとルーティングルールを定義し、トラフィックをこれらのインポートされたプールに転送します。CUSTOM_METRICS や IN_FLIGHT リクエストの使用など、きめ細かいロードバランシングの動作は、GCPInferencePoolImport にアタッチされた GCPBackendPolicy リソースを使用して構成されます。

このアーキテクチャにより、グローバルな低レイテンシのサービング、障害復旧、容量のバースト、異種ハードウェアの効率的な使用などのユースケースが可能になります。

GKE Inference Gateway のコアコンセプトについて詳しくは、ガイドをご覧ください。

使ってみる

AI 推論サービングワークロードをより多くの場所とより多くのユーザーにスケールする際に、マルチクラスタ GKE Inference Gateway をぜひお試しください。詳細と利用方法については、次のドキュメントをご覧ください。

- シニアプロダクトマネージャー、Arman Rye

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

AI ネイティブなコア: Google Kubernetes Engine を使用した、レジリエンスの高い通信事業者向けアーキテクチャ

Mon, 16 Mar 2026 03:00:00 +0000

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

通信業界は重要な転換点を迎えています。従来のオンプレミス中心のデータセンターモデルは、インフラストラクチャ費用の高騰と、可用性およびコンプライアンス要件による利用率の低さという重圧に苦しんでいます。しかし、AI の時代には、指数関数的なスケールと 99.9999999% を超える信頼性が求められます。通信事業者が考えるべきは、モダナイズするかどうかではなく、どのアーキテクチャパスが最も迅速にモダナイズできるかです。

モダナイゼーションは「完全な置き換え」のイベントではなく、戦略的な選択です。今回は、Google Kubernetes Engine（GKE）が、クラウド中心の進化と戦略的なハイブリッドモダナイゼーションという 2 つの汎用性の高いデプロイ戦略の高性能な基盤としてどのように機能するかをご紹介します。

ネットワークモダナイゼーションの 2 つの方法

すべての通信事業者は、リスク許容度、規制環境、投資基盤がそれぞれ異なります。アジリティを優先する通信事業者もいれば、ローカルな制御の必要性を重視する通信事業者もいます。GKE を使用すれば、両方のアプローチに対応できます。

1. クラウド中心のモダナイゼーション: 大規模なアジリティ

この方法は、クラウドの弾力性を最大限に活用したい通信事業者向けです。独自のコンテナ化されたネットワーク機能（CNF）を移行する場合でも、Ericsson-on-Demand のようなクラウドネイティブサービスを構築する場合でも、目標は同じです。それは、重い処理を Google Cloud に移行することです。

メリット: 音声コアやポリシー制御機能などのミッションクリティカルなワークロードを Google のグローバルファイバーバックボーンで実行することで、ピーク時のイベントに合わせて即座にスケールし、「ゼロヒューマンタッチ」運用に移行できます。
経済性: 多額の初期投資を必要とする CapEx から「成長に応じた支払い」モデルに移行できます。アイドル状態のハードウェアを過剰にプロビジョニングする必要はなく、クラウドが突発的な負荷を吸収してくれます。
製品化までの時間: 固定無線アクセス、IoT、プライベート 5G などの新しいサービスの製品化までの時間を短縮できます。

2. 戦略的なハイブリッドモダナイゼーション: クラウドのアジリティ、ローカルな制御

多くの通信事業者にとって、ハイブリッドアプローチはより優れたバランスを提供します。ハイブリッドアプローチでは、通信事業者は、アジャイルなコントロールプレーンコンポーネントとデータ分析を選択的にクラウドに移行しながら、レイテンシの影響を受けやすいユーザープレーン機能をオンプレミスまたはエッジに保持できます。

メリット: データプレーントラフィックをローカルに保持することで、超低レイテンシの最適化と厳格なデータ主権要件を満たしつつ、クラウドの AI による分析情報とオーケストレーション機能を活用できます。
汎用性: GKE を使用すると、コントロールプレーンのワークロードをクラウドで実行し、データプレーンサービスを独自のデータセンターまたはネットワークエッジで直接実行できます。これにより、環境全体で統一された運用モデルを構築できます。

「通信事業者グレード」の基盤のエンジニアリング

このブログ投稿では、GKE が通信事業者や機器ベンダーパートナーからの大きな勢いに支えられ、コンテナ化されたネットワーク機能（CNF）向けの業界で最も特化したプラットフォームへと進化してきた様子をご紹介します。

さまざまな機能のおかげで、これを実現しています。

接続と分離

標準の Kubernetes は、通信事業者が必要とする複雑なトラフィック分離を想定して設計されていません。GKE は、次の機能でこのギャップを埋めます。

マルチネットワーキング API: Pod ごとに複数のインターフェースを管理するネイティブの Kubernetes の手法。標準のネットワークポリシーをすべてのインターフェースに適用します。
シミュレートされた L2 ネットワーキング: 最新のクラウドネイティブなスタックで実行しながら、従来のアプリケーションがレイヤ 2 の運用モデルを維持できる「移行のスーパーパワー」。
通信事業者向け CNI: 特化型 Ubuntu イメージで Multus、IPvlan、Whereabouts をサポート。これにより、管理プレーン、制御プレーン、ユーザープレーンを外科手術のように正確に分離できます。

永続的なネットワーク到達性

エフェメラルなコンテナの世界では、通信事業者の機能には安定性が求められます。GKE は、以下を通じてこれを実現します。

GKE IP ルート: 等価コストマルチパス（ECMP）のような機能を GKE データプレーンに直接統合しました。ワークロードに障害が発生すると、サービスパスから自動的かつ迅速に削除されるため、複雑な外部ルーター構成なしで高可用性を実現できます。
永続 IP: GKE は、5G コア機能がライフサイクル全体で一貫したネットワーク到達性を確保するために必要な静的 IP サポートを提供します。標準の Kubernetes では利用できない NAT を使用しません。

1 秒未満の収束

通信事業者にとって、ミリ秒単位のダウンタイムは接続の喪失を意味します。HA ポリシーを介した GKE のデータプレーンは、超高速の障害検出と収束により、ほぼゼロのダウンタイムを実現するように最適化されています。通信事業者は、自己管理による復旧と Google による完全管理の障害検出のどちらかを選択できます。

AI で「節約」から「解決」へ

通信事業者にとって、モダナイゼーションの最終的な目標は、自律型ネットワークへの移行です。Vertex AI や BigQuery などの Google Cloud AI およびデータプラットフォームに隣接するプラットフォームでコアネットワーク機能を実行することで、テレメトリーをネットワーク最適化の実用的な変更に変えることができます。モダナイゼーションによって実現するユースケースとメリットには、次のようなものがあります。

予測 AIOps: AI を使用してパフォーマンスの低下を特定し、通話が切断される前に自動修復をトリガーします。スポーツイベントやサービスのリリース時に、クラウドを使用してオンデマンドのバースト容量を確保します。また、GKE でホストされる 5G コアのデータを使用して、AI を活用した自動化を促進し、問題が加入者に影響を与える前に予測します。
インテント主導のプログラマビリティ: 費用のかかる事後対応型の運用から移行し、新しいデプロイのセットアップ時間を数週間から数時間に短縮します。
分析情報の収益化: クラウドネイティブなデータに AI を活用して、ネットワークの適正化に加えて、まったく新しい収益機会を特定して獲得します。

貴社の戦略に合わせた変革を

通信業界の未来は、インテリジェントでレジリエンスに優れ、非常に柔軟なものになるでしょう。ハイブリッドデプロイへの第一歩を踏み出す場合でも、クラウドで完全にホストされるコアを立ち上げる場合でも、Google Cloud は貴社の戦略的パートナーとなります。

MWC にぜひご参加ください。ホール 2 のブース #2H40 では、GKE で動作するモバイルコアのライブデモなど、各種ソリューションの事例をご覧いただけます。

- Google Cloud、シニアプロダクトマネージャー、Abhi Maras

- Google Cloud、ソフトウェアエンジニア、Maciej Skrocki

独自の成長を促進: GKE のカスタム指標のネイティブサポートを導入

Fri, 13 Mar 2026 01:00:00 +0000

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

プラットフォームエンジニア、AI インフラストラクチャリードおよび開発者が Kubernetes で実行されるワークロードの自動スケーリングについて考えるとき、その目標は単純です。必要なときに、必要な容量を、最適な料金で手に入れることです。

しかし、CPU とメモリに基づくスケーリングは比較的簡単ですが、キューの深さやアクティブなリクエストなどのアプリケーションシグナルに基づくスケーリングは簡単ではありません。従来、このようなスケーリングは、モニタリング、IAM、特定のエージェント構成など、さまざまな手順を複雑に組み合わせて実現していたため、運用上のオーバーヘッドが大きくなっていました。

この摩擦を解消するために、このたび、Google Kubernetes Engine（GKE）で実行される HorizontalPodAutoscaler（HPA）のカスタム指標がネイティブにサポートされるようになりました。これは、カスタムワークロードシグナルをネイティブの GKE 機能へと高める新機能です。

現在の課題: カスタム指標に関わる「税金」

カスタム指標（アクティブなリクエスト、KV キャッシュ、ゲームサーバーのプレーヤー数など）に基づいてワークロードをスケールしようとしたことがある方なら、このアーキテクチャが非常に手間のかかるものであることをご存じでしょう。YAML を数行記述するだけでなく、複数の異種システムを連携させる必要があります。

現在、カスタム指標に基づいて HorizontalPodAutoscaler をスケールするには、複数のコンポーネントを構成する必要があります。

1. 指標をエクスポートする: まず、Pod が指標を Cloud Monitoring、Google マネージド Prometheus、または使用しているモニタリングシステムに送信（エクスポート）するように構成します。

2. 「仲介役」を構成する: 次に、クラスタに custom-metrics-stackdriver-adapter または prometheus-adapter をインストールして管理し、Cloud Monitoring と HPA の間のトランスレータとして機能させます。これらのアダプタの構成は必ずしも簡単ではなく、保守は複雑でエラーが発生しやすくなります。

3. 難しい IAM に対応する: これは多くの場合、最大のハードルです。エクスポートした指標をアダプタが読み取れるようにするには、次の手順が必要です。

◦ クラスタで Workload Identity 連携を有効にする。

◦ Google Cloud IAM サービスアカウントを作成する。

◦ Kubernetes サービスアカウントを作成してアノテーションを付ける。

◦ IAM ポリシーバインディングを使用して 2 つのアカウントをバインドする。

◦ 特定の IAM ロールを付与する。

4. 運用リスクを管理する: 自動スケーリングロジックを構成すると、そのロジックはオブザーバビリティスタックが利用可能であることに依存するようになります。指標の取り込みが遅れたり、アダプタが失敗したりすると、スケーリングが中断されます。

つまり、本番環境が突然モニタリングに左右されるようになります。モニタリングシステムは重要なインフラストラクチャの一部であり、本番環境の重要な要素ですが、モニタリングシステムが失敗しても、通常は本番環境の稼働を継続できます。ただし、この構成では、自動スケーリングメカニズムがモニタリングシステムに依存するようになります。モニタリングシステムの読み取りまたはシステム自体が失敗すると、ワークロードは自動スケールできなくなります。これにより、スケーリングロジックが外部のオブザーバビリティスタックの可用性に結び付けられるという、固有の運用上のリスクが生じます。ほとんどの IT ベストプラクティスでは、このような循環依存関係は推奨される構成ではありません。トラブルシューティングが複雑になり、サービスの全体的な復元力が低下するためです。

さらに、カスタム指標に基づいてスケールするように HPA を構成することは、これまで非常に煩雑で、エラーが発生しやすかったため、Kubernetes ユーザーはサードパーティソリューションを採用することがよくありました。サードパーティのソリューションとその複雑な設定の管理と同期は、GKE の更新またはアップグレードサイクルに合わせるのが難しい場合があります。

エージェントレス、ネイティブの自動スケーリング

GKE のカスタム指標のネイティブサポートにより、「仲介役」が不要になり、自動スケーリングのフローが根本的に再設計されました。リアルタイムのカスタム指標に基づくワークロードのスケーリングは、メモリや CPU に基づくスケーリングと同じくらい簡単になり、モニタリングシステム、アダプタ、サービスアカウント、IAM ロールに対する複雑な循環依存関係はなくなりました。

エージェント、アダプタ、複雑な IAM は不要: カスタム指標は Pod から直接取得され、HPA に配信されます。このエージェントレスアーキテクチャでは、カスタム指標アダプタを維持したり、複雑な Workload Identity バインディングを管理したりする必要がなくなります。

カスタム指標のネイティブサポート:

AI 推論、金融サービス、小売、ゲームなど、要求の厳しいワークロードを実行する組織にとって、この更新は大きな変化をもたらします。

「仲介役」は不要: アダプタ、サイドカー、IAM ロールバインディングの複雑さを解消します。アプリケーションが指標を公開すると、GKE はその指標に基づいてスケールできます。
レイテンシの短縮: 外部モニタリングシステムへのラウンドトリップが不要になるため、HPA の反応が大幅に速くなります。これは、トラフィックの急増時に需要の高いサービスのパフォーマンスが低下するのを防ぐために重要です。
高い費用効率: 自動スケーリングの決定にのみ使用される指標の取り込み費用を支払う必要がなくなります。スケーリングイベントへのより正確かつ迅速な対応は、コンピューティングリソースの節約にもつながります。
信頼性の向上: スケーリングロジックが外部のオブザーバビリティスタックの稼働時間に依存しなくなり、クラスタ内で自己完結します。

新しいコントローラを使用すると、HPA がスケーリングに使用する指標を簡単に構成できるため、指標の収集を簡素化できます。

code_block: <ListValue: [StructValue([('code', 'apiVersion: autoscaling.gke.io/v1beta1\r\nkind: AutoscalingMetric\r\nmetadata:\r\n name: vllm-autoscaling-metric\r\n namespace: autoscaling-metrics\r\nspec:\r\n metrics:\r\n - pod:\r\n selector:\r\n matchLabels:\r\n app: vllm-metrics\r\n containers:\r\n - endpoint:\r\n port: metrics\r\n path: /metrics\r\n metrics:\r\n - gauge:\r\n name: kv_cache_usage_perc\r\n prometheusMetricName: vllm:kv_cache_usage_perc\r\n filter:\r\n matchLabels:\r\n label: v1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fed0afcaa00>)])]>

この構成を作成したら、AutoscalingMetric コントローラを使用して、定義したばかりの指標に HPA を設定するだけです。

code_block: <ListValue: [StructValue([('code', 'apiVersion: autoscaling/v2\r\nkind: HorizontalPodAutoscaler\r\n...\r\nmetrics:\r\n - type: Pods\r\n pods:\r\n metric:\r\n name: autoscaling.gke.io|vllm-autoscaling-metric|kv_cache_usage_perc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fed0afcabb0>)])]>

これで完了です。GKE のカスタム指標のネイティブサポートにより、任意のワークロードからゲージ指標を選択し、HPA のトリガー値として使用できます。この 2 つの簡単なステップで、上で説明した設定のプロセス全体が置き換えられます。

ぜひお試しください

GKE のカスタム指標のネイティブサポートは、インテントベースの自動スケーリング に向けた取り組みの第一歩にすぎません。インテントベースの自動スケーリングでは、現在 SLO を定義するのと同様に、ワークロードに必要なパフォーマンスを簡単に定義できます。LLM の GPU 使用率の最適化、バースト性の高いバッチジョブの管理、高度にスケールするエージェントワークロードや、その他のミッションクリティカルなサービスの実行の際に、GKE では CPU やメモリのリソース指標を使用するのではなく、実際のワークロード指標に基づいてスケーリング戦略をシンプルかつ効率的に実現できるようになりました。ネイティブのカスタム指標の使用を開始するには、ドキュメントをご覧ください。

- GKE、シニアプロダクトマネージャー、Valentin Hamburger

- ソフトウェアエンジニア、Nabil Dabouz

GKE Inference Gateway で Vertex AI のレイテンシを 35% 削減した方法

Fri, 13 Feb 2026 03:00:00 +0000

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

生成 AI が試験運用から本番環境に移行するにつれて、プラットフォームエンジニアは、低レイテンシ、高スループット、管理可能なコストの実現という、推論サービングに関する共通の課題に直面します。

バランスを取るのは簡単ではありません。トラフィックパターンは、大量のデータを処理する必要がある複雑なコーディングタスクから、即座の返信が求められるくだけた会話まで、多岐にわたります。標準的なインフラストラクチャでは多くの場合、両方を効率的に処理するのは簡単ではありません。

Google のソリューション: この問題を解決するため、Vertex AI エンジニアリングチームは GKE Inference Gateway を採用しました。標準の Kubernetes Gateway API をベースに構築された Inference Gateway は、2 つの重要なインテリジェンスレイヤを追加することで、スケーリングの問題を解決します。

負荷認識ルーティング: モデルサーバーの Prometheus エンドポイントからリアルタイムの指標（KV キャッシュ使用率など）を直接スクレイピングし、リクエストを最も迅速に処理できる Pod にルーティングします。
コンテンツ認識ルーティング: リクエストの接頭辞を検査し、そのコンテキストが KV キャッシュにすでに存在する Pod にリクエストをルーティングすることで、費用のかかる再コンピューティングを回避します。

Vertex AI は、本番環境のワークロードをこのアーキテクチャに移行することで、この二重型のインテリジェンスが大規模なパフォーマンスを実現する鍵であることを証明しています。

ここでは、Vertex AI によってサービングスタックがどのように最適化されたかについて説明し、これらのパターンを独自のプラットフォームに適用して厳格なテールレイテンシ保証を実現する方法、キャッシュ効率を最大化してトークンあたりのコストを削減する方法、カスタムスケジューラの構築に伴うエンジニアリングオーバーヘッドを排除する方法をご紹介します。

結果: 本番環境規模で実証済み

Vertex AI モデルサーバーの前に GKE Inference Gateway を配置することで、標準的なロードバランシングアプローチと比較して、速度と効率の両面で大きな成果を上げることができました。

これらの結果は、コンテキストを多用するコーディングエージェントから高スループットの会話モデルまで、さまざまな AI ワークロードの本番環境トラフィックで実証されました。

レスポンス速度が 35% 向上: GKE Inference Gateway を使用することで、Vertex AI は Qwen3-Coder の最初のトークンまでの時間（TTFT）のレイテンシを 35% 以上短縮しました。
テールレイテンシが 2 分の 1 に改善: バースト性の高いチャットワークロードの場合、Vertex AI は GKE Inference Gateway を使用することで、Deepseek V3.1 の最初のトークンまでの時間（TTFT）P95 レイテンシを 2 分の 1（52%）に改善しました。
効率が 2 倍: ゲートウェイの接頭辞キャッシュ保存対応機能を活用することで、Vertex AI は GKE Inference Gateway を採用して接頭辞キャッシュヒット率を 2 倍（35% から 70%）にしました。

詳細: 高パフォーマンスなサービングのための 2 つのパターン

本番環境グレードの推論ルーターの構築は、AI トラフィックが単一のプロファイルではないため、見かけよりも複雑です。Vertex AI では、ワークロードが 2 つの異なるトラフィックパターンに分類され、それぞれに異なる最適化戦略が必要であることがわかりました。

コンテキストを多用するワークロード（コーディングエージェントなど）: これらのリクエストには、持続的なコンピューティング負荷を生み出す大規模なコンテキストウィンドウ（コードベース全体の分析など）が含まれます。ここでボトルネックとなるのは、再コンピューティングのオーバーヘッドです。
バースト性の高いワークロード（例: チャット）: これは、短いクエリの予測不可能で確率的な急増です。ここでボトルネックとなるのは、キューの輻輳です。

両方のトラフィックプロファイルを同時に処理するために、Vertex AI が GKE Inference Gateway を使用して解決した 2 つの具体的なエンジニアリング上の課題を以下に示します。

1. 多目的ロードバランシングのチューニング

標準的なラウンドロビンロードバランサは、特定のプロンプトのキャッシュされた KV ペアをどの GPU が保持しているかを認識しません。これは、キャッシュミスが発生すると大量の入力を最初から再処理しなければならなくなる「コンテキストを多用する」ワークロードでは特に非効率的です。ただし、キャッシュアフィニティのみを考慮したルーティングは危険な場合があります。全員が同じ人気のドキュメントをリクエストすると、1 つのノードが過負荷になり、他のノードはアイドル状態になります。

解決策: GKE Inference Gateway の多目的チューニングでは、競合するシグナルのバランスをとる構成可能なスコアラーを使用します。新しいチャットモデルのロールアウト中、Vertex チームは prefix:queue:kv-utilization の重みを調整しました。

比率をデフォルトの 3:3:2 から 3:5:2 に変更（キューの深さをわずかに優先）することで、キャッシュヒットが発生した場合でも、スケジューラが「ホット」ノードをバイパスするようにしました。この構成変更により、トラフィックの分散がすぐにスムーズになり、高い効率が維持されました。接頭辞キャッシュヒット率は 35% から 70% に倍増しました。

2. バースト性の高いトラフィックのキュー深度の管理

推論プラットフォームは、特に突然の同時バーストによる負荷の変動に対処するのが難しいことがよくあります。保護がないと、これらのリクエストによってモデルサーバーが飽和状態になり、リソースの競合が発生して、キュー内のすべてのユーザーに影響が及ぶ可能性があります。

解決策: これらのリクエストがモデルサーバーに直接到達するのを防ぐために、GKE Inference Gateway は、Ingress レイヤでアドミッションコントロールを適用します。キューを上流で管理することで、個々の Pod がリソース不足になるのを防ぐことができます。

データは価値を証明しています。レイテンシの中央値は安定したままですが、P95 レイテンシが 52% 改善されたことは、負荷が高いときに AI アプリケーションを悩ませることの多い分散をゲートウェイがうまく吸収したことを示しています。

プラットフォーム構築者にとっての意味

ここから得られる教訓は、スケジューラを再発明する必要はないということです。

カスタムインフラストラクチャを維持する代わりに、GKE Inference Gateway を使用できます。これにより、Google 社内のワークロードで実績のあるスケジューラにアクセスできるようになり、メンテナンスのオーバーヘッドなしで、飽和から確実に保護できます。

準備ができたら、GKE Inference Gateway をワークロード用に構成する方法をご確認ください。

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

- ソフトウェアエンジニア、Yao Yuan

ノードプールの高速な同時自動作成により GKE クラスタの自動スケーリングを加速

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

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

このたび、Google Kubernetes Engine（GKE）におけるノードプールの同時自動作成機能をリリースしました。これにより、プロビジョニングのレイテンシが大幅に減少し、自動スケーリングのパフォーマンスが向上します。社内ベンチマークでは、プロビジョニング速度が最大 85% 向上しています。デプロイ時間が短縮され、グッドプットが向上するため、特に異種ワークロード、マルチテナントクラスタ、複数の ComputeClass 優先度を使用するワークロード、大規模な AI トレーニングワークロードで効果を発揮します。この機能改良はすでに組み込まれており、保留中の Pod のノードプールを GKE が自動的に作成できるように設定すると適用されます。

問題点

GKE のノードプールは、同じ構成のノードをグループ化し、サイズ変更やアップグレードなどのオペレーションを統合します。空のノードプールの新規作成には 30～45 秒かかります。GKE では、Pod のリソースのニーズに基づいて、ノードプールの作成を自動化できます。

GKE ノード自動プロビジョニング（NAP）の以前のバージョンでは、オペレーションを 1 つずつ実行していたため、デプロイとスケーリングのレイテンシが増加していました。この点は、複数のノードプールを必要とするクラスタで特に顕著でした。新しいノードプールを 1 つ作成するのに必要な 30～45 秒が積み重なって、クラスタの自動スケーリングの全体的な応答性に影響を与えていました。ノードプールの作成中、他のノードプールのオペレーションは待機する必要がありました。

GKE ノードプールの自動作成機能は、Autopilot クラスタと Standard クラスタのどちらで使用するかにかかわらず、Autopilot モードの中核となる機能です。また、GKE Standard モードで運用している場合でも、必要に応じて使用できます。Autopilot によって新しい仮想マシン（VM）シェイプが追加されるたびに、内部で自動的にノードプールが作成されます。

解決策

ノードプールの同時作成がサポートされることで、システムが複数のオペレーションを同時に処理できるようになり、これまでより迅速にクラスタをデプロイして、さまざまなノードタイプにスケールアウトできます。この機能改良は、バージョン 1.34.1-gke.1829001 以降で有効です。GKE を最新バージョンにアップグレードするだけで、この機能改良をご利用いただけます。追加の構成は必要ありません。

ベンチマークを実行して結果を直接確認する場合は、ベンチマークコードをご覧ください。

ノードプールの同時作成が重要な理由

ノードプールの同時自動作成は、幅広い GKE ユースケースに大きなメリットをもたらします。

異種ワークロードとマルチテナントクラスタ - AI や ML を含む多くのワークロードでは個別のノードプールが必要であり、1 つのクラスタで複数のテナントに対応することがよくあります。この結果、構成が異なる複数のノードプールが必要になり、これらを 1 つのクラスタ内で迅速かつ効率的にデプロイまたは管理しなければなりません。
AI ワークロードとマルチホスト TPU スライス - 多くのマルチホスト TPU スライスを使用するワークロードでは、スライスごとに個別のノードプールが必要です。複数の新しいノードプールを迅速かつ同時に作成できるため、スケーリングを迅速に行うことができます。一般に、ノードプールが同時に自動作成されることで、AI ワークロードはプロビジョニングのパフォーマンスとリソース使用率（グッドプット）の向上という恩恵を受けることができます。
スポットインスタンスと複数の ComputeClass 優先度による費用の最適化 - プリエンプティブルノードは、構成が同一であっても、プリエンプティブルでないノードプールとは別のノードプールに分離する必要があります。一般に、カスタム ComputeClass 優先度は通常、別々のノードプールで表されます。つまり、クラスタには多くの場合、異なる優先度に対応する個別のノードプールがあります。並列処理を使用することで、これらのシナリオにより適切に対処できるようになりました。

プロビジョニングの高速化と起動時間の短縮

Google Cloud は、お客様の GKE 環境のパフォーマンス強化に尽力しています。ノードプールの同時自動作成は、プロビジョニングのパフォーマンスを向上させる取り組みの一つです。また、高速起動ノードによるノード起動レイテンシの改善、イメージストリーミングによるコンテナ pull レイテンシの改善、コンテナ最適化コンピューティングプラットフォームによる Pod スケジューリングレイテンシの改善にも取り組んでいます。詳細と利用方法については、以下のリソースをご覧ください。

- GKE、シニアソフトウェアエンジニア、Daniel Kłobuszewski,

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

Google の事例: 130,000 ノードで構成される世界最大級の Kubernetes クラスタの構築

Fri, 26 Dec 2025 17:00:00 +0000

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

Google Cloud では、ますます要求が厳しくなってきているワークロード、特に AI に対応できるように、Google Kubernetes Engine（GKE）のスケーラビリティを絶えず向上させています。GKE はすでに大規模な 65,000 ノードのクラスタをサポートしており、KubeCon では、130,000 ノードのクラスタを試験運用版モードで正常に稼働させたことを発表しました。これは、公式にサポートおよびテストされた上限の 2 倍のノード数にあたります。

このようなスケーリングは、単にノードの絶対数を増やすだけではありません。Pod の作成やスケジューリングのスループットなど、他の重要なディメンションもスケールする必要があります。たとえば、このテストでは、最適化された分散ストレージに 100 万を超えるオブジェクトを保存しながら、1,000 Pod / 秒のスループットを維持しました。このブログでは、こうしたメガクラスタの需要を牽引するトレンドを検証し、この極めて高いスケーラビリティを実現するために Google が実装したアーキテクチャのイノベーションについて詳しくご説明します。

メガクラスタの台頭

Google の大手企業のお客様は、AI ワークロードを通じて GKE のスケーラビリティとパフォーマンスの限界を積極的に押し広げています。実際、2 万～6 万 5,000 ノードの範囲でクラスタを運用しているお客様はすでに多数いらっしゃいます。また、大規模クラスタの需要は 10 万ノード前後で安定すると予想されます。

これは興味深いダイナミクスを生み出します。つまり、チップの供給が制約となる世界から、電力の供給が制約となる世界へと移行しつつあるのです。NVIDIA GB200 GPU 1 個あたり 2,700 W の電力を必要とすることを考えてみてください。チップが数万個、あるいはそれ以上搭載される場合、単一クラスタの電力消費量は数百メガワットにまで容易にスケールする可能性があります。この場合、複数のデータセンターに分散されるのが理想的です。したがって、10 万ノードを超える AI プラットフォームでは、クラスタやデータセンター全体で分散トレーニングや強化学習をオーケストレートできる、堅牢なマルチクラスタソリューションが必要になります。この大きな課題に対処するため、Google は MultiKueue などのツールに積極的に投資しており、さらなるイノベーションを視野に入れています。また、最近発表されたマネージド DRANET により高性能 RDMA ネットワーキングも進化しており、大規模 AI ワークロードのパフォーマンスを最大化するため、トポロジ認識を向上させています。今後の情報にご注目ください。

同時に、こうした投資は、GKE のお客様の大多数を占める、より小規模な運用を行うユーザーにもメリットをもたらします。GKE のコアシステムを過酷な使用環境に耐えられるように強化することで、平均的なクラスタに十分な余裕が生まれ、エラーに対する耐性が向上し、ユーザーによる Kubernetes API の誤用に対する許容度が高まり、一般にすべてのコントローラが最適化されてパフォーマンスが向上します。そしてもちろん、規模の大小を問わず、すべての GKE のお客様が、直感的なセルフサービスエクスペリエンスへの投資から恩恵を受けることができます。

主なアーキテクチャのイノベーション

とはいえ、このレベルのスケールを実現するには、コントロールプレーン、カスタムスケジューリング、ストレージなど、Kubernetes エコシステム全体にわたる大きなイノベーションが必要です。このプロジェクトにおいて重要であった主な領域をいくつか見てみましょう。

読み取りのスケーラビリティの最適化

大規模な運用においては、強整合性と、スナップショット可能な API サーバーのウォッチキャッシュが必要になります。ノード数が 130,000 になると、API サーバーへの読み取りリクエストの量が膨大になり、中央のオブジェクトデータストアが圧倒される可能性があります。これを解決するために、Kubernetes には、これらの読み取りリクエストを中央のオブジェクトデータストアからオフロードする複数の補完的な機能が組み込まれています。

まず、こちらで詳しく説明されている「キャッシュからの整合性のある読み取り機能」（KEP-2340）により、API サーバーがそのメモリ内キャッシュから直接、強整合性のあるデータを提供できるようになります。これにより、フィルタされたリストリクエスト（例: 「特定のノード上のすべての Pod」）などの一般的な読み取りパターンにおいて、オブジェクトストレージデータベースへの負荷が大幅に軽減されます。これは、リクエストを処理する前にキャッシュのデータが検証可能な最新状態であることを保証することで実現されます。

これを基盤にして、スナップショット可能な API サーバーキャッシュ機能（KEP-4988）では、API サーバーが以前の状態に対する LIST リクエスト（ページネーション経由または resourceVersion の指定による）を、同じ整合性のあるウォッチキャッシュから直接処理できるようにすることで、パフォーマンスをさらに向上させています。特定のリソースバージョンでキャッシュの B-tree「スナップショット」を生成することにより、API サーバーはデータストアに繰り返しクエリを実行することなく、後続の LIST リクエストを効率的に処理できます。

これら 2 つの機能強化を組み合わせることで、読み取り増幅の問題に対処し、強整合性のあるフィルタされた読み取りと以前の状態のリストリクエストの両方をメモリから直接提供することで、API サーバーの高速性と応答性を維持できるようにします。これは、極めて大規模な環境においてクラスタ全体のコンポーネントの健全性を維持するために不可欠です。

最適化された分散ストレージバックエンド

クラスタの大規模なスケールを支えるため、Google の分散データベース「Spanner」に基づく独自の Key-Value ストアを採用しました。13 万ノードでは、リースオブジェクトの更新に 13,000 QPS が必要でした。そのため、ノードのヘルスチェックなどの重要なクラスタオペレーションがボトルネックにならず、システム全体が確実に動作するために必要な安定性が確保されました。新しいストレージシステムではボトルネックは発生せず、より大規模なスケールをサポートできない兆候もありませんでした。

高度なジョブキューイングのための Kueue

デフォルトの Kubernetes スケジューラは個々の Pod をスケジュールするように設計されていますが、複雑な AI / ML 環境では、より高度なジョブレベルの管理が必要になります。Kueue は、Kubernetes にバッチシステム機能を提供するジョブキューイングコントローラです。公正な共有ポリシー、優先度、リソース割り当てに基づいてジョブを承諾するタイミングを決定し、ジョブ全体に対して「オールオアナッシング」のスケジューリングを可能にします。デフォルトのスケジューラをベースに構築された Kueue は、ベンチマークにおいて競合するトレーニング、バッチ、推論ワークロードの複雑な組み合わせを管理するために必要なオーケストレーションを提供しました。

スケジューリングの未来: ワークロード認識の強化

Kueue のジョブレベルのキューイング以外にも、Kubernetes エコシステムは、そのコアにおいてワークロードを考慮したスケジューリングへと進化しています。目標は、スケジューリングにおいて Pod 中心のアプローチからワークロード中心のアプローチに移行することです。つまり、スケジューラが利用可能な容量と潜在的な容量の両方を含めて、ワークロード全体のニーズを単一のユニットとして考慮して配置を決定します。この包括的な視点は、特に新たな AI / ML トレーニングと推論ワークロードにおいて費用対効果を最適化するために不可欠です。

新たに登場した Kubernetes スケジューラの重要な側面の一つが、Kubernetes 内でのギャングスケジューリングセマンティクスのネイティブな実装です。この機能は現在、Kueue などのアドオンによって提供されています。コミュニティは、KEP-4671: ギャングスケジューリングを通じてこの問題に積極的に取り組んでいます。

将来的には、コア Kubernetes でワークロードを考慮したスケジューリングがサポートされるようになり、GKE での大規模かつ緊密な結合アプリケーションのオーケストレーションが簡素化され、要求の厳しい AI / ML および HPC のユースケースに対応するプラットフォームがさらに強化されます。また、GKE 内で Kueue を二次レベルのスケジューラとして統合する取り組みも進めています。

データアクセス向け GCS FUSE

AI ワークロードは、データに効率的にアクセスできる必要があります。並列ダウンロードとキャッシュを有効化した Cloud Storage FUSE と、ゾーン単位の Anywhere Cache を組み合わせることで、Cloud Storage バケット内のモデルデータにローカルファイルシステムと同様にアクセスできるようになり、レイテンシが最大 70% 削減されます。これにより、分散ジョブやスケールアウト推論ワークフローにデータを供給するための、スケーラブルで高スループットのメカニズムが提供されます。あるいは、Google Cloud Managed Lustre という選択肢もあります。これは、フルマネージドの永続的なゾーンストレージソリューションであり、数ペタバイトの容量、TB / 秒単位のスループット、ミリ秒未満のレイテンシを必要とするワークロードをサポートします。AI / ML ワークロード向けのストレージオプションについて詳しくは、こちらをご覧ください。

大規模かつ動的な AI ワークロード向け GKE のベンチマーク

大規模な AI / ML ワークロードにおける GKE のパフォーマンスを検証するため、複雑なリソース管理や優先順位付け、スケジューリングの課題を伴う動的環境をシミュレートする、4 つのフェーズからなるベンチマークを設計しました。これは、前回の 65,000 ノードのスケールテストで使用されたベンチマークに基づいて構築されています。

ベンチマークをアップグレードして優先度クラスが異なるワークロードを使用することで、混合ワークロードをホストする一般的な AI プラットフォームを表すようにしました。

低い優先度: データ準備ジョブなどのプリエンプティブルなバッチ処理。
中程度の優先度: 重要ではあるが多少のキューイングは許容されるコアモデルのトレーニングジョブ。
高い優先度: リソースが保証される必要がある、レイテンシの影響を受けやすいユーザー向けの推論サービス。

割り当てとリソース共有を管理する Kueue と、トレーニングジョブを管理する JobSet を使用して、プロセスをオーケストレートしました。

フェーズ 1: 大規模なトレーニングジョブによるパフォーマンスのベースラインの確立

まず、単一の大規模なトレーニングワークロードをスケジュールし、クラスタの基本的なパフォーマンスを測定します。130,000 個の中優先度の Pod を同時に実行するように構成された JobSet を 1 つデプロイします。この初期テストでは、Pod の起動レイテンシや全体的なスケジューリングスループットなどの主要な指標のベースラインを確立し、クリーンなクラスタ上で大規模なワークロードを起動する際のオーバーヘッドを明らかにします。これにより、より複雑な条件下における GKE のパフォーマンスを評価する準備が整いました。実行後、この JobSet をクラスタから削除し、フェーズ 2 用に空のクラスタを残しました。

図 1: フェーズ 1: クリーンなクラスタ上に 130,000 個の Pod からなる大規模な事前トレーニングワークロードをデプロイしてパフォーマンスのベースラインを確立する。

フェーズ 2: 現実的な混合ワークロード環境のシミュレーション

次に、一般的な MLOps 環境をシミュレートするために、リソースの競合を導入しました。まず、650 個の低い優先度のバッチジョブ（合計 65,000 個の Pod）をデプロイし、クラスタの 130,000 個のノードの容量の半分を埋めました。

図 2: フェーズ 2: 65,000 個の低い優先度のバッチジョブ Pod を導入してクラスタ容量の 50% を埋め、現実的な MLOps 環境をシミュレートする。

次に、8 つの大規模な中優先度のファインチューニングジョブ（合計 104,000 個の Pod）を導入し、クラスタ容量の 80% を占有して、バッチワークロードの 60%（クラスタ容量全体の 30% に相当）をプリエンプトしました。このフェーズでは、GKE が混合ワークロードを管理する能力と、混合ワークロード環境内でのプリエンプションをテストしました。このシナリオでは、Kueue が実際に動作して既存のワークロードをプリエンプトし、多数のバッチジョブを一度にギャングスケジューリングすることで、ファインチューニングジョブをスケジュールできるようにする様子を確認しました。これにより、Kueue が kube-scheduler よりも優れている点が明らかになりました。プリエンプションがはるかに高速になり、ワークロードの切り替えがほぼ瞬時に行われます。

図 3: Kueue の動作: 優先度の高いファインチューニングジョブ用に 104,000 個の Pod を確保するため、優先度の低いバッチワークロードをプリエンプトする。

フェーズ 3: レイテンシの影響を受けやすい推論サービスの優先順位付けとスケーリング

このフェーズでは、優先度の高いジョブをデプロイすることで、合計 26,000 個の Pod（容量の 20%）で重要な推論サービスの導入をシミュレートしました。これに対応するため、Kueue は残りの優先度の低いバッチジョブをプリエンプトしました。

図 4: フェーズ 3: 優先度の低いバッチジョブの残りをプリエンプトすることで、レイテンシの影響を受けやすい重要な推論サービス（26,000 個の Pod）を優先する。

次に、推論ワークロードをスケーリングしてトラフィックの急増をシミュレートし、まず中優先度のファインチューニングジョブの一部をプリエンプトしました。推論ワークロードは、合計 52,000 個の Pod（容量の 40% に相当）にスケールアップされます。完全にスケールした後、10 分間のトラフィックシミュレーションを実行し、負荷がかかった状態でのパフォーマンスを測定しました。

図 5: トラフィックの急増をシミュレートする。推論ワークロードを 52,000 個の Pod（容量の 40%）にスケーリングすると、ファインチューニングジョブの部分的なプリエンプションがトリガーされる。

フェーズ 4: クラスタの弾力性とリソースの回復の検証

最後に、ピーク需要がすぎた後、クラスタがリソースを効率的に回復して再割り当てする能力を評価しました。優先度の高い推論ワークロードを 50% スケールダウンし、元の初期フェーズに戻しました。これにより GKE の弾力性が実証され、ワークロードの需要が変化しても貴重なコンピューティングリソースがアイドル状態にならないことが保証されたため、使用率と費用対効果が最大化されました。ここでも、Kueue がクラスタキューで待機していたプリエンプトされたファインチューニングワークロードの再承諾を処理しました。

図 6: フェーズ 4: 推論ワークロードをスケールダウンし、保留中のファインチューニングジョブのリソースを自動的に回復することで、クラスタの弾力性を実証する。

ベンチマークが完了して得られたデータから、GKE が極端なスケールのプレッシャーをどのように処理するかが明確に示されました。

GKE のさまざまな側面にわたるスケーラビリティの実証

4 つのベンチマークフェーズで、複数のパフォーマンスの項目をテストしました。フェーズ 1 では、クラスタは 3 分 40 秒で 130,000 個の Pod にスケールされました。フェーズ 2 では、優先度の低いバッチワークロードが 81 秒で作成され、平均スループットは約 750 Pod / 秒でした。

ベンチマークのさまざまなフェーズが強調表示されたワークロードの実行タイムラインの図を以下に示します。

図 7: 大規模 AI ワークロードベンチマークの 4 つの異なるフェーズが強調表示された実行タイムライン。

全体として、ベンチマークでは、優先度の低いジョブをプリエンプトして重要なトレーニングサービスと推論サービスのためのスペースを確保することで、変動する需要を管理する GKE の能力が実証され、クラスタの弾力性とリソースの再割り当ての能力が示されました。

図 8: 実行中のワークロード Pod の総数の推移。動的なプリエンプションとリソースの再割り当てを通じて GKE が高い使用率を維持できることを示している。

Kueue によるインテリジェントなワークロード管理

このベンチマークでは、Kueue はワークロードの優先順位付けを可能にする重要なコンポーネントでした。フェーズ 2 では、Kueue はバッチワークロードの 60%（クラスタ容量の 30%）をプリエンプトして、中優先度のジョブのスペースを確保しました。残りはフェーズ 3 でプリエンプトされ、優先度の高い推論ワークロードのスペースが確保されました。緊急タスクが優先されるこのシミュレーションは一般的な運用シナリオであり、この大規模なプリエンプションは、GKE と Kueue の組み合わせによって、最も重要なジョブにリソースを動的に割り当てられることを示しています。フェーズ 2 のピーク時には、93 秒で 39,000 個の Pod がプリエンプトされました。バッチワークロードのプリエンプションと、ファインチューニングワークロードの承諾および作成中の Pod のチャーンは、以下のように、中央値が 990 Pod / 秒、平均が 745 Pod / 秒に達しました。

図 9: プリエンプションイベント中の API リクエストスループット。POST リクエストと DELETE リクエストが混在しており、Pod のチャーンは平均 745 Pod / 秒。

Kueue からの承諾済みワークロードと削除済みワークロードのステータスを確認すると、多くのバッチワークロードが最初は承諾されたものの、その後ファインチューニングと推論ワークロードによってプリエンプトされたことがわかります。

図 10: ワークロードのステータスの推移。優先度の変化に伴い、Kueue によって受け入れられたジョブ数とプリエンプト（削除）されたジョブ数を可視化している。

1,000 Pod / 秒の超高速スケジューリング

Kubernetes のコントロールプレーンのパフォーマンスを測る重要な指標は、Pod を迅速に作成してスケジュールする能力です。ベンチマーク全体を通して、特に最も負荷の高いフェーズでは、GKE は Pod の作成と Pod のバインディング（Pod をノードにスケジュールする行為）の両方で、最大 1,000 オペレーション / 秒のスループットを安定して達成しました。

図 11: コントロールプレーンのスループット: スケジューリングが集中するフェーズで、Pod の作成と Pod のバインディングの両方で最大 1,000 オペレーション / 秒を維持する。

図 12: 大規模な事前トレーニング、バッチ、ファインチューニングのワークロードにおける、Pod 作成のスループットに関する詳細な統計情報（平均、最大、P50、P90、P99）。

Pod の低い起動レイテンシ

同時に、Pod 作成のスループットは、あらゆるワークロードタイプにおいて Pod の低い起動レイテンシと一致していました。レイテンシの影響を受けやすい推論ワークロードの場合、99 パーセンタイル（P99）の起動時間は約 10 秒で、需要に応じてサービスを迅速にスケールできることが保証されています。

図 13: ワークロードタイプ別の Pod の起動レイテンシ。

極端な負荷下におけるコントロールプレーンの安定性

テスト全体を通して、GKE のクラスタコントロールプレーンは安定していました。単一のデータベースレプリカ内のオブジェクトの合計数はピーク時に 100 万を超えましたが、重要なオペレーションにおける API サーバーのレイテンシは、定義されたしきい値を大幅に下回っていました。これにより、この規模であってもクラスタが応答性と管理性を維持できることが確認されました。

図 14: GET オペレーションと LIST オペレーションにおける API サーバーのレイテンシ。クラスタが大規模であるにもかかわらず、定義されたしきい値を大幅に下回り、安定している。

図 15: 動詞（GET、POST、PUT、PATCH、DELETE）別に分類された API リクエストの所要時間。負荷下でも応答時間が一定であることが確認できる。

図 16: LIST オペレーションの所要時間。ベンチマークのフェーズ全体で安定している。

図 17: データベース内の Kubernetes オブジェクト（Pod、Lease、Node を含む）の総数。100 万個を超えている。

リンク先: 大規模なスケール

この実験では、GKE が現在のパブリック制限をはるかに超える規模で AI および ML ワークロードをサポートできることが実証されました。さらに、この規模で運用したことで得られた分析情報は、GKE の今後の開発計画に役立っています。13 万ノードはまだ正式にはサポートされていませんが、非常に心強い調査結果が得られました。ワークロードでこのレベルのスケールが必要な場合は、Google にお問い合わせのうえ、具体的なニーズについてご相談ください。また、アトランタで開催された KubeCon では、Google のスペシャリストやアナリストが、スケーリングやその他のトピックに関する素晴らしい対談を行いました。こちらからぜひご覧ください。

-ソフトウェアエンジニア Besher Massri

-グループプロダクトマネージャー Maciek Różacki

NVIDIA Run:ai Model Streamer を使用して GKE 上のモデルのダウンロードを高速化

Mon, 15 Dec 2025 02:30:00 +0000

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

大規模言語モデル（LLM）のサイズと複雑さが増大し続けるのに伴って、推論のためにストレージからアクセラレータメモリを読み込む時間が重大なボトルネックになる可能性があります。この「コールドスタート」の問題は、単なる軽微な遅延ではありません。レジリエントかつスケーラブルな費用対効果の高い AI サービスを構築するうえで、大きな障壁となります。モデルの読み込みに費やされる 1 分 1 分は、GPU のアイドル状態、需要に応じたサービスのスケーリングの遅延、ユーザーのリクエストの待機がそれぞれ生じている 1 分です。

Google Cloud と NVIDIA は、こうした障壁を取り除くことに取り組んでいます。AI デベロッパーがまさにそれを実現するのに役立つ、強力なオープンソースのコラボレーションをご紹介できることをうれしく思います。NVIDIA Run:ai Model Streamer にネイティブの Google Cloud Storage サポートが追加され、Google Kubernetes Engine（GKE）上の vLLM 推論ワークロードが大幅に強化されました。GKE 上の Cloud Storage から AI/ML のデータにアクセスする速度がこれまで以上に高速になりました。

上のグラフは、デフォルトの vLLM モデルローダと比較して、モデルストリーマーが 141 GB の Llama 3.3-7 70B モデルを Cloud Storage から取得できる速度を示しています（値が小さいほど高速）。

コールドスタートを減らしてレジリエンスとスケーラビリティを向上

Kubernetes 上で実行される推論サーバーの場合、「コールドスタート」には、コンテナイメージの pull、プロセスの開始、そして最も時間がかかるモデルの重みの GPU メモリへの読み込みといういくつかのステップが含まれます。大規模モデルの場合、この読み込みフェーズには数分かかることがあり、ワークロードの起動を待機する間に自動スケーリングが遅延したり、GPU のアイドル状態になったりするなど、深刻な影響が生じます。

モデルストリーマーは、モデルを GPU メモリにストリーミングすることで、起動プロセスで最も時間がかかる可能性のある部分を大幅に短縮します。ストリーマーは、モデル全体がダウンロードされてから読み込まれるのを待つのではなく、オブジェクトストレージからモデルテンソルを直接取得し、GPU メモリに同時にストリーミングします。これにより、モデルの読み込み時間が数分から数秒に大幅に短縮されます。

単一のモデルを分割して複数の GPU で実行するモデル並列処理に依存するワークロードの場合、モデルストリーマーはさらに一歩進んだ機能を提供します。その分散ストリーミング機能は、NVIDIA NVLink を最大限に活用するよう最適化されており、高帯域幅の GPU 間通信を使用して、複数のプロセス間での読み込みを調整します。ストレージからの重みの読み込みは、参加するすべてのプロセスに効率的かつ均等に分割されます。各プロセスは、モデルの重みの一部をストレージから取得し、そのセグメントを NVLink 経由で他のプロセスと共有します。これにより、マルチ GPU デプロイでも、起動時間の短縮とコールドスタートのボトルネックの低減というメリットが得られます。

パフォーマンスとシンプルさ

Model Streamer の最新のアップデートでは、Cloud Storage のファーストクラスのサポートが導入され、Google Cloud ユーザー向けに統合された高性能なエクスペリエンスが実現します。この統合は、特に GKE 上で実行されるワークロード向けに、シンプルで高速かつ安全になるように設計されています。

vLLM などの一般的な推論サーバーのユーザーは、vLLM コマンドラインに 1 つのフラグを追加するだけでストリーマーを有効化できます。

--load-format=runai_streamer

Cloud Storage バケットに保存されたモデルを vLLM で起動する手順は以下のとおりです。

code_block: <ListValue: [StructValue([('code', 'vllm serve gs://your-gcs-bucket/path/to/your/model \r\n--load-format=runai_streamer'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fed0af403d0>)])]>

NVIDIA Run:ai Model Streamer は、Vertex AI Model Garden の大規模モデルのデプロイに不可欠なコンポーネントです。コンテナイメージストリーミングとモデルウェイトストリーミングにより、ユーザーの初回デプロイと自動スケーリングのエクスペリエンスと、NVIDIA GPU の効率を大幅に向上させることができました。

GKE 上で実行する場合、Model Streamer は自動的にクラスタの Workload Identity を使用できます。つまり、サービスアカウントキーを手動で管理してマウントする必要がなくなり、デプロイマニフェストが簡素化され、セキュリティポスチャーが強化されます。以下のデプロイマニフェストは、GKE 上で Llama3 70B を提供するコンテナを起動する方法を示しています。モデルの並列処理が 1 より大きい場合に読み込みを高速化するモデルローダの分散オプションを追加しました。

code_block: <ListValue: [StructValue([('code', 'apiVersion: apps/v1\r\nkind: Deployment\r\n…\r\n spec:\r\n serviceAccountName: gcs-access\r\n containers:\r\n - args:\r\n - --model=gs://your-gcs-bucket/path/to/your/model \r\n - --load-format=runai_streamer\r\n \t\t- --model-loader-extra-config={"distributed":true}\r\n\t\t…\r\n command:\r\n - python3\r\n - -m\r\n - vllm.entrypoints.openai.api_server\r\n image: vllm/vllm-openai:latest\r\n ….'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fed0af40df0>)])]>

これで完了です。残りの処理はストリーマーが行い、VM のパフォーマンスに合わせてストリーミングの同時実行数を自動調整します。詳しくは、GKE 上での vLLM モデルの読み込みの最適化に関するドキュメントをご覧ください。

NVIDIA Run:ai Model Streamer と Cloud Storage Anywhere Cache の組み合わせ

Anywhere Cache は、リージョンまたはマルチリージョンの Cloud Storage バケットに保存されたデータに対して、ゾーン内にコロケーションされた SSD ベースのキャッシュを提供します。レイテンシを最大 70% 短縮し、最大 2.5 TB/ 秒の読み込みスループットを提供する Anywhere Cache は、同じモデルが複数のノードにわたって何度もダウンロードされるスケールアウト推論ワークロードに最適なソリューションです。Anywhere Cache のサーバーサイドアクセラレーションと、NVIDIA Run:ai Model Streamer のクライアントサイドアクセラレーションを組み合わせることで、管理が容易で非常にパフォーマンスの高いモデル読み込みシステムが実現します。

今すぐ使ってみる

NVIDIA Run:ai Model Streamer は、AI インフラストラクチャのパズルの重要なピースへと進化しています。これにより、チームは GKE 上でより高速かつ復元力がある、より柔軟な MLOps パイプラインを構築できるようになります。

GKE で Model Streamer を使用する方法の詳細については、GKE NVIDIA Run:ai ガイドをご覧ください。
vLLM でストリーマーを使用する詳しい手順については、vLLM の公式ドキュメントをご覧ください。
モデルストリーマーの詳細と、継続的な開発への貢献については、GitHub の NVIDIA Run:ai Model Streamer プロジェクトをご覧ください。

-Google、ソフトウェアエンジニア Peter Schuurman

-Google、シニアプロダクトマネージャー Brian Kaufman

Agent Sandbox のご紹介: Kubernetes と GKE 上のエージェント AI 向けの強力なガードレール

Wed, 19 Nov 2025 01:50:00 +0000

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

Google とクラウドネイティブコミュニティは、最新のアプリケーションをサポートするために Kubernetes を絶えず強化してきました。今年初めの KubeCon EU 2025 では、AI 推論のサポートを強化するための Kubernetes の一連の機能強化を発表しました。本日 KubeCon NA 2025 で発表した Agent Sandbox をはじまりとして、Google は Kubernetes を AI エージェントにとって最もオープンでスケーラブルなプラットフォームに進化させることを目指します。

AI エージェント導入に伴う課題について考えてみましょう。AI エージェントは、アプリケーションとそれを利用するユーザーが目的を効率的に達成するために、単純なクエリの回答から複雑なマルチステップタスクの実行まで、さまざまな支援を提供できます。「前四半期の販売データを可視化して」というリクエストが与えられたら、まず最初のツールでデータをクエリし、2 つ目のツールでそのデータをグラフ化してユーザーに返さなければなりません。従来のソフトウェアが予測可能で決定論的に動くものであるのに対し、AI エージェントは、コードの生成、コンピュータターミナルやブラウザの使用など、ユーザーの目標達成のために利用できるツールを「いつ、どのように」使うかを自ら判断できます。

非決定論的に動ける強力なエージェントをオーケストレーションするには、強固なセキュリティと運用上のガードレールを施さなければ重大なリスクが生じる可能性があります。コードとコマンドを実行するエージェントをカーネルレベルで分離することは、妥協できない要件です。また従来型のアプリケーションと比べて、AI とエージェントベースのワークロードではインフラストラクチャのニーズも高まります。なかでも、数千ものサンドボックスをエフェメラル環境としてオーケストレートし、必要に応じて迅速に作成と削除を行いつつ、ネットワークアクセスを確実に制限するという AI ワークロード固有のニーズがあります。

成熟度、セキュリティ、スケーラビリティを備えた Kubernetes は、AI エージェントを実行するのに最適な基盤であると Google は考えています。しかし、エージェントによるコード実行やコンピュータの使用などのニーズを満せるまでには一層の進化が必要であることも認識しており、その方向への取り組みの第一歩が、今回発表した Agent Sandbox になります。

堅牢な分離と高いスケーラビリティ

エージェントによるコード実行とコンピュータの使用のために、タスクごとに隔離されたサンドボックスをプロビジョニングする必要があります。さらに、数千ものサンドボックスが同時に実行されるような状況でも、ユーザーはインフラストラクチャが遅れをとることなく対応できるものと期待しています。

Kubernetes コミュニティと共同で構築した Agent Sandbox は、エージェントによるコード実行とコンピュータの使用に特化して設計され、次世代のエージェント AI ワークロードに必要なパフォーマンスとスケーリングを実現するた新しい Kubernetes プリミティブです。Agent Sandbox は gVisor を基盤として構築され、ランタイム分離のための Kata Containers のサポートが追加されています。gVisor の強力なセキュリティ境界を提供することで、データの損失や引き出し、本番環境システムへの損害につながる可能性のある脆弱性のリスクを軽減します。オープンソースへの継続的な取り組みとして、Agent Sandbox は Kubernetes コミュニティの Cloud Native Computing Foundation（CNCF）プロジェクトとして構築されています。

GKE でのパフォーマンスの向上

最小のコストで最高のエージェントユーザーエクスペリエンスを提供するには、強固な分離だけでなく、エージェントをスケールさせてパフォーマンスを最適化する必要もあります。Google Kubernetes Engine（GKE）で Agent Sandbox を使用すると、GKE Sandbox 内のマネージド gVisor とコンテナ最適化コンピューティングプラットフォームを活用して、サンドボックスをより迅速に水平スケーリングできます。また、Agent Sandbox では管理者があらかじめサンドボックスのウォームプールを構成できるため、サンドボックスを低レイテンシで起動できます。この機能により、Agent Sandbox では完全隔離されたエージェントワークロードのレイテンシが 1 秒未満となり、コールドスタートと比較して最大 90% の改善を実現します。

隔離された環境で外部からの脅威を防ぐというサンドボックスの特性は、その一方でコンピューティングリソースの利用率低下の原因にもなります。スクリプトを使って各サンドボックス環境を再初期化する方法は、不安定で時間もかかり、アイドル状態のサンドボックスは貴重なコンピューティングサイクルを無駄にしてしまいがちです。実行中のサンドボックス環境のスナップショットを取得して、特定の状態から開始できるようにするのが理想的な方法です。

Pod Snapshots は、実行中の Pod の完全なチェックポイントと復元を可能にする、GKE 専用の新機能です。Pod Snapshots は、エージェントと AI のワークロードの起動レイテンシを大幅に短縮します。Pod Snapshots を Agent Sandbox と組み合わせると、スナップショットからサンドボックス環境をプロビジョニングできるため、数秒で起動できます。GKE Pod Snapshots は、CPU ベースと GPU ベースの両方のワークロードのスナップショットと復元をサポートしており、これまで数分を要した Pod の起動時間を数秒に短縮します。Pod Snapshots 使ってアイドル状態のサンドボックスのスナップショットを作成して一時停止できるため、エンドユーザーへの影響を最小限に抑えながらコンピューティングサイクルを大幅に節約できます。

AI エンジニアのためのサンドボックス

エージェント AI や強化学習（RL）システムを現在構築しているチームは、インフラストラクチャの専門家である必要はありません。そのような AI エンジニアを念頭に置いて構築された Agent Sandbox には、基盤となるインフラストラクチャを気にすることなく、サンドボックスのライフサイクルを管理できるように API と Python SDK が設計されています。

code_block: <ListValue: [StructValue([('code', 'from agentic_sandbox import Sandbox\r\n\r\n# SDK はすべての YAML を単純なコンテキストマネージャーに抽象化する\r\nwith Sandbox(template_name="python3-template",namespace="ai-agents") as sandbox:\r\n\r\n # サンドボックス内でコマンドを実行する\r\n result = sandbox.run("print(\'Hello from inside the sandbox!\')")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fed087f0910>)])]>

このように分けてしまうことで、AI デベロッパーは自分が得意とする役割に専念しながら、Kubernetes 管理者やオペレーターが期待する運用上の制御や拡張性も実現できます。

今すぐ使ってみる

エージェント AI は、ソフトウェア開発とインフラストラクチャの両チームに大きな変化をもたらします。Agent Sandbox と GKE は、エージェントに必要な分離とパフォーマンスを実現するのに役立ちます。オープンソースで提供されている Agent Sandbox は、今すぐ GKE にデプロイできます。GKE Pod Snapshots は限定プレビュー版で提供されており、今年後半にすべての GKE のお客様にご利用いただける予定です。まずは、Agent Sandbox のドキュメントとクイックスタートをご覧ください。皆様がどのようなものを構築されるか楽しみにしております。

ーシニアプロダクトマネージャー、Brandon Royal

GKE: コンテナからエージェントまで、あらゆる最新のワークロードに対応する統合プラットフォーム

Tue, 18 Nov 2025 03:00:00 +0000

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

クラウドネイティブインフラストラクチャのこの 10 年間は、コンテナ化やマイクロサービスから生成 AI の台頭まで、絶え間ない変化によって定義されてきました。あらゆる変化を通じて、Kubernetes は常に安定性を提供し、アプリケーションとインフラストラクチャの両方に対して、均一でスケーラブルな運用モデルを実現しています。

Google Kubernetes Engine（GKE）が 10 周年を迎えるにあたり、Kubernetes との共生関係はこれまで以上に重要になっています。Kubernetes で AI を最大規模で処理する需要が高まる中、Google は Kubernetes のコア機能を強化し、AI と AI 以外の両方のワークロードを向上させるために投資を続けています。今年の KubeCon North America では、以下の包括的な 3 つのアプローチが反映された大きな進展について発表しました。

次世代のワークロード向けに Kubernetes OSS のコアを強化 - これには、セキュリティ、ガバナンス、分離のための新しい Kubernetes ネイティブの AgentSandbox API を使用して、エージェントの波にプロアクティブに対応することが含まれます。また最近では、Inference Gateway API や Inference Perf など、推論ワークロードを強化する機能もいくつか追加しました。さらに、Buffers API や HPA などの機能は、すべてのワークロードのプロビジョニングレイテンシにさまざまな角度から対処するのに役立ちます。
マネージド Kubernetes の優れたリファレンス実装として GKE を提供 - Google は、高度な Google Cloud サービスを統合し、比類のないスケールとセキュリティを提供する、本番環境対応のフルマネージドプラットフォームへと、Kubernetes に関する専門知識を変換し、新しい機能とベストプラクティスを絶えず GKE に直接導入しています。このたび Google は、新しい GKE Agent Sandboxを発表しました。また、最近では GKE カスタムコンピューティングクラス、GKE Inference Gateway、GKE Inference Quickstart も発表しています。さらに、大規模なコンピューティングの需要に応えるため、13 万ノードのクラスタをサポートすることで、スケーリングの限界を押し広げています。今年は、クラスタの相互運用性とポータビリティの標準により、Kubernetes 上の AI / ML を簡素化する新しい CNCF Kubernetes Kubernetes AI Conformance プログラムにも参加します。GKE はすでに AI 適合プラットフォームとして認定されています。
フレームワークを推進し、運用上の摩擦を軽減 - Google は、オープンソースコミュニティやパートナーと積極的に協力して、Kubernetes 上の Slurm や Ray などの新しいフレームワークのサポートを強化しています。最近では Anyscale とのコラボレーションの下で、Anyscale Platform と Runtime を使用した GKE 向けに最適化されたオープンソースの Ray を発表しました。もっと最近では、パートナーと連携して、大規模な高性能 LLM 推論のための Kubernetes ネイティブの分散型コントロールプレーンを作成するオープンソースプロジェクトの llm-d の創設に貢献しました。

ここからは、こうした進展について詳しくご紹介します。

エージェントの波に対応

エージェント AI の波が押し寄せています。PwC によると、IT 部門のシニアリーダーの 79% がすでに AI エージェントを導入しており、88% がエージェント AI のために今後 12 か月間で IT 予算を増やす計画です。

Kubernetes では、エージェントを大規模にデプロイして管理するための堅牢な基盤が提供されているものの、エージェント AI ワークロードの非決定論的な性質が原因でインフラストラクチャの課題が発生します。エージェントはますます、コードの記述、コンピュータインターフェースの制御、無数のツールの呼び出しを行えるようになっており、分離、効率、ガバナンスに関するリスクが高まっています。

Google は、Kubernetes の基本的なプリミティブを進化させながら、GKE で実行されるエージェントの優れたパフォーマンスとコンピューティング効率を実現することで、これらの課題に対処しています。そして本日、Kubernetes ネイティブのエージェントコード実行とコンピュータ使用環境のための新しい機能セットである Agent Sandbox のプレビュー版をリリースしました。最初からオープンソースとして設計された Agent Sandbox は、gVisor を使用してエージェント環境を分離するため、LLM で生成されたコードを自信を持って実行し、AI エージェントとやり取りすることができます。

さらに安全で効率的なマネージドエクスペリエンスを実現する新しい GKE Agent Sandbox は、統合されたサンドボックススナップショットやコンテナ最適化コンピューティングなどの組み込み機能でこの基盤を強化します。Agent Sandbox は、完全に分離されたエージェントワークロードで 1 秒未満のレイテンシと、コールドスタートと比較して最大 90% の改善を実現します。詳細については、本日公開された GKE でエージェントを強化する方法に関する詳細な発表をご覧ください。

AI ギガワット時代のための比類のない規模

この「ギガワット AI 時代」において、基盤モデルの作成者は前例のないコンピューティング能力に対する需要を増大させています。Google では、試験運用モードのスタックに関する社内テストに基づいて、GKE を使用して 130,000 ノードを持つ最大規模の既知の Kubernetes クラスタを作成しています。

Google Cloud は、緊密に結合されたジョブの単一クラスタのスケーラビリティにも重点を置いており、ジョブのシャーディング（MultiKueue など）向けのマルチクラスタオーケストレーション機能を開発し、動的な容量再割り当てのための新しいアプローチを設計しています。これらはすべて、AI プラットフォームの開発とスケーリングを簡素化するために、オープンソースの Kubernetes API を拡張する間に行われました。Google は、大規模な AI の背後にあるツールのオープンソースエコシステム（Kueue、JobSet、etcd など）に多大な投資を行っています。同時に、最高のパフォーマンスと信頼性を実現するために、データセンターへの GKE 固有の統合（Spanner での GKE コントロールプレーンの実行など）も行っています。最後に、ハードウェア障害に関連する損失時間と、保存されたチェックポイントからの復旧の遅延を減らすことで、大規模な AI トレーニングジョブの効率を向上させるように設計された多層チェックポイント処理（MTC）ソリューションをオープンソース化しています。

あらゆるワークロードに対応する優れたコンピューティング

Google が 10 年にわたって Kubernetes に取り組んできたのは、あらゆるワークロードで Kubernetes をさらに利用しやすく、効率的にするためです。しかし、長年にわたって 1 つの大きな課題が残っています。それは、自動スケーリングを使用する場合に、新しいノードのプロビジョニングに数分かかることです。これは、大量のデータを扱う高速スケーリングアプリケーションには十分な速さではありません。今年、Google はこの問題に正面から取り組み、価格とパフォーマンスを最適化しながら、必要なときにほぼリアルタイムでスケーラブルなコンピューティング容量を提供するという使命を達成するために、さまざまな機能強化を行いました。

Autopilot をすべてのお客様に

Google は、GKE Autopilot 向けの完全に再構築された自動スケーリングスタックであるコンテナ最適化コンピューティングプラットフォームを導入しました。推奨される運用モードとして、Autopilot はノードインフラストラクチャの管理とスケーリングを完全に自動化し、パフォーマンスとコストに大きな影響を与えます。LiveX AI の共同創業者である Jia Li 氏は、「LiveX AI は GKE Autopilot を使用して、TCO を 50% 以上、運用コストを 66% 削減し、市場投入までの時間を 25% 短縮しました」と話しています。また最近、Standard クラスタ向けの Autopilot コンピューティングクラスの一般提供が開始されたことで、より多くのデベロッパーがこの操作不要のエクスペリエンスを利用して、ワークロードごとに Autopilot を採用できるようになっています。

あらゆる角度からプロビジョニングのレイテンシに対処

Google は、ノードプールの同時自動プロビジョニングの高速化を導入し、オペレーションを非同期化かつ高度に並列化しました。このシンプルな変更により、異種ワークロードのクラスタスケーリングが劇的に加速され、デプロイのレイテンシがベンチマークの何倍にも改善されました。また、スケールアップのニーズが厳しい場合は、新しい GKE Buffers API（OSS）を使用して、事前にプロビジョニングされたすぐに使用できるノードのバッファをリクエストし、コンピューティング容量をほぼ即時に利用できます。ノードの準備が整うと、新しいバージョンの GKE コンテナイメージストリーミングにより、コンテナイメージ全体がダウンロードされる前にアプリケーションを起動できるため、アプリケーションの実行が高速化されます。これは、大規模な AI / ML およびデータ処理ワークロードにとって非常に重要な改善点です。

リソース使用率を向上させる、中断のない自動スケーリング

速度の追求は、ワークロードレベルのスケーリングにも及びます。

新しい GKE Standard クラスタでは、パフォーマンス HPA プロファイルがデフォルトで有効になっています。これにより、最大 5,000 個の HPA オブジェクトのサポートや並列処理など、スケーリングが大幅に改善され、より高速で一貫性のある水平スケーリングを行えます。
Google は、VPA とインプレース Pod のサイズ変更のプレビュー版を使用して、垂直スケーリングの中断に対処しています。これにより、GKE はコンテナの CPU とメモリのリクエストを自動的にサイズ変更でき、多くの場合に Pod を再作成する必要はありません。

動的なハードウェア効率

最後に、動的な効率性に対する Google の取り組みは、ハードウェアの活用にも及びます。GKE ユーザーは以下を利用できるようになっています。

Google Axion プロセッサをベースとする新しい N4A VM（プレビュー版）と、第 5 世代 AMD EPYC プロセッサをベースとする N4D VM（一般提供）。どちらもカスタムマシンタイプ（CMT）をサポートしており、ワークロードに合わせて適切なサイズのノードを作成できます。
新しい GKE カスタムコンピューティングクラスにより、VM インスタンスタイプの優先順位リストを定義できるため、手動操作なしで最新かつ最も費用対効果の高いオプションがワークロードで自動的に使用されます。

AI 推論を強化するプラットフォーム

生成 AI 推論に関する真の課題は、組織を破産させることなく、数十億のトークンを超高速で確実に処理することです。

ウェブアプリケーションとは異なり、LLM のサービングはステートフルであり、計算負荷も高くなります。これに対処するため、Google は Kubernetes への広範なオープンソース投資を推進してきました。これには、LLM 対応ルーティングのための Gateway API Inference Extension、推論パフォーマンスプロジェクト、アクセラレータと HPA スケーリングの指標としきい値に関する綿密なモデルパフォーマンス分析情報のためのベンチマーク標準の提供、Kubernetes の Pod とワークロードへの GPU、TPU、その他のデバイスの割り当てとスケジューリングを合理化および自動化するための Dynamic Resource Allocation（Intel などとの共同開発）が含まれます。また、Red Hat および IBM とともに llm-d プロジェクトを立ち上げ、「SOTA アーキテクチャに到達するまでの時間」を最適化する Kubernetes ネイティブの分散推論スタックを構築しました。

GKE 側では最近、AI ワークロードのサービングのための Kubernetes ネイティブソリューションである GKE Inference Gateway の一般提供を発表しました。以下の 2 つのワークロード固有の最適化が利用可能になっています。

LLM 対応ルーティング: マルチターンチャットなどのアプリケーションで、キャッシュに保存されたコンテキストを使用するためにリクエストを同じアクセラレータにルーティングして、レイテンシの急増を回避する
分離型サービング: 「プレフィル」（プロンプト処理）ステージと「デコード」（トークン生成）ステージを、最適化された別々のマシンプールに分離する

その結果、GKE Inference Gateway では他のマネージド Kubernetes サービスと比較して、ピーク時のスループットで最初のトークンまでの時間（TTFT）のレイテンシを最大 96% 短縮し、トークン費用を最大 25% 削減できるようになっています。

AI 推論サーバーの起動レイテンシは、大規模モデルの起動に数十分かかるという一貫した問題です。このたび、Google は CPU と GPU のワークロードをメモリスナップショットから復元することで、起動レイテンシが大幅に改善される GKE Pod Snapshots を発表します。これにより、AI 推論の起動時間が最大 80% 短縮され、700 億パラメータのモデルをわずか 80 秒で、80 億パラメータのモデルをわずか 16 秒で読み込むことができます。

推論について語る際は、本番環境グレードの AI インフラストラクチャのデプロイの複雑さ、費用、難しさについて触れないわけにはいきません。GKE Inference Quickstart は、Google Cloud の最新のアクセラレータ、最新のオープンモデル、推論ソフトウェアによって最新の状態に保たれる、継続的な自動ベンチマークシステムを提供します。これらのベンチマークプロファイルを使用すると、推論固有のパフォーマンス指標の評価、構成、デプロイ、モニタリングのほか、デプロイの動的なファインチューニングにかかる時間を大幅に節約できます。このデータは、こちらの Colab ノートブックで確認できます。

Kubernetes と GKE の次の 10 年

GKE が 10 年にわたる基礎的な取り組みを記念する中、Google は未来をリードするお手伝いができることを誇りに思っています。そして、未来は一緒に築き上げるものだと考えています。コントリビューターコミュニティの取り組みがなければ、今日の Kubernetes は存在しなかったでしょう。このコミュニティには、基盤となる新機能を記述するメンバーから、プロジェクトを成功させるために不可欠な日常業務（「薪割りや水運び」）を行うメンバーまで、全員が含まれます。

Google では、新しい機能や Ironwood TPU などの刺激的な発表の確認、徹底したセッションへの出席、オープンソースインフラストラクチャの未来を形作るための取り組みへの参加など、さまざまな機会をご用意しています。ぜひご利用ください。

-Google Kubernetes Engine、プロダクト管理担当シニアディレクター、Drew Bradstock

Containers & Kubernetes

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

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

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

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

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

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

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

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

初期ベンチマーク

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

使ってみる

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

まとめ

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

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

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

使ってみる

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

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

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

対象

試す方法

Next ‘26 で発表された GKE の新機能

GKE Agent Sandbox: エージェント時代を加速

GKE ハイパークラスタがスケーラビリティの上限を再定義

最先端の推論を強化

RL コンピューティングのボトルネックの解消

カスタム指標に基づくインテントベースの自動スケーリング

新しいワークロード、変わらないミッション

Envoy: エージェント型 AI ネットワーキングのための将来を見据えた基盤

エージェント型 AI がネットワーキングの問題を変える

Envoy がこの移行に対応できる理由

1. Envoy はエージェント トラフィックを理解する

2. Envoy は重要な事項に関するポリシーを適用する

3. Envoy はステートフルなエージェントのインタラクションを大規模にサポートする

4. Envoy はエージェントの検出をサポートする

5. Envoy はエージェント ネットワーキングの課題に対する包括的なソリューション

コントロール プレーンがこれを運用可能にする

このソリューションが重要な理由

新しい GKE Cloud Storage FUSE プロファイルにより、AI ストレージの構成における当て推量が不要に

Cloud Storage FUSE の最適化に伴う課題

GKE 向け Cloud Storage FUSE プロファイルの概要

GKE で Cloud Storage FUSE プロファイルを使用する方法

使ってみる

GKE Inference Gateway を使用して、同じインフラストラクチャでリアルタイム推論と非同期推論を実行する

2 つの推論パターン: リアルタイムと非同期

1. リアルタイム推論: レイテンシの影響を受けやすい 0 秒のリクエスト

2. 非同期（ニア リアルタイム）推論: 0 分のレイテンシ

ソリューション: 非同期プロセッサ エージェント + Inference Gateway

統合ワークロードの実例

次のステップ

AI 時代のオープン プラットフォーム: GKE、エージェント、OSS のイノベーションを KubeCon EU 2026 で披露

Autopilot をすべてのお客様に

CNCF Kubernetes AI Conformance に向けて

Model Context Protocol: エージェント インターフェース

AI インフラストラクチャとしての Kubernetes

DRA はリソース管理の新たな標準です

エージェントの波に対応: 推論とエージェント

Kubernetes 上の Ray: TPU と優れたオブザーバビリティ

ブースにお立ち寄りください

AI インフラストラクチャとしての Kubernetes: Google Cloud、llm-d、CNCF

推論のための Kubernetes の強化

次世代の AI インフラストラクチャを共同で構築

DRA: 動的リソース割り当てが切り開く Kubernetes デバイス管理の新時代

静的なインフラストラクチャからの脱却

詳細解説: DRA の仕組み

ResourceSlice: 可用性の記述

ResourceClaim: 要件の定義

能力ベースのアプローチによるスマートなスケジュール設定

ぜひお試しください

マルチクラスタ GKE Inference Gateway のご紹介: 世界中で AI ワークロードをスケール

AI 推論にマルチクラスタを使用する理由

仕組み

使ってみる

AI ネイティブなコア: Google Kubernetes Engine を使用した、レジリエンスの高い通信事業者向けアーキテクチャ

ネットワーク モダナイゼーションの 2 つの方法

「通信事業者グレード」の基盤のエンジニアリング

AI で「節約」から「解決」へ

貴社の戦略に合わせた変革を

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

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

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

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

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

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

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

1. Envoy はエージェントトラフィックを理解する

5. Envoy はエージェントネットワーキングの課題に対する包括的なソリューション

コントロールプレーンがこれを運用可能にする

2. 非同期（ニアリアルタイム）推論: 0 分のレイテンシ

ソリューション: 非同期プロセッサエージェント + Inference Gateway

AI 時代のオープンプラットフォーム: GKE、エージェント、OSS のイノベーションを KubeCon EU 2026 で披露

Model Context Protocol: エージェントインターフェース

ネットワークモダナイゼーションの 2 つの方法

独自の成長を促進: GKE のカスタム指標のネイティブサポートを導入

1. 多目的ロードバランシングのチューニング

最適化された分散ストレージバックエンド

高度なジョブキューイングのための Kueue

極端な負荷下におけるコントロールプレーンの安定性

コールドスタートを減らしてレジリエンスとスケーラビリティを向上