Select Page
VibeVoice 是什麼?Microsoft ASR、即時 TTS 與 CPU 部署指南

VibeVoice 是什麼?Microsoft ASR、即時 TTS 與 CPU 部署指南

VibeVoice 現在不能只理解成一個文字轉語音模型,它已經變成 Microsoft 的開源語音模型家族,包含長音訊語音辨識、即時串流 TTS、長篇多人 TTS,以及最新的 CPU 量化辨識版本,值得注意的地方,不只是能把文字念出來,而是它開始把「聽懂一小時內容」與「收到文字後立刻開口」做成兩條可以獨立部署的路線。

先講我的結論。如果要做會議轉錄、訪談整理或字幕,先看 VibeVoice-ASR。如果只有一般電腦,優先測試 VibeVoice-ASR-BitNet。如果要讓 Agent 邊產生答案邊說話,選 VibeVoice-Realtime-0.5B,至於能合成 90 分鐘、最多四人對話的 VibeVoice-TTS-1.5B,目前官方快速體驗仍標示為停用,不能把社群整合包的功能直接當成官方現況。

VibeVoice 四個版本怎麼選

模型主要工作適合場景部署重點
VibeVoice-ASR-7B長音訊轉文字會議、訪談、字幕、多人對話可一次處理最長 60 分鐘,完整模型需要較多 GPU 記憶體
VibeVoice-ASR-BitNetCPU 語音辨識桌機、Mac、邊緣設備、離線轉錄模型約 1.58 GB,不需要 GPU
VibeVoice-Realtime-0.5B即時文字轉語音語音 Agent、即時旁白、串流回應單一說話人,英文為主要目標,其他語言仍屬實驗
VibeVoice-TTS-1.5B長篇多人語音合成Podcast、有聲內容、多人對話原始能力可達 90 分鐘與四位說話人,但官方程式與快速體驗目前停用

VibeVoice 的核心不是單純縮小模型

VibeVoice 使用聲學與語意連續語音 tokenizer,運作頻率只有 7.5 Hz,這代表模型不需要把長音訊展開成極密集的離散 token,處理長序列時比較節省,生成端再用 next-token diffusion,把語言模型負責的文字脈絡與對話流程,交給 diffusion head 補上聲學細節。

這個架構帶來兩個很實際的能力。ASR 可以在 64K token 長度內一次接收最長 60 分鐘音訊,輸出誰在什麼時間說了什麼。

Realtime TTS 則採用交錯的視窗設計,一邊接收新增文字,一邊延續前文產生聲音,讓 LLM 不必等完整答案寫完才開始說話。

如果正在組本地語音 Agent,可以把它放進 speech-to-speech 的 VAD、STT、LLM、TTS 管線。VibeVoice-ASR 負責聽,Realtime 負責說,中間的 LLM 可以換成本地模型。這比把整套功能綁死在單一 App 裡更容易維護。

ASR 不只是逐字稿,還會分辨說話人

一般 Whisper 工作流常要再接一套 speaker diarization,才能把不同說話人分開。VibeVoice-ASR 把語音辨識、說話人分離與時間戳放進同一個輸出,直接得到 Who、When、What 的結構。對會議記錄、Podcast 整理、客服通話和長篇訪談,這比單純吐出一整段文字更有用。

它也支援自訂 hotwords,可以先提供人名、產品名、技術術語與背景資料,減少專有名詞被聽錯的機率。官方 Transformers 版本支援超過 50 種語言,也能處理語句內與語句間的語言切換。這讓 Python 整合不必依賴特定 WebUI。

VibeVoice 真的比 Whisper 快又準嗎

答案不是單純的「是」,Microsoft 公布的 CPU BitNet 測試中,在 AMD EPYC 7V13 上使用三條 CPU 執行緒時,RTF 為 0.77,已經快於即時播放速度,四條執行緒降到 0.63。Apple M4 使用四條執行緒的 RTF 為 0.43。這些結果證明 CPU 即時辨識成立,但不同處理器、音訊長度與編譯方式都會影響速度。

VibeVoice ASR BitNet 與 Whisper 在七個資料集的 WER 比較圖
官方 WER 測試顯示兩個模型各有優勢,數值越低越好

準確率也要分資料集看。BitNet 在 MLC-EN、AMI-ihm、AMI-sdm 與 VoxPopuli 的 WER 低於 Whisper,但在 Fleurs-en、Libri-clean 與 Libri-other 則是 Whisper 較低。所以比較正確的說法是,VibeVoice-ASR-BitNet 在多說話人與部分長音訊測試很有競爭力,不能直接延伸成所有語言、所有錄音條件都勝過 Whisper。

如果目前的工作流已經大量使用 Whisper,可以先看我整理的 Whisper 本地語音辨識,再拿自己的中文會議、多人訪談與背景噪音資料做同一套測試。真正有意義的是自己的素材,不是只看單一排行榜。

最省硬體的做法,用 VibeASR.cpp 跑 BitNet

只想在 CPU 上完成轉錄,官方的 VibeASR.cpp 是目前最直接的路線。需要 Python 3.9 以上、CMake 3.14 以上,以及 GCC 或 Clang。Windows 需要 MinGW-w64,MSVC 目前不支援。

git clone --recursive https://github.com/microsoft/VibeASR.cpp.git
cd VibeASR.cpp
pip install -r requirements.txt
python setup_env.py

準備一個 WAV 音檔後,用四條 CPU 執行緒開始轉錄。

./build/bin/asr_infer \
  --vae-model models/vibeasr/vibeasr-vae-encoder-i8_s.gguf \
  --lm-model models/vibeasr/vibeasr-lm-i2_s-embed-q6_k.gguf \
  --audio input.wav -t 4

模型頁也提供 Ollama 的啟動方式。這條命令適合先快速取得模型,若要穩定處理音訊檔與調整執行緒,VibeASR.cpp 的 CLI 參數會更清楚。

ollama run hf.co/microsoft/VibeVoice-ASR-BitNet:Q6_K

用 Transformers 在 Python 呼叫 ASR

需要接進自己的 Python 程式時,使用 Transformers 5.3.0 以上的官方模型最乾淨。完整 ASR 權重較大,先確認顯卡記憶體與磁碟空間,不要把 Realtime 0.5B 的硬體需求套過來。

python -m venv .venv
source .venv/bin/activate
pip install transformers==5.3.0 accelerate soundfile
from transformers import AutoProcessor, VibeVoiceAsrForConditionalGeneration

model_id = "microsoft/VibeVoice-ASR-HF"
processor = AutoProcessor.from_pretrained(model_id)
model = VibeVoiceAsrForConditionalGeneration.from_pretrained(
    model_id,
    device_map="auto"
)

inputs = processor.apply_transcription_request(
    audio="input.wav"
).to(model.device, model.dtype)

output_ids = model.generate(**inputs)
generated_ids = output_ids[:, inputs["input_ids"].shape[1]:]
result = processor.decode(generated_ids, return_format="parsed")[0]

for item in result:
    print(item)

如果要讓多人共用,官方還提供 vLLM 外掛,對外開出 OpenAI 相容的 /v1/chat/completions 端點,並支援串流、長音訊、hotwords、資料平行與張量平行。這條路比較適合公司內部的集中式轉錄服務。

啟動 Realtime 0.5B 即時 TTS

Realtime 版本的價值是讓 LLM 還在產生文字時就開始發聲。官方資料寫的是約 200 毫秒產生第一段聲音,但實際聽到的時間還會加上網路與播放緩衝。官方測試中 NVIDIA T4 與 Mac M4 Pro 可以達到即時速度,這不代表每一台 Mac 或每張 6GB 顯卡都一定相同。

git clone https://github.com/microsoft/VibeVoice.git
cd VibeVoice
python -m venv .venv
source .venv/bin/activate
pip install -e ".[streamingtts]"
python demo/vibevoice_realtime_demo.py \
  --model_path microsoft/VibeVoice-Realtime-0.5B

Realtime 0.5B 目前只支援單一說話人,英文仍是主要目標。德文、法文、義大利文、日文、韓文、荷蘭文、波蘭文、葡萄牙文與西班牙文屬於實驗音色。中文長篇多人合成若來自社群分支或整合包,應分開標示版本與來源。想比較更偏聲音克隆的方案,可以延伸看 dots.tts 的 3 秒聲音復刻架構,若重點是音色設計,則可以看 Qwen3-TTS 的音色控制。

文字正規化是長篇 TTS 的必做前處理

長篇語音最常見的問題不是音色,而是日期、金額、百分比、網址與特殊符號被念錯。輸入「2026/7/28」與輸入「二零二六年七月二十八日」,模型收到的任務並不相同。正式生成前應先清理 Markdown、程式碼、罕見符號與過度複雜的標點,再把數字轉成預期的口語形式。

pip install wetext
from wetext import Normalizer

normalizer = Normalizer(lang="zh", operator="tn")
text = normalizer.normalize("2026年7月28日,版本 1.0")
print(text)

WeText 可以做中文、英文與日文的 TN 和 ITN。它不是萬能修正器,品牌名、縮寫與人名仍要自行建立字典。這一步也適合放在 Voicebox 本地 AI 語音工作室這類批次工作流前面,避免同一個錯誤被大量生成。

安裝時最容易卡住的地方

  • PyTorch 裝成 CPU 版:先用 python -c "print(__import__('torch').cuda.is_available())" 檢查,再依自己的 CUDA 版本重裝官方 PyTorch 套件。
  • 把所有版本當成同一套需求:ASR-7B、Realtime-0.5B 與 BitNet 的模型大小和執行後端完全不同。
  • 把社群功能當成官方保證:自訂音色、中文多人 TTS 與一鍵整合包要確認來源、commit 與安全性。
  • 忽略 FFmpeg:Gradio 與長音訊服務通常需要 FFmpeg 解碼,先確認 ffmpeg -version 能正常執行。
  • 直接丟進正式產品:Microsoft 明確把目前版本定位在研究與開發用途,正式商用前要自行測試準確率、延遲、授權與風險。

我會怎麼選

VibeVoice 最有價值的不是某一個模型贏過所有對手,而是它把語音工作拆成幾個明確層級。只有 CPU 就用 BitNet。需要長音訊、說話人與時間戳,就用完整 ASR。需要 Agent 邊想邊說,就用 Realtime。需要中文音色克隆與更強的角色控制,則把 dots.tts、Qwen3-TTS 或其他本地 TTS 放進比較名單。

我特別喜歡 BitNet 這次的方向。它不是叫使用者為了語音辨識再買一張顯卡,而是透過量化與專用 CPU runtime,把模型帶回一般電腦。這種改進比單純把參數做大更接近真正能落地的本地 AI。

官方資源

FAQ

VibeVoice 可以完全離線使用嗎

可以。模型與依賴下載完成後,VibeASR.cpp、Transformers ASR 與 Realtime TTS 都可以在本地執行。第一次安裝與下載權重仍需要網路。

6GB 顯存可以跑所有 VibeVoice 模型嗎

不可以。6GB 是特定 TTS 或 Realtime 組合的實測條件,完整 ASR 權重需要更多資源。只有一般電腦時,CPU 版 BitNet 是更合理的起點。

VibeVoice-Realtime 支援中文嗎

官方目前仍把英文列為主要目標,另提供九種實驗語言,名單不含中文。社群版本可能加入中文或自訂音色,但要分開看待。

audio.cpp 是什麼?本地語音 AI 終於有統一底座

audio.cpp 是什麼?本地語音 AI 終於有統一底座

以前想在本機跑語音模型,常常是一個 TTS 一套環境,一個 ASR 一套環境,AI 翻唱又是另一套 CUDA 和 Python 依賴。最後不是模型不夠好,而是環境先把人勸退。

audio.cpp-webui 想解決的正是這件事。它把 TTS、ASR、聲音克隆、即時語音、音樂生成、音色遷移和聲音設計放到同一個 WebUI 裡,背後用本地模型服務統一調度。你可以把它理解成語音領域的 llama.cpp 或 Ollama。文字大模型有本地推理中心,語音模型也開始有自己的本地運行中心。

audio.cpp 解決的是語音模型碎片化

本地語音 AI 的痛點一直很明顯。TTS 要裝一套,ASR 要裝一套,聲音轉換要裝一套,音樂生成又要裝一套。每套工具都有自己的版本要求、模型格式、顯存需求和啟動方式。audio.cpp 把這些能力接到同一個後台,讓使用者透過同一套界面切換模型。

這件事的意義很像我之前整理過的 本地大模型推理框架比較。當底座統一之後,真正省下來的不是某一次安裝時間,而是後續每次換模型、接應用、做工作流時的摩擦成本。

TTS 和聲音克隆是最容易上手的入口

audio.cpp-webui 的 TTS 介面可以選模型、載入參考音訊、輸入文字,再生成語音。整合包裡常見的入口包含 Pocket TTS 和 Qwen3-TTS 0.6B。Pocket TTS 偏英文,中文語音更適合用 Qwen3-TTS 這類模型。

Qwen3-TTS 的優點是參數不大,中文效果也不錯。若你想先理解它的能力,我之前整理過一篇 Qwen3-TTS 與音色設計,可以一起看。audio.cpp 的價值在於,它不是只支援某一個模型,而是讓多個 TTS 模型都能被放進同一個語音服務裡。

參考音訊不建議太長,控制在 10 秒以內比較實際。太長會拖慢合成速度,也不一定帶來更好的克隆效果。常用音色可以放到 WebUI 指定目錄,再把檔名與對應文字整理好,後續就不用每次手動上傳。

ASR 讓語音輸入變成可接入的文字層

ASR 是 audio.cpp 另一個關鍵能力。Qwen3-ASR 這類模型可以把麥克風或音訊檔轉成文字,中英文都能處理。單人語音轉寫比較穩,多人對話則可以使用對話模式,把不同說話人分段標出來。

這對本地 Agent 很重要。因為語音互動其實可以拆成三層:麥克風輸入交給 ASR,大語言模型負責理解與回答,最後再用 TTS 朗讀。audio.cpp 負責的是聽和說這一層,大模型可以是本地 Ollama,也可以是雲端 API。

如果你正在做語音 Agent,可以對照我之前寫的 Hugging Face speech-to-speech 本地即時語音 Agent。兩者關心的都是同一件事:把語音輸入、模型推理和語音輸出串成一條穩定的互動管線。

即時語音系統的架構

audio.cpp 的即時語音流程很直覺。使用者說話,ASR 把聲音轉成文字,LLM 生成回答,TTS 再把回答唸出來。整套流程可以把語音層放在本機,讓資料不必全部送到雲端語音平台。

步驟負責元件作用
語音輸入麥克風接收使用者說話
語音轉文字ASR 模型把聲音轉成文字 prompt
回答生成LLM本地或雲端大模型產生回答
文字轉語音TTS 模型把回答轉成聲音
應用接入OpenAI 相容接口讓其他應用呼叫本地 TTS 或 ASR

這個架構的彈性在於 LLM 那一層可以替換。你可以接雲端 API,也可以接本地 Ollama。若你想把語音服務接到不同電腦或區網環境,我之前的 Ollama 遠端連線教學也能作為網路配置的參考。

AI 翻唱和音樂生成也被放進同一個底座

audio.cpp 不只整合 TTS 和 ASR,也把 ACE-Step、Stable Audio、聲音轉換、歌聲轉換等音樂能力放進同一個工具裡。這讓它不只是語音助手工具,也能處理 AI 翻唱、換詞翻唱和背景音樂生成。

換詞翻唱的流程大致是先上傳原曲,讓模型分析歌曲風格與曲譜資訊,再填入原曲歌詞和新歌詞。若新詞唱不準,可以調 Flow Edit 參數,常見測試區間是 0.7 到 0.9。若只是要背景音樂,Stable Audio 會比 ACE-Step 更穩一些。

音色遷移則是保持內容和語氣,把聲音換成另一種音色。若追求歌聲轉換品質,RVC 流程仍然更值得保留。audio.cpp 的優勢在於統一入口,而不是每個單項都一定超過專門工具。

8G 顯存能跑,但要理解限制

這次最有吸引力的點,是多數核心功能可以在 8G 顯存的消費級顯卡上跑起來。像 Qwen3-TTS、Qwen3-ASR、部分 TTS 和 ASR 模型,對顯存要求相對友善。VibeVoice 合成長文本時,顯存也能控制在 7G 左右。

但這不代表所有模型都能在低配機器上順跑。音樂生成、翻唱、聲音轉換通常更吃資源。A 卡和沒有獨顯的機器可以走 CPU 模式,但速度會慢,適合測輕量模型,不適合期待即時體驗。

  • NVIDIA 16 系到 50 系顯卡比較適合整合包體驗
  • 8G 顯存可以跑多數 TTS、ASR 和部分音樂模型
  • CPU 模式能跑部分輕量模型,但延遲會增加
  • 參考音訊越長,TTS 合成速度越容易被拖慢
  • AI 翻唱隨機性較高,需要多試幾次參數

下載和使用要注意什麼

audio.cpp 本體是 C++ 專案,源碼在 audio.cpp-webui GitHub。對熟悉命令列的人來說,可以直接從源碼開始。若只想快速體驗,整合包會比較省事。

我的使用判斷

audio.cpp-webui 最適合兩種人。第一種是想在本機跑語音模型的創作者,例如要做配音、聲音克隆、語音轉文字、AI 翻唱。第二種是開發者,想替自己的本地 Agent 或應用加上語音輸入輸出。

如果你只需要單一 TTS,直接用專門工具可能更快。如果你想把 TTS、ASR、語音助手、聲音轉換和音樂生成放進同一套本地服務,那 audio.cpp 的價值就出來了。它把語音模型從「一堆分散工具」往「一個本地語音底座」推了一步。

我會把它看成語音 AI 版的本地推理中心。文字模型有 Ollama,圖片影片有 ComfyUI,語音模型也需要這樣的入口。audio.cpp 還在快速發展,但方向是對的。只要模型支援越來越多,接口越來越穩,本地語音 Agent 的門檻會明顯下降。

FAQ

audio.cpp 是什麼?

audio.cpp 是本地音訊模型底座,目標是把 TTS、ASR、聲音轉換、音樂生成和即時語音整合到同一套本地服務裡。

audio.cpp-webui 適合誰?

適合想在本機跑聲音克隆、語音轉文字、即時語音助手、AI 翻唱或本地 Agent 語音輸入輸出的人。

8G 顯存真的能跑嗎?

多數 TTS、ASR 與部分音樂功能可以在 8G 顯存上跑起來。部分輕量模型甚至能用 CPU,只是速度會慢一些。

它和 Ollama 或 llama.cpp 有什麼關係?

概念相似,Ollama 和 llama.cpp 解決文字大模型的本地推理,audio.cpp 想解決語音模型的本地統一服務。

可以接到自己的應用嗎?

可以。audio.cpp 提供 OpenAI 相容接口,只要應用支援填入 TTS 或 ASR 服務地址與模型名稱,就能接入本地語音服務。