模型跑得不慢，为什么你还是觉得慢？延迟感知的三笔账

上一篇我们聊了 AI 延迟（latency）的基本账本：首字延迟、生成速度和端到端完成时间。这一篇把镜头拉近一点，看看一个更微妙的问题：为什么同样的技术指标，在不同产品里给人的感受可以差出好几倍？答案不在模型里，在"延迟感知"这本账上。

第一笔账：等待的"质"比"量"更重要

人脑对等待的估计从来不是秒表。心理学里有个经典结论：充满信息增量的等待显得短，空洞的等待显得长。一个 3 秒的加载过程，如果不断有进度反馈（打字机效果、步骤提示），体感可能只有 1.5 秒；一个静止 3 秒的转圈，体感可能是 5 秒，还会伴随"是不是卡死了"的焦虑。

对 AI 应用来说，这意味着首字延迟（TTFT, Time To First Token）不只是工程指标，更是体验杠杆。把 TTFT 从 800ms 压到 300ms 的收益，远大于把总生成时间从 10 秒压到 8 秒——因为前者消除的是"有没有反应"的不确定，后者只是缩短了"反应多久"的确定等待。

第二笔账：可预测性抵得过绝对速度

等公交车的体感很说明问题：知道还有 2 分钟到站，等待是安心的；不知道要等多久，1 分钟都开始令人烦躁。AI 产品同理。流式输出（streaming）最大的功劳不是"更快得到答案"，而是把不可预测的黑盒等待，变成了可预测的、逐字兑现的承诺。

所以工程上排优先级时，可以按这个顺序自问：

1. 能不能让第一个可见反馈更快？（路由到小模型先答、缓存命中、预热连接）
2. 反馈节奏是否稳定？（避免卡顿后突然吐出一大段，tok/s 的方差比均值更伤体验）
3. 最后才轮到压缩总时长。

第三笔账：认知负荷伪装成延迟

很多"觉得慢"其实不是系统慢，是用户在等的时候无事可做：答案太长、结构太乱，读完的负担被误记为等待成本。这也是为什么同样 2000 token 的输出，带清晰小标题和列表的版本"感觉更快"——用户能扫读、能提前拿到结论，认知流水线提前下班了。

把账本摊开给系统看

具体到落地，建议给产品埋三个感知指标：首个可见字节时间、tok/s 的 P95 方差、以及"用户中途停止生成"的比例。第三个尤其诚实——它是用户用脚投票给出的延迟满意度评分。技术指标告诉你系统快不快，感知指标告诉你用户觉不觉得快，两者都对上，这本账才算平了。

下次优化 AI 体验时，别只盯着 dashboard 上的平均值。用户心里那本延迟账，记的是体感，不是毫秒。