Ming-3.0-tts 與 Ming-3.0-tts-tiny：較小的檢查點更值得下載，而較大的那個是唯一有人實測過的

Ant Group 以同一個名稱推出了兩個語音模型，而命名正是第一個會誤導你的地方。Ming-3.0-tts-the-default 是 0.5B 稠密模型：磁碟上占 2.96 GB，以 Qwen2.5-0.5B 為主幹，速度快、成本低，也是兩者中唯一有獨立評分的模型。Ming-3.0-tts-tiny 則是兩者中較大的那個，且大了一個數量級——它是 7.9B 參數的混合專家模型，每個 token 有 1.3B 活躍參數，建構於 Ling V3 主幹之上，分片權重共 18 GB——它之所以叫 tiny，是因為執行成本，而不是下載成本。只憑標籤挑選，你就會拿到錯誤的檔案。像這次發布背後有紀錄的 AI 失效與代理事故，都收錄在 the OrcaRouter AI Incident Archive，其中每筆條目都附有自己的來源、嚴重程度、信心等級與爭議標記。

第二件會誤導你的事是排行榜。Artificial Analysis 列有 Ming-3.0-tts 這一列，Provider Voice Elo 為 1,188、發音穩健性為 93.2%，而該列連結到 0.5B 檢查點。這些都不屬於 tiny。tiny 的數字是 Ant 自家的表格，發佈在模型卡與 GitHub README 中，且沒有任何第三方重現過其中任何一項。所以，誠實的比較有兩半：一個模型有獨立證據但沒有 podcast 模式，另一個模型有廠商證據，並具備前者所缺的能力。你需要哪一半，取決於你的工作負載，而不是哪個模型更好。

相同架構系列，兩款截然不同的機器

兩個模型共用 Ant 在 README 中描述的生成框架：文字與任務專用的控制詞元會對語言模型進行條件化，再由該模型驅動一個擴散 Transformer 的 patch head，輸出音訊詞元。差別在於底下所使用的語言模型。0.5B 版本採用稠密的 Qwen2.5-0.5B；tiny 版本則採用稀疏的 Ling V3 混合專家模型，總參數量為 7.9B，每個詞元約啟動 1.3B。

• 下載大小 — Ming-3.0-tts 2.96 GB，對比 Ming-3.0-tts-tiny 約 18 GB，分散於 30 個分片

• 參數 — 0.5B 稠密模型 vs 7.9B 總參數 / 1.3B 啟用參數 MoE

• 主幹 — Qwen2.5-0.5B 對比 Ling V3

• 執行階段 — 在 Python 3.8 時代的技術堆疊上使用 PyTorch 2.6 + CUDA 12.4，對比 Python 3.10.15 + PyTorch/torchaudio 2.7.1+cu118

• 硬體 — 已在 H800-80GB 與 H20-96G 上測試，建議使用 H800；SGLang-Omni 可在單一 GPU 上提供服務

• 多講者播客生成 — 不支援 vs 支援

• 授權條款 — MIT 對 MIT

• 獨立競技場評分 — 是，1,188 Provider / 1,068 Controlled / 93.2% 發音，對比無

這兩個檢查點並不共用同一個 Python 環境。這不是文件上的小毛病；這代表想在同一台機器上評估兩者的團隊得維護兩個 virtualenv，而想在生產環境對兩者做 A/B 測試的團隊則得維護兩個部署映像。如果你的計畫是「先從小規模的開始，之後再升級」，請把遷移當成一項真正的工作來編列預算，而不是只當成設定變更。

以 Ant 自己的數字來看，微小確實更勝一籌之處

說話者相似度是最明確且最一致的優勢，而這個數值決定複製出來的語音聽起來是否像本人。

• Seed-TTS 中文說話者相似度 — Ming-3.0-tts 0.758 對比 tiny 0.781

• Seed-TTS 英文說話者相似度 — 0.691 對 0.728

• 德語相似度 — 0.753 對 0.791

• 西班牙語相似度 — 0.763 對 0.797

• 法語相似度 — 0.675 對比 0.733

• 日語相似度 — 0.765 對 0.780

• 韓語相似度 — 0.793 對 0.797

Tiny 在相似度上於每種語言都勝出，通常領先三到六個百分點，而這個模式在對照基準上也成立：CV3 情緒平均為 74.00%，對比 72.33%；語音設計準確率為 75.37%，對比 72.29%。這兩件事是客戶不用被告知就會注意到的——聽起來像不像我，以及有沒有做到我描述的事。在這兩方面，7.9B MoE 都領先。

內容準確性的劃分方向正好相反，而且這種劃分並不對稱。

• Seed-TTS 中文詞錯誤率 — 0.800% 對 0.820%。基本上不相上下；稠密模型略佔上風。

• Seed-TTS 英文詞錯誤率 — 1.584% 對 1.666%。Dense 領先。

• 德語 — 0.365% 對 0.325%。微幅領先。

• 西班牙語 — 1.099% 對 0.971%。微幅領先。

• 法語 — 4.264% 對 3.470%。Tiny 大幅領先。

• 日文字元錯誤 — 3.765% 對 3.427%。微幅領先。

• 韓文字元錯誤 — 1.728% 對 6.000%。Dense 領先達三點五倍。

韓語是那個異常值，應該讓任何人都不會把「tiny 在多語言上更好」當成結論。Ant 自己的卡片就標示了這點：韓語在 tiny 模型中擁有最大的多語言準確率差距，而 6.000% 這個數字是五億參數模型所達到水準的三倍以上。為韓國市場打造的團隊有明確答案，而且那不是更大的模型。

不是基準的能力

Ming-3.0-tts-tiny 能根據帶有說話者參考的腳本生成多說話者的播客對話。Ming-3.0-tts 則不能。這是產品能力，不是分數，也不會出現在任何排行榜上——這正是為什麼在比較兩份都列出「語音克隆」和「語音設計」的規格表時，很容易忽略這一點。

Ant 的 podcast 評測在其自有測試框架上顯示，tiny 的字元錯誤率為 2.03%、語者相似度為 0.561、UTMOS 為 2.12；相較之下，ZipVoice-Dia 的 UTMOS 為 2.24，FireRedTTS2 的 CER 為 3.34%，MOSS-TTSD 為 8.62%。值得留意的是 UTMOS 的差距：tiny 在內容準確度上領先，卻在自然度上落後於最佳比較對象，而這正是語者相似度數字從另一方向暗示的同一種取捨。Podcast 生成更獎勵輪流發言與語者一致性，而非單一完美片段，而這正是 tiny 優勢的樣貌。

如果你需要的是兩人對話，這裡根本無從比較——一個模型做得到，另一個做不到。本文其餘內容談的都是兩者都能勝任的情況。

獨立缺口究竟會讓你付出什麼代價

在決定要給 0.5B 模型多少權重之前，值得先了解它在競技場中的位置。它的 Provider Voice Elo 為 1,188，在 97 個模型中排名第 18；Controlled Voice 為 1,068，在開放權重模型中排名第一，總排名第 12。在發音方面，它達到 93.2%，實務上與 Fish Audio Drama 3 Preview 持平，並領先 Eleven v4。這些都是獨立測量，且已公開樣本數與信賴區間。

這換來的是校準。你能大致知道稠密模型相對於 ElevenLabs 和 Cartesia 落在哪裡，因為同一個實驗室在同一個排行榜上測量了這三者。至於 tiny，你只知道 Ant 所說的內容，而那是在 Ant 的測試框架、用 Ant 的設定測出來的，而且 Ant 正是結果對其有利害關係的一方。這不是指控——這些表格異常坦白，包括韓語數據，以及一份把音高控制和角色扮演語音設計列為弱點的限制清單。這是在說明一個數字能支撐什麼。供應商表格告訴你，該模型在供應商選擇測量的維度上具有競爭力；arena 榜單中的一列則告訴你，它相對於你已在使用的系統落在哪裡。

還有一件具體的事，獨立榜單也沒有告訴你：它只測了一種聲音。Artificial Analysis 指出，每個模型在發音榜單上都是用單一聲音來評估，而 Ming 那一列使用的是 Ant 的端點，且提供三種原生聲音。93.2% 這個數字在產品實際會出貨的克隆聲音上是否依然成立，仍是未知數，而這正是最值得你自己先測試的地方。

在實踐中選擇

決策樹很短。

選擇 Ming-3.0-tts (0.5B)，如果你想要最小可行的下載檔案、如果你要部署韓語、如果你的硬體是一張還要用於其他用途的單張 80 GB 顯示卡，或者你需要一個行為已由作者以外的人測量過的模型。在獨立測試框架上，它以 2.96 GB 和每秒 44.3 個字元的表現，是一款堪用的旁白模型，能在單一 GPU 上超越即時語音的速度。

採用 Ming-3.0-tts-tiny，如果說話者相似度就是產品賣點——複製品牌嗓音、個人化朗讀，或任何聽眾第一時間會判斷「這聽起來像他們嗎」的用途——或者你需要 Podcast 對白，或者限制條件是法語、德語、西班牙語或日語的準確度。需準備 18 GB 的權重、獨立的 Python 3.10 環境，以及 H800 等級的顯示卡。

兩者都先別採信，但如果你需要在把產能投入 tiny 之前先取得一個獨立數字。arena 那一列並不存在，技術報告在路線圖上仍未被勾選，而 vLLM-Omni 加速在 README 中被標為完成，卻沒有公開的實作配方。這三個缺口，正是會讓 tiny 容易獲得推薦的同一三件事。

有一點操作上的說明同時適用於兩者：這兩個檢查點都不支援串流。兩個模型都沒有公布首次音訊時間（time-to-first-audio），而 arena 的吞吐量數字是針對已完成請求的生成速度。如果你的應用是對話式的，那麼無論你選哪個尺寸，這個系列都不是適合的工具。

路由問題，這裡有所不同

本站大多數比較文章都以一段關於統一存取的內容作結。本篇則不能這麼做，因為 OrcaRouter 並未託管任何一個 Ming 檢查點——目錄中沒有 Ming 語音模型，而兩者都必須透過複製 Ant 的 GitHub 儲存庫並自行執行權重來取得。若聲稱相反情況，那就是讀者三十秒內就能查證的謊言。

真實的情況範圍更窄，但仍然有用。語音管線通常先從文字開始：有某個環節負責寫腳本，有某個環節負責翻譯，有某個環節對照內部風格規範檢查。那個文字階段可以放在單一金鑰之後——超過 200 個模型，按供應商標價提供，不額外加價，自動容錯移轉，當供應商服務品質下降時，以及一套路由 DSL，可根據請求內容把任務送往不同模型。在這項比較中，語音階段無論如何都留在你的硬體上，而自架路徑正是讓這兩個檢查點之間的選擇可逆的關鍵：MIT 權重不會到期，而已經存放在磁碟上的模型，是你在評估其替代品時仍可繼續提供服務的模型。

什麼能讓它塵埃落定

三項進展，依其對推薦結論的影響程度排序。arena 上的一小列數據，就能告訴你相似度優勢能否在盲測聽眾比較中存活下來，而這是唯一尚未進行的測試。技術報告則會說明，為何一個 active 參數 1.3B 的 MoE 提升了說話者相似度，卻損失韓語準確度，以及這是資料切分還是架構造成的結果。而一份已發布的 vLLM-Omni 配方，將使 18 GB 檢查點在租用硬體上變得實用，而不只是研究部署。

在那之前，有用的理解框架是：Ant 針對兩項任務推出了兩個模型，並替它們取了名字，讓較小的那項任務聽起來像較小的檔案。事實並非如此。0.5B 是你能在設計審查中衡量、部署並為其辯護的那一個；7.9B 則是在七種語言中的六種裡，聽起來更像你複製的那個人——前提是你願意單憑信任接受這一點。