by Rain Chu 9 月 21, 2026 | AI , TTS , 圖型處理 , 影片製作 , 模型 , 虛擬人 , 語音合成 , 語音辨識
AI 女友本地部署，可以做成真正接得上話的語音數位人：當麥克風收音後，由語音辨識轉成文字，Qwen3 產生回答，Qwen3-TTS 合成聲音，再交給 LiveTalking 生成嘴型畫面。角色的回答隨當下對話產生，不只是播放固定台詞。
最實用的起步方式，是先把「聽得懂、答得出、播得出聲音」跑通，再加入人物形象。
這套系統有好幾個服務，任何一層沒啟動，都可能看起來像整個網頁壞掉。
先看懂整套流程：聊天模型只是其中一站
語音互動可拆成五個環節：VAD 判斷你是否正在說話，faster-whisper 辨識語音，Qwen3 組織回覆，Qwen3-TTS 產生音訊，LiveTalking 把音訊轉成嘴型並傳回瀏覽器，畫面與對話分工之後，才有辦法逐層測試。
Hugging Face speech-to-speech 採用可替換元件的語音流程，語言模型可以接自己的 llama.cpp 服務，初次接觸這類架構，可以先看本地即時語音 Agent 的元件分工 ，再加上數位人畫面。
「免 API 費」比較精確的意思，是不必向雲端模型服務支付推理費，程式之間仍可能透過本機 API 溝通，電腦硬體、用電與安裝時間也不會因此消失。
8GB 顯卡能跑嗎？先算所有常駐元件
只看 Qwen3 能不能載入，會低估整套系統的需求。語音辨識、語音合成、嘴型模型、上下文快取與桌面顯示，都可能一起使用顯示記憶體。素材生成階段的 ComfyUI 也有自己的負載，完成底片後應釋放它的資源，再測常駐對話服務。
下表採用作者教學頁 列出的 RTX 4090 配置估算，方便理解資源分配。這些近似值不是本文實測，也不是官方最低需求。
元件 範例配置 約用顯示記憶體 語言模型 Qwen3-14B Q4_K_M 9GB 語音辨識 faster-whisper large-v3 3GB 語音合成 Qwen3-TTS 1.7B 4GB 嘴型同步 wav2lip256 1.3GB
作者配置的近似值，僅供理解各元件負載，不能視為最低硬體門檻。 因此，不能把這份完整配置原封不動套到 8GB 顯卡，容量有限時，先選較小的量化 Qwen3、縮短上下文，再評估語音辨識模型與運算位置，faster-whisper 官方效能資料 也顯示，精度與批次設定都會改變記憶體需求，光是模型名稱一樣，佔用量仍可能不同。
步驟一：準備 WSL，先確認 GPU 與資料夾
以下以 Windows 搭配 NVIDIA 顯卡及 WSL 2 為主。先安裝 Windows 端的 NVIDIA 驅動，再安裝、更新 WSL，NVIDIA 官方文件 明確說明，WSL 使用 Windows 驅動映射的 CUDA 支援，不要在 WSL 裡另外安裝 Linux 顯示驅動。
Windows PowerShell 的起步指令如下，若已有 Ubuntu，不必重複安裝。
依畫面要求完成重啟與帳號設定後，在 Ubuntu 執行 nvidia-smi 確認顯卡可見。
wsl --update
wsl --install -d Ubuntu-24.04Python 環境、模型處理與執行檔案，建議放在 WSL 的 Linux 家目錄下，Microsoft 的檔案系統建議 是讓 Linux 工具優先使用 Linux 檔案系統，可減少跨系統讀寫負擔，環境基礎可參考Windows 與 WSL 的 AI 開發環境整理 。
WSL 網路設定不是一個開關解決全部問題
Windows 11 22H2 以上可在使用者目錄的 .wslconfig 啟用 mirrored 網路，Microsoft 說明 指出，這種模式支援 Windows 與 WSL 透過 127.0.0.1 互連。記憶體上限則應按實際機器調整，不要照抄別人的容量。
[wsl2]
networkingMode=mirroredhostAddressLoopback=true 是額外允許透過主機其他 IPv4 位址互連的設定，只在 mirrored 模式下適用，官方設定文件 並未說所有 WebRTC 失敗都必須靠它修復。改完設定後，可在保存其他 WSL 工作後執行 wsl --shutdown，再重新啟動環境。
步驟二：先讓 Qwen3 單獨回答文字
從 llama.cpp 官方專案 選擇適合 Windows 與顯卡的版本，下載對應的 GGUF 模型，容量有限時，可先研究 Qwen3-4B 官方 GGUF ，而不是直接載入較大的模型。檔名應以實際下載結果為準。
下面是啟動本機文字服務的設定範例，請把模型路徑換成自己的檔案。這組命令只用來說明參數，未在本文中進行 GPU 實測。
llama-server -m "C:\AI\models\your-qwen3-model.gguf" -ngl 99 -np 1 -c 4096 --host 127.0.0.1 --port 8090先開啟 http://127.0.0.1:8090 測試文字回覆，再把語音服務的模型端點指向同一個位址與連接埠，llama-server 文件 列有模型路徑、上下文與監聽位址參數，若使用 NAT 網路跨 Windows 與 WSL 連線，位址安排會不同，應按前一節的網路模式處理。
連接埠不是非 8090 不可。若無法綁定，先看錯誤與 Windows 保留區間，再選可用的埠，也不必為了單機測試直接監聽全部網卡，只有確實需要其他位址連入時，才調整監聽範圍與防火牆。
步驟三：接上語音辨識與 Qwen3-TTS
先用一句短句測試語音辨識，再讓 TTS 單獨唸出固定文字，兩者各自正常後，才把它們接到文字模型，這樣能分辨「沒聽見」「辨識錯」「模型沒回覆」與「音訊沒播出」是哪一段出問題。
若使用作者整合包，install-voice.sh、start-voice.sh 與後續的橋接檔案應維持同一版本，這些是教學包的客製腳本，並不是所有官方專案都有的通用指令，下載入口可由原作者部署教學 取得，本文未執行或驗證該整合包。
自行安裝目前官方 speech-to-speech 時，要明確選定本機 LLM 端點與本地語音元件，單獨執行預設服務命令，不代表一定選到全本地配置，首次啟動還需要下載模型與完成載入，前端頁面能打開，不代表語音後端已準備好。
聲音復刻要選 Base，固定音色則看 CustomVoice
Qwen3-TTS 官方說明 區分 Base、CustomVoice 與 VoiceDesign，想根據參考錄音復刻聲音，應使用支援 voice clone 的 Base 路徑，CustomVoice 提供預設說話者，不能把兩者的參數直接互換。
參考音訊使用自己錄製或有授權的聲音，保持單人、背景乾淨，並準備正確的逐字內容，
不要只把 MP3 副檔名改成 WAV，也不要假設所有模組都用同一取樣率，應在需要的交接點真正轉換格式。更多音色選擇可參考Qwen3-TTS 音色設計與聲音復刻 。
步驟四：用 LiveTalking 驗證聲音與嘴型
LiveTalking 官方專案 支援 Wav2Lip 等嘴型模型，並提供 WebRTC 輸出，先依目前 README 安裝相容環境與權重，使用官方範例形象測試。舊教學的 Python、PyTorch 版本可能和目前文件不同，不要任意混裝兩套依賴。
完成官方安裝與模型放置後，範例啟動命令如下。開啟 http://localhost:8010/index.html，建立連線後先測畫面，再測文字或音訊驅動。官方文件要求把對應權重放到指定目錄，檔名也要相符。
python app.py --transport webrtc --model wav2lip --avatar_id wav2lip256_avatar1這一步的目標是確認嘴型服務本身能工作，範例能出聲音，不足以證明聲音是本地生成的。 仍要核對選用的 TTS 後端，確保正式串接時收到的是前一層本地 TTS 的音訊。
步驟五：準備自己的形象，最後才做整合
人物底片使用嘴部清楚、沒有手遮擋、動作平穩的素材。可以自己錄製，也可先用 Wan2.2 等圖生影片工具製作一小段待機畫面。鏡頭固定、人物稍微呼吸或眨眼即可，避免原片持續大幅說話，讓後續嘴型替換更容易處理。
底片長度、解析度與幀率要配合生成模型及後續預處理，不能把某份模板的幀數與匯出設定，說成整個 Wan2.2 系列只能產生固定秒數，若模板有提示詞擴寫功能，先確認它是否改寫了你要保留的場景。
LiveTalking 提供 /avatar.html 形象建立頁面，可上傳影片並產生角色資料，完成後，用新形象的 ID 啟動服務，再確認嘴部邊緣、遮擋與音畫同步。底片是角色外觀素材，實際回話的嘴型仍依當下音訊產生。
完整整合需要橋接語音輸出與人物服務。作者教學包中的 avatar-sync.js 承擔這部分工作，因此不能只安裝兩個官方專案，就假設它們會自動連接。建議依序啟動文字模型、嘴型服務、語音服務，再開前端檢查每一層日誌。
讓對話更自然：回覆長度比華麗人設更有用
語音回答先控制在一兩個重點，避免長篇條列與會被唸出來的格式符號。以下是可自行調整的原創人設示例，重點是語氣與回覆形式，不需要要求角色否認自己是 AI。
你是一位名叫小晴的虛擬聊天夥伴。
使用自然的臺灣繁體中文口語，回覆以兩三句為主。
先回應對方剛說的內容，再視情況提出一個簡單問題。
不要使用 Markdown、編號或表情符號。
不知道的事情直接說不知道，不要虛構共同經歷。支援思考切換的 Qwen3 模型可以用 /no_think 控制模式，但仍要依模型與聊天模板確認，若換成不同的 Instruct 版本，不能假設同一控制文字都有相同效果。
聲音很自然，回答就一定聽懂了嗎？
聊天時最容易混淆的是語氣與理解能力。角色能用自然音色談論喝奶茶、工作很累等日常話題，並不代表它穩定追蹤了誰在說話、誰與誰是什麼關係。多人輪流發言或連續追問身分時，回覆可能仍然流暢，內容卻已經接錯人或繞回固定話題。
驗收時應把「聲音像不像真人」與「答案有沒有回應問題」分開。用幾句意思相近但主詞不同的問題測試，再核對辨識文字。如果前一層把話聽錯，先修收音與轉錄。如果轉錄正確而回覆混亂，再調整對話歷史、角色規則或模型，不能只因為聲音很順就判定整套系統成功。
搶話、沒反應、WebSocket 失敗，分層排查
一直顯示「等待語音後端就緒」
先查看後端是否正在下載模型，或已經因套件、CUDA、磁碟空間而退出。檢查真正的錯誤訊息與下載進度，再決定是否重啟。只重整前端頁面，無法修復後端缺少權重的問題。
網頁打得開，但 WebSocket 連不上
官方瀏覽器示範文件 區分前端頁面與語音後端。例如頁面可位於 7860，而語音連線使用另一個埠與 /v1/realtime 路徑。依實際版本核對位址、連接埠、路徑及協定，不能把前端網址直接當成 WebSocket 端點。
WebRTC 失敗則要看服務端、ICE 候選、網路模式與防火牆。
前端出現 JSON 解析錯誤，可能只是收到錯誤回應，不能僅憑這句話認定是某個 WSL 開關沒開。
麥克風有權限，卻完全沒有辨識結果
先確認選到正確輸入裝置與收音電平，再調整 noise gate 與 VAD 門檻。
門檻過高可能把正常說話擋掉，降得太低也可能讓環境聲觸發回應，瀏覽器麥克風規則 要求安全環境，本機可用 localhost，其他裝置連入通常應使用 HTTPS。
還沒說完就被搶答，或聽起來像在等很久
先調整結束發言的靜音等待，再測辨識與合成速度。等待較長，較能容忍句中停頓，但回答也會更晚開始。這是輪流說話的取捨，不能單靠加大模型解決。使用耳機也能避免喇叭聲再次進入麥克風，造成誤觸發。
衡量延遲時，要從你停止說話算到真正聽見第一個字，包含等待、辨識、文字生成、音訊生成與播放緩衝。嘴型影片播放流暢，只代表畫面跟得上，不等於對話回覆沒有延遲。
離線與免費，最後要驗收哪些條件？
首次安裝與模型下載通常需要網路。若要斷網使用，先讓選定的全本地配置完整啟動一次，再檢查模型快取、前端資源、語音後端，以及是否仍依賴外部 STUN 或其他服務。外網通道與雲端語音服務也不能算成純離線方案。
原始 Wav2Lip 專案 對其開源模型的商用有明確限制，不能因整合框架使用 Apache 授權，就推論整套權重都可任意商用。對外使用前，應核對實際下載模型的來源與授權。
第一個完成標準可以很簡單：連續問幾個新問題，辨識內容正確、回答有關聯、聲音完整、嘴型能跟上。這些都穩定後，再增加個性設定、外觀與更長的對話記憶。
常見問題
要復刻聲音，Qwen3-TTS 該用哪一版？
應使用支援參考音訊復刻的 Base 路徑。CustomVoice 提供預設音色，與聲音復刻的輸入方式不同。
為什麼 localhost 頁面能開，語音卻連不上？
前端頁面與語音後端可能使用不同連接埠。應先確認後端啟動完成，再核對 WebSocket 位址、路徑、協定與網路設定。
AI 女友本地部署後可以斷網聊天嗎？
選定的模型、依賴與前端資源都已備妥，而且語音、對話與串接服務不依賴雲端時，才可能離線使用。應先跑通完整配置，再做斷網測試。
by Rain Chu 9 月 14, 2026 | AI , QWEN , TTS , 虛擬人 , 語音合成 , 語音辨識
把 AI 對話、即時語音和會動的人像放在同一台電腦上，現在已經可以做出一套不依賴雲端 API 的互動數位人，用 faster-whisper 聽懂麥克風，讓 Qwen3 產生回答，再交給 Qwen3-TTS 合成聲音，最後由 LiveTalking 完成口型同步與 WebRTC 串流。
先講我的結論。這套方案的價值是隱私、角色控制與離線能力，不是安裝後完全沒有成本。模型權重下載完成後確實不需要按次支付 API 費用，但顯卡、記憶體、硬碟、電力與維護時間仍然是成本，所謂 8GB 顯存能跑，也必須以較小的 LLM、量化權重和分階段載入為前提．若想讓 14B LLM、Whisper large-v3、1.7B TTS 與口型模型同時常駐，16GB 顯存仍可能不夠。
整套本地 AI 數位人怎麼運作
這不是單一模型，而是一條由五個服務組成的即時管線。
VAD 判斷使用者何時開始與停止說話faster-whisper 把麥克風聲音轉成文字Qwen3 與 llama.cpp 根據角色設定產生回答Qwen3-TTS 把回答轉成指定音色的語音LiveTalking 接收音訊並驅動嘴型，再透過 WebRTC 顯示互動人像
這種模組化做法和我之前整理的 Hugging Face speech-to-speech 本地即時語音 Agent 是同一條思路。每一層都能替換，但每一層也有自己的模型、連接埠與執行環境。LiveTalking 不會自動知道 Qwen3-TTS 在哪裡，兩者中間仍需要官方支援的 TTS 外掛，或一個把生成音訊送到 /humanaudio 的橋接程式。
先算顯存，不要先相信 8GB 宣傳
元件 RTX 4090 範例占用 低顯存調整 Qwen3-14B Q4_K_M 約 9GB 改用 8B 或 4B 的 Q4_K_M faster-whisper large-v3 約 3GB 改用 medium，準確度會有取捨 Qwen3-TTS 1.7B 約 4GB 改用 0.6B 或依序載入服務 Wav2Lip 256 約 1.3GB 降低批次並避免其他 GPU 程式常駐
這是 RTX 4090 整合環境的估計值，不同量化、上下文長度與 CUDA 版本都會改變結果 四個元件加起來約 17.3GB，還沒算 CUDA context、瀏覽器與暫存空間。16GB 顯卡跑到 99% 甚至整台機器失去回應，並不意外。6GB 顯存可以先用 Qwen3-4B 的 GGUF 量化版，並把語音辨識改成 medium。8GB 到 12GB 則適合 Qwen3-8B 搭配較小 TTS，或讓部分元件使用 CPU。若想了解 GGUF、llama.cpp 與 Ollama 的取捨，可以先看 本地大模型推理框架比較 。
第一步，在 Windows 準備 WSL 2
這套整合方式把 llama.cpp 放在 Windows，語音與數位人服務放在 Ubuntu 24.04 的 WSL 2。先用系統管理員身分開啟 PowerShell。
wsl --update
wsl --install -d Ubuntu-24.04Windows 使用者目錄的 .wslconfig 可以設定記憶體與鏡像網路。32GB 是範例，請依實際 RAM 調整，不要把主機記憶體全部交給 WSL。
[wsl2]
memory=32GB
networkingMode=mirrored
[experimental]
hostAddressLoopback=true修改後重啟 WSL。
wsl --shutdown進入 Ubuntu 後先用 nvidia-smi 檢查 GPU。NVIDIA 的 Linux 驅動不要再裝進 WSL，CUDA passthrough 由 Windows 顯示卡驅動提供。AMD 顯卡不能照搬這套 CUDA 整合包，需要改走 ROCm 支援的元件，或把無法使用 ROCm 的部分移到 CPU。
專案最好放在 Linux 家目錄，不要直接在 /mnt/c 執行。這能避開 I/O 速度、權限與換行格式問題。
mkdir -p ~/setup
cp -r "/mnt/c/Users/YOUR_NAME/Desktop/AI/." ~/setup/
cd ~/setup
sudo apt update
sudo apt install -y ffmpeg dos2unix python3-venv
dos2unix *.sh
chmod +x *.sh第二步，用 llama.cpp 啟動 Qwen3
llama.cpp 提供 OpenAI 相容 HTTP 服務，語音管線不必知道底層跑的是 GGUF。16GB 以上可以從 Qwen3-14B 的 Q4_K_M 開始，8GB 到 12GB 建議改成 8B，4GB 到 6GB 則從 4B 測試。
llama-server -m E:\llama.cpp\models\Qwen3-14B-Instruct-Q4_K_M.gguf ^
-np 1 -c 8192 -fa on --temp 1.0 --top-p 0.95 ^
--host 0.0.0.0 --port 8090新版 llama.cpp 文件也開始使用 llama serve 名稱，實際命令要以下載版本為準。Windows 的 8080 有時落在 Hyper-V 保留範圍，所以範例改用 8090。若服務無法綁定，可以先檢查保留埠。
netsh interface ipv4 show excludedportrange protocol=tcp第三步，安裝即時語音管線
Hugging Face 官方 speech-to-speech 現在以 serve、talk 和 local 為主要命令，舊資料裡的 --mode 已經淘汰。先建立獨立環境，再安裝 faster-whisper 額外依賴。
python3 -m venv ~/venvs/s2s
source ~/venvs/s2s/bin/activate
python -m pip install --upgrade pip
pip install "speech-to-speech[faster-whisper]"以下範例把 LLM 指向 Windows 上的 llama.cpp。不同版本的 STT 參數名稱可能調整，正式啟動前先執行 speech-to-speech serve --help 對照目前安裝版本。
speech-to-speech serve \
--stt faster-whisper \
--stt_model_name large-v3 \
--language zh \
--llm_backend responses-api \
--tts qwen3 \
--model_name Qwen3-14B-Instruct-Q4_K_M \
--responses_api_base_url http://127.0.0.1:8090/v1 \
--responses_api_api_key "" \
--responses_api_stream \
--enable_live_transcription模型全部下載完成後，可以設定 HF_HUB_OFFLINE=1 驗證斷網狀態。這一步比口頭宣稱本地化更可靠，因為只要還有任一個後端指向雲端，就不算完整離線。
第四步，準備 Qwen3-TTS 與參考聲音
Qwen3-TTS 官方最簡單的安裝方式是獨立建立 Python 3.12 環境。它支援聲音克隆、音色設計與串流輸出。更多模型差異和 ComfyUI 節點用法，可以延伸看 Qwen3-TTS 音色設計整理 。
conda create -n qwen3-tts python=3.12 -y
conda activate qwen3-tts
pip install -U qwen-tts參考音訊建議控制在 5 到 15 秒，只留單一說話人，沒有音樂與明顯環境聲。參考文字必須和音訊實際內容完全相同，否則容易出現漏字、錯字與音色漂移。情緒也會一起被模仿，所以不要用過度激動的片段當作一般對話基準。
ffmpeg -i ~/setup/ref.wav -ac 1 -ar 16000 -c:a pcm_s16le ~/s2s/ref.wav
ffprobe -v error -show_entries stream=sample_rate,channels,codec_name \
-show_entries format=duration -of default=nw=1 ~/s2s/ref.wav只應克隆自己或已取得明確授權的聲音。把真人聲紋放入公開服務前，也要考慮檔案存取權限、提示注入與未授權冒用。
第五步，製作自然的待機人像
人像素材不適合直接使用張嘴、手擋住嘴巴或劇烈轉頭的畫面。先生成嘴唇閉合、正面或微側面的基準圖，再用 Wan2.2 圖生影片做五秒左右的待機動作。提示詞只描述動作，不要重新描述人物外觀，能減少五官漂移。
電影感 16 比 9 構圖，一位成年東亞女性位於畫面右側三分之一，深色安靜房間，左側保留大量空間，螢幕冷光照亮臉部，輪廓帶柔和暖光，嘴唇自然閉合，雙手不遮擋嘴部，自然皮膚紋理，淺景深，真實攝影質感
負面提示詞
張嘴，說話，露齒，正面平光，明亮背景，過高對比，過度曝光，人物置中，多人，手遮擋嘴部，文字，浮水印，塑膠皮膚，過度修圖，卡通，3D 渲染
待機動畫提示詞
人物保持坐姿，只有細微自然呼吸，緩慢眨眼一次，頭部輕微移動後回到原位，嘴唇全程閉合，鏡頭完全鎖定，沒有縮放，沒有切鏡
關閉自動提示詞增強，輸出比例盡量和原圖相同。Wan2.2 常見原生片段是 81 幀、16 FPS，約五秒。若要二十秒待機，不要期待模型一次生成毫無漂移的長鏡頭，可以在自然停頓點循環短片。其他數位人生成思路可參考 LongCat 數位人工作流 。
第六步，安裝 LiveTalking
LiveTalking 官方目前測試的環境是 Ubuntu 24.04、Python 3.12、PyTorch 2.9.1 與 CUDA 12.8。下面命令照官方版本撰寫，但 PyTorch 下載來源仍應配合自己的 CUDA 驅動，不要盲目安裝 cu128。
git clone https://github.com/lipku/LiveTalking.git
cd LiveTalking
conda create -n livetalking python=3.12 -y
conda activate livetalking
pip install torch==2.9.1 torchvision==0.24.1 torchaudio==2.9.1 \
--index-url https://download.pytorch.org/whl/cu128
pip install -r requirements.txt下載官方提供的 wav2lip256.pth 後，把它放到 models，並改名成 wav2lip.pth。範例角色資料夾則解壓到 data/avatars。完成後啟動 WebRTC 服務。
python app.py --transport webrtc --model wav2lip \
--avatar_id wav2lip256_avatar1 \
--stun 'stun:stun.l.google.com:19302'瀏覽器開啟 http://localhost:8010/index.html，按下開始連線。正式讓外部裝置使用時，官方提醒需要 TCP 8010 和 WebRTC 使用的 UDP 連接埠。不要直接把整段 UDP 範圍暴露到公網，應優先放在可信任區網、VPN 或經過限制的防火牆環境。
自己製作 Wav2Lip 角色時，可以把短影片轉成 avatar 資料。素材要維持正面可見、光線穩定與嘴部清楚。
python avatars/wav2lip/genavatar.py \
--video_path data/video/avatar.mp4 \
--img_size 256 \
--avatar_id my_avatar第七步，正確啟動與串接
我會把服務拆成四個終端視窗，照下面順序啟動。每一步都先確認健康狀態，再開下一個服務。
Windows 啟動 llama.cpp，確認 http://127.0.0.1:8090/v1/models 有回應
WSL 啟動 Qwen3-TTS 或 speech-to-speech，先完成單句語音測試
WSL 啟動 LiveTalking，確認 8010 網頁能顯示待機角色
最後啟動橋接程式，把 TTS 產生的音訊送入 LiveTalking 的 /humanaudio
作者提供的一鍵整合包包含自訂腳本與橋接程式，並不是 Hugging Face、Qwen 或 LiveTalking 的官方發行版。下載前應先檢查檔案來源、雜湊值、啟動腳本和網路連線，不要把未知執行檔直接放進主要工作電腦。想要長期維護，我更建議從官方專案建立環境，再自行補一個最小橋接層。
WebSocket failed 怎麼排查
先確認服務真的啟動 。7860、8010 與 8090 是不同服務，瀏覽器頁面存在不代表後端 WebSocket 已連線檢查 WSL 網路 。修改 .wslconfig 後一定要執行 wsl --shutdown，鏡像網路與 hostAddressLoopback 才會重新載入確認 Windows 防火牆 。先只開必要 TCP 埠，在同一台電腦測通後再處理區網不要混用 localhost 。容器、WSL 與 Windows 各自看到的 127.0.0.1 可能不是同一個服務確認瀏覽器麥克風權限 。遠端網頁通常需要 HTTPS 或 localhost 才能取得安全的麥克風權限降低 Noise Gate 。如果網頁已連線但偵測不到聲音，先關閉門檻測試，再逐步調高調整 VAD 停頓 。約 900 到 1200 毫秒比較不容易搶話，但設定越長，回答開始時間也越慢
可以改成真正的 3D 角色嗎
可以，但不是把 Wav2Lip 模型換成一個 3D 檔案就完成。現在這條路線以 2D 影像或待機影片為基礎，口型模型直接修改臉部像素。真正的 3D 角色需要另外加入 Unity、Unreal Engine 或 WebGL renderer，再把 TTS 音訊轉成 viseme、音素或 blendshape 權重，驅動角色的嘴型、表情、眼神與骨架。
保留 VAD、Whisper、Qwen3 與 Qwen3-TTS，替換最後一層即可。新的輸出流程會變成 TTS 音訊、音素時間軸、3D blendshape、即時 renderer。若只是想讓角色有更豐富動作，可以先使用 LiveTalking 的自訂動作設定或多段待機素材，成本會比完整 3D 低很多。
本地不等於沒有風險
角色資料、聲音與對話都留在本機，確實能降低資料送往雲端的風險。但只要把服務開到區網或公網，就要重新考慮驗證、連接埠、惡意音訊、提示注入與檔案上傳。對話記憶也不是安裝完成就會永久存在，長期記憶需要另外接資料庫、摘要或向量檢索，否則聊天變長後仍可能忘記前文或開始胡亂延伸。
LiveTalking 官方也明確要求，使用此專案製作並發布到平台的內容必須包含 LiveTalking 浮水印與標誌。正式商用前要再確認每個模型、角色素材、聲音和整合程式的授權，不要只看程式能不能跑。
官方資源與參考資料
FAQ
8GB 顯存真的可以跑本地 AI 數位人嗎
可以做出可用版本，但不適合讓 14B LLM、large-v3、1.7B TTS 與口型模型全部以高規格同時常駐。建議改用 Qwen3-8B 或 4B 量化版、較小 TTS、較低 batch，必要時把部分模型放到 CPU。
可以完全離線，不使用任何 API 嗎
可以。前提是 STT、LLM、TTS 和數位人全部使用本地後端，而且模型與依賴已下載完成。設定 HF_HUB_OFFLINE=1 並在斷網環境測試，才能確認沒有隱藏的雲端依賴。
可以用英文或其他語言聊天嗎
可以，但 STT、LLM 與 TTS 三層都要支援目標語言。Whisper 與 Qwen3 的多語能力較完整，最終自然度通常由 TTS 音色與參考音訊決定。中英混合時要額外測試專有名詞、數字與語速。
Mac 可以照這篇安裝嗎
不能原封不動照做，因為本文整合路線依賴 Windows、WSL 與 CUDA。llama.cpp、Whisper 和部分 speech-to-speech 元件可以改走 Apple Silicon 的 Metal 或 MLX，但 LiveTalking 口型模型與整合腳本需要另外確認 macOS 支援，不能直接套用 NVIDIA 命令。
最後怎麼選
如果只是想快速聊天，雲端語音助手會更省時間。如果需求是讓私人對話留在本機、建立固定角色、接自己的資料或研究數位人介面，這套模組化管線就很值得做。我的建議是先讓文字對話跑通，再加入 STT 和 TTS，最後才接 LiveTalking。一次啟動所有元件，只會讓錯誤來源變得難以判斷。
真正值得學會的不是某個一鍵包，而是知道聲音在哪裡變成文字，回答在哪裡生成，音色在哪裡被控制，口型又由哪一個服務驅動。把這五層拆清楚後，未來換模型、換角色、換前端，整套系統仍然能繼續使用。
by Rain Chu 7 月 28, 2026 | AI , 語音合成
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-BitNet CPU 語音辨識 桌機、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 即時辨識成立，但不同處理器、音訊長度與編譯方式都會影響速度。
官方 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、程式碼、罕見符號與過度複雜的標點，再把數字轉成預期的口語形式。
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 支援中文嗎
官方目前仍把英文列為主要目標，另提供九種實驗語言，名單不含中文。社群版本可能加入中文或自訂音色，但要分開看待。
by Rain Chu 7 月 23, 2026 | AI , 語音分離 , 語音合成 , 語音辨識
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 WebUI 和 Hugging Face speech-to-speech 本地語音 Agent ，Voicebox 則更偏向桌面應用和創作者工具，並且把 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 的做法 適合用途 高品質 TTS Qwen3-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`。
by Rain Chu 7 月 15, 2026 | AI , 語音合成 , 語音辨識
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 的價值在於把聲音、對話、畫面和平台工具接成一條內容生產線。 適合誰使用
第一類是短影音創作者。這類人需要快速產出角色旁白、社群內容、產品介紹和教學短片，平台化工具會比自己串模型更省時間。
第二類是品牌或電商內容團隊。商品介紹、活動宣傳、客服說明和直播切片都需要大量聲音與角色素材。只要品質穩定，數字人可以降低重複錄製成本。
第三類是 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 串起來，降低組裝成本。
by Rain Chu 7 月 14, 2026 | 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 服務地址與模型名稱，就能接入本地語音服務。
近期留言