Ming-3.0-tts-tiny 对决 Breeze-TTS-2：MIT 权重对抗非商业许可

两个开放权重语音模型在一个月内相继发布，但它们并不在同一维度上竞争。Ming-3.0-tts-tiny来自蚂蚁集团旗下 inclusionAI，是一个 7.9B 的混合专家检查点，每个 token 激活约 1.3B 参数，以 MIT 许可发布，覆盖九种语言，其中包括两种汉语方言。Breeze-TTS-2来自 BreezeBlue，是一个稠密 3B 模型，仅覆盖英语和中文，其代码以 Apache 2.0 发布，权重则以研究和非商业许可发布，并附带付费托管例外。最受关注的问题——哪个听起来更好——结果却是最不具决定性的，因为竞技场中看起来像 Ming 得分的条目完全属于另一个检查点，而许可差异才是决定你究竟能否发布的那个因素。此类发布背后有记录的 AI 故障和智能体事件，均收录于the OrcaRouter AI Incident Archive，其中每个条目都附有自己的来源、严重程度、置信度等级和争议标记。

两家厂商都没有以通常意义宣布正式全面可用（GA）事件，而这两个事实在这里都很重要。Breeze-TTS-2 的权重于 2026 年 8 月 25 日上线，语音设计和延迟测试套件则随后于 8 月 7 日跟进。Ming-3.0-tts-tiny 自 9 月 24 日起就存在于 Hugging Face 上，但直到 10 月 19 日其推理代码和任务 cookbook 登陆 GitHub 后才变得可运行。因此，这是对两个你必须自行托管的产物的比较，撰写时两者都还没有可引用的托管价格，并且全文都据此标注。

从许可证开始，因为对某些团队来说，它能终结争论

这两种许可证并非同一许可的不同变体。它们属于不同类别的许可。

• Ming-3.0-tts-tiny —— MIT 许可，权重和代码皆然。你可以将其用于商业用途、修改它、再分发它，并把它打包进闭源产品中。Ant 附带了一条使用说明，请求你不要在未经同意的情况下冒充他人，并请标注合成音频；这只是文档中的一项请求，并非授权条件。

• Breeze-TTS-2 — 源代码采用 Apache 2.0，权重则采用单独的“BreezeBlue Research and Non-Commercial License”。对托管输出进行商业使用需要付费的 BreezeBlue 订阅，而且即便如此，该订阅也不会将商业权利扩展到开放权重，也不会扩展到你通过自行托管这些权重所生成的输出。

仔细读第二条要点，因为最直观的理解恰恰是错的。向 BreezeBlue 付费并不会把权重变成你可以商业运行的东西；它授予的是托管服务的许可。无论你是否订阅，自托管都属于非商业用途。如果你的计划是"微调 3B 模型，把它挂在我们自己的端点后面，然后对外收费"，那么这份许可关上了这扇门，而 MIT 则把它敞开。对于内部研究、评估，或永远不会收费的原型，这一区别不产生任何成本。

还有第二个与许可证密切相关的差异，它比上面两段中的任何一段都更能左右部署选择。Ming 的发布将整套流程——主干、扩散头、音频分词器、说话人编码器和文本分词器——作为一组权重一起交付。Breeze 则同时提供代码和权重，并附带一条已同时打包适配多个运行时的推理路径：Breeze-TTS-2 周边的衍生生态包括 4 位和 8 位 MLX 构建以及一个全精度移植版、GGUF 量化、int8 和 int4 转换、一个 HQQ int4 构建、10 月 18 日的 ROCm/RDNA4 BF16 构建、10 月 19 日的 GPTQ int4 ROCm 构建、ComfyUI 微调模型，以及 10 月 6 日发布的巴西葡萄牙语 LoRA。Ming-3.0-tts-tiny 这些都没有，因为它拥有可用推理路径还不到一天。

两者在占用空间上的差距大约为一个数量级。

在这里，“tiny”不再意味着“小”。这个名字描述的是每个 token 的活跃参数，而不是你所需的内存。

• Ming-3.0-tts-tiny —— 根据 Hugging Face 自身元数据，BF16 下为 8,980,964,372 个参数，另有 F32 下 40,096 个参数，约 18 GB 仓库存储，且厂商环境说明中推荐使用 H800。你付出的是 7.9B 模型的内存代价，得到的却是 1.3B 模型的延迟；对于在租用硬件上进行批量合成来说，这是划算的取舍，而对于任何搭载 12 GB 显卡的场景来说，则很不划算。

• Breeze-TTS-2 — 3B 参数稠密模型，eager 模式下占用约 7.7 GiB GPU 显存，启用 --fast-all 时约 14.4 GiB。BreezeBlue 建议根据所选路径使用 12 GB 或 24 GB 显存，并说明其 Docker 默认面向 H100/Hopper sm90，而 A100 用户需设置 FLASH_ATTN_CUDA_ARCHS=80。

• Ming 的并发模型——每个任务一个 Python 入口点，并采用固定默认值：引导尺度 2.0、温度为零、十个流步骤、sigma 0.25、种子 1234。vLLM-Omni 支持已列入路线图但尚未勾选，因此目前还没有高吞吐量服务路径。

• Breeze 的并发模型——一个单并发 HTTP 流式 API，返回单声道 24 kHz 有符号 16 位小端 PCM，并声称在预热的 H100 上首音频时间低于 40 毫秒，实时因子为 0.32，约比实时快 3.1 倍。

最后那组对比才是对这项权衡的诚实总结。Breeze 是针对单次请求下的流式延迟进行设计的；Ming 则是针对稀疏激活下单位算力的吞吐量进行设计的，并且尚未发布服务栈。如果你的产品是实时语音智能体，这两者并不是等价的起点。如果你的产品是夜间批量生成旁白，并发模型的重要性就远低于许可证和内存开销。

语言覆盖范围相差甚远，而且差距是单向的。

Breeze-TTS-2 支持英语和中文。其卡片上毫不含糊地写明了这一点，并且还记录了两种语言的内联发声事件——英语中的 (laugh) 和 (sigh)，中文中的 [笑] 和 [叹气]——以及从带有精确转写文本的参考片段进行克隆，并提供语音风格控制。

Ming-3.0-tts-tiny 涵盖中文、英语、德语、西班牙语、法语、韩语和日语，并且在提供方言参考音频片段时还支持四川话和粤语。它新增了自由形式的风格控制、根据自然语言描述进行音色设计、100 多种内置中文音色和五种英文音色，以及 14 个内联副语言标签。它还支持多说话人播客生成，而 Breeze 并未尝试此功能。

问题就出在 Ant 自家的多语言表里，在假定九胜于二之前，这是首先要看的。在韩语上，Ming-3.0-tts-tiny 录得 6.000% 的字符错误率，在 Ant 基准测试的八个系统中排名第六，而 Ant 自家的 0.5B 同门模型为 1.728%。在法语上，它的错误率排名第二，但其 0.733 的说话人相似度未能进入前三，这是卡片自身指出的局限。德语（0.325%）和西班牙语（0.971%）在该表中位列第一。所以诚实的解读是：Ming 的七种语言中有五种可信，韩语尚不可信，而方言支持独一无二，但在 Ant 的测试框架之外未经验证。相比之下，Breeze 不会声称覆盖它并未覆盖的内容——只有两种语言，而且其卡片中的每一项结果都关乎这两种语言。

竞技场数据，以及为什么它们不是正面交锋

Breeze-TTS-2 有独立评分。Ming-3.0-tts-tiny 没有，那个看起来像评分的条目属于另一个模型。

• Breeze-TTS-2 在 Artificial Analysis 上，数据取自 2026 年 10 月 19 日的实时榜单——在 Provider Voice 上为 1,220 Elo，该榜单中每个模型使用其自带的原生音色阵容；在 Controlled Voice 上为 1,019 Elo，该榜单中每个模型克隆相同的八个参考语音。

• 同一榜单上的 Ming 行——1,188 Provider 和 1,069 Controlled——对应的是 Ming-3.0-tts-0.5B，即拥有五亿参数稠密骨干的兄弟模型，而不是那个微型检查点。Ant 的 GitHub README 在结果部分复述了这些数字，却没有作出这一区分。值得明确指出：Ming-3.0-tts-tiny 没有独立的 Elo，没有实测的每秒字符数，也没有第三方词错误率。

• 项目页面自带的排行榜把 Breeze 列为 1,222 Provider 和 1,018 Controlled，与实时榜单相比，两个数字各相差两点，且方向相反。这正是榜单仍在累积投票时会呈现的样子；如果你要对比文档，请引用实时数据，并注明取整情况。

• 在受控榜单上，开放权重系统的排名顺序为 Ming-3.0-tts-0.5B（1,069）、Fish Audio Drama 3 Preview（1,059）、Breeze-TTS-2（1,019）。在提供商榜单上，Breeze 以 1,220 领跑该组，Ming-3.0-tts-0.5B 为 1,188。因此，当语音保持不变时，小型 Ming 模型胜出；而当每个系统自带自己的配音阵容时，它则落败——这说明了一些关于 BreezeBlue 语音录音的情况，却几乎说明不了架构方面的问题。

上述任何内容都无法以任何方向迁移到那个微型检查点。读者可能会合理地推断：一个中文说话人相似度分数高于其 0.5B 同类模型的 7.9B 专家混合模型，会在受控排行榜上得分更高。这一推断尚未经过检验，它不是一个数字，本文也不会把它当作数字来呈现。

每个到底是做什么用的

抛开规格参数清单不谈，这两款型号解决的是不同的问题。

Breeze-TTS-2 是一个以部署为先的版本。它支持两种语言，拥有紧凑的 3B 参数规模，可在 eager 模式下装入 12 GB 显卡；提供流式 API，并附带成文的延迟路径说明；提供一个面向数据中心 Hopper 的容器，也可重新构建以适配 A100；还拥有一个生态，包括量化版本和特定运行时的移植版本，这些均在权重发布后的八周内出现。其下载量——上个月 14,636 次，获得 747 个点赞和 17 个 Spaces——正是一个模型易于运行时被采用的样子。它的限制在于许可证：权重仅限研究和非商业用途，付费托管路径并不会为你买来自行商业部署的权利。

Ming-3.0-tts-tiny 是一个能力优先的版本。九种语言、方言控制、音色设计、14 标签副语言系统、多说话人播客生成，以及同系列中最佳克隆语音得分——中文说话人相似度 0.781。它的制约在于能力之外的一切：18 GB 的下载包、需要真实 GPU 显存的稀疏激活、只是路线图上一个勾选项的服务方案、没有独立基准测试，也没有发布公告。Hugging Face 上二十次下载和三个赞、GitHub 上五颗星，以及一个下午十二次文档提交，说明厂商还在写说明书。

如果你需要在本季度、用已有硬件交付一个双语语音功能，那么采用商业授权安排的 Breeze-TTS-2 是更短的路径，需要谈判的是许可证，而不是数学计算。如果你需要德语、西班牙语、日语、粤语或播客格式，Breeze 帮不了你，而 Ming 是唯一有公开表格的开放权重选项——前提是你能承受内存开销，并接受韩语尚未就绪。

OrcaRouter 并不路由这两个模型中的任何一个，本文也不应被理解为暗示相反的情况。目录中列出的是这些语音所接入流水线的文本部分：一个密钥背后有 200 多个模型，按提供商标价且不加价，因此供应商价格变动当天就会在我们这边生效，而不是等到刷新周期。当你比较两个自托管检查点且两者都没有托管价格时，你唯一真正能控制的经常性账单就是编写脚本的模型，而这正是值得路由而不是为此租用 GPU 的部分。

经得起证据检验的结论，比 Elo 差距所暗示的更有限。在同等条件的商业部署中，还没读任何一项基准测试，MIT 许可证就已经决定了胜负。在对延迟敏感的双语任务中，还没轮到许可证，Breeze 的工程实现就已经决定了胜负。而对于大多数读者真正关心的问题——更大的模型听起来是否更好——诚实的答案是：没有人测量过；所有人都会引用的那行竞技场榜单对应的是错误的检查点；第一个在同一段参考音频上运行两个模型的人，将得出唯一值得引用的数字。