このセクションでは、トークン数のカウントや割り当ての適用において、プロビジョンド スループットが Gemini Live API とどのように連携して動作するかを説明します。
Gemini Live API は、セッション メモリを使用してターン間でコンテキストを保持し、低レイテンシのマルチモーダル インタラクションを実現します。その他の機能とセッションの上限については、Gemini Live API リファレンスをご覧ください。
各セッションは、プロビジョンド スループットまたは PayGo のいずれかに完全に専用にする必要があります。セッション中のスピルオーバーはサポートされていません。アクティブなセッション中にプロビジョンド スループットの割り当てを超えると、システムはエラーを回避するために一時的なバーストを許可し、超過分を全体的な割り当てに登録します。予期しない使用量の急増を回避するには、ピーク時の需要をサポートするのに十分な GSU を購入します。
スピルオーバーはセッション間でサポートされます。セッションを開始すると、システムはリクエスト ヘッダーを評価し、プロビジョンド スループットの割り当ての可用性を確認します。割り当てが不足している場合、新しいセッションはデフォルトで PayGo になります。
セッション メモリは、前のターンの出力を後続のリクエストの入力として引き継ぐため、プロビジョンド スループットは、新しい受信トークンと累積されたセッション トークンの両方に基づいて割り当てを計算します。その結果、セッションが進むにつれて、1 回のリクエストで処理されるトークンの合計数が増加し、事前に定義されたセッションの上限に達するまで増加し続けます。セッションがライブである限り、セッション メモリなどのセッション状態を使用できます。
必要なプロビジョンド スループットを見積もる際は、セッション メモリ トークンを考慮してください。出力動画アバター トークンはセッション メモリに含まれません。過去の PayGo トラフィック パターンは、GSU のニーズを計算する際の有用なベースラインとなります。
割り当ての適用期間は、モデル用に購入した GSU の数によって異なり、変更される可能性があります。
Gemini 3.8 Live API
割り当ての適用期間
Gemini 3.8 Live API モデルの GSU サイズごとの割り当て適用期間は次のとおりです。
- 1 ～ 9 GSU: 45 秒
- 10 個以上の GSU: 5 秒
記載されている値は、リクエストのレイテンシとは関係ありません。リクエストの処理時間は、割り当ての適用期間と同じではありません。プロビジョンド スループットでこのモデルの動画アバター関連のリクエストを処理できるようにするには、10 個以上の GSU を購入する必要があります。購入した GSU が 10 未満の場合、動画アバターベースのセッション全体が PayGo に移行します。
GSU の量が少ないほど、適用期間が長くなります。これにより、小さなリクエストが期間内に正常に処理されるようになります。モデルの GSU 数が増加しても、リクエストの処理に長いウィンドウ時間は必要ありません。プロビジョンド スループットを使用して出力をより頻繁に処理する必要がある場合は、購入する GSU の量を増やし、対応する適用期間を確認することをおすすめします。違反措置の期間はバックエンドのアルゴリズムによって異なり、変更される可能性があります。
GSU 要件の見積もり
潜在的なワークロードの例を見て、見積もりツールがこのモデルの推奨事項をどのように提供するかを理解しましょう。また、リクエストの処理方法とバーンダウン率の適用方法についても説明します。ユーザーが chatbot に Gemini Live API を使用することを計画しています。10 個の同時セッションが想定され、期間は 5 分（300 秒）です。セッションあたりの会話ターン数は 30 回と想定されており、ユーザーは最大セッション コンテキスト ウィンドウを 6,000 トリガー トークンに指定しています。リクエストの形式は次のとおりです。
| フィールド | 値の例 |
|---|---|
| 想定同時セッション数 | 10 |
| 想定される所要時間（秒） | 300 |
| セッションあたりの平均ターン数 | 30 |
| コンテキストの長さ（トリガー トークン） | 6,000 |
| ターンあたりの平均入力テキスト トークン数 | 20 |
| ターンあたりの平均入力音声トークン数 | 200 |
| ターンあたりの平均入力画像 / 動画トークン数 | 50 |
| ターンあたりの平均出力テキスト トークン数 | 100 |
| ターンあたりの平均出力音声トークン数 | 200 |
| 出力動画アバターが有効になっているか | はい |
ターンあたりの入力トークン数:
入力モダリティとそのそれぞれのバーンダウン率の積和を計算します。
ターンあたりの平均入力テキスト トークン数 * 入力テキストのバーンダウン率 = 20 * 1 = 20
ターンあたりの平均入力音声トークン数 * 入力音声のバーンダウン率 = 200 * 4 = 800
ターンあたりの平均入力画像 / 動画トークン数 * 入力画像のバーンダウン率 = 50 * 1.4 = 70
ターンあたりのバーンダウン調整済み入力トークンの合計 = 20 + 800 + 70 = 890
ターンあたりの出力トークン数:
出力モダリティとそれぞれのバーンダウン率の SUMPRODUCT を計算します。出力動画アバター トークンは、25 音声トークンあたり 6,192 トークン（固定）です。
ターンあたりの平均出力テキスト トークン数 × 出力テキストのバーンダウン率 = 100 × 6 = 600
ターンあたりの平均音声トークン数 × 出力音声バーンダウン率 = 200 × 16 = 3,200
出力動画アバターが有効になっているか。はい。音声トークン出力に（6,192/25）を掛け、出力動画アバター トークンのバーンダウン率を適用します。200 *（6,192/25）* 1.4 = 69,350
ターンあたりのバーンダウン調整済み出力トークンの合計 = 600 + 3,200 + 69,350 = 73,150
ターンあたりのコンテキスト ウィンドウ トークン数:
コンテキスト ウィンドウは、最大コンテキスト ウィンドウの長さに達して増加が停止するまで、各ターンで未加工の入力トークンと出力トークン（出力動画アバター トークンを除く）を蓄積します。トークンは、未加工のトークン（バーンダウン率を適用しない）としてコンテキスト ウィンドウの上限にカウントされます。ただし、コンテキスト ウィンドウがセッション メモリとして次のターンの入力リクエストに渡される場合、コンテキスト ウィンドウ内のトークンには、モダリティに基づいて対応する入力バーンダウン率を適用する必要があります。
バーンダウン率を考慮せずに、各セッションの未加工のトークンの合計を追加します。
- ターンあたりの平均入力テキスト トークン数 + ターンあたりの平均入力音声トークン数 + ターンあたりの平均入力画像 / 動画トークン数 + ターンあたりの平均出力テキスト トークン数 + ターンあたりの平均出力音声トークン数 = 20 + 200 + 50 + 100 + 200 = 570
次に、各未加工のトークン数の合計に対する比率を計算します。コンテキスト ウィンドウの計算では、動画アバターの出力トークンを無視できます。
- 入力テキストの比率 = 20/570 = 0.035
- 入力音声の比率 = 200 / 570 = 0.351
- 入力画像 / 動画の比率 = 50 / 570 = 0.088
- 出力テキストの比率 = 100/570 = 0.175
- 出力音声の比率 = 200 / 570 = 0.351
次に、比率、最大コンテキストの長さ、バーンダウン率の積和を、すべて入力モダリティであるかのように計算します。
入力テキストの比率 * 最大コンテキストの長さ * 入力テキストのバーンダウン = 0.035 * 6,000 * 1 = 210
入力音声の比率 * 最大コンテキストの長さ * 入力音声のバーンダウン = 0.351 * 6,000 * 4 = 8,424
入力画像 / 動画の比率 * 最大コンテキストの長さ * 入力画像 / 動画のバーンダウン = 0.088 * 6,000 * 1.4 = 739
出力テキストの比率 * 最大コンテキストの長さ * 入力テキストのバーンダウン = 0.175 * 6,000 * 1 = 1,050
出力音声の比率 * 最大コンテキストの長さ * 入力音声のバーンダウン = 0.351 * 6,000 * 4 = 8,424
未加工のトークンのコンテキスト ウィンドウの上限が 6,000 の場合、ターンごとに処理されるバーンダウン調整後のコンテキスト ウィンドウ トークンの合計は、210 + 8,424 + 739 + 1,050 + 8,424 = 18,847 です。
GSU の計算:
（ターンあたりの入力トークン数 + ターンあたりの出力トークン数 + ターンあたりのコンテキスト ウィンドウ トークン数）* セッションあたりの平均ターン数 * 予想される同時セッション数 *（1 / 予想される期間）*（1 GSU / 1,350 TPS）=（890 + 73,150 + 18,847）* 30 * 10 *（1/300）*（1/1,350）= 68.8。切り上げると 69 GSU になります。
リクエストの処理
このモデルのプロビジョンド スループットに関して、リクエストがどのように処理されるかの例を見てみましょう。3 つのリクエストがあるとします。
リクエスト 1 の詳細 - 入力音声と動画、出力音声
- 期間: 10 秒
- 送信されたトークン（音声）: 10 秒 × 25 トークン/秒 = 250 トークン
- 送信されたトークン数（動画）: 10 秒 × 258 トークン/フレーム/秒 = 2,580 トークン
- リクエストの性質に基づいて受信した出力音声トークン: 100 トークン
- 更新されたセッション メモリ = 250 + 2,580 + 100 = 2,930 トークン
リクエスト 2 の詳細 - セッション メモリを使用した入力音声、出力音声
- 期間: 40 秒
- 送信されたトークン（音声）: 40 秒 × 25 トークン/秒 = 1,000 トークン
- リクエスト 1 後のセッション メモリ = 2,930 トークン
- 送信された入力トークンの合計数: このリクエストで送信されたトークン数 + リクエスト 1 のセッション メモリ = 1,000 + 2,930 = 3,930 トークン
- リクエストの性質に基づいて受信した出力音声トークン: 200 トークン
- 更新されたセッション メモリ = 3,930 + 200 = 4,130 トークン
thought リクエスト #3 の詳細 - セッション メモリを使用した音声と動画の入力、アバター動画と音声の出力
- 期間: 10 秒
- 送信されたトークン（音声）: 10 秒 × 25 トークン/秒 = 250 トークン
- 送信されたトークン数（動画）: 10 秒 × 258 トークン/フレーム/秒 = 2,580 トークン
- リクエスト 2 後のセッション メモリ = 4,130 トークン
- 送信された入力トークンの合計数: このリクエストで送信されたトークン数 + リクエスト 2 のセッション メモリ = 250 + 2,580 + 4,130 = 6,960 トークン
- リクエストの性質に基づいて受信された出力動画アバター トークン: 61,920 トークン
- リクエストの性質に基づいて受信した出力音声トークン: 250 トークン
- 更新されたセッション メモリ = 6,960 + 250 = 7,210 トークン
処理されたトークンについて
セッション メモリに追加のトークンがないため、リクエスト 1 は進行中のリクエストの入力トークンと出力トークンのみを処理します。処理されたすべてのトークンがセッション メモリを構成するようになりました。
リクエスト 2 は、進行中のリクエストの入力トークンと出力トークンを処理しますが、リクエスト 1 のセッション メモリも含まれます。すべてのセッション メモリ トークンに、対応する入力トークンのバーンダウン率が適用されます。
リクエスト 3 は、進行中のリクエストの入力トークンと出力トークンを処理しますが、リクエスト 2 のセッション メモリも含まれます。すべてのセッション メモリ トークンに、対応する入力トークンのバーンダウン率が適用されます。
リクエスト 3 の送信後、処理に 1 秒かかった場合、このモデルのプロビジョンド スループットの割り当てに適用されるバーンダウン調整済みトークンは次のようになります。
入力音声トークン数 × 入力音声バーンダウン率 = 250 × 4 = 1,000
入力動画トークン数 × 入力動画のバーンダウン率 = 2,580 × 1.4 = 3,612
セッション メモリ音声 * 入力音声のバーンダウン率 =（250 + 100 + 1,000 + 200）* 4 = 6,200
セッション メモリ動画 * 入力動画のバーンダウン率 = 2,580 * 1.4 = 3,612
出力動画アバター トークン × 出力動画アバター バーンダウン率 = 61,920 × 1.4 = 86,688
出力音声トークン数 × 出力音声バーンダウン率 = 250 × 16 = 4,000
合計すると、105,112 個のバーンダウン調整済みトークンになります。
Gemini 2.5 Flash Live API ネイティブ音声
リクエストの処理
リクエスト 1 の詳細 - 入力音声と動画、出力音声
- 期間: 10 秒
- 送信されたトークン（音声）: 10 秒 × 25 トークン/秒 = 250 トークン
- 送信されたトークン数（動画）: 10 秒 × 258 トークン/フレーム/秒 = 2,580 トークン
- リクエストの性質に基づいて受信した出力音声トークン: 100 トークン
- 更新されたセッション メモリ = 250 + 2,580 + 100 = 2,930 トークン
リクエスト 2 の詳細 - セッション メモリを使用した入力音声、出力音声
期間: 40 秒
送信されたトークン（音声）: 40 秒 × 25 トークン/秒 = 1,000 トークン
リクエスト 1 後のセッション メモリ = 2,930 トークン
送信された入力トークンの合計数: このリクエストで送信されたトークン数 + リクエスト 1 のセッション メモリ = 1,000 + 2,930 = 3,930 トークン
リクエストの性質に基づいて受信した出力音声トークン: 200 トークン
更新されたセッション メモリ = 3,930 + 200 = 4,130 トークン
処理されたトークンについて
セッション メモリに追加のトークンがないため、リクエスト 1 は進行中のリクエストの入力トークンと出力トークンのみを処理します。処理されたすべてのトークンがセッション メモリを構成するようになりました。
リクエスト 2 は、進行中のリクエストの入力トークンと出力トークンを処理しますが、リクエスト 1 のセッション メモリも含まれます。すべてのセッション メモリ トークンに、対応する入力トークンのバーンダウン率が適用されます。
リクエスト 2 の送信後、処理に 1 秒かかった場合、このモデルのプロビジョンド スループットの割り当てに適用されるバーンダウン調整済みトークンは次のようになります。
- 入力音声トークン * 入力音声バーンダウン率 = 1,000 * 6 = 6,000
- セッション メモリ音声 * 入力音声のバーンダウン率 =（250 + 100）* 6 = 2,100
- セッション メモリ動画 * 入力動画のバーンダウン率 = 2,580 * 6 = 15,480
- 出力音声トークン数 * 出力音声バーンダウン率 = 200 * 24 = 4,800
合計すると、バーンダウン調整後のトークン数は 28,380 個になります。