Cloud Run での AI のコールド スタートに関するガイド

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

あるデベロッパーが Reddit で、複数のリージョンにまたがる Cloud Run で AI のコールド スタートを管理する「賢明な方法」はないかと質問しているのを見かけました。最大 20 秒にも及ぶ起動レイテンシに悩まされており、ユーザーが応答を待っている間にインフラストラクチャがスピンアップするという状況にもどかしさを感じていました。

そのディスカッションには、サーバーレス GPU をほぼ諦めかけていたデベロッパーも多数参加しており、中にはレイテンシを回避するためだけに GKE に戻す人もいました。そこで私は、AI のコールド スタートの仕組みを深く掘り下げ、その「賢明な方法」を見つけ出せるかどうか確かめてみることにしました。

Cloud Run で Gemma 4 などのモデルをホストする方法について調査していたところ、Google Cloud Next '26 で Oded Shahar（Cloud Run のシニア エンジニアリング マネージャー）とゲスト スピーカーの Ajay Nair 氏（Elastic のプラットフォーム担当グローバル バイス プレジデント）と一緒に共同プレゼンテーションを行う機会に恵まれました。

そのセッション「Cloud Run でカスタムモデルを使用して AI アーキテクチャを構築する」で、Nair 氏は、Cloud Run の「ゼロへのスケーリング」という効率性を維持しながら、17 種類以上のモデル バリエーションで 1 日数百万件のリクエストの処理を可能にした、Elastic の本番環境で実証済みの戦略を共有しました。

Nair 氏は、その秘訣はモデルそのもののみならず、GPU を管理すべきインフラストラクチャとしてではなく、代替可能なコンピューティングとして扱うことにあると教えてくれました。

その時、コールド スタートのレイテンシを最小限に抑えることは、単にモデルだけの問題ではなく、それを高速でスケーラブルかつ安全に維持するためのインフラストラクチャのパターンやアーキテクチャに関する決定も重要であることに気付いたのです。

AI のコールド スタートの仕組み

公式の Google Cloud GPU パフォーマンスのベスト プラクティスで説明されているように、AI のコールド スタートは、標準的なウェブ マイクロサービスのコールド スタートとは異なります。単にコードを起動するだけでなく、ギガバイト単位の重みを専用の物理アクセラレータに転送させるからです。

これは、4 段階のレースだと考えてください。各段階（フェーズ）を最適化しなければ、ユーザーを失うことになってしまいます。

フェーズ 1: インフラストラクチャのプロビジョニング（約 5 秒）

Cloud Run は物理 GPU を割り当て、プリインストールされた NVIDIA ドライバを追加します。Google がドライバを管理するため、Dockerfile が膨らむことはありません。

フェーズ 2: ブロックレベルのコンテナ イメージ ストリーミング（1 ～ 2 秒）

Cloud Run は「イメージ ストリーミング」を採用しており、起動に必要なブロックのみを取得します。15 GB の CUDA イメージでも、実際は小さな Node.js アプリと同じくらいの速さで起動できます。

フェーズ 3: エンジンの初期化（5 ～ 15 秒）

ここで、推論エンジン（vLLM、Ollama）がウォームアップします。これは CPU 負荷が高い処理であり、多くのユーザーが気付かないうちにスロットリングされる部分です。

フェーズ 4: モデルの読み込みと VRAM への転送

これが最後の難関です。モデルの重みをストレージから GPU メモリへと転送します。CPU が重要視される標準的なウェブアプリとは異なり、ここでは GPU メモリが主な制約要因となります。モデルの重みが GPU メモリに収まりきらない場合、より低速なシステム RAM にスワップされるため、パフォーマンスが大幅に低下します。

AI のコールド スタートを処理するためのベスト プラクティス

「賢明」な本番環境を構築するために、GPU を使用した AI 推論に関する Google Cloud の公式ドキュメントを参考に、いくつかの重要なポイントをご紹介します。

フェーズ 4 の最適化

適切なデプロイ オプションの選択

フェーズ 4 は、ギガバイト単位の重みをストレージから GPU メモリへと転送する「最後の難関」です。ストレージの選択によって、この転送の速度が決まります。

• Cloud Storage（同時ダウンロード）- 最速: Google Cloud CLI（gcloud storage cp）を使用すると、モデルファイルを並列でダウンロードできます。ネットワーク スループットを最大化し、転送時間を大幅に短縮できるため、大規模な重みに対して推奨される方法です。

• Cloud Storage（FUSE）- 最も簡単: バケットをローカル ファイル システムとしてマウントすることで、「コード変更を不要」にします。ただし、最初のダウンロードを並列化しないため、大規模なモデルの重みに対してはかなり遅くなります。

• コンテナ イメージ - 10 GB 未満に最適: 小規模なモデルの場合、Cloud Run のイメージ ストリーミングを使用してイメージに重みを付けるのが効率的です。ただし、10 GB を超えるモデルの場合、インポートやストリーミングのオーバーヘッドがボトルネックとなる可能性があります。

• インターネット: 避けるべきです。本番環境での推論において、最も時間がかかり、かつ最も予測困難な方法です。

モデルの形式とサイズ

フェーズ 4（モデルの読み込みと VRAM への転送）の時間の短縮につながる「裏技」が、モデルの形式とサイズの最適化です。このフェーズは、ギガバイト単位のデータを VRAM に転送できる速度によって制約されるため、より小さく効率的なファイルが重要となります。

•  4 ビット量子化: これはコールド スタートの究極の裏技です。重みが小さいほど、ストレージから引き出すギガバイト数が減るため、フェーズ 4 のダウンロードと転送のプロセスが直接高速化されます。

• 高速な形式: 起動時間を最小限に抑えるために、GGUF のような読み込み時間が短いモデル形式を選択します。最も高速なパフォーマンスを得るには、Python の「pickle」ファイルの使用を避け、ゼロコピー読み込みを実現する Safetensors を使用します。

• VRAM の容量の確保: 量子化モデルを使用して、重みが GPU メモリ内に完全に収まるようにします。モデルが VRAM を超えると、システムは非常に低速な RAM にスワップするため、フェーズ 4 が行き詰まってしまいます。

フェーズ 3 と 4 の最適化: インフラストラクチャとネットワークの活用手段

これらのインフラストラクチャ設定は、起動プロセスの最も要求の厳しい部分を高速化するために必要なリソースを提供します。

起動時の CPU ブースト（フェーズ 3 を高速化）

この機能により、起動時の CPU 性能が一時的に 2 倍になります。1 vCPU インスタンスが、起動中およびサービス提供開始後の最初の 10 秒間、2 vCPU に増強されます。エンジンの初期化は CPU 負荷の高い処理であるため、フェーズ 3 ではこの機能が不可欠です。

ダイレクト VPC 下り（外向き）と PGA（フェーズ 4 を高速化）

プライベート Google アクセス（PGA）でダイレクト VPC 下り（外向き）を利用すると、モデルの重み付けトラフィックが Google の内部高速バックボーン上に留まります。これにより、ネットワーク パスが最適化され、ギガバイト単位の重みを VRAM に転送する時間が短縮されます。

同時実行のチューニング（コールド スタートの回避）: 

Cloud Run において、「同時実行」とは、プラットフォームがスケールアウトして新しいインスタンスを起動する前に、単一インスタンスが処理できるリクエストの最大数を指します。AI ワークロードの場合、この設定はモデルエンジンの内部並列処理フラグ（例: vLLM の --max-num-seqs や Ollama の OLLAMA_NUM_PARALLEL）と合わせて調整する必要があります。

Cloud Run の最適な同時実行数を算出するには、公式の Google Cloud の数式を使用します。

（モデル インスタンス の数 ∗モデル あたりの 並列クエリ 数）+（モデル インスタンス の数 ∗理想的な バッチサイズ）

例: インスタンスが 3 つのモデル インスタンスを GPU に読み込み、各モデル インスタンスが 4 つの並列クエリを処理でき、理想的なバッチサイズが 4 である場合、Cloud Run の最大同時リクエスト数を 24 に設定します:（3 × 4）+（3 × 4）

計算方法: 目標は、GPU を完全に飽和状態に保ちながら、ユーザーが長いキューで待機しないようにすることです。この例では、合計 24 の同時リクエストが 2 つの機能グループに分割されています。

1. アクティブな処理（12 リクエスト）:（3 インスタンス × 4 クエリ）で計算され、GPU が任意の時点でアクティブに処理できるリクエストの合計数を表します。

2. 「次のバッチ」バッファ（12 のリクエスト）:（3 インスタンス × 4 バッチサイズ）で計算されます。これらは、コンテナ内で「待機中」のリクエストです。GPU が最初のバッチを完了すると、すぐにこれらの待機中のリクエストを処理します。

この値を VRAM の許容範囲内で最大（通常 10 ～ 20 ユーザー）にチューニングすることで、1 つのウォーム インスタンスで多数のリクエストを処理できるようになり、新しいスケールアウト イベントやそれに伴うコールド スタートをトリガーせずに済みます。

スケーリング制御（しきい値の調整）

上記の式は最大容量を定義するものですが、Cloud Run が次のインスタンスを起動するタイミングを調整することもできます。Cloud Run のオートスケーラーは通常、60% の使用率を目標としていますが、時間がかかる AI のコールド スタートの場合、スケーリング制御を使用して、このしきい値を 80% または 90% に引き上げることができます。

• 同時実行目標数: この値を大きくすると、スケールアウトがトリガーされる前に、単一のウォーム インスタンスにより多くのリクエストを「詰め込む」ことができます。

• CPU 目標値: CPU 目標値を引き上げることで、初期化や高負荷の推論によって CPU 使用率が一時的に急上昇しただけで、プラットフォームが新しいインスタンスを起動するのを防ぐことができます。

スケーリングと信頼性に関する戦略

単一リージョンの「常時稼働」のトレードオフ

グローバルにデプロイする場合、すべてのリージョンで最小インスタンス数を 1 に設定すると費用がかさみます。代わりに、1 つのリージョンのみで「常時稼働」のサービスを行うことを検討してください。グローバル ネットワークの遅延が 100 ミリ秒でも、ローカルのコールド スタートに 20 秒かかるよりは、はるかに優れたユーザー エクスペリエンスを提供できます。

15 分間の猶予期間: よく聞かれる質問に、「リクエストの後、インスタンスはどのくらいの間ウォーム状態を維持しますか？」というのがあります。Cloud Run は通常、インスタンスがアイドル状態（リクエストを処理していない状態）になってから 15 分間インスタンスの稼働を維持します。トラフィックが予測可能で、10 ～ 12 分ごとに発生する場合、「常時稼働」のサービスは必要ないかもしれません。プラットフォームのデフォルトのシャットダウン ポリシーにより、次のユーザーにウォーム インスタンスが無料で準備されます。

「先手を打った措置」戦略

時として、コールド スタートに対処する最善の方法は、先手を打った措置を講じることです。たとえば、ユーザーが「新しいチャット」をクリックしたり、テキスト領域にカーソルを合わせたりした時など、UI で次のリクエストを予測できる場合は、サービスに向けてすぐに軽量なヘルスチェックを送信できます。ユーザーがプロンプトの入力を終える頃には、コールド スタートの最初の 2 つのフェーズ（インフラストラクチャのプロビジョニングとコンテナ イメージのストリーミング）は、バックグラウンドですでに完了しています。

上級者向けのヒント: 非推論エンドポイントを使用します。この「先手を打った措置」を可能な限り高速化するには、「hi」のようなダミー プロンプトを送信するのではなく、常に非推論エンドポイントを使用します。

• 高速な理由: 非推論エンドポイント（vLLM の /v1/models や Ollama の /api/tags など）は、コンテナのウェブサーバーが起動した瞬間に処理されます。そのため、時間のかかる「フェーズ 4」のモデルの読み込みや VRAM への転送の完了を待つことなく、成功レスポンスを送信できます。

• チャット履歴への干渉なし: これらのエンドポイントはモデルの補完ロジックをトリガーしないため、ユーザーの実際のチャット履歴に干渉したり、バックエンドで誤ってセッションの作成をトリガーしたりすることはありません。

推奨されるエンドポイント:

• vLLM: GET /health または GET /v1/models

• Ollama: GET /api/tags または GET /api/version

VRAM の起動プローブの調整

AI モデルは、ストレージから GPU メモリにギガバイト単位の重みを転送するのにかなりの時間を要します（フェーズ 4）。起動チェックが何度も失敗すると、Cloud Run はコンテナが破損していると判断して強制終了します。

これを回避するには、以下を行います。

1. 失敗しきい値を引き上げる: 高い failureThreshold を使用します（例: 60 以上）。許容される合計起動時間は failureThreshold \times periodSeconds の積であるため、しきい値を 60、間隔を 5 秒にすると、5 分間というモデルを読み込むために十分な時間が確保されます。

2. 最大 30 分を活用: 標準サービスでは起動時間が 4 分に制限されていますが、Cloud Run では負荷の高いワークロードに対して、最大 30 分（1,800 秒）の合計起動時間をサポートしています。

3. 偽陽性の回避（Ollama 対策）: Ollama のようなエンジンを使う場合、サービスの開始直後、モデルが実際に VRAM に読み込まれる前に TCP ポートが開かれることがあるため、注意が必要です。コンテナのエントリポイント スクリプトで必ずモデルをプリロードし、モデルが確実に推論を実行できる状態になった時点で起動プローブが成功するようにしてください。

Elastic の戦略から得られる教訓

NEXT ‘26 のセッションにおいて、Ajay Nair 氏は、Elastic が GPU を管理すべきインフラストラクチャとしてではなく、代替可能なコンピューティングとして扱うことを可能にした 3 つのアーキテクチャに関する決定事項について強調しました。

1. コンパイル費用の回避: vLLM で enforce_eager=True を設定することで、わずかなスループットを犠牲にする代わりに、コールド スタートが数分ではなく 1 分未満で完了するようにしました。

2. スタンドアロンのチェックポイント: 各 LoRA バリエーションを事前にスタンドアロンのチェックポイントに統合することで、実行時のアダプタの切り替えに伴うレイテンシを回避しました。

3. 1 つのワークロード、1 つのサービス: モデル、タスク アダプタ、トラフィック パターンによって定義される、それぞれ個別のスケーラブルなワークロードは、独自の Cloud Run サービスとしてデプロイされます。これにより、約 15 のモデル ファミリーで 30 以上のサービスが生成され、一部のモデルはタスク（例: v5 の取得とクラスタリング）やクエリ / パッセージの役割によって分割されています。

準備ができたら

コールド スタートのプロセスを最適化できるかどうかが、趣味のプロジェクトとプロダクション レディなアプリケーションとの違いを決定付けます。この最適化の最大のメリットは、Cloud Run が NVIDIA ドライバと CUDA のインストールを処理し、インスタンスを約 5 秒で起動できることです。

詳細については、次の公式ドキュメントをご覧ください。

• ベスト プラクティス: GPU を使用した Cloud Run での AI 推論

• Cloud Run サービスの GPU 構成

• Cloud Run の起動時の CPU ブースト

技術的な詳細については、Google Cloud Next '26 のセッションの録画をご覧になることを強くおすすめします。サーバーレス インフラストラクチャで高性能なオープンモデルをホストするための最も包括的なブループリントを確認できます。

開発をお楽しみください。

この記事に対して、レビューとフィードバックを提供してくださった、Cloud Run チームの Sara Ford と Shane Ouchi、Elastic の Zac Li 氏に心より感謝いたします。

- Google Cloud デベロッパーリレーションズ、AI エンジニアリング責任者、Shir Meir Lador