Gemini Live API 的佈建輸送量

本節說明「佈建輸送量」如何搭配 Gemini Live API 運作,以計算權杖和強制執行配額。

Gemini Live API 支援透過工作階段進行低延遲多模態互動。這項功能會使用工作階段記憶體保留及回想工作階段內的互動資訊。模型就能回想先前提供的或討論的資訊。透過 Gemini Live API 模型,佈建輸送量支援 Gemini 2.5 Flash。如要進一步瞭解 Gemini Live API,包括工作階段限制和功能,請參閱 Gemini Live API 參考資料

計算 Gemini Live API 的輸送量

使用 Gemini Live API 時,儲存在工作階段記憶體中的權杖可用於後續對模型的要求。因此,佈建輸送量會將傳入的權杖和同一要求中的工作階段記憶體權杖納入考量。這可能會導致每個要求處理的權杖數量,大於使用者在進行中的要求中傳送的權杖數量。

Gemini Live API 對可儲存在工作階段記憶體中的權杖總數設有限制,且含有包含權杖總數的中繼資料欄位。計算服務要求所需的輸送量時,必須將工作階段記憶體中的權杖納入考量。如果您已使用即付即用 (PayGo) 方案的 Gemini Live API,可以運用這些流量模式和工作階段權杖,估算佈建輸送量需求。

如何估算 Gemini Live API 的佈建輸送量需求

在工作階段期間,所有流量都會以「佈建輸送量」或「隨用隨付」方式處理。如果工作階段期間達到「佈建輸送量」配額,您會收到錯誤訊息,要求稍後再試。配額恢復後,您就可以繼續傳送要求。只要工作階段處於有效狀態,就能存取工作階段狀態 (包括工作階段記憶)。

這個範例說明如何處理兩個連續要求,包括來自工作階段記憶體的權杖。

要求#1 詳細資料

時間長度:10 秒

傳送的權杖 (音訊):10 秒 x 25 個權杖/秒 = 250 個權杖

傳送的權杖 (影片):10 秒 x 258 個權杖/每秒影格數 = 2580 個權杖

要求 1 處理的權杖總數

  • 傳送的權杖:傳送的音訊和影片權杖總和 = 2580 + 250 = 2830 個權杖
  • 收到的權杖:100 個 (音訊)

要求#2 詳細資料

時間長度:40 秒

傳送的權杖 (音訊):40 秒 x 25 個權杖/秒 = 1000 個權杖

要求#2 處理的權杖總數

  • 傳送的權杖:要求#2 中傳送的權杖 + 要求#1 中的工作階段記憶體權杖 = 2830 個權杖 + 1000 個權杖 = 3830 個權杖
  • 收到的權杖:200 個 (音訊)

計算要求中處理的權杖數量

系統會計算這些要求處理的權杖數量,計算方式如下:

  • 要求 1 只會處理進行中要求的輸入和輸出權杖,因為工作階段記憶體中沒有其他權杖。

  • 要求 #2 會處理進行中要求中的輸入和輸出權杖,但也會納入來自工作階段記憶體的輸入權杖,包括來自工作階段記憶體中前一個要求 (要求 #1) 的輸入權杖。工作階段記憶體中的權杖消耗率與標準輸入權杖相同 (1 個輸入工作階段記憶體權杖 = 1 個輸入權杖)。

    如果系統在您傳送要求#2 後,正好花費 1 秒處理要求,則權杖會經過處理並套用至佈建輸送量配額,如下所示:

    • 將輸入內容乘以消耗率,即可得出輸入詞元總數:

      2830 x (每個工作階段記憶體權杖 1 個權杖) + 1000 x (每個輸入文字權杖 1 個權杖) = 3830 個每項查詢的權杖用盡調整輸入權杖

    • 將輸出內容乘以消耗率,即可得出輸出內容詞元總數:

      200 x (每個音訊輸出權杖 6 個權杖) = 1,200 個權杖

    • 將這兩個總數相加,即可得出處理的權杖總數:

      3,830 個權杖 + 1,200 個權杖 = 5,030 個權杖

如果您的佈建輸送量配額大於每秒 5,030 個權杖,這項要求就能立即處理。如果低於配額,系統會以您設定的配額速率處理權杖。

後續步驟