audio.cpp 是什麼？本地語音 AI 終於有統一底座

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 再把回答唸出來。整套流程可以把語音層放在本機，讓資料不必全部送到雲端語音平台。

這個架構的彈性在於 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 服務地址與模型名稱，就能接入本地語音服務。