【GCP】Vertex AI Flex PayGoを把握し、Gemini3系GAに備える

株式会社ブレインパッド プロダクトユニットの津久井です。

弊社は「データ活用の促進を通じて持続可能な未来をつくる」をミッションに、データ分析支援やSaaSプロダクトの提供を通じて、企業の「データ活用の日常化」を推進しております。

現在私は、AI SaaSのエージェントリンリーの開発リードを担当しています。

はじめに

Vertex AI Geminiに Flex PayGo という、「従来のリクエスト方法にhttp headerを足す」だけで使える、Batch predictionより互換性のあるコスト削減方法が追加されたので、実際のリクエスト事例も含めて解説します。

(※リクエストの優先度を上げるPriority PayGoもありますが、今回は深く触れません)

Vertex AI Flex PayGo とは?

Vertex AI Flex PayGo は、Gemini 3 系プレビューを global エンドポイントで呼び出すときに使える、低コスト寄りの従量課金オプションです。Standard PayGo（通常のリクエスト）より 50% 割引で使える代わりに、レイテンシ増加(レスポンスが遅くなる)やスロットリング増加を許容する前提があります。

REST で使う場合は、通常の JSON ボディを大きく変えるのではなく、Flex 用の HTTP ヘッダを追加して呼び出します。レスポンス側では usageMetadata.trafficType が通常の ON_DEMAND から ON_DEMAND_FLEX に変わるため、最低限の疎通確認でも「今どちらの課金経路で処理されたか」を見分けられます。

(※Gemini3未満には非対応)

今回の検証内容

• Flex ルーティング指定付きで最小リクエストを送る
• 応答を JSON で確認する
• 応答を JSON で確認し、通常リクエストと比べ、どの HTTP ヘッダが増えたかを把握する
• 応答を JSON で確認し、通常リクエストとレスポンス時間を比較する

手順

1. 事前に環境変数を準備する

set -euo pipefail

PROJECT_ID="your-project-id"
MODEL="gemini-3-flash-preview"
ACCESS_TOKEN="$(gcloud auth print-access-token)"
ENDPOINT="https://aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/publishers/google/models/${MODEL}:generateContent"

2. 最小リクエストの JSON を作る

cat > request.json <<'JSON'
{
  "contents": [
    {
      "role": "user",
      "parts": [
        {
          "text": "疎通確認です。1文で返答してください。"
        }
      ]
    }
  ],
  "generationConfig": {
    "temperature": 0.2,
    "maxOutputTokens": 128
  }
}
JSON

3. 通常リクエストを送る

curl -sS -X POST \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "Content-Type: application/json; charset=utf-8" \
  "${ENDPOINT}" \
  -d @request.json \
  | tee response-standard.json

4. Flex リクエストを送る

curl -sS -X POST \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "Content-Type: application/json; charset=utf-8" \
  -H "X-Vertex-AI-LLM-Request-Type: shared" \
  -H "X-Vertex-AI-LLM-Shared-Request-Type: flex" \
  "${ENDPOINT}" \
  -d @request.json \
  | tee response-flex.json

5. レスポンスを確認する

import json
from pathlib import Path

payload = json.loads(Path("response-standard.json").read_text(encoding="utf-8"))
candidates = payload.get("candidates", [])

text = candidates[0].get("content", {}).get("parts", [{}])[0].get("text", "")
print(text[:200])

通常リクエストと比べ、どの HTTP ヘッダが増えたか

リクエストヘッダ差分

通常リクエストに対して、Flex は次の 2 ヘッダを追加しました。

 Authorization: Bearer <redacted>
 Content-Type: application/json; charset=utf-8
+X-Vertex-AI-LLM-Request-Type: shared
+X-Vertex-AI-LLM-Shared-Request-Type: flex

この確認では、JSON ボディは同一で、差分は HTTP ヘッダ側にありました。

実行結果

• 通常リクエストのレスポンス
  • HTTP ステータス: 200
  • usageMetadata.trafficType: ON_DEMAND
• Flex ヘッダ付きリクエストのレスポンス
  • HTTP ステータス: 200
  • 応答本文の抜粋: READY
  • usageMetadata.trafficType: ON_DEMAND_FLEX

今回の実測では、gemini-3-flash-preview に対して同じ JSON ボディでも Flex ヘッダを追加すると、usageMetadata.trafficType が ON_DEMAND から ON_DEMAND_FLEX に切り替わりました。

通常リクエストとレスポンス時間を比較する

同一の動画入力(約16MB)と、同じ要約プロンプトを使って Standard PayGo（通常のリクエスト） / Flex PayGo を各 3 回ずつ交互に実行し、run 1(初回の暗黙キャッシュ作成時)を除いて、応答時間と routing を比較しました。

route	run 2	run 3
Standard PayGo（通常のリクエスト）	21136.2 ms	21242.6 ms
Flex PayGo	32129.4 ms	32978.9 ms

結果として、採用した 試行では Standard PayGo（通常のリクエスト）の方が短く約 21.2 秒、Flex PayGo は約 32.1 秒でした。

レスポンスだけでコスト削減は確認できるか?

レスポンス JSON だけでは、「この 1 リクエストで何円安くなったか」「何% コスト削減できたか」までは確定できません。

今回のレスポンスで確認できたのは、主に次の項目です。

• usageMetadata.trafficType
  • 通常リクエスト: ON_DEMAND
  • Flex リクエスト: ON_DEMAND_FLEX
• usageMetadata.promptTokenCount
• usageMetadata.candidatesTokenCount
• usageMetadata.totalTokenCount

レスポンスから確認できるのは、「Flex 経路で処理されたか」と「課金計算の元になるトークン使用量」です。実際の請求額や削減率はレスポンスには含まれません。

そのため、コスト評価をしたい場合は次のどちらかが必要です。

• 公式の料金表に、レスポンスのトークン数を当てて試算する
• Cloud Billing 側で実際の請求データを確認する

Flex の疎通確認では、ヘッダ差分と trafficType までをレスポンスで見ます。コストの確定値は料金表か Cloud Billing 側で別途確認します。

Billingでの確認方法

以下のように、Standard PayGo（通常のリクエスト）と Flex PayGo は SKUで区別されます。

各Predictionの比較

Vertex AI のPredictionにはFlex PayGoも含め下記の4パターンあり、それぞれ下記のような特徴があります。

比較表

方式	コスト傾向	レイテンシ/安定性	スパイク耐性	向いている用途	主な注意点
Flex PayGo	Standard PayGo（通常のリクエスト）比で低コスト（50% 割引）	低遅延保証を前提にしない	追加 3,000 QPM の余地あり	非同期寄り、多少の遅延揺らぎを許容できる生成処理	Preview、global endpoint 前提、20 MB 上限、30 分タイムアウト
Standard PayGo（通常のリクエスト）	基準となる従量課金	一般的なオンライン推論に使いやすい	DSQ 前提で運用	通常の API 呼び出し	コストは Flex より高くなる可能性
Provisioned Throughput(リソース予約)	予約ベースで高めになりやすい	厳しめの安定性要件に対応しやすい	事前確保した処理量で吸収	リアルタイム厳守、SLO を強く求める用途	事前設計と容量計画が必要
Batch Prediction(バッチ実行)	まとめ処理向けで効率的	即時応答には向かない(24時間目安)	バッチ処理で吸収	オフライン一括処理、定期処理	低遅延 API 代替にはならない

Flex PayGo が 向く用途・向かない用途

Flex PayGo が向く用途

• バックグラウンド処理やバッチ前段など、数秒から分単位の揺らぎを許容できる処理
• コスト最適化を優先しつつ、Preview 制約を受け入れられる検証/本番
• 追加 3,000 QPM を活かしてピークを吸収したいケース
• 遅延の許容は前提で、従来と同じ同期処理でコスト削減を行いたい場合

Flex PayGo が向かない用途

• 厳格なリアルタイム応答や低遅延を保証したい API
• リージョン制約や接続経路上、global endpoint 前提が運用要件に合わないケース
• 入出力サイズが大きく 20 MB 制約に抵触しやすいケース

最後に

Gemini3系のPreviewが取れないまま2.5がEOLになろうとしており(2026年6月17日)ヤキモキしていますが、
きっと近々リリースされるはずなので、それまでにGemini3系で出来ることを把握しておくのが良さそうです。