VoxCPM2：每月90萬次下載，而Transformers仍然無法載入它

Hugging Face 為 VoxCPM2 提供的元數據將其函式庫列為 voxcpm——而非transformers。這個單一欄位說明了目前開源語音領域一個奇怪的缺口：OpenBMB 的 2B 參數文字轉語音模型在過去三十天內獲得 900,282 次下載，催生了 25 個公開微調版本、10 個量化版本、7 個適配器及超過 100 個 Spaces，但至今仍無法透過該網站上幾乎所有其他模型所使用的函式庫載入。修復此問題的 pull request 於 2026 年 8 月 4 日提出，截至今日仍然開啟。

在修復落地之前，這個差距值得先理解清楚，因為它決定了你本週整合這個模型與下一季整合這個模型，分別要付出多少成本。而在這之上還有一個更有趣的問題：VoxCPM2 是否真的像報導所暗示的那樣遙遙領先。以下所有內容均讀取自三份主要來源：openbmb/VoxCPM2的模型卡與倉庫元數據、OpenBMB/VoxCPM 的 GitHub README，以及 VoxCPM2 技術報告（arXiv:2606.06928，2026 年 6 月 5 日提交）。本文中所有基準測試數字皆為 OpenBMB 自己的、由 OpenBMB 執行；而且——正如論文本身在其主要比較表中所言——表內的競爭對手數字是從其他論文抄錄而來，並非在匹配條件下重新運行。就我們所能查到的資料而言，尚無任何獨立實驗室發表過對其中任何結果的重現。

規格表，一個畫面顯示

VoxCPM2 於 2026 年 4 月發布（Hugging Face 儲存庫建立於 4 月 3 日，最後更新於 4 月 16 日），是 VoxCPM 系列的第三代。相較於其直接前代：

• 大小 — 2B 參數，對比 VoxCPM1.5 的 0.8B 與 VoxCPM-0.5B 的 0.6B 骨幹。

• 語言 — 30 種語言加上 9 種中國方言，而先前兩個版本僅有中文和英文。

• 音訊 — 接受 16 kHz 參考輸入，輸出 48 kHz；而 VoxCPM1.5 則為對稱的 44.1 kHz 輸入與輸出。

• 主幹 — 以 MiniCPM-4-1B（28 層，寬度 2048）作為文本語義語言模型，取代原本的 MiniCPM-4-0.5B（24 層，寬度 1024）。

• 序列預算 — 在 6.25 Hz 的語言模型端 token 速率下，8192 個 token 約等於一個上下文中的 20 分鐘音訊。

• 每秒語音的成本 — 在單張 RTX 4090 上，純 PyTorch 的即時因子為 0.30，透過 Nano-vLLM 則為 0.13，約佔 8 GB 顯示記憶體。VoxCPM1.5 以 0.8B 參數和 6 GB 記憶體達到了 0.15。

• 授權 — Apache-2.0 適用於權重、微調程式碼與推論工具。無使用門檻、無可接受使用附加條款，允許商業使用。

• 訓練資料 — 「超過兩百萬小時」的多語言語音，未提及任何語料庫名稱，也未說明資料來源。

將 RTF 行讀兩次，因為它跑反了。VoxCPM2 生成每秒音訊的耗時大約是它所取代的 0.8B 模型的兩倍，且需要的 VRAM 多三分之一。2B 沒有換來吞吐量；它換來的是語言和控制，並以延遲作為代價。如果你正在執行即時代理，這項取捨是首先要估量的。

PR #47756 實際上更改了什麼

如今，執行 VoxCPM2 意味著安裝 OpenBMB 自家的套件——pip install voxcpm，Python 3.10 至 3.12、PyTorch 2.5 或更新版本、CUDA 12 或更新版本——並透過一個VoxCPM.from_pretrained 呼叫來載入模型，而這個呼叫與 Transformers API 毫無關聯。這個決定之後的所有下游環節都是量身打造的：你自己的批次處理、你自己的服務黏合程式碼、你自己對五種生成模式的處理。

正在進行中的工作將改變這一點。Issue #47695「為 OpenBMB VoxCPM2 新增原生支援」於7月31日提出。PR #47756「VoxCPM2 支援」於8月4日緊接提出，最後更新於8月5日。它帶有「New model」標籤，新增了模組化配置與模型實作、自訂 tokenizer 與 processor、支援串流的 AudioVAE 編碼與解碼、參考語音條件化、提示音訊延續、自動類別註冊，以及文字轉波形管線入口——據報導有64項模型測試通過。它疊加在 PR #47736 之上，後者新增了 MiniCPM4 本身；文字主幹必須先合併，包覆它的語音模型才能合併。

有兩項細節值得重視，而兩者都不利於樂觀。首先，這三項——issue 和兩個 pull request——都是由同一位社群貢獻者開設的，不是 OpenBMB，也不是 Hugging Face 的維護者。背後沒有任何廠商承諾，因此也沒有你可以據以規劃的時程。其次，一個觸及新模態、包含 203 個 commit 的雙 PR 堆疊，不會是一次快速的審查。Transformers 中新模型的 PR 通常需要數週的維護者往返審查，而目前這個 PR 堆疊只有四則評論。

實際的解讀是：如果一個原生 Transformers 類別對你的架構而言是關鍵支柱——因為你標準化在 AutoModel 上，或是因為你的服務層只支援 Transformers——那麼 VoxCPM2 還沒為你準備好，而且目前沒有具體時程。如果你能接受在 voxcpm 套件的框架內運作，這個模型現在就已完全可用，而生態系也已經清楚表態這是可以接受的：在完全沒有任何原生支援的情況下，仍然累積了 900,282 次下載。此外還有一條大多數報導都忽略的中間路線。OpenBMB 提供了一個 vLLM-Omni 整合，公開了與 OpenAI 相容的 /v1/audio/speech 端點，另外還有一個搭載 GGUF 權重的 llama.cpp-omni 建置，可在 CPU、Metal、CUDA 或 Vulkan 上執行，而且完全不需要 Python 依賴。如果你從 Transformers 真正想要的是標準的服務介面，而不是那個類別本身，那麼這已經存在了。

「Tokenizer-free」並不代表未量化。

每個關於此模型的新聞標題中的用語，是最常被誤讀的。VoxCPM2沒有外部離散音訊編解碼器——在語言模型與波形之間，不存在如CosyVoice或Moshi系列中那樣的學習式語音token詞彙表。這就是其主張，而這主張屬實。

模型內部仍然存在量化。主幹網路基於有限純量量化（Finite Scalar Quantization，FSQ）運行一個可微分的半離散瓶頸；論文對其作用的說明十分明確：文本語義語言模型產生隱藏狀態，FSQ 按維度將這些狀態純量量化成一個「語義骨架」；殘差聲學語言模型負責找回 FSQ 所捨棄的細部資訊；而局部擴散 Transformer 則透過流匹配，將這兩條條件流轉換為下一個連續潛在片段。你看到縮寫為 LocEnc、TSLM、RALM 與 LocDiT 的四個階段，正是這條鏈路。

實際上真正重要的區別不在於「量化與否」，而在於瓶頸層是與周圍一切端到端聯合訓練，而非預先凍結成帶有自身損失函數的獨立編解碼器。這正是消除常見失敗模式的關鍵——語言模型學會預測編解碼器無法忠實解碼的 token。VoxCPM2 將 FSQ 瓶頸從 256 維拓寬至 512 維，並將原本以逐元素求和方式饋入殘差模型的做法，替換為可學習的串接投影——這些都是小改動，也是報告中少數由明確機制支撐、而非僅靠基準測試數據差異來證明的改動。

48 kHz 輸出有一部分是虛構的，而這正是設計所在。

「48 kHz 錄音室品質輸出」是這個模型最常被引用的規格，也是最常被誤解的一項。AudioVAE V2 是不對稱的：編碼器以 16 kHz 運作，解碼器以 48 kHz 重建。論文將此稱為「隱式超解析度」，這個名稱名副其實。

接下來談這個後果。16 kHz 編碼器具有 8 kHz 的奈奎斯特上限，所以參考音訊中任何高於 8 kHz 的內容永遠不會進入模型。輸出中最高兩個八度的每一分能量——嗓音裡的空氣感、齒音、鈸邊緣的亮度——都是解碼器從合理的先驗中產生的，而非來自你克隆的那個聲音。對大多數旁白與代理（agent）工作而言，這不是問題，甚至算是改進，因為良好的學習先驗勝過硬性的 8 kHz 截斷。但對任何以忠實重現特定錄音人聲為職志的人來說，這是設計時必須因應的事實，而且不是用筆記型電腦喇叭做聆聽測試就能察覺的。

論文中的理由陳述是報告中最可信的工程論證，值得重述，因為它不是行銷話術：將編碼器保持在 16 kHz，OpenBMB 就能整體重用原始的 VoxCPM 16 kHz 訓練語料庫，消除不同取樣率來源之間的潛在失配，並避免較高輸入率在自迴歸迴圈中必然導致的序列長度爆炸。只提升解碼器，就能在不增加模型昂貴部分負擔的情況下獲得輸出保真度。這是經過深思熟慮的划算交易。這也意味著 VoxCPM1.5 使用者正從 44.1 kHz 編碼器轉向 16 kHz 編碼器——在輸出端升級的包裝下，藏著輸入端的降級。OpenBMB 自家的重建表格顯示了這一點：VoxCPM1.5 的編解碼器仍然在三代產品中取得最佳的全頻段梅爾距離，1.139 對比 AudioVAE V2 的 1.335，因為它以原生高取樣率運作，而非重建升頻到高取樣率。

以 OpenBMB 撰寫的方式閱讀 OpenBMB 的計分板

有競爭力，而非第一

在 Seed-TTS-Eval（標準的零樣本語音複製基準）上，VoxCPM2 在英文集上報告了 1.84% 的詞錯誤率和 75.3% 的說話者相似度，在中文上報告了 0.97% 的字元錯誤率和 79.5% 的相似度，以及在困難中文子集上報告了 8.13% 的 CER 和 75.3% 的相似度。論文對此所用的詞是「competitive」，而表格支持的是這個詞，而非那些流傳中更強烈的說法。

在同一張表格中的開源系統裡，Fish Audio S2 在全部三個子集上都繳出更低的錯誤率（0.99 / 0.54 / 5.99）。Qwen3-TTS 在英文 WER 上以 1.23 擊敗它。而 LongCat-Audio-DiT 在六個欄位中有五個全面勝出——英文的 1.50 WER 與 78.6 相似度、中文的 81.8 相似度、困難中文的 6.04 CER 與 79.7 相似度。VoxCPM2 真正突出之處在於平衡：它是極少數同時在相似度上接近頂尖、在可懂度上也表現出色的系統之一，而且它是該清單上唯一同時具備自然語言語音設計的系統。但「最先進」並非它自己的標題表格所呈現的結果，誠實的說法是：這是一個強勁的通才型系統，而非評測基準的領先者。

3.3倍的參數量幾乎沒有換來任何可理解性的提升

那張表格中最有用的一列，是沒人引用的一列。VoxCPM-0.5B，即2025年9月的0.6B第一代，英文WER為1.85%，中文CER為0.93%。VoxCPM2，參數量2B，得分分別為1.84%和0.97%。英文表現差異在雜訊範圍內，中文則略差一些。

額外參數實際上帶來的效果，只有在相似度欄位中可見，別處看不到：英文 SIM 從 72.9 上升到 75.3，中文從 77.2 上升到 79.5。2B 所帶來的其他一切，完全不在這個基準測試範圍內——多了 28 種語言、從文字描述進行語音設計、可控制風格的複製、48 kHz 輸出。這些確實很多，也是升級的誠實理由。但如果你工作負載是英文或中文複製，且以錯誤率為選擇標準，VoxCPM2 給你的，0.6B 模型早就給了，而且權重是三倍、延遲是兩倍。奇怪的是，VoxCPM1.5 在這項基準上是三者中最差的（2.12 / 1.18），這使得整個系列看起來不像階梯式進步，更像三種不同產品。

一個模型，兩種評測，相差一個數量級

此處需格外謹慎，因為本報告中的兩項多語言結果嚴重分歧，而兩者皆被引述，彷彿已能定案。

這則頭條的重點是30種語言的平均錯誤率為1.68%。這來自OpenBMB自行建立的測試集——每種語言500條語句——並以Gemini 3.1 Flash Lite作為識別器進行評分。在此測試集上，VoxCPM2的英語錯誤率為0.42，中文0.92，印地語0.79，阿拉伯語1.23。

該報告也執行了 MiniMax-MLS-Test，這是一套第三方 24 語言測試集，並以 Whisper-large-v3 進行評分。同樣的模型。在那項測試中，VoxCPM2 在印地語獲得 19.70、阿拉伯語獲得 13.05——分別比自家基準測試宣稱的結果差了二十五倍和十倍，而這些都是它官方支援的語言。同一欄中還有：粵語 38.58、捷克語 24.13、羅馬尼亞語 21.58、烏克蘭語 6.32。

有三件事能化解其中大部分矛盾，而它們值得分開來談，因為這個故事廣為流傳的版本把它們說錯了。

• 捷克語、羅馬尼亞語和烏克蘭語不是受支援的語言。 查看該儲存庫自己的語言標籤：30 個代碼，其中沒有 cs、ro 或 uk。批評 VoxCPM2 在捷克語上有 24% 的 WER，無異於批評一個它從未聲稱支援的語言。粵語看似屬於「9 種中文方言」之列，但該欄位中的每個系統在粵語上的錯誤率都超過 30%，這指向辨識器而非任何模型。

• 阿拉伯語和印地語獲得支援，而這才是真正的發現。 這正是OpenBMB宣稱涵蓋的兩種語言，而其兩次評估結果相差了一個數量級。論文自己的解釋是，這些語言在訓練語料中的「資料量相對有限」，且「較高的WER有一部分可能源於辨識器的準確度有限。」這是合理的假設，也是未經驗證的假設。如果你正在推出支援阿拉伯語或印地語語音的產品，此模型公佈的範圍是0.79%至19.70%，而這兩個數字都未經獨立驗證。預留一天時間自行量測；切勿以任何一個數字作為預算依據。

• 這些指標甚至不是同一單位。印地語在內部資料集上以字元錯誤率計分，在 MiniMax-MLS 上則以詞錯誤率計分。這些數值無法直接相比，因此 25 倍的差距又多了一個不能當作明確指控的理由——1.68% 的平均值也多了一個不該被視為同基準分數的理由。

同樣的謹慎態度也適用於報導這個模型時最具數字分量的一項宣稱：VoxCPM2 在說話者相似度上擊敗 ElevenLabs，英文為 85.4% 對 61.3%，在 24 種語言中贏得 22 種。這確實是表格所顯示的內容。但這也是一張論文部分彙整自先前已發表結果的表格，而且在該表中，ElevenLabs 的可懂度欄位顯示泰語 WER 為 73.94%、越南語為 73.42%、中文為 16.03%。這些不是一個正常運作的商業產品該有的數字；它們是評分或設定配置不符的跡象。一張在某欄位已經有問題的表格，不會因為某個結果對你所閱讀的模型有利，就在另一個欄位變得可信。

單一骨幹，五種模式——驅動數據成長的祕方

這套架構中最乾淨俐落的設計，在於 VoxCPM2 並未為各項能力分設不同的模型或 head。五種模式均使用同一組參數，僅以輸入序列的排列方式區別，{{1}}因此單一個 2B checkpoint 便能涵蓋通常需要一小群模型才能做到的事{{/1}}：

• 基本 TTS — 文字輸入，語音輸出。

• 語音設計——括號內的描述只是直接加在文字前面，所以「(一個疲憊的中年男子，聲音沙啞，說話緩慢)」和台詞本身會經過同一個語言模型，不需要額外的模組。完全不需要參考音檔。

• 參考語音複製 — 透過獨立的參考片段設定說話者身分，無需文字轉錄稿。

• 可控式克隆 — 參考片段加上風格描述，因此你可以克隆聲音，然後讓它聽起來急促或有趣。

• 接續克隆——參考片段與其轉錄文字配對，視為供模型接續的音頻前綴，這是保真度最高的模式。

報告中埋藏著一個多數評測文章都不會提到的旋鈕，而它正是最可能改變你結果的那一個。兩個條件化路徑——獨立參考與延續前綴——可分別使用或合併使用，且彼此此消彼長。在 OpenBMB 自己的消融實驗中，兩者合併使用能在每個子集上取得最佳的說話者相似度。若捨棄延續前綴、僅以獨立參考作為輸入，則可在困難的中文文本上獲得最佳可懂度，CER 從 7.44% 降到 6.85%，但相似度損失約五個百分點。論文中的解釋是合理的：沒有時間音頻前綴來鎖定韻律時，模型更有自由去選擇一種能克服困難文本的呈現方式。

所以，預設值是一個選擇，而非上限。語音匹配工作需要兩種途徑；困難或不尋常的文字則只需要參考。老實說有個小問題：該消融表中的絕對數字，與論文聲稱全程使用的配方之主表格對不上；在預印本中，這更像是記錄疏失，而非什麼邪惡之舉——但這是第三個理由，讓我們把這裡的每個數字視為待測試的方向，而非可引用的數值。

語音設計：聽話重於自然

語音設計是讓這次發布顯得有趣而非僅是漸進式更新的功能，而正是在這方面，廠商自己的數據最能揭示出真實的取捨。

在 InstructTTSEval 上，VoxCPM2 在聲學參數指定方面得分為 84.2，在描述性風格指令方面得分為 83.2，在英語角色扮演方面得分為 71.4——最後這個數字是表格中最佳的，領先於 Qwen3-TTS-1.7B-VD 的 68.4 和 Gemini-TTS-Pro 的 67.2。在中文方面則較弱，排序翻轉：85.2 / 71.5 / 60.8，而 Gemini-TTS-Pro 則為 89.0 / 90.1 / 75.5。因此，最有力的說法是，VoxCPM2 在英語角色扮演方面領先，而在指令遵循的其他幾乎所有方面都落後於一個封閉式前沿系統。

根據報告，這個人類聽覺測試小組——由 50 名聽眾組成，採用隨機化和雙盲設計——使評估結果更加精確。在可控生成方面，VoxCPM2 在指令跟隨上以 4.50 對 Qwen3-TTS-VD 的 4.41 領先，但在自然度上以 4.48 對 4.61 落敗。在純零樣本克隆方面，它在語者相似度上獲勝（4.74 對 4.69），並在自然度上持平或略遜一籌（4.78 對 Qwen3-TTS 的 4.80，信賴區間重疊）。

這個模式已經足夠一致，可以據此規劃：VoxCPM2 會執行你的指令，但這樣做時聽起來稍微沒那麼像真人；而 Qwen3-TTS 聽起來稍微好一點，對指令的遵循程度則稍微差一些。哪一個才對，完全取決於你的產品價值在於精確控制還是流暢輸出。OpenBMB 本身在其限制說明中也點出了這個結論，而這正是廠商通常會略過不提的事：語音設計與可控複製「在不同運行之間可能產生變異結果」，要得到你想要的聲音，可能需要多次嘗試。請在流程中加入重試機制，而如果聲音很重要的話，再加一道人工聆聽把關。

營運需要多少成本，以及何時租賃才是正確選擇

各地都沒有託管 VoxCPM2。Hugging Face 自家的側邊欄說得很清楚——「此模型未由任何推理提供者部署」——這也包括我們：OrcaRouter 不提供 VoxCPM2，而且再怎麼想要也改變不了這個事實：一個沒有推理合作夥伴的 2B TTS 模型，要嘛是你自己託管權重，要嘛就是什麼都沒有。

這使得成本問題變成一個 GPU 問題，而且計算很簡潔。在單張 RTX 4090 上，以 Nano-vLLM 即時因子 0.13 計算，一個 GPU 小時可產生約 7.7 小時的音訊，因此你每音訊小時的成本，就是一張 24 GB 顯示卡的時薪除以約 7.7。在純 PyTorch 下，RTF 0.30 時，每 GPU 小時產出的音訊就降到約 3.3 小時。這兩個數字都是 OpenBMB 的數據，是在他們的硬體和文字上測量得到的，而在你的環境下，這兩個數字都會變化——批次大小、文字難度，以及你的品質關卡迫使系統進行的重試次數，都是 RTF 數字未包含的乘數。重試率是大家常忘記的一點：如果廠商告訴你，某個模型可能需要多次嘗試才能達到目標語音，那麼它的實際成本就不會是 RTF 所暗示的那樣。

此時人們想要的比較，是與租用的 API 相比，而誠實的答案是，這兩者無法乾淨地換算。openai/tts-1-hd的計費為每百萬個 token（進出合計）$30.00——這是供應商的列表價格，在 OrcaRouter 上直接轉嫁，因為我們的加成是 0%，所以我們模型頁面上的數字就是 OpenAI 收取的數字。但 token 不是秒，沒有任何公開的費率能可靠地換算兩者，足以讓你據此建立試算表。任何向您展示自架開放權重 TTS 模型與按 token 計費 API 之間乾淨的每小時比較的人，都做出了一個他們沒有向您展示的假設。

值得說明的是架構上的界線落在何處。當你需要特定的克隆語音、當音訊量夠穩定而能讓 GPU 保持忙碌、當資料不能離開你的基礎設施、或是當你打算對它進行 LoRA 微調時，自行託管 VoxCPM2 就很有意義——而且它只需要 5 到 10 分鐘的目標音訊即可支援微調，這確實相當便宜。當流量起伏不定、你無法配置 GPU 人力、或語音可替換時，租用就較為合理。大多數真實的語音產品其實是兩套系統，而非一套：一個合成層，加上一個負責「腦內推理」的語言模型。推理那一半才值得放在單一 API 金鑰後面，並在多家供應商之間自動容錯轉移，如此一來，模型替換只是改個字串，而不是走一輪採購流程；這正是 OrcaRouter 的用途所在，涵蓋 200 多個模型。而合成那一半，當它是你擁有並微調的特定語音時，則應該放在你自己的硬體上。VoxCPM2 正屬於第二類，而目前沒有人提供這項服務，是它的本質使然，而非疏漏。

OpenBMB 告訴你不要期待什麼

對於擁有如此大聲勢的發佈來說，這個限制章節異常坦率，而且簡短到足以讓人認真對待：

• 克隆品質是濫用面。 模型卡直接說明了這點：該模型生成的語音逼真到足以用於冒充和詐欺，而AI生成的音訊應予以標示。Apache-2.0 對此完全沒有任何限制——不像幾個競爭的開放權重語音模型的授權條款，這裡沒有可作為擋箭牌的可接受使用條款。你的同意與揭露政策由你自己撰寫。

• 運行間變異是預期的，在兩個控制特徵上並非需要回報的錯誤。

• 這30種語言是真正的界限。超出這些語言的任何內容可能可行但未經測試；預期需要微調。

• 風格控制一致性被描述為仍在開發中，由構建它的人。

而這張卡片未指出的缺口：完全沒有訓練語料庫的揭露，因此權重的 Apache-2.0 授權只解決了程式碼問題，對資料溯源則隻字未提。本文中沒有任何數據經過獨立評估。沒有以毫秒為單位發布的延遲數據——RTF 是吞吐量比率，而語音代理的生死取決於首次音訊時間，這在報告中完全沒有出現。

模型卡未能解決的三個問題

我是否應該轉換掉 VoxCPM1.5 或 VoxCPM-0.5B？

僅限於新的功能，而且只有在測量之後。如果你需要中英文以外的語言、語音設計或風格可控的克隆，升級就是重點所在，而且家族內別無替代方案。如果你目前正在使用英文或中文克隆且滿意，這個理由本身就站不住腳：同一基準測試顯示 VoxCPM-0.5B 在錯誤率上與 VoxCPM2 相當，而你將付出兩倍的延遲和三分之一的額外 VRAM，來換取約 2.4 分的說話者相似度。還有一個容易忽略的遷移細節——如果你先前提供的是 VoxCPM1.5 的 44.1 kHz 參考音訊，VoxCPM2 的編碼器接受 16 kHz，所以你的參考管線會改變，而來源素材的高頻部分就不再重要了。

我實際上可以在這上面推出商業語音產品嗎？

法律上，這份授權的寬鬆程度可謂數一數二：Apache-2.0、無審核門檻、無使用限制、明確允許商業使用，權重與微調程式碼雙雙涵蓋。真正的問題不在授權文字，而在授權背後缺了什麼。OpenBMB 沒有指名訓練語料庫，意味著沒有人能告訴你，那 200 萬小時裡有誰的聲音。對一個招牌功能是重現特定人聲的模型而言，這個問題該去問你的法律顧問，而不是看模型卡——而這也是當前所有開放權重語音模型都在閃躲的問題。落到實務上，更棘手的阻礙在營運端：還沒有原生的 Transformers 類別、沒有任何託管端點、控制特徵每次執行都會漂移，而且如果你想做任何對話式應用，連首段音訊延遲（TTFA）的數字都拿不到。

它夠好到能取代付費的TTS供應商嗎？

對於英語和中文的敘述、預錄內容，以及任何你能控制特定語音並能批次處理的工作：根據現有證據，是的，而且授權條款讓試用幾乎免費。對於即時對話代理：在承諾之前，請自行測量首次音訊時間，因為沒有人公佈過數據，RTF 也無法告訴你。對於阿拉伯語、印地語或任何長尾語言：供應商自己的兩次評估相差一個數量級，因此無論你看到哪個數字，都應將該模型視為未經驗證。而對於任何發音錯誤會構成業務事故而非僅是困擾的情況，請注意，VoxCPM2 即使在其自己的表格中也不是清晰度領先者——Fish Audio S2 和 LongCat-Audio-DiT 在那方面領先，而且它們也是開放權重。

看什麼

兩件事，發生在不同的時間軸。近的是 PR #47756，以及它下方的 MiniCPM4 PR。如果它們合併，VoxCPM2 就變成一次 AutoModel 呼叫，所有標準化使用 Transformers 的人整合成本會在一夜之間幾乎歸零——考量到每月 900,282 次下載已經是繞遠路才達成的，這是一個有意義的突破。如果它們停滯不前，那些團隊的答案仍然是「使用 OpenBMB 的套件或 vLLM-Omni 端點」，而同時承擔這兩個 PR 的社群貢獻者也無力改變現狀。

比較慢的那個問題是：OpenBMB 以外是否有人會公布任何數據。發布四個月後，已有每月 90 萬次下載、25 個微調模型，以及超過 100 個以它建立的 Spaces，但流通中的每一項效能數字，依然追根究底都來自同一份由訓練該模型的人所寫的技術報告。這不是對 OpenBMB 的批評——他們的文件記錄比多數人更徹底、更誠實；那份報告主動揭露了其辨識器的選擇、資料量不足的弱點，以及自身的穩定性問題。這是對我們其他人的批評。開源語音社群中，任何人這個月能發表的最有價值的一件事，就是在相同條件下，用 Whisper 評分的 Seed-TTS-Eval 與 MiniMax-MLS 基準，跑一輪 VoxCPM2、Qwen3-TTS、Fish Audio S2 和 LongCat-Audio-DiT。在有人做到這點之前，對 VoxCPM2 的公道總結是：它是目前為止任何人所發布、每個檢查點能力最強的開放權重語音模型；它不是最準確的那一個；而這句話的兩半，都建立在廠商自己的說法之上。