Vertex AI Provisioned Throughputはどんな企業に向いているか

向いている利用パターン

毎日一定量以上のトラフィックがあり、ピークが予測でき、遅延や容量不足が顧客体験へ直接影響するケースに向いています。検証段階や急激に需要が変わるサービスでは、オンデマンドの柔軟性が有利なことがあります。

オンデマンドとの比較

Provisioned Throughputは、対応モデルとロケーションを指定して処理能力を予約する固定費・固定期間のサブスクリプションです。処理量はGenerative AI Scale Unit（GSU）で扱われます。

一般論より先に自社ログを見る

導入判断には一般論よりも、自社の時系列データが重要です。モデル別の使用量を少なくとも数週間取得し、ピーク時の必要量と最低利用量を把握します。

• 時間帯別の入力・出力トークン
• 同時実行数と待ち時間
• エラー・再試行・タイムアウト
• 今後の顧客数と1社あたり利用量

見落としやすい契約リスク

対象モデル、1 GSUあたりの処理量、購入可能なロケーションはモデルごとに異なり、変更される可能性があります。価格だけでなく、モデル更新時の移行、需要下振れ時の未使用容量、予約枠を超えた通信をどう扱うかも確認します。

比較表に入れる項目

オンデマンド、予約容量、複数プロバイダーへの分散を同じ表で比較します。月額、ピーク耐性、レイテンシ、切替コスト、データ要件の5列があれば、経営と開発で判断を共有しやすくなります。

GSUはモデルによって価値が異なる

Generative AI Scale Unit（GSU）は、すべてのモデルで同じトークン数を処理する共通券ではありません。Google Cloudの対応モデル表では、1 GSUあたりの毎秒処理量と、入力・出力・キャッシュ・画像・音声などのburndown rateがモデルごとに定義されています。

たとえば同じ1万トークンでも、入力と出力ではGSU枠の消費量が異なる場合があります。長い推論出力、画像、音声、200Kを超える長文入力などを使う場合は、月間トークン総量をそのままGSUへ割り戻さず、対象モデルのburndown rateで換算します。

週額・月額の固定費とoverageを分けて考える

公式概要では、Provisioned Throughputは固定期間・固定費の契約で、週額または月額の予測可能な費用とoverageの制御を目的に挙げています。予約枠を超えた通信を従量処理へ回すのか、予約枠だけに制限するのかで、可用性と予算超過リスクが変わります。

顧客向けのリアルタイム機能ではoverageを完全に止めると処理失敗が増える可能性があります。一方、バッチ処理まで無制限に従量へ流すと費用上限が効きません。リアルタイム、非同期、社内処理で超過方針を分けます。

必要GSUの試算手順

購入前には、モデルとロケーションを固定したうえで、ピーク時の処理量をGSUへ換算します。平均値ではなく、実際に守りたい時間帯のp95負荷を基準にし、成長余地と再試行分を別枠で加えます。

• 対象モデル、バージョン、リージョンを決める
• 入力・出力・キャッシュ・画像・音声を分けて集計する
• 公式のper-second throughputとburndown rateでGSUへ換算する
• ピーク時のp95負荷、再試行、成長率を加える
• 候補GSU数ごとに固定費、未使用率、overageを比較する

モデル更新時の再計算が必要

対応モデルと処理量は固定ではありません。Google Cloudの対応モデル表はモデルバージョンごとに毎秒処理量とburndown rateを掲載しており、プレビューと一般提供のモデルも混在します。新モデルへ移行すると、同じリクエスト数でも必要GSUが変わる可能性があります。

モデルを更新する前に、品質テストだけでなく、同じ本番ログを使って必要GSUと費用を再計算します。fine-tuningしたモデルではbase modelと異なるburndown rateが適用される場合もあるため、購入済み枠をそのまま使えると決めつけないことが重要です。

導入後の月次レビュー

契約後も、予約したから完了ではありません。予約枠の使用率、overage、429、p95レイテンシを週次または月次で確認し、需要変化に合わせてGSU数を見直します。