Ming-3.0-audio-tiny 對決 VibeVoice-ASR-Streaming 1.5B：五道破折號對上具講者標註的串流

打開 Ming-3.0-audio-tiny 的 Hugging Face 儲存庫中的辨識圖像，並捲動到最底部。有五列——AISHELL-4、AliMeeting 與 AMI 的語者分離（speaker diarization）與串接最小排列錯誤（concatenated minimum-permutation error）——在 tiny 欄位中標的是一道破折號。不是什麼難看的數字，而是一片空白。廠商在全部五列上都量測了它較大的同系列模型，卻拒絕量測小的那一個。現在打開 VibeVoice-ASR-Streaming 1.5B 的模型卡，讀第一條要點：它會隨著語音持續抵達，不間斷地轉錄誰說了什麼。那就是同樣的五列，只是反了過來。一個模型幾乎什麼都公布，唯獨不公布語者歸屬；另一個模型的存在，主要就是為了公布它。 像這次發布背後的種種已記錄 AI 失效與代理事件，都收集在 the OrcaRouter AI Incident Archive，其中每一筆都附有自己的來源、嚴重程度、可信度等級與爭議標記。

兩者都尚未經過獨立評分。這一點在這裡不如平常那麼重要，因為這場對決取決於設計決策，而非某個數字：當音訊從不停止地湧入時會發生什麼事。Ming-3.0-audio-tiny 是檔案模型，具有大視窗與可選的語音輸出。VibeVoice-ASR-Streaming 1.5B 是串流模型，大約每三秒輸出文字，並為每個區段標註說話者。如果你的工作負載是錄音，它們會相互競爭。如果你的工作負載是房間，只有其中一個在嘗試。

在設定中，「串流」的成本是什麼？

微軟的程式碼庫對自身延遲預算的說明異常清楚，使這項權衡可以被檢驗，而不是行銷話術。聲學與語意 tokenizer 都是因果式的，並對 24 kHz 輸入以 3,200 倍壓縮運行，因此 token 串流約為每秒音訊 7.5 個 token。串流封裝器每個區塊批次處理 22 個 token 幀，並有 4 幀的前瞻：22 除以 7.5 約為每次輸出 2.9 秒，而 4 除以 7.5 約為半秒的未來音訊，是模型在定案前被允許看到的量。

• 發射節奏 —— 約 2.9 秒；前瞻緩衝的部分正是以延遲換取準確度的地方。

• 主幹 — Qwen2 系列解碼器，28 層、1,536 維隱藏層、12 個注意力頭（其中 2 個為鍵值頭），64,000 個 token 的視窗。

• 大小——三個 safetensors 分片，總計 5.63 GB。那不是 1.5B 參數；以 bf16 計算，5.63 GB 換算下來更接近 28 億，而名稱中的 1.5B 最好理解為語言主幹，而非整個堆疊。

• 語言 — 十種：中文、英文、法文、德文、義大利文、日文、韓文、葡萄牙文、俄文、西班牙文。

• 額外項目 — 作為上下文傳入的自訂熱詞，以及附加在每個輸出片段上的講者標籤。

• 日期 — 儲存庫建立於 2026 年 9 月 2 日 15:51 UTC，並於隔天早上最後修改。僅透過 VibeVoice GitHub README 中的一則消息公告，也就是說幾乎沒有正式公告。

那個 64K 視窗，是要拿來對照 Ming 的 131,072 的數字。聽起來像是容量的一半，但並不是同一種容量。串流模型不需要容納一小時，因為它已經把過去五十九分鐘寫下來了。視窗是當前區塊的工作記憶，加上模型向前攜帶的任何對話上下文。Ming 的 131K 則是相反的賭注：讓所有內容保持即時可用，並對其進行推理。

Ming 的賭注，以及它能換來什麼

這款微型模型的賣點不是辨識準確度——在 inclusionAI 自家的表格上，它在中文上落後較大的同系列模型 0.34 點（字元錯誤率 3.79 對 3.45），在方言上落後 0.89 點（10.29 對 9.40）。它的賣點在於：同一個檢查點能在同一次前向傳遞中完成辨識、理解、推理與語音處理，而且涵蓋的視窗長到足以讓你問出「她在前十分鐘說了什麼？」

它的音訊智慧分數以這樣的規模來說相當可觀，也是它勝過純轉錄器的理由：MMAU 75.90、MMAR 67.70、MMSU 73.06、BigBenchAudio 99.20，音樂方面則是 MuchoMusic 58.07。這些全都是廠商自行執行，自我評估的列上帶有星號，而規格卡也揭露比較模型是在 inclusionAI 自己的提示與解碼設定下重現的。把它們當成設計綱要來讀。

表格不會告訴你的是誰在說話。那正是五個破折號所標出的缺口，而且是結構性的，不是偶然。一個能回答關於某段錄音問題的模型，不需要逐說話者分段就能回答；一個要為會議產出逐字稿的模型則需要。Ming 大概可以透過提示做到類似說話者標註的事，而卡片上關於「multi-speaker recordings」的亮點暗示它訓練時接近過這個問題。但「大概」正在代替五列未公開的資料列發揮作用。

兩條管線，如實繪製

想像同一段九十分鐘的錄音分別經過每一個。

使用 VibeVoice-ASR-Streaming 1.5B 時，音訊會以約三秒的區塊抵達，文字也以相同節奏輸出，每個片段都帶有說話者。你可以即時顯示。代價是每個決策都偏向局部：模型只預先看到半秒，再加上它保留的任何上下文，因此停頓四秒的說話者重新出現時，可能被標記成不同的人；而第兩分鐘引入的名字，只能透過你提供的熱詞機制找回。跨區塊一致性是要測試的重點，也是模型卡沒有量化的部分。

使用 Ming-3.0-audio-tiny 時，檔案會送達，整份內容都進入上下文，而答案會在它送達時出現。跨區塊一致性不會有風險，因為根本沒有區塊——只要不超出視窗。代價是在模型完成之前什麼都拿不到，而且記憶體保留量是按完整視窗配置的：參考 ASR 設定檔在 32,768 個 token 的批次下佔用 0.92 張卡。你可以調低 max_model_len；但無法讓它串流，因為儲存庫中沒有串流路徑。

• 延遲形態 — VibeVoice：連續輸出，落後約 3 秒。Ming：最後才給出一個答案。

• 署名 — VibeVoice：依設計逐段標註。Ming：未公開。

• 背景 — VibeVoice：64K 工作窗口，外加它自己的轉錄文本。Ming：131,072 個位置，若處理器饋入單一連續串流，依編碼器推算約為三小時的音訊。

• 輸出 — VibeVoice：文字。Ming：文字，或文字加上透過第二張 GPU 上選配的 Talker 所合成的語音。

• 硬體 — VibeVoice：5.63 GB 的檢查點，因此只需一張一般市售顯卡。Ming：17.74 GB 的 Thinker，文字用一張卡，語音用兩張卡。

執照和文書資料是一樣的，這很不尋常。

兩者皆為 MIT 授權。兩者都是低調發布。兩者都在文件跟上之前就先釋出權重，而且都依賴一個並非以該檢查點命名的 GitHub 儲存庫：Ming 的部署設定檔位於 inclusionAI/Ming-3.0-audio-flash，而 VibeVoice 的使用說明則位於 microsoft/VibeVoice，與同系列的 7B 版本並列於同一處。

差異在於各儲存庫告訴你的內容。Microsoft 提供一份技術報告——arXiv 2609.02812——以及模型卡中的結果圖，而該圖是圖像而非表格，因此數字無法擷取，文中也未列出各語言的錯誤率。inclusionAI 則提供三張基準測試圖像——同樣是圖像——外加一張模型卡，僅透過留空儲存格來隱含指出自身弱點。兩家廠商都沒有提供可直接貼入試算表的數字，除非你手動轉錄。

有一點不對稱值得負責採購的人留意：Ming 的 Hugging Face 儲存庫裡沒有 LICENSE 檔案，只有卡片中繼資料裡一個指向另一個儲存庫授權條款的連結。VibeVoice 的卡片在中繼資料中標明 MIT，而該儲存庫也確實附有授權檔案。兩者的說法都成立；但只有其中一項存在於該產物之內。

路由器在這裡的用途與非用途

OrcaRouter 並不提供這兩個模型。Ming-3.0-audio-tiny 是一個檢查點，VibeVoice-ASR-Streaming 1.5B 也是一個檢查點；兩者都不在我們的目錄中，而本文任何內容都不構成託管它們的要約。在這樣的流程中，路由器位於轉錄的下游、決策的上游：摘要通話內容、擷取承諾事項、判斷該片段是否需要人工處理、翻譯非工作語言的部分。這些呼叫都是文字，而一個端點就能涵蓋 超過 200 個模型、0% 加價——供應商標價原樣傳遞，因此供應商價格一變，當天就會反映在我們這邊——讓建置流程少掉每個供應商一份合約。自動容錯移轉 正是當一項兩小時的轉錄工作必須在凌晨兩點把輸出交給可靠去處時，特別重要的功能。

路由器不會做的，是調和兩個彼此不一致的說話者標籤，或判定 Ming 缺少的說話者分離列究竟是真實的弱點，還是尚未被測量到的弱點。那得靠你自己的音訊來判斷。

能在一個下午分辨出他們的測試

錄製二十分鐘、三個人參與的內容，其中一人兩次打斷其他人說話，另一人使用筆記型電腦麥克風。用 VibeVoice-ASR-Streaming 1.5B 處理它，並將熱詞清單填入這三個名字，因為這正是該模型為此提供的機制。用同一個檔案透過 Ming-3.0-audio-tiny 執行，使用已驗證的提示詞，要求先輸出語言標籤、一個定位字元，然後是轉錄文字——接著在第二輪請它為每個句子標註發話者。

評分四件事：第一個模型正確辨識出多少次講者切換、錄音中途是否有任何講者標籤翻轉、第二個模型在整個檔案中的歸屬是否穩定，以及哪一份輸出你能更快手動修正。最後一項不是基準測試，而且會比兩家廠商的數字更能預測你的生產環境體驗。

而且做的時候，請把那些破折號放在心上。一個廠商若公布精確到小數點後兩位的方言表，卻留下五個說話者分離欄位空白，就已明確告訴你它的信心界線到哪裡為止。微軟則公布了圖形而非表格，讓你自行解讀那張圖。兩者都沒有給你一個經陌生外部人士查核過的數字。

每一項真正該歸屬的位置

即時字幕、客服中心監控，以及需要逐行標註發言者姓名的會議助理：VibeVoice-ASR-Streaming 1.5B 正是為這類情境打造，而且僅需 5.63 GB，就能在你可能早已擁有的硬體上運行。若是對檔案庫進行合規審查、「在這四十段錄音中找出所有提及和解案的地方」，或任何問題是在音訊之後才提出、而非在播放當下提出的情況：Ming-3.0-audio-tiny 的單一大型視窗與其理解分數會是更合適的選擇；而且如果沒有人問是誰說的，缺少的發言者分離列也就不再重要。

錯誤會是：因為 131,072 是 64,000 的兩倍，就為串流工作挑選 Ming；或因為 1.5B 聽起來比 9.3B 便宜，就為推理工作挑選 VibeVoice。這兩個數字所描述的，都不是那句話所假設的事物，而這正是這項比較所確立的最可靠之事。