影片筆記：本地语音 AI 终于统一了！ 实时对话、声音克隆、AI 翻唱8G 显存全跑通｜audio.cpp｜整合包

一句話總結

影片介紹了一款名為 Audio CPP 的本地 AI 音頻整合工具，旨在解決本地部署多個音頻模型時環境配置複雜的問題。該工具將 TTS、ASR、音樂生成等功能統一在同一底層架構中，提供帶 Web UI 的整合包，支持在低顯存（如 8GB）設備甚至 CPU 上運行，並演示了實時語音對話、聲音克隆、換詞翻唱等功能。

核心重點

• 統一底座與易用性：Audio CPP 將分散的音頻能力（TTS、ASR、音樂生成、聲音轉換）整合至同一後台，類似於大語言模型領域的 Ollama 或圖片生成的 ComfyUI。提供帶 Web UI 的整合包，解壓即用，降低部署門檻。
• 硬體兼容性與性能：
• 支持 Windows 16-50 系列 N 卡，A 卡及無獨顯設備可走 CPU 模式。
• 核心功能可在 8GB 顯存筆記本上運行，部分小模型無需顯卡。
• 官方宣稱在 RTX 5090 上運行速度比原生框架快 1-3 倍；實測在 RTX 4060 上，合成效率提升顯著（約 4 倍）。
• 核心功能演示：
• TTS（文本轉語音）：支持聲音克隆（需參考音頻），推薦 Pocket TTS（不支持中文）和千問 3 TTS 0.6B（支持中文）。
• ASR（語音轉文字）：支持中英文轉寫、對話模式識別及歌詞識別。
• 實時語音系統：結合本地 ASR、大語言模型（可接 Ollama 或 API）和本地 TTS，實現低延遲、隱私安全的本地語音交互。
• 音樂與聲音轉換：支持換詞翻唱（ACE STEP）、背景音樂生成（Stable Audio）、音色遷移（聲音轉換）及基於文字描述的「聲音設計」。

詳細大綱

I. Audio CPP 介紹與定位

• 定義：本地 AI 音頻工具，被比喻為「音樂領域的 Nama CPP」（疑點：應指 Ollama 或類似工具）。
• 解決痛點：
• 過去本地部署音頻模型需單獨配置環境、依賴庫，導致「環境把人勸退」。
• Audio CPP 將 TTS、ASR、音樂生成、聲音轉換統一至同一後台。
• 通過界面隨時切換模型，簡化本地運行各種語音模型的流程。

II. 性能與兼容性

• 硬件要求：
• 核心功能可在 8GB 顯存筆記本上運行。
• 部分小模型無需顯卡，可使用 CPU 運行。
• 速度對比：
• 官方數據：在 RTX 5090 上，Audio CPP 運行效率比原生推理框架快 1-3 倍，部分模型快 8-10 倍。
• 實測數據（RTX 4060）：
• 使用微軟開源模型（疑點：Vive Voice）合成 1 萬字小說朗讀。
• 官方程序耗時 110 分鐘。
• Audio CPP 耗時 29 分鐘（約為原來的 1/4）。

III. 核心功能詳解

1. TTS（文本轉語音）

• 基本操作：選擇模型 -> 加載 -> 選擇參考音頻（用於聲音克隆） -> 輸入文本 -> 生成。
• 推薦模型：
• Pocket TTS：支持參考音頻，聲音克隆秒級生成，但不支持中文。
• 千問 3 TTS 0.6B：參數小，效果不錯，支持中文。
• 低配友好：上述模型顯存佔用小，適合低配顯卡或無獨顯機器。
• 特色模型：
• Vox CPM2：支持方言生成與克隆（如國內大部分方言），可克隆語氣。
• Voic Voice（疑點：前文提及 Vive Voice，此處名稱不一致）：實測近萬字小說合成，顯存佔用未超 7G，無明顯漏讀錯讀。
• 使用技巧：
• 參考音頻建議控制在 10 秒以內，避免拖慢速度。
• 常用參考音頻可放入 WebUI 下的 Voice 目錄，並通過文件映射直接選擇。
• 可通過 ASR 標籤將音頻轉寫為文本，避免手動輸入參考音頻對應文本。

2. ASR（語音轉文字）

• 推薦模型：千問 3 ASR（支持中英文，速度快）。
• 功能特點：
• 對話模式：支持多人對話識別，輸出帶說話人序列文本（有長度限制，適合短片段）。
• 單人轉寫：無長度限制。
• 歌詞識別：可用於 AI 翻唱前的初步識別與手動校對。
• 實測數據：2 分多鐘音頻轉錄僅用 21 秒。

3. 本地實時語音系統

• 架構流程：麥克風輸入 -> ASR 轉文本 -> 大語言模型生成回答 -> TTS 朗讀。
• 優勢：
• 響應速度快（延遲約 1 秒）。
• 數據安全，注重隱私。
• 支持實時打斷、聯網搜索、視覺理解（疑點：需確認模型是否原生支持視覺）。
• 靈活性：
• 語音層（聽與說）本地化。
• 大語言模型層可接本地 Ollama 或訂閱的 API。
• 使用 OpenAI 兼容接口，可被其他應用（如 OpenMagic AI）調用。

4. 音樂生成與聲音轉換

• 換詞翻唱：
• 使用模型：ACE STEP（前文提及在本地 8G 顯存跑不動，現可本地運行）。
• 流程：上傳歌曲 -> 分析（幾十秒至幾分鐘） -> 設置參數（Remix 模式，自動填好曲風/曲譜） -> 輸入新歌詞 -> 生成。
• 調試：若音質不好增加「生存部署」（疑點：應為推理步數或類似參數）；若新詞唱不准調試 Flowedit 參數（0.7-0.9）。
• 背景音樂生成：推薦使用 Stable Audio，比 ACE Stable 更穩定。
• 聲音轉換（音色遷移）：
• 保持內容與語氣不變，僅更換音色。
• 實測建議追求高質量時，仍推薦使用之前的 RVC 流程，並建議先做人聲分離。
• 聲音設計：
• 類似聲音克隆，但無需參考音頻。
• 通過文字描述生成聲音（如「磁性的中年男生，語速偏慢」）。
• 適用於臨時配音。

IV. 整合包與使用指南

• 技術背景：Audio CPP 本身為 C++ 項目，官方主要支持命令行，對無技術基礎用戶有門檻。
• 整合包特性：
• 帶 Web UI 界面，解壓即用。
• 支持 Windows 16-50 系列 N 卡。
• A 卡及無獨顯機器自動走 CPU 模式（速度較慢，但可運行輕量模型）。
• 啟動流程：

1. 運行 Run Web UI 啟動網頁界面，下載所需模型。
2. 若需實時語音，先在 Web UI 加載模型，再啟動 ASR 服務。
3. 運行 Run Real Time。
4. 配置中修改接入的大模型 API Key（如 Deep Seek）。

• 資源分享：源代碼已開源至 GitHub，整合包及鏈接見評論區。

工具 / 模型 / 名詞整理

• Audio CPP：本影片介紹的核心本地 AI 音頻工具。
• Nama CPP：逐字稿提及，疑點，可能指代 Ollama 或類似本地模型運行框架。
• Ollama：用於本地運行大語言模型的工具。
• Comfy UI：逐字稿提及，用於圖片視頻生成的本地運行中心。
• OpenAI：提及兼容接口標準。
• GPT Live：逐字稿提及 OpenAI 發布的全雙工語音系統。
• Pocket TTS：推薦的 TTS 模型，支持聲音克隆，不支持中文。
• 千問 3 TTS 0.6B：推薦的 TTS 模型，支持中文，參數小。
• Vox CPM2：支持方言生成與克隆的 TTS 模型。
• Vive Voice：實測中使用的微軟開源模型。
• Voic Voice：逐字稿後段提及的模型名稱，與前文 Vive Voice 可能為同一模型或聽寫錯誤。
• 千問 3 ASR：推薦的語音轉文字模型。
• OpenMagic AI：用於測試調用 Audio CPP TTS 服務的應用。
• ACE STEP：用於換詞翻唱的音樂生成模型。
• Club：逐字稿提及，疑點，可能指雲端平台名稱。
• Stable Audio：推薦用於生成背景音樂的模型。
• ACE Stable：逐字稿提及，疑點，可能指代 ACE STEP 或 Stable Audio 的某種變體。
• RVC：推薦用於高質量聲音轉換（音色遷移）的流程/工具。
• Deep Seek：提及的大語言模型 API 提供商。
• GitHub：源代碼開源平台。

操作流程整理

1. TTS 聲音克隆流程

1. 在 Web UI 中選擇 TTS 模型（如 Pocket TTS 或千問 3 TTS）。
2. 加載模型。
3. 選擇參考音頻（建議 10 秒以內）。

• *技巧*：可將常用參考音頻放入 WebUI 下的 Voice 目錄，通過文件映射直接選擇。
• *技巧*：可通過 ASR 標籤將參考音頻轉寫為文本，避免手動輸入。

1. 輸入目標文本。
2. 點擊生成。

2. 本地實時語音系統搭建流程

1. 運行 Run Web UI 啟動網頁界面，下載所需模型。
2. 在 Web UI 中加載 ASR 模型（如千問 3 ASR）和 TTS 模型。
3. 啟動 ASR 服務。
4. 運行 Run Real Time。
5. 在配置中修改接入的大語言模型 API Key（如 Deep Seek 或本地 Ollama）。
6. 通過麥克風輸入語音，系統將執行：ASR 轉文本 -> LLM 生成回答 -> TTS 朗讀。

3. 換詞翻唱流程 (ACE STEP)

1. 上傳歌曲。
2. 等待分析（幾十秒至幾分鐘）。
3. 設置參數（Remix 模式，自動填好曲風/曲譜）。
4. 輸入新歌詞。
5. 點擊生成。

• *調試*：若音質不好，增加「生存部署」（疑點：應為推理步數）；若新詞唱不准，調試 Flowedit 參數（0.7-0.9）。

值得注意的限制或風險

• 硬體限制：雖然支持低顯存設備，但部分功能（如高質量聲音轉換）仍建議使用 RVC 流程並先做人聲分離。CPU 模式下運行速度較慢。
• 模型兼容性：不同模型對顯存佔用不同，需根據硬體選擇合適模型（如 Pocket TTS 和千問 3 TTS 適合低配）。
• 功能確認：實時語音系統是否原生支持「視覺理解」需進一步確認。
• 名稱一致性：部分模型名稱在逐字稿中存在不一致（如 Vive Voice 與 Voic Voice），可能影響準確查找。

逐字稿辨識疑點

• Nama CPP：逐字稿稱 Audio CPP 是「音樂領域的 Nama CPP」。根據上下文推測應為 Ollama（大語言模型本地運行框架）或 ComfyUI 的聽寫錯誤，但逐字稿原文為 Nama CPP，故標記為疑點。
• Vive Voice vs Voic Voice：前文實測速度對比時稱為「微軟開源的 Vive Voice」，後文介紹特色模型時稱為「Voic Voice」。兩者可能為同一模型，但名稱不一致，需查證。
• GPT Live：逐字稿提及「OpenAI launched GPT Live, A full duplex voice system for chat GPT」。需確認此為官方正式名稱還是口誤。
• 生存部署：在調試翻唱參數時，逐字稿提到「增加生存部署」。根據語境推測應為「推理步數」（Inference Steps）或類似參數的聽寫錯誤。
• Club：逐字稿提到「最後是在 Club 上演示的」。此處指代不明，可能是某個雲端平台或社區的名稱，需查證。
• ACE Stable：逐字稿推薦背景音樂生成時提到「比 ACE Stable 更穩」。此名稱與前文提到的 ACE STEP 不同，且 Stable Audio 已單獨提及，ACE Stable 可能是聽寫錯誤或特定模型變體，需查證。
• 實時語音系統功能：逐字稿提到實時語音系統支持「視覺理解」。需確認該本地語音系統架構是否原生支持視覺輸入，或僅為口誤。

可延伸追問

• Audio CPP 的源代碼和整合包具體下載鏈接為何？
• 「Nama CPP」是否為特定社區或工具的暱稱？
• 如何準確區分 Vive Voice 和 Voic Voice 這兩個模型名稱？
• 實時語音系統中的「視覺理解」具體指什麼功能？
• 「生存部署」具體對應哪個參數設置？