一、一个曾经理所当然的假设过去几年“做 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 RuntimeKyutai Pocket TTS 0.1B 参数专注英文用 PyTorch 量化推理两轮的实测结论是一致的RTF 稳定在 0.94-0.97 之间即生成 1 秒音频只需 0.94-0.97 秒的推理时间。这已经做到了实时。二、什么是 RTF为什么重要RTFReal-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-NanoMOSS-TTS-Nano 是 OpenMOSS 团队开源的小型 TTS 模型主打声音克隆 多语种。官方宣称~0.1B 参数支持 20 种语言用几秒参考音频就能克隆声音输出接近 CD 音质可一边生成一边播放CPU 推理的关键用 ONNX Runtime 把 PyTorch 模型转成 ONNX 格式CPU 端推理速度显著快于原生 PyTorch。我用的测试用例来自bench_speed.pyCASES[(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 TTSPocket 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. ...,}modelTTSModel.load_model()voicemodel.get_state_for_audio_prompt(alba)forname,textintexts.items():model.generate_audio(voice,text)# warm-uptimes,durations[],[]for_inrange(3):t0time.perf_counter()audiomodel.generate_audio(voice,text)elapsedtime.perf_counter()-t0 times.append(elapsed)durations.append(len(audio)/model.sample_rate)avg_t,avg_dsum(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 轮实测结果轮次输入文本音频时长推理耗时RTFrun1warm-up不计———run2短句29 字符4.64s4.77s0.97xrun3中句——0.96xrun4长句196 字符21.44s22.90s0.94xrun5中句6.48s6.78s0.96x4 轮平均———≈ 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 里直接给出的指标每个音频解码步耗时 79msmimi decoder 额外开销只有 6ms几乎可忽略。五、把两个实测放在一起看维度MOSS-TTS-NanoKyutai Pocket TTS参数量~0.1B 0.1B支持语言20 种仅英文声音克隆✅几秒参考音频❌推理方式ONNX RuntimePyTorch 量化CPU RTF 1.0x0.94-0.97x流式生成✅✅适用场景多语种、声音克隆英文场景、嵌入式两者都验证了超小参数量 TTS 在 CPU 实时推理的可行性但侧重不同如果你需要多语种 声音克隆比如做个性化的多语言助手、有声书配音MOSS-TTS-Nano 更合适如果你只需要英文 极致轻量比如嵌入式设备、浏览器内场景Pocket TTS 更合适六、为什么这件事重要过去要在产品里集成 TTS选项基本是调云 APIOpenAI、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-Nanogitclone https://github.com/OpenMOSS/MOSS-TTS-NanocdMOSS-TTS-Nano pipinstallonnxruntime numpy python bench_speed.py试 Kyutai Pocket TTSpipinstallpocket-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(faudio{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 已经从实验室玩具变成了可用产品组件。下次做技术选型时可以把它放进候选清单了。