Containers & Kubernetes

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

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

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

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

これにより、エージェントや 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 0x7f3d80760d30>)])]>

導入後（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 0x7f3d80760ee0>)])]>

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

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

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

デプロイ後、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 0x7f3d542fcbb0>)])]>

この構成を作成したら、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 0x7f3d81b50e80>)])]>

これで完了です。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 0x7f3d5507e5e0>)])]>

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

これで完了です。残りの処理はストリーマーが行い、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 0x7f3d550a3340>)])]>

このように分けてしまうことで、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

マイナーバージョンのロールバックで Kubernetes バージョンのアップグレードがより安全に

Mon, 17 Nov 2025 02:00:00 +0000

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

Kubernetes クラスタのアップグレードは、常に一方通行でした。前進するしかなく、コントロールプレーンに問題が発生した場合は、修正を適用してロールフォワードするしかありませんでした。これは日常的なメンテナンスに大きなリスクをもたらします。組織が新しい AI 機能のためにアップグレードを頻繁に行うようになり、同時に最大限の信頼性を求めるようになると、この問題はさらに悪化します。このたび、Kubernetes コミュニティと連携して、この問題を解決する Kubernetes 1.33 の新機能、Kubernetes コントロールプレーンのマイナーバージョンロールバックを導入しました。コントロールプレーンのアップグレードをロールバックする信頼できる方法が初めて提供されることで、クラスタのライフサイクル管理が根本的に変わります。この機能はオープンソースの Kubernetes で利用可能で、Google Kubernetes Engine では GKE 1.33 以降で統合され、まもなく一般提供される予定です。

課題: ロールバックが困難だった理由

Kubernetes のコントロールプレーンコンポーネント、特に kube-apiserver と etcd はステートフルであり、API バージョンの変更に非常に敏感です。アップグレードすると、新しいバイナリに多くの新しい API と機能が導入されます。一部のデータは、新しい形式や API バージョンに移行される場合があります。変更を安全に元に戻すメカニズムがないため、ダウングレードはサポートされていませんでした。ダウングレードすると、データが破損し、クラスタ障害が発生するリスクがありました。

簡単な例として、既存のリソースに新しいフィールドを追加することを考えてみましょう。これまで、ストレージと API は同時に処理されていたため、クライアントは新しいフィールドにすぐにデータを書き込むことができました。回帰が検出された場合、ロールバックによってそのフィールドへのアクセスは削除されますが、書き込まれたデータはガベージコレクションされません。代わりに、etcd にサイレントに保存されます。これにより、管理者はどうすることもできない状況に陥ります。さらに悪いことに、そのマイナーバージョンに再アップグレードすると、この古い「ガベージ」データが突然「復活」し、問題が発生する可能性のある、予測不可能な動作を引き起こす場合があります。

解決策: エミュレートされたバージョン

Kubernetes Enhancement Proposal（KEP）の KEP-4330: Compatibility Versions では、コントロールプレーンの「エミュレートされたバージョン」というコンセプトが導入されています。Google 社員が提供したこの機能により、2 段階の新しいアップグレードプロセスが作成されます。

ステップ 1: バイナリをアップグレードする。コントロールプレーンのバイナリはアップグレードされますが、「エミュレートされたバージョン」はアップグレード前のバージョンと同じままです。この段階では、すべての API、機能、ストレージデータ形式は変更されません。これにより、問題が見つかった場合にコントロールプレーンを以前の安定版に安全にロールバックできます。

健全性を検証し、回帰をチェックする。最初のステップでは、安全な検証期間が作成されます。この期間中は、新しい API バージョンにコミットする前に、続行しても安全であることを確認できます。たとえば、新しいバイナリで独自のコンポーネントやワークロードが正常に実行されていることを確認したり、パフォーマンスの低下がないかチェックしたりできます。

ステップ 2: アップグレードを完了する。テストが完了したら、エミュレートされたバージョンを新しいバージョンに「バンプ」します。これにより、最新の Kubernetes リリースのすべての新しい API と機能が有効になり、アップグレードが完了します。

この 2 段階のプロセスにより、きめ細かい制御、より優れたオブザーバビリティ、ロールバックの安全な検証期間が実現します。アップグレードで予期しない問題が発生した場合、ロールフォワードのために慌てる必要はなくなります。これにより、既知の良好な状態に戻し、クラスタを安定させ、次の動きを冷静に計画するための信頼できる方法が提供されます。これらはすべて、オープンソースの Kubernetes と GKE の両方で 2 段階アップグレードの包括的なテストによって裏付けられています。

これを実現するには多大な労力が必要でしたが、テスト、コンプライアンス、機能の適応に尽力し、この高度な機能を現実のものとしたすべての Kubernetes のコントリビューターと機能のオーナーに感謝いたします。

GKE 1.33 で近日リリース予定のこの機能は、アップグレードのリスクを軽減し、予期せぬ問題からの復旧時間を大幅に短縮する新しいツールとなります。

OSS Kubernetes でのアップグレードエクスペリエンスの向上

このロールバック機能は、コミュニティ全体の Kubernetes アップグレードエクスペリエンスを向上させるための、Google の長期的な大規模投資の一環にすぎません。Google では、クラスタの運用をよりスムーズ、安全、自動化するために、他にもいくつかの重要な機能強化をアップストリームで取り組んでいます。その一例をご紹介します。

バージョンをスキップしたアップグレードのサポート: KEP-4330 に関する作業により、Kubernetes の「スキップレベル」アップグレードが可能になります。つまり、すべてのマイナーバージョンに順番にアップグレードしていく必要がなくなり（例: v1.33 から v1.34、v1.35）、古いバージョンから新しいバージョンに直接アップグレードできるようになります。場合によっては、1 つ以上の中間リリースをスキップできます（例: v1.33 から v1.35）。これにより、大規模なアップグレードに伴う複雑さを軽減してダウンタイムを削減し、クラスタオペレータにとってプロセスをより効率的で中断の少ないものにすることを目指しています。
Coordinated Leader Election（KEP-4355）: この取り組みにより、さまざまなコントロールプレーンコンポーネント（kube-controller-manager や kube-scheduler など）がアップグレード中のリーダーシップの変更を適切に処理できるようになり、Kubernetes のバージョンスキューポリシーに違反しないようになります。
Graceful Leader Transition（KEP-5366）: 上記を基に、リーダーがアップグレードのためにシャットダウンする前に、そのポジションをクリーンに引き継ぐことができるようになります。これにより、コントロールプレーンコンポーネントのダウンタイムなしの移行が可能になります。
Mixed Version Proxy（KEP-4020）: この機能は、バージョンが混在するクラスタ（アップグレード中など）における API サーバーの信頼性を向上させます。リソースを認識するサーバーにリソースリクエストをインテリジェントにルーティングすることで、誤った「NotFound」エラーを防止します。また、検出によって、バージョンが混在するクラスタ内のすべてのサーバーからすべてのリソースの完全なリストが提供されるようにします。
Component Health SLIs for Upgrades（KEP-3466）: 安全にアップグレードするには、クラスタが正常な状態かどうかを知る必要があります。この KEP では、Kubernetes のコアコンポーネントの標準化されたサービスレベル指標（SLI）を定義します。これにより、自動アップグレードのカナリア分析に使用可能な、明確なデータドリブンシグナルが提供され、クラスタ全体に影響する前に不適切なロールアウトを停止できます。

これらの機能は、Kubernetes クラスタのライフサイクル管理の成熟度を大きく前進させるものです。この成果をオープンソースコミュニティに提供し、GKE のお客様にこれらの強力な機能をお届けできることを大変誇りに思います。

KubeCon で詳細を確認する

オープンソース機能とアップグレードの変更について詳しくお知りになりたい方は、KubeCon で Google のチームに会いに来てください。ブース #200 と #1100、および以下のセッションで皆様をお待ちしております。

Accelerating Innovation: The Evolution of Kubernetes and the Road Ahead（Google、Jago Macleod）
Upgrade Nightmare To Uptime Dream: The Cloud Provider's Playbook for Critical Kubernetes Work（Yuchen Zhou（Google）と Uttam Kumar 氏（Salesforce））
Navigating the Multi-Version Kubernetes Universe: How Emulation Version Shapes Your Contributions（Google、Siyuan Zhang による Maintainer Summit での講演）
GKE Upgrade: A New Era of Safety and Control（Google、Wenjia Zhang）ブース #200

使ってみる

オープンソースのイノベーションとマネージドサービスの卓越性を組み合わせることにより、このような結果が得られます。この新しい安全なアップグレード機能は、GKE 1.33 で間もなくリリースされます。クラスタの管理について詳しくは、GKE のドキュメントをご覧ください。

-ソフトウェアエンジニア、Siyuan Zhang

-エンジニアリングマネージャー、Wenjia Zhang

分散 AI と ML の未来に向けて Ray と Kubernetes をともに進化させる

Wed, 12 Nov 2025 01:01:00 +0000

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

Ray は、Google Cloud のデベロッパーの間で人気のある OSS コンピューティングエンジンで、CPU、GPU、TPU にわたる複雑な分散 AI ワークロードを処理します。同様に、プラットフォームエンジニアは、Kubernetes、特に Google Kubernetes Engine の強力で信頼性の高いインフラストラクチャオーケストレーションに長い間信頼を寄せてきました。今年初め、Google は Anyscale とのパートナーシップを発表し、Ray と Kubernetes の優れた機能を組み合わせて、最も要求の厳しい AI ワークロードに対応する分散オペレーティングシステムを構築しました。今回は、Ray と Kubernetes で共同開発したオープンソースの機能強化についてご紹介します。

Ray と Kubernetes のラベルベースのスケジューリング

Ray の主なメリットの一つは、柔軟なプリミティブセットです。これにより、デベロッパーは基盤となるハードウェアを直接意識することなく、分散アプリケーションを記述できます。しかし、Ray の仮想リソースの既存のサポートでは十分にカバーされないユースケースもあります。

スケジューリングの柔軟性を高め、Ray アプリケーションの自動スケーリングを Ray と Kubernetes のスケジューラがより適切に実行できるようにするため、ラベルセレクタを Ray に導入します。Ray のラベルセレクタは、Kubernetes のラベルとセレクタに大きく影響を受けており、両方のシステム間で使い慣れたエクスペリエンスとスムーズな統合を提供することを目的としています。Ray Label Selector API は Ray v2.49 以降で利用可能で、分散タスクとアクターのスケジューリングの柔軟性が向上します。

新しい Label Selector API により、Ray はデベロッパーが以下のようなことを直接行えるようにします。

Ray クラスタ内のノードにラベルを割り当てる（例: gpu-family=L4, market-type=spot, region=us-west-1）。
タスク、アクター、プレースメントグループを起動する際に、実行するゾーン、リージョン、アクセラレータタイプを宣言する。
カスタムラベルを使用して、トポロジと高度なスケジューリングポリシーを定義する。

GKE で分散アプリケーションをスケジューリングするには、Ray と Kubernetes のラベルセレクタを組み合わせて使用することで、アプリケーションと基盤となるインフラストラクチャを完全に制御できます。また、この組み合わせを GKE のカスタムコンピューティングクラスと併用して、特定の GPU タイプが利用できない場合のフォールバック動作を定義することもできます。具体的な例を見てみましょう。

以下は、利用可能な容量に応じてさまざまな GPU タイプで実行できる Ray リモートタスクの例です。Ray v2.49 以降では、プライマリ GPU タイプまたはマーケットタイプが利用できない場合に、フォールバック動作で GPU をバインドするアクセラレータタイプを定義できるようになりました。この例では、リモートタスクは L4 GPU を使用したスポット容量をターゲットにしていますが、オンデマンドへのフォールバックも可能です。

code_block: <ListValue: [StructValue([('code', '@ray.remote(\r\n label_selector={\r\n "ray.io/accelerator": "L4"\r\n "ray.io/market-type": "spot"\r\n },\r\n fallback_strategy=[\r\n {\r\n "label_selector": {\r\n "ray.io/accelerator": "L4"\r\n "ray.io/market-type": "on-demand"\r\n }\r\n },\r\n ]\r\n)\r\ndef func():\r\n pass'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3d565033a0>)])]>

GKE では、カスタムコンピューティングクラスを使用して同じフォールバックロジックを結合し、Ray クラスタの基盤となるインフラストラクチャが同じフォールバック動作と一致するようにできます。

code_block: <ListValue: [StructValue([('code', 'apiVersion: cloud.google.com/v1\r\nkind: ComputeClass\r\nmetadata:\r\n name: gpu-compute-class\r\nspec:\r\n priorities:\r\n - gpu:\r\n type: nvidia-l4\r\n count: 1\r\n spot: true\r\n - gpu:\r\n type: nvidia-l4\r\n count: 1\r\n spot: false\r\n nodePoolAutoCreation:\r\n enabled: true\r\n whenUnsatisfiable: DoNotScaleUp'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3d56503c70>)])]>

Ray ラベルセレクタの使用を開始するには、Ray のドキュメントをご覧ください。

Ray と Kubernetes でのアクセラレータサポートの強化

今年初め、Google は新しい Ray Serve LLM API を使用して、A3 High および A3 Mega マシンインスタンスで GKE 上に DeepSeek-R1 などの大規模モデルをデプロイする機能を実証しました。GKE v1.33 と KubeRay v1.4 以降では、動的リソース割り当て（DRA）を使用してハードウェアアクセラレータを柔軟にスケジューリングして共有できるため、Ray で次世代の AI アクセラレータを使用できます。具体的には、NVIDIA GB200 NVL72 ラックスケールアーキテクチャを利用する A4X シリーズのマシンに、DRA を使用して Ray クラスタをデプロイできるようになりました。A4X での Ray で DRA を使用するには、A4X 上に AI 向けに最適化された GKE クラスタを作成し、NVL72 ラックを表す ComputeDomain リソースを定義します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: resource.nvidia.com/v1beta1\r\nkind: ComputeDomain\r\nmetadata:\r\n name: a4x-compute-domain\r\nspec:\r\n numNodes: 18\r\n channel:\r\n resourceClaimTemplate:\r\n name: a4x-compute-domain-channel'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3d565033d0>)])]>

次に、Ray ワーカーの Pod テンプレートでクレームを指定します。

code_block: <ListValue: [StructValue([('code', 'workerGroupSpecs:\r\n ...\r\n template:\r\n...\r\nspec:\r\n ...\r\n volumes:\r\n ...\r\n containers:\r\n - name: ray-container\r\n ...\r\n resources:\r\n limits:\r\n nvidia.com/gpu: 4\r\n\t claims:\r\n - name: compute-domain-channel\r\n ...\r\nresourceClaims:\r\n - name: compute-domain-channel\r\n resourceClaimTemplateName: a4x-compute-domain-channel'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3d565036d0>)])]>

DRA と Ray を組み合わせることで、最も要求の厳しい Ray ワークロードで最適な GPU パフォーマンスを実現するために、Ray ワーカーグループが同じ GB200 NVL72 ラックに正しくスケジューリングされます。

また、Anyscale とのパートナーシップにより、Ray でよりネイティブな TPU エクスペリエンスを実現し、JAX などのフレームワークとのエコシステム統合を強化します。Ray Train では、Ray v2.49 以降で JAXTrainer API が導入され、JAX を使用した TPU でのモデルトレーニングが効率化されました。Ray でのこれらの TPU の改善について詳しくは、「A more native experience for Cloud TPUs with Ray on GKE」をご覧ください。

Kubernetes の書き込み可能な cgroup を使用した Ray ネイティブのリソース分離

書き込み可能な cgroup を使用すると、コンテナのルートプロセスは、特権機能を必要とすることなく、同じコンテナ内にネストされた cgroup を作成できます。この機能は、同じコンテナ内でユーザーコードと並行して複数のコントロールプレーンプロセスを実行する Ray にとって特に重要です。最も負荷の高いワークロードでも、Ray はコンテナリソースの合計の一部をシステムクリティカルなタスク用に動的に予約できるため、Ray クラスタの信頼性が大幅に向上します。

GKE v1.34.X-gke.X 以降では、次のアノテーションを追加することで、Ray クラスタの書き込み可能な cgroup を有効にできます。

code_block: <ListValue: [StructValue([('code', 'metadata:\r\n annotations:\r\n node.gke.io/enable-writable-cgroups.test-container: "true"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3d56503bb0>)])]>

書き込み可能な cgroup を使用して Ray のリソース分離を有効にするには、ray start で次のフラグを設定します。

code_block: <ListValue: [StructValue([('code', 'ray start --head --enable-resource-isolation'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3d565030d0>)])]>

この機能は、セキュリティを損なうことなくスタック全体の信頼性を向上させるために、Ray と Kubernetes を進化させている例の一つです。

近日中に、タスクおよびアクターごとのリソース制限と要件のサポートも導入する予定です。これは、Ray で長らく要望が寄せられていた機能です。さらに、この機能をアップストリームするために、オープンソースの Kubernetes コミュニティと協力しています。

Pod のインプレースサイズ変更による Ray の垂直自動スケーリング

Kubernetes v1.33 で Pod のインプレースサイズ変更が導入されたことで、Kubernetes で実行する際の Ray の垂直スケーリング機能を統合する初期段階に入りました。初期のベンチマークでは、Pod を水平スケーリングの前に垂直スケーリングすることで、ワークロードの効率が 30% 向上することが示されています。

3 つのワーカーノードを持つ GKE クラスタで、Ray を使用して 2 つの TPC-H ワークロード（クエリ 1 と 5）を 3 回完了した結果に基づくベンチマーク。各ワーカーノードには 32 個の CPU と 32 GB のメモリが搭載されています。

Pod のインプレースサイズ変更により、ワークロードの効率が次のように向上します。

タスク / アクターのスケールアップの高速化: インプレースサイズ変更により、Ray ワーカーは利用可能なリソースを数秒でスケールアップできます。新しいノードをプロビジョニングするのに数分かかる場合があることを考えると、大幅に改善されています。この機能により、新しい Ray タスクのスケジューリング時間が大幅に短縮されます。
ビンパッキングとリソース使用率の向上: Pod のインプレースサイズ変更により、Ray ワーカーを Kubernetes ノードに効率的にビンパッキングできます。新しい Ray ワーカーがスケールアップすると、利用可能なノード容量の小さな部分を予約し、残りの容量を他のワークロードのために解放できます。
信頼性の向上と障害の減少: メモリのインプレーススケーリングにより、メモリ不足（OOM）エラーを大幅に削減できます。失敗したジョブを再起動する必要がないため、この機能によりワークロード全体の効率と安定性が向上します。

Ray + Kubernetes = AI 向けの分散 OS

Google は、Anyscale とのパートナーシップから生まれた最近の共同イノベーションを紹介できることを嬉しく思います。Ray と Kubernetes は、その強力な相乗効果により、最新の AI / ML 向けの分散オペレーティングシステムとしての地位を確立しています。Google は、継続的なパートナーシップがオープンソースの Ray と Kubernetes のエコシステム内のイノベーションを加速し、最終的には分散 AI / ML の未来を推進すると考えています。

これらのアップデートにより、Ray が GKE でシームレスに動作するようになるための大きな一歩を踏み出しました。ご利用方法は以下のとおりです。

容量をリクエストする: Dynamic Workload Scheduler Flex Start を使用して、TPU と GPU をすぐに利用できます。これにより、7 日未満で実行されるジョブのコンピューティングにアクセスできます。
Ray on GKE を使ってみる
TPU で JaxTrainer を試す

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

Ray on GKE で Cloud TPU をよりネイティブに利用

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

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

エンジニアリングチームは、GPU と Cloud TPU の両方を含む幅広いハードウェアで AI ワークロードをスケーリングするために Ray を使用しています。Ray はコアとなるスケーリング機能を提供する一方、開発者は多くの場合、各アクセラレータの固有のアーキテクチャの詳細を管理してきました。Cloud TPU には、その特定のネットワーキングモデルと、単一プログラム複数データ（SPMD）プログラミングスタイルが含まれます。

Google は、Anyscale とのパートナーシップの一環として、Google Kubernetes Engine（GKE）で TPU を使用する際のエンジニアリング作業を削減する取り組みを進めています。その目標は、TPU での Ray の使用をできるだけネイティブで低摩擦なものにすることです。

本日、Google はそれを可能にするための重要な改善をいくつかリリースします。

Ray TPU ライブラリで、Ray Core における TPU の認識とスケーリングを改善

TPU には、独自のアーキテクチャと、SPMD と呼ばれる特定のプログラミングスタイルがあります。大規模な AI ジョブは、チップ間相互接続（ICI）と呼ばれる高速ネットワーキングで接続されたチップの集合体である TPU スライスで実行されます。

以前は、この特定のハードウェアトポロジを認識するように Ray を手動で設定する必要がありました。これは重要なセットアップ手順であり、正しく行われなければ、ジョブが接続されていない異なるスライスからリソースを断片的に取得し、深刻なパフォーマンスボトルネックを引き起こす可能性がありました。

この新しいライブラリ ray.util.tpu では、ユーザーがこれらのハードウェアの詳細を設定する必要がなくなりました。SlicePlacementGroup という機能と新しい label_selector API を使用して、コロケーションされた TPU スライス全体を 1 つのアトミックユニットとして自動的に予約します。これにより、ジョブは統合されたハードウェアで実行されることが保証され、断片化によるパフォーマンスの問題を回避できます。Ray ではこれまで、この単一スライスのアトミック性を保証できなかったため、信頼性の高い真のマルチスライストレーニング（意図的に複数のユニークなスライスにまたがる）を構築することは不可能でした。この新しい API は、Ray ユーザーがマルチスライステクノロジーを使用して複数の TPU スライスでスケーリングするための重要な基盤も提供します。

Jax、Ray Train、Ray Serve のサポートを拡大

Google の開発は、トレーニングと推論の両方に関わっています。トレーニングに関して、Ray Train は TPU 上の JAX（JaxTrainer 経由）と PyTorch のアルファ版サポートを提供しています。

JaxTrainer API を使用すると、マルチホスト TPU での JAX ワークロードの実行が簡素化されます。複雑な分散ホストの初期化を自動的に処理するようになりました。以下のコード例に示すように、ワーカー数、トポロジ、アクセラレータタイプなどのハードウェア要件を、シンプルな ScalingConfig オブジェクト内で定義するだけで済みます。残りの部分は JaxTrainer が行います。

これは、リソースの断片化という重大なパフォーマンス上の問題を解決する、大きな改善点です。以前は、「4x4」トポロジをリクエストするジョブ（スライスと呼ばれる単一のコロケーションハードウェアユニットで実行する必要がある）が、代わりに断片化されたリソースを受け取ることがありました。たとえば、1 つの物理スライスから 8 個のチップ、別の接続されていないスライスから 8 個のチップなどです。この断片化は、単一の統合されたスライス内にのみ存在する高速 ICI 相互接続をワークロードが使用できないため、大きなボトルネックとなっていました。

JaxTrainer がマルチホスト TPU でのトレーニングを簡素化する例:

code_block: <ListValue: [StructValue([('code', 'import jax\r\nimport jax.numpy as jnp\r\nimport optax\r\nimport ray.train\r\n\u200b\r\nfrom ray.train.v2.jax import JaxTrainer\r\nfrom ray.train import ScalingConfig\r\n\u200b\r\ndef train_func():\r\n"""この関数は、各分散ワーカーで実行されます。"""\r\n…\r\n\u200b\r\n# 分散ジョブのハードウェア構成を定義します。\r\nscaling_config = ScalingConfig(\r\nnum_workers=4,\r\nuse_tpu=True,\r\ntopology="4x4",\r\naccelerator_type="TPU-V6E",\r\nplacement_strategy="SPREAD"\r\n)\r\n\u200b\r\n# JaxTrainer を定義して実行します。\r\ntrainer = JaxTrainer(\r\ntrain_loop_per_worker=train_func,\r\nscaling_config=scaling_config,\r\n)\r\nresult = trainer.fit()\r\nprint(f"Training finished on TPU v6e 4x4 slice")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3d56f93820>)])]>

Ray Serve API は TPU をサポートしており、vLLM TPU の改善により、TPU に移行する際も vLLM で Ray を引き続き使用できます。これにより、GPU で使用しているのと同じスタックを、最小限のコード変更で TPU で実行できます。

ラベルベースのスケジューリング API で簡単に取得可能

新しいラベルベースのスケジューリング API は、GKE カスタムコンピューティングクラスと統合されています。カスタムコンピューティングクラスは、名前付きのハードウェア構成を定義する簡単な方法です。たとえば、cost-optimized というクラスを作成して、GKE にまず Spot インスタンスの取得を試み、次に Dynamic Workload Scheduler FlexStart インスタンスにフォールバックし、最終的に最後の手段として予約インスタンスにフォールバックするように指示できます。新しい Ray API では、Python からクラスを直接使用できます。シンプルな label_selector を使用して、「TPU-V6E」などのハードウェアをリクエストしたり、費用対効果が最適化されたクラスをターゲットにしたりでき、これらすべては個別の YAML ファイルを管理することなく行えます。

この同じ label_selector メカニズムは、TPU の詳細なハードウェア制御も公開します。GKE は、スライス用の TPU Pod をプロビジョニングする際に、メタデータ（ワーカーランクやトポロジなど）を各 Pod に挿入します。KubeRay（GKE 上の Ray を管理）は、GKE が提供するこのメタデータを読み取り、ノードの作成時に自動的に Ray 固有のラベルに変換します。これにより、TPU の世代（ray.io/accelerator-type）、物理チップのトポロジ（ray.io/tpu-topology）、スライス内のワーカーランク（ray.io/tpu-worker-id）などの重要な情報が提供されます。

これらのノードラベルを使用すると、Ray の label_selector を使用して、SPMD ワークロードを特定のコロケーションハードウェア（「4x4」トポロジや特定のワーカーランクなど）に固定できます。

以下の例では、Ray ユーザーが v6e-32 TPU スライスをリクエストしていますが、GKE にカスタムコンピューティングクラスを使用して、v6e-32 が利用できない場合は v5e-16 にフォールバックするように指示しています。同様に、ユーザーはスポットリソースまたは DWS リソースをリクエストすることから始め、それらが利用できない場合は、予約インスタンスにフォールバックできます。

デベロッパーがコンピューティングとノードプールを選択

プラットフォーム管理者が Kubernetes を設定

@ray.remote(num_cpu=1, label_selector={

"ray.io/tpu-pod-type": "v6e-32", “gke-flex-start”: “true”, },

fallback_strategy=[ {"label_selector": { "ray.io/tpu-pod-type": "v5litepod-16", “reservation-name”: “v5e-reservation”, }

]

)

def tpu_task(): # v6e 4x8 TPU スライス内のノードで実行を試み、 # v6e が利用できない場合は# v5e 4x4 TPU 内のノードにフォールバックする。…

apiVersion: cloud.google.com/v1kind: ComputeClass

metadata:

spec:

priorities:

- flexStart:

enabled: true

tpu: type:

tpu-v6e-slice

topology: 4x8

- tpu:

type: tpu-v5-lite-podslice

topology: 4x4

reservations:

specific:

- name: v5e-reservation

- affinity: Specific

TPU の指標とログを 1 か所に

TensorCore 使用率、デューティサイクル、高帯域幅メモリ（HBM）使用率、メモリ帯域幅使用率などの主要な TPU パフォーマンス指標を、Ray ダッシュボードで直接確認できるようになりました。また、低レベルの libtpu ログも追加しました。これにより、コードが原因で障害が発生したのか、TPU ハードウェア自体が原因で障害が発生したのかをすぐに確認できるため、デバッグが大幅に高速化されます。

使ってみる

これらのアップデートは、TPU を Ray エコシステムにシームレスに組み込む、大きな一歩です。これにより、既存の Ray アプリケーションを GPU と TPU の間で適応させるプロセスがはるかに分かりやすいものになります。詳細とご利用開始方法は次のとおりです。

ドキュメントを読む:

KubeRay で TPU を使用する
JAX ワークロード: JaxTrainer の使用方法については、新しいJAX を使ってみるガイドをご覧ください。JaxTrain の詳細もご覧ください。
TPU 指標: TPU 指標を Ray ダッシュボードまたは Grafana で表示

TPU 容量のリクエスト: 7 日未満で実行されるジョブに TPU へのアクセスを提供する TPU 向け DWS Flex Start を使用して、すぐに開始できます。
関連コンテンツ: TPU の概要

-Nisha Mariam Johnson、プロダクトマネージャー

-Ryan O'Leary、ソフトウェアエンジニア

Gemini CLI を使用して費用対効果の高い LLM ワークロードを GKE にデプロイする

Tue, 11 Nov 2025 00:00:00 +0000

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

LLM ワークロードをデプロイするのは複雑で費用もかかり、多くの場合、時間のかかる複数ステップのプロセスを伴います。この問題を解決するために、Google Kubernetes Engine（GKE）ではInference Quickstartが提供されています。

Inference Quickstart を使用すると、手作業による数か月もの試行錯誤を、すぐに使えるマニフェストとデーに基づく分析情報に置き換えることができます。Inference Quickstart は、ネイティブの Model Context Protocol（MCP）サポートを通じて Gemini CLI と統合され、LLM ワークロードのコストとパフォーマンス要件に合わせた最適な推奨を提供します。これらのツールを組み合わせることで、LLM を分析、選択、デプロイする作業を数分で完了できます。その方法をご紹介します。

1. Gemini CLI を使用して GKE で LLM を選択して提供する

gemini cli と gke-mcp サーバーをインストールする手順は以下のとおりです。

code_block: <ListValue: [StructValue([('code', '# Gemini CLI をインストールする（追加の手順）\r\nbrew install gemini-cli\r\n\u200b\r\n# gke-mcp を Gemini CLI 拡張機能としてインストールする\r\ngemini extensions install https://github.com/GoogleCloudPlatform/gke-mcp.git'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3d858ab580>)])]>

Gemini CLI に指定して LLM ワークロードを選択し、モデルを GKE クラスタにデプロイするために必要なマニフェストを生成するプロンプトの例を以下に示します。

code_block: <ListValue: [StructValue([('code', '1. GKE Inference Quickstart で利用できる最も安価なモデルを 3 つ挙げてください。関連するパフォーマンスデータと、実行したアクセラレータをすべて提供してください。\r\n2. このモデルを異なるアクセラレータで実行した場合、パフォーマンスはどのように異なりますか？\r\n3. この 2 つのモデルのどちらを選べばよいですか？\r\n4. このアクセラレータでこのモデルのマニフェストを生成し、現在のディレクトリに保存したいです。'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3d858ab8b0>)])]>

以下の動画では、この Gemini CLI の設定を使用して、最適な LLM ワークロードを迅速に特定し、既存の GKE クラスタにデプロイするエンドツーエンドの例を示しています。

2. パフォーマンスを維持しながらコストを節約

推論ワークロードに適したハードウェアを選択するには、パフォーマンスとコストのバランスを取る必要があります。ただし、そのトレードオフは単純ではありません。この複雑なトレードオフを簡単にするために、Inference Quickstart は Googleのベンチマークに基づいた、さまざまなアクセラレータにおけるパフォーマンスとコストの分析情報を提供します。

たとえば、下のグラフに示すように、vLLM 上の Gemma 3 4b のようなモデルのレイテンシを最小限に抑えると、コストが大幅に増加します。超低レイテンシを実現するには、リクエストのバッチ処理の効率を犠牲にする必要があるため、アクセラレータの利用率が下がってしまうためです。リクエストの負荷、モデルサイズ、アーキテクチャ、ワークロードの特性はすべて、特定のユースケースに最適なアクセラレータに影響する可能性があります。

十分な情報に基づいて意思決定を行うために、Gemini CLI に質問するか、Inference Quickstart の Colab ノートブックを使用して、データドリブンな推奨事項を即座に取得できます。

3. 入力 / 出力トークンあたりの費用を計算する

GKE などのプラットフォームで独自のモデルをホストする場合、課金されるのはアクセラレータの時間であり、個々のトークンではありません。Inference Quickstart では、アクセラレータの時間あたりのコストと入力 / 出力スループットを使用して、トークンあたりのコストを計算します。

次の式では、アクセラレータの総コストを入力トークンと出力トークンの両方に帰属させています。

code_block: <ListValue: [StructValue([('code', '$/出力トークン = アクセラレータ $/秒 /（1/4 入力トークン/秒 + 出力トークン/秒）\r\n\u200b\r\nここで\r\n$/入力トークン = ($/出力トークン) / 4'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3d858ab970>)])]>

この式では、出力トークンのコストは入力トークンの 4 倍であると想定しています。このヒューリスティックの理由は、プレフィルフェーズ（入力トークンの処理）は高度に並列化されたオペレーションであるのに対し、デコードフェーズ（出力トークンの生成）はシーケンシャルな自己回帰プロセスであるためです。Gemini CLI に、ワークロードの予想される入出力比率に合わせてこの比率を変更するように依頼できます。

費用対効果の高い LLM 推論を実現する鍵は、データドリブンなアプローチを採用することです。ワークロードのベンチマークに依存し、トークンあたりのコストなどの指標を使用することで、予算とパフォーマンスに直接影響する情報に基づいた意思決定を行うことができます。

次のステップ

GKE Inference Quickstart は、コストに関する分析情報と Gemini CLI の統合だけでなく、ストレージ、自動スケーリング、オブザーバビリティの最適化も含まれています。GKE Inference クイックスタートを使用して、LLM ワークロードを今すぐ実行し、GKE で LLM を迅速化および最適化する方法をご確認ください。

-Shuwen Fang、ソフトウェアエンジニア

-Anna Pendleton、ソフトウェアエンジニア

GKE と Gemini CLI の組み合わせで広がる可能性

Fri, 07 Nov 2025 03:00:00 +0000

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

クラウドネイティブ開発は常に進化しており、Google は、強力かつ直感的なツールで開発者と運用担当者を支援することに専念しています。

GKE Gemini CLI 拡張機能がオープンソース化されました。今回は、Gemini CLI と Google Kubernetes Engine（GKE）がどのように連携し、どのような新しい可能性を生み出すのかをご紹介します。この拡張機能により、GKE が Gemini CLI エコシステムに直接統合され、他の MCP クライアントからも MCP サーバーとして利用できます。これにより、開発者には次のようなメリットがあります。

リソース: GKE 固有のコンテキストを Gemini CLI の操作にシームレスに統合し、より簡潔で自然なプロンプトを実現します。
プロンプト: Gemini CLI のスラッシュコマンドと統合された詳細なプロンプトを提供し、一般的でありながら複雑なワークフローも簡単に完了できます。
強力なツール: 直感的なコマンドで GKE の機能を活用し、複雑な操作を簡素化します。Cloud Observability などのコンパニオンプロダクトとの統合も、特定のコンテキストとツールの追加により強化され、GKE 利用時の他の GCP プロダクトとのシームレスな互換性を確保しています。

定期的なリリースを通じて、GKE および GKE MCP サーバー向けの Gemini CLI 拡張機能の改善と強化を続けています。

お客様からは、すでにこの 2 つの連携について次のような声が寄せられています。「GKE と Gemini CLI の統合に強い関心を寄せています。この統合は、現実世界の課題を解決するためのエキサイティングな道筋を描いており、Google と協力してその未来を共に形作っていくことを楽しみにしています。」- Macquarie Bank エンジニアリング AI およびアーキテクチャ担当責任者 Jason O'Connell 氏

Gemini CLI が開発者にとって不可欠なツールになった理由

コマンドラインから直接 AI を活用する開発者にとって、Gemini CLI は瞬く間に欠かせないツールとなりました。詳細は、Gemini CLI に関するこちらのブログ投稿をご覧ください。この強力な AI エージェントは、コアツールへのアクセス機能を備え、幅広い標準機能を提供します。これにより、複雑なタスクを合理化し、開発ワークフローを加速できます。生産性を高めるインテリジェントなツールが持つ変革力を示しています。Gemini CLI は、GitHub で最も多くのスターを獲得したエージェント CLI となり、100 人を超えるコミュニティコントリビューターが関わる数十回のリリースを重ねています。

Gemini CLI の主な強みの一つは、その拡張性です。Gemini CLI 拡張機能は、MCP サーバー、コンテキストファイル、カスタムコマンドをシンプルなパッケージにまとめ、Gemini にあらゆるツールの使い方を教えます。この革新的なアーキテクチャにより、多様な拡張機能をシームレスに統合でき、開発者は AI を活用したワークフローを自在にカスタマイズして新たな可能性を切り開くことができます。

GKE: 次世代のワークロードを支える原動力

Google Kubernetes Engine（GKE）は、コンテナ化されたアプリケーションのデプロイ、管理、スケーリングを求める企業にとって、引き続き中核的なプラットフォームです。その堅牢で柔軟なインフラストラクチャにより、今後さらに重要性が高まる AI モデルのトレーニングや推論タスクなど、高度で要求の厳しいワークロードに最適な選択肢となっています。これまで GKE は、専用のリソースやプロンプト、ツールを持たず、Gemini CLI に組み込まれた Gemini 基盤モデルを活用してきました。

新しい GKE Gemini CLI 拡張機能は、驚くほど簡単に利用を開始できます。次の簡単なコマンドを実行して Gemini CLI にインストールするだけです。

code_block: <ListValue: [StructValue([('code', 'gemini extensions install https://github.com/GoogleCloudPlatform/gke-mcp'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3d82dc37c0>)])]>

他の MCP クライアントを使用している場合は、こちらでインストール手順を確認できます。

GKE + Gemini CLI: 推論の CUJ を実現

GKE と Gemini CLI を組み合わせることで、一般的な推論ユースケースで優れた効果を発揮します。GKE 上での AI モデルのデプロイと管理は、まるでコマンドラインと会話しているかのように自然です。

この強力な組み合わせがワークフローをどのように変革できるのかを、次の例で見てみましょう。

シナリオ: ML エンジニアとして、推論モデルをデプロイしたいと考えています。ビジネス要件を満たすために、どのモデルやアクセラレータを使用すればよいかわかりません。そこで、GKE MCP サーバーで構成された Gemini CLI に、レイテンシ要件 1,500 ミリ秒でモデルをデプロイするよう指示します。Gemini CLI は、モデルとアクセラレータの検出から、ビジネス要件に基づいたデプロイ可能な Kubernetes マニフェストの生成までのプロセスを自動化します。この動的なワークフローにより、作業の手間が大幅に軽減されました。

使ってみる

GKE と Gemini CLI を組み合わせることで、開発者は Kubernetes 上で AI を活用する際に、これまでになく効率的でパワフルな開発環境を体験できます。皆さんがこれらのツールを使って生み出す革新的なソリューションを楽しみにしています。Gemini CLI をダウンロードし、GKE Gemini CLI 拡張機能をインストールして、ぜひ試してみてください。ご意見もお聞かせください。

-Google シニアエンジニアリングマネージャー Adam Parco

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

Containers & Kubernetes

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 Inference Gateway で Vertex AI のレイテンシを 35% 削減した方法

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

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

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

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

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

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

問題点

解決策

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

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

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

メガクラスタの台頭

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

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

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

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

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

データアクセス向け GCS FUSE

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

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

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

Pod の低い起動レイテンシ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

マイナーバージョンのロールバックで Kubernetes バージョンのアップグレードがより安全に

OSS Kubernetes でのアップグレードエクスペリエンスの向上

Ray と Kubernetes でのアクセラレータサポートの強化

Pod のインプレースサイズ変更による Ray の垂直自動スケーリング