本節說明「佈建輸送量」如何搭配 Gemini Live API 運作，以進行權杖計數和配額強制執行。
Gemini Live API 支援透過工作階段進行低延遲多模態互動。這項功能會使用工作階段記憶體，保留及回顧工作階段內的互動資訊。模型就能回想先前提供的或討論的資訊。佈建輸送量支援 Gemini 2.5 Flash with Gemini Live API 模型。如要進一步瞭解 Gemini Live API，包括工作階段限制和功能，請參閱 Gemini Live API 參考資料。
Gemini Live API 的工作階段必須完全專用於佈建輸送量或即付即用流量。系統不支援在同一工作階段中，於已佈建輸送量和隨用隨付之間溢出的流量。工作階段開始時設定的流量類型會持續整個工作階段。如果工作階段進行期間達到佈建輸送量配額，您不會遇到節流或錯誤。系統不會立即停止，而是允許流量暫時爆量，讓工作階段繼續進行，但後續所有用量都會計入整體配額。這段暫時的流量爆量可能會導致監控資訊主頁顯示的佈建輸送量用量 (專屬流量) 超出上限。為避免在工作階段中超出分配的限制，請務必購買足夠的 GSU，以支援預期用量。
系統支援從一個工作階段溢出到下一個工作階段。如果工作階段結束後，您超過了佈建輸送量限制，可以使用 PayGo 啟動額外工作階段。工作階段開始時，系統會決定整個工作階段是以佈建輸送量或 PayGo 處理。系統會檢查使用者傳送的標頭，然後驗證工作階段是否有足夠的佈建輸送量配額。如果可用的佈建輸送量配額不足以處理整個工作階段，系統就會改用 PayGo 配額。
計算 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 (每個音訊輸出權杖 24 個權杖) = 4,800 個權杖
將這兩個總數相加，即可得出處理的權杖總數：
3,830 個權杖 + 4,800 個權杖 = 8,630 個權杖