首字时间 TTFT
从请求发出到收到第一个字的时间，决定用户是否觉得系统卡住。怎么测：固定输入样本、预热后测、区分流式与非流式；边界是检索增强场景要包含检索耗时，只测模型会低估真实等待，用户感知的是整段时间。
每字间隔 TPOT
输出阶段相邻字的平均间隔，决定阅读是否顺畅。为什么单列：首字快但吐字慢，整体体验依然差。做法：按输出长度分桶统计；边界是长输出场景下间隔会波动，要看分位而非均值，均值容易掩盖中途卡顿。
端到端分位
从请求到完整回答的耗时分布，重点看高位分位而不是平均。为什么：平均值会被大量快请求拉低，掩盖少数极慢请求。怎么做：按业务设不同目标，检索类与生成类分开统计；边界是目标要写进验收，不能停留在口头。
并发吞吐
单位时间能完成的请求数或生成的字符数，决定容量规划。怎么做：做并发阶梯测试，记录吞吐与延迟的拐点；边界是吞吐与延迟互相制约，动态批处理能提吞吐但会推高单请求延迟，需要按业务取舍，不能两头都要。
超时与降级率
超过约定时限的请求占比，以及降级后仍能给出可用回答的比例。为什么关键：延迟指标再好，也要有兜底。做法：为不同业务设不同超时并验证降级路径；边界是降级回答要明确标识，不能让用户误以为是完整结果。
适用与不适用
适合谁
- 要为新功能设定延迟目标的业务与产品团队
- 正在比较自建与云 API、需要客观数据的架构师
- 承担容量规划、需要拐点数据的运维负责人
不适合谁
- 尚未有真实请求、只能做空载跑分的项目
- 只关心功能是否可用、不设任何响应目标的产品
典型场景
某保险公司的条款问答上线前，团队用一批历史问题做基线测试，发现首字时间达标但长条款的每字间隔波动很大。进一步排查是检索阶段返回内容过长导致上下文膨胀。调整召回条数与截断策略后重测，端到端高位分位明显收敛，才写入验收标准。
可执行步骤
- 确定业务可接受的首字时间与端到端目标，区分核心与非核心场景分别设定
- 准备分层样本，覆盖长短输入、长短输出与多轮对话等各类型请求场景
- 预热之后再测首字、每字间隔与端到端分位，冷启动单独记录备查留档
- 做并发阶梯测试，找出吞吐与延迟之间的拐点位置与斜率的变化趋势
- 验证超时之后的降级路径与提示文案，确认用户能看懂并接受这种处理
常见坑
- 只报平均延迟而高位分位很差，问题就看不见，上线之后被少数慢请求拖垮口碑、续费意愿与评价。
- 只测模型耗时而不测检索，端到端与实测差距很大，对客户承诺的响应时间无法兑现也找不到原因所在。
- 冷启动与稳态混在一起统计，数据忽高忽低，既不能作为容量依据，也无法复现问题现象与趋势变化。
- 没有超时与降级设计，个别请求长时间挂起并持续占用连接资源，会把整个服务拖慢甚至打挂掉。
自检与验收清单
- 首字时间与端到端的目标是否已按业务分别设定
- 测试样本是否覆盖长短输入输出与多轮对话场景
- 统计口径是否统一使用分位数，而非平均值与均值
- 是否测过并发阶梯，是否记录了吞吐与延迟拐点
- 降级路径是否验证过，界面上是否都有明确标识
常见问题
首字时间多快才算好？
取决于场景。对话类通常希望首字尽快出现，检索类要叠加搜索耗时。与其定一个统一数字，不如分业务测出基线与高位分位，再和业务约定可接受范围，并把目标写进验收标准与测试方案。
为什么不能看平均延迟？
平均值会被大量快请求拉低，掩盖少数极慢请求。用户投诉往往来自这些慢请求，尤其在高峰时段。统计应给出高位分位并按输入输出长度分桶，否则结论会误导容量规划与验收判断。
端到端要不要含前端？
要。用户感知的是从点击到看到完整答案的全过程，包含网络、检索、推理与渲染。只统计服务端会低估等待，建议在前端埋点并与服务端 trace 对齐，定位时才能分清是哪个环节的问题。