Ming-3.0-tts-0.5B 两次发布，Ant Group 却两次都未官宣

有三个日期与Ming-3.0-tts-0.5B相关联，每一个都标志着不同的事件。Hugging Face 仓库创建于 2026 年 9 月 22 日，权重则在两天后上传。GitHub 仓库直到 2026 年 10 月 19 日才出现，当时首个提交以“Ming-3.0-tts 的初始发布”为题到来。Artificial Analysis 在同一天开设了模型页面并给出了评分。无论是在哪个日期，我们都没有找到来自 inclusionAI 的博客文章、新闻稿或发布帖。撰写本文时，该检查点有六次下载和零个点赞；GitHub 仓库有两个星标。像此次发布这类发布背后有记录的 AI 故障与智能体事件，均收录在the OrcaRouter AI Incident Archive中，其中每条记录都带有各自的来源、严重程度、置信度等级和争议标记。

这对如何阅读本文余下部分很重要。蚂蚁集团的开放权重团队发布了一个完整的、采用 MIT 许可证的语音模型，具备 14 个标签的副语言系统、文本到音色设计、两种中文方言以及完整的基准测试结果表。但到目前为止，它也没有向任何人透露此事。下文将区分该仓库所能证明的内容与只有蚂蚁集团才能确认的内容。

这三个日期，以及每个日期实际涵盖的内容

这种困惑并非人为制造。Ant 自己的两个代码仓库在公开场合说法不一，而两者都没有错。

• 2026年9月22日 12:46 UTC — Hugging Face 仓库已创建，初始提交仅包含一个占位 README，尚无权重。

• 2026年9月24日 04:21 UTC —— 检查点通过一次 upload-large-folder 提交落地，二十分钟后，又追加了一份针对该模型的 README。从这一刻起，模型即可下载，而几乎没有人下载它。

• 2026年10月19日 07:03 UTC — GitHub 仓库创建完成。08:58 UTC，首次提交“Ming-3.0-tts 初始版本”带来了推理代码、一个 Dockerfile、一键示例脚本和任务手册。文档提交持续了整个下午。

GitHub README 的 News 部分称，0.5b 和 tiny 模型是在“2026.10”发布的。Hugging Face 卡片则完全没有提到日期。两者描述的是同一个产物：检查点在九月就已存在，而可用的发布——代码、环境版本锁定、示例——到十月才到位。如果你是在为采购文件标注模型日期，那么 9 月 22 日是它公开的时间；如果你是按“可运行”来标注日期，那么 10 月 19 日才是诚实的答案。

我们无法告诉你的是其中的原因。对于一个指望让模型卡自己说明一切的研究机构来说，静默发布很正常。当计划进行更大规模的公告时，分阶段发布也会呈现出这种样子。两个仓库中都没有说明是哪一种情况，而我们不会去猜。

0.5B 检查点里有什么？

该模型是一个稠密语音生成器，基于 Qwen2.5-0.5B 主干构建，并带有一个扩散 Transformer patch 头和一个独立的音频分词器。发布包不只是一个语言模型：仓库将主干、DiT 头、音频 VAE、以 ONNX 形式提供的 CAM++ 说话人编码器以及文本分词器全部打包在同一个文件夹中。这一打包决策解释了你会立刻遇到的一处差异。

• 参数——模型卡片和模型名称都标着 0.5B；而 Hugging Face 自己的元数据却将该仓库列为 1B，且单个 model.safetensors 文件就有 2.96 GB。0.5B 指的是语言主干部分。你实际下载的整个包在 bf16 下大约是它的三倍。

• 输出 — 44.1 kHz 音频，高于大多数开源 TTS 发布版本，也是这里少数几个你能用文件检查器在十秒内验证的说法之一。

• 语言——中文、英语、德语、西班牙语、法语、韩语和日语；提供该方言的参考片段时，还支持四川话和粤语。

• 语音——基于简短参考音频进行零样本克隆、通过自然语言描述设计音色，并内置 100 多种中文音色和 5 种英文音色。

• 控制 — 14 个内联标签，用于笑声、叹息、咳嗽、呼吸和犹豫，外加明确的情感、速度、音高和音量设置。卡片坦率地指出，音高是这四项中最不准确的。

• 任务 — TTS、自由形式指令、音色设计、多语言、基础属性、情感、方言以及内置音色模式。这些控制项在设计上互斥：自由形式不能与音色设计或内置音色组合使用。

• 许可 — MIT，权重与代码均适用。Ant 的使用免责声明要求你不得在未经同意的情况下冒充他人，并需标注合成语音，这属于请求而非许可证条件。

同一版本中还有第二个模型。Ming-3.0-tts-tiny 是基于 Ling V3 主干的混合专家设计，总参数 7.9B、激活参数 1.3B，并新增了 0.5B 模型不具备的多说话人播客生成能力。如果你特别关注小模型，更有用的理解框架是：0.5B 是轻量级部署选项，而 tiny 是能力上限——并不是说一个取代另一个。

基准测试表格，以及它们是由谁制作的

模型卡上的每一个数字都来自蚂蚁自己的评测框架。这不是批评——发布表格本来就是这样——但这些表格正被其他地方引用，却没有带上这个标签，所以这里说明一下。

• 零样本 Seed-TTS，中文——0.800% 词错误率，0.758 说话人相似度。

• 零样本 Seed-TTS，英语 — 词错误率 1.584%，说话人相似度 0.691。

• NVBench 副语言、单一事件 — 中文字符错误率 2.70，英文 7.60。

• Dialect、WSC-Eval-TTS-easy — 字符错误率 2.27%，准确率 80.68%。

• 语音设计，InstructTTSEval-ZH — 平均 72.29%。

• 基础属性控制 — 平均 93.30%，词错误率为 0.317%。

有趣的部分在于，同样这些表格在与该模型自己选定的竞品对比时说明了什么。在中文零样本错误率上，CosyVoice3-1.5B 录得 0.710%，Qwen3-TTS-12Hz-1.7B-Base 录得 0.770%，均优于 Ming 的 0.800%。在说话人相似度上，CosyVoice3-0.5B 的 0.780 胜过 Ming 的 0.758。在英文错误率上，Qwen3-TTS-12Hz-1.7B-Base 达到 1.240%，而 Ming 为 1.584%。

所以，Ming-3.0-tts-0.5B 即便在自身的对比集中也没有宣称摘得准确率桂冠，而且它也不需要这么做。它的优势在于其他模型没有填补的栏目：方言控制、音色设计，以及一个副语言套件——在其中它领先大多数单一事件类别。请把这张卡片理解为“在五亿主干参数下实现广泛控制”，而不是“最佳错误率”，这样它就站得住脚。

这份模型卡还异常坦率地列出了自身弱点，这一点值得反复强调，因为大多数模型卡并不会这么做：说话人相似度落后于内容准确度，法语相似度是最明显的多语言差距，多事件副语言句子仍不稳定，当词语本身不携带情感信号时情绪控制会下降，而开放式音色设计仍未达到其对比测试中最强系统的水平。

第一个独立数字在公告发布之前就到了。

Artificial Analysis 于 10 月 19 日将 Ming-3.0-tts 加入其语音竞技场，并将该条目链接到这个确切的 0.5B 检查点，这解决了模型卡留下的一个问题：被评分的模型就是小模型。两个榜单，两种结果，而它们指向不同的方向。

• Provider Voice：每个模型都使用各自的原生语音——Elo 1,188，95% 区间为 1,173 至 1,203，在榜单 98 个模型中排名第 19，在开放权重模型中排名第三，落后于 Elo 1,245 的 Fish Audio Drama 3 Preview 和 Elo 1,220 的 Breeze TTS 2。

• 受控语音（Controlled Voice）：每个模型都会克隆相同的八个参考语音——Elo 1,069，区间 1,053 至 1,085，总排名第 14，在开放权重模型中排名第一，领先于 Fish Audio Drama 3 Preview（1,059）和 Breeze T​TS 2（1,019）。

• 速度——在 Artificial Analysis 的硬件上，生成速度中位数为每秒 42.1 个字符，每次请求的生成时间中位数为 2.46 秒。作为参照，在同一套设备上，Simba 3.2 为每秒 77.8 个字符，Qwen-Audio-3.0-TTS-Plus 为每秒 25.6 个字符。

这种区分是有关该模型已公开发布的内容中最有用的。它的克隆语音在排行榜上与最好的开放权重系统相比具有竞争力；它自有的整套语音则不然。无论 Ant 的原生语音录音是什么样，它们都是拖低提供商语音排名的部分，而这是一个可修复的工程问题，而不是架构问题。

有一条我们无法核实的厂商说法：项目页面称，Ming-3.0-tts 在 Artificial Analysis 的发音稳健性指标上总体排名第一，达到 93.2%，并在其中两个子类别中排名第一。该指标确实存在，Artificial Analysis 也发布了它，但我们能读取的页面数据中并未公开每个模型的具体数值，因此在你亲自看到柱状图之前，请将 93.2% 视为厂商提供的数字。

运行它大约需要二十分钟，还得改三处。

Hugging Face 仓库只是一个 checkpoint 发布页。顶部附近的提示框里已经说明了这一点：推理需要依赖 GitHub 项目，而模型卡中提到的 Python API 和 CLI 都来自那里。这是第一处不便，也正是十月仓库比九月上传版更重要的原因。

第二个是文本规范化。数字、日期、单位和符号由需要 pynini 的 FST 语法处理，而 pynini 没有通用 wheel；Ant 自己的说明会引导你到 conda-forge 获取 2.1.6 版本。如果你不想这样做，--no_text_normalization 会跳过它，你就只能沿用文本现有的样子。对于生产级旁白流水线来说，这是一个真正的决策，而不是脚注。

第三点是硬件。环境固定为 PyTorch 2.6、CUDA 12.4 和 transformers 4.46.3，并提供了 Dockerfile，且已在 H800-80GB 和 H20-96G 上测试过。flash-attn 是可选的，推理会回退到 PyTorch SDPA。发布内容中没有任何迹象表明它能在消费级显卡上轻松运行，而且目前 Ant 之外还没有人在更小规模的硬件上公布吞吐量数据。

环境就绪后，最小可行调用就是一次 CLI 调用，并附带一段参考音频片段及其转录文本——克隆会同时以这两者为条件，其中 --use_spk_emb 会启用说话人嵌入条件。还有一个预检脚本，可以在不加载权重的情况下检查检查点和分词器；在因为糟糕的下载而浪费一次 GPU 分配之前，值得先运行它。

还有什么仍然无法知晓？

有四件事会改变评判这个模型的方式，而这四件事目前都还不存在。

没有托管端点，也没有价格。Artificial Analysis 将价格字段列为空，因为没有什么可定价的——调用它的唯一方式就是自行运行它。对于拥有 GPU 的团队来说这没什么问题，但对其他人来说就是个难题，而这也是本次发布与它将被拿来比较的托管语音之间最大的实际区别。

没有技术报告。GitHub 路线图将其列为一个未勾选的复选框，而 Ant 从模型卡中删除了早先对一份未经证实的报告的引用。这使得架构描述仅停留在一张图和一段话的水平，足以运行模型，却不足以复现训练相关的声明。

没有独立的错误率复现。Seed-TTS 和 NVBench 的数字是 Ant 的，使用 Ant 的协议和 Ant 推荐的推理设置测得。竞技场评分是独立的，但衡量的是偏好，而不是准确率。实验室之外没有人发表过这个检查点的词错误率。

而且没有任何意向声明。没有公告就意味着没有支持承诺、没有弃用政策，也没有任何迹象表明是否会推出托管服务。对于一个采用 MIT 许可证的研究发布来说，这或许完全是有意为之。但对于任何打算将其用于产品的人来说，这是一个必须被计入成本的风险。

OrcaRouter 不路由 Ming-3.0-tts-0.5B，本文也不应被解读为暗示相反的情况——目录中并不包含任何 Ming 语音模型。目录真正收录的是语音流水线的其余部分：openai/tts-1 与 tts-1-hd、gpt-4o-mini-tts 以及 G​emini T​TS 预览版，全部按供应商标价提供，不额外加价；同一密钥背后还有 200 多个文本模型，服务于系统中负责撰写脚本或驱动智能体的那一半。如果你正在评估一款尚未验证的开源权重语音模型，稳妥的部署方式是让它远离关键路径，直到它证明自己配得上这个位置；跨供应商的自动故障转移，正是这条流水线中文本那一半在你做决定期间保持可用的方式。

下一个真正的信号不会是又一张基准测试表格。而是 Ant 之外的第一个人在自己的音频上运行 0.5B checkpoint，并公开说明哪里出了问题。在这一步发生之前，站得住脚的总结只能是有限的：一个确实具备能力、MIT 许可、44.1 kHz 的多语种语音，在独立榜单上拥有最佳的开源权重克隆语音得分，但原生音色阵容较弱，发布未经预告，也没有托管归属。这是一个有前景的研究产物，尚不足以构成产品决策。