VibeVoice：讓 60 分鐘錄音一次產生「誰、何時、說了什麼」的開源語音 AI

語音 AI 的難題，從來不只是把聲音轉成文字。真正進入會議紀錄、訪談整理或客服分析流程後，系統還必須回答三個問題：是哪一位說的、在什麼時間說的，以及完整內容是什麼。當音檔從幾分鐘拉長到一小時，傳統切段再辨識的做法也容易失去跨段落的上下文與說話者一致性。

Microsoft 開源的 VibeVoice，正好把這個問題放在核心位置。它不是只有單一模型，而是一個涵蓋長篇語音辨識與語音合成的 voice AI 家族。其中目前最適合拿來實作驗證的是 VibeVoice-ASR：官方文件描述它能以單次處理方式接收最長 60 分鐘的連續音訊，輸出包含說話者、時間戳與內容的結構化轉錄，並支援自訂 hotwords 與 50 種以上語言。

本文不把 VibeVoice 包裝成已經可以無條件上線的產品，而是從工程角度拆解它的能力邊界、安裝方式，以及如何把它接到一個可維護的語音處理流程。

先看懂 VibeVoice 目前包含什麼

VibeVoice Repository 目前同時放入三條主要路線：

VibeVoice-ASR：以 VibeVoice-ASR-7B 為核心的長篇語音轉文字模型，重點是一次處理長音檔、說話者資訊、時間戳、自訂 hotwords 與多語支援。
VibeVoice-TTS：原本主打最長約 90 分鐘、最多 4 位說話者的長篇多說話者語音合成，README 目前明確標示安裝與使用功能已停用。
VibeVoice-Realtime：參數量 0.5B 的即時 TTS 變體，設計目標是讓文字串流進來後，在完整答案產生前就開始播放語音。

這個區分很重要。若你的任務是把會議錄音整理成逐字稿，應該先看 ASR 文件；若你的任務是讓 LLM 邊生成邊說話，才是 Realtime TTS 的範圍。不能因為同一個 Repository 同時列出 TTS 與 ASR，就把所有模型的能力與可用性混為一談。

VibeVoice-ASR 解決的核心問題

一次處理長音檔，保留全局上下文

官方文件以 64K token 長度描述 VibeVoice-ASR 的輸入能力，目標是處理最長 60 分鐘的連續音訊。這種設計與「先把檔案切成很多短片段，再逐段呼叫 ASR」不同：模型可以在更大的上下文中維持說話者追蹤，也比較有機會讓前後語意保持連貫。

這不代表任何 60 分鐘檔案都能在所有 GPU 上輕鬆完成。實際耗時仍受音訊格式、顯示卡記憶體、推論設定與輸入內容影響。比較精確的說法是：VibeVoice-ASR 提供了單次長篇辨識的模型與程式路徑，讓工程師不必從切段策略開始設計整套流程。

把 ASR、diarization 與 timestamp 放在同一個輸出

一般語音轉文字服務常常需要另外接說話者分離與時間戳模組。VibeVoice-ASR 的定位則是聯合產生 Who、When、What，也就是說話者、發生時間與內容。對會議摘要、訪談編輯、法務稽核或客服品質分析而言，這比一大段沒有角色資訊的純文字更容易接到後續工作流。

不過，說話者標籤仍然應該被視為模型輸出，而不是不可質疑的事實。多人同時說話、環境噪音、遠距離麥克風與口音都可能影響 diarization 和文字正確率。正式流程應該保存原始音檔、模型版本與推論參數，並保留人工抽查入口。

用自訂 hotwords 處理專有名詞

會議中最容易辨識錯的，通常不是日常用語，而是產品名稱、人名、技術名詞或公司內部縮寫。VibeVoice-ASR 提供 customized hotwords，讓使用者提供領域詞彙或背景資訊，協助模型在特定場景中辨識。

這項功能特別適合 AI Chain 這類技術內容流程：可以把模型名稱、框架名稱、API 產品名與團隊成員姓名整理成每個專案的詞彙表，再隨音檔一起送入推論。它不是保證正確的字典替換，而是讓模型在語境中更注意這些詞；因此仍需用原始音檔或低信心片段做抽樣驗證。

從官方路徑開始安裝

官方 ASR 文件建議使用 NVIDIA Deep Learning Container 管理 CUDA 環境，並列出 NVIDIA PyTorch Container 24.07 到 25.12 的驗證範圍。若既有環境已經具備相容的 PyTorch、CUDA 與 flash attention，也可以直接在自己的環境安裝。以下是官方文件提供的基本路徑：

sudo docker run --privileged --net=host --ipc=host \
  --ulimit memlock=-1:-1 --ulimit stack=-1:-1 \
  --gpus all --rm -it nvcr.io/nvidia/pytorch:25.12-py3

 git clone https://github.com/microsoft/VibeVoice.git
 cd VibeVoice
 pip install -e .

Repository 的 pyproject.toml 要求 Python 3.10 以上，依賴包含 PyTorch、Transformers、Diffusers、Librosa、Gradio、FastAPI、Uvicorn 與音訊處理套件。若容器內沒有 flash attention，官方文件也提醒需要依照 flash-attention 專案的說明額外安裝。

實務上建議先確認三件事：GPU 驅動與容器 CUDA 版本是否匹配、音訊是否能被 ffmpeg 或 av 正常讀取，以及模型下載後的磁碟空間是否足夠。不要在沒有測試的生產環境直接把 60 分鐘檔案塞進服務；先用短檔建立可重現的 smoke test，再逐步拉長輸入。

兩種官方推論方式

方式一：啟動 Gradio 示範

ASR 文件提供 Gradio demo，適合第一次確認環境與模型是否能正常載入：

apt update && apt install ffmpeg -y
python demo/vibevoice_asr_gradio_demo.py \
  --model_path microsoft/VibeVoice-ASR --share

--share 會建立公開分享入口，測試時要注意音檔的隱私與外部曝光風險。若內容來自客戶、內部會議或含有個人資料，應優先在本機或受控網路中啟動，不要為了方便展示而把敏感音訊送到公開 demo。

方式二：直接處理音訊檔案

如果要接入自己的 pipeline，官方也提供直接從檔案推論的腳本：

python demo/vibevoice_asr_inference_from_file.py \
  --model_path microsoft/VibeVoice-ASR \
  --audio_files /path/to/meeting.wav

建議把這個腳本包在一個更小的服務層中，服務層負責檔案驗證、格式轉換、任務佇列、結果保存與錯誤重試，模型程序則專注於推論。這樣做的好處是模型更新時不必重寫上傳、權限與通知邏輯，也可以在 GPU 資源不足時把任務排隊，而不是讓 HTTP 請求一直阻塞。

一個可維護的語音處理流程

以會議轉錄為例，可以把流程拆成以下幾層：

接收音檔並產生不可猜測的任務 ID，保存檔案雜湊、來源、上傳者與保留期限。
檢查副檔名之外的實際音訊格式、取樣率、聲道與播放時間，拒絕異常或超過政策上限的檔案。
依專案或客戶載入 hotwords，並把模型版本、硬體與推論參數寫入任務 metadata。
將任務送入 GPU worker，以官方 inference script 或等價的 Python 呼叫執行 VibeVoice-ASR。
保存原始結構化結果，不要只保存最後整理過的摘要；後續摘要、搜尋與審核都應能回到原始片段。
對說話者標籤、時間戳與專有名詞抽樣檢查，低品質任務進入人工覆核。
完成後刪除超過保留期限的原始音檔，並以權限控管方式提供逐字稿與衍生資料。

這個設計的重點不是把一次推論包成一支更大的腳本，而是把「模型結果可能出錯」當成正常情況處理。語音辨識會進入知識庫、搜尋與自動摘要時，錯誤會被後續系統放大；保留來源與可追溯 metadata，才有機會定位問題。

Realtime TTS：讓 LLM 更早開口

VibeVoice-Realtime-0.5B 是另一個很有工程吸引力的方向。官方文件描述它支援 streaming text input，並以約 200 毫秒的初始可聽延遲為設計目標，讓應用程式可以在 LLM 還沒有完成整個回答時就開始播放。它使用交錯、視窗化的設計，持續編碼新進文字，同時延續先前內容的 diffusion acoustic latent 生成。

這種架構特別適合語音助理、即時旁白或串流資料朗讀。不過目前文件也列出清楚的限制：此變體是單一說話者、主要針對英文，其他語言可能出現不可預期結果；它不處理背景音樂與音效，也不適合直接朗讀程式碼、數學公式或特殊符號。文件中的 TODO 甚至仍包含完整的 streaming text input function，表示「模型支援串流」與「你的應用程式已經有成熟串流 API」是兩件不同的事。

官方的快速測試方式是：

pip install -e .[streamingtts]
python demo/vibevoice_realtime_demo.py \
  --model_path microsoft/VibeVoice-Realtime-0.5B

若只是想先確認體驗，也可以使用官方 Colab；若要在自己的服務中使用，則必須額外處理 WebSocket、音訊佇列、播放端緩衝與網路延遲。文件也提醒，使用者實際聽到第一段聲音的時間可能比模型生成延遲更長，因為網路與播放端本身會增加等待。

為什麼不能忽略風險與授權

VibeVoice Repository 採用 MIT License，但「程式碼採 MIT」不等於所有模型權重、資料來源與使用情境都自動沒有額外限制。導入前仍應逐一閱讀模型頁、技術報告與 Repository 內的最新說明，確認權重、商業使用與再發布條件。

更需要注意的是合成語音的冒用風險。官方 README 明確提醒，模型可能產生偏誤或不準確的結果，高品質合成語音也可能被用於冒充、詐騙與散播錯誤資訊。VibeVoice 的文件不建議未經進一步測試與開發就用於商業或真實世界應用，並要求使用者以合法且負責任的方式部署。

因此，實際產品至少應加入來源標記、內容審核、權限管理、濫用監控與刪除機制。對 TTS 尤其應避免未經同意模仿特定人物聲音；對 ASR 則應把逐字稿視為需要驗證的資料，不應把模型輸出直接當成法律、醫療或財務決策的唯一依據。

VibeVoice 適合誰？

如果你正在做以下事情，VibeVoice 值得放進實驗清單：

想把長篇訪談、會議或課程音檔轉成帶有說話者與時間戳的可搜尋資料。
想研究單次長上下文 ASR 如何減少切段流程，以及它對 diarization 一致性的影響。
想把自訂專有名詞詞表接到技術支援、研究訪談或企業內部語音工作流。
想讓 LLM 產生文字時立即啟動語音播放，探索低延遲的 voice agent 互動。

它不適合被簡化成「下載後就能取代所有語音 API」的結論。GPU 成本、模型載入時間、長音檔記憶體、語言支援、輸出品質與濫用防護，都是部署前必須實測的條件。

結語

VibeVoice 的價值，在於把長篇語音處理從一堆彼此拼接的元件，重新整理成一組可研究、可實作的開源模型路線。VibeVoice-ASR 以 60 分鐘單次輸入、Who／When／What 結構化轉錄、多語與 hotwords，對會議與內容工作流提出了清楚的工程介面；VibeVoice-Realtime 則把低延遲串流 TTS 與 LLM 的逐 token 輸出連在一起。

最務實的採用方式，是先選一個短音檔與一組領域詞彙建立基準，再逐步測試長度、語言、說話人數與硬體條件，最後才決定是否接入正式 pipeline。對 AI 工程團隊而言，這比只看 demo 音檔更有價值：你會得到可重現的品質數據，也能在真正處理敏感語音之前，先把隱私、授權與安全邊界設計好。

參考資料

GitHub Repository：https://github.com/microsoft/VibeVoice
VibeVoice-ASR 官方文件：https://github.com/microsoft/VibeVoice/blob/main/docs/vibevoice-asr.md
VibeVoice-Realtime 官方文件：https://github.com/microsoft/VibeVoice/blob/main/docs/vibevoice-realtime-0.5b.md
VibeVoice 技術報告：https://arxiv.org/pdf/2508.19205
VibeVoice-ASR 報告：https://arxiv.org/pdf/2601.18184