AIREITER語音代理的成本，往往不是從使用者開口的那一刻才開始變複雜。來電者停頓、突然轉換話題、等待工具回應，甚至只是保持通話半小時，都可能改變最後帳單。Gemini 3.8 Live 採用 Token 計費，還會受到持續上下文重複處理的影響；GPT-Live-1 則公布了語音層每分鐘 $0.05 的單一價格。對生產團隊來說，真正該比較的不是哪個標價比較低，而是哪種計費方式更符合你的工作階段實際運作方式。
給生產團隊的快速結論
Google 的 Live API 文件在工作階段恢復範例中使用了 gemini-3.8-live 這個模型字串。Google 目前的 Live 文件也指出，音訊會以 Token 計費，而保留的上下文可能在後續回合再次被處理。OpenAI 的 GPT-Live-1 發表公告則列出前端語音層每分鐘 $0.05 的價格，後端推理與工具另行計費。
因此，兩者適合的情境很不一樣：
| 生產需求 | 較適合的起點 | 原因 |
|---|---|---|
| 需要容易預估的語音層預算 | GPT-Live-1 | 以實際通話時間計費，比會持續增長的音訊上下文更容易預測 |
| 需要進行 Token 層級最佳化 | Gemini 3.8 Live | 可以調整活躍上下文、壓縮策略與使用的模態 |
| 需要具備受控記憶的長時間對話 | Gemini 3.8 Live，但前提是工程設計要到位 | 上下文壓縮與工作階段恢復都是 API 設計中明確提供的機制 |
| 希望快速部署電話語音代理 | GPT-Live-1 | OpenAI 將此模型定位為支援全雙工電話服務，並可將工作委派給後端處理 |
| 通話可能長時間保持靜音 | 沒有設定防護措施時，兩者都不理想 | GPT-Live-1 會按工作階段時間計費；Gemini 仍可能累積上下文與傳輸成本 |
但有一點必須特別注意：本文查閱的Google Gemini API 定價頁面中，沒有列出 Gemini 3.8 Live 的獨立價格項目。不要把 Gemini 3.1 Flash Live 的費率直接套用到 Gemini 3.8 Live 的財務預估上。
Gemini 3.8 Live 與 GPT-Live-1 的計費單位
Gemini 3.8 Live：音訊 Token、上下文與壓縮
Google 的 Live API 最佳實務指南指出，原生音訊約以每秒音訊 25 個 Token的速度累積。指南同時說明，持續工作階段可能在後續回合重新計費已累積的上下文。換句話說，對話越長，下一次回應所攜帶的歷史輸入可能就比前一次更大。
可以先用下面這個粗略模型理解：
Gemini 工作階段成本
= 當前音訊與文字用量
+ 各回合重複處理的保留上下文
+ 輸出音訊與思考用量
+ 選用的轉錄用量
+ 工具與基礎設施壓縮會改變成本曲線。Google 提供了 ContextWindowCompressionConfig，也記錄了適合長時間工作階段的滑動視窗策略。在 Google 的範例中，壓縮會於25,000 個 Token時觸發，並採用8,000 個 Token 的滑動視窗。不過，正式環境的設定應根據記憶召回能力與工具準確度測試，而不是直接照抄範例。
轉錄也可能帶來額外費用。Google 表示，啟用 inputAudioTranscription 或 outputAudioTranscription 後，除了原生音訊計費外，還會增加文字 Token 用量。如果團隊需要可搜尋的逐字稿，就應該把這筆附加成本納入每次問題解決的成本模型。
GPT-Live-1：按實際語音工作階段時間計費
OpenAI 將 GPT-Live-1 的前端語音層定價為每分鐘 $0.05，並以每秒為計費精度。實際換算如下：
| 工作階段長度 | GPT-Live-1 語音層成本 |
|---|---|
| 5 分鐘 | $0.25 |
| 30 分鐘 | $1.50 |
| 1 小時 | $3.00 |
| 持續開啟 8 小時 | $24.00 |
關鍵在於靜音。這個按分鐘計算的公開價格，是以工作階段持續時間為基準，而不只是使用者實際說話的秒數。也就是說，一通 30 分鐘的電話即使有 10 分鐘完全靜音，工作階段仍然維持了 30 分鐘。
當然，GPT-Live-1 也不是完整的代理帳單。OpenAI 將它描述為語音層，可把更深層的推理與工具呼叫交給後端處理，因此後端 Token、工具、電信、儲存、監控與人工轉接都要另外計算。
長時間工作階段的成本效益：四種情境
以下比較採用已公布的 GPT-Live-1 算式與公式，不自行捏造 Gemini 3.8 的價格。
1. 五分鐘的預約電話
GPT-Live-1 在不計後端推理與電信費用前，語音層成本為$0.25。至於 Gemini 3.8 Live，在 Google 公布或提供對應確切模型 ID 的適用費率前，無法負責任地給出價格。
使用 Gemini 時，應從實際工作階段記錄音訊輸入秒數、音訊輸出秒數、保留上下文 Token、轉錄 Token 與工具呼叫次數。短通話確實可能讓 Token 計費看起來更划算，但前提是提示內容與上下文都受到控制。
2. 三十分鐘的客服通話
GPT-Live-1 的語音層成本為$1.50。這個數字很好預算，但不代表這通電話一定成功解決了問題。
Gemini 的成本取決於保留了多少音訊，以及工作階段產生了多少回合。兩通同樣 30 分鐘的電話，Token 使用量可能差異很大：一通可能持續有人說話，另一通則可能包含長時間停頓、重複說明或多模態輸入。
3. 靜音等待或工具延遲
只要 GPT-Live-1 的工作階段仍保持開啟，就會持續計費。實務上的控制方式，是設定嚴格的靜音逾時，或明確切換到交接狀態。
Gemini 也不能簡單理解成「靜音就免費」。連線、工具協調、上下文策略，以及之後可能出現的下一個回合，都應納入成本模型。把靜音視為產品狀態問題，而不只是供應商定價細節。
4. 全天候聆聽的工作階段
按照 GPT-Live-1 公布的語音層費率，持續開啟 8 小時的成本是$24。如果同時維持 10 個這樣的工作階段，每天就是$240，還未包含後端模型與其他基礎設施。
如果應用程式避免傳送不必要的音訊，並且壓縮歷史內容，Gemini 的 Token 模型在互動稀疏的情況下可能更有效率。但如果應用程式保留原始對話上下文，並允許對話無限制地循環，成本就可能變得難以預測。全天候運作的設計必須經過負載測試，不能拿五分鐘 Demo 的結果直接外推。
會改變試算表的生產環境限制
上下文與連線存續時間
Google 的工作階段管理文件記載，未壓縮的純音訊工作階段上限為15 分鐘，音訊與影片工作階段則為2 分鐘。同一份文件也說明，單一 WebSocket 連線的持續時間約為10 分鐘，這與邏輯工作階段的存續時間是兩回事。生產環境用戶端同時需要上下文壓縮與工作階段恢復。
Google 的恢復 Handle 在工作階段最後一次終止後兩小時內仍然有效。伺服器也會在連線關閉前傳送 GoAway。如果漏接這些事件，長時間通話可能變成中斷通話、重複執行工具動作，或遺失來電者狀態。
並行數量是另一筆成本
每分鐘價格只能回答「一個開啟中的工作階段要多少錢」，無法回答「我同時可以執行多少個工作階段」。GPT-Live-1 文件以並行工作階段說明容量，列出的級別從Tier 1 的 25 個工作階段，到 Tier 5 的 500 個工作階段不等。即使每月支出仍在預算內，突然湧入的電話也可能撞上這個上限。正式上線前，應查閱 OpenAI 的 GPT-Live-1 模型參考文件，確認目前帳戶可用的並行額度。
使用 Gemini 時，則要記錄並行 WebSocket 數量、重新連線率、壓縮事件與配額錯誤。Token 吞吐量和同時執行的工作階段，是兩種不同的瓶頸。
電信服務與音訊橋接
電話語音代理還會產生模型以外的成本。Gemini 的電話整合指南採用 Twilio Media Streams 這類橋接方式，並說明如何在 Twilio 的8 kHz μ-law音訊、Gemini 的16 kHz PCM輸入，以及 Gemini 的24 kHz PCM輸出之間進行轉換。這個中繼層會增加電信商、傳輸、運算與營運工作。
GPT-Live-1 的全雙工定位，或許能減少自行處理打斷與互動協調的工作，但不會消除電信費用或後端工作。比較時要看完整通話成本，而不只是推理成本。
「我為行銷資料收集部署了一個 Gemini Live 語音代理，但它在預約流程中一直卡住。」— @ramanpal，回報 Gemini 3.8 Live Extended Thinking 的
turnComplete處理錯誤（X）。
這只是單一開發者早期部署時的回報，並不是經過測量的失敗率。但它仍然提醒我們：協定語意造成的問題，代價可能遠高於 Token 價格之間的一點差異。
我的選擇判準
如果目前最大的不確定性在語音層，而財務團隊需要一個清楚、按通話時間估算的數字，可以選擇GPT-Live-1。但要為靜音時間、單通電話最長時限、並行數量與後端推理設定硬性上限。每分鐘 $0.05 只是語音層的起點，不是每通電話的總成本。
如果團隊有能力追蹤 Token 用量，並且需要上下文壓縮、多模態能力或更細緻的 Token 控制，則可以選擇Gemini 3.8 Live。建議從範圍受控的工作流程開始，而不是一上來就打造沒有邊界的通用助理。衡量指標應該是每次完成任務的成本，而不是每分鐘成本：
每次成功解決問題的成本
= 模型 + 工具 + 電信 + 基礎設施的總成本
/ 有效完成的問題解決數在做出決定前，讓兩套系統處理相同的通話組合，並記錄平均值與 p95 的通話時間、音訊秒數、保留上下文 Token、轉錄用量、工具重試次數、轉接率、重新連線次數與問題解決率。真正的贏家，是在通話時間拉長後仍能維持這些指標穩定的系統。
常見問題
Gemini 3.8 Live 已正式開放嗎？
Google 目前的工作階段管理文件在恢復工作階段的範例中使用了 gemini-3.8-live。正式部署前，請在自己的 Google 專案中確認存取權限、地區、配額，以及確切的定價項目。
GPT-Live-1 會對靜音時間收費嗎？
它公布的價格是前端語音工作階段每分鐘的費用，並按秒計費。除非你的帳戶合約另有說明，否則應預設包含靜音在內的工作階段時間都會產生費用。
GPT-Live-1 每分鐘 $0.05 就是完整通話成本嗎？
不是。OpenAI 將這筆費用描述為前端語音層價格。後端推理、工具、電信、儲存、監控與人工升級處理，都屬於額外的成本中心。
Gemini 的上下文壓縮能讓長時間工作階段完全免費嗎？
不能。壓縮是上下文管理機制，不是零成本模式。它可以限制保留的歷史內容，並幫助避免超過時間限制，但即時音訊、輸出、工具與基礎設施仍會產生費用，或至少仍是營運上不可忽略的因素。
長時間語音工作階段中，哪個模型比較便宜？
在適用的 Gemini 3.8 Live 費率與實際流量型態都尚未明確前，沒有足夠依據給出一個普遍適用的答案。GPT-Live-1 較容易預估；Gemini 則可能讓上下文與輸入管理做得好的團隊獲得更佳成本效益。最終應以完成問題解決的成本來比較兩者。
生產環境的語音代理，不是用第一次令人印象良好的對話來定價，而是由長尾情境決定：靜音、重試、上下文增長、重新連線，以及最後仍需要人工介入的通話。在選模型之前，先把計費與觀測機制設計進整體架構。