延迟监控：LLM服务的脉搏检测

可视化演示

展示LLM推理延迟监控体系：多阶段延迟分解（排队→Prefill→Decode→网络）、P99时序监控与异常告警、以及TTFT/TPS关键指标与优化方向。

1. 延迟指标定义

早晨查房时，护士会先测体温、量血压、数脉搏——这是三项最基础的生命体征。对 LLM 服务来说，延迟这个“生命体征”也要拆成三根线：首字延迟（TTFT）、单字生成延迟（TPOT）和端到端时延。不先把指标定义清楚，后面所有的监控都是空中楼阁。

TTFT（Time To First Token）指用户从发出请求到收到第一个字的等待时间，相当于护士按下秒表后，第一次看到“脉搏跳动”的间隔。TPOT（Time Per Output Token）是生成每个输出 token 的平均耗时，类似“每次心跳之间的间隔”。端到端时延则是从请求发出到完整回复展示的总时长，是用户真正在屏幕上感受到的等待。

这三者不是并列关系，而是串联关系——先等首字，再逐字产出。如果模型这次回答生成了 N 个 token，端到端时延大致等于首字延迟加上每一字耗时乘以 N：

$$\displaystyle L_{total} = L_{TTFT} + L_{TPOT} \times N_{tokens}$$

1. 输出字数 N_tokens：模型这次回答一共会生成多少个 token，可理解为“这段话一共有多少个字”。

$$N_{tokens}$$

2. 逐字生成总耗时：每个 token 的耗时 L_TPOT，乘以字数 N_tokens，就得到正文部分的全部生成时间。

$$L_{TPOT} \times N_{tokens}$$

3. 首字延迟 L_TTFT：从请求发出到第一个 token 出现的等待时间，它决定用户“第一眼”的速度。

$$L_{TTFT}$$

4. 相加为总时延：首字等待和逐字生成先后发生，二者相加构成端到端时延。

$$L_{total} = L_{TTFT} + (L_{TPOT} \times N_{tokens})$$

回到查房的比喻：护士绝不会只测一项指标就下结论，因为体温、血压、脉搏各自反映不同的问题。延迟监控也一样——TTFT 慢了，往往是首字链路或排队的问题；TPOT 慢了，往往是推理引擎或显存带宽的问题。三项指标一起看，才能知道病人的真实状况。

2. 采集方式设计

心电监护仪上的波形并不是天生就有的，护士要把电极贴片贴在病人胸口，信号才能传到屏幕。延迟监控的第一步，就是给每个请求“贴上电极贴片”——在关键环节埋点计时。

贴片做法有三种常见形态。SDK 埋点：在网关或客户端 SDK 里自动记录每个请求的各阶段耗时，集成成本最低。结构化日志：把耗时字段连同模型、版本、用户 ID 一起写入日志中心，便于事后检索。链路追踪：用 traceId 把一次请求的网关、推理引擎、存储访问串联起来，方便后续按链路完整回放。

但每分钟可能有几万甚至几十万个请求，如果每个请求都全量记录，日志存储会很快爆炸。这时需要“采样策略”——只在部分请求上记录详细延迟。采样率可以这样估算：

$$\displaystyle r_{sample} = \min\left(1,\ \frac{N_{budget}}{N_{estimated}}\right)$$

1. 预算样本数 N_budget：当前存储和计算资源能承受的日志条数。

$$N_{budget}$$

2. 预估请求量 N_estimated：根据历史流量预测出的总请求数量。

$$N_{estimated}$$

3. 两者相除：得出按比例分配的采样率。

$$\frac{N_{budget}}{N_{estimated}}$$

4. 与 1 取最小值：请求少时全采样，请求多时降采样，采样率永远不会超过 100%。

$$\min\left(1,\ \frac{N_{budget}}{N_{estimated}}\right)$$

护士不可能 24 小时用笔记录每一次心跳，但智能监护仪可以全量感知、选择性记录：危重病人全量记录，普通病人按比例抽样。这样既不会漏掉关键异常，又不会让日志把数据平台淹没。

3. 分布统计解读

一个病房一天会产生几十万次心跳记录，如果只看“平均心率 72 次/分”，护士根本无法发现某个病人曾在凌晨 3 点心动过速。延迟数据也一样，平均值会掩盖长尾问题。

因此我们要用百分位数来“分层看脉搏”。P50 表示一半请求比它快、一半比它慢，是典型体验；P95 表示 95% 的请求比它快，代表“大多数场景的上限”；P99 表示 99% 的请求都比它快，它才真正反映那 1% 的最差体验。对 LLM 服务来说，P99 往往比均值高出数倍，这就是“长尾”。

计算 P99 的方法很简单：把 N 条延迟数据从小到大排序，再取第 99% 位置上的那个值：

$$\displaystyle P_{p} = x_{\left\lceil p \times N \right\rceil},\quad x_1 \le x_2 \le \cdots \le x_N$$

1. 升序排列：把所有延迟从小到大排成一列，极小值和极大值各就各位。

$$x_1 \le x_2 \le \cdots \le x_N$$

2. 计算位置索引：用分位 p（如 0.99）乘以样本数 N，再向上取整。

$$\left\lceil p \times N \right\rceil$$

3. 取该位置的值：排序后位于这个位置的值，就是第 p 百分位。

$$P_p = x_{\lceil p \times N \rceil}$$

体检报告之所以不能只看“平均血压”，是因为它没有告诉你血压有没有瞬间冲高。P99 的使命，就是抓住那根最危险的心率尖峰，让长尾问题无处可藏。

4. 可视化看板构建

监护仪之所以把心跳画成一条绿色波形线，是因为人眼对“图形趋势”比“数字变化”敏感得多。数据落到看板上，你才能在一片数字里一眼看出“是不是开始异常爬升了”。

一个典型的 LLM 延迟看板至少包含三层。总览面板展示 P50/P95/P99 时序曲线和当前请求量；维度筛选面板支持按模型、机器人、机房、用户端筛选；异常联动视图在检测到慢请求时，自动关联日志和链路追踪，方便值班人员一键下钻。

为了让曲线不过度抖动，看板里常会用一个“滑动窗口平均”来平滑噪声。假设最近 w 个请求的延迟是 L₁、L₂、…、L_w，那么：

$$\displaystyle \bar{L}_w = \frac{1}{w}\sum_{i=1}^{w} L_i$$

1. 取最近 w 个请求：把时间窗口内的延迟数据收集起来，记为 L₁ 到 L_w。

$$L_1, L_2, \dots, L_w$$

2. 求和：把窗口内所有延迟加起来。

$$\sum_{i=1}^{w} L_i$$

3. 除以 w 求平均：得到窗口平均延迟，画成平滑曲线。

$$\frac{1}{w}\sum_{i=1}^{w} L_i$$

如果说原始日志是化验单上的数值，那看板就是心电监护屏上的波形。好的看板让值班医生三秒钟看懂病情，而不是在几十万条日志里大海捞针。

5. 异常检测告警

监护仪最让人安心的是它会“滴滴”响。但报警器不能乱响：响得太频繁，护士会麻木；响了却不处理，就形同虚设。异常检测要做的，就是既准确又克制。

最简单的是“固定阈值规则”：P99 超过 1000ms 就告警。优点是直观，缺点是早晚高峰、节假日流量天然不同，一条固定线很难适应所有时段。更健壮的是“动态基线检测”：用当前滑动窗口的历史延迟算出平均值和标准差，当实时延迟超出“均值 + 3σ”时，才判定为异常：

$$\displaystyle Alert: \quad L_{current} > \bar{L}_{w} + 3\sigma_{w}$$

1. 窗口均值：最近一个窗口内延迟的平均水平，代表“正常基线”。

$$\bar{L}_{w}$$

2. 窗口标准差：同一窗口内延迟的离散程度，σ 越大说明波动越剧烈。

$$\sigma_{w}$$

3. 叠加 3σ：基线加上 3 倍标准差，形成动态警戒线。

$$\bar{L}_{w} + 3\sigma_{w}$$

4. 判断越线：当前延迟若超过警戒线，则判定为异常并触发告警。

$$L_{current} > \bar{L}_{w} + 3\sigma_{w}$$

监护仪的“克制”还体现在告警降噪上：连续 N 次超阈值才触发、触发后进入静默期、按 P95/P99 分级通知。就像护士不会因为一次早搏就呼叫全科会诊——只有持续异常才值得惊动主治医生。

6. 归因分析诊断

心跳快了，医生不会上来就给心脏开药，而要先判断是心脏泵血弱，还是血管阻力大，又或者是病人刚跑完楼梯。延迟高也一样，先别急着换 GPU，要拆解“慢在哪一段”。

一次请求从用户手机到 LLM 服务再返回，可以分成四段。客户端网络耗时、服务端排队耗时、模型推理耗时、返回传输耗时，这一段段拼起来，正好构成端到端延迟：

$$\displaystyle L_{total} = L_{client} + L_{queue} + L_{infer} + L_{return}$$

1. 客户端网络耗时：用户设备到服务端之间的传输时间，受跨地域、弱网影响明显。

$$L_{client}$$

2. 服务端排队耗时：请求进入服务后被放入队列等待，直到有空闲 worker 处理。

$$L_{queue}$$

3. 模型推理耗时：GPU 或推理引擎真正执行 token 生成的时间，最能体现模型性能。

$$L_{infer}$$

4. 返回传输耗时：响应从服务端返回用户设备的时间，流式场景下尤其值得关注。

$$L_{return}$$

5. 四段相加并逐段对比：每段用链路追踪记录耗时，看各段占比即定位瓶颈。

$$L_{total} = L_{client} + L_{queue} + L_{infer} + L_{return}$$

这就好比医生给身体分区听诊：心音弱听心脏、呼吸弱听肺、四肢凉查末梢循环。四段里哪段高，就重点优化哪段，而不是盲目“砸 GPU”。

7. 优化方向探索

心电监护仪显示病人心率过快，医生会开出处方，但处方一定针对病因：心脏泵血弱就加强心药，血管阻力大就扩血管，紧张焦虑就镇静。LLM 延迟优化的“处方”，同样要基于归因结果来开。

第一张处方是“模型推理加速”。通过量化压缩模型体积、投机采样减少解码步数、优化 KV cache 降低显存带宽压力，可以让每个 token 的生成时间（TPOT）明显下降。第二张处方是“缓存与预填充”。把高频问题的前缀做前缀缓存、把常见问答做语义缓存，命中时可以把首字延迟从数百毫秒压到几十毫秒。

第三张处方是“流式输出”，它的原理很巧妙：用户并不需要等全部内容生成完才开始阅读。只要第一个字到达，用户就可以边看边等，所以用户实际感知到的等待时间约等于首字延迟：

$$\displaystyle L_{perceived} \approx L_{TTFT}$$

1. 感知延迟：用户主观感受到的等待时间，不完全等于服务端计算时间。

$$L_{perceived}$$

2. 近似等于首字延迟：流式场景下，第一个字到达后用户就开始阅读，后续文字陆续补齐。

$$L_{perceived} \approx L_{TTFT}$$

监护仪的波形要恢复正常，靠的不是某一次大力出奇迹，而是“指标→采集→统计→看板→告警→归因→优化”这个闭环持续转起来。当你能从这个闭环里读懂服务的每一次心跳，你就真正成了 LLM 服务的主治医生。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""LLM 服务延迟监控模拟器: 模拟请求延迟、计算分位数、检测异常。"""import mathimport random rnd = random.Random(42)  def simulate_request():    """生成一次 LLM 请求的延迟数据, 返回 (ttft_ms, tpot_ms, tokens, total_ms)。"""    ttft = max(50, rnd.gauss(300, 60))       # 首字延迟, 均值 300ms    tpot = max(10, rnd.gauss(45, 10))         # 每字延迟, 均值 45ms/token    tokens = rnd.randint(20, 80)              # 输出 token 数    total = ttft + tpot * tokens               # 端到端时延    if rnd.random() < 0.03:                    # 3% 长尾异常        total *= rnd.uniform(2.0, 4.0)    return ttft, tpot, tokens, total  def percentile(sorted_vals, p):    """返回升序数组第 p 百分位, 使用 ceil(n*p/100) 定位。"""    n = len(sorted_vals)    if n == 0:        return 0.0    rank = int(math.ceil(n * p / 100.0))    rank = max(1, min(n, rank))    return sorted_vals[rank - 1]  def monitor_latency(request_count=1000):    """延迟监控主流程: 采集 -> 排序 -> 分位数 -> 异常告警。"""    totals = []    for _ in range(request_count):        totals.append(simulate_request()[3])     totals.sort()    p50 = percentile(totals, 50)    p95 = percentile(totals, 95)    p99 = percentile(totals, 99)    threshold = p95 * 1.5                       # 动态阈值: 超过 P95 的 1.5 倍    anomalies = [t for t in totals if t > threshold]     print("== LLM 服务延迟报告 ==")    print("P50  = %6.0f ms" % p50)    print("P95  = %6.0f ms" % p95)    print("P99  = %6.0f ms" % p99)    print("Max  = %6.0f ms" % totals[-1])    print("异常请求数量: %d (阈值 %.0f ms)" % (len(anomalies), threshold))    return {"p50": p50, "p95": p95, "p99": p99}  if __name__ == "__main__":    monitor_latency()

1. ttft = max(50, rnd.gauss(300, 60))用正态分布模拟 300ms 附近的首字延迟，下限设 50ms 防止出现负值。
2. total = ttft + tpot * tokens端到端时延 = 首字延迟 + 每字延迟 × 输出字数，对应文中第一条公式。
3. if rnd.random() < 0.03: total *= rnd.uniform(2.0, 4.0)注入 3% 的长尾异常，模拟真实偶发的慢请求。
4. totals.sort()对延迟排序，这是计算所有分位数的基础。
5. rank = int(math.ceil(n * p / 100.0))用“分位 × 总量向上取整”定位百分位，正是文中 P99 的定义。
6. threshold = p95 * 1.5动态阈值策略：超过 P95 的 1.5 倍即视为异常，避免固定阈值失效。
7. anomalies = [t for t in totals if t > threshold]找出所有超过阈值的异常请求，等价于告警触发的候选集合。

常见误区

面试题