サーバーレスGPU推論対応のクラウドGPUプロバイダー

クラウドGPU推論における「サーバーレス」の本当の意味

上記の比較でプロバイダーにserverless: yesとタグ付けされている場合、それは長時間稼働するインスタンスを借りて管理することなくGPUワークロードを実行できることを意味します。ノードをプロビジョニングし、ウォーム状態を維持し、アイドル状態の秒数ごとに支払う代わりに、コンテナやモデルエンドポイントをデプロイし、プラットフォームが需要に応じてGPU容量を割り当て、トラフィックに応じてアクティブなワーカー数をスケールアップ・ダウンします。コードが実際にGPU上で実行されている時間に対して課金され、多くの場合は秒単位またはそれ以下の単位で計測され、リクエストがない場合は頻繁にゼロにスケールされます。

これは、従来の「GPUを搭載した仮想マシンを起動する」レンタルモデルとは根本的に異なります。サーバーレス層はホストを抽象化しており、SSHでボックスに入ることも、カーネルを選ぶことも、特定の物理カードをピン留めすることも通常ありません。必要なGPUクラスを指定し、イメージとエントリポイントを渡すだけで、プラットフォームが配置、オートスケーリング、終了処理を行います。

実際の推論ワークロードにおいてサーバーレスが重要な理由

サーバーレスGPUは推論パターンを中心に設計されており、長時間のトレーニングには向きません。需要が突発的、不規則、または平均的には低いがバースト的である場合に特に効果を発揮します。これはほとんどの本番AI機能に当てはまります：

• バースト的なAPIトラフィック — 午前3時にはリクエストがゼロで、正午に集中するチャットボット、画像生成器、埋め込みエンドポイント。GPUノードを24時間稼働させる代わりに、忙しい秒数だけ支払います。
• 多数の小モデルや多数のテナント — 数十の微調整済みバリアントを提供する場合、常時稼働のGPUをそれぞれに割り当てるのは無駄です。サーバーレスならアイドル状態のモデルはコストゼロです。
• イベント駆動型バッチジョブ — アップロードされたファイルの文字起こし、サムネイル生成、時折の埋め込みジョブなど、リクエストが来て処理が行われ、ワーカーが消えるパターン。
• プロトタイプや初期段階の製品 — 実際のトラフィック形状が分かる前に予約容量を確保するリスクを避けられます。

経済的な論理は単純です：従来のレンタルはプロビジョニングされた時間に対して支払いますが、サーバーレスは使用した時間に対して支払います。GPU利用率がフル稼働を大きく下回る場合、サーバーレスは劇的に安くなる可能性があります。GPUをほぼ飽和状態で24時間稼働させるなら、上記リストの専用または予約インスタンスの方が通常はお得です。

トレードオフ：コールドスタート、制御、上限

スケール・トゥ・ゼロは最大の利点であり、同時に主な欠点の原因でもあります。ワーカーが終了された後、次のリクエストはコールドスタートを待たなければなりません。プラットフォームがGPUをスケジューリングし、コンテナイメージをプルし、モデルの重みをVRAMにロードし、ランタイムを初期化します。数ギガバイトのモデルでは、最初のリクエストで数秒から数十秒の遅延が発生することがあります。考慮すべき点は：

• コールドスタート対コスト — 最小数のウォームワーカーを維持すればコールドスタートはなくなりますが、アイドル課金が再発生します。多くのプラットフォームは「最小レプリカ数」やウォームプール設定を提供し、レイテンシを下げることが可能です。
• ハードウェア制御の制限 — 正確なカードリビジョン、NUMAレイアウト、カスタムドライバーを選べないことが多いです。GPU階層を指定し、スケジュールされたものを受け入れます。
• ステートレス性 — ワーカーはリクエスト間で消えることがあるため、ローカルディスクは一時的です。永続的な状態、モデルキャッシュ、大きな重みは通常、接続されたネットワークボリュームやオブジェクトストレージに保存され、プラットフォームが対応しているか確認が必要です。
• 実行制限 — サーバーレス関数は最大リクエスト時間や同時実行数の制限があることが多いです。長時間のトレーニングジョブには不向きで、専用インスタンスが適しています。
• VRAMは依然として重要 — サーバーレスでもモデルとKVキャッシュがGPUメモリに収まる必要があります。サーバーレスのH100クラスワーカーはH100そのものであり、モデルに必要なVRAMで階層を選びます。

サーバーレスの比較ポイント

上記リストのサーバーレスとラベル付けされたプロバイダーは同じではありません。契約前に以下の詳細を確認してください：

1. 課金の細かさ — 秒単位が一般的ですが、リクエスト単位や100ミリ秒単位で課金する場合もあります。細かい単位は短く突発的な呼び出しに有利です。
2. スケール・トゥ・ゼロの挙動 — アイドル時に本当にコストがゼロになるか、トラフィック急増時にどれだけ速く復帰するか。
3. コールドスタートの軽減策 — ウォームプール、スナップショット、迅速なイメージプル、重みキャッシュなどが初回リクエストの遅延を減らします。
4. 提供されるGPU階層 — 利用可能なカードの範囲（エントリーレベル推論GPUからトップクラスアクセラレータまで）と階層ごとのVRAM容量。
5. 同時実行数とオートスケーリング制御 — 最大ワーカー数、ワーカーあたりのリクエスト数、負荷時のキュー挙動。
6. ストレージとネットワーク — 重み用の永続ボリューム、プラットフォームからの出力転送にかかる通信費。
7. コンテナか管理されたエンドポイントか — 任意のDockerイメージを持ち込むか、制約のある意見的なランタイムにデプロイするか。

最新の料金や各サーバーレスオプションが提供する正確なGPUクラスは、上記の比較表を参照してください。秒単位課金や利用可能ハードウェアは頻繁に変動します。

よくある質問

サーバーレスGPUは専用インスタンスより常に安いですか？

いいえ。GPUが多くの時間アイドル状態の場合にサーバーレスが有利です。作業がない時に支払いが停止するためです。GPUを24時間ほぼフル稼働させる場合、上記リストの専用オンデマンド、スポット、予約インスタンスの方が通常は計算単位あたりのコストが低くなります。これはレイテンシを低く保つためのリクエストごとのオーバーヘッドやウォームプール料金を回避できるためです。

サーバーレスGPUは推論だけでなくトレーニングにも使えますか？

一般的にフルトレーニングには不向きです。サーバーレスプラットフォームは短時間でステートレスな実行を好み、最大リクエスト時間や同時実行数の制限があることが多いです。一方、トレーニングは長時間かつステートフルなノードと高速なマルチGPUインターコネクトを必要とします。短いファインチューニングやバッチ推論は可能ですが、大規模トレーニングは専用インスタンスが適しています。

コールドスタートとは何で、どう避けますか？

コールドスタートは最初のリクエスト前の遅延で、プラットフォームがGPUをスケジューリングし、イメージをプルし、モデル重みをVRAMにロードする時間です。最小数のウォームワーカーを維持したり、小型または量子化モデルを使ったり、永続ボリュームに重みをキャッシュしたり、イメージプルが速いプロバイダーやスナップショット機能を選ぶことで軽減できます。ただしウォームワーカーを維持するとアイドルコストが再発生します。

サーバーレスで正確なGPUモデルを選べますか？

通常は特定のカードリビジョンではなくGPUの階層またはクラスを選びます。プラットフォームが適切なハードウェアをスケジュールするため、選択したサーバーレスオプションがモデルに必要なVRAMや精度（FP16、BF16、FP8、INT8など）をサポートする階層を提供しているか、上記比較で確認してください。