Ming-3.0-TTS 本機部署：選 0.5B 還是 Tiny？

名稱裡有「Tiny」，不代表它就是最輕鬆的本機部署選項。Ming-3.0-TTS 恰好相反：首次安裝建議從 dense 架構的 0.5B checkpoint 開始；只有在多講者 Podcast 生成不可或缺時，才值得考慮 Tiny。要注意的是，InclusionAI 公開的測試硬體是 H800/H20，並未給出消費級 GPU 的最低門檻。

建立環境前，先選好 checkpoint

Ming-3.0-TTS 提供兩個 checkpoint，底層架構、相依套件與啟動方式都不同。0.5B 適合作為第一個安裝目標；若你更重視說話者相似度或多講者對話，而非部署簡便性，Tiny 的較大體積才有其價值。

兩個 checkpoint 都能生成 44.1 kHz 音訊、支援七種語言，並針對聲音複製、聲線設計、情緒、方言及其他控制功能提供獨立任務模式。官方 repository 以 MIT 授權釋出兩者，並明確指出 Tiny 的固定相依版本與 0.5B 不同，必須使用獨立環境。

「Tiny」描述的是啟用中的 MoE 運算量，並非儲存權重的大小。Tiny model card 指出，其 backbone 有 7.9B 參數、每個 token 約啟用 1.3B 參數，而整個 repository 約為 18 GB。

從 clone 專案到驗證 checkpoint 的本機流程

要穩定地在本機部署 Ming-3.0-TTS，兩個模型應維持在分開的環境中。官方程式碼只需 clone 一次，再依你選定的 checkpoint 安裝對應 requirements、下載權重，並在載入模型前執行相符的預檢指令稿。

安裝 0.5B 環境

基本的 repository 安裝流程如下：

git clone https://github.com/inclusionAI/Ming-3.0-tts.git
cd Ming-3.0-tts
conda create -n ming-tts python=3.10 -y
conda activate ming-tts
pip install -r requirements.txt

0.5B model card 指出，參考設定使用 PyTorch 2.6、CUDA 12.4 與 transformers==4.46.3。FlashAttention 為選用項目，無法使用時會改走 PyTorch SDPA。這個後備路徑能確保相容性，但專案未公布其速度損失。

數字、日期、單位與符號會透過 FST 文字正規化處理。請使用 Conda 安裝指定版本的 Pynini：

conda install -c conda-forge pynini==2.1.6

pynini 並沒有通用 wheel。雖然 --no_text_normalization 可以略過它，但這會把原始縮寫、日期、數字與符號直接交給語音合成器；因此它適合用於除錯，而不是正式環境的預設設定。

為 Tiny 建立獨立環境

不要直接在 0.5B 的環境上安裝 Tiny。官方設定固定使用 Python 3.10.15、CUDA 11.8 wheels、PyTorch 與 torchaudio 2.7.1，以及 transformers==4.46.3：

conda create -n ming-tiny python=3.10.15 -y
conda activate ming-tiny
pip install -r requirements-tiny.txt

Tiny 採用 BF16 運算、可攜式 MoE 迴圈與 FP32 recurrent state。InclusionAI 建議使用 NVIDIA H800；文件則未提供受支援的 CPU、Apple Silicon、GGUF 或 llama.cpp 路徑。

下載並驗證任一 checkpoint

透過 Hugging Face CLI，可以將權重放入固定且容易管理的本機目錄：

pip install "huggingface_hub[cli]"
hf download inclusionAI/Ming-3.0-tts-0.5B \
  --local-dir Ming-3.0-tts-0.5b
python tools/preflight.py --model_path Ming-3.0-tts-0.5b

若使用 Tiny，替換 model ID 並執行它專屬的驗證程式：

hf download inclusionAI/Ming-3.0-tts-tiny \
  --local-dir Ming-3.0-tts-tiny
python tools/preflight_tiny.py --model_path Ming-3.0-tts-tiny

這些預檢指令稿會驗證 checkpoint 與 tokenizer 結構，不會載入權重。中國大陸使用者可改用專案 README 所記載的 ModelScope 下載指令。

先成功生成一個檔案，再考慮架設服務

最有價值的首次驗證，是透過 repository CLI 產生一個 WAV。若要用 0.5B 進行聲音複製，需提供目標文字、參考 WAV、其完全一致的逐字稿，以及 --use_spk_emb；逐字稿屬於 conditioning 流程的一部分，不是可省略的附加資訊。

python infer.py \
  --model_path Ming-3.0-tts-0.5b \
  --task TTS \
  --language_id English \
  --text "The release candidate passed every audio check." \
  --prompt_wav_path reference.wav \
  --prompt_text "This is the exact speech in the reference recording." \
  --use_spk_emb \
  --output output/first.wav

輸出應是一個 44.1 kHz WAV。若 checkpoint 驗證已通過、這個指令卻失敗，請先檢查 CUDA/PyTorch 相容性與參考音檔，再去加裝 UI 或 server 層。Hugging Face repositories 僅發佈 checkpoint；兩份 model card 都說明，實際推論仍需要另外取得 GitHub repository。

參考錄音應保持乾淨，逐字稿也必須精確。官方文件沒有公布理想的參考音檔時長，因此不應把未經文件證實的經驗法則當成硬性驗證要求。

用單一語音端點提供 Ming-3.0-TTS

SGLang-Omni 可在單張 GPU 上，透過 POST /v1/audio/speech 暴露任一 checkpoint。Ming-3.0-TTS SGLang cookbook 的架構是將前處理放在 CPU，並讓 backbone 與 AudioVAE decoder 共用同一張 GPU。

啟動其中一個 checkpoint：

sgl-omni serve --model-path inclusionAI/Ming-3.0-tts-0.5B

接著請求一個 WAV：

curl http://127.0.0.1:8000/v1/audio/speech \
  -H "Content-Type: application/json" \
  -d '{
    "model": "inclusionAI/Ming-3.0-tts-0.5B",
    "input": "The local speech endpoint is ready.",
    "response_format": "wav",
    "seed": 123
  }' \
  --output speech.wav

此端點接受 wav、mp3、flac 或 pcm，預設格式為 WAV。輸入空字串會回傳 HTTP 400；model 欄位必須與啟動 server 時使用的 checkpoint 相同。

播放端不應依賴 token 式串流。SGLang cookbook 表示，即使設定 stream=true，仍會等到生成完成，然後回傳一個完整的 PCM response body。此外，它在聲音複製時只接受一段參考錄音，提供第二段參考音訊會遭到拒絕。

控制功能是任務模式，不是可任意疊加的參數

Ming-3.0-TTS 的控制功能各自對應獨立的任務合約。請依預期輸出選擇正確任務，而不是在一次呼叫中混用所有可用控制項。

官方 cookbook 明確說明，free-form 模式不能與聲線設計、內建聲線、情緒、方言或基本屬性搭配。單句可支援多個 paralinguistic event，但repository limitations 也指出，其穩定性仍不如只有單一事件時。

分數能證明什麼，又不能證明什麼

目前最有力的公開證據，支持將 0.5B 作為預設選擇，而將 Tiny 視為特定需求的專用版本。官方 README 轉載的 Artificial Analysis 結果顯示，Ming-3.0-TTS 在 2026 年 10 月取得 1,069 Controlled Voice Elo 與 93.2% pronunciation robustness；但這些排行榜數據適用於 0.5B，不能據此證明 Tiny 的品質。

供應商評估呈現出確實存在的 checkpoint 取捨。在 Seed-TTS 評估資料上，0.5B 的中文／英文 WER 為 0.800%／1.584%，Tiny 則為 0.820%／1.666%。不過 Tiny 在兩種語言的說話者相似度都較高：0.781/0.728，對比 0.5B 的 0.758/0.691。這些數字來自 InclusionAI 的評估表，而非可在本機重現的測試。

Tiny 並非在其支援的七種語言中都更好。官方多語言表格顯示，Tiny 的韓語 CER 為 6.000%，0.5B 則為 1.728%。Podcast 只有 Tiny 支援，並公布了 2.03% Podcast CER、0.561 conditional speaker similarity 與 2.12 UTMOS；不過 InclusionAI 也將預測的 Podcast 音訊品質列為待改善項目。

實務上的結論很明確：首次部署、韓語需求，以及希望降低操作複雜度時，選 0.5B；只有在要做 Podcast 生成，或你自己的參考音訊測試證實 Tiny 較高的聲音相似度確實值得較大 checkpoint 時，再評估 Tiny。

請在自己的硬體上完成部署驗證

官方安裝成功，並不等於它能在消費級 GPU 上投入正式使用。部署驗收應記錄峰值 VRAM、第一個完整 WAV 的生成時間、real-time factor、失敗率，以及在應用程式實際會使用的語言與參考音訊條件下的輸出品質。

「目前沒有 GGUF/llama.cpp，也沒有消費級 GPU benchmark。」— @TeksEdge on X

這項觀察符合官方公開證據的邊界：0.5B 文件列出的測試系統是 H800-80GB 與 H20-96G，Tiny 則建議 H800。兩份官方 model card 都沒有公布 RTX 4090、RTX 3090、Windows、WSL2、macOS、最低 VRAM 或 real-time factor 的結果。

可依下列順序進行驗收：

1. 執行相符的預檢指令稿，並連同 checkpoint revision 保存輸出結果。
2. 先以 built-in 或 zero-speaker 路徑生成短 WAV，再以正式環境的參考音訊格式重複測試。
3. 針對短、中位長度與長篇正式文字，量測峰值 VRAM 與 wall time。
4. 針對每一種即將上線的語言，分別評估可懂度與說話者身分一致性。
5. 將每個必要控制功能當成獨立任務測試；依賴不受支援組合的設定應直接淘汰。
6. 針對完整 waveform API 行為進行負載測試，包括 request timeout 與 concurrency。

缺少這些量測時，「可在本機執行」只代表參考技術堆疊能在文件記載的資料中心硬體上載入並合成語音。

Ming-3.0-TTS 常見問題

Ming-3.0-TTS 能在 RTX 4090 或 3090 上執行嗎？

官方發佈內容沒有公開最低 VRAM 數字或消費級 GPU benchmark。0.5B 是較合理的起點，但無論使用哪一張卡，都應先在本機驗證峰值配置量與 real-time factor，再做決定。

Ming-3.0-TTS 支援 Windows 或 macOS 嗎？

官方參考環境是以 CUDA 為基礎的 Linux stack。官方 repository 沒有記載原生 Windows、WSL2、Apple Silicon、MLX、GGUF 或 llama.cpp 支援。

Ming-3.0-TTS 可以商業使用嗎？

程式碼與已釋出的 checkpoint 均採 MIT 授權。維護者在使用指引中禁止具欺騙性或未經同意的身分模仿，並要求在合成語音可能被誤認為真實錄音時加以標示。

SGLang API 能即時串流音訊嗎？

不能。文件記載的 stream=true 行為，是等到生成完成後才回傳單一 PCM response body，因此 client 應將它視為完整回應生成，而不是漸進式播放。

我該用 Ming-3.0-tts-0.5B 還是 Tiny？

若你需要較小 checkpoint、較簡單的部署、韓語合成或一般單講者工作，先用 0.5B。只有在多講者 Podcast 生成是必要條件，或本機評估確認 Tiny 較高的中文／英文說話者相似度分數能轉移到你的聲音資料時，才選 Tiny。