用户评判一款对话玩具或陪伴机器人，只需要十秒钟，标准只有一条：说完话之后，它沉默了多久。

大约 700 毫秒以内，像对话；超过 1.5 秒，评价就是”卡""笨""坏了”。中间没有过渡地带。

时间不是花在大模型上

多数品牌方以为延迟来自云端模型。实际上，请求发出去之前，预算已经被设备自己花掉大半。

一台对话机器人从听到说话到开口回答，要经过：唤醒词检测 → 断句（判断你说完了没有）→ 降噪 → 语音识别 → 网络往返 → 大模型生成 → 语音合成 → 播放。

前四步全部发生在设备本地，它们每多耗一毫秒，留给模型的就少一毫秒。断句是重灾区：判断太急，孩子话说一半就被打断；太保守，光确认说完就吃掉半秒。

所以延迟是个硬件问题

要把本地链路压进两三百毫秒，靠端侧算力。目前的主流做法是带 NPU 的应用处理器——按”哪些必须留在本地”选 0.5 到 16 TOPS——唤醒、断句、降噪、语音识别全在设备上跑完，只把理解和生成交给按市场选定的云端大模型。

这就是为什么同样调用一个大模型 API，有的产品像真人对话，有的像对讲机。差距不在模型，在模型前面那半秒。

立项前问方案商的三个问题

  1. 要一张延迟分解表：本地各环节、网络往返、模型首字各占多少毫秒。做过的团队张口就来；没做过的只会跟你聊模型。
  2. 开工时就定延迟指标，写进需求文档，别等第一版样机让人失望之后再补。
  3. 断网表现提前定：6 TOPS 以上可以本地跑小模型兜底；达不到的，就明确断网时玩具说什么——沉默就是退货的开始。

3CBAY 在深圳做陪伴机器人、车载 AI 助手与 AI 玩具机芯的开发与量产，延迟预算从立项第一天就定死，芯片选型、声学、固件、结构在同一个团队完成。有对话类产品要立项，联系我们。