降低模型推理延迟，先别急着换硬件或压缩模型。请求可能耗时在排队、数据准备、算子执行、结果整理或网络传输，瓶颈不同，办法也不同。有效的模型推理延迟优化策略，应从可重复的测量开始，逐层缩小问题范围。
先把“延迟”拆成可观察的部分
分别记录端到端延迟与模型执行时间，并至少查看中位数和高分位数（如 P95）。前者反映多数请求，后者更容易暴露排队、长输入或资源争用。对生成式模型，还要区分首 token 延迟（TTFT）与后续 token 间隔；对 BERT 这类编码器模型，则重点看不同输入长度下的单次推理时间。
建立基线时，固定模型版本、输入样本、并发量和运行环境，先预热，再重复测量。把请求等待、预处理、推理、后处理及返回结果分开计时。若端到端明显慢于模型执行，继续优化算子通常收益有限，应先检查服务排队和数据搬运。
从算子和精度入手，确认计算是否值得
找热点，再尝试融合
查看逐算子耗时、设备利用率和内存占用，找出反复执行且耗时集中的算子。算子融合可减少中间结果写回和调度开销，但并非所有图都能融合；动态形状、复杂控制流或不受支持的算子，可能让编译优化无法覆盖整段计算。可比较原始执行与 ONNX Runtime、OpenVINO 等运行时的结果，并确认所用执行后端确实支持目标算子。
精度优化要用任务指标兜底
若计算受限，可测试 FP16、BF16 或 INT8 等较低精度路径。量化推理可能降低计算与内存开销，但效果取决于硬件、模型结构和校准数据；少数任务会出现精度下降。每次只改一种精度设置，用固定验证集比较准确率或任务指标，同时复测延迟和吞吐。不能只看单个算子的速度。
按模型类型优化内存与批处理
自回归生成模型会逐 token 计算，KV 缓存能保留已有 token 的键和值，避免重复计算历史内容；但缓存占用会随并发请求和上下文长度增加。长提示词场景应同时监测显存或设备内存、请求数和生成速度。vLLM 等支持连续批处理的推理系统，能在请求到达和结束时调整批次，适合输入长度、生成长度不一致的服务；代价是调度更复杂，仍需验证尾部延迟。
动态批处理能提高设备忙碌程度，却可能让先到请求等待凑批。交互式服务可先把最大等待时间设为约 1–5 毫秒做对照测试，再根据流量和延迟目标调整；这是起始测试范围，不是通用最佳值。离线任务通常可以接受更大的批次，以吞吐优先。固定批次更容易预测延迟，动态批次更能适应流量变化，但等待和批次波动需要纳入评估。
按顺序执行的调优步骤
- 固定输入长度、并发和模型版本，记录端到端延迟、执行时间、P95 与吞吐。
- 拆分排队、预处理、传输、推理和后处理时间，先处理占比最大的部分。
- 针对计算热点试算子融合或低精度，并用验证集检查输出质量。
- 比较不同批次大小及动态批处理等待上限，同时监控内存和高分位延迟。
- 每次只改一个变量；保留基线，确认收益在目标负载下可重复后再发布。
这套模型推理延迟优化策略的关键，不是追求某项孤立指标，而是让延迟、吞吐、内存和结果质量同时满足约束。优化后还应复测真实请求分布；输入长度或并发改变，最佳配置也可能随之改变。
常见问题
吞吐提高，为什么 P95 反而变差？
批次等待或资源竞争可能增加单个请求的排队时间。检查等待上限、并发量和长请求比例，分别比较 P50 与 P95。
应该先量化还是先做动态批处理？
先根据拆分结果判断瓶颈：计算占主导时测试量化推理；设备空闲且请求可合并时测试动态批处理。两者都要单独测量，再评估组合效果。
不同输入长度要分开测试吗？
要。短输入和长输入的计算量、缓存占用及排队影响不同；至少按常见长度区间分组比较。
优化后还需要重新测吗？
需要。模型、运行时、硬件或流量变化都可能改变瓶颈，应在目标负载下重新测量并保留对照结果。
