VibeVoice-ASR-Streaming-7B 對比 Whisper Large v3 Turbo：微軟的串流檢查點為開放權重預設增添了什麼

在過去兩年的大部分時間裡，「低成本自行轉錄」這道問題的答案，一直是 Whisper Large v3 Turbo——OpenAI 的 8.09 億參數開放權重模型：MIT 授權、支援 99 種語言、小到能在工作站上跑，而且只要你已經擁有硬體，它就完全免費。2026 年 9 月 2 日，Microsoft Research 上傳了一個挑戰這個預設選項的新選擇：VibeVoice-ASR-Streaming-7B。這是 Hugging Face 上一個 MIT 授權的串流檢查點，會在音訊送達時邊收邊轉錄，並宣稱輸出帶有說話者標記；而且——不同於大多數團隊目前正在跑的模型——它從來就不是被設計來當批次作業用的。兩者都是大型實驗室釋出的開放權重模型。除此之外，兩者之間幾乎每一項差異都是取捨，而這個頁面要講的，就是你實際上正在做哪一種取捨。

有一項不對稱性形塑了整個比較，因此先談它。Whisper Large v3 Turbo 是世界上被獨立重現最多次的語音模型：多年來，數千個團隊已在公開基準測試與自己的音訊上重新執行過它的字錯誤率數字，其弱點與優點一樣都有充分的文件紀錄。VibeVoice-ASR-Streaming-7B 才剛推出一天，在各地都沒有獨立的基準測試；微軟也未以可讀文字發布串流字錯誤率。下方所有與微軟相關的內容，都出自該儲存庫——包含 config、模型卡與微軟的串流文件——並會如此標示。

開放權重的預設地位，以及它為何歷久不衰

Whisper Large v3 Turbo 是 Whisper Large v3 的蒸餾姊妹模型：它保留 32 層編碼器，並將解碼器從 32 層縮減為 4 層，因此參數量降到 809M，在 GPU 上的吞吐量大約為原先的四倍，同時準確度仍維持接近。由於其權重以 MIT 授權釋出，且模型體積小，它成了會議機器人、字幕工具與通話記錄管線的預設嵌入式轉錄引擎。它的限制也同樣眾所周知。它是批次模型——接收音訊檔案後回傳逐字稿，而非在語音說出時即時產生文字。它未針對翻譯進行訓練，該任務的表現會嚴重衰退。它對吵雜、帶口音或重疊語音的辨識準確度並不穩定，而且輸出為純文字：預設沒有標點符號或大小寫、無說話者分離、此變體無時間戳記、也無關鍵字偏置。建立在 Whisper 之上的生產技術棧會分別組裝這些部分，各自增加延遲與故障模式。

規格差距

• 參數 — 809M（蒸餾解碼器）對比總計約 9B（Qwen2-7B 語言主幹加上語音編碼器；「7B」指的是 LLM 的參數量，Hugging Face 頁面列出的是 9B）。

• 授權 — MIT，開放權重，兩者皆是。

• 串流 — 設計上即為批次：自架串流實作的延遲通常落在 1–5 秒，反觀串流原生：約 2.9 秒的區塊，約 0.5 秒的前瞻，文字逐區塊輸出，上下文保存在 KV 快取中。

• 語言 — 社群多年來重製出 99 種語言，而官方公布僅 10 種（en、zh、es、pt、de、ja、ko、fr、ru、it）。

• 在轉錄稿之外 — 預設沒有，對比宣稱的串流「誰說了什麼」輸出與自訂熱詞（未經驗證）。

• 書面標稱的精確度 — LibriSpeech test-clean 上 WER 為 2.1%，test-other 上為 4.2%，Open ASR 綜合基準約為 7.7%，社群測試中的嘈雜音訊則為 8–12%；上述結果均經獨立重現，然而串流 WER 尚無以文字公布的數據。

• 佔用資源 — 可在筆記型電腦或單張中等 GPU 上運行；相比之下，bf16 權重約需 18 GB（尚未計入 KV cache），因此請以 24 GB 級別的 GPU 作為預算基準。

串流實際上添加了什麼

之所以要把目光越過 Whisper Large v3 Turbo，唯一理由就是即時這條賽道——正是在這裡，兩個模型不再具有可比性。Whisper 是批次導向的：若要在一段話還在講的當下就取得文字，團隊得自行拼湊區塊切割、語音活動偵測與黏合程式碼；而自行架設的串流實作，延遲通常落在 1 到 5 秒——若沒有紮實的工程投入，便達不到電話客服代理與即時字幕所需的亞秒級門檻。VibeVoice-ASR-Streaming-7B 正是為這條賽道而打造。其設定顯示，音訊被壓縮 3,200 倍，變成每秒 7.5 幀的 token 串流；處理時以 22 幀為一個區塊，並帶有 4 幀的前瞻，每個區塊約涵蓋 2.9 秒的音訊——每當區塊解析完成便輸出文字，而先前的上下文則由 KV 快取承接，因此整個工作階段不需要從頭重新計算。這個節奏是源自設定的設計特性，並非實測延遲；目前也還沒有人公布它的端到端數據。但這套架構毫無疑問是即時轉錄架構，而 Whisper 則不是。

Whisper 的紀錄既長且公開；新檢查點的紀錄則是空白。

在準確度方面，Whisper Large v3 Turbo 的「年資」反而是項資產。它在 LibriSpeech test-clean 上的 WER 為 2.1%，在 test-other 上為 4.2%，這些都是開放權重數據，且已被無數團隊重現；其在 Open ASR 排行榜綜合指標約 7.7% 的成績，落後完整版 Large v3 約一個百分點；而社群測試中記載其在嘈雜音訊上 8–12% 的錯誤率，也讓所有人對此毫不意外。這些弱點都記錄在案——它們讓你在以它為基礎進行開發之前，就能確切知道模型在哪些地方需要協助。

VibeVoice-ASR-Streaming-7B 完全沒有這類紀錄。其模型卡以圖片形式附上評估數據，微軟的串流技術報告則是一份 PDF，但沒有任何可供引用的散文式串流詞錯誤率。該系列中唯一的數值錨點，來自批次版 VibeVoice-ASR 模型卡上廠商回報的表格——在八個英語測試集上平均 WER 為 7.77%，LibriSpeech clean 上為 2.20%——但這並非此檢查點的數據，而且批次模型在社群間的反響好壞參半：有人稱讚其開箱即用的語者分離功能，也有人批評它過於笨重且偶爾容易產生幻覺。這些都無法轉移到串流模型上，而這正是關鍵所在：使用 Whisper 時，你事先就知道失敗模式；使用 VibeVoice-ASR-Streaming-7B 時，你就是第一個測試者。

語言數量與模型大小：99 對 10，0.8B 對 9B

轉換成本中最具體的兩項是語言與模型規模。Whisper Large v3 Turbo 可轉錄 99 種語言；低資源語言與聲調語言的效果會打折扣——泰語、粵語和威爾斯語是常被提到的弱項——但這份語言清單背後有多年社群實作驗證。VibeVoice-ASR-Streaming-7B 則宣稱支援十種語言：英語、中文、西班牙語、葡萄牙語、德語、日語、韓語、法語、俄語與義大利語。如果你的流量落在這十種語言之內，覆蓋率完全不是問題；若否，比較到此為止。規模是第二項成本：8.09 億個參數可以在筆電上運行，而約 90 億個總參數在 bf16 格式下，意味著光權重就約佔 18 GB，還需要一張 24 GB 等級的 GPU 才能流暢服務。對於已經在精簡硬體上運行 Whisper 的團隊來說，這在基礎設施上是一大躍升，唯有真正的即時轉錄需求才能合理化這項投入。

當免費不是重點

Whisper Large v3 Turbo {{1}}可免費運行{{/1}}；成本在於圍繞它所需要投入的硬體與工程。以 GPU 的市場行情費率計算，在單張 T4 上部署 faster-whisper，每小時音訊的處理成本約為 0.05–0.10 美元；若要持續處理工作負載，還得加上你必須自行打造的說話人區分（diarization）與標點符號整合層，因為 Whisper 只回傳純文字。VibeVoice-ASR-Streaming-7B 同樣{{2}}可免費運行{{/2}}，但需要更昂貴的硬體，換取的是串流架構——它聲稱具備 Whisper 欠缺的說話人歸屬與上下文控制能力；而既然沒有獨立的評測基準，這些宣稱都得由你自己來驗證。就大量批次轉錄而言，Whisper 的吞吐量與極小佔用空間依然勝出。至於需要即時轉錄、且對話期間就必須產出逐字稿的現場多說話人音訊，Whisper 是逆著它的設計初衷在運作，而這個串流檢查點才是順著需求走——前提是它真的能運作，而這正是你應該用自己的音訊、在自己的 GPU 上回答的問題。

務實的技術棧

最常見的真實世界答案不是「二選一」，而是「兩者並行」，而這也正是這裡的建議：保留 Whisper Large v3 Turbo 作為高吞吐量的批次處理通道，因為它的實績與資源佔用使其在此難以被超越；同時在 Whisper 無法以所需延遲服務的即時通路上評估 VibeVoice-ASR-Streaming-7B——並設下明確的評估門檻，因為目前沒有可供依賴的基準。兩者可共享同一個 GPU 預算與同一套程式碼庫。在這套架構中，路由層真正值得存在的位置，是轉錄文本之上的那一層，而非轉錄本身：OrcaRouter 現階段並不處理語音轉文字的路由，這兩個模型也都不在它的目錄中；但那些消費即時轉錄文本的摘要器、警示規則與代理規劃器，正是它以單一 API 對接、按供應商牌價原價轉傳且不加價、並具備跨供應商自動容錯移轉的 200 多個語言模型。一個未附任何基準測試即出廠的串流檢查點，理應獲得與任何未經驗證模型相同的待遇——在備援後方承接一小部分真實流量，以你自己會議中的實際證據，而非一張模型卡，來贏得或失去你的信任。