模型跑得慢，为什么用户觉得更慢？

一个反直觉的事实：用户投诉「太慢了」，往往不是因为总耗时真的很长，而是因为等待体验出了问题。同样是等三秒钟，刷短视频几乎无感，等一个 AI 回答却可能让人想刷新页面。这背后是一套可以量化、也可以设计的「延迟感知账本」。

一、人对时间的感知是非线性的

心理物理学里的 Weber-Fechner 定律告诉我们：人对刺激强度的感受是对数关系，对时间也同样如此。等待 0.5 秒和 1 秒的差别很小，但从 5 秒到 10 秒却是质变——大脑会把「超预期等待」自动归类为「卡住了」。更微妙的是，不确定的等待比已知的等待显得更长。医院告诉你「还要等四十分钟」，反而比「快了快了」更容易让人平静，因为前者给了大脑一个可以预期的锚点。

对 AI 产品来说，这意味着：把延迟从 8 秒优化到 6 秒，用户可能毫无感觉；但加一个「正在思考…」的进度指示，投诉会立刻下降。不是玄学，是预期管理。

二、首字延迟才是真 KPI

传统 Web 性能有 TTFB（首字节时间），LLM 应用里对应的指标是 TTFT（Time To First Token，首字延迟）。大量线上 A/B 测试反复验证：用户对 AI 回答的满意度更多由 TTFT 决定，而不是总生成时间。原因很简单——第一个 token 出现之前，大脑处于「系统是否活着」的不确定焦虑中；一旦文字开始流动，等待就变成了「阅读节奏」问题，而阅读本身是愉悦的。

这就是为什么流式输出（streaming）几乎是所有 LLM 产品的标配。后端总耗时一秒没少，用户感知却快了一倍。配合「思考中」的骨架屏、逐字渲染的打字机效果，感知延迟可以被压缩到实际延迟的一半以下。

三、延迟的账要分层记

一次 AI 请求的时间线其实很长：网络往返、鉴权、prompt 拼装、prefill（处理输入）、decode（逐字生成）。工程上常见的坑是只盯总耗时，结果优化错了地方。举个例子：prefill 时间与输入长度平方相关，一个塞满上下文的请求光 prefill 就要两秒；这时你优化 decode 速度毫无意义，应该先做上下文瘦身或者 KV cache 复用。

另一个常被忽略的变量是输出的确定性。同样的问题，用户不知道会得到半句还是三百字时，等待显得格外漫长。聪明的做法是先给出一个短的结论帧（哪怕只是「找到了，共三点」），再展开细节——把不确定的长等待拆成确定的短等待。

四、什么时候快反而是坏事

最后一个少有人讨论的角度：即时回复有时会伤害信任。秒回的客服让人怀疑是机器人；瞬间生成的报告让人怀疑没认真读材料。适当的「思考时长」反而是质量信号。所以延迟优化的终点不是把所有时间压到零，而是让每一段等待都有意义、有反馈、可预期。

延迟感知是一门把工程指标翻译成心理体验的学问。记住这本账的三条规则：先优化首字，再优化总时长；给等待一个锚点；把长任务切成有反馈的短段。做到这三条，六秒的用户满意度可以胜过三秒的沉默。