Speech-AI-Forge：把十種 TTS 模型塞進同一個 API Server
🍦 Speech-AI-Forge is a project developed around TTS generation model, implementing an API Server and a Gradio-based WebUI.
秒懂
- 它是什麼？
- 這個專案用一層統一的 API 與 Gradio 介面包住 ChatTTS、CosyVoice、FishSpeech、F5-TTS 等模型，解決的是模型切換與長文本推理的工程問題，而不是訓練新模型。代價是 AGPL-3.0 與持續追蹤上游模型版本的維護負擔。
- 適合誰用？
- 需要在自己機器上一次跑多個 TTS 模型、並且要一個現成 API 給內部工具呼叫的團隊，這個專案省下的是整合與長文本切分的工。只想用單一模型、或產品要閉源出貨的團隊不該採用，AGPL-3.0 會直接卡住你。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 117 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是模型切換，不是語音品質
TTS 開源生態這幾年的問題不是沒有模型，而是模型太多且各自為政。ChatTTS、CosyVoice、FishSpeech、F5-TTS、Index-TTS、Spark-TTS、FireRedTTS、GPT-SoVITS、Qwen3-TTS 各有自己的推論腳本、自己的權重目錄結構、自己的取樣參數命名。想在同一套服務裡比較兩個模型在同一段文本上的表現，通常得先寫兩份載入程式碼。Speech-AI-Forge 的定位就是把這層重複工作收掉：README 開頭寫得很直白，這是一個圍繞 TTS 生成模型開發的專案，實作了 API Server 與基於 Gradio 的 WebUI。
目標讀者是已經有 GPU 機器、需要把 TTS 接進自己系統的工程師，或是要做多模型 A/B 比較的研究者。它不訓練模型，不微調模型，也不承諾某個模型比另一個好。README 的模型支援表列出的是「實現情況」，每一列後面標的是版本號，例如 Index-TTS 標 v1/v1.5、CosyVoice 標 v2/v3、F5-TTS 標 v0.6/v1。這張表才是這個專案真正的資產：一份已經接好的模型清單。
兩個入口：webui.py 與 launch.py 的分工
專案把介面拆成兩個進入點，這個切法值得說明。python webui.py 啟動 Gradio 介面，功能集中在互動式操作：音色切換、風格控制、長文本推理、Refiner、分割器設定、調節器（速度、音調、音量與響度均衡）、人聲增強、生成歷史。python launch.py 啟動純 API 服務，README 的說法是「某些情況，你並不需要 webui 或者需要更高的 api 吞吐」。啟動後 http://localhost:7870/docs 可以看到開放了哪些端點，另有 docs/api.md 與 python launch.py -h 可查。
這裡的設計判斷是對的。Gradio 的佇列與前端渲染在批次生成時是純粹的額外開銷，把 API 路徑獨立出來，等於承認 WebUI 只是其中一種消費者。需要注意的是兩者共用同一套模型載入邏輯，所以同時跑會佔兩份顯存，README 沒有提供共享模型快取的說明。
API 端點裡有一個具體的版本分界：Breaking change log 記載 241111 新增 v2/tts API。也就是說舊的 tts 端點與 v2/tts 並存，欄位不同。寫整合程式碼時要確認自己打的是哪一個，不要照著舊範例改。
長文本怎麼切：分割器、Refiner 與 Batch Size
多數 TTS 模型對單次輸入長度有硬限制，長文本必須切。Speech-AI-Forge 把這件事做成可調參數而不是寫死的邏輯。WebUI 的 TTS 區塊下有分割器設定，可控制分割結束符（eos）與分割閾值；另有 Batch size 設定，README 說明它用於「提升支持批量推理模型的长文本推理速度」。
ChatTTS 走的是另一條路：專案支援 ChatTTS 原生文本 refiner，README 稱其「支持无限长文本处理」。這代表同一份長文本在 ChatTTS 與其他模型上會走不同的處理路徑，行為不會一致。如果你的評估標準是跨模型輸出穩定性，這一點要先接受。
SSML 是第三條路徑。README 列出 SSML 區塊下有分割器、Podcast、From Subtitle、腳本編輯器。Podcast 的用途寫得很具體：建立長文本、多角色的音頻，適合播客或劇本式合成；From Subtitle 則從字幕檔生成 SSML 腳本。腳本編輯器支援從分割器匯出並編輯 SSML 再送回去合成。對於要把有聲書或對話式內容批次生產的人，這條路徑比逐段呼叫 API 實用。
部署路徑與實際會踩到的依賴
README 給了三條部署路徑。Windows 使用者可直接取 Releases 的整合包，最新一版是 portable_v0.7（2026-02-02）。Colab 使用者有現成 notebook。本地部署則要先看 docs/dependencies.md 裝好依賴，再依模型下載權重，然後執行 python webui.py。
容器部署分成兩個 compose 檔：docker-compose -f ./docker-compose.webui.yml up -d 與 docker-compose -f ./docker-compose.api.yml up -d，環境變數分別放在 .env.webui 與 .env.api。這種把 webui 與 api 拆成兩個 compose 檔的做法，讓你可以只部署其中一個，對資源有限的機器是合理的。
README 沒有列出各模型的顯存需求，也沒有說明依賴的具體版本範圍。這是評估時最大的空白。CosyVoice、FishSpeech、Index-TTS 這類模型的推論依賴彼此可能衝突，docs/dependencies.md 是唯一線索。先在目標機器上跑通一個模型，再逐步加第二個，比一次裝齊所有模型穩妥。
AGPL-3.0 是這個專案最硬的邊界
授權是 AGPL-3.0。這不是可以忽略的細節。AGPL 的網路條款意味著，如果你修改了這個專案並把它作為網路服務對外提供，你需要向使用者提供對應的原始碼。把它包在自己的 SaaS 後端、不對外散布二進位，並不會讓你繞過這個義務。
這對內部工具沒有影響，對閉源產品則可能是致命的。評估時要先確認你的使用情境：純內部使用、研究用途，AGPL 不構成障礙；要把 TTS 能力做進要賣的產品，就得考慮替代路線或取得另行授權。這裡不提供法律意見，實際判斷請找法務。
另一個常被忽略的層面是模型本身的授權。專案整合了十來個上游模型，每個模型的權重都有自己的授權條款，README 的模型表只列連結，沒有彙整各模型的授權狀態。AGPL 管的是這個專案的程式碼，管不到你下載的權重。兩件事要分開查。
維護成本來自上游，不是來自這個專案
看 Breaking change log 的時間分布，會發現更新頻率相當高：240723 支援 CosyVoice、241009 支援 FireRedTTS、241109 支援 fishspeech、250505 支援 Index-TTS、250507 支援 F5TTS-v1、250508 支援 Spark-TTS、250518 支援 SenseVoice ASR、250522 支援 GptSoVits、250912 支援 Index-TTS-2、260129 支援 Qwen3-TTS、260202 支援 CosyVoice3、260402 支援 Cloud TTS（minimax tts）。
這份清單說明維護者的主要工作是追上游。對使用者的意義是：上游模型改版，這個專案的適配層就可能需要跟著動，而模型權重的格式變動往往不是向後相容的。升級前要確認對應的模型版本，例如表上寫的 FishSpeech 是 1.4、F5-TTS 是 v0.6/v1，這些版本號決定了你要下載哪一份權重。
專案本身沒有版本號語意化，Releases 只有 portable 整合包，程式碼變更直接進 main。這代表沒有穩定分支可依賴，鎖定 commit 是你自己的責任。對生產環境而言，這是需要納入考量的風險。
什麼時候該用別的方案
如果你的需求是單一模型、單一語言、固定音色，這個專案的多模型抽象層就是多餘的。直接使用上游專案更省事：要 ChatTTS 就用 2noise/ChatTTS，要 F5-TTS 就用 SWivid/F5-TTS。少了中間層，出問題時查錯的路徑短得多，授權也回到上游自己的條款。
兩者的差異在於取捨方向。上游專案專注把單一模型做到最好，參數命名與載入邏輯都是為該模型量身設計；Speech-AI-Forge 反過來，把每個模型的特性壓進同一組介面，代價是模型特有的能力可能無法完整暴露。舉例來說，ChatTTS 的 refiner 被保留了，但其他模型若有類似的特殊機制，README 沒有說明是否同樣開放。
另一個方向是雲端 TTS。專案在 260402 加入了 MiniMax Cloud TTS 支援，這對不想自己管 GPU 的人是第三條路。它與本地模型的差別是顯而易見的：本地推理沒有 API 呼叫成本與網路延遲，但要自己承擔顯存、模型下載與版本維護；雲端反過來。README 只列出這項支援，沒有提供成本或延遲數字，這部分需要自行驗證。
ASR 方面，專案支援 Whisper 與 SenseVoice，並提供 Force Alignment 做文稿匹配以提高識別準確性。如果你只需要轉錄，faster-whisper 這類專注於推論效率的實作可能更直接。
編輯結論
需要在自己機器上一次跑多個 TTS 模型、並且要一個現成 API 給內部工具呼叫的團隊，這個專案省下的是整合與長文本切分的工。只想用單一模型、或產品要閉源出貨的團隊不該採用，AGPL-3.0 會直接卡住你。動手前先確認三件事：docs/dependencies.md 列出的依賴是否與你的 CUDA 版本相容、你要的模型權重是否已下載、以及 python launch.py -h 印出的參數是否涵蓋你的部署方式。跑起來之後先打 http://localhost:7870/docs，確認 v2/tts 端點的實際欄位再寫進程式。
社群筆記