朗读与 AI 语音

离线 AI 语音为什么重要

很多年里，好的合成语音都意味着把你的文本送到别人的服务器上。对一个段落而言，这笔交换是公平的。而对一本要读三周的书来说，这就是另一笔账了；一个不起眼的技术转变，已经悄悄让它变得不再必要。

一部小说是八到十二小时的语音，大约五十万个字符。这个数字就是全部论据，所以值得先在它上面停一停。

一、成本不再隐形

云端文字转语音按字符计费。放到一本书的规模上，这不是四舍五入的误差：这正是建立在它之上的每一项服务都卖订阅、而不是卖一次买断的原因。你可以只要还在读就一直按月付费，也可以把模型跑在自己已有的硬件上，按小时的费用为零。

这不是在说订阅有错。这是在说：在所有活动里，唯独阅读不该挂着一个计价器。

要念出你的文本，云服务必须先收到你的文本。对一篇文章而言无关紧要。对一座书库而言，那是一份关于你读了什么、按什么顺序、在一天的什么时候、读到哪里的记录。阅读史的暴露程度异乎寻常：健康、信仰、政治、丧亲，以及上个月你悄悄查过的一切。

而且不只是书。人们会把合同、体检报告和未发表的书稿丢进朗读工具。设备本地朗读意味着这些内容从不离开手机，这是任何隐私政策都比不上的保证。

地铁、飞机、乡间公路，以及每九十分钟就要重新登录一次的酒店 Wi-Fi。住在你设备上的声音，无论满格还是无信号，都在同一秒开始。云端语音则要缓冲、在信号边缘卡顿，到了万米高空干脆停摆。

还有一个更细微的版本：设备本地引擎可以提前生成接下来的几段，于是章节切换毫无代价。它成功时没人注意；它失败时人人都注意。

诚实的说法是：本地生成语音耗的是处理器，流式播放耗的是射频。两者都不免费。实际情况是，持续联网通常比一个小而高效的模型更费电，而本地朗读完全不用移动流量；对长时间收听来说，这才是更大的那个数字。

模型的重量在这里很关键。像 Piper 这样的轻量引擎几乎察觉不到；像 Kokoro 这样较重的会更吃芯片，在旧手机上会体现在续航里。在两者之间做选择是一个真实的决定，我们在Piper 与 Kokoro里谈过。

云服务会变。价格上调、免费额度关闭、API 被弃用、公司被收购。而躺在你应用存储里的语音模型没有这些失效模式：五年后它读给你听的样子，与今天一模一样，无论当初启发它的那项服务是否还有人维护。

对于一款人们会用上好几年的阅读应用，这份稳定性和音质一样值钱。

这一切在不久之前都还做不到，值得把原因说准。神经语音模型过去需要一个数据中心。两件事改变了它：一是用少得多的参数就能产生好语音的架构，二是手机芯片在这类工作上真的变快了。

Piper 出自开源语音助手的世界，每个音色的模型都很小，强调速度和语言覆盖。Kokoro 走的是另一条路，把更多容量花在结果听起来有多像真人上，同时仍小到能在手机上跑。两者合在一起，覆盖了读者需要的大部分场景；而且它们都是开放的，独立应用才有可能把它们装进来。

由此得出的结论是：读一篇临时的文章，谁好听用谁。而对你的书库来说，声音应当住在书所住的地方。

Lectern 同时内置两个引擎，检测你打开的书的语言，推荐匹配的声音，下载一次，此后再也不需要网络。正在朗读的句子会高亮以便你跟读，朗读时屏幕保持常亮，而整条链路上任何位置都没有账号。

重点不在于“离线”是一项功能。重点在于：一本属于你的书，由一个跑在你自己设备上的声音读给你听，没有谁在做记录，这就是阅读在变成一项服务之前的样子。

离线语音和云端语音一样好吗？

接近，但不相同。最好的托管模型仍然更有表现力。不过就连续数小时的朗读而言，如今设备本地的神经语音（比如 Kokoro）已经足够舒服，多数听众不再留意差别。

一个语音要占多少存储？

轻量引擎通常每个语音几十兆字节，较重的更多。你只需下载自己会读的语言，而且只下载一次。

本地朗读费电吗？

它用的是处理器而不是射频。在长时间收听中，这通常与流式播放持平或更好，而且完全不用移动流量。需要留意的情形是旧手机上跑较重的模型。

为什么多数应用还在用云端？

因为那样更省事：一次 API 调用，任何设备都得到同样的声音。要把跑在手机上的模型装进应用，意味着打包、更新，并在大量机型上测试。

继续阅读

Piper 与 Kokoro，离线、无订阅、不上传。朗读时还能跟着读。