Gemini Live API のプロビジョンド スループット

このセクションでは、トークン数のカウントや割り当ての適用において、プロビジョンド スループットが Gemini Live API とどのように連携して動作するかを説明します。

Gemini Live API を使用すると、セッション メモリを使用してターン間でコンテキストを保持し、低レイテンシのマルチモーダル インタラクションを実現できます。その他の機能とセッションの制限については、Gemini Live API リファレンスをご覧ください。

各セッションは、プロビジョンド スループットまたは PayGo のいずれかに完全に専用にする必要があります。セッション中のスピルオーバーは対象外です。アクティブなセッション中にプロビジョンド スループットの割り当てを超過した場合、エラーを回避するために一時的なバーストが許可され、超過分が全体的な割り当てに対して登録されます。予期しない使用量の急増を避けるため、ピーク時の需要に対応できる十分な GSU を購入してください。

セッション間のスピルオーバーがサポートされています。セッションを開始すると、システムはリクエスト ヘッダーを評価し、プロビジョンド スループットの割り当ての可用性を検証します。割り当てが不足している場合、新しいセッションはデフォルトで PayGo になります。

セッション メモリは前のターンの出力を後続のリクエストの入力として引き継ぐため、プロビジョンド スループットは新しい入力トークンと蓄積されたセッション トークンの両方に基づいて割り当てを計算します。その結果、リクエストごとに処理されるトークンの合計数は、セッションが進むにつれて増加し、事前に定義されたセッションの上限に達するまで増加します。セッションがライブである限り、セッション メモリなどのセッション状態を使用できます。

必要なプロビジョンド スループットを見積もる際は、セッション メモリ トークンを必ず考慮してください。出力動画のアバター トークンはセッション メモリに含まれません。過去の 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 の要件を見積もる

潜在的なワークロードの例を見て、見積もりツールがこのモデルの推奨事項をどのように提供するかを理解しましょう。この推奨事項は、リクエストの処理方法とバーンダウン率の適用方法も示します。ユーザーが、10 個の同時セッションが想定され、継続時間が 5 分(300 秒)のチャットボットに Live API を使用することを計画しています。セッションあたりの会話ターン数は 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

ターンあたりの出力トークン数:

出力モードとそのバーンダウン率の積和を計算します。出力動画アバター トークンは、オーディオ トークン 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 トークン

リクエスト #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 個になります。

次のステップ