先讲一个我碰到过很多次的场景监控图上平均延迟 180ms很漂亮但线上用户还是不断吐槽“又卡了”甚至直接超时报错。问题不在玄学而是监控数字本身选错了。这篇我想聊聊为什么平均延迟会骗你以及怎么用 AIPerf 这类带百分位统计的工具把 P99 尾延迟变成日常排查习惯。如果你是负责 AI 推理服务、API 网关或者在线系统的稳定性工程师后面这些内容应该能省掉不少加班时间。先说结论平均延迟是给报告用的P99 才是给用户用的。大多数互联网服务尤其是 AI 推理场景下延迟分布都不是一条平滑曲线而是典型的“长尾分布”。绝大多数请求很快完成少数请求莫名其妙地慢几倍。如果我们只盯着均值相当于把一群人里最高的几个身高和一个普通人的身高做平均然后说“大家都不矮”这显然是自欺欺人。1. 先别急着看平均延迟你的监控数字可能一直在骗你我见过太多次这样的排查现场服务平均时延 180ms监控大屏漂漂亮亮线上用户却一直在骂“卡死了”“转圈半天”。大家第一反应是查网络、查地域、查客户端结果查来查去根因就在监控面板上——你一直在看平均延迟而用户感受到的恰恰是平均延迟看不出来的那一小撮慢请求。1.1 一个简单的算术题就能说明问题假设 1000 个请求里有 990 个耗时 100ms只有 10 个请求跑到 2000ms平均是多少990100 加上 102000等于 119000除以 1000平均延迟 119ms。监控图上非常好看但实际那 1% 的用户等了两秒。对用户来说平均值毫无意义因为每个人只发起一次请求他遇到的就是那一次的真实耗时。那 1% 的用户感受到的是两秒卡顿而你只看到一条漂亮的曲线。在统计上这叫“分布偏斜”。在线服务里延迟分布通常呈长尾绝大多数请求很快完成少量请求因为排队、锁、GC、依赖超时、网络重传等原因被拖得很慢。均值是整个请求集合的算术平均值它天然会被大多数正常请求拉低长尾的影响被稀释得几乎看不见。一个灾难性的慢请求甚至不会让平均值跳出一个像样的水位。1.2 在 AI 推理场景里尾延迟问题会被放大这个道理放到 AI 推理服务里尤其明显。一次大模型请求并不是一次固定计算它涉及输入处理、缓存建立、逐字生成、输出返回等多个阶段还受输入长度、输出长度、同一批次里其他请求的资源竞争等多重因素影响。GPU 上的排队位置稍微靠后等待时间就可能从几毫秒变成几秒。举一个很现实的例子假设 95% 的对话请求都在 1 秒内完成剩下 5% 由于排队慢了三倍平均延迟依旧很好看但用户对在线交互场景的延迟极度敏感。人和机器对话等待 2 秒和等待 200 毫秒的感受完全不同。平均延迟平滑得越漂亮说明掩盖的问题可能越严重。所以第一步要做的是把视角从“平均延迟”换到“尾延迟”。紧接着的问题是尾延迟怎么看看哪个指标怎么从指标倒推根因。下面我会围绕 AIPerf 这个工具以及 P99 百分位的原理把实际操作中验证过的路径一起捋一遍。2. AIPerf 是什么AI 服务延迟剖析的正确打开方式先澄清一下AIPerf 不是那种通用 APM 系统换了个皮。以我实际使用的版本来说它是一套专门面向 AI 推理服务的性能剖析工具。它和普通监控最大的区别在于它把一次请求从网络入口一直跟踪到模型推理完成的每一步并把每一步的耗时放进同一个延迟分布里做计算。换句话说它不仅能告诉你平均多少毫秒还能告诉你 P99 究竟在哪个阶段失控。2.1 为什么通用监控很难看清 AI 服务的尾延迟我自己搭过 Prometheus 加 Grafana 的组合也用商业 APM。默认仪表板大多叫“平均响应时间”百分位不是没有但很多场景下根本没有足够的样本粒度。传统监控通常只记录服务端处理总耗时而一次 AI 推理请求里至少包含几个完全不同的耗时来源接入网关反序列化、鉴权、排队等待、输入预处理、逐字生成、返回前的结果后处理。如果只看总耗时的均值或者最大值你根本不知道慢在哪里。这也是我觉得 AIPerf 比较顺手的原因。它是天然的分阶段剖析器每个请求进来以后会以中间件或者 SDK 埋点的方式记录各个阶段的耗时。我测试时拉到的数据大致包含以下阶段网关耗时从收到请求到进入调度器排队耗时调度器等待可用 GPU 或推理引擎的时间输入处理耗时处理输入内容并建立缓存的时间生成耗时每个输出内容实际生成阶段的累计耗时后处理与返回耗时包括结果序列化、响应写出。这些阶段分别都有独立的百分位分布而不是合并成一个孤零零的总数。线上用户那一下卡顿到底卡在哪往往对应着排队耗时或者生成耗时的突发上涨这一点在传统监控里很难直接看出来。2.2 AIPerf 不是只做统计它在做可解释的延迟画像一般监控只给数字AIPerf 更接近“画像”。它在每个统计窗口里保存延迟直方图而不是存每条原始耗时的明细。听起来好像不算大优势但落到线上就是工程大坑如果网关每秒有上千请求每次都存全量请求列表到内存一分钟六万条数据内存和检索成本都扛不住。用直方图分桶比如 10ms、50ms、100ms、200ms、500ms、1s、2s、5s、10s 这样的区间每个区间只维护计数内存开销几乎恒定事后计算 P50、P90、P99 也很快。正因为这样AIPerf 的采集端可以做得比较轻。我把它部署在推理服务旁边CPU 占用基本可以忽略也不要求改造业务大框架。它输出的报表里我最常看三个值P50 代表典型体验P99 代表那些差点掉队的体验max 只用来怀疑极端情况。再把阶段拆开看哪个阶段把 P99 抬起来一眼就能定位。3. P99 究竟怎么算原理、口径与误区当你打开 AIPerf 的报告看到一个 P99 等于 1.8 秒这个数到底是从哪来的逻辑其实不复杂但一旦理解透了后面排查时能少踩很多坑。3.1 百分位的计算逻辑假设一个统计窗口内收集到了 N 个请求耗时样本把所有样本按耗时从小到大排成一列。第 p 百分位就是把样本分成 p% 和 100-p% 两个部分的界值。类比一下考试成绩如果你考到了 P90 的分意思是 90% 的人成绩比你低。对延迟来说P99 表示 99% 的请求耗时小于等于这个值只有 1% 的请求比它慢。具体找法也不复杂。对 N 个样本排序后位次一般取 rank N*p/100 向上取整。举个例子N1000p99rank990排序后第 990 个样本的耗时就是 P99。如果第 990 个样本耗时 1.8 秒就意味着这 1000 个请求里最多 10 个请求超过 1.8 秒。很多监控组件还会在分桶直方图上先按区间累积再插值计算近似值所以不同监控工具显示 1.78 秒和 1.82 秒这种小差异并不奇怪。这里有一个特别常见的误区P99 不是把最慢的 1% 挑出来求平均。P99 是一个边界点不是一段平均值。P99.9 同理它是 99.9% 的样本都不超过的那个值通常 P99.9 会比 P99 高出一大截因为最极端的那些请求往往极端得离谱。3.2 口径不一致P99 就没法比P99 看似一个数字实际上非常依赖口径。第一个口径是统计窗口长度。你拉 1 分钟窗口的 P99和拉 5 分钟窗口的 P99结果基本不可能一样。1 分钟窗口如果恰好覆盖到一次突发排队P99 会冲高5 分钟窗口会把突发摊平P99 会低不少。所以团队里定性能目标时一定要先固定 P99 是在 1 分钟窗口还是 5 分钟窗口。否则你和开发对齐时他那边显示 P99 只有 1 秒你这边看到 5 秒最后发现两个人看的时间窗口根本不同。第二个口径是延迟的起止点。端到端延迟包含客户端到服务端的网络耗时服务端延迟只从服务端收到请求开始算两者可能差很多。对用户体感来说端到端才有意义对排查服务自身问题来说服务端延迟更方便定位。AIPerf 两种都能统计但报告时必须分开说不要混在一个指标里。第三个口径是采样策略。在线高并发系统经常不是完整记录所有请求而是按比例采样。如果采样率低尤其没有针对性保留慢请求样本P99 会被严重低估。理想方案是保留所有请求的分桶计数AIPerf 默认就是这么做所以它比“随机抽取 1% 样本做均值打分”的监控更可信。3.3 P99 的几个反直觉现象第一个现象是 P99 数字天然有噪音。正态分布下均值很稳定但长尾分布下 P99 由少数慢请求决定窗口内多一个慢请求或者少一个慢请求P99 变化可能非常大。P99 从 800ms 跳到 1.6 秒不一定代表系统突然变差可能只是窗口里多了几个超时。优化时不要死盯单条 P99 曲线要看一段时间内 P99 的趋势分布。第二个现象是优化平均值并不等于优化 P99。你很容易通过限流把最慢的 2% 请求挡在外面平均延迟立刻好看P99 也可能好看但 P99.9 和用户真实的长尾体验仍然刺眼。反过来如果只提升平均性能比如把一个公共组件从 50ms 降到 30ms均值改进明显但 P99 可能毫不动摇。因为决定 P99 的往往是资源竞争和排队而不是那 50ms 的正常路径耗时。4. 实操复盘用 AIPerf 揪出那条看不见的长尾理论聊得差不多了直接上一个真实场景。某个在线对话服务用户反馈页面经常长时间停在“生成中”后端监控却显示平均时延只有 220ms。我们按传统思路查了一轮网络正常、CPU 不高、内存不紧张卡得莫名其妙。后来我把 AIPerf 的采集器接到服务网关上等了 20 分钟拿到了非常明确的数据。4.1 启动采集并检查整体分布我用的命令大致是这样aiperf record --service chat-svc \ --duration 20m \ --bucket 10ms,50ms,100ms,200ms,500ms,1s,2s,5s,10s \ --percentiles 50,90,99,99.9记录结束后直接看汇总报告aiperf report --service chat-svc \ --percentile 99 \ --by-stage \ --since 2025-03-10 15:20 --until 2025-03-10 15:40报告里最扎眼的是下面这张表我把关键行为整理了出来阶段P50P99P99.9网关与鉴权12ms90ms220ms排队等待15ms4600ms9.8s输入处理40ms180ms420ms内容生成180ms820ms1.5s返回后处理5ms35ms90ms看这张表就明白了请求总体均值漂亮是因为大多数请求的生成和各阶段都比较快但排队阶段的 P99 已经到了 4.6 秒P99.9 接近 10 秒。用户体感恰恰就是“等了好久后面才突然冒出来”的卡顿。4.2 一步步追踪根因这个报告没有停在“排队慢”这个结论上。AIPerf 把排队等待继续拆成了忙碌等待和下一个批次等待。我点开时间轴看到 15:30 到 15:34 这一段每分钟排队 P99 从 800ms 拉高到 5 秒正好对应一批内部测试流量。根因定位到调度策略上推理引擎采用固定时间窗口批量处理请求窗口刚结束时新到的请求没法插入当前批次必须等下一轮如果下一轮又被前排大请求占住这个请求就会被继续顺延。简单说不是服务整体崩了而是请求在批量窗口边界处撞上了“晚到”的强制等待。后面几天的动作是这样把批量窗口从 30ms 调整成 10ms窗口变小后等待下一批的时间上限降低吞吐会损失一些但尾延迟明显改善对交互型请求单独走一条轻量调度通道不跟长任务绑死在同一个批次里当排队时间超过阈值时做优先级上报而不是让请求在队列里空等。调整之后排队阶段 P99 降到 400ms 左右用户侧的“生成中”少了很多。这个方法论的启示是先分阶段定位再拍板优化方向。如果按平均延迟去优化总耗时很可能你会先去折腾内容生成阶段但真正的瓶颈在排队。4.3 日常使用 AIPerf 的建议只做一次排查是不够的我建议固定一套日常动作建一个阶段耗时明细仪表板P50、P99、P99.9 分列展示每次发布之后重点看 P99而不是平均延迟设置阈值告警比如排队 P99 大于 1 秒时触发但别把告警粒度压到秒级否则全是噪声按模型版本和上游业务维度分组看同一个网关对不同模型和不同调用方的延迟差异可能极大混在一起看只会互相掩盖。这套动作跑起来之后排查问题基本就不靠猜了。5. 常见问题速查为什么 P99 总压不住实操中大家问得最多的往往不是概念而是“为什么我都看了 P99还是压不下去”。5.1 平均正常但 P99 高第一反应检查排队前面举的例子已经说明这一点。如果某个阶段的延迟特别长一般背后都有队列要么是线程池队列要么是 GPU 排队要么是连接池等待。平均延迟被大多数快速请求抬低但 P99 高这时候先看各个依赖的排队指标比看 CPU 使用率更有效。很多后端服务 CPU 只有 50%却频繁出现请求毛刺背后往往是下游连接池已经占满排队的请求全被阻塞。5.2 P99 变了但用户还是卡窗口太短或者口径不一致有一段时间我们发现服务端 P99 记录很漂亮但用户依旧喊卡最后发现监控里的 P99 只统计了“处理阶段”把客户端建连、TLS 握手、传输排队都漏掉了。等我们把端到端 P99 接进来才发现比服务端 P99 多了将近 1 秒。看 P99 不能只看一个层级从用户到网关、从网关到推理引擎每一跳都应该有自己独立的百分位。如果只盯服务端内部指标等于把外部队列全漏了。5.3 快速排障时怎么组织思路我常用下面这个表格作为第一轮检查清单现象大概率方向用 AIPerf 重点看P99 高P50 稳定间歇性排队或资源竞争排队等待阶段的时间分布P99 和 P50 同时上涨正常路径变慢输入处理、内容生成、下游调用单个窗口 P99 冲高突发流量或慢依赖抖动时间轴上对应时刻的直方图P99.9 比 P99 高一个量级锁竞争、超时重试、冷启动阶段分布中最大耗时的样本特征P99 波动很大环境抖动或样本量不足样本量、分钟窗口、跨窗口趋势这里要再强调一次样本量不够的情况下P99 很难解读。如果一分钟只有 30 个请求排序后 P99 几乎落在最末端本质上接近最大值。对比数据之前先看样本量再决定要不要信这个数字。6. 从指标到改进压尾延迟的几个实操心得前面讲的是怎么看 P99这一节聊怎么压。我从实际项目里积累了几个方向不一定每个系统都完全适用但思路可以复用。6.1 限流不是解决 P99 的好办法限流确实能让 P99 指标变好看但代价是用户请求被拒绝体验反而更差。很多系统在峰值故意丢弃超额请求以保护剩余请求的延迟。这种策略可以接受但一定要做到透明给客户端返回明确的错误码和重试建议而不是让请求悄悄超时。否则请求被丢弃后用户看到的卡顿并不会消失只是从“慢”变成了“失败”。6.2 为 AI 服务定制调度策略而不是无脑调参数前面讲到的批量窗口边界问题对 AI 推理服务尤其常见。推理服务为了摊薄 GPU 成本通常会尽量多凑请求一起处理但如果所有请求都被平均地塞进一个批次尾延迟一定不会好看。我建议的组合方案是交互型请求用较小的批次窗口优先保证延迟离线任务和批量分析任务分流到独立资源不要和线上交互型请求共用队列采用连续批处理策略满足时间条件或者数量条件就立刻开始不用傻等一个固定满员窗口对超长输出内容设置上限或者用流式输出降低用户等待首个响应的时间。这些优化方向都是通过 AIPerf 报告看到排队阶段飙升之后才意识到的。如果没有分阶段延迟数据我大概率还在盲目调超时时间。6.3 客户端超时和重试设计必须与 P99 配合这是很容易被忽视的联动问题。如果你的服务端 P99 是 3 秒客户端把超时设成 2 秒那么那 1% 的慢请求会被强行中断然后可能触发重试重试又叠加在已经拥挤的队列上让排队更严重P99 进一步恶化。这是一种典型的“超时雪崩”。更稳妥的做法是客户端超时按服务端 P99 再留一点裕量一般设置为 P99 的 1.5 到 2 倍重试一定要加抖动不能整点同一时刻全部重试如果有指数退避也要避免大量请求在同一时间点退避回来。如果服务端长期有超过 1% 慢请求优先修服务端而不是靠延长客户端等待来掩盖问题。6.4 用 P99 定目标但别忽略最极端的请求我比较推荐团队把平均延迟从性能目标里拿掉换成 P99 或者 P99.9。比如“可用性 99.9%端到端 P99 延迟小于 2 秒错误率不超过 0.5%”。但要注意只看 P99 意味着完全不关心最慢的 1%而对在线对话类服务来说那 1% 可能代表一批重度用户体验崩坏。如果性能和成本预算允许也要关注 P99.9 和最大耗时至少知道极端情况发生时到底慢到了什么程度。我现在的个人习惯是打开监控第一眼先看 P50 和 P99 的差距差距越大说明系统越不稳定而不是系统越“快”。第二眼看排队阶段有没有异常上涨因为多数尾延迟问题的根源都在队列里。第三眼才会回到总延迟和平均延迟但那只是为了写汇报材料不是为了判断线上体验。另外还有一个小技巧当你发现 P99 总是降不下去的时候先别急着加机器试试把所有阶段的延迟明细导出来看一遍。很多时候机器加得再多也解决不了因为调度策略、超时重试或者客户端和服务端口径不一致引入的延迟。数据到位了方案自然就有了。