均值代替分位
平均延迟达标不代表体验达标，少数极慢请求往往决定投诉。为什么常见：均值容易算也好汇报。做法是默认报高位分位，并在验收中写明；边界是分位要基于足够样本，样本太少时分位本身不稳定。
只测模型不测链路
真实请求包含鉴权、检索、重排与前端渲染，模型只占其中一段。为什么误判：模型跑分最方便，也最容易被当成整体对外汇报。做法是端到端埋点并分段计时；边界是分段计时本身有开销，采样率要合理设置。
忽略输出长度
生成长度直接决定总时长，同一模型答一句话与答一段话差别很大。怎么做：按输出长度分桶统计，并在产品侧限制冗余输出；边界是压缩输出可能损失必要信息，需要在完整性与速度之间定好规则并评审。
冷启动混入稳态
首次加载模型、建立连接与预热缓存的耗时远高于稳态，混在一起统计会得出错误结论。为什么重要：容量规划依据的是稳态数据。做法是预热后开始计时并单独记录冷启动；边界是冷启动无法完全消除，要靠预热缓解。
盲目加机器
排队可能来自批处理策略、连接池或下游检索，加机器不一定有效。怎么做：先看队列长度与资源利用率的组合，判断是容量不足还是调度问题；边界是盲目扩容会同时抬高成本与闲置，问题依旧存在。
适用与不适用
适合谁
- 正被反馈系统慢、需要定位原因的技术团队
- 要建立延迟验收标准的产品与测试负责人
- 承接性能优化项目、需要统一测量口径的服务商
不适合谁
- 没有线上流量、无法采样的早期项目
- 只接受单一跑分结论、不愿做分段计时的团队
典型场景
某企业的文档问答被反馈很慢，运维第一反应是加卡。性能小组先做端到端分段计时，发现模型推理只占小部分，大部分时间耗在向量检索与重排上，且高峰排队来自连接池配置。调整检索条数与连接池后延迟下降，扩容计划被取消。
可执行步骤
- 先做一遍端到端的全链路分段计时，找出各环节耗时占比与瓶颈位置
- 按输出长度与输入长度分别分桶统计，避免长短请求混在一起算平均
- 预热之后再测稳态延迟，并把冷启动数据单独记录、注明测试条件与轮数
- 区分容量不足与调度问题，再决定是扩容、调批处理还是修改连接池
- 把高位分位与样本量写进验收标准，替换原有的平均延迟统计口径与结论
常见坑
- 用平均延迟汇报，高位分位的问题被完全掩盖，上线之后投诉集中爆发，回头再查要花很多时间。
- 只看模型耗时，忽略检索与重排，优化方向从一开始就错，投入的人力与时间都换不来改善。
- 把冷启动数据当稳态使用，容量规划偏保守或偏乐观，最终不是浪费就是不够用，两种都要返工。
- 不定位瓶颈就扩容，成本上升而延迟没有改善，还会让团队误以为问题已经解决而放松跟进。
自检与验收清单
- 汇报口径是否已经默认给出高位分位数与样本量
- 是否做过端到端的分段计时，并完成了逐段归因
- 统计时是否按输入与输出长度分别分桶，避免混算
- 冷启动数据是否单独记录，是否注明测试环境条件
- 扩容之前是否确认过瓶颈所在的具体环节与证据
常见问题
分位要报哪几个？
常见做法是报中位与高位分位，重点看高位。样本量要足够，否则分位不稳定。按业务分别统计检索类与生成类，避免混算。汇报时同时给出样本量与测试条件，便于复核与比较。
分段计时会影响性能吗？
会有轻微开销，取决于埋点密度与采样率。建议在高并发链路上按比例采样，关键路径保留全量计数。埋点字段要能串起同一请求，否则分段数据无法拼合，定位时还是只能靠猜。
加机器前还要做什么？
先看队列长度、资源利用率与下游依赖耗时。三者组合能区分容量不足、调度不当与外部依赖慢。确认是容量问题再扩容，并同步准备降级方案，避免扩容期间高峰仍在排队。