本節說明「佈建輸送量」如何搭配 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 配額。
計算 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 個權杖