核心要点
先看分布与分段：是 P99 翘尾还是整体上移；用 trace 拆分检索/特征/推理/网络各段耗时
查容量与排队：流量突增导致请求排队、batch 变大或资源打满，看 QPS、队列长度、GPU/CPU 利用率
查缓存与依赖：缓存命中率骤降、下游服务（特征库/向量库/DB）变慢或超时重试放大延迟
查运行时抖动：GC/显存碎片、冷启动/扩容、慢查询、网络抖动，对照变更与发布时间线
标准回答
先定位「慢在哪一段」，再查「为什么慢」（独占一行）
第一步看监控：延迟是整体上移还是 P99 长尾翘尾，发生在什么时间点，是否对齐某次发布或流量变化。然后用分布式 trace/可观测性 把一次请求拆成检索→特征→模型推理→后处理→网络各段，找出耗时暴涨的环节。
容量与排队
流量突增时请求在服务前排队，等待时间计入端到端延迟；同时动态批处理会把 batch 攒大、单请求等待变长。查 QPS、队列长度、并发数与 GPU/CPU/显存利用率是否打满，必要时扩容或调小批等待窗口。
缓存与下游依赖
缓存（结果缓存/KV/向量索引）命中率骤降会让大量请求走慢路径；下游特征库、向量库、数据库变慢或超时触发重试，会放大整体延迟。逐个依赖看其自身延迟与错误率。
运行时与基础设施
GC 暂停、显存碎片、实例冷启动/弹性扩容、慢查询、网络抖动、节点异常都会造成尖刺。对照发布、配置变更、依赖升级时间线定位（推理层优化见 推理服务架构）。
常见误区
⚠️ 常见踩坑
只盯平均延迟，忽略 P99 长尾与排队等待；或一上来就扩容，却没先用 trace 分段定位——结果慢的是某个下游依赖或缓存失效，扩容并不解决根因。
追问
追问 1：平均延迟正常但 P99 突然翘尾，通常是什么原因？
长尾翘尾多由间歇性事件造成：GC 暂停、冷启动/扩容实例、偶发慢查询、缓存未命中走慢路径、批处理把个别请求攒进大 batch、或某个下游依赖偶发超时重试。应抓尾部慢请求的 trace 单独分析，而非看均值。
追问 2：动态批处理（continuous batching）如何影响延迟？
它通过攒批提升吞吐和 GPU 利用率，但单请求要等待凑批，等待窗口越大、batch 越大，单请求延迟越高。需在吞吐与延迟间权衡：设置最大等待时间与最大 batch 上限，对低延迟场景调小等待窗口或单独走小批/独立实例。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。