VibeVoice-ASR-Streaming-1.5B 對決 Gemini 3.5 Transcribe：微軟低調的串流語音辨識對上 Google 的新 API

這兩套最新的串流語音轉文字系統，彼此相隔七天，也隔著一道哲學鴻溝。2026年8月26日，Google 將 Gemini 3.5 Transcribe 推向公開預覽：這是一個代管式、封閉的語音轉文字 API，按音訊 token 計費，並提供獨立的 Live 端點供即時會話使用。2026年9月2日，Microsoft Research 將 VibeVoice-ASR-Streaming-1.5B 上傳至 Hugging Face 的 microsoft 命名空間下——採用 MIT 授權的權重，沒有新聞稿、沒有發布文章，而且截至本文撰寫時，沒有任何第三方報導。兩者都能在語音仍在傳入時進行轉錄。除此之外，在其他一切方面——誰能執行、成本多少、有哪些證據顯示它們有效——兩者幾乎截然不同。

此頁面比較的是兩者現今實際存在的樣貌，因此證據的兩邊並不對稱。Gemini 3.5 Transcribe 是 Google 的正式產品，公布了 token 價格，也有來自 Artificial Analysis 的第三方準確度數據；這些就是下方標示為 AA 的數字。VibeVoice-ASR-Streaming-1.5B 則是一個檢查點，其模型卡完全沒有以文字公布任何詞錯誤率或延遲數字——模型卡的評估是一張圖片，而這個串流系列目前唯一的公告，是 Microsoft 的 VibeVoice GitHub 儲存庫中一則日期為 9 月 3 日的新聞。下方 Microsoft 方面的所有資訊，都是可從該儲存庫得知的：設定檔、模型卡，以及 Microsoft 自家的串流文件。其中還沒有任何部分經過獨立基準測試。

兩款模型一覽

• 它是什麼 — VibeVoice-ASR-Streaming-1.5B：開放檢查點、MIT 授權、可自行託管；對比 Gemini 3.5 Transcribe：託管 API、封閉權重。

• 發布 — 2026年9月2日的權重、9月3日的 repo 新聞線，對比2026年8月26日附完整發布材料的公開預覽。

• 串流型態 — 以約 2.9 秒的區塊輸出文字，並具約 0.5 秒的前瞻；工作階段狀態透過前綴快取保存，相較於 WebSocket Live 工作階段按音訊 token 計費，且每個工作階段最多 10 分鐘的音訊。

• 印刷品中的準確度 — 未以文字發布任何 WER 或延遲數據；相較之下，AA 在預錄端點上測得 2.6% 的 WER，而在 Live 端點上測得 4.0%。

• 說話者輸出 — 宣稱具備串流式的發言歸屬功能（未經驗證）；Live 端點則沒有說話者分離，也沒有逐字時間戳記。

• 熱詞 — 受支援，可透過與批次 VibeVoice-ASR 相同的上下文提示使用；Live 端點則未將其列為功能。

• 成本 — 權重費用為 $0，自行託管約需 5.6 GB；相比之下，依 Google 公布的 Token 價格，預錄端點綜合約為每小時音訊 $0.30，Live 端點則約為 $0.54。

一個代管 API 和一次低調的上傳，相隔七天

Gemini 3.5 Transcribe 是 Google 的替代級轉錄模型，以兩種產品形式提供。預錄端點透過 Interactions API 提供服務，接收完整音訊檔案，並回傳具備預期附加資訊的逐字稿。Live 端點 gemini-3.5-transcribe-live 則透過雙向 WebSocket 運作，在任務形態上與 VibeVoice-ASR-Streaming-1.5B 競爭：即時轉錄正在進行的會話。Google 以慣常機制發布了這項產品——8 月 26 日公開預覽上線、模型頁面列出定價、第三方排行榜在數日內將其納入。

微軟的串流發佈完全沒有這些。9月2日，Microsoft Hugging Face 帳號在同一分鐘內建立了兩個檢查點：VibeVoice-ASR-Streaming-7B 和 VibeVoice-ASR-Streaming-1.5B。GitHub 儲存庫的模型表格現在將 VibeVoice-ASR-Streaming 列為家族成員，其 News 區塊則刊出9月3日的公告，宣布推出「一個統一的串流 ASR 模型，能在語音送達時持續轉錄誰說了什麼，並支援自訂熱詞與10種語言」——但該公告只點名了 7B，而 1.5B 是隨之一起推出、卻未被提及的較小兄弟版本。我們在上傳一天後檢查時，兩個檢查點的下載數仍然都是零。

各端「串流」的含義

「串流」一詞隱藏了真正的設計差異。Microsoft 的預處理器設定使 VibeVoice 的節奏變得具體：音訊以 24 kHz 抵達，並被壓縮 3,200 倍，成為約 7.5 Hz 的語音 token 串流（每個 token 約 133 毫秒）。該設定接著宣告一個 22 幀的區塊及 4 幀的前瞻——每個區塊約含 2.9 秒的音訊，其中約半秒的未來音訊用於強化當前區段。模型在每個解析完成的區塊輸出一次文字，而 Microsoft 的文件指出，先前區塊的上下文會透過 KV 快取保留，因此長時間的工作階段無需從頭重新計算。算術就寫在設定中；實際的結果是，轉錄文字以約三秒的增量增長，而非以逐字的部分結果呈現。

Google 的 Live endpoint 是另一種不同的串流形式：一種雙向 WebSocket 會話，其中音訊以每秒 25 個音訊 token 計費，專為互動式使用而設計，但每次會話的音訊上限為 10 分鐘，而且——特別是在 Live endpoint 上——不提供說話者分離或逐字時間戳。對於任何將兩者作為即時轉錄引擎來比較的人來說，重要的差異在於會話上限（Google Live 側為 10 分鐘，Microsoft 側僅受您自己的 GPU 和記憶體限制）、輸出節奏（約 3 秒的區塊，對比 WebSocket 會話所傳送的內容），以及額外的輸出功能（Microsoft 規格中所宣稱的說話者歸屬和熱詞，在 Google Live 的功能清單中付之闕如）。

準確度：一側是數字，另一側是圖片。

這是該對比中差距最大的部分，而這是一個證據上的差距，未必是品質上的差距。Artificial Analysis 測得 Gemini 3.5 Transcribe 在預錄端點的文字錯誤率為 2.6%，在 Live 端點則為 4.0%——你為即時傳輸付出的溢價反映在錯誤率上，這是串流系統常見且誠實的取捨。這些是第三方在中立排行榜上發布的數據，於產品上市數日後公布。

VibeVoice-ASR-Streaming-1.5B 在任何地方都沒有可相比的數據。模型卡只以圖片形式附上了一張評估結果圖，卻沒有在文字中提供任何數值的 WER、RTF 或延遲數據——沒有可引用的內容，也沒有可獨立查證的內容。無論是 7B 還是 1.5B，微軟都沒有在文字中列出串流模型的準確度數字。整個系列中唯一的數值錨點，是批次（非串流）VibeVoice-ASR 模型卡，其中記載了由廠商自行執行的平均 7.77% WER（橫跨八個英文測試集），以及 LibriSpeech clean 上的 2.20%——但這描述的是非串流模型，而串流模型通常會以些許準確度換取延遲上的優勢。在有人將串流 checkpoint 放到公開測試框架上跑出結果之前，最誠實的立場是：Google 的模型有經過量測，而微軟的沒有。

成本：每音訊小時對比每GPU小時

Google 以 token 計費銷售 Gemini 3.5 Transcribe，且定價清楚地區分兩個端點。預錄端點列出的價格是每 100 萬音訊輸入 token 2 美元，每 100 萬文字輸出 token 12 美元，換算下來每音訊小時綜合約 0.30 美元。Live 端點列出的價格是每 100 萬音訊 token 3.50 美元，每 100 萬文字 token 21 美元——每音訊小時綜合約 0.54 美元，比預錄端點貴約 80%，這就是即時傳輸的價格。Google 以每秒 25 個音訊 token 計費，因此只有在你的用戶端不串流傳送靜音時，靜音才免費；重新連線、重複的音訊以及記錄都可能讓實際帳單增加。另有免費方案，但要注意免費方案的內容可能被用於改善 Google 產品。

微軟的模型改以 GPU 時數計價。1.5B 檢查點約含 5.6 GB 的 bf16 權重（一個 1.5B 級 Qwen 語言骨幹，加上音訊 tokenizer 與擴散頭——safetensors 元資料合計約 30 億個參數），而文件記載的執行途徑都是自架：microsoft/VibeVoice 儲存庫中的 Python 示範，或是微軟所述、用於提供 OpenAI 相容與 WebSocket 端點的 vLLM 外掛。目前還沒有託管價格，因為尚無任何推論供應商列出此模型。成本問題完全在於你自有的 GPU 時間是否比 Google 的每小時費率更便宜——對任何持續性的轉錄量來說，幾乎可以肯定確實如此；而授權問題與成本問題是分開的，因為 MIT 權重可以讓你永久保有，這是任何 API 訂閱都辦不到的。

在生產技術棧中，這兩者並不互斥。對於今天就需要即時轉錄的團隊，務實的模式是讓 ASR 層保持於單一端點之後，使選擇維持可逆：一個以供應商列表價格接入 200+ 模型的路由 API——不加價，因此供應商價格變動當日即生效——並具自動容錯移轉，正是這樣的一層讓你能以 Google 的計量 API 作為預設，同時在供應商託管 VibeVoice-ASR-Streaming-1.5B 的那一刻，以一部分真實流量對其進行測試。這就是 OrcaRouter 的模式，也是採納一個準確度尚無人驗證之檢查點的低風險途徑。

該由誰來選擇哪一個

若你想要一個現今即可使用的轉錄 API，具備已公開的準確度、可預期的每小時計價，而且不需費心看管 GPU——尤其是當你的音訊不屬於 Microsoft 所列出之十種語言，或者你需要預錄端點的說話者分離與字詞層級時間戳記來進行檔案轉錄時，請選擇 Gemini 3.5 Transcribe。10 分鐘的 Live 工作階段上限是一項實際的限制，在將其投入即時工作階段之前，應先針對你的使用情境進行測試。

如果你要自行部署、想要 MIT 授權提供的權重與資料掌控權、需要無上限的工作階段長度，或是「誰說了什麼」的串流輸出與熱詞是你特別想評估的功能，那就選 VibeVoice-ASR-Streaming-1.5B。請預留從原始碼安裝的預算、NVIDIA GPU 上約 5.6 GB 的權重，以及你自己的評估關卡——沒有基準可依賴，所以準確度的問題必須由你用自己的音訊來回答。

一週 verdict 出爐：Google 推出的是有數據背書的穩健產品，而 Microsoft 押注的則是更有想像空間的實驗。Gemini 3.5 Transcribe 是更安全、且有第三方數據支撐的預設選擇；VibeVoice-ASR-Streaming-1.5B 則是開放原始碼、可自行託管、但完全未經驗證的另一條路。這個選擇之所以成本低廉，是因為它不必是永久性的——只要讓 ASR endpoint 保持可替換，就算一個 checkpoint 連一項 benchmark 都沒跑過，也能憑你自己 transcripts 的實際證據，贏得或失去你的流量。