延迟分位数是什么
报告延迟要看分位数而不是平均值：平均延迟会被大量快请求拉低，掩盖少量极慢请求——而用户体验与超时预算恰恰由尾部决定。常规做法是同时给出 P50、P95、P99 以及超时率，并且把首字节（首个 token）与完整输出分开统计：流式输出场景下用户感知的是首字节，批处理场景更关心完整耗时。
基本信息
| 适用平台 | 在线服务化的推理接口、代理应用与批处理任务 |
|---|---|
| 必报分位 | P50 反映典型体验；P95/P99 决定超时预算与用户容忍度 |
| 分段口径 | 首字节延迟与完整输出延迟分开统计，流式场景首字节更关键 |
| 采样要求 | 覆盖高峰与低峰时段，注明采样比例与观察窗口 |
典型使用场景
- 上线评审：把延迟分位数作为护栏指标，与质量一起验收
- 超时配置：按 P99 而不是平均值设定超时阈值，避免误杀正常慢请求
- 容量规划：峰值时段的 P95 决定需要多少并发能力
- 体验优化：确认慢点在首字节还是逐 token 生成阶段
- 对外承诺：向业务方给出分位延迟而非「平均约 2 秒」的模糊说法
延迟报告模板
延迟报告模板
# P50 首字节：0.6s P50 完整：1.8s
# P95 首字节：1.4s P95 完整：4.2s
# P99 首字节：2.9s P99 完整：8.9s
# 超时率（超过 10s 的比例）：0.4%
# 采样来源：生产流量 2% 抽样，窗口 2026-10-01 至 2026-10-07
# 备注：峰值时段（每日 09:00-11:00）P95 完整延迟为 5.6s
# 分段：排队 0.2s / 推理首字节 1.2s / 生成 2.4s / 校验 0.4s分位数怎么读
| 指标 | 含义 | 偏高时的排查方向 |
|---|---|---|
| P50 | 一半请求快于此值 | 整体慢了：看模型与提示是否变重 |
| P95 | 最慢的 5% 起点 | 先看排队与上游依赖，再看重试 |
| P99 | 长尾，决定超时兜底 | 定位个别慢请求的路由与输入特征 |
| 超时率 | 直接反映用户可见失败 | 收紧输出长度或缩短上下文 |
| 首字节占比 | 用户感知的等待 | 优化预处理、缓存与提示长度 |
平均值不是没用，只是不能单独用：它适合做长期趋势的粗看。凡是与用户体验、超时、容量相关的判断，都要落到分位数上。
采样口径要写清：只统计低峰时段会低估真实延迟，只统计成功请求会漏掉超时与失败请求带来的最差体验。失败与超时应当计入统计并单列。