一句话定义：100 毫秒感知阈值（perceptual threshold）指的是：当界面对操作的反应落在约 0.1 秒以内时，人多半不会觉得“它在处理”，而会觉得“它就是我手的一部分”；一旦超过这条线，等待开始被感知。
打个比方：按电灯开关时，灯亮不带来延迟感，你不会觉得“灯响应了我”，只会觉得“我开了灯”。但如果灯泡要半秒才亮，你会怀疑没按到，并再按一次。这就是阈值的关键，不只是在“多等 0.4 秒”，还会触发“是不是没生效”的怀疑；用户一旦重试，代价就翻倍。
人机交互领域有个被反复引用的经验划分：0.1 秒内觉得即时；1 秒内思路不断，但会注意到等待；10 秒以上注意力跑掉，人开始切窗口。这只是一项经验规则，具体数值随任务和人的状态浮动，不要把它当成物理常数。
“看起来快”和“实际快”是两回事。 一个总耗时 800 毫秒、中间毫无反馈的转圈，比总耗时 1.5 秒、但一点下去就立刻出现内容的界面更让人烦躁。流式输出（streaming）不减少总时长，但把首字延迟（TTFT，Time To First AI 词典：Token">Token）压进阈值内，感受就完全不同。骨架屏（skeleton screen）、乐观更新（optimistic UI）、进度提示都是同一类手段：它们改变等待的形状，但不改变等待的总量。
| 感知延迟 | 实际延迟 | |
|---|---|---|
| 衡量什么 | 用户主观感受 | 端到端真实耗时 |
| 受什么影响 | 首帧反馈、动效、进度可见性 | 网络往返、排队、推理、渲染 |
| 怎么优化 | 骨架屏、乐观更新、流式输出 | 缓存、并行、边缘部署、小模型兜底 |
| 主要风险 | 掩盖真实性能问题 | 优化了用户其实不在意的一段 |
砍延迟的顺序。第一件事是量，不是猜：把端到端拆成网络往返（RTT）、排队、计算、渲染四段，看时间到底花在哪。跨洲一次往返常常就是几百毫秒量级，这一项不动，模型再快也白搭。
- 减少往返次数：合并请求、提前建连、把静态资源放得离用户近一点。
- 把“第一个字节”提前：流式返回、先给结论再补细节、小模型先答大模型兜底。
- 缓存与预热：高频问题直接出结果，别每次都跑一遍完整推理。
- 前端别空转：按钮按下 16 毫秒内要有视觉变化，用户就安心了。
- 藏不住的要说明白：给出可预期的进度，比让用户盯着空白猜要好。
对从业者：模型的延迟只是链路中的一环，TTFT 和总时长是两个指标，只看吞吐容易自欺。对普通人：判断一个产品快不快，别只看宣传，看它多久给你第一帧反应。