Ming-3.0-tts-0.5B 已推出兩次，Ant Group 卻兩次都未公布

有三個日期與 Ming-3.0-tts-0.5B 相關，且每個日期都標記不同事件。Hugging Face 儲存庫建立於 2026 年 9 月 22 日，權重則在兩天後上傳。GitHub 儲存庫直到 2026 年 10 月 19 日才存在，當時首個提交以「Ming-3.0-tts 初始版本」為標題送達。Artificial Analysis 同日開設模型頁面並給予評分。無論在這兩個日期中的哪一天，我們都找不到 inclusionAI 的部落格文章、新聞稿或發布討論串。撰寫本文時，該模型檢查點有六次下載、零個讚；GitHub 儲存庫則有兩顆星。像這次發布背後有紀錄的 AI 失敗與代理事件，都收集在 OrcaRouter AI 事件檔案，其中每筆條目都附有自己的來源、嚴重程度、信心等級與爭議標記。

這對本篇文章其餘部分該如何解讀很重要。螞蟻集團（Ant Group）的開放權重團隊已發布一個完整、以 MIT 授權的語音模型，具備 14 個標籤的副語言系統、文字轉語音設計、兩種中文方言，以及完整的基準測試結果表。但到目前為止，它也拒絕向任何人說明此事。以下內容將區分倉庫所證明的事項，與只有螞蟻才能確認的事項。

這三個日期，以及每一個實際上涵蓋的內容

這種混淆並非刻意製造。Ant 自家的兩個儲存庫在公開場合彼此不一致，而兩者都沒有錯。

• 2026年9月22日 12:46 UTC — Hugging Face 儲存庫已建立，初始提交包含一個佔位用的 README。尚無權重。

• 2026 年 9 月 24 日 04:21 UTC — 該檢查點透過一次 upload-large-folder 提交正式上線，二十分鐘後又補上一份針對該模型的 README。從此刻起，這個模型便可供下載，而幾乎沒有人下載它。

• 2026 年 10 月 19 日 07:03 UTC——GitHub 儲存庫建立完成。08:58 UTC，第一筆提交「Ming-3.0-tts 初始發行」帶來了推論程式碼、Dockerfile、一鍵範例腳本，以及任務操作指南。整個下午持續有文件相關的提交。

GitHub README 的 News 區塊說 0.5b 與 tiny 模型是在「2026.10」發佈的。Hugging Face 模型卡則完全沒提到日期。兩者描述的是同一個產物：檢查點在九月就已存在，可用的發佈版本——程式碼、環境版本鎖定、範例——則在十月到位。如果你是在為採購文件標註模型日期，9 月 22 日是它公開的日期；如果你是以「可以實際執行」的角度標註日期，10 月 19 日才是誠實的答案。

我們無法告訴你的是原因。對一個期待由模型卡來說明一切的研究機構而言，低調發布是正常的。而當計畫有更大的公告時，這也正是分階段發布的樣子。兩個儲存庫中都沒有說明是哪一種情況，而我們不會去猜。

0.5B checkpoint 裡面有什麼？

此模型是以 Qwen2.5-0.5B 為骨幹建構的稠密語音生成器，搭配 diffusion-transformer patch 頭與獨立的音訊 tokenizer。發布包不只是一套語言模型：儲存庫在同一個資料夾內一併提供骨幹、DiT 頭、音訊 VAE、ONNX 形式的 CAM++ 說話者編碼器，以及文字 tokenizer。這項打包決策，正好說明了你立刻就會遇到的一處不一致。

• 參數——模型卡和模型名稱都標示 0.5B；但 Hugging Face 自家的中繼資料把該儲存庫列為 1B，而單一的 model.safetensors 檔案為 2.96 GB。0.5B 這個數字指的是語言主幹。你實際下載的套件在 bf16 下大約是該數量的三倍。

• 輸出 — 44.1 kHz 音訊，這高於大多數開源 TTS 發佈版本，也是這裡少數幾項你能用檔案檢查工具在十秒內查證的說法之一。

• 語言 — 中文、英文、德文、西班牙文、法文、韓文與日文，另外若提供該方言的參考音檔，還包括四川話與粵語。

• 語音 — 可從簡短的參考音檔進行零樣本複製、依自然語言描述設計聲音，並內建超過 100 種中文語音與五種英語語音。

• Control — 14 個內嵌標籤，用於笑聲、嘆息、咳嗽、呼吸與猶豫，另可明確設定情緒、速度、音高與音量。說明卡坦承，音高是這四項中最不準確的。

• 任務 — TTS、自由形式指令、語音設計、多語言、基本屬性、情緒、方言以及內建語音模式。這些控制項在設計上互斥：自由形式無法與語音設計或內建語音合併使用。

• 授權條款 — MIT，權重與程式碼皆同。Ant 的使用免責聲明要求你不要在未經同意的情況下冒充他人，並標示合成語音；這是請求，而非授權條件。

同一個發佈版本中還有第二個模型。Ming-3.0-tts-tiny 是基於 Ling V3 主幹的混合專家設計，總參數為 7.9B、啟用參數為 1.3B，並新增了 0.5B 模型所沒有的多講者播客生成功能。如果你特別關注的是小模型，比較有用的理解方式是：0.5B 是輕量部署方案，而 tiny 是能力上限——而不是說其中一個會取代另一個。

基準測試表，以及它們是由誰製作的

模型卡上的每一個數字，都來自螞蟻自家的評估工具鏈。這不是在批評——發布表格本來就是這麼一回事——但這些表格正被其他地方引用，卻沒有帶著這個標註，所以在此說明。

• 零樣本 Seed-TTS，中文 — 0.800% 字錯誤率，0.758 說話者相似度。

• 零樣本 Seed-TTS，英文 — 1.584% 詞錯誤率，0.691 說話者相似度。

• NVBench 副語言、單一事件 — 中文字元錯誤率 2.70，英文 7.60。

• 方言，WSC-Eval-TTS-easy — 字元錯誤率 2.27%，準確率 80.68%。

• 語音設計，InstructTTSEval-ZH — 平均 72.29%。

• 基本屬性控制 — 平均 93.30%，詞錯誤率為 0.317%。

有趣的是，同樣這些表格在模型自己選定的競爭對手面前呈現出什麼結果。在中文零樣本錯誤率上，CosyVoice3-1.5B 為 0.710%，Qwen3-TTS-12Hz-1.7B-Base 為 0.770%，兩者都優於 Ming 的 0.800%。在說話者相似度上，CosyVoice3-0.5B 的 0.780 勝過 Ming 的 0.758。在英文錯誤率上，Qwen3-TTS-12Hz-1.7B-Base 達到 1.240%，而 Ming 為 1.584%。

所以 Ming-3.0-tts-0.5B 即使在自己的比較集合中也不爭奪準確率寶座，而它也不需要這麼做。它的強項在於其他模型未填補的欄位：方言控制、聲音設計，以及一套副語言功能，其中它在大多數單一事件類別上領先。請把這張模型卡解讀為「以五億主幹參數實現廣泛控制能力」，而不是「最佳錯誤率」，這樣它就站得住腳。

這張卡片也異常願意指出自身弱點，這一點值得重申，因為大多數都不會這樣做：說話者相似度落後於內容準確度，法語相似度是最明顯的多語言差距，多事件副語言句子仍不穩定，當詞語本身不帶情感訊號時情緒控制會退化，而開放式語音設計仍未及得上評測時對照的最強系統。

第一個獨立數字在公告發布之前就到了。

Artificial Analysis 於 10 月 19 日將 Ming-3.0-tts 加入其語音競技場，並將該條目連結到這個確切的 0.5B checkpoint，這釐清了該卡片留下的一個疑問：被評分的模型是較小的那個。兩個排行榜、兩個結果，而它們指向不同方向。

• Provider Voice：每個模型都使用自己原生的語音——Elo 1,188，95% 區間 1,173 至 1,203，在排行榜上的 98 個模型中排名第 19，在開放權重模型中排名第三，僅次於 Fish Audio Drama 3 Preview 的 1,245 和 Breeze T​TS 2 的 1,220。

• 受控語音：每個模型都複製同樣的八個參考語音——Elo 1,069，區間 1,053 至 1,085，總排名第 14，且在開放權重模型中排名第一，領先 Fish Audio Drama 3 Preview 的 1,059 與 Breeze TTS 2 的 1,019。

• 速度 — 在 Artificial Analysis 的硬體上，生成時間中位數為每秒 42.1 個字元，每個請求的生成時間中位數為 2.46 秒。作為對照，在同一套設備上，Simba 3.2 測得每秒 77.8 個字元，Qwen-Audio-3.0-TTS-Plus 則為 25.6。

那種區分是任何人針對這個模型發表過最有用的內容。它的克隆聲音可與排行榜上最佳的開放權重系統競爭；它自家的聲音陣容則不行。無論 Ant 的原生語音錄音是什麼，它們就是拖低供應商語音排名的那部分，而那是可修正的工程問題，而非架構問題。

有一項我們無法驗證的廠商說法：專案頁面指出，Ming-3.0-tts 在 Artificial Analysis 的發音穩健性指標上以 93.2% 整體排名第一，並在其兩個子類別中也排名第一。該指標確實存在，且 Artificial Analysis 會公布，但我們能讀取的頁面資料並未揭露各模型的數值，因此，在你親自看到長條圖之前，請將 93.2% 視為廠商提供的數字。

執行它大約需要二十分鐘，以及三次修正。

Hugging Face 儲存庫僅是檢查點釋出。頂部附近的提示框寫明了這點：推論需要 GitHub 專案，而模型卡中提到的 Python API 與 CLI 都來自那裡。這是第一個摩擦點，也是十月的儲存庫比九月的上傳更重要的原因。

第二個是文字正規化。數字、日期、單位和符號由需要 pynini 的 FST 文法處理，而 pynini 沒有通用 wheel；Ant 自己的指示會引導你到 conda-forge 取得 2.1.6 版。如果你不想這麼做，--no_text_normalization 會跳過它，而你就得沿用文字目前的樣子。對正式上線的旁白管線來說，這是個實際的決定，不是腳註。

第三點是硬體。環境固定為 PyTorch 2.6、CUDA 12.4 與 transformers 4.46.3，並附有 Dockerfile，且已在 H800-80GB 與 H20-96G 上測試過。flash-attn 為選用項目，推論會回退到 PyTorch SDPA。發布內容中沒有任何跡象顯示這能在消費級顯卡上順暢運行，而目前 Ant 以外也還沒有人公布較小型硬體上的吞吐量數據。

環境啟動後，最小可行的呼叫方式是單次 CLI 叫用，並附上參考片段及其逐字稿——複製會同時以這兩者為條件，而 --use_spk_emb 會啟用說話者嵌入條件化。另外還有一個預檢腳本，可在不載入權重的情況下檢查檢查點與分詞器；在你把 GPU 配置花在糟糕的下載之前，值得先執行它。

什麼至今仍不可知？

有四件事會改變這個模型應受評判的方式，而它們目前都還不存在。

沒有託管端點，也沒有價格。Artificial Analysis 將價格欄位列為空白，因為沒有東西可以定價——唯一能呼叫它的方式就是自行執行。對擁有 GPU 的團隊來說這沒問題，但對其他人來說就是個問題，而這也是這個版本與它將被拿來比較的託管語音之間，最大的單一實務差異。

沒有技術報告。GitHub 路線圖把它列為未勾選的方框，而 Ant 從模型卡中移除了先前對一份未經證實報告的提及。這使得架構描述僅停留在圖表和一段文字的層面，足以執行該模型，卻不足以重現其訓練聲明。

目前沒有獨立的錯誤率複現結果。Seed-TTS 與 NVBench 的數字是 Ant 的，是依 Ant 的協定與 Ant 建議的推論設定測得。競技場分數是獨立的，但衡量的是偏好，而非準確度。實驗室外沒有人發表過這個檢查點的詞錯誤率。

而且沒有任何意向聲明。沒有公告就意味著沒有支援承諾、沒有棄用政策，也沒有任何跡象顯示是否會推出託管服務。對於以 MIT 授權的研究性發布而言，這可能完全是有意為之。對於任何打算把它納入產品的人來說，這是必須納入成本評估的風險。

OrcaRouter 並未路由 Ming-3.0-tts-0.5B，而本文也不應被解讀為暗示相反情況——型錄中並未收錄任何 Ming 語音模型。型錄實際收錄的是語音管線的其他部分：openai/tts-1 與 tts-1-hd、gpt-4o-mini-tts，以及 Gemini TTS 預覽版，全數以供應商定價提供，未加收任何加成，並且同一個金鑰背後還有超過 200 個文字模型，供系統中負責撰寫腳本或驅動代理的那一半使用。如果你正在評估一個尚未經證實的開放權重語音模型，合理的部署方式是讓它遠離關鍵路徑，直到它證明自己值得這個位置；跨供應商的自動容錯移轉，正是讓該管線的文字半邊在你做決定時仍保持運作的辦法。

下一個真正的訊號不會是另一張基準測試表。它會是 Ant 之外的第一個人，在自己的音訊上執行 0.5B checkpoint，並公開哪些地方出了問題。在這樣的情況出現之前，站得住腳的總結很有限：一個真正有能力、以 MIT 授權、44.1 kHz 的多語言語音，在獨立排行榜上擁有最佳的開放權重複製語音分數，原生音色陣容較弱，發布未經宣布，且沒有託管落腳處。那是有前景的研究產物，還不是產品決策。