本節說明「佈建輸送量」如何搭配 Gemini Live API 運作，以進行權杖計數和配額強制執行。
Gemini Live API 支援低延遲多模態互動，並使用工作階段記憶體在多輪對話中保留脈絡。如要瞭解其他功能和工作階段限制，請參閱 Gemini Live API 參考資料。
每個工作階段都必須完全專用於佈建輸送量或即付即用，不支援工作階段中途的溢出。如果有效工作階段期間的佈建輸送量超出配額，系統會允許暫時爆量，避免發生錯誤，並將超額用量計入整體配額。為避免用量突然暴增，請購買足夠的 GSU，以因應尖峰需求。
溢出金額可跨工作階段使用。啟動工作階段時，系統會評估要求標頭，並驗證佈建輸送量配額是否可用。如果配額不足，新工作階段預設會採用隨用隨付方案。
由於工作階段記憶體會將先前的輪次輸出內容做為後續要求的輸入內容，因此佈建輸送量會根據新傳入的權杖和累積的工作階段權杖計算配額。因此，隨著工作階段進行，每個要求處理的權杖總數會增加，直到達到預先定義的工作階段上限為止。只要工作階段處於直播狀態，就能存取工作階段狀態，包括工作階段記憶體。
預估所需佈建輸送量時，請務必將工作階段記憶體權杖納入考量。請注意，輸出影片的虛擬人偶權杖不會納入工作階段記憶體。即付即用流量的歷史模式可做為計算 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 需求
讓我們逐步瞭解潛在工作負載的範例，以及預估工具如何為這個模型提供建議，進而瞭解要求處理方式和用量扣抵率。使用者打算為聊天機器人使用 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
每回合的輸出內容詞元：
計算輸出模式的總和乘積及其各自的燃盡率。請注意，輸出影片虛擬分身詞元數代表每 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 秒 x 25 個權杖/秒 = 250 個權杖
- 傳送的詞元數 (影片)：10 秒 x 每秒 258 個詞元/影格 = 2,580 個詞元
- 根據要求性質收到的輸出音訊權杖：100 個權杖
- 更新後的工作階段記憶體 = 250 + 2,580 + 100 = 2,930 個權杖
要求 #2 詳細資料 - 輸入音訊 (含工作階段記憶體)，輸出音訊
- 時間長度：40 秒
- 傳送的權杖 (音訊)：40 秒 x 25 個權杖/秒 = 1,000 個權杖
- 要求 #1 後的工作階段記憶體 = 2,930 個權杖
- 傳送的輸入權杖總數：這項要求傳送的權杖 + 要求 #1 的工作階段記憶體 = 1,000 + 2,930 = 3,930 個權杖
- 根據要求性質收到的輸出音訊權杖：200 個權杖
- 更新後的工作階段記憶體 = 3,930 + 200 = 4,130 個權杖
要求 #3 詳細資料 - 輸入含有工作階段記憶體的音訊和影片，輸出虛擬人偶影片和音訊
- 時間長度：10 秒
- 傳送的權杖 (音訊)：10 秒 x 25 個權杖/秒 = 250 個權杖
- 傳送的詞元數 (影片)：10 秒 x 每秒 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 秒 x 25 個權杖/秒 = 250 個權杖
- 傳送的詞元數 (影片)：10 秒 x 每秒 258 個詞元/影格 = 2,580 個詞元
- 根據要求性質收到的輸出音訊權杖：100 個權杖
- 更新後的工作階段記憶體 = 250 + 2,580 + 100 = 2,930 個權杖
要求 #2 詳細資料 - 輸入音訊 (含工作階段記憶體)，輸出音訊
時間長度：40 秒
傳送的權杖 (音訊)：40 秒 x 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 個依燃盡圖調整的權杖。