这台机器的GPU是GTX 1080 Ti,专门留给本地大模型做推理。语音合成这一段完全没碰GPU——全程CPU计算,而且换上一颗12年前发布的Intel酷睿i7-4770K,合成同一段测试文本也只要4.7秒。这不是极限压榨出来的成绩,是Kokoro这个只有82M参数的开源TTS模型,默认配置下随手跑出来的结果。
部署方式很直接:Kokoro-FastAPI容器,一条命令拉起,自带语音模型,还兼容OpenAI的Speech API,接入现成程序几乎不用改代码。三颗CPU测过同一段文本,耗时从4.7秒到1.5秒不等。
| CPU | 发布时间 | 合成耗时 | 说明 |
|---|---|---|---|
| Intel i7-4770K | 12年前 | 4.7秒 | 老平台照样能用 |
| Apple M2 Pro | 现役 | 4.5秒 | 和老平台相差无几 |
| AMD Ryzen 7 8745HS | 现役 | 1.5秒 | 明显更快 |
这组数字本身不算戏剧性,真正值得追问的,是一个82M参数的小模型凭什么把音质做到这个水平,以及"主要面向英语"这类描述到底准不准。
小而美不是玄学,是账本算出来的
Kokoro的架构是StyleTTS2加iSTFTNet的组合,许可证是Apache-2.0,商用不受限。训练数据只有几百小时音频——比起动辄几万小时语料的大型TTS,这个体量小得不像话。官方给出的训练成本大约是1000个A100 80GB GPU小时,换算下来是千元美金级别。
这才是"小而美"的真正含义:不是拿质量换速度,而是用架构效率把训练成本压下去,用远低于大厂TTS的投入,做出一个能在CPU上实时合成的模型。这笔账透明到可以在模型卡上直接查——它不是运气,是路径选对了。
"主要面向英语"?没那么绝对
官方语音清单VOICES.md列出54个语音,覆盖9种语言/方言。英语系(美式加英式)合计28个,数量最多,但剩下26个语音铺在日语、普通话、西班牙语、法语、印地语、意大利语、巴西葡萄牙语七种语言上。英语占比刚过一半,离"主要面向英语"这种笼统印象还有距离。真正的差距不在数量,在成熟度——英语语音训练最久、调优最细,非英语更像是覆盖面的补齐。
默认配置不是最优配置
想要更低延迟,Kokoro-FastAPI的官方文档给了答案:换成response_format="pcm"并开启HTTP流式传输,而不是默认的MP3编码。CPU做语音合成本身就要花力气,MP3编码是额外的一层开销——这部分延迟跟模型能力无关,纯粹是集成方式的选择。也就是说,几秒钟的benchmark数字里,有一截其实可以直接抠掉。
- 提醒.默认容器配置未必是最优路径,生产部署前值得先测一遍PCM+流式传输的延迟差。
Kokoro到底排第几
把Kokoro放进本地TTS的坐标系里看,位置没那么梦幻。专攻CPU速度的Piper跑得更快、也更省;要多语言和音色克隆,Coqui的XTTS v2支持16种语言,克隆能力Kokoro完全不具备;真要音质天花板,StyleTTS2本身表现更好,只是离不开GPU。Kokoro更像是在三边里挑出的一个折中点——CPU够用、质量够好、部署够简单,但没有一项是第一名。
- 结论.Kokoro没有解决多语言克隆,也没有解决高并发下的排队问题——Kokoro-FastAPI的GitHub issue区这两条还开着,这才是接下来该盯的地方。
这也是为什么它值得写、但不必神化。它证明了一件事:本地大模型配本地语音合成的全离线管线,已经不需要拿显卡去赌,普通CPU就能撑住实时对话的延迟。
便宜的模型不等于将就的模型,这次账本是算清楚的。
12年前的CPU能撑起这套语音合成,说明的不是Kokoro有多神,而是"本地TTS必须靠GPU"这件事,已经先一步过时了。