Ming-3.0-tts-tiny 對比 VoxCPM2：兩個檢查點，其中一個公開其速度

這是 Ming-3.0-tts-tiny 系列中唯一一個雙方都能實際執行的比較，而這改變了爭論的重點。Ming-3.0-tts-tiny來自螞蟻集團的 inclusionAI，是一個 79 億參數的專家混合模型，每個 token 啟用約 13 億參數，採用 MIT 授權，磁碟上約 18 GB，並列 H800 為建議顯卡。VoxCPM2來自 OpenBMB，是一個 20 億參數、無需分詞器的模型，基於 MiniCPM-4 骨幹，採用 Apache 2.0，bfloat16 下約 8 GB，於 2026 年 4 月發布。兩者都沒有排行榜條目。兩者都沒有託管價格。當兩個模型都可下載且都未被評分時，比較就不再是偏好問題，而是算術問題：每 GPU 小時能產生多少小時的音訊、每個行程佔用多少記憶體，以及你是否能在不自己撰寫訓練程式碼的情況下對它進行微調。像這類發布背後有紀錄的 AI 故障與代理事件，都彙整於 the OrcaRouter AI Incident Archive，其中每一條紀錄都附有自己的來源、嚴重程度、信心等級與爭議標記。

發布歷程值得直說，因為它們解釋了成熟度差距。VoxCPM2 自四月起公開，過去一個月累積約 847,000 次下載，並且在推理之外還附帶訓練腳本。Ming-3.0-tts-tiny 的儲存庫建立於 2026 年 9 月 22 日，權重於 9 月 24 日上線，而直到 10 月 19 日 08:58 UTC、九個提交在一個下午內出現之前，運行這些權重的程式碼並未公開存在。螞蟻尚未宣布該模型。沒有技術報告；路線圖將其列為未勾選項目，而模型卡於 10 月 16 日被特地編輯，以移除對技術報告的提及。所以，其中一個是已有使用者基礎、歷時五個月的專案，另一個則是截至本文撰寫時僅一週大的流程。

它們當中有一個會發佈，另一個則不會。

VoxCPM2 的模型卡指出，在 RTX 4090 上以標準 PyTorch 執行時，即時因子約為 0.30，而在 Nano-VLLM 下則降至約 0.13。即時因子是指每產生一秒音訊所需的運算秒數，因此這兩個數字意味著：在第一種情況下，每 GPU 小時可換得約 3.3 小時的成品語音；在第二種情況下則約為 7.7 小時。

Ming-3.0-tts-tiny 完全沒有公布吞吐量。不是即時因子，也不是每秒字元數，沒有任何在顯示卡上測得的數據。這個版本真正提供的是它驗證時所用的環境——Python 3.10.15、torch 與 torchaudio 2.7.1 搭配 CUDA 11.8、transformers 固定為 4.46.3、H800，以及一支會在您浪費一次執行之前檢查安裝環境的預檢腳本——再加上架構資訊：BF16 下有 8,980,964,372 個參數，F32 下有 40,096 個，總計 7.9B 的專家堆疊，每個 token 約有 1.3B 個活躍參數。

你無法借用 0.5B 同系列模型的吞吐量來填補差距。該模型在獨立測試框架上測得每秒 42.1 個字元，佔用 2.96 GB；這個微型模型每個 token 啟用的參數約為其兩倍半，佔用的磁碟空間則約為其六倍。稀疏路由彌補了較大總參數量帶來的部分成本，而這正是該架構的重點所在，但 Ant 以外沒有人量化過到底彌補了多少。

做成本計算，但其中有個漏洞

因為一方公布其速度，另一方則沒有，所以這項比較誠實的版本是一個範圍，而不是一個具體數字。它的輪廓如下。

• 在 RTX 4090、PyTorch 上運行 VoxCPM2 — 0.30 RTF，因此每 GPU 小時可產生 3.3 小時音訊。一百萬個字元的旁白，以每秒約 15 個字元的語速粗略估算，約等於 18.5 小時的成品音訊，或大約 5.6 GPU 小時。

• 同一張顯示卡上的 VoxCPM2，搭配 Nano-VLLM —— RTF 為 0.13，換算下來每 GPU 小時可產生 7.7 小時的音訊，也就是同樣一百萬字元大約只需 2.4 GPU 小時。這套服務堆疊完全不必更動模型權重，產出就提升超過一倍。

• Ming-3.0-tts-tiny — 未知。在假設每秒 20 個字元的情況下，約需 14 小時的生成時間；若為每秒 10 個字元，則約需 28 小時。這兩個數字都不是實測值，在有人公布實測數據之前，兩者都應視為暫定值。

• 記憶體 — VoxCPM2 在 bf16 下標示約需 8 GB，能放進 24 GB 的消費級顯卡，還留有批次處理的空間。Ming-3.0-tts-tiny 的 18 GB 權重，再加上激活值與音訊解碼器，意味著 80 GB 的 H800 才是合理的目標，24 GB 的顯卡則不夠用。

• 序列長度限制——VoxCPM2 上限為 8,192 個 token，這對長篇工作是一項實質限制，在正式投入前，值得拿你最長的段落來核對。Ming-3.0-tts-tiny 並未公布對應的限制；其長篇處理路徑是 podcast 任務，該任務接收的是腳本，而非單一語句。

在缺了那個數字之後仍然成立的結論，談的是利用率而非速度。一張閒置的顯示卡，無論價格如何，都會輸給每一個託管 API；而一張你已經擁有並持續保持忙碌的顯示卡，無論你跑這兩者中的哪一個，都會在邊際成本上勝出。0.30 與 0.13 RTF 之間的差距，換算成每小時音訊成本是 2.3 倍，這比大多數團隊預期從服務堆疊變更中看到的差距更大，也比參數量差異所暗示的更大。

微調正是兩者不再具可比性之處。

VoxCPM2 的文件說明，完整監督式微調與 LoRA 皆可在少至五到十分鐘的音訊上進行，且兩者各自都有訓練腳本與設定。這不是附註；這正是「租用模型行為」與「擁有模型行為」之間的差別。

Ming-3.0-tts-tiny 記錄的是推論，而非訓練。這個儲存庫是一本任務操作手冊——涵蓋種子語音複製、多語言、副語言、播客、基本屬性、情緒、方言、自由形式、語音設計，以及一個「ip」任務——全部圍繞著單一 MingTinyTTS.from_pretrained 進入點。這裡沒有 LoRA 配方、沒有 SFT 設定，也沒有任何關於是否支援微調的說明。微調很可能確實可行；畢竟檢查點就是檢查點。但「可行」與「有可用腳本且已記錄在案」代表著不同份量的工程投入，而後者正是 VoxCPM2 所提供的。

對品牌調性、受監管領域，或兩種模型都無法直接妥善處理的語言來說，這就是決定性的不對稱。五分鐘的參考音訊加上一份提供的設定，等於一週的工作量。在沒有參考實作的情況下，為一個稀疏 7.9B 模型逆向工程出一條訓練路徑，則要花上一季。

語言、方言，以及「30 種語言」能換來什麼

• Ming-3.0-tts-tiny — 支援中文、英文、德文、西班牙文、法文、韓文和日文；若提供該方言的參考音檔，還可支援四川話和粵語。連同兩種方言計算，共九種。

• VoxCPM2 — 支援 30 種語言，包括粵語和四川話，且說明卡指出不需要語言標記：你只要給它文字，它就會推斷語言。這雖然方便，卻也伴隨一種失效模式，因為混合語言的文字會由模型來判定，而不是由你決定。

在雙方共有的語言上，只有一方公布了各語言錯誤率，那就是 Ant。德語字元錯誤率 0.325%、西班牙語 0.971%、日語 3.427%、法語 3.470%、韓語 6.000%，全都是在 Ant 自家的測試框架上得出，且全都未經重現。VoxCPM2 並未公布各語言表格，因此無法用深度主張來檢驗其廣度優勢。任何在此就語言品質斷言誰勝出的人，都是在拿一家廠商的試算表，對比另一家廠商的沉默。

韓語的數字值得單獨用一句話說明，因為它是 Ming-3.0-tts-tiny 紀錄中最明顯的缺陷：6.000% 的字元錯誤率，大約是它自家 0.5B 同系列模型在同一語言上所記錄的 1.728% 的三倍半。卡片將韓語列為已知弱點之一，卻未提供任何機制說明。稀疏路由的解釋雖屬合理，但尚未經過實測。

牌照問題：差距比表面看起來更小

兩者在商業使用上都很寬鬆，這在這個領域並不常見，值得明白說出來。Ming-3.0-tts-tiny 的權重與程式碼採用 MIT 授權，並附有一則使用說明，要求你不要在未經同意的情況下冒充他人，並標示合成音訊——這是文件中的請求，而非授權條款中的條件。VoxCPM2 採用 Apache 2.0，明確可免費用於商業用途，並有其自身的可接受使用條款。

兩種授權都不會迫使專案走上因法律審查而終止一途，也都沒有那種會讓某些開放權重語音釋出版本在生產環境中無法使用的託管服務例外條款。對於自我託管的部署來說，兩者已經接近到授權不該成為決勝關鍵；真正該成為決勝關鍵的，是訓練方面的整體情況、記憶體佔用量與速度。

他們兩個都不在看板上，而且反正會有一個號碼被借用

Artificial Analysis 在 Provider Voice 上以 1,188 Elo、在 Controlled Voice 上以 1,069 Elo 列出了一個 Ming-3.0-tts 條目。那是 0.5B 模型。Ming-3.0-tts-tiny 沒有 arena 列——不是已排名、不是未排名，也不是預覽條目——而 GitHub README 重現了 1,188 與 1,069 這兩個數字，卻未說明是哪個檢查點產生它們。

VoxCPM2 在兩個排行榜上都完全沒有任何資料列，而其 Hugging Face 頁面也註明，沒有任何推論服務供應商部署它。這種缺席並不是低分。這意味著，沒有人曾把這兩個模型中的任何一個送到偏好評測小組面前，因此這場比較中唯一的品質證據，一邊是 Ant 自家的測試套件，另一邊則什麼都沒有。

如果你需要在開始之前先有一個數字，實用的替代方案是 VoxCPM2 確實會公布的那個：即時因子。它不是品質指標，但它是實測出來的、可以在你自己的顯示卡上重現，而且它能告訴你運行這個模型要付出多少成本。Ming-3.0-tts-tiny 的對應數值則是一個範圍，你得自己測出來。

每個實際上是用來做什麼的

當工作負載是長篇且對成本敏感時，當你需要 Ant 九種語言之外的語言時，當 8 GB 的 VRAM 很重要、因為你的部署是單張消費級顯示卡時，或當你已把用自己五分鐘的音訊訓練 LoRA 列入規劃時，就選擇 VoxCPM2。無需分詞器的設計，以及透過 AudioVAE V2 內建超解析度實現的 48 kHz 輸出，都是真正的工程優勢；而五個月的公開使用意味著各種失效模式是由陌生人而非廠商記錄下來的。

當你需要只有它才提供的功能時，請選擇 {{1}}Ming-3.0-tts-tiny{{/1}}：{{2}}單次即可完成的多講者播客任務{{/2}}、{{3}}14 個內嵌副語言標籤，並可明確控制情緒、語速、音高與音量{{/3}}、{{4}}100 多種中文語音陣容，搭配五種英文語音{{/4}}，以及{{5}}以中文為優先的模型，其方言處理是建構而成，而非推論而來{{/5}}。作為交換，請接受：{{6}}你將是第一個對它進行基準測試的團隊{{/6}}、{{7}}韓文是已公開的弱項{{/7}}、{{8}}微調功能沒有文件說明{{/8}}，以及{{9}}整個版本才剛推出滿一週{{/9}}。

OrcaRouter 並未路由這兩個模型中的任何一個，而本文也不應被解讀為暗示相反的情況——兩者都是透過下載並自行執行來使用。目錄中提供的是同一條流程的文字部分：超過 200 個模型共用一組金鑰，按供應商定價計費、不加收任何費用，因此供應商價格變動當天就能反映給你，並針對撰寫腳本或驅動代理的模型提供跨供應商自動容錯移轉。由於兩種語音選項皆為自行託管，且都不按字元計費，你真正能逐月比較的經常性成本是文字層，而這一層值得放在單一端點之後。

這段比較回到了起點：兩個檢查點、沒有共用的計分板，而最終的決定歸結於你需要的是在中等規格硬體上的速度與微調能力，還是在大型硬體上的中文優先掌控。VoxCPM2 以已公布的數字回答了前者。Ming-3.0-tts-tiny 則以一份任務食譜回答了後者，卻沒有提供吞吐量數字——而這正是 Ant 下一步最該公布的一項資訊。