交互系统中的延迟权衡

交互系统里决定体验的，很少是平均延迟这一个数，而是用户在等待期间知道什么。这是个很老的系统经验，而语音和端侧 AI 让它重新变得要紧。

一个数不够，至少要三个

• 首字延迟——从请求到第一个可见反应。
• 稳态吞吐——之后每秒出多少。
• 总时长——这件事整体多久做完。

一个系统可以在其中一个上很快、在另一个上不可用。而且速度永远是「在什么条件下的速度」：LFM2.5-Encoders 快约 3.7 倍这个数，附带的限定是「长上下文、在 CPU 上、对比 ModernBERT-base」——去掉限定，这个数就没有意义。同理，Gemini Robotics 2 的时刻定位平均误差 0.96 秒是在「4 倍于大得多的模型的执行速度」下取得的，被买下的权衡是单位时间内的准确度，不是单纯的准确度。

感知延迟可以和真实延迟脱钩

你能改的往往不是延迟本身，而是等待期间发生了什么：流式输出让首字延迟代替总时长成为体感、确认音和语气词填住空档、乐观更新先给出可撤销的结果。

语音把这件事推到极端。GPT-Live 这类模型直接驱动语音产品，而语音没有屏幕可以放一个转圈——沉默会被直接读成失败。所以语音的延迟预算不是省出来的，是重新分配出来的。

预算要分配，不是一味压缩

一条链路的延迟花在检索、模型、工具调用、后处理几段上。先量出各段占比，再决定优化哪一段——否则优化的往往只是你看得见的那一段。

端侧和云的取舍也落在这里：本地省掉了网络往返，但把模型规模压死了；混合架构的实质是按「哪些请求容忍得起这次往返」来切，而不是按技术偏好切。

定义好「太慢了怎么办」

每个交互系统都需要为「超时」写下明确行为：降级到更小的模型、返回部分结果、转人工，或者干脆告诉用户失败了。没有定义的超时行为，就是挂起。 这一条比任何加速手段都更早需要被决定。

与相邻条目的分工

这一条是概念：延迟由哪几个数描述、预算怎么分、感知怎么和真实脱钩。语音产品的对话节奏、打断与兜底怎么设计，是「实时语音交互设计」；为很多人服务时的排队、批处理与副本数，是「推理服务容量规划」；一台具体机器上的实测与调优，是「端侧模型部署与硬件适配」；哪些请求走本地、哪些走云，是「本地与云混合推理架构」。