Phonon：一个 64 MB 的 TTS 模型，其三份规格表却互不一致

英文检查点 Phonon 31M——发布为 gradium/phonon-31m-en——是一个 64.5 MB 的文件。这就是整个模型，量化为八位，并能在笔记本电脑 CPU 上生成 24 kHz 语音，其首音延迟被厂商称为个位数毫秒。由前 Kyutai 研究人员创立的巴黎语音公司 Gradium 于 2026 年 10 月 20 日将 Phonon 系列发布到 Hugging Face，同时发布了 Rust 运行时和 WebAssembly 构建，让它在浏览器标签页内就能说话。

三天后，读者能做的最有用的事，不是去听演示，而是把发布博客、模型卡和运行时 README 并排放在一起看。它们描述的是同样的两个检查点——Phonon 31M和Phonon 40M——而它们在数字上并不一致。这种不一致并非丑闻；对一个发布仅三天的版本来说，这很正常。但它恰好告诉你，哪些数字可以放心据此做规划，哪些仍只是运输途中的营销说辞。

10月20日实际发布了什么

Gradium 一次性发布了四样东西：权重、语音、运行时，以及一项比基准测试表更重要的许可证拆分。

权重以三种形式提供。Phonon 31M仅支持英语，采用 Apache 2.0 许可，内置 37 种音色，并提供大小为 64.5 MB 的 q8 GGUF。Phonon 40M以五个独立的单语言检查点形式发布——英语、法语、德语、西班牙语和葡萄牙语——每个约 74.6 MB，每个都需要接受 Hugging Face 条款后才能访问，且每个均采用 CC BY-NC 4.0 许可。第三个检查点，Phonon 40M multilingual将全部五种语言合并到一个拥有 102 种音色的模型中，并采用相同的非商业许可。

那条许可条款是第一个决策点，而且很容易被忽略，因为这个系列被描述为开放。只有 31M 英语模型可免费用于商业用途。40M 模型是研究意义上的开放权重：可下载、可检查、可运行，但若无商业协议，就不能授权用于产品。团队如果因为 40M 听起来更好而用它做原型，之后又试图发布产品，就会很晚且代价高昂地撞上这堵墙。

用一段话概述架构

Phonon 是一个流匹配 Transformer，它以 80 毫秒帧预测音频潜变量，并将其交给 Kyutai 的 Mimi 编解码器进行解码。它基于 Pocket TTS 构建，后者是出自同一研究圈的小模型产品线。运行时 xn-ptts 使用 Rust 编写，推理时不使用 PyTorch：CPU 路径使用 Arm KleidiAI，Apple 设备可使用 Core ML，Snapdragon 芯片可使用 QNN NPU，浏览器则可获得 SIMD WebAssembly 构建版本。它提供 Python、Swift、JavaScript 和 C 的绑定，另有一个暴露 OpenAI 兼容语音端点的 Docker 镜像。

实际后果是，Phonon 并不是那种你加载到 Python notebook 里、指望它能跑起来的检查点。它是一个部署目标。同一个 64 MB 文件可在 Raspberry Pi、iPhone、浏览器和容器中运行，而运行时本身和权重一样，都是产品的一部分。

三份文件，三组数字

值得放慢细看的部分在这里。在10月20日的发布博客中，Phonon 31M 在 MacBook Air M5 CPU 上可在7毫秒内输出首个音频，在单核上以11.6倍实时速度运行，在四线程上达到29.9倍。在 Raspberry Pi 5 上，它启动耗时38毫秒，并以3.7倍实时速度运行。同一篇博客给出 Phonon 31M 的困难文本词错误率为1.70%，英语自然度 Elo 为2,098，而 Kokoro 为2,043。

在同一时间窗口内更新的运行时 README 对同一台 MacBook Air M5 给出的数据是：单核上吞吐量为实时的 26 倍，首字节时间为 5 ms；四核上为实时的 41 倍，首字节时间为 6 ms。在 Raspberry Pi 5 上，它称吞吐量为实时的 2.3 倍，首个音频输出延迟为 68 ms。这些并不是舍入差异。一份文档称该模型在 Pi 上的速度大约是另一份文档所述的两倍。

Hugging Face 模型卡新增了第三个版本：Phonon 31M 在困难集上的 WER 为 1.5%，在 Seed-TTS 上为 0.51%，Elo 同为 2,098。发布博客的表格显示困难集上为 1.70%。两者均为厂商自行开展的评估。二者均未引用独立测试框架，且 Artificial Analysis 上尚无该系列模型的条目。

• 参数数量——不含音频分词器为 31M，但 Hugging Face 元数据对同一检查点列出的是 41.1M。

• 首段音频 — 在发布博客上为 7 毫秒，在 README 中为 5 毫秒，均在相同的 MacBook Air M5 上测得。

• 单核吞吐量——博客中为实时速度的 11.6 倍，README 中为 26 倍。

• Raspberry Pi 5 — 博客中为 38 毫秒、3.7×，README 中为 68 毫秒、2.3×。

• 困难集 WER——博客上为 1.70%，模型卡上为 1.5%。

这并不是放弃该版本的理由。相反，这提醒我们：在 Gradium 之外的任何人复现之前，应把每个数字都视为一个区间。Elo 分数最具可比性，因为它们明确给出了基线：Phonon 40M 为 2,117，Phonon 31M 为 2,098，Phonon 40M 多语言版为 2,097，Kokoro 为 2,043。在厂商自家的听力测试中领先 Kokoro 55 分是一个有分量的主张，而且它可被证伪——这已经比大多数 TTS 发布所提供的内容更多了。

仓库告诉你但博客没有告诉你的事

该代码仓库回答了公告中略过的那些问题。浏览器包只能直接从 Hugging Face 加载 Phonon 31M；40M 检查点必须由你自己的应用来提供，如果你最初被吸引的是“在标签页中实现 TTS”这个卖点，那这就是一个实打实的限制。受限模型需要在构建时或运行时提供 Hugging Face token。Android QNN 路径要求 Android 12 和支持的 Snapdragon HTP，而且没有自动的 CPU 回退——如果 NPU 拒绝该模型，你会得到错误，而不是更慢的运行。

语音文件与权重是分开的。检查点中附带了一些语音，而 gradium/phonon-voices 的目录收录了更多语音，包括 .safetensors 格式的自定义语音。这种分离是合理的工程做法，但也是文档最少的部分。截至 10 月 23 日，自定义语音如何训练、随附何种同意记录，以及 Gradium 是否为生成的音频加水印，这些在公开材料中均未得到解答。

已确认的是：代码采用 MIT 或 Apache-2.0，由你选择；31M 权重采用 Apache 2.0；40M 权重采用 CC BY-NC 4.0；并且运行时确实存在于 Linux、macOS、Windows、iOS、Android、浏览器和 Docker 上。尚未确认的是：独立延迟、独立可懂度、超出几句话的长文本稳定性，以及多语言检查点如何处理句子内部的语码转换。

在哪些场景下，3100 万参数才是合适的工具

Phonon 在第一周被拿来比较的模型，大多是参数量高出百倍、前面还多一跳网络的云端系统。这是类别差异，不是质量差异。一个能在个位数毫秒内开始发声的 64 MB 英语模型，适用于音频不能离开设备，或必须在无网络时也能工作的情况：离线无障碍工具、游戏对话、自助终端与家电界面、手机上的私人助手，以及无法承受一次网络往返的浏览器功能。

对于相反的情况，它就不太适合了。如果你需要三十种语言、48 kHz 输出、根据文本描述设计声音，或者从十秒参考音频进行工作室级克隆，Phonon 31M 这些都做不到。即便是多语言的 Phonon 40M，也只覆盖五种语言，而不是三十种，而且它的许可证把大多数商业产品排除在外。

三天后，诚实的总结是：Gradium 交付了一套异常完整的端侧技术栈，但外部验证却异常薄弱。其工程实现可供审查——运行时在 GitHub 上，权重可下载，基准测试的文档足够详尽，足以复现。但其宣称尚未被任何人复现。

Phonon 未覆盖的那一半语音环路

本地 TTS 模型只是语音助手的一个组件，而且是最后一个环节。仍然需要有东西来决定说什么：转写用户的话、检索答案、起草回复。Phonon 在设备上把文本转换成音频，但文本通常来自模型服务器，而运维的复杂性实际上恰恰存在于那台服务器上。

这就是 OrcaRouter 所处的边界。Phonon 不在我们的目录中——它运行在你的硬件上，而非通过 API，本文任何内容都不应被理解为在暗示相反的情况。但为 Phonon 撰写脚本的那个语言模型可以，它与另外 200 多个模型一起共用一个密钥，对供应商标价零加价，并具备自动故障转移，在某个供应商服务劣化时生效。对于离线优先的产品来说，这种分工再自然不过：语音合成留在设备上，文本生成则路由到当下最便宜、最健康的那个模型。

未来一个月值得关注什么

三个信号将解决大部分悬而未决的问题。第一个是独立评估——Artificial Analysis 增加语音条目，或某个实验室基于已发布的检查点重新运行 Seed-TTS。第二个是 40M 模型的商业许可；如果 Gradium 开放这些模型，多语言检查点会比英语检查点有趣得多。第三个是声音克隆文档。Gradium 自己的博客承诺将在“未来的一篇文章”中公布盲听结果，这既是一种诚实的发布，也承认了当前证据不过是公司在给自己打分。

到那时为止，站得住脚的立场是这样的：Phonon 31M 是真实存在的，它很小，它能在厂商声称它运行的地方运行，而且它是 Apache 2.0。确切的速度和准确度处于厂商自己的文档所描述的范围内的某个位置。任何打算围绕 7 ms 这个数字规划产品的人，都应该先在其目标硬件上测试它——而任何围绕 40M 模型做规划的人，都应该先读一下许可证，再爱上这个声音。