Gradium 开源端侧 TTS 模型 Phonon：英语 31M 版 Apache 2.0，64.5 MB 可离线跑
据 MarkTechPost 2026 年 10 月 22 日报道，Gradium 开源端侧 TTS 家族 Phonon，含 31M 参数、64.5 MB q8 权重的英语 Phonon 31m，Apache 2.0 许可；厂商自测困难句集 WER 1.70%，MacBook Air M5 CPU 上 6.9 ms 出首个音频。
发生了什么
据 MarkTechPost 2026 年 10 月 22 日报道，从 Kyutai 分拆出来的巴黎语音公司 Gradium 开源了端侧文本转语音模型家族 Phonon。该家族包含三个模型：仅英语的 Phonon 31m，31M 参数（不含音频 tokenizer）、64.5 MB q8 GGUF、24 kHz 单声道输出、内置 37 个音色，采用 Apache 2.0 许可；按语言各自独立的 Phonon 40m（英语、法语、德语、西班牙语、葡萄牙语），74.6 MB，以及把五种语言放进单个模型、提供 102 个音色的 Phonon 40m 多语言版，后两者采用 CC BY-NC 4.0 非商业许可。架构上，Phonon 采用因果 transformer 主干，前缀拼接文本与说话人嵌入，使用 4000 词表的 SentencePiece tokenizer 直接读取原始文本，不做音素转换；主干每 80 ms 帧输出一个潜向量，flow-matching 头单步将其转为音频嵌入，再由 Kyutai Mimi 解码器的缩小变体输出 24 kHz PCM，另有独立的语音结束头决定停止。Phonon 31m 为 6 层、宽度 512、8 个注意力头，40m 为 9 层同宽度，二者均从更大的 Phonon 教师模型蒸馏而来，训练在 NVIDIA H100 集群上完成，工作建立在 Kyutai 的连续音频语言模型研究与 Pocket TTS 之上。厂商公布的性能数字包括：1189 名评分者、17270 次投票的盲测中，美式英语 Phonon 40m 为 2117 Elo、Phonon 31m 为 2098，Kokoro 为 2043；在公开困难句集上（每语言 500 句，含电话、邮箱、邮编）Phonon 31m 的 WER 为 1.70%，Kokoro 为 3.50%，NeuTTS Nano 为 8.71%；在较容易的 Seed-TTS 集上差距缩小，Phonon 31m 的 LLM WER 为 0.51%，反而略高于 Kokoro 的 0.45%。速度方面，4 线程 MacBook Air M5 CPU 上首个音频 6.9 ms、约 29.9 倍实时（配合 Arm KleidiAI 与 Apple Accelerate 可达 46.7 倍），Raspberry Pi 5 上 38 ms 启动、3.7 倍实时，Snapdragon 8 Elite Gen 5 上 7.5 ms、24 倍实时，NVIDIA L40S 上 CUDA 5 ms，AMD EPYC 7413 CPU 43 ms。运行时采用 MIT 或 Apache-2.0 许可，覆盖 Rust、Python（pip install ptts）、Swift、C、C++ 及浏览器（phonon-tts），并提供 OpenAI 兼容服务器与 WebSocket 服务器；模型可在 Transformers、MLX-Audio、Ollama、LM Studio 中加载，声音克隆与声音设计在 Gradium Studio 完成后再本地运行。
对开发者的影响
对开发者而言，这条消息的实际价值在于把英语 TTS 从按字符计费的云端调用，变成可随应用分发的本地组件。31M 参数、64.5 MB q8 权重的体积意味着它可以与业务代码一起打进移动端安装包或浏览器资源，不必依赖网络往返，也不占用 GPU 预算；流式能力带来 6.9 ms 级首音频，使实时对话、交互式朗读这类对首字延迟敏感的场景在纯 CPU 上变得可行。但需要注意三点：其一，Apache 2.0 只覆盖英语 Phonon 31m，40m 与 40m 多语言版是 CC BY-NC 4.0，商业产品不能把多语言能力当作同一授权下的免费扩展，若需要法语、德语等语种，要么寻求另行授权，要么继续使用其他方案。其二，报道中的 Elo、WER、速度数字均来自 Gradium 自建评测，评测集与对比对象由厂商选择，困难句集 WER 1.70% 对 Kokoro 3.50% 的领先主要被归因于内置文本规范化，而在更常规的 Seed-TTS 集上 Phonon 31m 反而略落后于 Kokoro，说明优势集中在电话号码、邮箱、邮编这类结构化文本，不应外推为全面领先。其三，量化体积、多线程延迟与吞吐高度依赖具体硬件、线程数和运行时后端，同一模型在不同 CPU、不同绑定方式下表现可能明显不同，报道给出的单点数字只能作为量级参考。
接入与评估建议
建议按以下两条条件化决策推进。第一，若产品的主要诉求是英语离线播报且部署环境为 CPU 或手机，建议直接以 Phonon 31m 为候选替代云端 TTS：先确认许可范围只用于英语 31m，再在目标设备上以 q8 权重实测。评估标准可设为——在目标机型上以固定线程数跑一批真实业务文本，测量首音频延迟的 P50 与 P95，并与现有云端方案的端到端延迟（含网络）对比，若 P95 首音频未达到可接受阈值则退回云端方案。第二，若产品需要多语言，建议把 40m 多语言版视为非商业选项单独立项：在确认商业模式允许 CC BY-NC 之前，仅用于内部原型。评估标准可设为——用困难句数据集中的多语言样本比较各语种 WER 与音色自然度主观分，同时记录许可证是否满足分发要求，若两者任一不达标则维持原有供应商。第三，无论选哪条路径，都建议先做文本规范化对照测试：把电话号码、邮箱、邮编、金额等结构化文本抽成固定用例集，分别用带内置规范化的 Phonon 与需要自行预处理的方案跑同一批文本，比较错误率，因为报道明确指出这部分是差距的主要来源；若自研规范化已足够好，Phonon 的这项优势就会被抹平，选型应转向延迟与体积。第四，建议把运行时后端也作为变量纳入评测：比较普通 CPU 路径与启用 Arm KleidiAI、Apple Accelerate 等加速库的版本，确认在目标芯片上是否能复现数量级的吞吐提升，若不能复现则按保守值规划并发容量，并提前评估 WebSocket 与 OpenAI 兼容服务器在自托管场景下的运维成本。以上均为基于报道的推荐与条件分析，不是已核实的事实。
限制与待确认事项
报道中的 Elo、WER 与延迟数字均出自 Gradium 自建评测与新闻稿，评测集、对比对象和测试条件由厂商选定，未经过第三方独立复现，Seed-TTS 集上 Phonon 31m 反而落后于 Kokoro 这一点也说明优势有条件。许可方面只确认英语 Phonon 31m 为 Apache 2.0，40m 与多语言版为 CC BY-NC 4.0，开源权重不等于可自由商用，选型前应核对各模型卡原文而非仅凭权重可下载推断授权。另外，Phonon 31m 及整个 Phonon 系列目前未出现在 KimiSeek 的实时模型目录中，本文所引用的可用性、许可与性能信息均来自 Gradium 及其报道，与 KimiSeek 平台无关，也不代表该平台提供该模型或相关 API；各方价格与许可条款可能随时间变化，请以发布方与平台最新页面为准。