一、一个曾经理所当然的假设
过去几年，“做 TTS"几乎等于"买 GPU"或"调云 API”。
不管是 OpenAI TTS、ElevenLabs，还是开源的 Bark、Suno-Bark、VITS，本地部署的标配都是一张至少 8GB 显存的显卡。推理太慢、显存不够、batch size 撑不起来——这些问题让"在 CPU 上跑 TTS"听起来像天方夜谭。
但最近几个月情况变了。模型压缩、蒸馏、量化、CPU 推理框架（ONNX Runtime、GGML 等）的成熟，加上大量"小到能在浏览器里跑"的模型发布，让我好奇一个具体的问题：
0.1B 参数级别的开源 TTS，能不能在笔记本 CPU 上做到实时？
我选了 2 个代表性的项目实测：
- MOSS-TTS-Nano：~0.1B 参数，支持 20 种语言 + 声音克隆（用 ONNX Runtime）
- Kyutai Pocket TTS：< 0.1B 参数，专注英文，用 PyTorch + 量化推理
两轮的实测结论是一致的：RTF 稳定在 0.94-0.97 之间，即生成 1 秒音频只需 0.94-0.97 秒的推理时间。这已经做到了"实时"。
二、什么是 RTF，为什么重要
RTF（Real-Time Factor）的定义很简单：
RTF = 推理耗时 / 生成音频时长- RTF < 1.0 → 推理比播放快，可以实时合成
- RTF = 1.0 → 刚好赶上播放速度
- RTF > 1.0 → 推理慢于播放，会卡顿或堆积延迟
对产品来说，RTF < 1.0 是"实时合成"的硬门槛。比如你想做一个语音助手边听边播、或者给视频自动配音，RTF 必须在 1.0 以下。
过去小模型 TTS 的 RTF 通常在 2-5 之间（要靠批处理 + GPU 才能压到 1 以下）。这次的实测结果显示，0.1B 量级的模型在 CPU 上单条推理就能跑进 1.0 以内——这是一个量级的变化。
三、第一个实测：MOSS-TTS-Nano
MOSS-TTS-Nano 是 OpenMOSS 团队开源的小型 TTS 模型，主打"声音克隆 + 多语种"。
官方宣称：
- ~0.1B 参数
- 支持 20 种语言
- 用几秒参考音频就能克隆声音
- 输出接近 CD 音质
- 可一边生成一边播放
CPU 推理的关键：用 ONNX Runtime 把 PyTorch 模型转成 ONNX 格式，CPU 端推理速度显著快于原生 PyTorch。
我用的测试用例（来自bench_speed.py）：
CASES=[("zh_short","今天天气真不错，我们一起去公园散步吧。"),("en_short","This little open source model can clone your voice from just a few seconds of audio."),("zh_long","声音克隆技术正以惊人的速度走进普通人的生活……（约 200 字）"),]三个用例覆盖短中文、短英文、长中文——日常 TTS 场景基本都在这个长度区间。
实测结果：在我这台普通笔记本上（Intel 处理器），三个用例都跑出了稳定的 RTF < 1.0。具体数字这里不展开（不同机器会有差异），但趋势是一致的：0.1B 参数 + ONNX Runtime + CPU 已经够用。
最关键的是：整个链路不需要 GPU，不需要云 API，离线就能跑。
四、第二个实测：Kyutai Pocket TTS
Pocket TTS 是 Kyutai Labs 出的更小版本 TTS，主打"超轻量级"。
参数规模在 0.1B 以下，专注英文场景（不支持中文）。但它的设计目标更激进——希望做到浏览器内、嵌入式设备上也能跑。
我用了一个 23 行的 Python 脚本（bench.py）跑 5 轮实测：
texts={"short (29 chars)":"Hello, this is a speed test.","medium (103 chars)":"Pocket TTS is a lightweight text to speech model...","long (196 chars)":"The quick brown fox jumps over the lazy dog. ...",}model=TTSModel.load_model()voice=model.get_state_for_audio_prompt("alba")forname,textintexts.items():model.generate_audio(voice,text)# warm-uptimes,durations=[],[]for_inrange(3):t0=time.perf_counter()audio=model.generate_audio(voice,text)elapsed=time.perf_counter()-t0 times.append(elapsed)durations.append(len(audio)/model.sample_rate)avg_t,avg_d=sum(times)/3,sum(durations)/3print(f"{name:22s}audio={avg_d:5.2f}s gen={avg_t:5.2f}s RTF={avg_t/avg_d:4.2f}")5 轮实测结果
| 轮次 | 输入文本 | 音频时长 | 推理耗时 | RTF |
|---|---|---|---|---|
| run1 | warm-up（不计） | — | — | — |
| run2 | 短句（29 字符） | 4.64s | 4.77s | 0.97x |
| run3 | 中句 | — | — | 0.96x |
| run4 | 长句（196 字符） | 21.44s | 22.90s | 0.94x |
| run5 | 中句 | 6.48s | 6.78s | 0.96x |
| 4 轮平均 | — | — | — | ≈ 0.96x |
几个有意思的发现
1. 长度对速度影响极小。run4 是 run5 的 3.3 倍音频长度，但 RTF 只差 0.02。这意味着模型基本是"匀速"生成——不会因为句子变长就显著变慢。
2. warm-up 之后基本没有波动。5 轮实测的 RTF 都在 0.94-0.97 之间，4 轮平均 0.96x，非常稳定。这对产品级部署很重要——不会出现"突然变慢"的尖刺。
3. 平均生成步耗时 79ms。这是看 log 里直接给出的指标，每个音频解码步耗时 79ms；mimi decoder 额外开销只有 6ms，几乎可忽略。
五、把两个实测放在一起看
| 维度 | MOSS-TTS-Nano | Kyutai Pocket TTS |
|---|---|---|
| 参数量 | ~0.1B | < 0.1B |
| 支持语言 | 20 种 | 仅英文 |
| 声音克隆 | ✅（几秒参考音频） | ❌ |
| 推理方式 | ONNX Runtime | PyTorch + 量化 |
| CPU RTF | < 1.0x | 0.94-0.97x |
| 流式生成 | ✅ | ✅ |
| 适用场景 | 多语种、声音克隆 | 英文场景、嵌入式 |
两者都验证了"超小参数量 TTS 在 CPU 实时推理"的可行性，但侧重不同：
- 如果你需要多语种 + 声音克隆（比如做个性化的多语言助手、有声书配音），MOSS-TTS-Nano 更合适
- 如果你只需要英文 + 极致轻量（比如嵌入式设备、浏览器内场景），Pocket TTS 更合适
六、为什么这件事重要
过去要在产品里集成 TTS，选项基本是：
- 调云 API（OpenAI、ElevenLabs、Azure 等）：成本按字符/分钟计，量大之后账单不便宜；数据出境合规有时也麻烦
- 自己部署 GPU 服务：要买卡、要运维、要处理高可用，单卡并发能力有限
现在有了 0.1B 量级的 CPU 实时 TTS，第三个选项出现了：离线、本地、零 API 成本、单机可服务大量并发。
具体到产品形态，几个突然变得可行的场景：
- 隐私敏感的本地语音助手：医疗、法律、心理咨询等场景，语音数据不能出境，本地 TTS 成了唯一选项
- 嵌入式 / / IoT 场景：智能音箱、车载系统、工业设备不一定有 GPU，但有 CPU
- 低延迟实时配音：视频会议字幕自动配音、直播字幕语音化，CPU 实时推理能把延迟压到几百毫秒级
- 大规模批处理：批量给视频/有声书配音，不花钱调云 API 也不用占 GPU
七、还差什么？
虽然实测结果是乐观的，但离"产品级 TTS"还有几道坎：
1. 长文本稳定性。run4 是 196 字符（大约 20 秒音频），更长的文本（比如几小时的有声书）会出现什么情况？长上下文下 RTF 会不会飙升？需要更多实测。
2. 音质上限。0.1B 参数的音质天花板肯定比不上 1B+ 的 SOTA 模型。声音克隆质量、多语种发音准确性、情感表现力都有差距。如果对音质要求极致，还是得上大模型。
3. 工程化。模型自动从 HuggingFace 拉取、错误处理、流式接口对接、音频编码格式兼容——这些工程化细节每个都得自己踩一遍坑。
4. 量化精度损失。ONNX Runtime 和量化都会引入一定精度损失，需要评估对最终音质的影响。
八、怎么自己试一下
如果你也想验证一下这个结论，最快的方式：
试 MOSS-TTS-Nano
gitclone https://github.com/OpenMOSS/MOSS-TTS-NanocdMOSS-TTS-Nano pipinstallonnxruntime numpy python bench_speed.py试 Kyutai Pocket TTS
pipinstallpocket-tts python-c" from pocket_tts import TTSModel import time model = TTSModel.load_model() voice = model.get_state_for_audio_prompt('alba') text = 'Hello, this is a speed test.' # warm-up model.generate_audio(voice, text) # 实测 times = [] for _ in range(3): t0 = time.perf_counter() audio = model.generate_audio(voice, text) elapsed = time.perf_counter() - t0 times.append(elapsed) audio_dur = len(audio) / model.sample_rate avg_t = sum(times) / 3 print(f'audio={audio_dur:.2f}s gen={avg_t:.2f}s RTF={avg_t/audio_dur:.2f}') "注意：首次运行会从 HuggingFace 下载模型权重（几百 MB），需要网络通畅。
九、结论
回到开头的假设——“做 TTS 一定要 GPU”——这个假设在 2026 年已经不再成立。
0.1B 参数级别的开源 TTS 模型，已经可以在笔记本 CPU 上跑出 RTF < 1.0 的实时推理速度。两个不同技术路线（ONNX + 声音克隆 vs PyTorch 量化 + 极致轻量）的实测都得出了相同的结论。
这不是某一个团队的突破，而是模型蒸馏、量化、CPU 推理框架、流式解码几个技术线在同一年发生共振的结果。
下一步值得关注的方向：
- 更小的模型：0.05B、甚至 10M 参数级别的 TTS 已经在一些研究里冒头
- 浏览器内推理：配合 WebGPU / WASM，未来 TTS 可能完全跑在浏览器里
- 多模态融合：同一个 0.1B 模型同时做 ASR + TTS + 简单对话，进一步压低部署成本
但有一点是确定的：CPU 实时 TTS 已经从"实验室玩具"变成了"可用产品组件"。下次做技术选型时，可以把它放进候选清单了。
