Grok Voice Transcribe 2.0 對比 VibeVoice ASR Streaming 7B：微軟沒公布的那個數字

VibeVoice ASR Streaming 7B 是 Microsoft 的統一串流語音辨識器，於 2026 年 9 月 2 日上傳至 Hugging Face，並在隔天於 microsoft/VibeVoice 儲存庫中依 MIT 授權條款發布；它能做到 Grok Voice Transcribe 2.0 及其大多數競爭對手都做不到的事：在音訊抵達時就輸出帶有講者歸屬的文字，且不需要獨立的語者分離階段。Microsoft 的技術報告指出，這個 7B checkpoint 在五個評估集上取得最低的平均 WER 與 CER，並在 13 個評估設定中的 12 個取得最佳或並列最佳的講者歸屬。模型卡並未以文字公布任何單一數字——沒有 WER、沒有 RTF、沒有延遲數字；這些結果只以圖片形式存在於報告中。Grok Voice Transcribe 2.0 於十六天後、2026 年 9 月 18 日推出，批次處理每音訊小時收費 $0.10，串流處理每小時 $0.20，並公布一切：在 Artificial Analysis 的串流排行榜上，最終轉錄稿 WER 為 2.7%，首個部分結果 WER 為 3.4%，兩者皆為 0.49 秒。所以，這個比較誠實的起點是：這兩個模型中，有一個在可衡量意義上比另一個有更好的文件記錄，而這種不對稱本身就是這場對決中最與決策相關的事實。

Microsoft 發布了什麼，以及讀者能如何運用它

VibeVoice 的報告是真實的研究，而其中的主張在形態上是具體的，即便在數值上未必如此。它評估了四項會議基準測試——AliMeeting、AISHELL-4、AMI-SDM 與 AMI-IHM——再加上 MLC-Challenge，涵蓋九種語言，並報告了兩項主要結果：7B 模型在五組資料中的平均 WER/CER 最低，且在 13 種評估設定中有 12 種取得最佳或並列最佳的語者歸因表現。這兩者都是相對性的主張，而這是一種有意義的主張類型：「在這五組中最低」是一項關於排序的陳述，而排序正是買方所需要的。

缺席的是每一個絕對數字。沒有可與任何事物相比的 WER 百分比，沒有吞吐量數字，沒有延遲測量值，也沒有逐集細分的文字說明。一張把 VibeVoice 與 Grok Voice Transcribe 2.0 並列、並替 Microsoft 模型安上一個數字的比較表，是在凭空捏造那個數字。能說的是，VibeVoice 贏得了它自己的五集評估，而 Microsoft 以外的任何人都沒有重新跑過它——沒有獨立基準、沒有第三方評估，而且在撰寫本文時，完全沒有任何託管推論服務商列出這個模型。因此，這項比較是在一個有文件記載的數字與一個沒有文件記載的排名之間進行，而那個沒有文件記載的排名，並不會只因為它少了小數點，就成為兩者中較弱的那一個。

Grok Voice Transcribe 2.0 的文件則有相反的問題。它的 2.7% 和 3.4% 來自 Artificial Analysis 的 AA-WER Streaming 排行榜，該榜是將 AA-AgentTalk 以 50% 權重，與 VoxPopuli 和 Earnings22 各以 25% 權重加權而成的綜合指標——約八小時的代理形態英語會話音訊，由獨立機構執行，這確實是比廠商自家評估更可靠的來源。但這只是英語中一個狹窄的切片，而該排行榜頁面本身只繪出了 SpaceXAI 在宣稱於 32 個模型中奪得第一時所計入的 33 個模型當中的 27 個。在狹窄測試上的精確數字，與在更廣泛範圍上的不精確宣稱，兩者無法直接相比，本文也不會假装如此。

兩秒半對半秒

延遲比較是唯一能讓這兩個模型在不必對資料集加上任何但書的情況下並列對照的地方，因為兩者都公開其串流配置——而差異是架構性的，而非調校上的選擇。

VibeVoice ASR Streaming 7B 以區塊方式運作。其已發布的檢查點每個區塊使用 22 個潛在幀，以該模型每秒 7.5 個潛在幀計算，每個區塊約為 2.9 秒的音訊，並具有四個潛在幀的前瞻量——大約 0.5 秒的未來音訊——以及約 2.00 秒的預期說話者歸因延遲。它每個區塊輸出一次文字。那是一個真正的串流系統，但其節奏是以秒為單位，而非毫秒。

Grok Voice Transcribe 2.0 會在講者停止說話後 0.49 秒回傳第一份部分轉錄結果，並在語音結束後 0.49 秒完成最終轉錄。它是用速度換來這份準確度——首次部分轉錄的錯誤率從 1.0 版的 18.3% 降至 2.0 版的 3.4%，代價是在同一項指標上從 0.25 秒增加到 0.49 秒。

將它們並排放置：

• 串流節奏 — Grok Voice Transcribe 2.0 會持續輸出部分結果，首個部分結果的延遲為 0.49 秒，而 VibeVoice ASR Streaming 7B 則大約每 2.9 秒輸出一個文字區塊

• 說話者歸因延遲——包含在同一條 0.49 秒路徑內，相較於設計上約 2.00 秒

• 前瞻 — 未發布對比四個潛伏幀，約 0.5 秒的未來音訊

• 實際影響 — 語音代理能對仍在進行中的句子採取行動，而系統則是每三秒接收一段標註了說話者的段落

這兩者都沒有錯。對會議轉錄來說，2.9 秒的音訊區塊是完全合理的設計；在這種情境下，輸出是一份文件，而價值在於這份文件是在會議進行期間送達，而不是會議結束之後才出現。但對對話式代理而言，這是錯誤的設計；在這裡，三秒的靜默不是停頓，而是失靈。這兩種節奏之間的差距大約有六倍，而這幾乎正好對應到「轉錄一段對話」與「參與一段對話」之間的差異。

說話者歸屬作為輸出，而非管線階段

這正是 Microsoft 模型真正領先的地方，而這個設計值得理解，因為它正是分塊之所以粗略的原因。

VibeVoice 採用兩個預先訓練好的符元化器——一個聲學編碼器與一個語意編碼器——以 24 kHz 運作，並進行 3,200 倍降採樣，每秒產生 7.5 個潛在幀，也就是每 133 毫秒一個。這些幀會被投影到 Qwen2.5 語言模型主幹中，而傳入的語音與生成的文字會交錯成單一序列，先前觀察到的語音與文字則保留在模型的脈絡中。其結果是，說話者身分從來不是一個獨立的問題：模型並不是先轉錄、再判斷是誰說的，而是以仍含有聲音的音訊歷史為條件來生成文字。這正是為什麼沒有需要對齊的語者分段階段，也是為什麼 Microsoft 關於在 13 種設定中有 12 種能進行說話者歸屬的主張，在架構上是可信的，而非事後補強所得的結果。

這種設計的代價是歷史保留量會隨錄音長度線性成長，這也是為什麼已發布的檢查點只針對最長八分鐘的錄音。那是實實在在的上限，而且說得很明白。這使得該模型不適用於長篇工作——兩小時的財報電話會議、一整天的聯絡中心音訊——除非你自己建立分段與重新初始化，但這麼做正好會重新引入該架構原本就是要移除的複雜性。

Grok Voice Transcribe 2.0 以不同的方式解決同一個問題，並伴隨一組不同的限制。它免費包含語者分離（diarization）功能，並在單一請求中支援最多八個獨立音訊通道。對於聯絡中心電話語音而言，每位參與者通常各自經由自己的通道傳入，通道分離比語者分離更可靠，而且沒有附帶的錯誤率。對於混合音訊，這取決於語者分離的品質；而與 Meta 的 Muse Voice Transcribe 不同——後者公布了 17.5% 的平均語者分離錯誤率——SpaceXAI 完全沒有公布任何語者分離數據。因此，這兩款模型都在語者分離的證據上留下缺口：一個公布了排名卻沒有數值，另一個公布了功能清單卻沒有量測數據。

十八 GB、十種語言、MIT

部署層面的事實差異如此徹底，幾乎無法相提並論。VibeVoice ASR Streaming 7B 的 bf16 權重約為 18 GB——Hugging Face 頁面列出這個名為 7B 的檢查點總參數量為 9B，另有約 5.6 GB 的 1.5B 同系列模型——採用 MIT 授權，並附有 Python 示範和用於 serving 的 vLLM 外掛。十種語言：中文、英文、法文、德文、義大利文、日文、韓文、葡萄牙文、俄文和西班牙文。微軟將其定位於研究與開發用途。

Grok Voice Transcribe 2.0 是一個受管理的端點，無需下載權重，支援 12 種輸入格式，從 8 kHz 電話音訊到 48 kHz、最多八個聲道、每次請求 100 個關鍵詞、自動語言偵測並可在錄音中途切換、跨 25 種語言的反向文字正規化、檔案大小最高 500 MB，以及服務限制為每秒 10 次請求和每個團隊 100 個並行串流工作階段。它僅在 us-east-1 執行，而且只在 us-east-1。

• 權重 — MIT、18 GB，可隨處自行運行；對比：無，僅由廠商託管

• 語言 — 10 種具名語言，對比支援 25 種語言格式的自動偵測

• 關鍵詞偏置 — 透過熱詞支援，對比每個請求最多 100 個關鍵詞

• 錄製長度 — 每個檢查點約八分鐘，之後歷史記錄保留會成為限制；相對地，未公布上限，檔案可達 500 MB

• 區域控制 — 無論你部署在哪個區域，與 us-east-1 相比

• 成本 — 無需授權費，另加 18 GB GPU 記憶體與服務堆疊，相較之下為每批次小時 $0.10 及每串流小時 $0.20

18 GB 的模型不是筆電跑得動的東西，而 vLLM 外掛意味著需要具備充足記憶體的 GPU。相較之下，這種規模的模型採用 MIT 授權並不尋常且極具價值：在兩者之中，它是唯一能讓你在自家網路內執行、完全無需與供應商建立關係的選項；對受監管的音訊而言，這不是偏好，而是必要條件。代管式替代方案每小時費用低廉，卻不可能在地端部署。

路由決策應該放在哪裡

成本正是這兩個模型最終能以具體數字相互比較的地方。Grok Voice Transcribe 2.0 的批次處理路徑每音訊小時收費 0.10 美元，約合每 1,000 分鐘 1.67 美元；其串流路徑則為 0.20 美元，約合 3.33 美元。VibeVoice ASR Streaming 7B 完全沒有授權成本；取而代之的是約 18 GB 的常駐 GPU 記憶體，以及一套由你自行維運的 vLLM 服務堆疊。這種規模的 7B 級模型在租用硬體上，每小時音訊的處理成本不可能便宜，而且使用率曲線毫不留情——為了尖峰流量而保持預熱的 GPU，無論是在轉錄還是閒置，成本都一樣。

那是自建與外購之爭的典型樣貌，而它會因用量多寡，以及音訊是否獲准離開你的網路，得出不同的結論。過去一個月改變的是答案變動的速度：串流準確率的領先者在三週內兩度易主，而九月初發布的模型到了九月中就被取代。任何讓模型選擇變得難以逆轉的架構，如今都是這個類別裡錯誤的架構。

OrcaRouter 正是讓這種反轉變得廉價的地方。一組與 OpenAI 相容的金鑰就能涵蓋 200 多個模型，並可跨供應商自動容錯移轉，因此單一區域的受管端點故障只是一次路由事件，而不是服務中斷；而且供應商標價以 0% 加成原樣傳遞——這意味著供應商調價或新的檢查點，我們這邊當天就會上線。對於想用自己的音訊，拿 VibeVoice 與 Grok Voice Transcribe 2.0 對測的團隊，或是想讓自架備援方案位於與受管主要方案相同的介面之後，呼叫端就不再是那個必須改變的東西。

誠實的結論是：VibeVoice ASR Streaming 7B 是更有趣的模型，而 Grok Voice Transcribe 2.0 是更實用的產品，而這兩種說法之間的落差，完全可以由一家廠商發布圖表、另一家發布數字來解釋。如果你的需求是地端部署、對八分鐘以下的會議進行講者歸屬的轉錄，那麼 Microsoft 的檢查點是兩者中唯一符合資格的。如果你的需求是能在對話停頓內回答的語音代理，那麼 2.9 秒的區塊節奏在討論準確率之前就已將它排除。而如果你正在等待那場能一錘定音的比較——同一段音訊跑過兩個模型，並由不任職於這兩家公司的人評分——那項量測目前還不存在，這一點值得記住，下次有表格在 VibeVoice 的名字旁邊放上數字時。