VibeVoice-ASR-Streaming-1.5B，解析：微軟的串流式 ASR 未經正式發布即悄然登場

2026年9月2日，Microsoft Research 在沒有新聞稿、沒有部落格文章、也沒有任何宣傳聲勢的情況下，將兩個新的語音轉文字檢查點上傳到 Hugging Face：microsoft/VibeVoice-ASR-Streaming-1.5B以及其規模更大的同系列模型microsoft/VibeVoice-ASR-Streaming-7B。目前唯一的公告是2026年9月3日在 Microsoft 的開源 VibeVoice GitHub 儲存庫之新聞區塊中發布的一則消息，將該發布描述為一個統一的串流式 ASR 模型，能在音訊仍持續送達的同時轉錄出說話者是誰及說話內容，並支援自訂熱詞與十種語言。兩個檢查點都採用 MIT 授權，也都由官方 microsoft Hugging Face 帳號在約五分鐘內接連建立；我們一天後查看時，兩者的下載次數皆為零。我們找不到任何第三方對其中任何一個的報導。

這使得這篇文章與眾不同：一個真實、可確定日期的發布——Hugging Face 上的權重日期為9月2日，儲存庫內的公告日期為9月3日——而外界尚未得知。以下所有可知的內容都來自閱讀儲存庫：設定檔、模型卡，以及微軟自家的串流文件。尚未確認的事項——準確度、實際延遲、串流說話者歸屬是否能經得起真實雙人通話的考驗——都已如實標示。目前沒有可供引用的基準，因為微軟尚未以文字形式發布任何基準。

唯一的公告是一則新聞快訊

VibeVoice 是 Microsoft Research 旗下採用 MIT 授權的開放原始碼語音模型系列。其最知名的 ASR 成員，microsoft/VibeVoice-ASR，於 2026 年 1 月 21 日推出：它屬於批次模型，可單次處理最多六十分鐘的音訊，並回傳含說話者、時間與內容的結構化逐字稿；此後 Hugging Face 下載量約達 700,000 次。同年 9 月 2 日，同一組織發布了串流版姊妹模型 microsoft/VibeVoice-ASR-Streaming-7B 與 microsoft/VibeVoice-ASR-Streaming-1.5B；Hugging Face 的 API 將 7B 版的時間戳記為 2026-09-02T15:46 UTC，1.5B 版則在五分鐘後的 15:51 UTC。GitHub 儲存庫的模型表格現已將 VibeVoice-ASR-Streaming 列為獨立條目，其 News 區塊也載有 9 月 3 日宣布此事的訊息。

真正與一月版本不同之處在於互動模型：串流檢查點會隨音訊到達即時轉錄，而非等待完整檔案。其餘部分——底層語音 Token 架構、說話者歸屬輸出、熱詞機制——都是批次設計的延續，經擴展後重新指向即時使用場景。請先注意語言支援的差異：批次模型標榜支援 50 多種語言，而串流模型規格僅列出十種。

此檢查點中的「串流」是什麼意思？

Microsoft 的串流文件明確說明了其意圖：模型在音訊仍在送達時進行轉錄，並在每個音訊區塊送達時輸出一次文字，因此轉錄稿會隨著講者說話即時出現。1.5B 儲存庫中的 preprocessor_config.json 讓此節奏具體化：

• 取樣率與 token 率 — 輸入 24 kHz 音訊，壓縮 3,200 倍，產生約 7.5 Hz 的語音 token 串流（約每 133 毫秒一個 token）。

• 區塊 — 22 幀，以 7.5 Hz 計算，每個輸出片段約為 2.9 秒的音訊。

• 前瞻 — 4 幀，約 0.5 秒的未來音訊，用於鞏固目前區段。

（從 repo 的運算很直接：22 × 3,200 = 70,400 個樣本 ≈ 2.93 秒（在 24 kHz 下）；4 × 3,200 = 12,800 個樣本 ≈ 0.53 秒。Microsoft 自己的文件指出，檢查點一律以其訓練時的 chunk 大小執行，因此這些在推論時無法調整。）

這使其屬於分塊串流（chunked-streaming）的範疇，而非逐字串流：即時轉錄內容約以三秒為一個區間增長，並帶有約半秒的前瞻，而不是以逐詞元的部分結果呈現。這種設計對會議與通話轉錄來說既合理又常見，但其延遲特性與會輸出亞秒級部分結果的系統不同——因此，請把「串流」視為一個連續頻譜，在基於此打造即時字幕產品前，先依據你自己的延遲預算加以衡量。

深入解析：Qwen 規模的語音 LLM

閱讀 1.5B checkpoint 的 config.json，會得到如今已相當熟悉的 VibeVoice 配方，只是規模較小：

• 解碼器是 Qwen2 家族語言模型，其維度與 1.5B Qwen2.5 等級完全一致：28 層、1,536 個隱藏單元、12 個注意力頭（含 2 個鍵值頭），以及 65,536 個 token 的上下文視窗。正是這個 LLM 讓模型得以在整份轉錄稿中持續掌握對說話者與內容的理解。

• 聲學與語義 tokenizer——具備 8/5/5/4/2/2 步幅的深度卷積編碼器——將 24 kHz 音訊轉換為解碼器讀取的約 7.5 Hz 語音 token 串流。

• 生成端採用擴散頭（DDPM、20 步去噪、v-prediction），與 VibeVoice 產品線的其餘部分保持一致。

• 大小誠實性：該 checkpoint 自身的 safetensors 中繼資料列出約 30 億個參數，權重約 5.6 GB。名稱中的「1.5B」指的是語言主幹的規模——這是對配置的自然解讀，其解碼器是 1.5B 級別的 Qwen 模型——其餘部分則由音訊 tokenizer 與擴散頭（diffusion head）構成。配置中的架構字串 VibeVoiceForASRStreamingTraining 表明這是一個研究系列（research-family）的 checkpoint。

誰說了什麼，以十種語言

此模型卡的主打能力是串流式、可歸屬發言者的轉錄：據模型卡本身的條列說明，它能「在語音抵達時持續轉錄誰說了什麼」。此外它也宣稱支援為領域術語自訂熱詞，並列出十種支援語言——中文、英文、法文、德文、義大利文、日文、韓文、葡萄牙文、俄文和西班牙文。

熱詞是透過批次模型所使用的同一種上下文偏置機制實作的。在 Microsoft 的命令列示範中，你可以將它們當作上下文資訊傳入——例如 --context_info "Microsoft,VibeVoice"——以便在不做任何微調的情況下，讓辨識結果偏向人名與技術詞彙。至於串流模型，卡片上完全沒有提到語言自動偵測或語碼轉換，這是相較於批次模型所宣稱內容的另一項落差。

有一點需要強調：串流文件頁面著重於分塊輸出與熱詞，但未詳細說明說話者歸屬如何在分塊邊界之間維持。串流說話者分離確實困難——說話者會重疊，而分塊邊界正是歸屬偏移的關鍵點。卡片上「誰說了什麼」的框架只是供應商的宣稱，除非有人用真實的雙人即時通話跑過一遍並加以驗證。

定位：VibeVoice 家族与 2026 年流式自动语音识别领域

在家族中，此版本的定位如下：

• microsoft/VibeVoice-ASR（2026年1月21日）— 批次處理旗艦：單次處理可達60分鐘，支援50多種語言，輸出「人物/時間/內容」資訊，支援熱詞，約70萬次下載。

• microsoft/VibeVoice-ASR-Streaming-7B 與 microsoft/VibeVoice-ASR-Streaming-1.5B（2026年9月2日）——新的串流變體；本文的主題是 1.5B。

• microsoft/VibeVoice-ASR-BitNet（2026年7月23日）— 適用於批次模型的量化、以CPU為導向的邊緣引擎。

VibeVoice-1.5B TTS 與 VibeVoice-Realtime-0.5B streaming-TTS 模型是同一系列中的兩個獨立成員，不屬於 ASR 產品線。

開放權重 ASR 領域這一整年來持續朝向即時處理發展，因此新的串流模型一推出便有直接的比較基準。Qwen3-ASR（阿里巴巴，約 1.7B）是統一的串流與離線模型，涵蓋 50 多種語言與方言。NVIDIA 的 Nemotron 3.5 ASR 是 0.6B 的串流模型，支援 40 種語言，採用 OpenMDW 授權而非 MIT。IBM 的 Granite Speech 5.0 470M TurboCTC 使用 Apache-2.0，廠商公布的吞吐量數字異常地高。相比之下，Microsoft 的串流模型在三個方面有所區隔：MIT 授權、具備說話者與內容理解能力的 LLM 主幹（而非純聲學模型），以及以說話者標註為核心的即時轉錄框架。其待解問題在於準確度與真實世界延遲——這兩者目前都還沒有獨立的測量數據。

什麼尚未被驗證？

閱讀 repo 能告訴你設計；但無法告訴你它運作得多好。具體來說：

• 內文中沒有準確度或延遲數值。模型卡以圖片形式附上結果圖，但文字敘述中並未提供包含 WER、RTF 或延遲數值的表格——沒有任何可獨立引用的數據。

• 沒有第三方評估。上傳一天後下載量仍為零；沒有社群基準測試、沒有排行榜登錄，也找不到任何獨立測試。

服務路徑是從原始碼建置的研究型設定。Microsoft 的串流文件說明是在 NVIDIA PyTorch 容器（nvcr.io/nvidia/pytorch，建議使用 flash-attention）內，從 VibeVoice GitHub 儲存庫的複本執行。模型卡也展示了 Transformers pipeline 程式碼片段，並將安裝細節交由 GitHub 處理；至於目前發布的 Transformers 版本是否能直接對這個 checkpoint 執行串流推理，我們尚未驗證。

• 定位以研究為先。Microsoft 的存放庫將 VibeVoice 模型描述為旨在供研究與開發之用。權重採用 MIT 授權；其姿態是「這是科學」，而非「這是受支援的產品」。請為你自己的評估關卡編列預算。

你應該在此基礎上發展嗎？

對於已經自行託管 ASR 的團隊，如果你的音訊落在十種語言範圍內，而且你確實需要來自 MIT 授權模型、具備說話者歸屬的即時轉錄，那麼這值得花一個週末評估。請預留約 5.6 GB 的權重（1.5B 模型）在 NVIDIA GPU 上，並從原始碼進行安裝；同時計畫在你自己的音訊上自行測量準確度，再決定是否信任它。

對於現今要推出正式生產轉錄管線的團隊，審慎的答案是等待以下三件事之一：微軟公布目前僅以圖片呈現的準確度與延遲數據；出現獨立的基準測試；或出現具有受支援執行環境且持續維護的服務路徑。此外，分塊的約 3 秒節奏也是一個規格，應對照你的延遲需求進行合理性檢查，而非從「streaming」一詞直接推斷。

保持選項開放的廉價方式，是避免將應用程式硬綁定到單一轉錄引擎。透由一個 API 前端串接多個模型的路由層，意味著當 VibeVoice-ASR-Streaming——或下一個開放 ASR——出現在推論供應商上時，在同一流量上對它與現有引擎進行 A/B 測試，只是組態變更，而非重新打造平台。由於透傳路由會以供應商定價收費、不加價，這樣的比較成本依然低廉，而自動故障轉移也能讓一個新穎、未經驗證的模型，不會成為管線中的單點故障。這是採納任何剛出爐模型的通用模式：讓它先在真實流量上證明自己的價值，再將生產環境押注在它身上。

常見問題

VibeVoice-ASR-Streaming-1.5B 真的是 Microsoft 發布的產品嗎？

是的。該檢查點位於微軟官方的 Hugging Face 帳號上，建立時間戳記為 2026 年 9 月 2 日；microsoft/VibeVoice GitHub 儲存庫也在其模型表中引用了 VibeVoice-ASR-Streaming，並有一則日期為 2026 年 9 月 3 日的新聞條目。不尋常的並非來源，而是那份沉默：截至本文撰寫為止，沒有新聞稿、沒有部落格文章，也沒有任何第三方報導。

為什麼有兩種尺寸，7B 和 1.5B？

Microsoft 在同一分鐘內上傳了兩個檢查點，但尚未發布比較結果。從配置來看，1.5B 是較小的一端——一個 1.5B 等級的 Qwen 語言主幹加上音訊堆疊，約有 3B 參數和約 5.6 GB 的權重。自然的解讀是：7B 準確度較高，而 1.5B 更便宜、更快，但 Microsoft 並未如此說明，也沒有基準測試可以證實這項取捨。

這與先前的VibeVoice-ASR有何不同？

一月份的批次模型單次處理即可吸收長達 60 分鐘的音訊，並標榜支援 50 多種語言。串流檢查點會在音訊送達時同步轉錄，以約 3 秒的區塊輸出轉錄文字，並具備約 0.5 秒的前瞻時間，模型卡上則列出十種語言。兩者共用相同的語音 token 架構、說話者歸屬輸出概念，以及熱詞機制。

目前，VibeVoice-ASR-Streaming-1.5B 是一個檢查點加一條新聞。若你自行託管且需要以寬鬆授權的串流語音辨識來評估，請閱讀該儲存庫；若你正在挑選生產引擎，則先等數據出來。值得注意的訊號是，微軟正同時以兩種規模將它的語音產品線推向即時化——而且動作如此低調，以至於一天後下載計數器仍顯示為零。