端侧 TTS 和云端 TTS 怎么选

2026-08-24

语音合成放哪儿跑，是个部署决策，不是技术优劣之争。 端侧和云端各有一组硬性代价，选错的后果通常不是”效果差一点”，而是整个方案在你的场景里根本立不住。

这篇不给结论式的推荐，只把五个维度摊开，让你能对照自己的场景找出那条硬约束。

一句话结论

要离线可用、或文本本身敏感 —— 端侧。这不是省钱选项，是唯一选项。
要大量音色、要高音质、要随时换模型 —— 云端。端侧装不下也更不动。
固定话术多、个性化内容也多 —— 混合。这是多数成熟产品的实际形态。
原型验证期、量还很小 —— 先云端。别一上来就为端侧适配一堆芯片型号。

五个维度的取舍

维度	端侧	云端
隐私	待合成文本不出设备	文本需传输到第三方
网络	离线可用	依赖网络
音质与音色数量	受设备资源限制，音色装不了几个	上限更高，可提供大量音色
成本结构	一次性投入	按用量持续支出
更新方式	需随 App 分发	服务端即时生效

这张表的用法：从上往下扫，找到第一行”这条我让不了”的，答案基本就定了。

隐私：TTS 的风险和 ASR 不一样

这是最容易被想当然的一条。很多人把 TTS 的隐私问题直接套用端侧语音识别的那套说法，其实两者的风险面方向相反。

ASR 上传的是用户说出来的话——音频里带着声纹、环境音、说话内容，风险很直观，所有人都能立刻意识到。

TTS 上传的是待朗读的文本——看起来只是一串字符，没有生物特征，感觉安全得多。但真正要读出来的往往正是这些内容：

医疗类应用要朗读检查结果与诊断建议
银行与账单类应用要播报余额、订单号、交易明细
消息辅助类应用要读出私信与聊天记录
无障碍阅读工具会朗读用户屏幕上的任何东西

也就是说，TTS 请求里的文本，恰恰是这个场景中最值得被读出来、也最值得被保护的那部分内容。 一句”我们只传了文本，没传音频”并不构成豁免。

判断方法很简单：把你要送去合成的那批文本导出来看一眼，如果里面有你不愿意让第三方留存的东西，隐私这一行就是硬约束。

网络：不是慢一点，是不工作

云端 TTS 断网就是不出声。对某些形态的产品，这等同于坏了：

车载导航在隧道里、户外设备在无信号区、工厂车间的语音提示、地铁上的有声读物。这些场景里网络质量本来就不可控，“平时能用、偶尔哑掉”在体验上比”一直是本地音”要糟。

还有一类容易被忽略的：播报的即时性要求。按键反馈音、操作确认、告警提示这类短提示，走一趟网络往返总会有抖动，而端侧合成不受网络状况影响。首包延迟为什么比总耗时更重要，流式合成那篇讲得更细。

音色数量：TTS 独有的一个维度

这条在 ASR 那边不存在，是 TTS 特有的。

识别模型装一个就够用，但发音人是要一个一个装的。产品上一旦提出”让用户挑喜欢的声音”，音色数量就直接变成设备资源问题——端侧装不下几十个发音人，能带上两三个已经算宽裕。

同一条逻辑也作用在音质上。端侧的声学模型与声码器都要在设备资源约束下选型，可用的方案集合本身就更窄；云端没有这个限制，可以上更重的模型。

所以碰到这类需求，基本就得往云端走：多语种多口音、给不同角色配不同声线、按用户偏好定制音色、需要细腻的情感与语气表现。

成本结构：不是”哪个更便宜”

端侧是一次性投入：模型选型、量化适配、多芯片验证、包体积谈判，都是前期的人力成本，上线后不随调用量增长。

云端是按用量持续支出：用量涨，成本跟着涨。

真正要注意的是别把这两句话读成”量大就该上端侧”。端侧的一次性投入是按目标设备型号累加的，设备越杂，适配成本越高；而云端的持续支出在用量还小的时候几乎可以忽略。验证期用云端跑通产品逻辑，规模起来之后再评估端侧，是更稳的顺序。

另外，缓存策略能在不改部署形态的前提下砍掉相当一部分云端调用——固定话术命中缓存就不必重复合成。这一招通常应该在考虑迁端侧之前先做掉。

更新方式：修一个 bug 要多久生效

假设线上发现某个专有名词读错了。

云端：改前端词典、替换模型、服务端发布，所有用户立刻拿到修复。

端侧：改完要发新版本、等应用商店审核、等用户升级。生效周期以周甚至月计，而且线上永远同时跑着多个模型版本。排查用户反馈时，第一件事是先问清对方装的是哪个版本。

这里有个实用的缓解办法：把前端处理和模型分开更新。 多音字词典、数字读法规则、停顿标注这些前端环节的配置，如果做成可远程下发的数据文件而不是编译进包里，大部分读错类问题就能绕开发版流程直接修掉。这是端侧方案值得提前埋的一个口子。

混合策略：多数产品的真实答案

上面五行很难同时满足，所以成熟产品普遍不做单选题：

固定话术走端侧，保证离线可用与即时响应——欢迎语、菜单提示、错误播报、告警音。 复杂或高质量需求走云端——长文朗读、多音色切换、需要情感表现的内容。

值得注意的是，这和缓存是同一个思路的两种形态：都是把”高频且不变”的部分预先固化下来，只让”低频且多变”的部分吃实时算力。缓存把它固化在服务端或本地存储里，端侧模型把它固化在设备的合成能力里。两者可以叠加使用。

落地时有两个细节要提前想：一是降级路径，网络不可用时端侧要能接管，切换过程中的音色差异用户是能听出来的；二是一致性，端云两侧的发音人尽量选相近的，否则同一段播报里前后半句音色不同，比全程用端侧音还突兀。

端侧的落地面有多广

值得说明的是，端侧不再是个实验性方向。以 sherpa-onnx 为例，它自述基于 onnxruntime、无需联网，同时提供 STT 与 TTS 能力，README 列出的运行目标覆盖 x86、x86_64、32 位与 64 位 ARM、RISC-V、RK NPU、Ascend NPU，以及 Android、WearOS、iOS、HarmonyOS、Raspberry Pi、Windows、macOS、Linux。

Piper 自述为快速的本地神经网络 TTS 引擎，仓库地址是 https://github.com/OHF-Voice/piper1-gpl（注意旧的 rhasspy/piper 已归档，别再用）。

这份清单本身就是结论：端侧 TTS 的工具链已经铺到手表、国产 NPU 和 RISC-V，选型时它是个成熟的工程选项，不是权宜之计。

一个必须提醒的点：Piper 的许可证是 GPL-3.0，和常见的 MIT / Apache-2.0 项目在传染性上不是一回事。如果你打算把它用在闭源产品里，请自行查阅其 LICENSE 全文并咨询法务，本文不提供任何法律结论。

常见问题

问：端侧 TTS 是不是一定比云端难听？

不能这么下结论。端侧受设备资源约束，可选方案更窄，上限确实低于云端，但对固定话术这类需求，端侧完全能做到够用。真正该问的不是”哪个更好听”，而是”你的场景需要多好听”。播报菜单和朗读有声书，标准差得远。

问：混合方案是不是要维护两套内容？

某种程度上是。端云两侧的前端处理规则（多音字、数字读法、停顿）要尽量保持一致，否则同一句文本在两边读法不同，用户会觉得系统很不稳定。建议把这套规则做成单一数据源，端云共用同一份配置。

问：先做哪边？

除非隐私或离线是硬约束，否则一般先云端。云端能让你快速验证产品逻辑、试各种音色、拿到真实的文本分布数据——这些数据反过来正好告诉你哪些话术值得固化到端侧。反过来先做端侧，很容易在还不知道需求边界的时候就把资源花在适配上。