如果你想把一段文章直接念成十幾分鐘的旁白，TontaubeV1 的重點不是「聲音像不像真人」這一句宣傳，而是它試圖把長篇、串流與本機推理同時處理好。
先看結論：它解決的是長篇語音的工程問題
TontaubeV1 是 Tontaube AI（由 Fritz Cremer 與 Jonathan Cremer 開發）發布的 2.9B（約 28.7 億參數）開放權重文字轉語音模型，定位在富有表達力的長篇語音、低延遲回傳與本機部署。模型主要針對英語和德語進行調校，並支援西班牙語、法語、義大利語、荷蘭語與葡萄牙語等共 7 種語言，同時能使用 5 至 60 秒（上限約 1 分鐘）的參考音檔進行零樣本聲音複製（Zero-Shot Voice Cloning）。
這個定位和只產生一句廣告口號的 TTS 不太一樣。長篇內容會遇到更多實際問題：段落之間的語氣是否連得起來、生成時能不能一邊播放一邊繼續合成、文字很長時上下文會不會失控，以及一次處理多個請求時 GPU 是否浪費在等待上。TontaubeV1 的設計幾乎都圍繞這些問題展開。
在授權方面需特別注意：推理服務程式碼採用 Apache License 2.0 開源授權，但模型權重本身採用的是 Tontaube Community Model License 1.0，屬於允許研究與符合條件之商業用途的開放權重（Open-weight）授權，而非純粹的 OSI 開源授權。
架構重點：四個自回歸模型接力產生聲音
官方技術報告把 TontaubeV1 描述成由四個自回歸模型（CB0 至 CB3）組成的分層語音生成系統。它採用 DualCodec（12.5 Hz，總位元率約 625 bit/s）作為語音表徵，將語音拆解為 1 個語意碼本與 3 個聲學精鍊碼本：
- CB0（語意與時長預測）：基於 Qwen3-1.7B 骨幹（約 18.3 億參數，28 個 Transformer 區塊），負責從文字生成語意音訊碼本並決定語音時長與韻律。
- CB1（聲學精鍊一）：基於 Qwen3-0.6B 骨幹（約 4.49 億參數，16 個 Transformer 區塊），補上第一層聲學細節。
- CB2（聲學精鍊二）：基於 Qwen3-0.6B 骨幹（約 3.27 億參數，8 個 Transformer 區塊），進一步擴充聲學殘差。
- CB3（聲學精鍊三）：基於 Qwen3-0.6B 骨幹（約 2.69 億參數，4 個 Transformer 區塊），完成最後一層聲學修飾。
四個模型總計 56 個 Transformer 區塊、約 28.7 億參數。這種設計有兩個直接好處：
- 早期串流播放：由於 DualCodec 本身的解碼器非因果（Non-causal），TontaubeV1 在推論時將重疊的 DualCodec 重建映射至 VibeVoice 的聲學隱空間（Acoustic Latent Space），再透過 VibeVoice 的因果解碼器輸出，使第一個可播放音訊能在約 200 毫秒（TTFT）內出現。
- 有界上下文（Bounded Context）：系統採用滾動上下文視窗（Rolling Context Window），並使用以字元為單位的 Tokenizer 與共享的邏輯位置編碼（Logical RoPE Positions），讓已處理過的區塊不必無限留在上下文中，降低長文越念越不穩或漂移的風險。
此外，文字端預設要求 spoken-form 拼寫。官方另外提供了一個獨立訓練的英文文字正規化模型（TontaubeV1-Verbalizer，基於 Qwen3-1.7B），可選擇性啟用，將數字、日期與貨幣單位（如 1984）轉譯為發音文字（nineteen eighty-four）。
速度數字與硬體需求
官方在暖機後的單張 NVIDIA GeForce RTX 5090 測試中，回報單請求約為 0.08 RTF（即生成速度約為即時播放的 12.5 倍）；在 8 個請求併發的批次條件下，累積 RTF 可達約 0.02 RTF（生成速度約為即時播放的 50 倍）。
在硬體門檻方面，由於底層採用 vLLM 作為推論引擎以支援高併發與低延遲：
- 低顯存 profile (
low-vram)：支援 1 個 CB0 活躍序列，需要至少 24GB VRAM。 - 平衡 profile (
balanced，預設)：支援 3 個 CB0 活躍序列，需要至少 24GB VRAM。 - 高吞吐 profile (
high-throughput)：支援 8 個 CB0 活躍序列，建議準備 32GB VRAM。
若額外啟用英文 Verbalizer 模型，還需增加約 4.8 至 5.5 GiB 的 VRAM 預算。
與主流語音產品的對比實測
為了評估實際讀語音的表現，官方使用 400 段取自 Project Gutenberg (PG-19) 的英文有聲書文本（每段 250–500 字元），由 Gemini 3.1 Pro Preview 進行雙盲雙向評測（LLM-as-a-judge，共 800 次評估），在「韻律（Prosody）」與「文字正確性（Correctness）」兩個維度上與商業及開源 TTS 模型進行對比：
| 比較對象 | 韻律偏好率 (Prosody) | 文字正確率 (Correctness) | 平局率 (Tie Rate) |
|---|---|---|---|
| ElevenLabs Flash v2.5 | 50.1% | 48.9% | 韻律 9.2% / 正確性 80.2% |
| Fish Audio S2 Pro | 82.1% | 49.6% | 韻律 5.8% / 正確性 77.8% |
| Gradium API (2026年4月版) | 86.2% | 54.6% | 韻律 3.9% / 正確性 69.6% |
| Cartesia Sonic 3 | 82.3% | 60.8% | 韻律 1.9% / 正確性 61.8% |
測試結果顯示，TontaubeV1 在英文有聲書朗讀的韻律上達到與商用頂尖服務 ElevenLabs Flash v2.5 相近的表現（50.1% 接近打平），並顯著優於 Fish Audio S2 Pro、Gradium API 與 Cartesia Sonic 3。
此外，在 Seed-TTS 評測集的 1,088 個英文零樣本測試中，TontaubeV1 搭配 Whisper large-v3 語音辨識測得的平均字詞錯誤率（WER）為 1.66%。
實際怎麼開始？先看模型卡，再決定部署方式
官方模型權重放在 Hugging Face 的 TontaubeV1 頁面，推理程式碼則在 craitech/tontaube GitHub。目前最穩妥的做法是按照 GitHub 的安裝與啟動說明，使用匹配版本的推理程式，不要只下載權重後自行猜測輸入格式。
想先聽效果，可以使用 Tontaube Playground。如果你需要了解訓練資料、音質評估與限制，應直接閱讀 TontaubeV1 technical report，而不是只根據展示頁的幾個短句下結論。相關研究版本也已整理在 arXiv 論文頁面。社群討論可參考 Reddit 發布討論。
實作上，建議先用三種輸入測試：一段短句、一段兩到三分鐘的文章，以及含有數字、英文縮寫與專有名詞的腳本。這樣比較容易分辨問題到底來自聲音品質、長上下文，還是文字正規化。
適合誰？又有哪些限制？
TontaubeV1 適合需要自行掌握音訊資料、想做長篇旁白、播客草稿、有聲書原型或內部語音服務的開發者。開放權重也讓團隊可以針對延遲、批次和儲存方式調整，而不必把完整文字送到第三方 API。
但它目前仍有幾個不能忽略的限制：
- 語言支援範圍：主要為英語和德語，其他 5 種語言未經母語人士大規模評估；
- 硬體資源要求高：需要至少 24GB 以上 VRAM 的顯卡才能順暢運行；
- 聲音複製風險：涉及明確的授權與冒用風險。若要複製真人聲音，應先取得聲音持有人的同意，並在產品中清楚標示合成內容。
如果你的需求是手機端離線朗讀、支援大量語言，或只想快速做一個低成本 API，TontaubeV1 未必是第一個選擇。它真正值得看的地方，是把長篇語音的上下文、串流和本機服務當成同一個系統問題處理。
導入前可以怎麼測？
不要只拿一個短句聽一次就決定是否採用。比較有意義的測試可以分成四組：短句與標點、三到十分鐘的長篇連續性、包含日期金額與英文縮寫的難讀文字，以及單人播放和多請求批次下的首音延遲、RTF、GPU 記憶體和錯誤率。
這些測試也能幫助你決定是否真的需要 vLLM batching。若產品只是一次產生一段旁白，降低首音延遲可能比追求最高批次吞吐量重要；若是播客或大量有聲書製作，批次效率才會直接影響成本。
聲音複製則要額外記錄參考音檔的授權、來源和使用範圍，並在資料庫中保留刪除與撤回機制。長篇 TTS 還有一個常被忽略的產品問題：輸出失敗時要不要從頭重做。若系統以串流方式直接把音訊送給播放器，後半段發現專有名詞念錯，就很難只替換中間一小段。因此比較穩妥的流程，是先以句子或段落為單位生成並保存 metadata，再決定哪些片段可以立即播放、哪些片段要等文字正規化和品質檢查完成。
