Phonon vs VoxCPM2：多出 64 倍的参数在 TTS 中究竟能换来什么

VoxCPM2是 OpenBMB 于 2026 年 4 月发布的一款 20 亿参数语音模型，能以 48 kHz 说 30 种语言，并能根据文字描述创造声音。Phonon 31M是 Gradium 于 2026 年 10 月 20 日发布的一款 3100 万参数模型，能以 24 kHz 用 37 种固定音色说英语，且体积仅 64.5 MB。参数比约为 64 比 1，而令人惊讶的不是更大的模型做得更多，而是在两家厂商都公布的唯一一个数字——Seed-TTS 上的英语单词错误率——上，较小的模型却声称得分更好。

这个说法几乎肯定不是公平的比较，而弄清其中的原因，比任何一款模型的发布博文都更能说明开源 TTS 的现状。VoxCPM2 和 Phonon 31M 都采用 Apache 2.0 许可，都可以下载，也都面向那些希望使用语音而不必按字符付费的团队。但它们面向的硬件完全不同。

两份不同的工作却顶着同一个标签

VoxCPM2 是一个通用多语言语音生成器。它无需分词器，采用扩散自回归架构，在 AudioVAE V2 潜空间中运行，基于 MiniCPM-4 主干网络，历经作者命名为 LocEnc、TSLM、RALM 和 LocDiT 的四个阶段。它支持根据自然语言描述进行音色设计、基于短参考音频的可控克隆，以及同时使用参考音频片段及其转录文本的续写式克隆。它输出 48 kHz 音频，并接受 16 kHz 参考音频。

Phonon 31M 是一个单语言、单一用途的合成器。它是一个基于 Mimi 潜在表示的流匹配 Transformer，每次处理 80 毫秒的帧，解码为 24 kHz 单声道。它不具备音色设计功能，在文档化的 API 中无法从参考片段进行克隆，也没有语言检测功能。它有一个音色目录、一个文本输入，以及一个能在个位数毫秒内启动的运行时。

把两者都称作“开放 TTS”既准确，又没什么帮助。一个是语音研究平台；另一个是嵌入式组件。

64× 放在哪里

参数预算能换来四点，而这四点都体现在规格表上，而不是听感测试中。

• 语言——VoxCPM2 支持 30 种语言外加九种中文方言；Phonon 31M 仅支持英语。

• 输出采样率 — VoxCPM2 原生支持 48 kHz；Phonon 31M 为 24 kHz 单声道。

• 语音创建 — 基于描述的音色设计，以及 VoxCPM2 的三种克隆模式；37 个内置音色，外加 Phonon 31M 的自定义音色目录。

• 硬件门槛 — VoxCPM2 在 RTX 4090 上约需 8 GB 显存；Phonon 31M 则需 64.5 MB 和一个 CPU 核心。

• 速度 — 在 RTX 4090 上，VoxCPM2 的实时因子约为 0.30，使用 Nano-vLLM 时则为 0.13；根据 Gradium 的 README，Phonon 31M 在笔记本单核上的速度比实时快 26 到 41 倍。

• 许可证 — 两者均为 Apache 2.0。

WER 比较并不是比较

VoxCPM2 的技术报告列出其在 Seed-TTS-eval 上的英语 WER 为 1.84，说话人相似度为 75.3。Phonon 的模型卡列出 Phonon 31M 在 Seed-TTS 上为 0.51。对照来看，这像是一场碾压：一个 31M 模型在可懂度上以三倍的优势击败了一个 2B 模型。

并非如此。这两个数字来自不同的测试框架，可能使用了不同的参考集，而且几乎可以肯定使用了不同的转写模型来对输出进行打分。Gradium 为其早期评测公开发布的方法论使用了 Seed-TTS 的英语部分——1,008 条话语——通过 whisper-large-v3 转写，并用编辑距离打分。OpenBMB 的技术报告在其模型页面上展示的图表中并未使用完全相同的流程。两家厂商都没有用各自的测试框架运行对方的检查点，也没有第三方发布过正面对比。

这些数字确实支持的，是一个较弱但仍然有用的说法：两个模型在标准英语测试集上的 WER 都处于低个位数区间，也就是说，两者都足够清晰，可用于生产环境的朗读工作。认为 3100 万参数无法生成干净英语的观点，在 2026 年根本不成立。认为 3100 万参数模型能在 30 种语言上比肩 20 亿参数模型的观点同样不成立，而且两家厂商都没有这样宣称。

不信任这个标题还有第二个理由：Gradium 自己的文件彼此矛盾。发布博客给 Phonon 31M 硬性设定的 WER 为 1.70%，模型卡给出的是 1.5%，而运行时 README 完全没有公布 WER。当同一厂商的三份文档在同一指标上相差 13% 时，正确的应对方式是把该数字视为一个区间。

硬件下限才是真正的决定因素

VoxCPM2 需要 GPU。参考配置约为 8 GB 显存，在未使用优化服务栈的 RTX 4090 上，模型运行耗时约为实时的三分之一。在配备 Q8_0 量化的 Apple M4 Pro 上，实时因子约为 1.76，也就是说生成一秒音频需要 1.76 秒计算——慢于实时，在该硬件上不适合实时对话。使用 Nano-VLLM 时，该因子降至约 0.13，速度很快，但这是一个带有自身运维成本的服务栈。

Phonon 31M 的最低门槛是一颗 CPU 核心。Gradium 的 README 列出了这些数据：在 MacBook Air M5 的单核上达到 26 倍实时，在 iPhone 16 Pro 的神经网络引擎上达到 22 倍实时，在 Raspberry Pi 5 上达到 2.3 倍实时。发布博客中的数字有所不同——单核 11.6 倍，Pi 上 3.7 倍——但每个版本的数字所描述的都是一款能握在手中的设备。

这不是一个关于质量高低的论点。通过 GPU 渲染的 48 kHz VoxCPM2 会比 24 kHz 的 Phonon 渲染听起来更好，而且理应如此。问题在于，你的产品能否负担为每个并发流配备一块 GPU。对于服务器端的配音流水线来说，可以。对于必须在飞机上运行的手机应用来说，不行。

语音设计与固定配音阵容的对比

VoxCPM2 最具辨识度的特性是音色设计：只需在文本提示中写一段括号内的描述，就能生成一个完全无需参考音频的声音。再加上可控克隆——用一小段音频确定音色、用一条风格指令确定表达方式——你便拥有了一个能够打造整套角色阵容、而不只是朗读脚本的系统。

Phonon 完全没有这些。它的 37 种英语语音是一组固定集合，自定义语音需要.safetensors文件，而不是一句描述。这是一种有意的简化：语音目录更易于审核、更易于授权，并且无法通过提示让它用名人的声音说话。对于合规敏感的部署，这种限制是一项特性。对于创意工作，它是一堵墙。

两者都采用 Apache 2.0，这会改变考量。

这正是让这一对比比 Phonon 的其他搭配更为清晰的地方。VoxCPM2 的代码和权重均采用 Apache 2.0。Phonon 31M 的权重采用 Apache 2.0，运行时则采用 MIT 或 Apache-2.0。Gradium 的 40M 检查点采用 CC BY-NC 4.0，未经协议无法用于商业产品；与之不同，上述两者都可以直接商用发布。

Gradium 自家产品系列内部的许可差异值得反复说明，因为它很容易被忽略：听起来最好的模型——Phonon 40M，Elo 为 2,117，而 31M 为 2,098——恰恰是你不能商用的那个。Apache 2.0 模型则是更小的、仅支持英语的那个。

每个的优势所在

当你需要英语以外的语言、48 kHz 输出、音色设计、声音克隆或长篇旁白，并且部署环境中已配备 GPU 时，请选择 VoxCPM2。对于多语言 TTS 研究而言，它也是更优选择，因为其检查点、技术报告和评估集均公开可用。

当音频必须在设备端生成、英语就足够、语音集可以固定，并且 64 MB 的下载量决定能否发布时，选择 Phonon 31M。游戏、无障碍工具、自助终端、浏览器功能和离线助手是它的领域。2B 模型在该领域无法企及，它也不打算这样做。

OrcaRouter 并不托管这两个模型——VoxCPM2 通过 vLLM-Omni 或本地运行时提供服务，而 Phonon 在你的硬件上运行。路由层真正发挥作用的地方在栈的上一层，也就是生成语音脚本的环节：200 多个语言模型只需一个密钥即可调用，按供应商标价以 0% 加价直通，并且当某个供应商出现故障时可自动故障转移。TTS 留在它该在的位置；文本生成则可以迁移。

下一次基准测试应当解决什么

缺失的实验显而易见，却没有人做过：两个检查点、一个测试集、一个转写模型、一个评分器，连同音频一起发布。在这一实验出现之前，诚实的立场是：VoxCPM2 是能力更强的系统，Phonon 31M 是更适合部署的系统，而 0.51 与 1.84 的 WER 比较只是方法学上的巧合，而非一项结果。

毋庸置疑的是发展趋势。到2026年10月，一个64 MB的英语模型用于生产级朗读工作是可信的，而2025年初的64 MB模型则不可能做到这一点。对于下一个发布周期，有趣的问题不是小模型能否在英语上匹敌大模型，而是小模型能否在不使规模翻倍的情况下掌握第二语言。Gradium的40M多语言检查点是首次尝试，其非商业许可表明该公司尚未决定如何销售它。