VibeVoice 只開源了一半：缺失的那一半才是教訓

微軟的 VibeVoice 儲存庫掛著 MIT 授權、約 55,000 顆星，以及一段讀起來像承諾的描述：開源前沿語音 AI。但它真正裝著的，是一堂關於當模型強大到令人擔憂時，「開源」究竟意味著什麼的課。

這個故事有兩個走向。一個方向上，儲存庫持續成長，留下來的部分確實有用。另一個方向上，最強大的那塊消失了。2025 年 9 月，微軟在發現有人以該公司所稱、與專案初衷不符的方式使用後，從儲存庫移除了 VibeVoice-TTS 的推論程式碼。該模型的權重仍在 Hugging Face 上。能執行它們的程式碼卻不在。今天想要那個特定模型的人，只能靠自己。

這個決定形塑了 2026 年這個儲存庫被使用的一切方式，而且它比任何基準測試都更具啟發性。

實際上裝了什麼

如今的主角是 VibeVoice-ASR，一個 70 億參數的語音辨識模型，能在單次處理中轉錄長達 60 分鐘的音訊。它不只是把字寫下來。它會回傳誰說了話、何時說的、說了些什麼，產出帶有講者標籤與時間戳記的結構化輸出。它能處理超過 50 種語言，無須設定語言旗標，並且接受自訂熱詞，所以你可以把預期會出現的姓名和技術術語交給它，讓它不再把它們寫錯。

圍繞這個核心的是幾個精簡變體。有一個串流 ASR 版本，在音訊還在傳入時就逐塊輸出文字，當你等不及完整錄音時很有用。有一個 BitNet 版本，完全不需要 GPU、可只在 CPU 上執行，壓縮到約 1.58GB，對這個規模的模型來說相當驚人。還有 VibeVoice-Realtime-0.5B，一個小型串流文字轉語音模型，大約 200 到 300 毫秒就能產生第一段音訊，內建預設語音，而且值得注意的是，不支援語音複製。

7.5 Hz 的訣竅

把這個家族繫在一起的技術構想，是一個以異常低幀率運作的語音分詞器：每秒 7.5 幀。大多數語音分詞器的運作頻率是 50 Hz 或更高。較低的頻率之所以重要，是因為它能在同一個上下文視窗中塞進多得多的音訊。這正是單次處理就能涵蓋整整一小時對話的原因，因為每秒的 token 越少，模型的記憶體就能容納越多秒的音訊。

低幀率通常會犧牲保真度，VibeVoice 用兩階段設計來處理這個問題。語言模型負責語意，決定說了什麼、是誰在說；擴散頭則生成細緻的聲學細節。分詞器只需保留足夠的音訊品質，讓擴散頭能發揮它的作用。這是乾淨俐落的分工，也是這個模型能同時兼顧長視窗與細節的原因。

你能打造什麼、不能打造什麼

對任何處理語音的人來說，VibeVoice 可用的那一半相當可觀。帶有講者標籤的會議轉錄、播客的講者分離、需要知道誰在何時說了什麼的訪談流程、即時應用的串流辨識，以及能在普通硬體上執行的輕量助理語音：這些如今全都觸手可及。尤其是 CPU 版本，為在沒有獨立 GPU 的機器上執行辨識開啟了大門，這對成本以及在 GPU 稀缺地區的部署都有影響。

不可用的那一半，正是讓 VibeVoice 聲名大噪的部分。最初的 VibeVoice-TTS 能合成長達 90 分鐘的語音，最多可有四個不同的講者，這是貨真價實的研究進展，獲 ICLR 2026 接受為口頭論文。而那項能力，正是你今天無法從儲存庫執行的部分。那個聲名遠播的版本，實際上就是被撤下的版本。

開源是一道光譜

VibeVoice 這個案例，讓業界愛說的那套簡潔敘事變得複雜。一邊是被稱為開放的模型，意思是權重可以下載。另一邊是被稱為封閉的模型。VibeVoice 卡在中間。權重是開放的，授權是寬鬆的，而真正要用上最有潛力的那個模型所需的程式碼卻不見了。只發布權重而不發布推論程式碼是一條中間路線，而隨著風險升高，這或許會是更多強大模型的落腳處。

實際上也有些麻煩的細節。這個儲存庫自稱是研究框架而非完成品，所以期待應該相應調整。你無法從 PyPI 安裝那個名稱下的官方 Python 套件，而共用同名的套件並不是微軟的專案。微軟也建議這些模型僅供研究，未經進一步測試不建議商業使用，儘管授權本身相當寬鬆，這種落差正是那種會讓只讀授權、跳過 README 的團隊大吃一驚的情況。

這些都不代表這次發布是失敗的。ASR 模型很強，串流版本很實用，CPU 版本也確實聰明。但它提醒我們，「開源」如今涵蓋了各式各樣的安排，而具體是哪一種安排，比標籤本身更重要。需要 TTS 能力的團隊，應該在規劃專案之前就知道，而不是之後才知道。

值得一問的問題

VibeVoice 拋出的誠實問題是：移除程式碼是否是應對濫用的正確做法。權重仍在外流通，所以任何下定決心要執行這個模型的人都能找到方法。與此同時，那些原本可能依授權負責任地使用程式碼的人，卻失去了存取權。這是每個實驗室在強大模型擴散時都會面臨的張力：限制工具，你對謹慎使用者的不便會大於粗心的使用者；開放工具，你就得接受某些濫用會發生。

微軟選擇了中間路線。它保留了有用的語音辨識工作並維持開放，撤下了風險較高的合成程式碼。其他實驗室會做出不同的決定，而使用者將不得不繼續細讀細則，而不是相信標題。VibeVoice 值得研究，不是因為它不尋常，而是因為它預示了隨著技術成熟，更多發布將會如何被建構。

對任何以開源模型為基礎進行開發的人來說，教訓是在投入前先驗證。確認你想要的權重附有能執行它們的程式碼。閱讀授權與 README，因為它們可能互相矛盾。確認你打算依賴的版本在一年後仍可維護。這些都不令人興奮，但全都比專案進行六個月後才發現你需要的模型那一半從未發布來得便宜。VibeVoice 幫了這個領域一個忙，讓「開放權重」與「可用」之間的區別令人無法忽視。