認識 Qwen3.8-LiveTranslate：讓 AI 口譯跟上人類節奏的半秒鐘

Qwen3.8-LiveTranslate於 2026 年 9 月 19 日發布，而整份發布公告歸結起來就是一道減法。平均延遲——LAAL，即一個詞從講者口中說出，到其翻譯傳入聽者耳中的平均時間差——從上一代的 2.8 秒降至 2.3 秒。專業人類口譯員的「耳到口」時間差大約落在 2 到 3 秒。這就是整件事的全貌：重點不在於機器變快了，而在於它的延遲如今已落在聽者根本不再察覺到機器存在的區間之內。發布數據指出，上一代在 FLEURS 上的翻譯品質為 83.0 xCOMET-XXL；這一代則宣稱達到 85.7。這兩個數字都出自廠商，且是在廠商自家的評估環境中產生的，目前尚無任何獨立第三方重現這些結果——而這是本文最重要的一項但書。

讓這次發布值得讀過標題後繼續看下去的，是它的機制。Qwen 並不是靠打造更快的辨識器或更精簡的合成器來削減延遲。它刪除了兩者之間的接縫。

真正改變的是：接縫不見了

傳統同步口譯是一個三階段流程，十年來都以相同方式組裝：自動語音辨識轉錄串流，機器翻譯轉換轉錄文本，文字轉語音將結果朗讀出來。每個階段都是一個獨立的模型，有其自身的延遲預算，而每次交接都會遺失一些東西——第一個階段遺失的是韻律，第三個階段遺失的是說話者身分，以及在每個邊界上固定的數百毫秒，因為模組必須等待足夠的符元才能有信心。

Qwen3.8-LiveTranslate 以廠商所稱的 Interleave 架構取代了那樣的層層串接，該架構建構於 Hybrid MoE 骨幹之上，並拆分為兩個相互協作的模組：

• Thinker — 將影片、音訊、原始文本與譯文編排成單一的因果序列，並依時間順序交錯，還能以一次而非三次的流程，端到端產生理解與翻譯。

• Talker — 會將譯文連同原始音訊一併處理，合成出保有來源講者音色的語音，因此配音後的嗓音聽得出正是原本說話的那個人。

這項架構上的主張是：由於辨識、翻譯與合成共用同一個序列建模框架，而不是在模組邊界之間傳遞訊息，因此系統不再每說一句話就付兩次模組間稅。這是一個關於那 0.5 秒從何而來的合理說法，而它也正好是那種宣稱起來很便宜、驗證起來很昂貴的主張。把它當成廠商的解釋，而不是已確立的結果。

真正全新的三項能力

語言涵蓋範圍沒有變動：可辨識 60 種來源語言，其中 29 種可供語音輸出——與 Qwen3.5-LiveTranslate 的數量相同。有趣的新增功能，全都圍繞著多人同時說話時會發生的情況。

• 即時語者分段 — 每句話在說出的當下就會歸屬於某位說話者，而音色複製在輪替變化之間被描述為更穩定。Qwen 自行回報，在其自家的長篇多說話者測試集上，分段錯誤率為 9.7%，而 Seed LiveInterpret 2.0 則為 30.6%。這兩項數據皆來自 Qwen。

• 原文與譯文置於同一畫面——模型在同一條時間軸上輸出原始逐字稿與譯文，這正是讓雙語螢幕字幕得以成對呈現、無須再進行第二次對齊處理的關鍵。

• 長上下文消歧義——先前的上下文會被延續下來，使姓名、敬稱與領域術語保持一致。這一點在實務上最為關鍵：同步口譯的經典失誤並非用錯詞，而是同一個人在一場會議中被呈現成三種不同的樣貌。

語者分離才是這裡真正具有區別性的項目。Gemini 3.5 Live Translate 是 Google 旗下與之競爭的即時語音轉語音模型，在輪替發言方面有已知的困難——它可能難以判斷說話者是否真的已經停止說話。Qwen 則把相反的特性當作一項功能來宣稱。兩家公司都尚未發表能一決高下的直接對比。

誠實地解讀基準測試的宣稱

Qwen 在兩組資料上進行了測試，而這兩組值得分開來看，因為它們衡量的是不同的東西。

• FLEURS，涵蓋 70 個語言方向 — 公開且廣為使用的多語言音訊基準。Qwen 宣稱其在翻譯品質、平均延遲、語音辨識準確度與語音合成品質上，均領先自家前代產品，以及其所稱的當前主流即時口譯系統。85.7 對 83.0 的 xCOMET-XXL 比較即出自此處。

• Omnilingua-MSpeaker，14 個語言方向——Qwen 自家的多講者長音訊評估集。該公司聲稱它在忠實度、流暢度與簡潔度上更佳，且語者分離錯誤率更低。由供應商自行打造的基準並非毫無價值，但也不算證據：它正是由被評測模型的那批人所設計的。

誠實的總結是，FLEURS 是真實且公開的，因此 85.7 至少在原則上可受查核；Omnilingua-MSpeaker 則不是，所以在有人重新跑過之前，其語者分離的勝出只是一種說法。截至撰寫本文時，尚無第三方公布 Qwen3.8-LiveTranslate 的數據，而且該模型才問世幾小時。

API 的成本是多少，以及一個會反咬你一口的數字

Qwen3.8-LiveTranslate 是封閉權重且僅提供 API。它透過 WebSocket Realtime API 運行，模型 ID 為 qwen3.8-livetranslate-flash-realtime，而非一般的 HTTP 端點。定價以每百萬個 token 計算，而由於音訊 token 的密度很高，其標示費率與文字模型相比乍看之下相當驚人，直到你想起音訊 token 究竟是什麼：

• 新加坡區域 — 音訊輸入 $7.50、圖片輸入 $0.55、文字輸出 $20.00、音訊輸出 $30.00（每百萬個符元）。

• 北京地區 — 每百萬個 token 音訊輸入 ¥40、圖像輸入 ¥3.3、文字輸出 ¥100、音訊輸出 ¥160，以目前匯率換算約為 $5.65 / $0.47 / $14.13 / $22.61。

• 上下文 — 總計 53,248 個 token，拆分為 49,152 個最大輸入與 4,096 個最大輸出。

• 速率限制 — 每分鐘 10 次請求與每分鐘 100,000 個權杖，兩個區域皆相同。

那個速率限制才是該畫線強調的數字。每分鐘十次請求，對少數幾間會議室來說很寬裕，但對聯絡中心部署，或是有數千個同時串流的直播來說，卻遠遠不夠。Qwen 讓這個介面的定價與前一代基本上持平——北京價格不變，新加坡則略便宜——但一個在架構上已為規模化做好準備的模型，卻以預覽版的方式配置額度。任何規劃正式環境流量的人，都應該把 10 RPM 上限視為真正具約束力的限制條件，而不是每 token 的價格。

呼叫它並不像呼叫聊天模型

Realtime API 是事件驅動的，這與 completion 端點的心智模型不同。你會開啟一個 socket、收到 session.created，接著在任何音訊開始流動之前，傳送一個 session.update 事件來設定工作階段。

• target_language為必填，且必須在首個音訊區塊之前設定——沒有隱含的預設目標。

• source_language為選用項目，預設為自動偵測。

• output_modalities 可選 ["text"] 僅產出逐字稿，或 ["text","audio"] 產出翻譯後的語音。

• input_audio_buffer.append 會將 base64 編碼的 PCM 區塊往上傳送；response.text.delta 與 response.audio.delta 則會往下傳回，並由 response.done 標示一輪對話的結束。

兩點實務上的提醒。首先，瀏覽器無法在 WebSocket 握手時設定 Authorization標頭，因此連線必須由伺服器端開啟，再透過你自己的 socket 把音訊轉送到用戶端——這不是能直接接到前端裡的東西。其次，Qwen 明確警告其參數與事件集與前一代 LiveTranslate 不同，因此任何針對 Qwen3.5-LiveTranslate 撰寫的程式碼都需要重新檢查，而不是改個指向就好。免費試用端點正在 omni.qwen.ai/live-translate 運行，如果你想在投入工程時間之前先聽聽延遲狀況，可以去試試。

它刻意不做的事

Qwen 列出了一些無法使用的功能，而這份清單釐清了狀況。沒有函式呼叫。沒有結構化輸出。沒有網路搜尋。沒有前綴續寫、脈絡快取或批次推論。沒有微調。

這是專家，不是戴著口譯員帽子的通才。它不會執行你的代理迴圈，也不會是負責摘要會議的模型。據此設計：口譯員產出逐字稿與翻譯後的音訊串流，而這之後下游的一切——行動項目擷取器、術語表強制執行器、CRM 回寫——都是另一個文字模型的工作。

這種分工正是路由器發揮價值的地方。Qwen3.8-LiveTranslate 本身可透過供應商自家的 API 及數個第三方平台取得；它目前並不在 OrcaRouter 的目錄中，我們也不會假裝不是如此。OrcaRouter 確實收錄的是周邊的技術堆疊——包括阿里巴巴自家的 Qwen3.8-Max 旗艦模型，這是一個具備 2.4 兆參數的稀疏專家混合模型，擁有 1M token 的上下文，每百萬輸入 token 收費 $2.00、每百萬輸出 token 收費 $6.00，依供應商定價計費，零加價轉嫁。把翻譯引擎與取用其輸出的模型放在同一個端點與同一把金鑰之後，代表當你更換摘要模型時，逐字稿管線不需要再簽第二份合約；而自動容錯移轉能在單一供應商出現波動時，讓系統的下游半部持續運作——在每分鐘 10 次請求的情況下，這是值得事先規劃、而非事後才發現的情境。

接下來要看什麼

有兩件事會讓這次發布從一個論證充分的說法變成板上釘釘的事實。第一是獨立的延遲測量：LAAL 是一個定義明確的指標，任何擁有試用端點和碼錶設備的人都能得出一個並非由 Qwen 自己產出的數字。第二是 Qwen 自己公開的路線圖——更接近延遲下限、跨工作階段的長期記憶，以及對長尾語言與區域方言的涵蓋。長尾這一項才是該拿來要求他們兌現的，因為 60 種源語言是個體面的數字，卻悄悄排除了世界上大多數的使用者，而一個能在華語和英語運作的示範，與一個能在約魯巴語或克丘亞語運作的示範之間的落差，正是即時口譯產品歷來卡住的地方。

目前合理的立場是：Qwen3.8-LiveTranslate 是第一個同步口譯模型，其招牌數字是對照人類口譯員，而非對照自己的前代模型——而這種對照框架，比它所取代的那一種是更難通過的考驗。它尚未通過。它只是自願接受這項考驗而已。