VoxCPM2：每月90万次下载，而Transformers却仍然无法加载它

Hugging Face 为 VoxCPM2 列出的元数据将库标为voxcpm，而非transformers。这一字段恰能解释当前开源语音领域一个奇怪的缺口：OpenBMB 的 20 亿参数文本转语音模型在过去三十天内获得了 900,282 次下载，催生了 25 个公开微调、10 个量化版本、7 个适配器和 100 多个 Spaces，却仍然无法被该网站上几乎所有其他模型都在使用的那个库加载。修复该问题的拉取请求于 2026 年 8 月 4 日发起，至今仍未合并。

在修复落地之前，这个差距值得理解，因为它决定了你本周与下季度集成该模型的成本差异。而在这个差距之下，还有一个更有趣的问题：VoxCPM2 是否真的像报道所暗示的那样遥遥领先？以下所有内容均来自三个主要来源：openbmb/VoxCPM2 的模型卡与仓库元数据、OpenBMB/VoxCPM GitHub README，以及 VoxCPM2 技术报告（arXiv:2606.06928，2026年6月5日提交）。本文中的每个基准数字都是 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 分钟的音频。

• 每秒语音的成本 — 纯 PyTorch 下的实时因子为 0.30，通过 Nano-vLLM 在单块 RTX 4090 上为 0.13，显存占用约 8 GB。VoxCPM1.5 在 0.8B 参数和 6 GB 显存下达到了 0.15。

• 许可证 — Apache-2.0 适用于权重、微调代码及推理工具。无门槛，无附加使用限制条款，允许商业使用。

• 训练数据——"超过200万小时"的多语言语音，未指明语料库名称，也未提供来源说明。

RTF 那一行要读两遍，因为它的方向是反的。VoxCPM2 每生成一秒音频的耗时大约是它所取代的 0.8B 模型的两倍，并且需要多三分之一的显存。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 日。它带有“新模型”标签，并增加了模块化配置和建模实现、自定义分词器和处理器、支持流式的 AudioVAE 编码与解码、参考语音条件化、提示音频延续、自动类注册，以及文本到波形流水线入口——据报道有 64 项模型测试通过。它基于 PR #47736，后者添加了 MiniCPM4 本身；文本主干必须先落地，包装它的语音模型才能随之落地。

有两个细节值得重视，而两者都不利于乐观情绪。首先，这三项内容——issue 和两个 pull request——都是由同一位社区贡献者提出的，并非 OpenBMB，也非 Hugging Face 的维护者。这背后没有厂商的承诺，因此也没有可据以规划的时间表。其次，一个包含两个 PR、涉及 203 次提交、触及新模态的改动，不可能很快完成审查。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系列那样经过学习的语音令牌词汇表。这就是其核心主张，而且确实如此。

模型内部仍然存在量化。骨干网络运行一个基于有限标量量化（Finite Scalar Quantization）的可微半离散瓶颈，论文明确阐述了其作用：文本语义语言模型产生隐藏状态，FSQ 逐维度对它们进行标量量化，形成“语义骨架”；残差声学语言模型恢复 FSQ 丢弃的精细细节；局部扩散 Transformer 通过流匹配将两条条件流转化为下一个连续潜变量块。你看到的缩写为 LocEnc、TSLM、RALM 和 LocDiT 的四个阶段正是这条链路。

实践中真正重要的区别不在于“是否量化”，而在于瓶颈层是与其周围的所有组件一同进行端到端训练，而不是预先作为一个带有自身损失函数的独立编解码器被冻结固定。正是这一点消除了常见的失败模式——语言模型学会预测编解码器无法忠实解码的词元。VoxCPM2 将 FSQ 瓶颈从 256 维扩展到 512 维，并用可学习的拼接-投影取代了原先馈入残差模型的逐元素求和——这些都是小改动，也是该报告中少数几个由明确机制支撑、而非仅靠基准测试分数差异支撑的改动之一。

48 kHz 输出部分是虚构的，而这正是设计使然。

“48 kHz 录音室级输出”是这款模型最常被引用的规格，也是最容易被误解的一点。AudioVAE V2 是非对称的：编码器以 16 kHz 运行，解码器以 48 kHz 重建。论文将这一过程称为“隐式超分辨率”，这个称呼恰如其分。

由此推论。16 kHz 编码器的奈奎斯特上限为 8 kHz，因此参考音频中任何高于 8 kHz 的内容都永远不会到达模型。输出中最高的两个八度里的每一丝能量——嗓音中的气息、齿音、镲片边缘的亮度——都是由解码器从合理的先验中生成的，而不是从你克隆的说话人那里保留下来的。对于大多数旁白和智能体工作而言，这要么不可见，要么反而是一种改进，因为良好的学习先验胜过硬性的 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的记分板

有竞争力，而非第一

{{1}}在标准零样本语音克隆基准 Seed-TTS-Eval 上，VoxCPM2 在英语测试集上报告了 1.84% 的词错误率和 75.3% 的说话人相似度，在中文测试集上报告了 0.97% 的字符错误率和 79.5% 的相似度，在中文困难子集上报告了 8.13% 的字符错误率和 75.3% 的相似度。{{/1}}{{2}}论文自己的措辞是"有竞争力的"，而表格数据支持这一措辞，而非流传的那些更强烈的说法。{{/2}}

在同一张表格的开源系统中，Fish Audio S2 在全部三个子集上取得了更低的错误率（0.99 / 0.54 / 5.99）。Qwen3-TTS 在英语 WER 上以 1.23 超越它。LongCat-Audio-DiT 则在六个单元格中直接横扫五项——英语上 WER 1.50、相似度 78.6，中文上相似度 81.8，困难中文上 CER 6.04、相似度 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种语言、根据文本描述设计声音、风格可控的克隆、48kHz输出。这确实很多，也是升级最实在的理由。但如果你的任务是英文或中文克隆，并且你是按错误率来选择，那么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%的词错误率，是在批评一种它从未声称支持的语言。粤语看似可以归入“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 并未为其各项能力配备单独的模型或头部。五种模式共享同一套参数，仅以不同的输入序列排列方式实现区分，正因如此，单个 2B 检查点就能覆盖通常需要一小批模型才能完成的任务。

• 基础 TTS — 文本输入，音频输出。

• 语音设计 — 括号描述只是简单地前置到文本中，因此"(一个疲惫的中年男子，声音沙哑，语速缓慢)"和台词本身经过同一个语言模型，无需额外模块。完全没有参考音频。

• 参考克隆 — 通过独立的参考音频片段即可确定说话人身份，无需提供转录文本。

• 可控克隆 — 参考片段加上风格描述，因此你可以克隆一个声音，然后让它听起来急促或愉悦。

• 延续克隆——参考片段与其转录文本配对，作为模型继续生成的音频前缀，这是最高保真度的模式。

报告中埋藏着一个大多数评测都会略过的参数，而它恰恰是最可能改变你结果的那一个。两种条件化路径——隔离参考（isolated reference）与延续前缀（continuation prefix）——可以单独使用，也可以组合使用，二者相互权衡。在OpenBMB自己的消融实验中，两者结合使用在每个子集上都取得了最佳的说话人相似度。去掉延续前缀、只传入隔离参考，则在困难中文文本上取得了最佳可懂度，CER为6.85%，对比7.44%，但相似度损失了约5个百分点。论文的解释是合理的：没有时间上的音频前缀来锚定韵律时，模型拥有更多自由，可以选择一种能够驾驭困难文本的发音方式。

所以默认设置是一种选择，而非上限。语音匹配工作需要两条通路；困难或罕见的文本只需参考模式。一个坦诚的疑点：该消融表中的绝对数字与论文声称全程使用的配方所对应的主表数字无法吻合——在预印本中，这更可能是记账疏漏而非什么恶意——但这已是第三个理由，让我们把这里的每个数字都视为有待测试的方向，而非可引用的数值。

语音设计：与其说是自然，不如说是听话

语音设计是让此次发布显得有趣而非仅仅增量式的特性，而厂商自己的数据也正是在这一点上最能揭示出真正的权衡取舍。

在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），在自然度上与 Qwen3-TTS 打平或略逊（4.78对4.80，置信区间重叠）。

这种模式已经足够一致，可以据此规划：VoxCPM2 会执行你的指令，但听起来稍微不那么像真人；而 Qwen3-TTS 听感稍好，但对指令的遵循程度略低。选哪个完全取决于你产品的价值所在——是精准控制，还是自然流畅的输出。OpenBMB 在自身局限性说明中指出了这一推论，而这正是供应商通常不会提及的那类问题：语音设计和可控克隆"在不同运行之间可能产生可变结果"，想要获得理想的声音可能需要多次尝试。在流水线中加入重试机制，如果声音至关重要，再加一道人工监听把关。

运行成本是多少，以及何时应选择租用

任何地方都没有托管的 VoxCPM2。Hugging Face 自己的侧边栏明确写着——“此模型未由任何推理提供商部署”——这也包括我们：OrcaRouter 不提供 VoxCPM2，再多的期望也改变不了这一事实：一个没有推理合作伙伴的 2B TTS 模型，要么是你自己托管的权重，要么什么都没有。

这使得成本问题变成了一个GPU问题，而且计算很简单。在单张RTX 4090上，Nano-vLLM的实时因子（RTF）为0.13时，一个GPU小时大约能产生7.7小时的音频，因此你每音频小时的成本就是一张24GB显卡的每小时费用除以约7.7。在纯PyTorch环境中，RTF为0.30时，这个数字会降到每个GPU小时约3.3小时音频。这两个数字都来自OpenBMB，是在他们的硬件上、用他们的文本测得的；而在你的环境中，这两个数字都会变化——批次大小、文本难度，以及你的质量门控强制要求的重试次数，都是RTF数字本身不包含的乘数。人们最容易忽略的是重试率：如果供应商告诉你，某个模型可能需要多次尝试才能达到目标音色，那么它的实际成本就不会是RTF所暗示的那样。

此时人们想要的对比是与租用 API 进行比较，而诚实的答案是二者无法简单换算。openai/tts-1-hd按每百万 token 进出各 30.00 美元计费——这是提供商在 OrcaRouter 上的标价原样透传，因为我们不赚取任何加价，所以模型页面上的数字就是 OpenAI 收取的金额。但 token 不是秒数，也没有任何已公布的费率能在两者之间可靠换算，足以让你据此编制表格。任何向你展示自托管开放权重 TTS 模型与按 token 计费 API 之间清晰小时费用对比的人，都做出了一个他们没有向你展示的假设。

值得说明的是，这条界线在架构上落在何处。当你需要某个特定的克隆声音、音频量足够稳定以使 GPU 保持忙碌、数据不能离开你的基础设施，或者你打算对模型进行 LoRA 微调时，自托管 VoxCPM2 是合理的——而且它仅需 5 到 10 分钟的目标音频就能支持微调，这确实非常划算。当用量呈尖峰状、你无法安排专人维护 GPU，或者声音可以互换时，租用则更合理。大多数真实的语音产品其实是两套系统，而非一套：一个合成层，加上一个在“两耳之间”负责推理的语言模型。推理这一半值得放在一个统一的密钥后面，并在各服务商之间自动故障转移，这样更换模型只是改一个字符串，而不是走一遍采购流程；这正是 OrcaRouter 的用途所在，它覆盖 200 多个模型。而合成这一半——当它是一个你拥有并微调的特定声音时——应当放在你自己的硬件上。VoxCPM2 恰好处在第二类中；没有人以托管服务的形式提供它，这并非疏忽，而是由其本质所决定的。

OpenBMB 告诉你不该期待的事

对于如此势头强劲的发布版本而言，局限性部分出奇地坦诚，而且简短到足以让人认真对待：

• 克隆质量是一个滥用面。模型卡直接说明了这一点：该模型生成的语音逼真到足以用于冒充他人和欺诈，AI 生成的音频应当被标注。Apache-2.0 对此没有任何限制——与几款竞品的开放权重语音模型许可证不同，没有可用来规避责任的可接受使用条款。同意与披露政策需要你自己来制定。

• 批次间差异属于预期，在这两个控制特征上并非需要提交的缺陷。

• 这30种语言是真正的边界。超出这些语言范围的内容可能可以运行，但未经测试；预期需要进行微调。

• 样式控制的一致性仍在开发中，据其构建者所述。

而该卡片没有指出的空白：完全没有训练语料库的披露，因此 Apache-2.0 许可证只解决了代码问题，对数据来源则只字未提。本文中的任何数字都未经独立评估。没有以毫秒为单位的延迟数据——RTF 是吞吐量比率，而语音代理的生死取决于首次音频时间，这一点在报告中无处可寻。

模型卡没有解决的三个问题

我是否应该不再使用VoxCPM1.5或VoxCPM-0.5B？

仅针对新能力，且仅在测量之后。如果你需要中英文以外的语言、语音设计或风格可控的克隆，升级正是关键所在，且该产品系列内没有其他选择。如果你目前正在运行英文或中文克隆且感到满意，那么升级的理由表面上就很薄弱：同一基准测试显示，VoxCPM-0.5B在错误率上与VoxCPM2相当，而你却要为了大约2.4个百分点的说话人相似度付出两倍的延迟和多三分之一的显存。还有一个容易被忽略的迁移细节——如果你之前向VoxCPM1.5输入44.1 kHz的参考音频，VoxCPM2的编码器接收的是16 kHz，因此你的参考流程会改变，源素材的高频部分也不再重要。

我真的能在这上面发布商业语音产品吗？

在法律层面，该许可证的宽松程度几乎无以复加：Apache-2.0，无门槛，无使用限制，明确允许商用，权重和微调代码均涵盖在内。真正的问题不在许可证文本，而在于其背后缺失的东西。OpenBMB 没有列出训练语料库，这意味着没有人能告诉你那两百万小时里都有谁的声音。对于一个主打功能是复刻特定人声的模型来说，这个问题该去问你的法律顾问，而不是看模型卡——而这也是目前所有开放权重语音模型都在回避的同一个问题。实际上，更难的阻碍在于操作层面：尚无原生的 Transformers 类，任何地方都没有托管端点，控制特征存在逐次运行差异，而且如果你在构建任何对话式应用，也没有 time-to-first-audio（首次音频输出时间）的数据。

是否足以取代付费的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评分对VoxCPM2、Qwen3-TTS、Fish Audio S2和LongCat-Audio-DiT进行Seed-TTS-Eval和MiniMax-MLS测试的结果。在那之前，对VoxCPM2的公道总结是：它是迄今为止发布的每检查点能力最强的开源权重语音模型，但它不是最准确的，而且这句话的两部分都建立在供应商的一面之词上。