GPT-Live-1 對比 Gemini 3.5 Live Translate：已正式推出的通才，對上預覽版專才

這兩個模型會被拿來比較，是因為它們都把即時語音放進 API，而一旦你讀了模型卡，這個比較就立刻站不住腳。GPT-Live-1 是通用型全雙工語音模型，Ope​nAI 於 2026 年 9 月 10 日將其移入開發者 API，距離它 7 月 8 日在 ChatGPT 內推出已過了三個月。Gem​ini 3.5 Live Translate 是單一用途的音訊對音訊翻譯模型，由 Goo​gle DeepMind 於 2026 年 6 月 9 日發布，而且它的模型 ID 仍帶著 preview 這個字。其中一個，你今天就能以已公布的費率放到付費客戶面前。另一個，Goo​gle 可以在你不知情的情況下變更，而且不會發出淘汰通知。決定選擇的應該是這種不對稱性，而不是基準測試表。

兩台不同的機器貼著相同的標籤

值得直白地說，這兩者重疊的地方少之又少。Gemini 3.5 Live Translate 負責翻譯。它接收一種語言的串流音訊，並以另一種語言回傳串流音訊，同時保留說話者的聲音與語氣，涵蓋 70 多種語言、超過 2,000 個語言配對，並具備自動語言偵測與雙向運作能力。它不會進行對話、呼叫函式，也不會回答問題。它是一套同步口譯引擎。

GPT-Live-1 則是相反的形態。它是一個對話模型：同時聆聽與說話，每秒會做出多次決定，判斷該繼續聆聽、暫停、插話，還是呼叫工具，並在對話持續進行的同時，把繁重的工作——網路搜尋、更深度的推理、代理式任務——透過 Responses API 交給另一個獨立的推理模型。OpenAI 自己公開的 WebRTC 範例，便是把這項委派接到 GPT-5.6 Terra。翻譯是它能做的事之一；而反過來說，Google 的模型並沒有任何對等的功能。

所以，實際的問題比標題對決所暗示的更狹隘：如果你打造的是口譯功能，Goo​gle 的模型是為此專門打造的，而 Ope​nAI 的則是通用型。如果你打造的是偶爾會翻譯的語音代理，那麼在兩者之中，GPT-Live-1 是唯一甚至屬於正確產品類別的選擇。

每一項每分鐘音訊的成本是多少

這正是專家發揮價值的地方，而這筆帳對 OpenAI 來說確實很棘手。

• GPT-Live-1 — 語音每分鐘 $0.05，以秒計費，而非進位至下一個整分鐘。由委派後端所進行的推理與工具呼叫，則依該模型的正常費率另行計費。

• Gemini 3.5 Live Translate — 每百萬個音訊輸入 token 為 3.50 美元，每百萬個音訊輸出 token 為 21.00 美元，計費以每秒音訊 25 個 token 計算。兩者合計，每分鐘翻譯音訊約為 0.037 美元。

若單看純翻譯分鐘數，Google 大約便宜四分之一。這在大規模下並非四捨五入的差異：每月 10,000 分鐘的口譯，使用 GPT-Live-1 的語音層約需 500 美元，而使用 Gemini 3.5 Live Translate 則約需 368 美元。而且這個差距是真實的，並非計量方式變更所造成的假象，因為這兩個模型是以截然不同的單位計費。

反過來也有一個陷阱。GPT-Live-1 所標榜的 $0.05，只是語音層的價格。如果你的代理除了翻譯還去查資料，或把難處理的句子升級交給推理模型，你還得為這層委派額外付費——而被委派的模型就像其他任何前沿模型一樣，是按 token 計價的。純翻譯的工作負載永遠不會觸發這種情況。但翻譯加上任何其他功能的工作負載就會，於是每分鐘成本比較的贏家就不再那麼明顯了。

預覽標籤是沒有人計入定價的風險

Gemini 3.5 Live Translate 的模型 ID 是 gemini-3.5-live-translate-preview。它已以公開預覽形式在 Gemini Live API 和 Google AI Studio 推出，同時也在 Android 和 iOS 的 Google 翻譯應用程式中推出，並在 Google Meet 中向特定 Workspace 客戶提供私人預覽。預覽一詞在 Google 向來意指：不保證穩定性、沒有公佈的淘汰期，也不承諾你目前支付的費率能挺過下一次發佈。

對消費型應用程式來說，這沒問題。但對這個模型真正鎖定的工作負載——客服中心的即時口譯、會議產品、旅遊產品——而言，它是整個技術堆疊中最大的單一整合風險。你正在建立一項正式環境的依賴，而依賴的是一個 Google 明確尚未承諾的模型。

GPT-Live-1 有相反的問題，而且這個問題較小，但並非為零。它已正式推出，有公開的費率，也有文件記載的端點，而且不會消失。但它的 API 介面很狹窄，這會讓那些以為它能直接套用到現有 OpenAI 整合的團隊感到意外：它只有一個模型 ID、一個端點，且無法透過 Chat Completions、Responses、Realtime、Batch、Assistants 或微調來使用。唯一進入方式是位於 v1/live/sessions 的 Live Sessions 端點，透過 WebRTC，並在資料通道上處理事件。這是一項新的整合，而不是單純變更參數。

語言，以及通才確實較弱之處

Google 的數字是 70 多種語言，並能保留語音與語氣。OpenAI 自家的文件對自身涵蓋範圍明顯較不具信心：發布資料指出，對某些語言而言，模型可能帶有非母語口音，或在流利度上出現落差，而且它並未公布能與 Google 匹敵的語言數量。

那不是供應商在故弄玄虛——那是通用型對話模型與針對這個問題受訓的專家模型並列時的樣子。如果你的產品價值主張是「我們能妥善處理 40 種語言」，專家模型才是誠實的選擇，而通用模型會在長尾情境中讓你難堪。如果你的產品是面向英語市場的語音代理，只是硬加上翻譯功能，那麼通用模型的語言落差永遠不會浮現。

兩個模型都會用 SynthID 為生成的音訊加上浮水印；如果你所在的司法管轄區或客戶合約要求合成語音必須具備來源溯源，這一點就很重要。這一項算是打平。

在委派架構改變建置之處

這兩者在結構上的差異在於，GPT-Live-1 其實是兩個模型，中間有一道接縫。語音層負責讓對話持續進行；另一套獨立的推理模型則負責思考。那道接縫正是你投入工程心力之處，也是成本模型變得複雜的地方。

值得知道的是，被委派的那一半是一個普通的文字模型，你可以像其他任何模型一樣對它進行路由。GPT-5.6 Terra，也就是 OpenAI 自家範例中的後端，是透過 OrcaRouter 提供服務的，每百萬輸入權杖 $2.00、每百萬輸出權杖 $12.00，具備 1M 權杖的上下文視窗，並同時提供 /v1/chat/completions 與 /v1/responses 端點。如果你想替換語音代理背後的推理大腦——在簡單通話時換成更便宜的模型，或在升級處理時換成更強大的模型——堆疊中的那一半是有選擇的，因為它就只是一般的 API 呼叫，與同一把金鑰上的大約 190 個其他模型並列。

語音那一半則不然。GPT-Live-1 不在 OrcaRouter 上，Gemini 3.5 Live Translate 也一樣；兩者都只能向打造它們的原廠取得。在這樣的架構裡，路由器真正能佔有一席之地的地方，是音訊之後的所有環節：負責檢索、摘要、CRM 回寫與升級處理的文字模型，也就是帳單中你確實能整合到單一金鑰與單一發票上的那一半。

實際上該選什麼

• 如果翻譯本身就是產品、每分鐘價格比合約穩定性更重要，而且你能承受預覽版模型在你底下變動，就選擇 Gemini 3.5 Live Translate。預算大約每分鐘 $0.037，並在呼叫之上保留一層抽象層，好讓 GA 模型能取代它而無需重寫。

• 若你需要一個碰巧能翻譯的對話式代理、若你需要在語音迴路中進行函式呼叫與工具使用，或者若採購團隊會問當模型退役時會發生什麼事，而你需要的答案比「大概什麼都沒有」更好，就選擇 GPT-Live-1。

• 不要只因為某個模型贏得一項基準測試就選它。雙方的基準測試根本無法互相比較——Ope​nAI 的全雙工數據是自家發布的，沒有任何第三方重現過；而 Goo​gle 的語言能力宣稱，也從未在同一組音訊資料上與通用型模型對測過。

一個前瞻性的提醒：這兩個介面正在趨於匯流，而非相互衝突。Google 的翻譯模型早已內建於 Gemini Live 之中，而 GPT-Live-1 的語音層在設計上本就明確打算讓新的前沿模型直接置於其後。合理的預期是，在幾輪發布週期之內，通用型產品的翻譯會有所改善，而專門型產品的整合故事也會變得不那麼像一場賭注。如果你今天正在開發，而且兩者之間的抉擇難分高下，那麼這正是支持選擇較便宜、較容易替換之選項的理由，也是無論如何都該把音訊路徑隔離在一個介面之後的理由。