Ming-3.0-tts 对比 Ming-3.0-tts-tiny：较小的检查点更值得下载，而较大的那个是目前唯一有人实际测量过的

Ant Group 以同一个名称发布了两款语音模型，而命名正是最先误导你的地方。Ming-3.0-tts-the-default 是 0.5B 稠密模型：磁盘占用 2.96 GB，基于 Qwen2.5-0.5B 骨干，速度快、成本低，也是这对模型中唯一有独立评分的。Ming-3.0-tts-tiny 则是两者中规模大一个数量级的那款——一个 7.9B 参数的专家混合模型，每 token 激活 1.3B 参数，基于 Ling V3 骨干，分片权重共 18 GB——它之所以叫 tiny，是因为运行成本，而不是下载成本。按标签来选，你就会拿错文件。像这次发布背后的、已被记录的 AI 故障和智能体事故，都收集在 the OrcaRouter AI Incident Archive中，其中每条记录都带有自己的来源、严重程度、置信度评级和争议标记。

第二件会误导你的事是排行榜。Artificial Analysis 有一行 Ming-3.0-tts，Provider Voice Elo 为 1,188，发音鲁棒性为 93.2%，而这一行链接到 0.5B 检查点。这些都不属于 tiny。tiny 的数据来自 Ant 自己的表格，发布在模型卡和 GitHub README 中，且没有任何第三方复现过其中任何一个。因此，诚实的比较有两半：一个模型有独立证据但没有播客模式，另一个模型有厂商证据且具备前者所缺的一项能力。你需要哪一半，是关于你的工作负载的问题，而不是关于哪个模型更好的问题。

同一架构家族，两种截然不同的机器

两个模型共用 Ant 在 README 中描述的生成框架：文本和任务特定的控制 token 作为条件输入到一个语言模型，再由该语言模型驱动扩散 Transformer patch 头输出音频 token。区别在于底层的语言模型。0.5B 使用密集的 Qwen2.5-0.5B；tiny 使用稀疏的 Ling V3 混合专家模型，总参数量为 7.9B，每个 token 大约激活 1.3B。

• 下载大小 — Ming-3.0-tts 为 2.96 GB，而 Ming-3.0-tts-tiny 在 30 个分片中共约 18 GB

• 参数 — 0.5B 稠密模型 对比 7.9B 总参数 / 1.3B 激活参数 MoE

• 骨干 — Qwen2.5-0.5B 对比 Ling V3

• 运行时 — 在 Python 3.8 时代的技术栈上使用 PyTorch 2.6 + CUDA 12.4，对比 Python 3.10.15 + PyTorch/torchaudio 2.7.1+cu118

• 硬件 — 已在 H800-80GB 和 H20-96G 上测试，推荐使用 H800；SGLang-Omni 可在单块 GPU 上提供服务

• 多说话人播客生成 — 不支持 vs 支持

• 许可证 — MIT 对比 MIT

• 独立竞技场评分——是，1,188 Provider / 1,068 Controlled / 93.2% 发音，对比无

这两个检查点不共享同一个 Python 环境。这不是文档中的小怪癖；它意味着，想在同一个机器上评估两者的团队要维护两个 virtualenv，而想在生产中对它们做 A/B 测试的团队要维护两个部署镜像。如果你的计划是“先用小的，之后再升级”，那就得把迁移当作一项真正的工作来预留预算，而不是一次配置更改。

在蚂蚁自己的数据上，小模型确实更胜一筹之处

说话人相似度是最清晰、最一致的胜出项，也正是决定克隆语音听起来是否像本人的那个数字。

• Seed-TTS 中文说话人相似度 — Ming-3.0-tts 0.758 对比 tiny 0.781

• Seed-TTS 英语说话人相似度 — 0.691 对比 0.728

• 德语相似度 — 0.753 对比 0.791

• 西班牙语相似度 — 0.763 对 0.797

• 法语相似度 — 0.675 对比 0.733

• 日语相似度 — 0.765 对比 0.780

• 韩语相似度 — 0.793 对 0.797

Tiny 在相似度上于每种语言都胜出，通常领先三到六个百分点，这一规律在对照基准上也同样成立：在 CV3 情感测试中平均为 74.00%，而对比结果为 72.33%；在音色设计准确率上为 75.37%，而对比结果为 72.29%。这两点正是客户无需被告知就能注意到的——听起来像不像我，以及它是否做到了我所描述的效果。在这两项上，7.9B MoE 都领先。

内容准确性则朝另一个方向分化，而且这种分化并不对称。

• Seed-TTS 中文词错率 —— 0.800% 对 0.820%。实际上基本持平；稠密模型略占上风。

• Seed-TTS 英语词错误率 — 1.584% 对比 1.666%。前方内容密集。

• 德语 — 0.365% 对 0.325%。略微领先。

• 西班牙语——1.099% 对 0.971%。略微领先。

• 法语 — 4.264% 对比 3.470%。Tiny 以大幅优势领先。

• 日语字符错误 — 3.765% 对 3.427%。略微领先。

• 韩文字符错误率——1.728% 对 6.000%。Dense 以 3.5 倍的幅度领先。

韩语就是那个异常值，足以让任何人不再把“tiny 在多语言上更强”当作板上钉钉的结论。Ant 自己的模型卡就指出了这一点：在 tiny 模型中，韩语的多语言准确率差距最大，而 6.000% 这一数字是五亿参数模型所达到水平的三倍多。为韩国市场构建产品的团队有明确答案，而且不是更大的模型。

并非基准测试的能力

Ming-3.0-tts-tiny 能根据带有说话人参考的脚本生成多说话人播客对话，而 Ming-3.0-tts 不能。这是产品能力，不是评分，也不会出现在任何排行榜上——正因如此，在对比那些都列有“声音克隆”和“声音设计”的规格表时，这一点很容易被忽略。

Ant 在其自有测试框架上进行的播客评估显示，tiny 的字符错误率为 2.03%，说话人相似度为 0.561，UTMOS 为 2.12；相比之下，ZipVoice-Dia 的 UTMOS 为 2.24，FireRedTTS2 的 CER 为 3.34%，MOSS-TTSD 为 8.62%。值得注意的正是 UTMOS 差距：tiny 在内容准确率上领先，但在自然度上落后于最佳对比对象，这与说话人相似度数字从另一个方向暗示的取舍相同。播客生成更看重轮流发言和说话人一致性，而不是单个完美片段，而这正是 tiny 优势的形态。

如果你需要两个人对话的场景，那这里就没什么可比的——一个模型能做到，另一个做不到。本文其余内容讨论的都是两者都能胜任的情况。

独立性差距究竟会让你付出什么代价

在你决定给予它多少权重之前，0.5B 模型在竞技场中的排名值得了解。它的 Provider Voice Elo 得分为 1,188，在 97 个中排名第 18；Controlled Voice 得分为 1,068，在开放权重模型中排名第一，总排名第 12。在发音方面，它达到 93.2%，实际与 Fish Audio Drama 3 Preview 持平，并领先于 Eleven v4。这些是独立测量，均公布了样本数量和置信区间。

这换来的是校准。你大致知道密集模型相对于 ElevenLabs 和 Cartesia 处在什么位置，因为同一个实验室在同一块榜上测了这三者。对于 tiny，你只知道 Ant 所说的内容，而且是在 Ant 的测试框架、用 Ant 的设置测得的，而 Ant 是结果中的利益相关方。这不是指控——这些表格异常坦率，包括那个韩语数字，以及一份将音高控制和角色扮演音色设计列为弱点的局限清单。这是关于一个数字能支撑什么的陈述。厂商表格告诉你，模型在厂商选择衡量的维度上具有竞争力；竞技场排名则告诉你，它相对于你已在使用的系统落在何处。

独立榜单还有一件具体的事没告诉你：它只测了一个音色。Artificial Analysis 指出，每个模型在该发音榜上都只用单一音色评估，而 Ming 那一行用的是 Ant 的端点，且有三种原生音色可用。93.2% 在产品实际会交付的克隆音色上是否依然成立仍未知，而这正是最值得你自己先测的一点。

实践中的选择

决策树很短。

Ming-3.0-tts (0.5B)如果你想要最小的可用下载包，如果你要为韩语部署，如果你的硬件是一张还要兼作他用的 80 GB 显卡，或者你需要一个行为已由作者以外的人测量过的模型，那就选它。在独立测试框架上，它以 2.96 GB 的体积和每秒 44.3 个字符的速度，成为一个堪用的叙述模型，能在一张 GPU 上跑赢实时语音。

选择 Ming-3.0-tts-tiny如果产品核心在于说话人相似度——克隆品牌声音、个性化朗读，或任何听众第一判断是“这听起来像不像他们”的场景——或者你需要播客对话，或者法语、德语、西班牙语或日语的准确度是硬性约束。需预留 18 GB 权重、单独的 Python 3.10 环境和一张 H800 级显卡。

两个都别选，不过如果你在将生产容量投入 tiny 之前需要一个独立数字。竞技场中的那一行并不存在，技术报告在路线图上仍未勾选，而 vLLM-Omni 加速在 README 中被标记为已完成，却没有公开的配方。这三个缺口，正是会让 tiny 容易被推荐的那三件事。

有一条运维层面的说明对两者都适用：这两个检查点都不支持流式输出。两个模型都没有公布首音频延迟数据，而 arena 的吞吐量数字指的是完整请求的生成速度。如果你的应用是对话式的，那么无论你选择哪个尺寸，这个系列都不是合适的工具。

路由问题，在这里有所不同

本网站上的大多数对比都以一段关于整合访问的内容收尾。这一篇不能这样，因为 OrcaRouter 并不托管两个 Ming checkpoint 中的任何一个——目录中没有任何 Ming 语音模型，而两者都需要通过克隆 Ant 的 GitHub 仓库并自行运行权重来获取。若说不是这样，那就是一个读者三十秒内就能核实的谎言。

真正成立的部分范围更窄，但仍然有用。语音流水线通常先处理文本：某部分负责写脚本，某部分负责翻译，某部分负责按内部风格规范检查。这个文本阶段可以置于一个密钥之后——以提供商标价提供 200 多个模型，且不额外加价，自动故障转移，在提供商服务降级时生效，以及一种路由 DSL，可根据请求内容将任务发送到不同模型。本次对比中的语音阶段无论如何都留在你的硬件上，而自托管路径正是让两个检查点之间的选择可逆的原因：MIT 权重不会过期，而且已经存在于磁盘上的模型，可以在你评估其替代品期间继续提供服务。

什么能了结它

三项进展，按它们对推荐结论的影响程度排序。在 arena 上增加一行小数据，就能看出相似度优势能否在盲听对比中依然成立，而这是唯一尚未进行的测试。技术报告则会解释为什么一个 1.3B-active 的 MoE 提升了说话人相似度却损失了韩语准确率，以及这是数据划分造成的，还是架构层面的后果。而一份已发布的 vLLM-Omni 方案，会让 18 GB 检查点在租用硬件上变得实用，而不只是研究部署。

在那之前，一个有用的理解框架是：Ant 为两项任务发布了两款模型，并给它们起了这样的名字，让较小的那项任务听起来像是较小的文件。但事实并非如此。0.5B 是你能在设计评审中衡量、部署并为之辩护的那一款；7.9B 则是在七种语言中的六种里，听起来更像你所克隆之人的那一款——前提是你有底气仅凭信任就接受它。