Gradium Phonon 开源：3100 万参数端侧 TTS，词错率 1.70%

一句话结论：法国语音 AI 公司 Gradium 开源了 Phonon 端侧文本转语音家族，3100 万参数的英文版只有 64.5 MB，词错率 1.70%，在 MacBook Air M5 的纯 CPU 上 6.9 毫秒就能吐出第一段音频。

2026 年 10 月 22 日，Gradium 把 Phonon 模型的权重和运行时放到了 GitHub 与 Hugging Face 上。这家公司是从 Kyutai 分拆出来的巴黎语音 AI 团队，此前只在闭源服务里做定制音色。开源之后，Phonon 成为 2026 年 10 月端侧语音合成的竞争者中参数最省的一档，比 Kokoro 的 8200 万参数更小，比 NeuTTS Nano 的约 2.29 亿总参数更小，比刚开源的 IBM Granite Speech 5.0 更贴近消费级设备能承受的体积。

过去两年端侧 TTS 的进展集中在「让小模型也能听懂复杂文本」。IBM 的 Granite Speech 5.0 把英文词错率压到 5.68%，站内那篇 IBM Granite Speech 5.0 开源与词错率拆解 记录了它的位置。Phonon 走的是另一条路，先把体积和首段延迟压到能在树莓派上跑，再在难句集上追准确率。两条路线在云端合成面前都站得住，因为它们服务的场景完全不同。

Phonon 家族：三个模型，两套许可证

Phonon 一共放出三款权重，全部是因果 Transformer 骨干，区别只在语言覆盖、音色数量和许可证上。最关键的一点是，31m 是唯一拿到 Apache 2.0 的版本，可以直接商用；两款 40m 都是 CC BY-NC 4.0，明确禁止商用。这个切分基本决定了不同团队该选哪一个。

参数量统计不含音频 tokenizer，输出统一为 24 kHz 单声道。运行时本身是 MIT 或 Apache-2.0，用 Rust 编写，提供了 Rust、Python（pip install ptts）、Swift、C、C++ 与浏览器端（phonon-tts）绑定，还带一个 OpenAI 兼容服务器和一个 WebSocket 服务器。权重可以直接在 Transformers、MLX-Audio、Ollama 和 LM Studio 里加载，Gradium Studio 做的音色克隆与音色设计也支持本地运行。

这一点的意义比体积更实际。上一代端侧语音方案往往要在推理栈上做适配，Phonon 把 OpenAI 兼容接口做进了运行时，ollama 与 LM Studio 也能直接挂载，对于要把语音塞进现有 Agent 应用的团队来说，迁移成本比省下的那几十兆更有意义。

词错率与 Elo：难句集拉开差距，易句集并不领先

Gradium 用两套测试集衡量 Phonon。一套是自建的难句集，每种语言 500 句，句子里塞满电话号码、邮箱和邮编；另一套是公开的 Seed-TTS 测试集。前者对文本归一化能力要求极高，后者句子更常规。结果是 Phonon 在难句集上大幅领先，在 Seed-TTS 上反而落后于 Kokoro。

难句集上 1.70% 对 3.50% 的差距，来源是内置的文本归一化把号码、邮箱、日期读对。Kokoro 在更难读的数字串上会明显掉分，而 Phonon 用一个 4000 词的 SentencePiece 分词器直接读原始文本，不做音素转换，省掉了整条音素化链路，也省掉了随之而来的规则维护成本。

Seed-TTS 上 0.51% 落后 Kokoro 的 0.45%，差距很小但方向明确。同一批测试还显示 Phonon 40m 多语版是 0.48%，比 31m 的 0.51% 更好，这一行的排序与模型大小的直觉相反，也说明这两个数字之间的差异可能落在评测噪声范围内。

盲测是这套数据里最硬的部分。Gradium 请了 1189 名评分者投出 17270 票，做的是两两成对比较。英文环境下 Phonon 40m 拿到 2117 分，31m 是 2098，Kokoro 2043，NeuTTS 2034，Magpie 1939。55 分的差距建立在有基线、有样本量的测试上，比单方跑分更值得看。模型卡里还给出按语言拆分的数字，法语环境下 Phonon 40m 拿到 2072 分，Kokoro 只有 1578，不过每个语种的评分者只有 170 到 200 人，比英文池小得多。

速度：CPU 上 6.9 毫秒，树莓派上 38 毫秒

端侧 TTS 的体验瓶颈往往不在音质，首段延迟才是关键。用户点下播放到听到声音之间隔了半秒，整个交互就散了。Phonon 的定位就是把这个数字压到毫秒级。

树莓派上 38 毫秒对 7 秒这个对比最能说明问题。Kokoro 慢在不做流式，整段合成完才输出，Phonon 按 80 毫秒一帧往下生成，音频边生成边播。对本地助手、读屏工具、游戏对话这类场景，流式与否决定了体验是可用还是不可用。

这套「端侧能跑」的组合在近半年密集出现。Recursive Flint 让 40B 的 MoE 模型只激活 25 亿参数、在本地跑到每秒 131 token，站内 Recursive Flint 开源与本地吞吐拆解 记录了那条路径。讯飞星火 X2.6 则把 4B 版本推到端侧 BFCL 拿 71.8 分，讯飞星火 X2.6 的端侧与云侧分工 里有完整拆解。手机侧的限制也在松动，骁龙 8 Elite Gen 6 让本地跑 300 亿参数 MoE 模型 是其中的标志性进展。Phonon 补上的是语音这一格。

架构：因果 Transformer 加流匹配头

Phonon 的骨架不复杂。SentencePiece 分词器以 4000 词表直接读原始文本，文本嵌入与说话人嵌入拼接成前缀送进因果 Transformer。骨干每 80 毫秒吐出一个隐向量，流匹配头一步把隐向量加噪声转成音频嵌入，再交给一个缩小版的 Kyutai Mimi 解码器输出 24 kHz PCM。停止发声由一个独立的结束预测头决定，不靠长度上限硬切。

31m 是 6 层 Transformer，宽度 512，8 个注意力头；40m 是 9 层，宽度不变。两款都由更大的 Phonon 教师模型蒸馏而来，训练跑在英伟达 H100 集群上，用了 NCCL 与 CUDA Graphs。这套设计直接继承自 Kyutai 的连续音频语言模型研究和 Pocket TTS，Gradium 的贡献在于把它缩到消费级硬件能承载的尺寸。

对做端侧推理的人，链路选择和体积是一体两面。递归激活加本地内存调度这条路，站内 Colibrì 用 SSD 当显存跑 744B 模型 展示的是把 25GB 内存塞进大模型的极限思路；Phonon 走的是相反方向，把模型压到不需要这类技巧的尺寸。推理引擎侧的另一种优化方式可以看 llm-d 1.0 的 17000 节点吞吐实践，那是集群侧的调度课。

三个被官方数字掩盖的问题

Phonon 的发布材料完整，但几处数字互相打架，值得单独列出来。第三方测评把博客、README 和模型卡并排比对后指出，首段延迟在博客里写 7 毫秒、README 写 5 毫秒，同一台 MacBook Air M5；单核实时倍速在博客是 11.6 倍、README 是 26 倍；树莓派 5 的启动时间博客写 38 毫秒 3.7 倍，README 写 68 毫秒 2.3 倍；难句集词错率博客写 1.70%、模型卡写 1.5%；同一个 checkpoint 在 Hugging Face 元数据里标着 4110 万参数，和官方口径的 3100 万对不上。

这些差异不构成否定理由，但足以提醒一件事，所有数字都应按区间看，等第三方复现。目前还没有独立复现，Artificial Analysis 这类第三方评测库也还没有该家族的条目。

第二是浏览器端的实际限制。浏览器包只能直接从 Hugging Face 加载 31m，40m 的 checkpoint 需要自建服务，这和「在浏览器里跑 TTS」的第一印象有落差。部分模型是 gated 的，构建或运行需要 Hugging Face token。Android 的 QNN 路径要求 Android 12 与支持 HTP 的骁龙芯片，且没有自动回退到 CPU，NPU 不认模型时直接报错，不会自动降速到 CPU 上跑。

第三是许可证与合规的空白。40m 全系禁止商用，商用只能选 31m 或换其他家族。音色文件与权重分离存放，一部分音色在 checkpoint 里，另一部分在 gradium/phonon-voices 目录，还有自定义的 safetensors 格式音色。这套分离在工程上合理，但公开材料里没有交代自定义音色的训练方式、同意记录如何流转、生成音频是否加水印，这三件事在语音克隆场景里都是绕不开的合规问题。

谁该用，谁该绕开

Phonon 适合三类场景。一是音频不能离开设备的场景，无障碍读屏、本地助手、游戏与设备语音播报，合规上要求不出网时，它是目前体积最小的可行选项之一。二是延迟敏感场景，首段 6.9 毫秒到树莓派 38 毫秒这个区间，比绝大多数云端方案的往返时间短一个数量级。三是需要英文商用授权的场景，Apache 2.0 加 37 个内置音色，商用路径没有障碍。

不适合的场景也很清楚。需要三十种语言、48 kHz 输出、从十秒参考音频做录音室级克隆，这三样 Phonon 都不做。五种语言加非商用许可，对多数商业产品是硬约束。已经在用云端 TTS 且对音质要求高于首段延迟的团队，也没有换过去的必要。

它的位置可以这样看。云端语音模型继续追求音色设计与克隆质量，Gemini 3.8 Flash TTS 支持 100 种语言、30 秒复刻声音，站内 Gemini 3.8 Flash TTS 的能力边界 做过梳理；蚂蚁百灵开源的 Ming-3.0 语音系列则覆盖合成、理解与识别三类任务，Ming-3.0 语音系列拆解 里能看到国内开源语音的完整布局。Phonon 的位置在两者之间，它不追求功能广度，只把英文单语种这一件事做到足够小、足够快。

常见问题

Phonon 31m 可以商用吗

可以。31m 采用 Apache 2.0 许可，允许商用修改与再分发。40m 与 40m 多语版都是 CC BY-NC 4.0，明确禁止商业用途。需要多语言就只能选 40m，且要接受非商用限制，或者改用其它家族。

词错率 1.70% 的测试由谁完成

是，全部来自 Gradium 自建难句集与公开 Seed-TTS 集，盲测的 1189 名评分者与 17270 票也是自家组织。第三方测评指出模型卡与博客在词错率、延迟、体积上数字不一致，目前也没有独立复现。这些数字可以当作厂商口径的参考区间，不宜当成行业公认基线。

在树莓派上真的能用吗

能用。官方给出树莓派 5 上首段 38 毫秒、3.7 倍实时的结果，同设备上 Kokoro 需要约 7 秒才能启动。需要注意的是第三方在 README 里读到的是 68 毫秒与 2.3 倍倍速，以及浏览器包只能直接加载 31m、QNN 路径无 CPU 回退这些约束，实际部署前应在自己的硬件上实测一遍。

小结

Phonon 把端侧 TTS 的两个长期矛盾摊到了同一张表上，体积和准确率。二三十年来这条链路一直是取舍关系，参数压下去词错率就飘，词错率压住延迟就上去了。Phonon 用内置文本归一化加上不做音素转换的选择，在难句集上拿到 1.70%，同时把权重压到 64.5 MB、首段压到 6.9 毫秒。这个组合在 Apache 2.0 授权下拿出来，是端侧语音从演示走向可用的一次实质性推进。

它当然有自己的边界。数字还没被独立复现，多语言全部锁在非商用许可里，自定义音色的合规细节仍是空白。真正的考验在第三方跑分出来的那天。但对需要把语音放进离线助手、读屏工具和设备端交互的团队，这套权重现在就可以下载、量化、跑起来。

相关阅读

• IBM Granite Speech 5.0 开源：英文词错率 5.68%，开源第二
• 蚂蚁百灵开源 Ming-3.0 语音系列：五款模型覆盖合成、理解与识别
• Gemini 3.8 Flash TTS 发布：30 秒复刻声音，支持 100 种语言
• Recursive Flint 开源：40B 只激活 2.5B，本地跑 131 tok/s
• 讯飞星火 X2.6：293B 国产算力训练，4B 端侧 BFCL 拿 71.8 分