PawAI
語音開發歷程總整理
PawAI 機器狗：語音模組開發復盤與踩坑總結 (終極完整版)
一、架構演進：從「邊緣端」到「端雲協同」
專案初期，團隊曾嘗試將語音模型直接部署在 Unitree Go2 機器狗背上的 Jetson Orin Nano。但實測發現，VRAM 容量不足與運算時的嚴重發熱降頻，導致對話延遲高達 10 秒以上。
-->最終決策：確立「端雲協同」架構。 邊緣端（機器狗/手機 App）僅負責輕量的麥克風收音與喇叭播放；而龐大的 STT --> LLM --> TTS 矩陣運算，則統一交由遠端 RTX 8000 GPU 伺服器集中處理，大幅解放了硬體限制。
二、語音轉文字 (STT / ASR) 模組復盤
在「聽覺」模組的開發中，核心挑戰是必須滿足：「中文優先、離線運作、速度 > 準確度（降低老人等待的延遲感）」。為此，團隊橫向評測了多款主流開源模型。
語音辨識 (STT) 比較表
我們的目標是抵抗環境噪音，且推論時間必須在數百毫秒內。
| 模型名稱 | 特性與優勢 | 淘汰原因 / 測試痛點 | 最終選擇 |
|---|---|---|---|
| FunASR (Paraformer) | 阿里巴巴達摩院開發，非自回歸架構，速度極快且專為中文特化。 | 測試中出現同音字選字錯誤（如「瓦斯爐」聽成「瓦斯魯」）；且 API 封裝較厚，不易與我們的 Pipeline 整合。 | ❌ |
| Qwen3-ASR (0.6B) | Audio-LLM 架構，具備強大上下文語意修正能力。 | 吃重 VRAM（約 16GB）且載入極慢；長句推論時會出現大量注音文與亂碼幻覺。 | ❌ |
| SenseVoice | 極度輕量化 (~0.3B)，速度飛快。 | 在實驗室或有背景音的環境下，中文抗噪能力較弱，容易辨識錯誤。 | ❌ |
| Sherpa-onnx | C++ 底層，適合邊緣裝置。 | 模型設定繁瑣，與 Python 雲端非同步架構對接成本過高。 | ❌ |
| Faster-Whisper | 基於 CTranslate2 引擎優化。 | 無明顯缺點。精準度繼承 Whisper large-v3-turbo，速度在 RTX 8000 上提升數倍，完美勝出。 | ✅ |
1. 候選模型詳細評測結果
- FunASR (Paraformer)：阿里巴巴達摩院開發，非自回歸架構，速度極快且專為中文特化。但在測試中出現選字錯誤（如將「瓦斯爐」聽成「瓦斯魯」、「log檔」聽成「g檔」）。
- 🔗 GitHub: https://github.com/modelscope/FunASR
- 🤗 Hugging Face: https://huggingface.co/funasr
- Sherpa-onnx (Zipformer)：Next-gen Kaldi 團隊開發，專注於邊緣運算，模型僅 14MB，速度極快。踩坑點在於長句處理嚴重卡頓（處理時間暴增至 1.6 秒），且有嚴重亂碼幻覺（如「瓦斯 l l e」）。
- 🔗 GitHub: https://github.com/k2-fsa/sherpa-onnx
- 🤗 Hugging Face: https://huggingface.co/k2-fsa
- Vosk：極致省資源的老牌離線庫，適合關鍵詞喚醒，但不適合長篇大論的聊天。
- 🔗 GitHub: https://github.com/alphacep/vosk-api
- 🤗 Hugging Face: https://huggingface.co/alphacep
- Qwen3-ASR (0.6B)：Audio-LLM 架構，具備強大上下文語意修正能力。但踩了嚴重的硬體與效能坑，極度吃 VRAM（約 16GB），推論速度慢（大於 2 秒），甚至出現大量注音文與亂碼幻覺，最終被判定為「完全不可用」。
- 🤗 Hugging Face: https://huggingface.co/Qwen
- SenseVoice-Small：阿里通義實驗室新作，準確度極高（推論僅 0.2 秒），甚至支援「情緒識別」（判斷平靜、憤怒等）。致命踩坑點是「冷啟動極慢」，每次執行需耗費 11 秒開啟模型。
- 🔗 試玩頁面: SenseVoice HuggingFace Space
- 🤗 Hugging Face: https://huggingface.co/FunAudioLLM/SenseVoiceSmall
- Faster-Whisper (Large-v3-Turbo / Small)：基於 CTranslate2 引擎加速。啟動極快（1.27 秒），推論快（0.35 秒）。踩坑點是在安靜或雜音結尾時容易有「腦補幻覺」（如自己加上「B」或「好」），以及同音字誤判（如 log檔聽成 lockdown），需靠 Prompt 參數修正。
- 🤗 Hugging Face: https://huggingface.co/Systran/faster-whisper-large-v3
2. STT 最終選型決策
-->最終選擇：Faster-Whisper (Large-v3-Turbo)
- 獲選原因：在 Mac M4 上綜合表現最穩定，達到「秒開秒回」（1.27 秒開啟 + 0.35 秒辨識）。其幻覺缺陷可以透過程式碼（
initial_prompt）有效抑制。 - 備案保留：如果未來 PawAI 改寫為常駐背景服務（Daemon/Server），不需反覆經歷 11 秒開機，則會考慮切換至準確度更高且具備情緒識別的 SenseVoice。
三、語言模型 (LLM) 選型簡述
作為中樞思考大腦，最終選擇了 Qwen2.5-7B-Instruct (4-bit 量化)。其優勢在於中文語感極佳，能嚴格遵守「PawAI 機器狗」的熱情口語化人設；更重要的是，4-bit 量化技術大幅節省了 VRAM，確保 STT 與 TTS 能在同一張顯卡上並行運作而不崩潰。
- 🤗 Hugging Face: https://huggingface.co/Qwen/Qwen2.5-7B-Instruct
四、文字轉語音 (TTS) 模組復盤
TTS 的核心訴求是：「可離線、極速反應、聲音自然」。團隊針對雲端與本地端生成式 AI 模型進行了嚴格的對比。
🗣️ 語音合成 (TTS) 比較表
我們要的是即時生成、中英夾雜流暢，且不能依賴不穩定的外部網路 API。
| 模型名稱 | 特性與優勢 | 淘汰原因 / 測試痛點 | 最終選擇 |
|---|---|---|---|
| Edge-TTS | 微軟免費 API，聲音自然好聽。 | 致命傷：高度依賴外部網路連線。 只要實驗室網路一慢，延遲就會飆升到 3-5 秒，甚至超時斷線，無法作為穩定的工業級解法。 | ❌ |
| CosyVoice | 語音克隆 (Voice Cloning) 能力極強，情感豐富。 | 模型過於龐大，生成完整句子的時間太長。雖然好聽，但在「即時對話」的場景下顯得太過笨重。 | ❌ |
| Qwen3-TTS | 聲音品質好。 | 偏向傳統大模型架構，生成速度依然無法壓在 1 秒內的黃金標準。 | ❌ |
| MeloTTS | 極速、輕量、支援多語言。 | 完美支援即時串流生成，中英夾雜不卡頓，本地 GPU 生成幾乎是瞬間完成，是即時互動的最佳解。 | ✅ |
1. 候選模型詳細評測結果
- CosyVoice：阿里雲生成式音訊模型，支援零樣本語音複製。踩坑紀錄：在本地端測試時遭遇效能災難。耗時隨字數「線性暴增」，長句生成需高達 62.97 到 75 秒。且因算力不足，長句會出現嚴重的「口齒不清/含滷蛋」與發音錯誤（把「機」唸成 Key）。與 DeepSpeed 軟體環境相容性不佳，硬體資源要求極高。
- 🤗 Hugging Face: https://huggingface.co/FunAudioLLM/CosyVoice-300M
- Qwen3-TTS (0.6B)：同樣基於 LLM 架構。踩坑紀錄：遭遇嚴重的生成式「幻覺」，長句生成直接崩潰變成亂碼與注音文（如
辨ㄒㄧˋ、ㄐㄧㄝ ㄏㄤˊ）。推論極慢，長句耗時 22.75 秒，模型載入高達 8~9 秒，完全不適合即時互動。- 🤗 Hugging Face: https://huggingface.co/Qwen
- Edge-TTS (備案)：微軟 Azure 雲端 API，聲音廣播級、極度穩定，無論句子長短皆能維持在約 0.6 秒的極速生成。踩坑紀錄：曾遇到網路重試導致 135.69 秒異常延遲（需寫 Timeout 機制）。最大致命傷是「必須連網」，若展示場地無 WiFi 則機器狗會直接失語。
- 🔗 GitHub: https://github.com/rany2/edge-tts
- 🤗 Hugging Face: (無，此為微軟 Azure 閉源雲端 API)
- MeloTTS：由 MyShell 團隊開發，基於 VITS 技術（跳過拼音，文字直達聲音），主打能離線跑且像真人。優勢：模型極輕量（約 0.1
0.2B），CPU 就能輕鬆跑。推論速度達 0.10.5 秒（秒回等級），中英切換自然。踩坑紀錄：中英夾雜時發音需調教（例如 "Paul" 會唸成 "泡"），必須另外建立發音字典強制標註修正。- 🤗 Hugging Face: https://huggingface.co/myshell-ai/MeloTTS-Chinese
2. TTS 最終選型決策
--> 最終選擇：MeloTTS
- 獲選原因：它是唯一能同時滿足「斷網能跑（純離線）」且「推論極速（0.1~0.5秒）」的最佳解決方案，完美契合 PawAI 的需求。
- 優化策略：透過建立發音字典修正特定專有名詞，並將語速（speed）微調至 1.1 或 1.2 以提升自然度。
- 備案保留：Edge-TTS 作為有網路環境下的高品質備案使用。
五、全線整合與底層踩坑血淚史 (Troubleshooting)
在成功將 Faster-Whisper (耳) + Qwen2.5-7B (腦) + MeloTTS (嘴) 串聯成 Pipeline 後，團隊遭遇了最密集的系統級 Bug 爆發。以下是 5 個最致命的坑與對應解法：
🕳️ 坑洞 1：延遲載入導致的「尷尬 13 秒冷啟動」
- 踩坑原因：AI 套件具備「延遲載入 (Lazy Loading)」機制，第一次說話時系統才把好幾 GB 的模型搬進 GPU，導致第一次對話卡頓近 13 秒。
- 解法：實作**「暖機 (Warm-up) 機制」**。在程式啟動時，背景自動丟入一句假資料 (
warmup_dummy.wav) 強迫大腦與嘴巴先跑過一次推論。優化後對話反應大幅縮短至 2.5 到 4 秒左右，達成「秒回」境界。
🕳️ 坑洞 2：TTS 長句「越講越小聲」 (Attention Collapse)
- 踩坑原因：語音生成模型的物理限制。只要 LLM 回覆超過 7~8 秒，MeloTTS 唸到後面就會出現注意力崩潰，聲音衰減甚至變成氣音或雜訊。
- 解法：導入**「斷句拼接與音量鎖定」**。嚴格限制 LLM 用句號或驚嘆號斷句，並透過程式將長文切分為短句 (Chunking) 分批生成；檢查並強制放大每一段的音量 (Normalization)，最後再將短音訊無縫拼接，同時將 TTS 語速鎖定為 1.0。
🕳️ 坑洞 3：多 GPU 搶奪導致 LLM 量化崩潰
- 踩坑原因：Qwen 4-bit 量化模型預設將張量分散掛載到多張 GPU，但框架不支援跨卡的動態指派，導致
ValueError: .to is not supported for 4-bit...記憶體崩潰。 - 解法：在程式碼頂端強制宣告環境變數，戴上「眼罩」將程序的視野鎖死在單一張顯示卡上：
os.environ["CUDA_VISIBLE_DEVICES"] = "1"。
🕳️ 坑洞 4：張量資料型態打架 (Half but found Float)
- 踩坑原因：Faster-Whisper 模型設定為追求極速的
FP16 (Half)，但有時環境異常會自動降級交給 CPU 運算。CPU 不支援 FP16 只能用預設的FP32 (Float)，導致兩種資料格式撞車引發RuntimeError。 - 解法：不僅在初始化時明確宣告
device="cuda", compute_type="float16"，更加上防呆機制，確保啟動前伺服器確實抓到了 NVIDIA 顯示卡。
🕳️ 坑洞 5：伺服器顯示卡權限被反鎖 (Insufficient Permissions)
- 踩坑原因：共用實驗室伺服器時，其他組員執行高負載的 Isaac Sim 模擬，導致 NVIDIA 底層驅動程式將 GPU 的讀寫權限鎖死，噴出
Failed to initialize NVML: Insufficient Permissions。 - 解法：請求具有
sudo權限的管理員執行sudo chmod a+rw /dev/nvidia*強制釋放權限，並養成透過nvidia-smi查詢 Memory-Usage 避開高負載車道的習慣。
六、下一步計畫 (Next Steps)
目前伺服器端的「超級大腦」已經具備極速反應且聲音穩定。下一個階段的任務是**「網路連線」**。團隊計畫將這支 Python 程式包裝成網路 API（如 FastAPI），讓 Mac 控制端或 Unitree Go2 機器狗能真正透過網路傳送麥克風收音，並即時接收語音播出來，完成最終的整合實裝。