响应延迟是什么：开始显示与完整完成需要分别计时
解释端到端延迟、首段等待和排队的差别，说明比较模型速度时需要固定的输入及质量条件。
先说结论
先理解这个概念
响应延迟是从确定起点到目标结果可用的等待时间。对模型应用，首个词元出现与完整答案完成不是同一指标，工具执行或网络排队也可能占时间。比较前必须定义计时边界，固定输入和质量要求；不能只看文字开始滚动，就认定任务更快完成，更不能把加载等待全部归为模型生成慢。
01
完整请求包含模型之外的等待
OpenAI 的延迟说明讨论生成长度、请求组织等影响，vLLM 指标区分首词元、排队与端到端时间。服务内部计算快，不代表应用立即取得结果；代理缓冲或后续解析可能增加等待。反过来，流式能较早呈现部分内容，但完整结构仍需等结束。看速度报告时应确认测量从用户提交、服务接收还是推理开始计时，终点是首段还是可使用结果，避免将不同边界的数值直接排序。
02
同一输入分别记录冷启动和稳定请求
例如固定一段公开资料要求输出相同字段，在相同模型与并发下记录多次完整请求。首次加载与后续稳定结果分开，失败重试也计入实际等待。输出更短可能更快，却要确认没有删掉必要内容。若任务使用工具，应同时保留工具完成状态，不能只计模型首段文字。本文没有计时测试或测量服务，例子只定义验证方法，不提供特定模型的速度榜。应保留原输入与配置，让其他维护者可以重跑同样条件。
03
延迟目标应与质量和任务类型一起定
交互聊天关注及时反馈，离线批处理可能更关注规定时间内完成总量，二者不宜只按同一秒数判断。维护时观察慢请求分布，平均值可能掩盖少量等待很久的任务。调整缓存、并发或模型后重查质量，不能为缩短数字默默降低结果要求。成本还包括等待期间的恢复操作和人工处理，最终用可完成任务的结果衡量体验，而不是把“首字很快”扩写成整条业务都高效。
核对来源
以下资料用于核对概念和方法。文中的示例与测试范围分别注明，实际使用时请核对所用工具的版本。