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，是一个基于 MiniCPM-4 主干的 20 亿参数无分词器模型，采用 Apache 2.0 许可证，bfloat16 精度下约 8 GB，于 2026 年 4 月发布。两者都没有榜单条目，也都没有托管价格。当两个模型都可下载且都未评分时，比较就不再关乎偏好，而变成算术问题：每 GPU 小时能生成多少小时音频、每个进程的内存占用，以及能否在不自己编写训练代码的情况下微调它。此类发布背后有据可查的 AI 故障与智能体事件，均收录于 OrcaRouter AI Incident Archive，其中每条条目都附带自己的来源、严重程度、置信等级和争议标记。

发布历程值得直白说明，因为它们解释了成熟度差距。VoxCPM2 自 4 月起公开，过去一个月累计约 84.7 万次下载，并且在提供推理能力的同时附带训练脚本。Ming-3.0-tts-tiny 的代码仓库创建于 2026 年 9 月 22 日，权重文件于 9 月 24 日上线，而运行这些权重的代码直到 10 月 19 日 08:58 UTC 才公开出现，当时一个下午内出现了九次提交。Ant 尚未宣布该模型。没有技术报告；路线图将其列为未勾选的方框，而模型卡在 10 月 16 日被专门编辑，以删除对技术报告的一处引用。所以，这两者中，一个是已有五个月历史、拥有用户基础的项目，另一个则是截至本文撰写时仅有一周之久的流水线。

它们中排名第一的那个会发布，另一个则不会。

VoxCPM2 的模型卡给出的实时因子约为 0.30，这是在 RTX 4090 上使用标准 PyTorch 测得的；在 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 激活的参数约为其 2.5 倍，磁盘占用约为其六倍。稀疏路由挽回了一部分因更大总量而产生的成本，这正是该架构的全部意义所在，但 Ant 之外还没有人量化过它能挽回多少。

进行一项有漏洞的成本计算

因为一方公布了自己的速度，而另一方没有，所以这个比较的可靠版本是一个范围，而不是一个具体数字。大致情况如下。

• 在 RTX 4090 上运行 VoxCPM2，使用 PyTorch——RTF 为 0.30，因此每 GPU 小时可生成 3.3 小时音频。一百万个字符的旁白，按大约每秒 15 个字符的语速计算，约合 18.5 小时的成品音频，也就是大约 5.6 GPU 小时。

• 在同一张显卡上，VoxCPM2 搭配 Nano-VLLM——0.13 RTF，即每 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 并未公布同等的限制；其长篇内容的处理路径是播客任务，该任务接收的是脚本，而非单条话语。

那个在缺失数字后仍成立的结论，关乎利用率而非速度。一块闲置的卡，无论价格如何，都会输给每一个托管 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 列出了一个Ming-3.0-tts 条目，其在 Provider Voice 上为 1,188 Elo，在 Controlled Voice 上为 1,069。那是 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 显存很重要时，或者当基于你自己的五分钟音频训练 LoRA 已列入路线图时，就选择 VoxCPM2。无分词器设计，以及通过 AudioVAE V2 内置超分辨率实现的 48 kHz 输出，都是实实在在的工程优势；而五个月的公开使用意味着，这些故障模式是由陌生人而非厂商记录下来的。

当你需要只有 Ming-3.0-tts-tiny 才能提供的能力时，就选择它：单次处理即可完成多说话人播客任务；14 个内联副语言标签，支持显式情绪、语速、音高和音量控制；100 多种中文音色，外加五种英文音色；以及一个中文优先的模型，其方言处理能力是专门构建的，而不是推断出来的。作为交换，你需要接受：你将是第一个对它进行基准测试的团队；韩语是已公布的弱项；微调没有文档；整个版本发布才刚满一周。

OrcaRouter 并不路由这两个模型中的任何一个，本文也不应被理解为暗示相反的情况——这两者都需要你自己下载并运行才能使用。目录中提供的是同一流程中的文本部分：一个密钥即可调用 200 多个模型，按供应商标价计费、不额外加价，因此供应商调价当天就能反映到你这里，并且对于负责编写脚本或驱动智能体的模型，支持跨供应商自动故障转移。由于两种语音方案均为自托管，且都不按字符计费，你真正能逐月比较的经常性成本是文本层，而这一层值得放在单一端点之后。

比较的终点又回到了起点：两个检查点，没有共同的记分牌，最终决定取决于你是在中等硬件上需要速度和微调，还是在大硬件上需要中文优先的控制。VoxCPM2 用已公布的数据回答了前者。Ming-3.0-tts-tiny 用一份任务手册和缺失的吞吐量数字回答了后者，而后者正是 Ant 接下来最该公布的东西。