このセクションでは、トークン数のカウントや割り当ての適用において、プロビジョンド スループットが Gemini Live API とどのように連携して動作するかを説明します。
Gemini Live API は、セッションを通じて低レイテンシのマルチモーダルなインタラクションをサポートします。セッション メモリを使用して、セッション内のインタラクションから情報を保持し、呼び出します。これにより、モデルは以前に提供または議論された情報を思い出すことができます。プロビジョンド スループットは、Gemini Live API モデルの Gemini 2.5 Flash をサポートしています。セッションの制限や 機能など、Gemini Live API の詳細については、 Gemini Live API リファレンスをご覧ください。
Gemini Live API では、セッションをプロビジョンド スループットまたは従量課金制トラフィックのいずれかに完全に専用にする必要があります。同じセッション内でプロビジョンド スループットと従量課金制の間でトラフィックがオーバーフローすることはサポートされていません。セッションの開始時に設定されたトラフィック タイプは、セッションの全期間にわたって継続されます。アクティブなセッション中にプロビジョンド スループットの割り当てに達しても、スロットリングやエラーは発生しません。代わりに、セッションを続行するためにトラフィックが一時的にバーストし、その後の使用量はすべて全体的な割り当てに対して登録されます。この一時的なバーストにより、モニタリング ダッシュボードに、割り当て上限を超えるプロビジョンド スループットの使用量（専用トラフィック）が表示されることがあります。セッション中に割り当てられた上限を超えないようにするには、予想される使用量をサポートするのに十分な GSU を購入することが重要です。
オーバーフローは、あるセッションから次のセッションにサポートされます。セッション終了後にプロビジョンド スループットの上限を超えた場合は、従量課金制を使用して追加のセッションを開始できます。セッションがプロビジョンド スループットまたは従量課金制のどちらで完全に処理されるかは、セッションの開始時に決定されます。システムはユーザーから送信されたヘッダーを確認し、セッションに十分なプロビジョンド スループットの割り当てがあるかどうかを確認します。セッション全体を処理するのに十分なプロビジョンド スループットの割り当てがない場合は、代わりに従量課金制の割り当てが使用されます。
Gemini Live API のスループットを計算する
Gemini Live API を使用している間、セッション メモリに保存されたトークンは、その後のモデルへのリクエストでも利用できます。その結果、プロビジョンド スループットは、今回のリクエストで送信されたトークンに加えて、セッションメモリに保存されているトークンも計算に含めます。そのため、1 回のリクエストで処理されるトークンの数が、ユーザーがそのリクエストで送信したトークンの数よりも多くなることがあります。
Gemini Live API には、セッション メモリに保存できるトークンの合計数に上限があります。また、トークンの合計数を含むメタデータ フィールドもあります。リクエストを処理するために必要なスループットを計算する際は、セッション メモリ内のトークンを考慮する必要があります。従量課金制（PayGo）で Gemini Live API を使用したことがある場合は、これらのトラフィック パターンとセッション トークンを使用して、プロビジョンド スループットのニーズを見積もることができます。
Gemini Live API のプロビジョンド スループット要件を見積もる方法の例
セッション中、すべてのトラフィックはプロビジョンド スループットまたは従量課金制として処理されます。
セッションがライブである限り、セッション メモリなどのセッション状態を使用できます。
この例は、セッション メモリからトークンを含めることで、2 つの連続するリクエストが処理される方法を示しています。
リクエスト 1 の詳細
期間: 10 秒
送信されたトークン（音声）: 10 秒 × 25 トークン/秒 = 250 トークン
送信されたトークン数（動画）: 10 秒 × 258 トークン/フレーム/秒 = 2,580 トークン
リクエスト 1 で処理されたトークンの合計数:
- 送信されたトークン数: 送信された音声トークンと動画トークンの合計 = 2,580 + 250 = 2,830 トークン
- 受信したトークン: 100（音声）
リクエスト 2 の詳細
期間: 40 秒
送信されたトークン（音声）: 40 秒 × 25 トークン/秒 = 1,000 トークン
リクエスト 2 で処理されたトークンの合計数:
- 送信されたトークン数: リクエスト 2 で送信されたトークン数 + リクエスト 1 のセッション メモリ トークン数 = 2,830 トークン + 1,000 トークン = 3,830 トークン
- 受信したトークン: 200（音声）
リクエストで処理されたトークンの数を計算する
これらのリクエストで処理されるトークンの数は、次のように計算されます。
セッション メモリに追加のトークンがないため、リクエスト 1 は進行中のリクエストの入力トークンと出力トークンのみを処理します。
リクエスト 2 は、進行中のリクエストの入力トークンと出力トークンを処理しますが、セッション メモリの入力トークンも含まれます。これは、セッション メモリの前のリクエスト（リクエスト 1）の入力トークンで構成されます。セッション メモリ内のトークンのバーンダウン率は、標準の入力トークンと同じです（入力セッション メモリトークン 1 個 = 入力トークン 1 個）。
リクエスト 2 の送信後、処理に 1 秒かかった場合、トークンは次のように処理され、プロビジョンド スループットの割り当てに適用されます。
入力にバーンダウン率を掛けて、入力トークンの合計数を取得します。
2,830 x（セッション メモリ トークンあたり 1 トークン）+ 1,000 x（入力テキスト トークンあたり 1 トークン）= クエリあたりのバーンダウン調整済み入力トークン数 3,830
出力にバーンダウン率を掛けて、出力トークンの合計を取得します。
200 x（オーディオ出力トークンあたり 24 トークン）= 4,800 トークン
次の 2 つの合計を追加して、処理されたトークンの合計数を取得します。
3,830 トークン + 4,800 トークン = 8,630 トークン