MAI-Transcribe-2-Streaming 對比 Gemini 3.5 Transcribe Live：同樣 9 美元，不同取捨

MAI-Transcribe-2-Streaming 與 Gemini 3.5 Transcribe Live 的成本相同，但兩者對於串流轉錄器究竟所為何來，建立在彼此相反的理論上。兩者每 1,000 分鐘串流音訊的價格都約為 9.00 美元。微軟的模型於 2026 年 10 月 1 日發布，是一件精密工具：宣稱在 0.13 秒內產生最終轉錄稿，串流詞錯誤率為 2.5%，而且根據微軟自己的說法，在最終與部分轉錄稿的準確度上均名列第一；此數據是依 Artificial Analysis 的串流方法論測量，但尚未在該排行榜上列為一列。另一款模型自 2026 年 8 月 26 日起公開預覽，並透過 Live API 提供服務，則是一件涵蓋範圍工具：支援 85 種以上語言且可於串流中途切換、提供免費方案，串流詞錯誤率為 4.00%、延遲 0.40 秒，此為 Artificial Analysis 為其測得的數字。兩者都不是顯而易見的首選，原因在於它們實際上並非在競爭相同的工作負載。

以下是正面對決，按照數字實際呈現的方式——標示出廠商通報的數字，註明追蹤機構的數字，並指出某一機型在某個面向勝出、而另一機型完全未與之競爭的部分。

一行版本

• 準確度與延遲——根據已公布的數據，MAI-Transcribe-2-Streaming 的表現如下。Microsoft 聲稱串流 WER 為 2.5%，最終轉錄稿延遲 0.13 秒，在最終與部分轉錄稿的準確度上均為第一，且首個部分轉錄稿的準確度為 2.5%、延遲 0.12 秒。相較之下，Artificial Analysis 測得 Gemini 3.5 Transcribe Live 為 4.00%、0.40 秒。Microsoft 宣稱的優勢為 1.5 個百分點，且定稿速度約快三倍。但需注意的是，該追蹤平台尚未把 MAI-Transcribe-2-Streaming 本身列入圖表——目前榜首是 Grok Voice Transcribe 2.0，為 2.73% 與 0.49 秒，Muse Voice Transcribe 則為 3.06% 與 0.16 秒——因此 2.5% 是廠商數據，拿來對照該追蹤平台確實有測量的領域。在兩款模型都有公布的這項軸線上，這並非難分高下，但其中只有一方是獨立公布的。

• 語言廣度 — Gemini 3.5 Transcribe Live。支援 85 種以上語言，可自動偵測，並能在不重新啟動工作階段的情況下於串流中途切換語言，這是 Google 為 Live API 打出的主要賣點。MAI-Transcribe-2-Streaming 涵蓋 60 種語言，具備自動連續語言偵測。Microsoft 的下限較高；Google 的上限較廣，而這 25 種語言的差距，大多落在單一語言串流模型根本無法使用的語言上。

• 工作階段形態——Gemini 3.5 Transcribe Live，而這一點是一體兩面。Live API 是上限為 10 分鐘的 WebSocket 工作階段，這對語音代理的一輪互動來說沒問題，但對長達一小時的會議就很尷尬；Microsoft 並未公布其串流模型有對等的工作階段上限，如果你的工作單位是一通通話，而不是一輪對話，這點就很重要。

• 入門成本 — Gemini 3.5 Transcribe Live。它提供免費方案，而 Google 的混合費率在以 token 計價的定價方式下，換算約為每分鐘 $0.009。Microsoft 的每音訊小時 $0.54 是推廣費率，Microsoft 表示該費率會持續到年底，且未公布標準價格——這與其九月批次推出時的結構相同。

為什麼準確度差距比看起來還要大

1.5 個百分點的詞錯誤率差距，聽起來像是四捨五入的差別，直到你把它換算成代價。在 4.00% 的串流 WER 下，Gemini 3.5 Transcribe Live 每 1,000 個字大約會錯 40 個字；對比 Microsoft 宣稱的 2.5%，MAI-Transcribe-2-Streaming 則錯 25 個。以即時管線所產生的處理量來看——一個每月處理 5,000 小時通話的客服組織，等於 300,000 分鐘，以一般對話語速換算超過 4,500 萬個字——這樣的差距每年就是數百萬個錯誤字詞，而且集中在下游系統所依賴的實體上：帳戶名稱、工單編號、劑量、地址。

延遲差異是比較難推銷的那一項。語音結束後 0.13 秒對上 0.40 秒，在即時字幕串流中是感受得到的——低於約 0.2 秒會被讀成同步，而三分之一秒則會被讀成逐字稿在追著講者跑——但在以人類時間尺度更新的客服輔助面板中，這並感受不到。如果你的消費者是一旁跟著閱讀的人，微軟的延遲領先就是產品本身。如果你的消費者是一個在對話輪結束時才拿到最終逐字稿的模型，那它就只是一個數字。

這兩個數字都有同樣的但書，而且值得在此說明一次：這些是來自一份涵蓋 37 個模型的追蹤排行榜的單次執行數字，而該排行榜上第一名與第三名之間的差距不到一分。重新執行可能會攪動串流排行榜前段的名次，而批次排行榜上兩分的差距則不會如此。Microsoft 的 2.5% 也還完全不在該排行榜上——那是依追蹤器方法論測量出的廠商說法，與追蹤器所公布的一列資料是兩回事。

限制正是決策真正所在之處

功能限制比基準測試更快將這兩者區分開來，而且它們朝相反的方向發展。

Gemini 3.5 Transcribe Live 帶有三項有明文記載的限制：Live API 的 10 分鐘工作階段上限、不支援說話者分離，以及沒有字詞層級的時間戳記。第一項屬於架構層面的限制——透過 WebSocket 工作階段進行串流，其上限是設計使然——這也意味著長篇即時轉錄必須跨工作階段拼接，而接縫的處理得由你自行負責。後兩項則是絕對的：如果你的產品需要將語音歸屬於特定說話者，或需要把某個字詞放到時間戳記上以供搜尋或字幕同步，那麼無論你出多少錢，Gemini 3.5 Transcribe Live 都辦不到。

MAI-Transcribe-2-Streaming 的限制條件記載得較少，而這本身就是一項資訊。Microsoft 並未對串流模型作出語者分離的宣稱，也沒有提出詞級時間戳記的宣稱；批次版 MAI-Transcribe-2 內建語者分離並回傳詞級時間戳記，但那是批次產品，而假設串流 SKU 會繼承這些能力，正是發表資料存在所要防止的那種推論。Microsoft 確實宣稱的是支援 60 種語言、具備持續語言偵測，以及在準確度與延遲之間位居帕雷托前緣——這兩項廠商說法都與追蹤器的資料一致。

所以，坦白從功能面來看是：這兩款串流模型都沒有公布支援語者分離或詞級時間戳記。Gemini 3.5 Transcribe Live 有已公布的工作階段上限，並提供免費方案；MAI-Transcribe-2-Streaming 有已公布的語言數量，但沒有公布上限。如果你的需求包含語者分離，這兩者都不是解答，而你實際上是在看一套前面硬加了一層串流的批次轉錄。

價格一致性真正在告訴你什麼

兩家供應商從相反方向得出相同的每 1,000 分鐘 9 美元，是這項比較中最有趣的事實。Google 是透過 Live API 工作階段的 Token 計價達到這個價格：音訊輸入為每百萬個 Token 3.50 美元，文字輸出為每百萬個 Token 21 美元，且每分鐘大約消耗 175 個文字 Token，混合換算後約為每分鐘 0.009 美元。Microsoft 則是藉由為某個模型列出每音訊小時 0.54 美元的固定價格來達到這個數字，而該模型同家族中的批次版本為 0.10 美元。一個是按用量計費的即時工作階段；另一個則是附帶初期折扣的固定每分鐘費率。

這些結構在擴展規模時會有不同的表現。固定費率可預測，也容易編列預算；以 token 計量計費的工作階段則會隨著模型回覆的多寡，以及工作階段閒置開啟的時間長短而變動。對高流量的管線而言，固定費率是較友善的帳單；對原型或低流量功能而言，免費方案與依 token 計費則是較友善的入門選擇。

兩種結構都未改變的，是轉錄稿之上的那一層。無論是哪個模型產出，即時轉錄稿都是摘要、分類、遮蔽與路由的輸入，而這些步驟各自有其成本與品質曲線——通常會橫跨多個模型執行，而非只靠一個。那正是 OrcaRouter 涵蓋的層：一個 API 橫跨 200 多個模型、供應商定價以 0% 加成原樣傳遞、自動容錯移轉，以及一套可依工作負載將轉錄稿導向不同模型的路由 DSL。MAI-Transcribe-2-Streaming 與 Gemini 3.5 Transcribe Live 都不在那份名單上——它們分別透過 Microsoft 與 Google 自家的語音堆疊提供——重點不在於將它們納入路由，而在於讓它們下游的一切保持可攜。

該選哪一個

當準確度與定稿時間就是產品本身時，請選擇 MAI-Transcribe-2-Streaming：供人閱讀的即時字幕、聽錯實體會付出成本的即時合規或品質評分，或是 Gemini 的 10 分鐘上限會逼得你必須拼接的長時間工作階段。當涵蓋範圍就是產品時，請選擇 Gemini 3.5 Transcribe Live：你無法事先列舉語言的全球部署、串流中途切換語言，或是免費方案與按 token 計費能免去長期承諾的原型。兩者都需要的團隊不會陷入困境——兩者是不同的 API、不同的工作階段模型，而誠實的架構是依工作負載來路由，而不是標準化採用其中一個。

從這項比較中值得採納的主張，並不是 Microsoft 贏了。而是串流轉錄如今已有兩個定價相同、可信的頂尖選項，這意味著決策已從「有什麼可用」轉向「這個特定工作負載需要什麼」。這是個更值得面對的問題。