模型部署与推理优化

排错清单：OOM、长尾延迟与吞吐瓶颈的定位方法

kp-027进阶30 分钟07-端侧与实践

一句话定义

推理排错的方法论是"分层定位 + 单变量修改"：先按 负载 → 调度/容量 → 算子/硬件 → 数值/参数 四层把症状归类，再用对照实验逐项排除，本页给出高频症状的现成对照表。

为什么重要

生产事故不会等你从容分析：OOM 报警、P99 突刺、"吞吐比测试环境低 5 倍"是三类最常见告警，90% 的案例能在这页的表里直接对号入座。它也是最小可用路径的收口——前三小时学的所有账本与机制，在这里变成排查工具。

前置知识

  • kp-004（显存账本——一切 OOM 排查的起点）、kp-022（vLLM 指标与参数）、kp-002（延迟指标口径）。

核心概念：分层定位方法论

  1. 负载层：流量画像变了吗？（输入长度、输出长度、QPS、采样参数）——先对比历史 P50/P99 与请求长度分布，多数"性能变差"是流量变了。
  1. 调度/容量层：看 running/waiting、KV 池占用、抢占次数——指标会直接告诉你排队还是饱和（kp-022）。
  1. 算子/硬件层：nvidia-smi 的功耗与带宽、kernel 耗时 profile——确认是否触顶或降频。
  1. 数值/参数层：chat template、采样参数、量化档位、引擎版本——输出"内容异常"（而非"速度异常"）时先查这层。

铁律：一次只改一个变量；用固定 seed 与固定请求集做 A/B 复现。

原理与机制

分层定位有效的原因是因果链有序：流量决定调度压力，调度决定算子负载，算子与数值参数决定单步行为——任何故障的注入点必在链上某一层，且上游变化必然向下传导。因此自上而下逐层排除时，每层只需要一两个指标即可判真伪（负载层看长度分布、调度层看 running/waiting、算子层看功耗与带宽、参数层看 template 与采样），比"到处改参数碰运气"快一个数量级。

排错清单（症状 → 定位 → 处置）

  • 启动 OOM：重算账本（util×容量 − 权重 − 开销 ≤ 0？）→ 降 util/max-model-len → 加 TP；别忘了 CUDA Graph 与编译工作区的额外占用。
  • 运行中 OOM / 频繁抢占：并发或长请求超 KV 池 → 降 max-num-seqs、缩上下文、KV 量化，或加副本。
  • TTFT P99 突刺：waiting 队列深 → 容量不足；waiting 为零但 TTFT 高 → 长 prefill 阻塞（开 chunked prefill）或前缀缓存未命中（查路由亲和，kp-023）。
  • TPOT 全体变高：batch 过大（降并发）、降频（查功耗/温度）、或混入了长 prefill（PD 问题，kp-024 的 chunked 缓解）。
  • 吞吐远低于压测：对比线上与压测的请求长度分布与采样参数——"长输出多 30%"就足以解释一半差距；再看缓存命中率。
  • 输出质量异常（乱码/复读/格式错）：先查 chat template 与采样参数，再查量化档位兼容性（kp-009 排错表），最后才怀疑模型本身。
  • 偶发超时/断流：网关超时设置 < P99 TTFT、客户端重试风暴放大排队——先修超时预算再谈引擎。

图示

症状(慢/炸/错) → 负载层(流量变了吗?) → 调度层(排队还是饱和?)
             → 算子层(触顶/降频?) → 参数层(template/采样/量化)
每个分支: 固定seed复现 → 单变量修改 → 指标对比

实例或案例

典型案例复盘："上线长文本版后服务整体变慢 3 倍"。分层排查：负载层发现均值输入从 300 涨到 5k（流量变了）；调度层 waiting 堆积、KV 池占用 95%；处置 = 缩 max-model-len + 开 chunked prefill + 临时扩 2 副本，半小时恢复。教训：任何配置变更（尤其上下文长度）上线前必须重算显存账本并压测（kp-004/kp-002 的闭环）。

常见误区

  • "先重启再说"：重启清空 KV 缓存与统计信息，破坏现场；应先抓指标快照。
  • "用最大并发压一次就当容量结论"：容量是"SLO 约束下的并发"（goodput），不是"不崩的最大值"。
  • "同时改三个参数看哪个有用"：无法归因；单变量修改是排错纪律。
  • "把引擎日志当唯一真相"：指标（/metrics）、日志、账本计算三方互证才算定位。

自测题

  1. TTFT P99 突刺但 waiting 为零，下一步查什么？

要点：长 prefill 阻塞（chunked prefill）或前缀缓存未命中（路由亲和），属调度/缓存层。

  1. 运行中 OOM 的第一动作是什么？

要点：重算显存账本（KV 池 vs 当前并发×上下文），再决定降并发/缩上下文/加副本。

  1. 为什么排错要固定 seed？

要点：让"修改前后"的输出差异可归因于被改变量而非采样随机性。

与其他知识点的关系

调用 kp-004 的账本、kp-002 的度量、kp-022 的参数与指标；容量结论汇入 kp-028 的成本模型；本页与 kp-029 的误区清单互为表里。

延伸阅读

本节不适用——排错方法论以本页表格与所引知识点的机制为准，工具侧（nvidia-smi、引擎 metrics）按所用引擎文档查阅。

#排错#OOM#长尾延迟#吞吐瓶颈#方法论