本地語音架構遷移
把語音生成從雲端成本搬到本地速度。
從雲端語音模型遷移到本地推論，維持語音品質的同時，改善速度、成本，跟多語言彈性。
問題在哪
原本七個角色聲線都掛在雲端 TTS，一個月成本差不多九萬台幣。品質不錯，中文輸出沒問題，但沒辦法用同一個聲音身分彈性切換到多語言角色表演，成本也壓不下來。
Role: 架構規劃 · Adapter 實作 · API 相容性負責人 · 上線負責人
雲端 → 本地
雲端語音架構
品質不錯，但卡在中文，而且有按用量計費的成本跟網路延遲。
本地推論
同一個聲音身分跨語言通用，跑起來更快也更便宜。
我做了什麼
實際動手做的事。
規劃從雲端到本地 runtime 的遷移架構。
調度多個 sub-agent 建立自動化評估管線，在數十個開源模型中交叉比對語音品質，找出能兼顧情緒起伏跟台灣口音的方案。
在既有 API 合約周圍調整介面跟相容層，處理 speaker mapping、延遲限制、上線規劃。
負責語音模型訓練跟行為調校以外的整個遷移工作。
AI 協作治理
在數十個開源模型裡挑出對的那一個，不是靠我一個個聽、憑感覺選，而是我把「怎麼評估」設計成一條 AI 自己會跑的管線——這頁記錄的是我如何治理一場大規模的模型選型。
治理案例
點開看一手證據
AI 的慣性盲點
語音品質評估天生主觀：情緒起伏夠不夠、台灣口音道不道地，一個一個人工試聽既慢又不一致，在數十個開源模型間根本無法可靠比較——這正是 AI 協作最容易淪為「憑感覺」的地方。
我建立的治理機制
調度多個 sub-agent 建立自動化評估管線（Pipeline），把主觀的音質判斷拆解成可交叉驗證的指標，在數十個開源模型間跑一致的比對，而不是靠我一個人的耳朵。
協作解鎖的價值
讓「在極其有限的本地算力下，同時保住豐富情緒起伏與可調性」這件事變成可執行的工程流程；最終選定的模型是管線跑出來的，不是拍腦袋選的。
AI 的慣性盲點
換掉底層推論引擎時，AI 容易只顧「新的能跑」，忽略上層一堆依賴舊 API 合約、speaker mapping、延遲假設的下游——一改就整條炸。
我建立的治理機制
把遷移約束在既有 API 合約周圍：加相容層、明確處理 speaker mapping 與延遲限制、規劃分批上線，讓底層從雲端換到本地，但對上層是無感的。
協作解鎖的價值
七條聲線的雲端成本從月費約 9 萬台幣砍到幾乎零，同時上層系統不需要為了這次遷移重寫——降本沒有以穩定性為代價。
結果怎樣
成本歸零
雲端月費從約 9 萬台幣降到幾乎零成本，七條聲線全部搬到本地跑，只剩電費。
延遲改善
生成位置更靠近 runtime，讓互動式角色使用時的回應更即時。
多語言聲音身分
本地模型可以跨語言維持同一個角色聲音，把使用場景擴展到原本只有中文輸出之外。