CPU 跑 TTS 实测：Kyutai Pocket TTS 值不值得上

一、事情是这样的

最近 Reddit 上有人把 Kyutai 刚放出来的 Pocket TTS 和 Kokoro、Supertonic、Inflect-Nano 拉到一起，跑了一轮纯 CPU 环境的 benchmark。数据挺有意思——180 次跑测、六种文本长度、UTMOS 客观打分——基本把"小模型 TTS 在 CPU 上到底能不能用"这件事讲清楚了。

背景先交代一下。Kyutai 前段时间（10 月底）扔出来的 Pocket TTS 是个 100M 参数的流式 LM，跑在自家 Mimi neural audio codec 上。号称不用 GPU 就能实时合成，还支持声音克隆。听着像画饼，但架构上确实和市面上大多数 TTS 不一样——不是 StyleTTS2 那一挂的非自回归 vocoder 路线，而是把音频当 token 序列，用语言模型的方式一段段吐出来。

这就带来一个很直接的问题：LM 式的流式生成，在 CPU 上还能不能扛住实时？这也是这次测评最值得看的点。

二、测试环境和对比对象

跑测的机器很朴素，Intel Xeon 8272CL、4 核、15.6GB 内存，CUDA 环境级别禁掉，ONNX session 强制绑 CPUExecutionProvider。别指望这是什么发烧配置——就是一台普通的云服务器 vCPU。

参赛选手：

• Kokoro 82M：StyleTTS2 血统，PyTorch 和 ONNX Runtime 两个版本都测了。开源 TTS 圈的老熟人。
• Supertonic 3：Vector Estimator 骨架的 flow-matching 模型，分别跑 2 步和 5 步两种配置。
• Inflect-Nano-v1：4.6M 参数的 FastSpeech 风格模型，属于"能跑就行"那种极致轻量。
• Pocket TTS：Kyutai 新出的 100M 参数流式 LM，本次的主角。

六种文本长度从 12 字符一路怼到 1712 字符，每格跑 5 次记时（丢弃一次 warmup）。每段合成出来的 WAV 用 UTMOS（utmos22_strong）打分，拿到一个客观 MOS。这套方法论比"我自己听着不错"要靠谱得多。

三、数据摆出来看

聚合结果里，几个关键数字（RTF 越低越快，UTMOS 越高越好）：

| 配置 | 平均 RTF | UTMOS | |---|---|---| | Supertonic 3 (2-step) | 0.121 | 1.53 | | Inflect-Nano-v1 | 0.145 | 3.48 | | Supertonic 3 (5-step) | ~0.25 | ~1.6 | | Kokoro (ONNX) | ~0.3-0.4 | ~3.9 | | Pocket TTS | 相对最高 | 最高 |

（原帖表格有截断，后面几行是根据讨论区补的近似值）

先说 Supertonic。RTF 0.121 什么概念？1 秒的音频只要 121 毫秒算完，快得离谱。但代价是 UTMOS 1.53——这个分数基本就是"能听出来是人话但难受"的水平。2-step 到 5-step 音质没有质变，属于花了两倍算力买了个心理安慰。

Inflect-Nano 是这次测试的意外之喜。4.6M 参数，RTF 0.145，UTMOS 却干到 3.48。参数量比对手小一个数量级，音质反而甩开 Supertonic 一大截。FastSpeech 那套老架构在极小模型上的效率是真扎实。

Kokoro 依然稳。ONNX 版本 RTF 在 0.3-0.4 区间，UTMOS 接近 3.9，属于"没有短板"型选手。这也解释了为什么过去一年 Kokoro 在开源 TTS 项目里被塞进各种 pipeline——它就是那个不用你操心的默认选项。

Pocket TTS 的定位更特殊。UTMOS 拿了最高分，但 RTF 是几个里面最高的，尤其在短文本上劣势明显。原因也不难想——LM 式自回归的启动成本本来就大，Mimi codec 每帧都要走一次 forward，短句体现不出流式优势，长句才回本。

四、Pocket TTS 到底能不能用？

这是开发者最关心的问题。

先说结论：能用，但要看你的场景。

如果你做的是实时对话（agent、语音助手），Pocket TTS 的流式特性是有价值的——它不需要等整句合成完再播，可以边生成边推。100M 参数、纯 CPU 实时，这个组合在今年之前是不敢想的。Kyutai 技术报告里跟 F5-TTS、Chatterbox Turbo、Kokoro 对比 WER 也不落下风，声音克隆能力更是这几个里唯一原生支持的。

但如果你只是批量合成播报稿、有声书这种离线任务，Pocket TTS 的 RTF 劣势就没必要忍了。Kokoro 更省事，Inflect-Nano 更省钱。

还有个细节值得提一句：这次测试是 4 核 Xeon，如果换到 M 系列 Mac 或者 AVX-512 更全的桌面 CPU 上，Pocket TTS 的表现会更好——LM 式推理对 SIMD 指令集敏感度更高。云上 vCPU 是它的下限场景，不是典型场景。

五、几个容易被忽略的坑

跑过这类小 TTS 的应该都踩过：

1. ONNX Runtime 版本敏感。Kokoro 的 ONNX 版和 PyTorch 版之间能差出 30%+ 的 RTF，主要是算子融合有没有覆盖到。跑生产之前建议自己 benchmark 一遍，别信官方 README。

2. UTMOS 不是万能。这个分数对韵律和长时结构不敏感——一个句子里字都念对了但重音全错，UTMOS 可能还给你 3.8。真上线前还是得人工听一批 badcase。

3. 流式 TTS 的"首包延迟"比 RTF 更重要。RTF 0.3 但首包 800ms，和 RTF 0.5 首包 200ms，对话体验完全是两回事。这次测评没细拆首包延迟，是个小遗憾。

4. 中文场景要单独验证。以上四款里，Kokoro 有中文支持但不算强，Pocket TTS 目前主要面向英语和法语，中文能力还没验证过。国内落地要谨慎，或者干脆看 CosyVoice2、Fish Speech 这类专门做中文的。

六、行业里的位置

把视角拉远一点看。2026 年的小模型 TTS 已经有点"内卷"了：

• SiliconFlow 那边主推的 CosyVoice2-0.5B，流式模式 150ms 延迟，中文方言全都能上；
• Fish Speech 1.5 在 TTS Arena 上 ELO 1339，多语言质量顶级；
• IndexTTS-2 主打精确时长控制和零样本克隆；
• 再加上今天讲的这几个 CPU 端选手。

路线分得很清楚：GPU 端拼质量和情感表达，CPU 端拼延迟和成本。Pocket TTS 是 CPU 端目前唯一把 LM 流式路线跑通的样本，这个方向短期内应该还会有更多玩家进来——尤其是端侧 agent 火起来之后，声音这一环不能再依赖云端 API 了。

顺带一提，OpenAI Hub 目前主要接的是各家云端 TTS（含 OpenAI TTS、Gemini 的语音合成等），如果你懒得自己部署 Kokoro/Pocket TTS，可以直接用 API 调，一个 Key 走通所有模型，国内直连不用挂梯子。但如果你的场景对隐私、延迟、成本任意一项敏感，本地跑这些小模型仍然是更优解——这不是矛盾，是分工。

七、给开发者的选型建议

简单粗暴地总结一下：

• 要实时对话、要声音克隆、能接受 100MB 级别模型：上 Pocket TTS。
• 要综合稳、不折腾：Kokoro ONNX，闭眼选。
• 极端资源受限（边缘设备、嵌入式）：Inflect-Nano，4.6M 参数是真的能塞进去。
• 要中文、要方言、能上 GPU 或者接受云 API：CosyVoice2 / Fish Speech / IndexTTS-2 三选一。
• Supertonic：除非你只关心 RTF 不关心音质，否则可以跳过。

最后说句题外话。TTS 这个赛道过去一年的进步比想象中快——一年前 CPU 上跑 TTS 还是要么慢要么难听二选一，现在已经能在 4 核云服务器上做到 RTF 0.15、MOS 3.5+。再过一年，端侧 agent 的语音输出可能就不是问题了。这个节奏挺让人期待的。

参考来源

• CPU TTS benchmark with UTMOS MOS scoring (Reddit r/MachineLearning) — 本文核心数据来源，原始 benchmark 帖
• Kyutai Pocket TTS 讨论 (Reddit r/LocalLLaMA) — Pocket TTS 发布时的社区讨论，含端到端延迟实测反馈
• 轻量级 TTS：MeloTTS 纯 CPU 跑语音合成指南 (知乎) — 中文语境下的 CPU TTS 方案对比参考