こんにちは、生成AI研究開発チームのデータサイエンティストとしてAI開発を担当している保坂です。
皆さんGemini使ってますか？私はとても好きで、プライベートでも日常業務でもとても良く利用しています。一度、技術的な記事の執筆の際に、うまいストーリーを組み立てるのに苦労していたところ、Geminiさんに壁打ちしてもらっていたら、ストーリーの組み立てに感銘を受け、大ファンになってしまいました。それ以来、文章を書く際にはいつもGeminiさんに壁打ち相手をしてもらうようになりました。 最近では、Gemini利用のシェアがかなり上がっているというニュースも話題になっていましたね。 また、音声や動画のようなマルチモーダルの入力を受け付けられるうえ、安価に利用する事ができるので、ユースケースによってはプロダクト活用の有力な候補にもなるなと感じています。
しかし、半年ほど前にGA（General Availability）となったGemini 2.5系からは、Vertex AIからのAPI利用で固定のクォータによるオンデマンド利用ができなくなり、「動的共有クォータ」または「プロビジョンドスループット（Provisioned Throughput）」のいずれかしか利用できなくなりました。動的共有クォータはさばけるリクエスト量の不定性があり、安定したサービス提供のためにはプロビジョンドスループットの利用が有力な候補となります。
この記事では、執筆時点(2026/1)での公式情報に基づいて、Geminiの少し特殊なプロビジョンドスループットの仕組みについて詳しくご紹介します。 あくまで私が必要と考えて調査した範囲の内容のご紹介となりますので、より詳細な内容は公式ドキュメントを確認してください。
なお、ここでご紹介する内容はVertex AIを通じたGeminiの利用に関する調査結果となります。Gemini APIを経由した利用ではないのでご注意ください。
今後、この仕組みを前提とした具体的なキャパシティプランニングの方法についてもご紹介したいと思っています。
動的共有クォータとプロビジョンドスループットについて
Geminiのスループット管理方法には、以前の「静的クォータ」と、現在主流の「動的共有クォータ」「プロビジョンドスループット」という3つの方式が存在します。それぞれの特徴と違いを理解することが、適切なキャパシティプランニングの第一歩となります。
静的クォータ
Gemini 1.5のオンデマンド利用で採用されていた方式で、プロジェクトごとに「1分あたりのリクエスト数」といった固定的でわかりやすいクォータが設定されていました。利用状況の上限が明確で予測しやすいため、計画が立てやすいというメリットがありました。しかし、Gemini 2.5系以降ではこの方式は利用できなくなっています。
参考: Vertex AI の生成 AI の割り当てとシステム上限
動的共有クォータ(DSQ、現在は Standard PayGo)
複数のユーザーでリソースを共有するベストエフォート型のサービスです。利用者に対して明示されたクォータがなく、上限が予測しにくく、計画が立てにくいです。自分たちが提供するサービスもベストエフォート型のサービスであれば利用しやすいですが、スループットを保証したいサービスの場合には利用が難しいです。 ※記事の執筆をしている間に、「動的共有クォータ」から「Standard PayGo」へと名称が変わっていました。仕様も変更されており、Tierの導入などにより、Standard PayGoのほうが上限の予測がしやすくなっています。
参考: Standard PayGo
プロビジョンドスループット(PT)
自社サービス専用の処理能力をあらかじめ確保しておく仕組みです。AWSのProvisioned ConcurrencyやAzureのProvisioned Throughputなど、多くのクラウドサービスで同様の仕組みが提供されています。これにより、安定したパフォーマンスを保証できますが、利用量ではなく確保量に応じてコストがかかるので、あらかじめキャパシティプランニングを行っておいて、必要最小限だけ確保するようにしないと、無駄なコストが発生してしまいます。
Geminiの少し特殊な「プロビジョンドスループット」の仕組み
多くのLLMサービスでは、スループットの制限を「分あたりのリクエスト数（RPM）」や「分あたりのトークン数（TPM）」で設定することが一般的です。一方、Geminiのプロビジョンドスループットはやや複雑です。
TPSによるスループットの計測
Geminiのプロビジョンドスループットは、TPS（Tokens Per Second）の単位でスループットを計測・管理します。
生成AIサービスでは、リクエストごとのトークン数にはかなり幅があると考えられるため、リクエスト数ではなくトークン単位でスループットが管理される仕様となっているのは必然と言えるでしょう。さらに、分単位（RPM/TPM）ではなく秒単位での管理となっており、精緻にスループット管理されていることがうかがえます。これに伴い、利用者としてもより細かな粒度でサービス利用のピークを見極め、キャパシティプランニングを行う必要が出てきます。
ただし、後述するように、正確には秒単位でスループットを超えると即座にエラーとなるわけではなく、30秒間の平均で判断されるため、実際の挙動としてはシビアさは少し緩和されています。
スループット購入の共通単位GSU (Generative AI Scale Unit)
モデルの種類に関わらず、GSU(Generative AI Scale Unit)という共通の単位で処理能力を購入します。 同じGSUでも、適用するモデルによってそれが保証するスループットが違ってきます。性能の良いモデルほど、小さなTPSの保証にしかならない形になっています。
| モデルファミリー | GSUあたりのスループット (TPS) |
|---|---|
| Gemini 2.5 Pro | 650 |
| Gemini 2.5 Flash | 2,690 |
| Gemini 2.5 Flash-Lite | 8,070 |
| Gemini 2.0 Flash | 3,360 |
参考: Vertex AI ドキュメント: サポートされるモデル
例えば同じ価格で購入できる1GSUが、Gemini 2.5 Flash-Liteでは8,070 TPSのスループットを保証するのに対して、Gemini 2.5 Flashではその1/3の2,690 TPSの保証にしかなりません。 これらのスループットの比率は、動的共有クォータ（DSQ）におけるモデル間のコスト比率と概ね一致しており、課金方式間での整合性を取るための設定となっているようです。
モダリティごとに異なるスループットの消費率(バーンダウンレート)
同じトークン数でも、入力/出力、モダリティ（テキスト、音声、動画、画像）によってスループットの消費率が異なり、それぞれに「バーンダウンレート」という重み付けがされています(表はGemini 2.5 Flash-Liteの例)。
| モダリティ | タイプ | トークン換算レートの目安 | バーンダウンレート (消費倍率) |
|---|---|---|---|
| テキスト | 入力 | - | 1倍 |
| テキスト | 出力 | - | 4倍 |
| 音声 | 入力 | 1秒あたり約32トークン | 3倍 |
| 画像 | 入力 | 1枚あたり約258トークン | 1倍 |
| 動画 | 入力 | 1秒あたり約16トークン | 1倍 |
参考: Vertex AI ドキュメント: サポートされるモデル
この倍率は、動的共有クォータ（DSQ）における入力/出力やモダリティ(テキスト/音声等)ごとのコスト比率を反映しており、これも課金方式間での整合性を取るためのものと考えられます。
細かなスライディングウインドウによるスループット管理
前述の通り、GeminiはTPSでスループットが計測されますが、1秒間のリクエスト量が購入したTPSを超えたら即座にエラーとなるわけではありません。実際にはもう少し緩やかな管理が行われています。公式のドキュメントを読み解いていくと、Geminiのプロビジョンドスループットは ウインドウ幅30秒、スライド幅1秒のスライディングウインドウ でスループット管理が行われていると言えそうです。
つまり、あるリクエストがプロビジョンドスループットを通じて処理可能かどうかは、そのリクエストと、そこから30秒間遡った範囲に入っているリクエストの消費トークン数の秒単位平均値が、あらかじめ購入したスループット(TPS)を超えないかどうかで判断される、ということです。
例えば、1,000TPSを購入していて、直前の29秒に毎秒900トークンを消費していたとすると、次の1秒に来るリクエストはその消費トークン数をTとして、
(900 × 29 + T) / 30 ≦ 1000
を満たすならプロビジョンドスループットを通じて処理可能であり、それを満たさない場合にはエラーもしくは動的共有クオータによる処理となります。
出力トークン数の推定に基づく割当可否判定
プロビジョンドスループットの割当判定の際には、推定した出力トークン数が用いられます。つまり、あるリクエストがプロビジョンドスループットにより処理可能かどうかの判断を行う際には、リクエスト内容から確定的に算出できる入力トークン数に加えて、リクエスト内容から推定された出力トークン数を用いて判定が行われるということです。リクエストの処理が完了すると、推定値と実際に消費したトークン数の差分が反映されるようです。
プロビジョンドスループットの購入方法
プロビジョンドスループットの購入方法などについて説明します。まず、プロビジョンドスループットは実際の使用状況に関係なく、確保したGSU分の料金が発生するものになります。 定常的なリクエストが見込まれたり、常にリクエストの失敗がないようにしたい、などの理由がない限り、プロビジョンドスループットの購入はよく注意して行うようにしましょう。 また、スループットは次の月に繰り越せません。購入した期間に対する保証を買うということになるので注意しましょう。
購入単位
GSUはモデル共通の単位ですが、特定のプロジェクト、リージョン、モデル、バージョンの組み合わせに対して購入します。 1つのGSUの購入を複数のリージョンなどにまたがって同時に使用することはできません。 例えば、別のリージョンで同じモデルに対するリクエストを行っても、プロビジョンドスループットは適用されません。
価格
1GSUあたりの料金は契約期間によって異なります。長い期間で一括契約するほど安価に利用できます。
| 期間 | GSUあたりの料金 |
|---|---|
| 1週間契約 | $1,200/週(≒$4,800/月1) |
| 1か月契約 | $2,700/月 |
| 3か月契約 | $2,400/月 |
| 1年契約 | $2,000/月 |
参考: プロビジョンドスループット
簡単に計算してみたところ、短期間だけGSUを補強したい場合、2週間までなら1週間契約のほうが割安で、それ以上になるなら1ヶ月契約のほうが割安となっていました。
契約の変更、終了
期間中のキャンセルはできないそうなので、買いすぎ、間違った購入に注意してください。 途中で数量を増やすことはできるそうです。 また、期間終了時に契約が自動更新されるように設定できます。長期にわたり利用したい場合に便利ですね。 自動更新されないようにする事もできるようです。 購入注文後即座に利用できるわけではなく、一定のリードタイムがあるので、注意が必要です。
おわりに
今回は、Geminiのプロビジョンドスループットの仕組みについてご紹介しました。Geminiをプロダクト活用しようと考えている方などの参考になれば幸いです。 今後、この仕組みを前提とした具体的なキャパシティプランニングの方法についてご紹介したいと思っています。 最後までお読みいただきありがとうございました！
- 1月=4週間として月あたりに換算↩
