VibeVoice 用 7.5 Hz tokenizer 合成 90 分鐘多人 TTS

如果你做過 podcast 自動化、把長文章轉成有聲書、或是想生成「教學情境對話」這類內容，大概都會撞到同一面牆：開源 TTS 在「單句」品質上已經追平商業方案，但只要時長拉到十分鐘以上、加進兩個以上的 speaker，就會開始崩——音色漂移、停頓不自然、speaker A 講到後面講話像 speaker B。

Microsoft 在 2025 年 8 月底丟出來的 VibeVoice 把這個問題硬扛下來了。模型卡寫的數字很驚人：1.5B 參數能一次合成 90 分鐘音訊、最多 4 個 speaker 同場對話、context 長度 64K tokens，而且整個專案是 MIT license。論文後續入選 ICLR 2026 Oral，到 2026 年 3 月已經併入 Hugging Face Transformers。

這篇文章記錄我把 VibeVoice 從 1.5B 跑到 Realtime-0.5B 的整個過程：模型架構為什麼能撐這麼長、實際合成 30 分鐘節目花多少 GPU 時間、跟 XTTS-v2 / F5-TTS / ElevenLabs 的差距、以及最重要的——它的限制與應該守住的倫理紅線。

一、為什麼長篇多人 TTS 是難題

1.1 傳統 TTS 的「失憶症」

絕大多數開源 TTS 模型——Bark、XTTS-v2、F5-TTS、Coqui TTS——都是 utterance-level設計：給一句話、給一個 reference audio、合成出對應的語音。當你要做「半小時對話」，工程習慣是把腳本切成短句、逐句合成、再用 ffmpeg 拼接。

問題出在三件事：

• 音色一致性：每一段都是獨立 inference，speaker 1 在第 3 分鐘的聲音可能跟第 25 分鐘有微妙差異。聽起來不太對勁，但說不出哪裡有問題。
• 韻律 flow：句與句之間的停頓、語氣強弱、轉折，沒有跨句記憶。對話感（你一句我一句的節奏）合不出來。
• 混合 speaker：A、B 輪流講話需要動態切換 reference embedding，模型沒看過完整 context、容易在轉換點露餡。

1.2 為什麼不直接用更長的 context

直覺解法是：把 TTS 模型 context 拉長，讓它一次看完整段對話。但這條路撞到一個結構性瓶頸——token rate。

傳統 acoustic tokenizer（HuBERT、EnCodec、SoundStream）的 frame rate 是 50–100 Hz，意思是 1 秒語音佔 50–100 個 token。要合成 30 分鐘語音 = 30 × 60 × 75 ≈ 135,000 tokens，這已經逼近現代 LLM 的 context 上限。要做 90 分鐘乘 3 倍，根本塞不進去。

VibeVoice 的解法直接攻擊這個核心：把 frame rate 砍到 7.5 Hz。

二、VibeVoice 的架構

2.1 7.5 Hz acoustic tokenizer

這是整個專案最重要的設計決策。1 秒語音只用 7.5 個 token（傳統的 1/10），90 分鐘 = 90 × 60 × 7.5 = 40,500 tokens，剛好塞進 64K context window。

模型卡描述的 tokenizer 是 σ-VAE 變體，把 24 kHz 取樣率的音訊用 3200 倍 downsample 壓成 token 序列。那「失去的 acoustic 細節」誰來補？答案是 diffusion head。

2.2 next-token diffusion 範式

VibeVoice 的核心是 next-token diffusion，這個範式跟一般 LLM autoregressive 生成差很多：

1. LLM 主幹（Qwen2.5-1.5B）負責「該說什麼、什麼語氣、誰在講」這類 semantic + prosodic 決策，輸出 7.5 Hz 的 token stream。這個 stream 包含 semantic latent（語意）+ acoustic latent（音色 + 韻律雛形）。
2. Diffusion head（4 層 transformer，~40M 參數）並行對每個 token 做 diffusion，把 latent 還原成 24 kHz 的 acoustic detail（細節到呼吸、唇齒、空氣感）。

你可以這樣理解：LLM 是編劇 + 導演，決定「這一段該怎麼演」；diffusion 是配音演員，把演技細節做出來。兩階段分工讓 LLM 不用浪費 capacity 學 acoustic 細節，可以把所有注意力放在 dialogue flow 上——這就是它能做到長篇多人對話的關鍵。

2.3 模型家族

到 2026 年 4 月為止 Microsoft 釋出了三個版本：

• VibeVoice-TTS-1.5B（2025-08-25）：90 分鐘、最多 4 人、context 64K，主力長篇 TTS。
• VibeVoice-Realtime-0.5B（2025-12-03）：context 8K、單 speaker、首字延遲約 300ms，給直播、即時翻譯用。
• VibeVoice-ASR-7B（2026-01-21）：反向版本，60 分鐘音訊一次轉文字、context 64K。

到 2026-03-06 整個 VibeVoice 系列被併入 Hugging Face Transformers 主分支，意味著之後 from transformers import VibeVoiceForConditionalGeneration 就能直接用，不用再裝 Microsoft 自家 fork。

2.4 課程學習與訓練細節

模型卡裡有提到一個值得注意的訓練策略——課程學習（curriculum learning）。1.5B 模型不是一開始就用 64K context 訓練，而是分四階段把序列長度遞增：4K → 16K → 32K → 64K。每個階段都讓模型先在較短序列上學會基本對話 flow，再逐步把上下文視野拉長。Realtime 版本走類似邏輯但短得多：4K → 8K。

acoustic tokenizer 與 LLM 是分階段訓練的：tokenizer 先單獨 pretrain（重建損失 + perceptual loss），權重凍結後才開始訓 LLM 與 diffusion head。這個分階段邏輯在 audio-language model 訓練裡並不少見，但 VibeVoice 把它做到極致——LLM 永遠看不到原始 waveform，只看 7.5 Hz token，反而讓它把所有 capacity 投在「對話結構」上。

三、實際跑起來

3.1 環境準備

我手邊跑的硬體是 RTX 4070 Ti（12 GB VRAM），1.5B 模型在 BF16 下剛好塞得下，比較長的合成需要 gradient checkpointing 或開 8-bit quant。基本配置：

pip install transformers accelerate bitsandbytes
git clone https://github.com/microsoft/VibeVoice
cd VibeVoice && pip install -e .

# 下載權重（HF 帳號要登入）
huggingface-cli download microsoft/VibeVoice-1.5B

雲端的話 A100 40 GB 跑 90 分鐘合成大約 8–12 分鐘 wall time（real-time factor 約 0.1×），消費級顯卡 12 GB 跑 30 分鐘節目大概 6–8 分鐘 wall time。

3.2 podcast 範例

VibeVoice 的腳本格式很直觀，speaker 用標籤區分：

Speaker 1: 大家好，今天我們來聊聊 WiFi 訊號做姿勢估計的最新進展。
Speaker 2: 對，這個題目其實 2023 年 CMU 就發過論文，但工程化一直卡在硬體上。
Speaker 1: 你說的是 Intel 5300 NIC 對吧？那塊現在 eBay 都炒到 80 美元一張。
Speaker 2: 沒錯，所以社群這次用 ESP32-S3 重做整套 pipeline 才會這麼有意義。

對應的 Python 推論腳本：

from transformers import AutoProcessor, VibeVoiceForConditionalGeneration
import torch

processor = AutoProcessor.from_pretrained("microsoft/VibeVoice-1.5B")
model = VibeVoiceForConditionalGeneration.from_pretrained(
    "microsoft/VibeVoice-1.5B",
    torch_dtype=torch.bfloat16,
    device_map="cuda",
)

# 4 段參考音訊（每段 6-30 秒，clean voice）
speaker_prompts = [
    "voices/host_male.wav",
    "voices/expert_female.wav",
    "voices/casual_male.wav",
    "voices/narrator_female.wav",
]

with open("script.txt") as f:
    script = f.read()

inputs = processor(
    text=script,
    speaker_audios=speaker_prompts[:2],  # 只用前兩個 speaker
    return_tensors="pt",
).to("cuda")

audio = model.generate(**inputs, max_new_tokens=20_000)  # 約 44 分鐘
processor.save_audio(audio, "podcast_output.wav", sample_rate=24000)

實測下來最讓我意外的是 speaker 切換的自然度。我故意在腳本中放快速來回（A-B-A-B 短句），合成出來的停頓、抑揚、甚至 A 接 B 的反應時間都很有節目感，不像 utterance-level 拼接那樣有「跳接」的感覺。

3.3 Realtime-0.5B 拿來做什麼

Realtime 版本最大的差異不是「快」，是「串流文字輸入」。它支援逐塊 encode：你可以一邊串流 LLM 輸出（例如 GPT 寫腳本）、一邊把文字餵給 VibeVoice，第一個音節在 ~300 ms 後就開始播放。

這對「直播即時字幕轉語音」「LLM 對話 agent 的 voice 模式」非常實用。它代價是只支援單 speaker、context 砍到 8K（約 10 分鐘）。架構上也降規：LLM backbone 換成 Qwen2.5-0.5B、acoustic tokenizer 變 σ-VAE 340M、diffusion head 還是 40M。

實際把 0.5B 跑在 4070 Ti 上，雖然官方說 deployment-friendly，但要真的拿到 300ms 首字延遲，模型載入完之後 cuda warm-up 還是要做（第一次 inference 約 1.2 秒）。Production 場景建議用 Triton 或 vLLM 自己 wrap 一層。

四、跟其他開源 / 商業 TTS 的比較

4.1 vs. XTTS-v2 / F5-TTS / Bark

開源這條陣線比較直接：

• XTTS-v2（Coqui）：強項是 voice cloning，6 秒 reference 就能 clone。弱在 long-form——超過 30 秒會崩。
• F5-TTS：flow matching 架構，品質中上、單句快。但是 utterance-level 設計，跨句一致性不行。
• Bark：Suno 的早期工作，能做歌唱、笑聲、效果音，但 hallucination 嚴重、不穩定。
• Spark-TTS：2025 中出現的對手，類似 LLM-based 設計，但最大長度仍只到 ~2 分鐘。

VibeVoice 在「長篇 + 多 speaker」這條軸線上目前沒有同等級開源對手。它在「單句最頂級品質」可能還是輸 F5-TTS 一點點，但 use case 完全不同。

4.2 vs. ElevenLabs / OpenAI Voice Engine

商業這側 ElevenLabs 是壓倒性領先 single-utterance 品質，但兩個結構性差異：

• 錢：ElevenLabs 多 speaker 方案 $99/月起跳，做 podcast 自動化還會被流量計費吃掉。VibeVoice 自託管之後 inference 只算 GPU 電費。
• 隱私：自託管意味著腳本 / 參考音訊不會送到第三方。對企業內部 e-learning、醫療場景幾乎是必選項。

OpenAI 的 Voice Engine 還沒對開發者開放，而且 OpenAI 自己 2024 年就強調「不打算 wide release，因為 voice cloning 風險過大」。VibeVoice 等於是這個生態目前唯一可商用、可自託管、能做多 speaker 長篇的選擇。

4.3 watermark 與倫理

模型卡裡有一條我覺得 Microsoft 做得很對的設計：imperceptible watermark 強制嵌入。任何用 VibeVoice 生成的音訊都會帶一個聽不出來的浮水印，第三方可以用解碼器驗證「這段是 AI 生成的」。

更激進的是模型還會在生成內容前後嵌入一段 audible disclaimer："This segment was generated by AI"——你想拿掉這段，要去 fork 並修改 codebase。Microsoft 用工程手段把濫用門檻拉高。

模型卡也明確聲明：「不建議用於商業或現實世界應用」，明示是研究釋出。實作上你當然可以拿來做 podcast、AI agent voice、語音書，但侵犯他人 voice、做 deepfake 詐騙這條線不能踩。

五、限制與可能踩到的雷

5.1 工程限制

到目前為止我撞到的：

• 語言：英文 + 中文最穩，日文勉強能用，其他語言訓練資料少、聽起來不自然甚至產出失真。
• 不支援 overlap speech：兩個 speaker 同時講話、互相打斷在訓練資料裡很少見，模型遇到就會有一個 voice 變得含糊。
• 沒有背景音樂 / 效果音：純 voice track，要做完整節目得自己用 DAW 混。
• emotion control 有限：可以做出基本喜怒哀樂，但精細到「鬱悶又帶點諷刺」這種就 hit-or-miss。
• VRAM：1.5B BF16 推 90 分鐘需要約 14 GB peak，12 GB 卡要走 8-bit quant。

5.2 Microsoft 暫停事件

2025 年 9 月 5 日 Microsoft 一度因「發現不當使用情況」暫停過 repo，後來又恢復、加上更嚴格的使用條款與 watermark 機制。這事件提醒一件事：這類模型隨時可能被原廠下架。

我自己的做法是 weights、代碼、配置都拉一份本地備份，並在 production 系統設計上避免硬綁特定版本——萬一原版下架，至少有時間遷移到其他模型。

5.3 法律灰色地帶

台灣個資法、歐盟 AI Act 對「voice cloning」的規範還在發展。實務上幾條保險做法：

• 若用名人 / 真人聲音當 reference，必須有書面授權。
• 商業 podcast 公開時，文案中明示「部分音訊由 AI 生成」。
• 不要把 watermark 拿掉。Microsoft 強制嵌入是有道理的，這是你「沒打算騙人」的舉證。
• 客戶語音資料若用做 fine-tune，走標準 GDPR / 個資法的 consent flow。

六、適合的應用場景

我自己跑了一輪後覺得目前最適合的 use case：

• 長文 / blog 自動轉 podcast：把技術文章丟給 GPT 改寫成 dialogue 形式 → 4 個 speaker prompt → VibeVoice 一次合成。一篇 3000 字文章變 25 分鐘節目，整套 pipeline 不到 15 分鐘。
• 教學情境對話：語言學習、產品說明、SOP 演練——「角色互動」對學習效果幫助大，過去要請真人配音。
• AI agent voice mode：用 Realtime-0.5B 做即時對答，比 ElevenLabs API 便宜兩個量級。
• e-learning narration：自託管解決企業隱私顧慮，內部訓練教材一次合成數小時。

不適合的：

• 商業電影、廣告級配音——VibeVoice 的「最後 5%」品質還是輸給專業配音員。
• 即時電話客服——300ms 延遲在電話場景偏高，需要更激進的優化。
• 需要強烈情感表演的場景——技術還在演進。

七、結論

VibeVoice 重要的不是「又一個 SOTA TTS」，是它在工程上把 frame rate 從 50–100 Hz 砍到 7.5 Hz這個決策，搭配 next-token diffusion 範式，把 long-form + 多 speaker TTS 這條技術路線打通了。配上 ICLR 2026 Oral 的學術背書、Hugging Face Transformers 主線整合、MIT license，這個專案在 2026 年下半年應該會成為自託管 TTS 的標準起點。

如果你的場景是「我需要一次合成 10 分鐘以上、超過一個 speaker、自託管、不想被商業 API 綁住」——VibeVoice 目前沒有同等級替代品。如果你只想做單句 high-fidelity 配音，F5-TTS 或 ElevenLabs 還是會在那塊 niche 贏一截。

接下來我會把 VibeVoice 接到自己的 podcast pipeline 上，搭配 GPT-4 改寫腳本、ffmpeg 加 BGM，看能不能做到「一篇技術文章 → 完整 25 分鐘節目」全自動化，再來分享流程。

參考資料

• VibeVoice 官方頁面
• microsoft/VibeVoice GitHub
• VibeVoice TTS 文件
• VibeVoice Realtime 0.5B 文件
• microsoft/VibeVoice-1.5B HuggingFace
• microsoft/VibeVoice-Realtime-0.5B HuggingFace
• BentoML：開源 TTS 模型概覽