一句提示音，其实是个服务
称重台的「请将商品放在秤台上」、自助收银的「请扫描商品条码」、排队叫号、后厨叫单、打烊前的清场提醒——门店一天要出几百到几千句声音。
这些声音通常来自语音合成服务：把一句话文本发出去，换一段音频回来播放。绝大多数门店不会去问这套东西跑在哪儿，直到某天它不响了。
云端合成在门店里的三个隐性成本
断网就哑。 这是最直接的一条。收银机能离线记账，播报却要靠网络，结果就是断网时收银员得靠喊来引导顾客。自助设备更尴尬：屏幕上写着「请扫码」，人不知道该扫哪儿。
首字延迟看网络脸色。 云端合成要走完「上传文本—排队—合成—下载音频」四步，高峰期抖动直接变成顾客面前的一段静默。自助收银前面站着一个不想多等的人，超过一秒没反应，他就会重复扫、反复放商品，反而把流程搞乱。
内容逐句出门。 播报里常带会员姓氏、消费金额、商品名。「张女士，您消费 128 元」这句话发到外部服务，等于把门店的经营切片一句一句送出去。单条不算什么，一天几千条就是完整的客流与客单画像。
本地做的代价也要算清
把合成搬到设备上，不是免费换来的：
- CPU 被占。 收银机本来就在跑收银软件、打印、界面渲染。合成占的是同一颗 CPU，高峰时段会互相拖。
- 音质要打折。 端侧模型的体积受限，为了跑得动，采样率和自然度通常要让一步。
- 更新和维护变复杂。 云端换个音色是后台操作，本地要发版本、要到店、要一台一台更新。
- 多语种、多音色覆盖不全。 一家在旅游区、有外籍顾客的店，端侧模型很难备齐。
划算的做法通常是折中
真实门店里，播报内容可以切成两半：
固定话术——「请刷卡」「请取走小票」「请将商品放在秤台上」。这些句子全年不变，完全可以提前生成音频文件放进设备，播放时直接读文件，一次推理都不用。
变量部分——金额、商品名、会员姓氏、排队号码。这部分必须实时合成，但句子短、字数少。
按这条线切开之后，本地真正要实时合成的量通常只剩一小部分，CPU 压力和对音质的要求都降下来了。再配上流式合成（按短片段边合成边播，不等整句算完），首字延迟可以压到人的感知阈值以内。
这也是为什么有些设备的播报听起来「有点机械但很快」，另一些「好听但慢半拍」——它们在这个取舍上站的位置不同。
什么店值得往本地搬
值得考虑的情况：
- 断网频率高（老旧商圈、地下层、临时用电的摊位）。
- 播报量大，尤其是自助设备和多台称重台同时在跑的店。
- 播报里带顾客信息（会员称呼、金额），对数据出门有顾虑。
- 自助设备多、现场没人守着，一旦没声音，顾客不会去问店员，只会放弃。
不值得折腾的情况：
- 一天播几十句的小店，云端按次调用的钱可以忽略。
- 播报用于品牌宣传、广告配音，对音质的要求高于实时性。
- 有多语种、多音色长尾需求的场景。
验收清单
真要上本地合成，这几条比听演示有用：
- 拔网线播一遍。 断网后应该照常出声；如果静音或报错，说明它其实在等云端。
- 连续播一小时。 记录第 1 分钟和第 60 分钟的首字延迟。无风扇设备跑久了会降频，播报是最先暴露的地方（原理见 收银机为什么越跑越烫、越跑越慢）。
- 在真实噪声下听。 店里本来就有抽风机、人流、广播。演示间里 48kHz 的细腻，在收银台前听不出来。别为听不出的指标付钱。
- 同时播两路。 两台秤、一台自助机同时出声，看会不会互相卡住。
- 克隆音色要文件。 如果供应方用某位员工或主播的声音做音色，要拿到书面授权，并确认合同结束后能真正删除——模型文件里带的是这个人的声纹特征（延伸阅读见 端侧语音合成）。
一句话结论
判断要不要搬回本地，看的不是音质，是两件事：一天播多少句，一个月断几次网。 这两条成立，本地合成省下的不只是钱，还有顾客站在收银台前那几秒的耐心。
火眼识别提供端侧视觉引擎与设备管理平台，相关方案见 火眼识别官网。