模型推理延迟优化策略不能只盯着单次生成速度：在线服务还要看并发增加时的排队、吞吐变化和输出质量。量化与动态批处理解决的问题不同，前者压缩模型权重，后者把时间上接近的请求合并计算。选型时应先定位瓶颈，再逐项验证，而不是同时更换精度和组批参数。
量化：减轻权重负担，效果取决于模型与内核
权重量化把参数从较高精度表示转换为较低位宽表示。以常见的 4 位权重方案为例，权重本身的存储量理论上可降至原来的约四分之一；实际显存还要容纳量化比例参数、激活值、缓存和运行时开销，因此总占用不会按同一比例下降。若模型原先因权重过大而无法完整放入显存，量化可能减少分片或数据搬运；若瓶颈在排队或输出阶段的计算，收益则未必明显。
可对比 GPTQ、AWQ 等量化方案，但不能只看位宽名称：推理框架、GPU 架构和对应算子是否支持，会影响实际速度。使用 Llama 3 这类生成模型时，应拿代表性提示词和目标输出长度做验证，检查事实问答、格式遵循及长文本任务是否退化。量化带来的显存余量，也可能让服务容纳更大的并发批次；但这属于间接收益，仍需实测。
动态批处理：用短暂等待换并行效率
动态批处理在请求到达后暂缓片刻，把多个请求合并执行。请求较密集、单次输入较短时，合批通常能提高硬件利用率和整体吞吐；请求稀疏时，等待本身就会增加响应时间。对自回归生成而言，各请求输入长度和生成进度不一，短请求可能被长请求拖慢，因此只增加批次规模，不一定改善每个用户的体验。
连续批处理进一步允许已完成的请求退出、后到请求加入，不必等整批任务全部结束。它适合请求持续流入的生成服务，但会增加调度复杂度，也需要留意显存中的缓存占用。动态批处理的等待预算应由响应目标和到达率决定，不能照搬其他服务的固定值。
怎样判断该先优化哪一项
这套模型推理延迟优化策略可以按以下顺序落地，避免把两种优化的收益混在一起：
- 建立基线。固定模型版本、输入长度、输出上限和硬件，记录不同并发下的中位延迟、慢请求分位数、吞吐及显存占用。测试负载应包括短输入与长输入。
- 单独测试量化。先保持调度设置不变，比较原始权重与候选量化版本的速度、显存和任务质量。若质量下降超过业务容忍范围，即使吞吐提升也不宜上线。
- 单独调组批。保持模型精度不变，逐步扩大可合并请求规模，并缩短或延长等待预算；观察吞吐提升是否以慢请求明显变长为代价。
- 组合复测。选出单项测试中可接受的方案后再组合，检查缓存占用、请求排队和异常输入下的稳定性。上线时保留回退配置，并用真实流量持续观察。
按瓶颈做取舍
如果模型权重占据主要显存，或权重读取限制了计算，优先评估量化；如果请求密集、单请求计算规模偏小，而设备常有空闲，则先评估动态批处理。两者也可能互补：量化腾出的空间支持更高并发，批处理再提高并行效率。不过，较大的批次可能拉长排队时间，量化也可能改变算子表现，组合效果不能从单项结果直接推断。可靠的模型推理延迟优化策略，应以相同负载下的延迟分布、吞吐和质量共同决策。
常见问题
量化后一定会更快吗？
不一定。若运行环境缺少高效量化算子，或瓶颈不在权重存取，速度提升可能有限；应同时核对硬件和框架支持。
动态批处理会降低单个请求延迟吗？
不保证。它常能改善并发吞吐，但等待组批和长短请求互相影响，可能让部分请求更慢。
应先优化量化还是批处理？
先看基线：显存或权重读取受限时先测量化；请求密集但设备利用不足时先测批处理，再分别验证组合效果。
只比较平均延迟够吗？
不够。还应检查慢请求分位数、吞吐、显存和任务质量，避免平均值掩盖少数请求明显变慢的问题。
