Qwen3.8-LiveTranslate 對決 Gemini 3.5 Live Translate：一方交出的是數字，另一方交出的是地圖

兩款領先的即時語音翻譯模型，對於自己願意接受哪些指標檢驗這件事上看法分歧，而這種分歧比任何規格比較都更有用。Qwen3.8-LiveTranslate於 2026 年 9 月 19 日發布，主打一個明確的硬指標：平均延遲 2.3 秒，低於上一代的 2.8 秒。Gemini 3.5 Live Translate是該廠商於 2026 年 6 月發表的語音轉語音模型，至今仍掛著預覽版模型 ID，它主打的是覆蓋範圍——70 多種語言、自動偵測、對話中途切換，以及整合進該廠商的 Translate 與 Meet 應用程式。一家公司公布了能被外界檢驗的延遲數字。另一家則公布了語言數量。如果你正要在兩者之間做選擇，理解為什麼這是兩種不同性質的承諾，比哪份清單更長更重要。

兩種架構，只在目標上一致，別無其他共識。

這兩款模型存在的目的，都是要消滅同一種行為：那種輪流發言式的翻譯器，會等你把一句話說完才開口。正是那段停頓，讓機器口譯感覺起來就像機器口譯。

Qwen3.8-LiveTranslate 透過在 Hybrid MoE 骨幹上的 Interleave 架構達成此目標，該架構分為 Thinker 模組與 Talker 模組：前者將音訊、視訊、來源文本與翻譯折疊成一個因果序列，後者則以原始說話者的音色重新合成翻譯。其主張是，將辨識、翻譯與合成收束為單一序列，可消除三階段管線在每個模組邊界所付出的延遲與語意損失。

Gemini 3.5 Live Translate 則是從相反方向採取相同的端到端定位：它以 Gemini 3 Pro 為基礎打造，是原生的音訊對音訊模型，透過 Gemini Live API 持續串流，而不是執行離散的 ASR → MT → TTS 串接流程。實務上，你會維持一條持續存在的雙向 WebSocket，向上推送 100 毫秒的音訊區塊，向下拉取翻譯後的音訊區塊。這兩個模型都不再做舊的那一套。兩者現在都在做新的事。差異全都在次級細節裡。

延遲比較並非表面上看起來的平手。

Google 將 Gemini 3.5 Live Translate 描述為會「落後講者幾秒鐘」。該公司尚未針對這個模型公布 LAAL 數值，或任何其他具名、可重現的延遲指標。Qwen 則已公布 2.3 秒，並定義了其含義。

這種不對稱經常被抹平成「兩者大約都落在兩到三秒之間」。這種解讀並不獲兩家公司先前的任何說法支持。Google 的說法既可與 2 秒相容，也可與 4 秒相容；該公司只是拒絕被明確定位。今天真正能做的比較是：

• 已公布的延遲指標 — Qwen3.8-LiveTranslate：LAAL 2.3 秒，由廠商自行報告。Gemini 3.5 Live Translate：未公布任何數據。

• 獨立延遲量測——兩者皆無，對任一模型而言都是如此。沒有任何第三方發表過正面對決的比較結果。

誠實的結論是：就延遲而言，Qwen 提出了可證偽的主張，而 Google 提出的主張則含糊不清。這在透明度上是 Qwen 的加分項，但在效能上，除非有人實際測量兩者，否則它完全得不到任何加分。如果延遲是你的部署中的決定性因素，那麼目前的證據狀態無論朝向哪一方，都不足以支持你做出採購決策。

60 種語言對比 70 多種語言，是錯誤的計分標準。

語言統計數字經常被引用，而它們會在兩個方向上造成誤導。

Qwen3.8-LiveTranslate 可辨識 60 種來源語言，並以其中 29 種產生語音輸出。Gemini 3.5 Live Translate 支援 70 多種語言並具備自動偵測功能，而在 Google Meet 中，這更可擴展至 2,000 多種語言組合，相較之下，先前的上限是以英文為基礎、涵蓋五種語言的翻譯。

在把它當成三重勝利之前，請先仔細讀第二個數字。Google 的 2,000 多這個數字，計入的是有序配對——每一種來源語言與每一種目標語言交叉配對——這是一種合理且確實有用的涵蓋範圍衡量方式，但無法與單一語言的數量相提並論。而 Google 的名單雖然較廣，卻嚴重偏向使用人口眾多的語言：南非語、阿拉伯語、孟加拉語、荷蘭語、英語、法語、德語、印地語、印尼語、義大利語、日語、韓語、馬來語、波斯語、波蘭語、葡萄牙語、俄語、西班牙語、史瓦希里語、坦米爾語、泰盧固語、泰語、土耳其語、烏克蘭語、烏爾都語、越南語、祖魯語。Qwen 的 29 種語音輸出語言則更狹窄，而且兩家廠商的名單都無法真正回應長尾需求——那些區域方言與低資源語言，正是口譯工具歷來失敗最慘重的地方。兩家公司都說正在處理。但兩家都尚未推出。

真正分歧之處在於：那擠滿人的房間

這些模型唯一真正做出不同承諾的地方，就是多說話者處理；而這也正是最可能決定實際部署結果的差異。

Qwen3.8-LiveTranslate 內建即時講者分離功能：每當句子出現時，就會歸屬於對應的講者，而語音複製在輪替變化時仍被描述為穩定。Qwen 自我報告在其自身的長篇多講者測試集上，講者分離錯誤率為 9.7%，而 Seed LiveInterpret 2.0 則為 30.6%——這是在廠商自行執行的評估上所進行的廠商比較，因此應將其視為附帶數字的宣稱，而非結果。該模型還在同一時間線上輸出原文與譯文，這正是讓同步雙語字幕無需另行進行對齊處理即可實現的原因。

Gemini 3.5 Live Translate 則著重於相反的方向。其官方記載的強項是韻律保留——維持講者的音高、節奏、語調與情感色彩，讓翻譯後的語音帶有原音的感受。其官方記載的弱點，恰恰是語者分離能派上用場之處：語音複製不穩定，長時間停頓後可能出現漂移，或落到錯誤的性別；輪替發言能力薄弱，缺乏明確的句尾訊號；面對濃重口音，以及西班牙語與葡萄牙語這類相近語言組合時會有困難；背景噪音的處理也不夠完善。此外，Google 也將純音訊工作階段的長度上限設為 15 分鐘，除非另行延長；而每個生成的音訊串流都會被蓋上目前無法移除的 SynthID 浮水印。

• 多說話者歸因 — Qwen：即時語者分離，聲稱 DER 為 9.7%。Gemini：文獻記載其輪替發言能力薄弱，未聲稱支援語者分離。

• 語音保真度 — Qwen：透過 Talker 模組重現來源音色。Gemini：保留韻律、音高與語速；已記錄的複製漂移。

• 雙語輸出 — Qwen：原文與譯文在同一時間軸上輸出。Gemini：可選的輸入與輸出轉錄，依工作階段進行設定。

• 浮水印 — Qwen：未提及。Gemini：所有生成的音訊皆嵌入 SynthID，無移除途徑。

• 工作階段長度 — Qwen：未說明。Gemini：純音訊工作階段上限為 15 分鐘。

• 輸入類型 — Qwen：音訊與圖像。Gemini：僅音訊，無文字輸入。

每一項實際運作起來的成本是多少

Qwen3.8-LiveTranslate 透過 WebSocket Realtime API 以每百萬個 token 計價。在新加坡區域：音訊輸入 $7.50、圖像輸入 $0.55、文字輸出 $20.00、音訊輸出 $30.00。在北京：每百萬 ¥40 / ¥3.3 / ¥100 / ¥160——約為 $5.65 / $0.47 / $14.13 / $22.61。其上下文為 53,248 個 token，而兩個區域的速率限制皆為每分鐘 10 次請求及每分鐘 100,000 個 token。

那個 10 RPM 上限是費率表中最舉足輕重的數字。Gemini 3.5 Live Translate 的商業條款並未以相同方式公布，這本身就是一項關於成熟度的訊號：Google 正透過 Live API 和 AI Studio 以公開預覽形式發布它，透過 Google Meet 向特定 Workspace 客戶提供私人預覽，並在 Android 和 iOS 上的 Translate 應用程式中推出。預覽版定價與預覽版速率限制可能隨時變更，恕不另行通知，且 Google 尚未承諾 GA 日期。

所以，現在的成本比較，是在一個有公開定價與硬性併發上限的模型，和一個沒有公開定價、上限也未指明的模型之間進行。如果你這季需要建立單位經濟模型，這兩者之中只有一個是可編列預算的。

獨立測試必須顯示什麼

以上所有內容都是根據兩家廠商自家的公告拼湊而成，因為還沒有人讓這些模型彼此對測過。要有真正能定奪這場對決的結果，需要四項條件，而這四項目前都還不存在：

• LAAL 在兩個模型上以相同方式量測，使用相同音訊、相同語言對——Qwen 的 2.3 秒數字無法與 Google 拒絕說明的任何內容相比。

• 在共享的多說話者語料庫上的語者分離錯誤率，而非 Qwen 自家的 Omnilingua-MSpeaker 資料集。

• 長時間通話階段的語音複製穩定性，這正是 Gemini 自家文件點出會有漂移問題，而 Qwen 在此做出最強聲明的地方。

• 併發限制下的行為——Qwen 的 10 RPM 在真實會議負載下是否撐得住，以及 Gemini 的預覽配額能否經得起正式環境的考驗。

在那項測試出現之前，站得住腳的立場其實很有限：Qwen 公開發表的東西更多，也承諾了更具體的事；Google 則有更廣泛的語言涵蓋範圍，以及只靠 API 的模型無法比擬的通路版圖。

該選哪一個

著眼於問題的形狀，而非計分板，因為計分板還不值得信賴。

如果你的工作負載涉及多方且歸屬很重要——會議轉錄、座談小組、法庭，任何情況下知道誰說了哪一句經翻譯的句子本身就是價值的一部分——那 Qwen3.8-LiveTranslate 是兩者中唯一宣稱具備這項能力者，而 Gemini 有紀錄的輪替發言弱點也指向同一結論。如果你的工作負載是廣泛語言、面向消費者，且早已身處 Google 生態系統中，那麼 Gemini 3.5 Live Translate 的七十多種語言，以及它在 Translate 應用程式與 Meet 中的存在，是任何僅有 API 的競爭對手在觸及範圍上無法比擬的優勢。

如果你是在打造產品，而不是買一個示範品，請注意這兩者都是狹窄的專門工具。兩者都不會執行代理迴圈，兩者都不會做摘要，而 Qwen3.8-LiveTranslate 明確不支援函式呼叫、不支援結構化輸出、不支援上下文快取，也不支援微調。口譯模型是你管線的前端，而不是管線的全部。OrcaRouter 不是今天呼叫這兩個翻譯模型的地方——兩者都不在我們的目錄中，我們寧可直說，也不願暗示並非如此。我們提供的，是堆疊中負責消費逐字稿的那一半：一組金鑰即可使用 200 多個模型，依供應商定價計費，零加成轉嫁，因此閱讀該逐字稿的摘要工具、術語表強制執行工具或下游代理，都能在不需觸及第二份供應商合約的情況下進行替換或容錯移轉。

它的底部

Qwen3.8-LiveTranslate 和 Gemini 3.5 Live Translate 在基本面上足夠接近，以至於行銷成了區別關鍵：一方公布了延遲數字和費率表，另一方則公布了語言地圖和生態系。兩者都尚未接受獨立測試。這場對決值得一讀的版本，是在有人把兩者跑在同一段音訊上之後才會寫出來的那個版本——而考量到這個類別發展之快，那個時間可能不遠了。