用户不会看你的架构图，只会说一句"它反应好慢"。而"慢"通常不是某一段特别慢，是六段串起来的总和。
从你开口到听到回应，链路是这样的：
唤醒 → 断句(VAD) → 语音识别(ASR) → 大模型生成(LLM) → 语音合成(TTS) → 播放
每一段都有固定的处理时间和网络往返时间。串行执行时，它们相加就是用户感知的延迟；优化的本质，是把能并行的部分并行起来，把能提前做的事情提前做。
最容易踩的坑是"整段收完再上传"。流式识别在用户还在说话时就已经把音频送出去，说话结束的那一刻识别结果基本就绪，直接省掉一整段上传等待。
唤醒词检测和设备端可处理的基础指令不需要联网，断网也能响应。把这一步放在本地，等于把链路的第一段延迟压到接近零。
生成侧拿到第一句话就交给合成，合成侧生成第一段就交给播放。用户听到第一句的时间，取决于"第一个字"什么时候出来，而不是"整段话"什么时候写完。
"随时打断"是体验分水岭。设备需要在播放自己的声音时同时收音，这要求回声消除（AEC）做得干净，否则会把喇叭里的声音当成用户说话。
优化顺序建议： 先做流式和首字优先（改动小、收益大），再抠唤醒与基础指令的本地化，最后才考虑换模型或加机器。
语音交互最不耐受长尾。平均延迟 1 秒、但每十次有一次卡 3 秒，用户体验就是"它老是卡"。所以我们更关注 P95 而不是平均值。
小智语音对话平台把这条链路做成了一套服务，包含流式识别、多模型对话与流式合成，并按上面这些经验做了默认优化。如果你正在被延迟问题困住，欢迎联系我们聊聊具体场景。