Select Page
Voicebox 是什麼?本地 AI 語音工作室與 Agent 發聲工具

Voicebox 是什麼?本地 AI 語音工作室與 Agent 發聲工具

Voicebox 最吸引我的地方,是它不是只做 TTS,也不是只做 Whisper 聽寫,而是把語音輸入、語音輸出、聲音克隆、故事編輯器、REST API 和 MCP server 放在同一個本地優先的工具裡。這讓 AI Agent 不只會回文字,也能用你指定的音色說話。

如果說過去的語音工具常常分成兩邊,ElevenLabs 偏輸出,WisprFlow 偏輸入,那 Voicebox 想做的是完整 voice I/O stack。更重要的是,它預設把模型、聲音資料和錄音留在本機,這對語音克隆和工作資料來說很關鍵。

先講結論

Voicebox 是 Jamie Pine 開源的 AI voice studio,官方定位是 local-first。它可以做文字轉語音、聲音克隆、全域快捷鍵聽寫、Whisper 轉錄、故事多軌編輯,還能透過 REST API 和 MCP server 讓 Claude Code、Cursor、Cline 這類 MCP-aware agent 發聲。

我會把它放在「本地語音 AI 底座」這一類,之前整理過 audio.cpp 本地語音 AI WebUIHugging Face speech-to-speech 本地語音 Agent,Voicebox 則更偏向桌面應用和創作者工具,並且把 Agent 整合做得很直接。

Voicebox 本地語音輸入輸出與 MCP Agent 整合流程圖
Voicebox 把聽寫、轉錄、配音和 Agent 語音輸出放在同一個本地工具裡。

Voicebox 在補語音 AI 的哪一塊

很多語音工具只有單點能力。TTS 工具能把文字變聲音,但不一定能做聽寫。STT 工具能轉錄,但不一定能配音。聲音克隆工具效果強,但常常依賴雲端 API。Voicebox 的取向比較完整:輸入端用 Whisper,輸出端有多個 TTS 引擎,中間還有本地 Qwen3 LLM 做潤飾、角色語氣和 persona。

這種整合方式很適合兩種人:

第一種是內容創作者,想做旁白、podcast、故事對話、角色音色。

第二種是 AI Agent 使用者,想讓 Claude Code、Cursor 或自己的工具在完成任務後,用指定聲音提醒你,而不是只丟一段文字。

7 個 TTS 引擎和 23 種語言

官方 README 列出 7 個 TTS 引擎:Qwen3-TTS、Qwen CustomVoice、LuxTTS、Chatterbox Multilingual、Chatterbox Turbo、HumeAI TADA 和 Kokoro。它們的定位不同,有的適合多語言克隆,有的適合 CPU 快速推理,有的適合加入情緒標籤和語氣控制。

能力Voicebox 的做法適合用途
高品質 TTSQwen3-TTS、Chatterbox、HumeAI TADA 等引擎旁白、教學、產品介紹
聲音克隆用參考音訊做 zero-shot cloning個人聲音、角色聲音、品牌聲線
快速預設音色Kokoro 和 Qwen CustomVoice 提供 50+ 音色快速試稿、多角色對話
語音輸入全域快捷鍵加 Whisper STT聽寫、轉錄、工作筆記

如果你對開源 TTS 的音色設計有興趣,可以搭配看 Qwen3-TTS 的音色設計整理dots.tts 聲音復刻架構。Voicebox 比較像把這些能力打包成桌面工作台,而不是單一模型 demo。

聲音克隆和預設音色的差別

聲音克隆適合你有一段參考音訊,想生成相似聲線。預設音色適合你只是要快速找一個可用聲音,不想準備樣本。Voicebox 同時支援兩種路線,這點很實用。創作者可以先用預設音色打草稿,確定文本節奏後,再換成克隆音色做正式版本。

但聲音克隆也有界線。它很適合克隆你自己擁有權利的聲音,或明確授權的角色聲音。不要拿來模仿名人、同事或客戶聲音做未授權內容。語音模型越容易使用,倫理和授權越要先想清楚。

Whisper 聽寫補上輸入端

Voicebox 的另一半是輸入。它用 OpenAI Whisper 做 speech-to-text,支援全域 dictation hotkey、push-to-talk 和 toggle mode。macOS 上可以把轉錄結果直接貼到目前焦點文字欄位,這會讓它接近一個本地版語音輸入法。

Whisper 對長音訊和技術內容一直很適合。如果你常做訪談、會議紀錄、口述筆記,Voicebox 把 captures、replay、re-transcribe、refine 放在同一個介面裡,會比單純命令列轉錄更順。這裡也可以延伸看之前整理的 Whisper 開源語音轉文字

MCP 讓 Agent 真的開口說話

Voicebox 最有意思的一點,是內建 MCP server,官方 README 寫到它提供 `voicebox.speak`、`voicebox.transcribe`、`voicebox.list_captures`、`voicebox.list_profiles` 四個工具,這代表 MCP-aware agent 可以呼叫 Voicebox,把文字變成指定音色播放出來,也可以讀取 captures 和 voice profiles。

這不只是好玩。Agent 的語音輸出可以拿來做任務完成提醒、錯誤警告、長任務回報、pair programming 對話。你甚至可以把不同 agent 綁定不同聲音,例如 Claude Code 用一個音色,Cursor 用另一個音色,聽聲音就知道是哪個工具在回報。

{
  "tool": "voicebox.speak",
  "arguments": {
    "text": "任務完成,測試已通過",
    "profile": "Morgan"
  }
}

如果你已經在玩 Playwright CLI 讓 Codex 操作瀏覽器,Voicebox 可以補上另一個感官通道。Agent 不只可以操作網頁,也能在完成後直接用語音提醒你。

Stories editor 適合做多角色內容

Voicebox 也有 Stories editor,可以做 conversation、podcast、narrative 這類多段落、多角色內容。這對部落格轉 podcast、教學腳本、角色對話、短劇旁白都很有用。比起一次產生一整段音訊,多軌 timeline 更適合慢慢調整角色、節奏和轉場。

如果你平常會把文章轉成短影片或語音內容,Voicebox 可以放在內容工作流後段。先由 Agent 整理稿件,再用 Voicebox 做角色分配和配音,最後再進剪輯工具。

安裝與使用入口

Voicebox 官方網站是 voicebox.sh,GitHub repo 是 jamiepine/voicebox。官方 README 提供 macOS Apple Silicon、macOS Intel 和 Windows 下載入口,也有開發者本地建置方式。

我會怎麼用

我不會只把 Voicebox 當成免費配音工具:

更有價值的用法,是把它接進 AI Agent 工作流,平常寫文章、整理筆記、跑 Codex、跑 Claude Code,最後都可以由 Voicebox 轉成語音摘要。長任務完成時不用一直盯螢幕,讓 Agent 開口提醒就好。

第二個用法是做內容實驗,先用預設音色快速產出版本,再用克隆音色做正式版。

第三個用法是本地聽寫,把口述想法直接丟進任何 app,再交給 Agent 整理。這會比只靠鍵盤更接近自然工作流。

我的判斷

Voicebox 不是單一模型展示,而是把語音 AI 變成桌面工作台。它的亮點不是某個 TTS 引擎本身,而是整合:本地隱私、TTS、STT、故事編輯、聲音 profile、REST API、MCP server。

如果你只需要偶爾產一段聲音,線上 TTS 服務可能更快。但如果你想要長期建立自己的聲音素材庫、做本地聽寫、讓 Agent 用聲音回報任務,Voicebox 會是值得試的工具。

延伸資源

FAQ

Voicebox 是什麼?

Voicebox 是開源的本地優先 AI 語音工作室,可以做 TTS、聲音克隆、Whisper 聽寫轉錄、故事編輯和 MCP Agent 語音輸出。

Voicebox 可以離線使用嗎?

官方定位是 local-first,模型、聲音資料和 captures 會留在本機。實際能否完全離線,取決於你是否已下載需要的模型和使用的引擎。

Voicebox 支援哪些 TTS 引擎?

官方列出 Qwen3-TTS、Qwen CustomVoice、LuxTTS、Chatterbox Multilingual、Chatterbox Turbo、HumeAI TADA 和 Kokoro。

Voicebox 可以接 Claude Code 或 Cursor 嗎?

可以。Voicebox 內建 MCP server,MCP-aware agent 可以使用 `voicebox.speak`、`voicebox.transcribe`、`voicebox.list_captures` 和 `voicebox.list_profiles`。

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 工作流。