详细解释
延迟百分位（Latency Percentile）是描述 API 响应延迟分布的核心统计量，定义为：「PXX 百分位延迟值 = 全量请求中，有 XX% 的请求延迟小于等于这个值」。它纠正了「平均延迟（Average / Mean）」会被极端异常值稀释、无法真实反映多数用户（尤其是慢用户）体感的致命缺陷。真实线上系统中，90% 用户体验由尾部 P95/P99 延迟决定，而非漂亮的 P50 中位数。
常见的百分位指标有四种：P50（中位数）表示有一半用户比这个快、一半比这个慢，体现典型用户体感；P95 表示 95% 的用户都能达到该延迟值，是面向业务体验的核心 SLA 指标；P99（TP99）表示最慢 1% 请求的延迟阈值，是高级体验与系统稳定性的分界线；TP999（P99.9）表示千分之一最差请求的延迟，专用于衡量金融、交易、语音通话等极端敏感场景。
以 大模型推理 API 为例，一组常见指标可能是：P50=800ms、P95=2.2s、P99=4.5s、TP999=9s——这意味着「一半用户 0.8 秒内出首字，但千分之一的用户要等 9 秒以上」。如果只看平均值（如 1.1s），会严重误判体验与稳定性。唯元智创 的 API 平台 默认提供 P50/P95/P99/TP999 四档实时延迟百分位仪表盘，并按模型、地域、时间段三维下钻，当 P99 连续 5 分钟超出 SLA 阈值时自动触发 自动扩缩容 或限流告警。
延迟百分位指标家族与落地对比表
| 指标名称 | 含义（全量请求中 ≤ 该值的比例） | 数值特征 | 主要用途 | SLA 建议阈值（LLM 场景） | 告警优先级 |
|---|---|---|---|---|---|
| P50 中位数 | 50% 请求 | 最稳定，抗异常 | 典型体感基线，容量规划参考 | 首字 TTFT 低于 600ms；总时延低于 1.5s | 低（辅助） |
| P90 | 90% 请求 | 介于 P95/P50 | 移动端 App 体验基线 | 首字 TTFT 低于 1.2s | 中 |
| P95 | 95% 请求 | 业务核心指标 | 正式 SLA 承诺 + 对外报价依据 | 首字 TTFT 低于 2s；总时延低于 4s | 高（核心） |
| P99 (TP99) | 99% 请求 | 尾部性能主指标 | 体验敏感场景 + 稳定性审计 | 首字 TTFT 低于 3.5s；总时延低于 8s | 高（核心） |
| P99.9 (TP999) | 99.9% 请求 | 极端尾部，对 GC/冷启动敏感 | 金融/交易/语音/实时协作 | 首字 TTFT 低于 6s；总时延低于 15s | 极高（核心敏感场景） |
| P99.99 (TP9999) | 99.99% 请求 | 对网络抖动/硬件故障极敏感 | 运营商级/证券级核心链路 | 低于 20s | 极高（仅顶级合规） |
| Max | 100%（最慢 1 次） | 极不稳定，无统计意义 | 仅用于 Debug 故障单点 | 不用于 SLA | 低（仅 Debug） |
| Mean 平均 | 算术平均 | 被长尾严重扭曲 | 成本估算辅助，不做体验 | 不用于 SLA 承诺 | 低（误导性） |
实战经验与避坑
- SLA 承诺绝对不能只写 Mean，必须至少绑定 P95 + P99 两个指标：很多厂商的宣传页写「平均延迟 500ms」，但真实 P99 可能高达 5 至 10 秒；客户侧如果按平均值做容量规划，上线后 5% 的用户会严重抱怨。正确做法是对外 SLA 至少写三条：① P95 延迟（首字 TTFT / 总时延）阈值；② P99 延迟阈值；③ 月度 可用性 SLA，三者缺一不可。
- 百分位统计务必用 HDRHistogram / DDSketch 这类高压缩直方图，别用简单数组全量存储：HDRHistogram 可在 1 至 2 MB 内存内精确存下 1 亿条延迟数据的完整分布，并支持任意百分位数查询；而朴素数组或数据库明细行存储（1 行 = 1 次请求），百万级 QPS 下一天的数据量就会达到 GB 甚至 TB 级，查询 P99 极其缓慢且成本高。Prometheus 默认的 Histogram bucket 也是近似方案，bucket 边界要选对（如 50ms、100ms、200ms、500ms、1s、2s、5s、10s、30s）才能让 P99 误差低于 5%。
- 百分位告警务必用「连续 N 分钟超阈值」而非单点瞬时：一秒钟的 P99 抖动到 10 秒很可能是一次 GC 或网络抖动，误报率极高；推荐设置「P99 连续 5 分钟超阈值」或「P99 5 分钟滑动窗口平均值超阈值」再告警，误报率下降 80%；同时 TP999 这类极端尾部指标，建议用连续 15 分钟窗口，避免偶发硬件故障误报。
- 百分位分析时必须做「下钻三件套」：模型维度、地域维度、输入长度维度：拿 LLM 场景举例，P99 暴涨有三种根因，不下钻会完全误判——① 某个新版本的 70B 大模型 TP/PP 通信瓶颈导致；② 某个海外地域回程网络丢包导致；③ 某些超长上下文（输入 Token 超过 32K）触发超长 Prefill。正确做法是把 P99 按这三个维度切割开，哪一子集高就针对哪一子集优化，绝不能拿全量混合指标乱调参数。
- TTFT 首字延迟与总时延的百分位要分开管，优化手段完全不同：TTFT 的 P99 主要瓶颈在「队列排队 + Prefill 阶段 + 冷启动」，优化方向是 自动扩缩容 的预热副本、PagedAttention Prefill 批处理、KV 缓存淘汰 策略；而总时延（End-to-End）的 P99 瓶颈在「Decode 阶段长输出 + 连续批处理饥饿 + 长文本分段解码」，优化方向是 Decode token 并行、输出长度限制、Chunked-Prefill 等。两者混为一谈会导致 50% 的优化努力投错方向。
- 降级 Max 指标的决策权重，但保留用于故障根因分析：Max 是单点最差值，统计意义几乎为零，不能拿来做任何 SLA 或告警；但 Max 对应那次请求的 trace_id + 详细日志（输入、副本、GPU、排队时长、阶段耗时）是定位「为什么 TP999 会炸」的绝佳入口——把每周 Top 10 Max 延迟请求做 case study，是稳定压下长尾延迟的最佳实践。
常见问题
为什么大家都用 P95/P99，而不是直接用 P100（最慢那次）？
因为 P100（最大值）是「单点最坏事件」，不具备统计可重复性，且成本收益比极低：三大原因决定 P100 不能做指标——第一，统计噪声极大。如果你一天有 100 万次请求，最慢那次可能是某台机器突然 GC、某块网卡瞬时丢包、甚至一次内核级调度抖动导致，只要机器数够多（如 100 台以上），每天都会出现类似事件，即使你把硬件翻倍，P100 可能依然是 30 秒甚至 60 秒，几乎不可能控制。第二，成本收益严重失衡。把 P99 从 5s 优化到 4s 可能只需增加 20% 的算力；但把 P100 从 30s 优化到 20s 可能需要 3 倍算力（例如所有请求都在超高速单机裸金属 + 独占 GPU 运行），而这一优化仅惠及百万分之一的用户，ROI 几乎为负数。第三，工程上无法做告警。P100 只要有 1 次慢请求就会炸，告警会 24 小时不停响，运营团队会直接忽略告警，真正重要的故障反而被淹没。正确做法是：P95/P99 管「绝大多数用户体验」并做 SLA，P99.9/P99.99 管极端敏感用户，Max 只用于事后 Debug 单点案例，绝不进入 SLA 或告警。
怎么把 P99 从 5 秒压到 2 秒？最有效的手段 Top 3 是什么？
按 ROI 从高到低排序，大多数场景前三手段可贡献 60% 至 80% 的 P99 下降：第一 ROI：消灭排队（贡献 30% 至 50% 的下降）——真实线上 40% 至 70% 的 P99 延迟根本不是 GPU 计算慢，而是请求在队列里排队等 GPU 空出来。优化有三小步：① 自动扩缩容的扩容触发阈值从「GPU 利用率 70%」提前到「队列平均排队时长 > 200ms」；② 给小模型/短请求单独开「低延迟队列」避免被长请求堵塞；③ 使用 vLLM 类连续批处理框架，消除请求-请求的 GPU 空转。第二 ROI：P99 下钻后针对性优化（贡献 15% 至 25%）——把 P99 请求按模型/地域/输入长度/输出长度四维度拆开，90% 情况会发现 1 至 2 个子集贡献了 80% 的尾部延迟（如「70B 模型 + 输入长度超过 32K」）。针对子集做单独优化：超长输入做 上下文压缩、70B 做 TP/PP 扩卡、地域差做就近部署。第三 ROI：热缓存 + 预热副本（贡献 10% 至 20%）——对高频前缀（如常见人设 System Prompt、常见 FAQ 查询）启用 前缀缓存，P99 Prefill 阶段可下降 30% 至 60%；同时维持 5% 至 10% 的 GPU 「预热冷备副本」永远空转待命，突发流量到来时直接接管，避免冷启动 20 秒的 TP999 波峰。这三件做完，P99 通常能从 5s 压到 2s 以内；若仍不足，再进一步考虑：GPU 升级（如从 A100→H100）、KV Cache 精度切换到 FP8、输出长度限制、流式分段解码等进阶手段。
第三方厂商只给我「平均延迟」，我怎么估算它的 P95/P99 会不会超标？
用「延迟分布三问 + 72 小时采样压测」两阶段法，80% 情况下可提前识别不合格厂商：第一阶段 「书面三问」（务必写入合同或技术应答，避免口头承诺）：①「你们对外 SLA 中 P95/P99 的月度保证阈值是多少？如果不达标如何赔付？」——正规厂商会有明确数字和赔付条款，没有写的基本默认 P99 会经常超标；②「请提供最近 30 天我所在地域对应模型的 P50/P95/P99/TP999 实际运行值的分钟级或小时级趋势图」——如果趋势图里 P99 在晚高峰会周期性飙升到阈值的 2 倍以上，说明容量严重不足；③「并发 100 QPS、平均输入 2K Token、平均输出 500 Token 的典型场景下，你们的实测 P99 是多少？」——拒绝回答或模糊回答的，默认不合格。第二阶段 「72 小时灰度采样压测」：选你自己的真实业务请求日志（脱敏后），按 2% 流量或固定 30 至 50 QPS 的速率，连续 72 小时向厂商打真实请求，并在客户端侧自己存延迟明细（每条请求精确到毫秒，记录开始/结束/模型/输入长度/输出长度）。72 小时后用 HDRHistogram 或 Python pandas 自己算 P50/P95/P99/TP999。经验公式：如果真实采样中「P99 / Mean」的比值大于 4，说明该厂商尾部抖动严重，稳定性差；比值大于 6 基本不能用于体验敏感场景；比值小于 2 属于优质稳定厂商。最后一步：验证如果厂商说「我们 P99 低于 2s」，你 72 小时采样的 P99 是否真的低于 2s，偏差超过 30% 就说明厂商宣传水分极大，要谨慎合作。再结合 SLA 可用性 的月度承诺，基本可筛选出稳定靠谱的供应商。