Ming-3.0-tts 以 0.5B 參數登上 TTS 頒獎台，MIT 讓你能檢視成果

五億個參數大約相當於小型嵌入模型的規模，或幾年前手機等級語言模型的大小。這並不是任何人預期會在獨立文字轉語音排行榜上看到並列第一的規模。然而，Ming-3.0-tts——inclusionAI 團隊推出、隸屬螞蟻集團 Ming-3.0 系列的語音合成產品線——正是如此：其稠密 5 億參數檢查點以 93.2% 的成績並列 Artificial Analysis 英語發音排行榜榜首，而且是我們追蹤的任何 TTS 排行榜前三名中唯一的 10 億參數以下模型。該系列於 2026 年 10 月 20 日以 MIT 授權公開發布，權重放在 Hugging Face 與 ModelScope，推論程式碼則位於另一個 GitHub 儲存庫。

真正立刻值得注意的，並不是小模型表現好。小模型現在已經很好了；大約在第一批蒸餾語音模型出現時，這就不再是新鮮事。有意思的是，一個 0.5B 模型表現好，會如何改變你採購語音功能的方式：它把決策從「我該向哪家供應商租用按字元計費的服務」轉移到「我手上哪張 GPU 還有閒置資源」。這是另一個商業問題，而這正是本次發布真正回答的問題。

哪些已經正式推出，哪些早已外洩

Ming-3.0 語音系列涵蓋三條產品線、共五個模型：文字轉語音、音訊理解與對話，以及語音辨識。這五個模型中有兩個是 TTS 檢查點，而它們並不是同一款產品的不同尺寸版本。

• Ming-3.0-tts-0.5B — 以 Qwen2.5-0.5B 為骨幹的稠密模型，配備 DiT patch 頭、音訊 tokenizer、說話者編碼器與文字 tokenizer。約 2.96 GB 的 safetensors。這是附有獨立量測結果的檢查點。

• Ming-3.0-tts-tiny — 一個建構於螞蟻集團 Ling V3 主幹上的混合專家模型，總參數為 79 億，但每個 token 僅約 13 億活躍參數。總計約 18 GB，分佈於 30 個分片之中。它新增了多說話者播客生成功能。這個名稱指的是執行時成本，而非下載大小，而這項命名決定已經讓許多人感到困惑。

有一個值得釐清的細節，因為它會改變你如何解讀這次發布報導：0.5B 檢查點在公告之前就已經放在 Hugging Face 上了。大約在 10 月 19–20 日出現的，是帶有實際推論程式碼的 GitHub 儲存庫、一場協調一致的開源發布公告，以及獨立的基準測試執行結果。權重並非在公告當天才問世；當天新具備的，是能夠不必反向工程某個檢查點就能運行它們。

目前仍然沒有技術報告。對於一個以架構效率為主要賣點的模型而言，那正是缺失的文件。以下關於為何 0.5B 就足夠的所有內容，都是從模型卡、程式碼與排行榜推斷而來，而非來自一篇解釋訓練配方的論文。

讓 0.5B 變得舉足輕重的算術

TTS 模型的參數量不是抽象的分数。它決定了模型能跑在什麼硬體上，也因此決定了服務成本。

• 外形規格 — Ming-3.0-tts-0.5B 的權重約占 3 GB。以 BF16 計算，這能輕鬆放進單張 24 GB 的消費級顯卡，還有空間容納音訊 tokenizer 與一批並行請求。本專案曾在 H800-80GB 與 H20-96G 上測試，這些是實驗室手邊剛好有的設備，而非模型本身所需。

• Backbone——文字端採用的是 Qwen2.5-0.5B，這是一個廣受支援的架構。這一點對工具鏈的意義更甚於對品質的意義：量化、服務與效能剖析的路徑皆已存在。

• 輸出 — 44.1 kHz 音訊，高於大多數開放語音模型仍會輸出的 24 kHz，並低於阿里巴巴 Qwen-Audio-3.0-TTS 所改用的 48 kHz。對於旁白、Podcast 及大多數產品配音而言，44.1 kHz 可省去重新取樣的步驟。

將這點與經常和它並提的兩個模型相比。Qwen-Audio-3.0-TTS 僅提供 API，且未公開參數量；無論哪個尺寸，你都無法把它放進自己的 GPU。Sesame Preview 的示範語音跑在一個 Sesame 從未發布的正式模型上；可下載的 CSM-1B 則是另一個較弱的模型。相較於這兩者，Ming-3.0-tts 是這番討論中唯一一個其規模是你能據以行動的數字，而不是在定價頁面上讀到的一項資訊。

實際後果就是成本曲線。按字元計費的 API，對第一小時音訊和第一萬小時音訊收取相同費用。自架的 0.5B 模型則收取固定的 GPU 費用，之後邊際成本趨近於零。低於某個用量時，API 顯然更便宜，因為 GPU 費用確實存在，而且處於閒置。超過該用量後，曲線會劇烈反轉。確切的交叉點取決於你的使用率和 GPU 價格，但曲線的形狀無庸置疑。

五億個參數最終落在何處

Artificial Analysis 於 2026 年 10 月測量了 0.5B 檢查點。這些是獨立、由人工評判的執行結果，而非 Ant 自己的表格，這就是它們在這裡具有份量的原因。

• 發音穩健性 — 93.2%，與榜上所有模型並列總排名第一。這正是 sub-1B 主張最站得住腳的一張榜單：緊鄰它的模型，規模都是它的好幾倍。

• 受控語音 — 1,069 Elo，在開放權重模型中排名第一，總體約第 13 名。此排行榜使用八種克隆語音，涵蓋四種美國口音與四種英國口音，因此是公開數據中最接近克隆測試的一項。

• Provider Voice — 1,188 Elo，在開放權重模型中排名第三，總體約第 18 名。這個排行榜採用各模型自家的內建語音，而這也是這個小模型顯得最不出色的地方。

最後那組數字，用兩個數字就道盡了這個模型的全貌。Ming-3.0-tts 在複製聲音時，遠比使用自家預設聲音時強大得多。模型卡在限制章節中也這麼說，而原因在規格表上清楚可見：隨附的目錄是 100 多種中文語音，卻只有五種英文語音。如果你的工作是「用我們的品牌聲音朗讀這份稿子」，五種英文參考語音稱不上目錄，而是一種限制。如果你的工作是「複製這位特定說話者的聲音」，這個模型可與規模大得多的系統競爭。

總體分數也掩蓋了一個具體弱點，而這個弱點正是被頭條數字粉飾過去的：在獨立詞條——品牌名稱、地名、孤立專有名詞——上，該模型在 31 個中排名第 21。它擅長發音評審團所獎勵的序列層級工作，卻不擅長真實腳本中充斥的一次性詞彙。如果你的產品會唸出「Kubernetes」、「Xavi」或客戶的姓氏，請先測試這一點，再相信 93.2%。

MIT 是那個會被人們低估的部分。

授權條款通常是模型發布公告中最無趣的一行，卻是採購審查中最關鍵的一行。Ming-3.0-tts 採用 MIT 授權，兩個檢查點皆然，沒有審批關卡，沒有可接受使用條款的點擊同意，也沒有商業用途的除外條款。

• 微調 — 允許，包括使用你自己的專有語音資料，且無須公開結果。

• 再散布 — 允許，包括內嵌於您所銷售的產品中。

• 稽核 — 程式碼位於 GitHub，因此您可以在將客戶的聲音上傳給模型之前，先透過參考音訊片段了解模型會如何處理它。

這與兩個顯而易見的替代方案有著實質不同的立場。Sesame 的 CSM-1B 採用 Apache-2.0，但需先接受條款才能使用，而且它不是示範中的聲音。Qwen-Audio-3.0-TTS 完全沒有公開權重。對於法務審查會問「說話者音訊會去哪裡」的團隊來說，在這項比較中，MIT 加上本機推論是唯一不需要信任供應商資料政策的答案。

MIT 授權無法帶給你的是正式環境的可用性。Hugging Face 上的儲存庫僅供散布檢查點；若要進行推論，必須複製 GitHub 儲存庫，而這些程式碼僅達到研究等級。它公開至今才不過幾天。這是真實存在的風險，沒有任何授權條款能消除它。

實際運作要花多少成本

並沒有按字元計價，因為沒有託管端點。撰寫本文時，Hugging Face 指出該模型{{1}}未由任何推論供應商部署，{{/1}}這是「開放權重就是中國境外全部產品」最清楚不過的表述。

• 運算 — 單一張現代 GPU 就能處理 0.5B 檢查點；微型 MoE 則需要更多記憶體，且根據該儲存庫，還需要獨立環境。

• 相依套件 — CUDA 12.4、PyTorch、可選的 flash-attn 路徑（會退回 PyTorch SDPA），以及用於 FST 文字正規化的 pynini（除非你停用正規化）。最後這一項在近期 Python 版本上向來是安裝時的老問題。

• 中國境內可使用 — Ant 透過 Ling Studio 提供 API，該模型系列已在 Alipay 搜尋、Afu 健康應用程式及內部辦公工具中進行內部部署。這是真實的生產環境訊號，但並非國際可用的受管端點。

所以誠實的成本說法是：免費的權重，外加一筆維運帳單。如果你本來就在跑 GPU，邊際成本很小，邊際心力則是花一天跟依賴套件搏鬥。如果你沒有，那你現在就是在做 GPU 生意了，而你原本想避開的那個 API，可能很長一段時間內都是比較便宜的選項。

當語音模型位於你自己的硬體上時，路由器適合放在哪裡

OrcaRouter 並未託管 Ming-3.0-tts。我們的平台上沒有 Ming 語音端點，我們也不會暗示並非如此。我們實際託管的是語音管線的另一半：負責撰寫或改寫腳本的語言模型，以及當你想要受管理的語音而非自架語音時可以呼叫的文字轉語音模型，包括 Gemini 3.1 Flash TTS Preview 與 OpenAI 的 GPT-4o mini TTS。

這種拆分比乍聽之下更有用。自託管的 Ming 節點提供語音能力，卻不提供任何可用性保證；其周圍的路由層則補上其餘部分。一組 API 金鑰涵蓋 200 多個模型，以供應商定價 0% 加成，因此供應商降價當天就會在我們這邊生效，而不必等經銷商更新價格表。自動容錯移轉意味著，當你唯一的 Ming GPU 忙碌或故障時，請求可以改由託管的 TTS 模型接手，而不是直接失敗；路由 DSL 讓你能將該備援組合進呼叫中，而不是在應用程式碼裡臨時加裝。這些都不會讓 Ming 本身更可靠。它讓 Ming 周圍的管線能在 Ming 無法使用時繼續運作，而這正是任何研究級自託管模型在生產環境中的實際問題。

什麼會改變這項評估？

有三件事值得關注，而每一件都會讓判斷朝不同方向發展。

第一個是技術報告。Ant 已承諾會提供一份。在它發布之前，效率主張雖有經過測量，卻沒有得到解釋，也無法得知 0.5B 的結果是來自真正更好的架構，還是來自一個精心策劃、卻無法轉移到你的領域的訓練集。

第二是服務支援。儲存庫提到 vLLM-Omni 加速推論是路線圖項目。如果這件事成真，自架成本會再次下降，因為 0.5B 模型跑在完善的 serving stack 上，便宜的程度是研究腳本比不上的。如果沒有成真，你就得無限期維護一條 Python 推論路徑。

第三項是英語。五個內建英語語音是供應商語音評分板上的關鍵限制，而這是團隊最容易修正的一點。更廣泛的英語語音目錄能在不更動架構的情況下，改善模型最弱的指標。

值得懷疑的是標題裡的那個說法：一個 0.5B 模型竟能與體量大它許多倍的模型同登頒獎台。在發音排行榜上，以英文文本衡量，今天確實如此。在供應商語音排行榜上，它在開放權重模型中排名第三，總體約第 18 名；以這樣的規模來說是好成績，但還算不上登台。這兩件事同時成立，而二者之間的差別，正是複製你自己提供的聲音與使用模型內建聲音之間的差別。你需要的是哪一種，決定 0.5B 是否足夠。