Select Page
dots.tts 是什麼?3 秒聲音復刻背後的開源 TTS 架構整理

dots.tts 是什麼?3 秒聲音復刻背後的開源 TTS 架構整理

開源 TTS 最近很熱,但 dots.tts 值得特別看,原因不是只有聲音像,而是它把文字轉語音的路線又往前推了一步,它是一個 2B 參數的全連續端到端自回歸 TTS 系統,官方說明裡最關鍵的一句話是,整條管線不使用離散 token,而是用連續 latent 來完成語音生成。

如果你已經看過 Qwen3-TTS 的音色設計,或之前玩過 VoxelCPM 本地聲音復刻,dots.tts 可以放在同一條脈絡裡理解,以前很多 TTS 工具在可用性上已經不差,現在競爭點開始變成音色相似度、情緒穩定度、跨語言保真,以及能不能進一步做成即時語音 Agent 的底層能力。

先講結論

dots.tts 最適合被理解成一個偏研究與工程兼具的開源 TTS 底座。它不是只把文字念出來,而是把語意編碼器、LLM、自回歸 flow-matching 聲學頭、48 kHz AudioVAE 和 speaker x-vector 接成一條完整語音生成管線。

它目前最吸引人的地方有三個。

第一,官方釋出 pretrained、SCA 和 MeanFlow distilled 三種 checkpoint。

第二,SCA 版本主打更好的 voice cloning 表現。

第三,MeanFlow 版本用比較少的取樣步數換取推理速度,比較適合在產品或本地服務裡評估。

dots.tts 是什麼

dots.tts 是一個 2B 參數的 fully continuous end-to-end autoregressive text-to-speech 系統。官方 README 寫得很直接,它的骨幹由 semantic encoder、LLM 和 autoregressive flow-matching acoustic head 組成,底層則接 48 kHz AudioVAE。

這裡的重點是 fully continuous。傳統語音生成常會把聲音先離散化成 codec token,再讓模型預測 token,dots.tts 選擇不要走這條路,而是在連續 latent 空間裡處理語音。這個設計會讓架構更複雜,但它也讓音色、韻律和情緒細節有更大的保留空間。

三個 checkpoint 怎麼選

官方目前釋出三個 Hugging Face checkpoint,它們共用同一個 backbone,差別在品質、速度與對 voice cloning 的優化方向。

版本定位建議步數適合情境
dots.tts-base預訓練 checkpoint10 到 32想先確認基本品質與架構
dots.tts-soarSelf-corrective-aligned 版本10 到 32重視聲音復刻和音色相似度
dots.tts-mfMeanFlow distilled student4重視速度與部署成本

我會先從 dots.tts-soar 開始測,因為 voice cloning 通常是大家最在意的部分。如果要做服務化,才把 dots.tts-mf 拉進來比較延遲與硬體成本。

它的架構重點

官方架構可以拆成四層來看。AudioVAE 負責把 48 kHz mono waveform 編碼成連續 latent,也負責還原成聲音。Semantic encoder 會把新生成的 VAE patch 重新編碼成較緊湊的語意表示,LLM 由 Qwen2.5 1.5B Base 初始化,直接吃 BPE text。最後的自回歸 flow-matching acoustic head 則負責預測下一段聲音 latent。

這個設計有一個很有意思的方向。它不只是 TTS,也比較像是在替語音互動系統準備底座,官方提到 1T1A interleaved mode,可以讓一個 BPE token 和一個 audio step 交錯,目標是低延遲 streaming。這就會和 本地即時語音 Agent 的方向接起來。

數據上有多強

官方 benchmark 裡最直觀的是 Seed-TTS-Eval,dots.tts SCA 在中文測試的 WER 是 0.94,英文是 1.30,中文 hard set 是 6.60,平均 WER 是 2.95。這組數字和 Qwen3-TTS、CosyVoice 3、F5-TTS 放在一起看,已經是開源 TTS 裡非常前段的位置。

模型參數量英文 WER中文 WER中文 hard WER平均 WER
dots.tts SCA2B1.300.946.602.95
Qwen3-TTS1.7B1.231.226.763.07
CosyVoice 31.5B2.221.125.833.06
F5-TTS0.3B2.001.538.674.10
dots.tts 與其他開源 TTS 在 Seed-TTS-Eval 平均 WER 的比較
平均 WER 越低代表文字內容錯誤率越低。這張圖只取官方 README 表格中的部分模型,方便快速比較。

另一個值得注意的是 MiniMax Multilingual,官方寫到 dots.tts SCA 的平均 speaker similarity 是 83.9,並且在 24 種語言裡有 19 種取得 SIM 領先,另有 2 種並列,這代表它的聲音相似度不是只在中文或英文好看,而是有跨語言保存音色的能力。

本地部署先看這幾件事

官方建議用 Python 3.10 到 3.12 開新的 conda environment,再從 source 安裝。這類語音模型通常對套件版本很敏感,所以我會照官方 constraints 跑,不會一開始就混用自己環境裡的 torch、transformers 或音訊套件。

conda create -n dots_tts python=3.10 -y
conda activate dots_tts
python -m pip install --upgrade pip
python -m pip install -e . -c constraints/recommended.txt

最小測試可以用 CLI。voice cloning 建議給一段乾淨 reference audio,官方建議大約 10 秒就好,太長不會帶來更好的結果。更重要的是 prompt text 要和 reference audio 實際說的內容一致,不一致會讓穩定度變差,甚至出現 word-level 錯誤。

dots.tts   --model-name-or-path rednote-hilab/dots.tts-soar   --text "這是一段語音合成測試"   --prompt-audio /path/to/reference.wav   --prompt-text "參考音訊實際說出的文字"   --num-steps 10   --output clone.wav

我會怎麼測 dots.tts

第一輪不要急著做長文朗讀,先準備三種 reference audio,分別是乾淨女聲、乾淨男聲、帶一點情緒的自然說話,每段控制在 8 到 12 秒,背景聲音越少越好,然後用同一段中文、英文和中英混合文字跑三次,看它的穩定度和語言切換表現。

第二輪才測情緒與語氣,這裡不要只聽像不像,還要看文字內容是否漏字、重複、破音,還有語尾是否自然,TTS 如果只追求音色相似,很容易忽略可讀性,真正能進工作流的 TTS,應該是長時間輸出也不容易出錯。

第三輪測 streaming,官方 Python API 提供 generate_stream,這對語音助理、客服機器人、角色互動很重要,這也能和我之前整理的 audio.cpp 本地語音 AI 底座 放在一起看,未來本地語音工作流很可能會走向 ASR、LLM、TTS 都可替換的模組化架構。

限制也要先看清楚

dots.tts 不是所有語言都一樣穩,官方風險與限制裡提到,低資源語言會有 WER gap,特別是阿拉伯文、印地文、土耳其文、越南文這類資料覆蓋比較吃緊的語言,它可以保住 speaker similarity,但文字正確率不一定跟高資源語言一樣漂亮。

另一個限制是訓練資料偏 speech-heavy,AudioVAE 雖然原則上是 modality-agnostic,但這次釋出的模型不涵蓋唱歌,也不是統一的 speech 加 sound generation 模型。所以如果你的需求是歌曲翻唱、音效生成或完整聲音設計,它不是最直接的答案。

我的判斷

dots.tts 最值得關注的不是 3 秒復刻這種口號,而是它把開源 TTS 拉到更接近產品級底座的位置,2B 參數、連續 latent、自回歸 flow matching、SCA 對齊、MeanFlow 蒸餾,這些都不是單純 demo 型專案會一次放齊的東西。

如果你只是想快速產生中文旁白,現成工具可能更省事,如果你想研究本地 voice cloning、即時語音 Agent、跨語言音色保留,或把 TTS 放進自己的產品工作流,dots.tts 很值得列入測試清單

延伸資源

FAQ

dots.tts 適合拿來做聲音復刻嗎?

適合評估,尤其是 dots.tts-soar。官方把它定位成 voice cloning 表現最好的 checkpoint,但實際品質仍取決於 reference audio 是否乾淨,以及 prompt text 是否和參考音訊一致。

dots.tts-mf 和 dots.tts-soar 差在哪裡?

dots.tts-soar 偏向品質與聲音復刻,dots.tts-mf 是 MeanFlow distilled student,官方建議 4 steps,目標是降低推理成本與提升速度。

參考音訊要多長?

官方建議大約 10 秒。更長不一定更好,乾淨、高取樣率、低背景噪音、自然說話,比單純拉長音訊更重要。

dots.tts 可以做唱歌或音效生成嗎?

不建議把它當成這類任務的主要方案。官方限制裡寫到這次釋出偏 speech-heavy,沒有覆蓋唱歌,也不是 speech 加 sound 的統一生成模型。

Mossland 是什麼?MOSS-TTS 搭配數字人工作流整理

Mossland 是什麼?MOSS-TTS 搭配數字人工作流整理

AI 數字人最容易卡住的地方,不是單一模型不夠強,而是聲音、口型、表情、角色圖像和剪輯工具分散在不同地方。Mossland 值得注意的地方,是它把語音創作和圖視頻生成放進同一個平台,讓「先有聲音,再有角色,再變成可交付內容」這條路更短。

這次重點可以拆成三個部分:

第一是 MOSS-TTS V1.5 這類更有情緒與控制能力的語音模型。

第二是 Bernini-R SVI 這類數字人動態表現端。

第三是 Mossland 作為創作平台,把音色庫、資產庫、工具集和 AVATAR 串起來。

先講結論

  • Mossland 不是單純 TTS 網站,而是一站式 AI 語音與圖視頻創作平台。
  • MOSS-TTS 的價值在聲音品質、音色控制、長文本穩定性和零樣本聲音復刻。
  • MOSS-TTSD 補上多角色長對話,對播客、短劇、互動內容和教學旁白更有用。
  • Bernini-R SVI 的定位可以放在「讓角色動起來」這一端,和 TTS 組合後才像完整數字人工作流。
  • 如果你已經在研究 數字人模型與 RunningHub 工作流,Mossland 這類平台可以當作更偏創作者的整合入口。

Mossland 的平台定位

Mossland 官網把功能分成幾個入口:語音合成、音色設計、音頻轉寫、音色轉換、音頻降噪、圖視頻生成和 AVATAR 數字人。這個排列很清楚,它不是只做聲音,而是想把內容生產流程往後接到視覺端。

對創作者來說,這種平台最直接的價值是少切工具,以前可能要先用 TTS 生旁白,再到另一個工具做口型或角色動態,最後再進剪輯軟體,Mossland 的方向是把聲音、素材、模板和數字人放在同一個工作台裡。

這也跟 RunningHub 把 ComfyUI 工作流平台化 的邏輯相似,底層可能有多個模型和流程,但真正讓非工程使用者覺得好用的,是模板、入口、資產管理和可重複的工作流。

MOSS-TTS 的重點不是只會念字

MOSS-TTS Technical Report 把 MOSS-TTS 定位成語音生成基礎模型,它採用離散音訊 token、自回歸建模和大規模預訓練,並建立在 MOSS-Audio-Tokenizer 上。

真正值得注意的是控制能力,MOSS-TTS 支援零樣本聲音復刻、token 級時長控制、音素與拼音級發音控制、中英切換和長文本穩定生成。這些能力對數字人很重要,因為數字人不是只要聲音像,還要節奏、情緒和發音能配合角色。

如果你之前看過 Qwen3-TTS 和音色設計,就會知道現在開源語音模型的競爭,已經不只是「像不像真人」。更重要的是能不能穩定控制語氣、角色感、長句節奏和跨語言表現。

MOSS-TTSD 補上長對話和多角色

一般 TTS 很適合單人旁白,但數字人內容常常需要對話、角色切換和長時間穩定輸出,MOSS-TTSD 的定位就是 Text to Spoken Dialogue,可以從帶有說話者標籤的劇本生成多角色語音。

論文提到它支援最長 60 分鐘單次合成、最多 5 位說話者的多方對話,也支援用短參考音訊做零樣本聲音復刻。這對播客、動態解說、短劇、互動內容都很關鍵,因為真正有用的不是一小段試聽,而是能不能撐完整內容。

這也呼應我之前整理 本地語音 AI 統一底座 時的觀察:語音模型下一步要處理的不只是音質,而是長上下文、角色一致性、語者歸屬和整段內容的穩定性。

Bernini-R SVI 的角色:讓聲音變成可看的角色

如果 MOSS-TTS 負責聲音,那 Bernini-R SVI 這類模型就可以理解成數字人畫面端,也就是把角色圖像、動態表現、口型或視覺演出接上語音,讓內容從「一段旁白」變成「一個角色在說話」。

這裡最重要的不是單點能力,而是組合後的可交付性,單獨一個漂亮聲音不一定能變成短影音,單獨一張角色圖也不一定能支撐內容。但當語音模型和 SVI 數字人動態搭起來,就比較接近創作者每天能用的工作流。

這和 讓照片動起來的數字人方向 是同一條線,只是現在更重視整套內容管線,而不是單次展示。

Mossland 工作流怎麼看

階段主要能力對內容創作者的價值
聲音MOSS-TTS 語音合成與音色設計讓角色聲音更自然且可控
對話MOSS-TTSD 長對話與多角色語音適合旁白、播客、短劇與互動內容
畫面圖視頻生成與 AVATAR 數字人把聲音變成可交付的視覺內容
平台音色庫、資產庫、工具集與 AI 應用降低從素材到成品的組裝成本
Mossland 數字人內容工作流表格
Mossland 的價值在於把聲音、對話、畫面和平台工具接成一條內容生產線。

適合誰使用

第一類是短影音創作者。這類人需要快速產出角色旁白、社群內容、產品介紹和教學短片,平台化工具會比自己串模型更省時間。

第二類是品牌或電商內容團隊。商品介紹、活動宣傳、客服說明和直播切片都需要大量聲音與角色素材。只要品質穩定,數字人可以降低重複錄製成本。

第三類是 AI 工作流玩家。這類人可能仍會偏好本地部署,但可以把 Mossland 當作快速驗證平台,先看聲音和角色組合是否有市場感,再決定要不要回到本地工作流重做。

我會注意的限制

第一,聲音好不代表數字人就自然。角色表情、口型同步、鏡頭節奏、身體動作和背景設計都會影響成品。很多數字人看起來不自然,不是 TTS 的問題,而是視覺端沒有跟上。

第二,平台好用不代表資料風險消失。如果要上傳真人聲音、商業腳本或品牌素材,要先確認授權、隱私和使用條款。聲音復刻尤其要小心,最好只用自己有權使用的聲音。

第三,開源免費不等於零成本。模型、平台、素材整理、後製、審稿和版權確認都要算進去。真正的成本常常不是生成,而是讓生成結果可以被公開使用。

我的判斷

Mossland 這類平台反映了一個很明確的趨勢:AI 內容工具正在從單點模型,變成可組裝的內容生產線。TTS 模型負責聲音,SVI 或數字人模型負責角色動態,平台負責模板、資產和交付流程。

如果你只是想研究模型,MOSS-TTS 和 MOSS-TTSD 的技術報告值得看。如果你想做內容,重點應該放在「整條流程能不能穩定產出」。這也是我會關注 Mossland 的原因,它不是只展示某個模型,而是把語音和視覺創作接在一起。

對台灣創作者來說,我會先用它測三件事:中文語氣是否自然,角色畫面是否能承受社群平台放大檢視,整體流程是否比自己串 ComfyUI 或本地工具更省時間。這三件事過關,才有真正導入價值。

延伸資源

FAQ

Mossland 是什麼?

Mossland 是 MOSI Studio 的一站式 AI 語音與圖視頻創作平台,提供語音合成、音色設計、音頻轉寫、音色轉換、降噪、圖視頻生成與 AVATAR 數字人等功能。

MOSS-TTS 適合做什麼?

MOSS-TTS 是語音生成基礎模型,重點包含零樣本聲音復刻、發音控制、長文本穩定生成、多語言與中英切換能力,適合旁白、角色配音和內容生產。

MOSS-TTSD 和一般 TTS 差在哪?

MOSS-TTSD 面向多角色長對話,可以用明確說話者標籤生成長篇對話,支援多方對話、長時間合成和短參考音訊聲音復刻,更適合播客、短劇和互動內容。

Bernini-R SVI 在工作流中扮演什麼角色?

Bernini-R SVI 可以理解成影像和數字人動態表現端,MOSS-TTS 負責聲音,SVI 負責讓角色畫面跟聲音一起變成可交付內容。

Mossland 適合本地部署玩家嗎?

如果目標是研究模型或完全離線,本地部署仍有價值。如果目標是快速做內容,Mossland 這類平台的優勢是把音色庫、工具集、模板和 AVATAR 串起來,降低組裝成本。

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 服務地址與模型名稱,就能接入本地語音服務。

Qwen3-TTS 是什麼?音色設計補上開源 TTS 最大短板

Qwen3-TTS 是什麼?音色設計補上開源 TTS 最大短板

Qwen3-TTS 這次真正補上的,不只是「又一個開源 TTS 模型」,而是把 AI 語音從單純文字轉語音,往「可以設計聲音」推了一步。對創作者來說,這個差異很大:以前多半是找一段參考音頻去克隆,現在可以先用文字描述你想要的音色,再生成符合角色感的聲音。

我會把 Qwen3-TTS 放在本地 TTS 工具鏈的一個重要位置:它不是完全取代 Index TTS2,也不是只適合做 demo,而是補上了「音色捏臉」這個創作端很需要的能力。尤其當它被包進 ComfyUI 節點後,對做短片、角色對白、旁白、多角色音頻工作流的人會更順手。

如果你之前已經看過 VoxelCPM 本地 TTS本地即時語音 Agent,Qwen3-TTS 可以理解成另一條更偏「創作型語音生成」的路線。

先講結論:Qwen3-TTS 最值得看的是音色設計

Qwen3-TTS 的幾個核心能力可以拆成三塊:音色設計、音色克隆、自訂聲音與情緒控制,音色克隆大家比較熟,給一段參考音頻,再讓模型生成相似聲音;真正新鮮的是音色設計,你可以用提示詞描述聲音,例如年齡、性別、顆粒感、情緒、語氣、角色氣質。

這件事對內容創作很實用。做科幻短片時,你可以要一個「低沉、沙啞、有壓迫感的中年男聲」;做兒童故事時,可以要「明亮、溫柔、帶笑意的年輕女聲」;做遊戲角色時,可以先把聲音當成角色設定的一部分,而不是等拿到參考音頻後才開始克隆。

這也是 Qwen3-TTS 和 Index TTS2 的關鍵差異,Index TTS2 在參考音頻和情緒控制上仍然很靈活,但 Qwen3-TTS 把「從文字描述生成音色」這件事做成主能力,兩者不是誰完全取代誰,而是切入點不同。

Qwen3-TTS 的三種用法

從 ComfyUI 節點 README 來看,HAIGC 的 Comfyui-HAIGC-QwenTTS 把 Qwen3-TTS 包成幾個常用節點,最核心的是模型載入、聲音設計、聲音克隆、自訂聲音、角色預設保存與多角色對話合成。

用法需要的模型適合場景限制
聲音設計VoiceDesign用文字描述角色聲線,先捏出音色需要會寫清楚聲音提示詞
聲音克隆Base用參考音頻生成相似聲音需要參考音頻與對應文本
自訂聲音CustomVoice使用預設說話人或提示詞控制聲音情緒與音色控制受模型能力限制
多角色對話搭配角色預設短劇、廣播劇、遊戲 NPC 對話要管理角色名與預設檔

這裡有一個實作上很重要的細節:模型要放在 `ComfyUI/models/qwen-tts/` 下面,節點不會幫你自動下載模型。也就是說,這不是裝好節點就直接能跑,還要自己把 Qwen3-TTS 的對應模型資料夾放到正確位置。

ComfyUI 節點讓它更像創作工作流

如果只看 TTS CLI,Qwen3-TTS 會比較像模型測試。但進到 ComfyUI 節點後,它就開始有工作流價值。你可以把文案、角色聲音、參考音頻、角色預設、多角色對話接成流程,最後輸出可用音頻。

這對影片創作者尤其實用。前面整理 OpenMontage 本地 AI 影片工作流時也提過,影片生成不是只有畫面,旁白、角色語音、字幕和音效都是完整作品的一部分。Qwen3-TTS 這類工具的價值,就是把聲音也放進可控流程裡。

站上之前也整理過 ComfyUI 本機部署工作流。圖像生成和 TTS 看起來是不同領域,但 ComfyUI 的優勢都是一樣的:把模型變成節點,讓創作者能用流程管理。

音色設計:最像「聲音捏臉」的功能

音色設計最適合用在你還沒有參考音頻,但已經知道角色感的情境。比方說,你想要一個「沙啞、低沉、帶警告意味的戰士聲音」,傳統聲音克隆會問你:參考音頻在哪裡?Qwen3-TTS 的 VoiceDesign 則是讓你先用文字描述聲音。

這對角色型內容很關鍵。短劇、遊戲、動畫、解說頻道,都常常不是缺一個真實人聲,而是缺一個「符合角色設定」的聲音。音色設計讓 TTS 從工具變成創作材料,這是我覺得 Qwen3-TTS 最值得測的地方。

但提示詞也會變成新門檻。你不能只寫「好聽的聲音」,最好描述清楚年齡、性別、音域、情緒、語速、質感、場景。例如:

A deep, raspy middle-aged male voice, slow pace, serious and threatening tone, cinematic fantasy character.

中文也可以寫,但英文描述通常比較容易控制細節。之後如果要大量產角色聲音,我會建議把常用聲音提示詞整理成自己的 prompt library。

聲音克隆:自然度不錯,但仍要看參考音頻品質

Qwen3-TTS 的聲音克隆需要參考音頻,也最好提供參考音頻對應的文本,這點和很多 zero-shot voice cloning 工具一樣:參考音頻越乾淨,語速和情緒越穩,克隆結果越容易自然。

這裡我會提醒兩件事。第一,不要拿太吵、太短、音量忽大忽小的音頻當參考;第二,克隆聲音牽涉聲紋與授權問題,不要拿真人聲音去做未經同意的商業使用,工具越方便,這條線越要自己守住。

如果你主要目標是語音克隆,可以把 Qwen3-TTS 和 VoxCPM 語音克隆一起測,不要只看單句 demo,要測長句、情緒、停頓、重複生成穩定性。

情緒控制:Qwen3-TTS 和 Index TTS2 的取捨

Qwen3-TTS 可以透過自訂聲音與預設說話人做某種程度的情緒與語氣控制,但這裡要小心期待值,它的自訂情緒方式更偏「用預設或提示詞控制」,而 Index TTS2 在某些情境下則可以直接用參考音頻帶出情緒,操作上會更直覺。

所以我不會說 Qwen3-TTS 全面打掉 Index TTS2。更準確的說法是:

  • 你想從文字描述直接設計聲音,Qwen3-TTS 更值得測。
  • 你有很好的參考音頻,想保留聲音和情緒,Index TTS2 仍然有優勢。
  • 你要做 ComfyUI 影音工作流,Qwen3-TTS 節點會更容易串進流程。
  • 你要穩定量產,兩者都要測長文本、批次生成和錯誤率。

安裝與使用時先注意這幾點

  1. 模型要自己下載:節點預設讀 `ComfyUI/models/qwen-tts/`,資料夾命名要和模型後綴一致。
  2. 先確認模型類型VoiceDesign、Base、CustomVoice 對應的功能不同,載錯模型就會覺得節點怪怪的。
  3. FP16 / FP32 和 CUDA 要看環境GPU 跑得快,但顯存、驅動、torch 版本都會影響穩定性。
  4. 角色預設要管理好如果要做多角色對話,角色名、.pt 預設檔和對白格式最好固定。
  5. 節點早期可能有 bug遇到預設節點跑不起來,先看 GitHub issue 和最新 commit,不要急著判定模型不可用。

如果你只是想快速試用,也可以先用 ModelScope 的 Qwen3-TTS demoRunningHub 工作流感受效果。真正要放進自己的內容生產流程,再回頭做本地 ComfyUI 部署。

適合誰?

我覺得 Qwen3-TTS 特別適合四種人。

  • 短片創作者。需要快速做旁白、角色音、警告音、廣播音,不想每次找真人錄音。
  • 遊戲與互動敘事作者。多角色對話、NPC 聲音、角色預設會很有用。
  • ComfyUI 工作流玩家。想把聲音生成接進圖像、影片、字幕和後製流程。
  • 本地 AI 研究者。想比較 Qwen3-TTS、Index TTS2、VoxCPM、ChatTTS 等不同開源 TTS 路線。

如果你只需要最簡單的文字轉語音,反而不一定要上這套。Qwen3-TTS 的價值在於音色設計、角色聲音與工作流整合,而不是單純把一段文字念出來。

資源整理

Qwen3-TTS 補上的是創作者最想要的控制感

Qwen3-TTS 最讓我在意的,不是它又多會念文字,而是它讓聲音開始可以被設計。對內容創作來說,聲音不是最後補上的配件,而是角色、情緒和敘事的一部分。

它目前還不是無腦安裝、無腦量產的工具。模型要自己放、節點要確認版本、不同功能要對應不同模型,ComfyUI 工作流也需要一點整理。但方向很明確:TTS 正在從「文字轉語音」進化成「聲音設計工具」。

一句話總結:Index TTS2 仍然香,但 Qwen3-TTS 把音色捏臉這塊補起來了。之後做角色語音、短劇旁白、多角色對話,我會把它列入優先測試清單。

Hugging Face speech-to-speech:本地即時語音 Agent 怎麼跑?

Hugging Face speech-to-speech:本地即時語音 Agent 怎麼跑?

Hugging Face 的 speech-to-speech 真正有趣的地方,不只是「本地 AI 語音聊天」這句話,而是它把即時語音 Agent 拆成一條清楚的工程管線:VAD 偵測你什麼時候開始和結束說話,STT 把語音轉成文字,LLM 產生回應,TTS 再把文字變回聲音。

這條路線的價值很直覺:如果你不想把麥克風聲音、私人對話、公司資料一路送到雲端,那就把語音 Agent 搬回自己的機器。代價也很明顯:你要處理 Python、FFmpeg、CUDA、模型下載、本地 LLM server、TTS 後端、瀏覽器端 WebSocket。這不是「安裝一個 App 就結束」的工具。

如果你之前看過 VoxelCPM 本地 TTS,這篇可以當成下一步:TTS 只是讓 AI 開口,speech-to-speech 則是把「聽、想、說」接成一個即時循環。

先講結論:它不是語音模型,而是一條可替換的語音 Agent 管線

huggingface/speech-to-speech 的 README 把架構講得很清楚:這是一條低延遲、模組化的 voice-agent pipeline,順序是 VAD → STT → LLM → TTS,並且透過 OpenAI Realtime-compatible WebSocket API 對外提供服務。

也就是說,你可以把支援 OpenAI Realtime 協議的 client 指到本機 server。

這個設計比單純做一個 demo 更有意思,因為每一段都能換。

STT 可以用 Parakeet、Whisper、Faster Whisper、MLX Whisper 或 Paraformer;LLM 可以接 OpenAI-compatible provider,也可以接 vLLM、llama.cpp、llama-server;TTS 可以用 Qwen3-TTS、Kokoro、Pocket TTS、ChatTTS 或 MMS TTS。

換句話說,它的重點不是某個模型最強,而是把語音 Agent 做成可插拔架構。

這和 OpenWork / OpenCode 工作台的方向有點像:真正可長期使用的 AI 工具,不應該只綁死在單一供應商或單一模型。

Speech-to-speech 和傳統語音翻譯有什麼差別?

Hugging Face Audio Course 裡對 speech-to-speech translation 的說明很適合拿來釐清概念。

傳統機器翻譯是文字到文字,speech-to-speech 則是語音到語音。最常見的做法是串接:先把語音轉成文字,再做翻譯或生成,最後合成語音。

它也提醒一個很重要的問題:管線越長,錯誤越會累積,延遲也越高。

ASR 認錯一個字,後面的 LLM 可能照著錯字理解;LLM 回答太長,TTS 就要等更久;TTS 聲音不自然,最後體驗還是會掉下來。

所以本地即時語音 Agent 的關鍵不是只看「能不能講話」,而是看四件事:

  • 語音辨識是不是準,尤其是中文、口音、背景噪音。
  • LLM 回應是不是夠快,不要讓人等到出戲。
  • TTS 聲音是不是自然,長時間聽會不會疲勞。
  • 整條管線的延遲是不是穩定,而不是偶爾順、偶爾卡。

官方預設路線:先跑起 realtime server

官方 quickstart 很短:

pip install speech-to-speech
export OPENAI_API_KEY=...
speech-to-speech


跑起來之後,server 會在本機開一個 OpenAI Realtime 相容端點,常見位置是:
ws://localhost:8765/v1/realtime

預設路線會用本地 STT、本地 TTS,再把 LLM 接到 OpenAI-compatible API。你如果想讓 LLM 也留在本機,可以用 llama.cpp 啟動本地模型 server,再把 `responses_api_base_url` 指到本機。

speech-to-speech \
  --model_name "ggml-org/gemma-4-E4B-it-GGUF" \
  --responses_api_base_url "http://127.0.0.1:8080/v1" \
  --responses_api_api_key ""


這裡的重點是 OpenAI-compatible。只要你的本地 LLM server 能提供類似 OpenAI API 的介面,它就有機會接進來。這也是為什麼 Ollama 遠端連線和本地 OpenAI-compatible server 的設定很重要:語音只是入口,真正回答問題的是後面的 LLM。

Windows 實作路線:不是難,是零件很多

核心流程可以簡化成這樣:

  1. 裝 Python 3.11、Git、FFmpeg。
  2. 建立 `C:\s2s` 之類的資料夾,開 venv。
  3. 安裝 `speech-to-speech`。
  4. 用 llama.cpp 跑本地 Qwen 模型,開在 `http://127.0.0.1:8080/v1`。
  5. 啟動 speech-to-speech,把 STT 指到 Whisper、LLM 指到本地 server、TTS 指到 Qwen3-TTS。
  6. 開網頁 client,WebSocket 指到 `localhost:8765`。

這裡最容易踩坑的是 FFmpeg 和 winget。留言裡有人遇到 `winget` 找不到,這通常代表 Windows App Installer / winget 沒裝好,或 PowerShell 環境找不到它。這時候不要卡在同一條命令,可以改成手動下載 FFmpeg,或先修好 winget,再重新開 PowerShell。

架構表:每一段都可以替換,但每一段也都會出事

階段作用常見選擇容易卡住的地方
VAD判斷使用者何時開始/停止說話Silero VAD背景噪音、切句太早或太晚
STT語音轉文字Parakeet、Whisper、Faster Whisper中文辨識、口音、GPU/CPU 速度
LLM理解問題並產生回應OpenAI-compatible API、llama.cpp、vLLM、Ollama 類服務延遲、上下文長度、模型能力
TTS文字轉語音Qwen3-TTS、Kokoro、Pocket TTS、ChatTTS聲音自然度、CUDA wheel、中文品質
Client麥克風輸入與播放Realtime WebSocket client、網頁呼吸球介面瀏覽器權限、WebSocket 位置、服務啟動順序

這張表就是我對本地語音 Agent 的看法:模組化很香,但你不能只看成功 demo 任一段延遲太高、模型太大、依賴裝錯、WebSocket 指錯,都會讓整體體驗掉下來。

4GB 顯存、4090、CPU:期待值要分開看

如果你只是想體驗,本地小模型加 CPU/GPU 混跑可以試;如果你想每天使用,就要認真看顯卡、VRAM、記憶體、模型大小與量化格式。這部分可以搭配 AI 工作站顯卡選購那篇看,因為語音 Agent 不是只吃一個模型,而是一整條 pipeline。

本地部署值不值得?

安裝太複雜、Python 依賴一直重裝、免費雲端語音也能用、中文場景不一定比微信等現成工具舒服。

我會這樣判斷:

  • 如果你只想偶爾語音聊天,雲端 App 更省事。
  • 如果你在意隱私、離線、可控模型,本地 speech-to-speech 才有意義。
  • 如果你要接自己的 Agent 或自動化流程,OpenAI Realtime 相容 API 很有價值。
  • 如果你不想處理依賴,等整合包或 Docker / 一鍵腳本會比較舒服。

有留言建議做整合包,把 Python、虛擬環境、依賴、模型檔都打包好。這個方向很務實。語音 Agent 要走向一般使用者,最重要的可能不是模型再強一點,而是安裝流程少掉一半。

接進 Hermes、OpenWork 或自己的 Agent:語音只是入口

有人問如果部署在 Hermes 裡,是不是就不用打字了。方向是對的,但要分清楚:speech-to-speech 解決的是語音輸入與語音輸出,Agent 真正能不能工作,還要看後面的工具調用、上下文、記憶、權限與任務執行。

也就是說,語音不是 Agent 的全部,只是更自然的控制入口。你可以想像之後用語音叫本地 Agent 幫你查資料、改檔案、跑腳本、操作工作流,但這需要像 OpenWorkHermes Agent 這類工作台或 runtime 來承接任務。

真正有用的組合會是:speech-to-speech 負責「聽和說」,Agent runtime 負責「做事」,本地 LLM / 工具 / MCP 負責「連到你的資料和系統」。語音只是讓人更容易下指令,不能替代完整的任務架構。

資源整理

本地即時語音 Agent 很香,但現在還偏工程師玩具

speech-to-speech 讓本地語音 Agent 的架構變得很清楚:你可以把 VAD、STT、LLM、TTS 串起來,對外提供 OpenAI Realtime 相容 API,再用網頁或其他 client 連進來。這條路很有想像空間,尤其適合隱私敏感、離線使用、機器人、客服、語言練習、自建 AI 助手。

但我不會把它包裝成人人都該裝。現階段它還需要處理太多環境問題,Windows 下尤其明顯。真正適合的人,是願意花時間把本地模型、音訊依賴、GPU、WebSocket 和 Agent runtime 串起來的人。

一句話總結:本地即時語音不是為了取代手機上的語音助手,而是為了把「能聽、能想、能說」這個入口,接到你自己的模型、資料和工作流上。這件事如果跑順,會比單純聊天更有價值。

FAQ

speech-to-speech 是什麼?

speech-to-speech 是 Hugging Face 的開源語音 Agent 管線,透過 VAD、STT、LLM、TTS 四個階段,把使用者語音轉成模型回應,再合成語音輸出。

它可以完全本地運行嗎?

可以,但需要把 STT、LLM、TTS 都換成本地後端,例如 Whisper、llama.cpp 或其他 OpenAI-compatible 本地 LLM server,以及 Qwen3-TTS 等本地語音合成模型。

為什麼不用雲端語音助手就好?

如果只是日常聊天,雲端語音助手更省事。本地方案的價值在於隱私、離線、可控模型、可接自有資料與 Agent 工作流。