训练好的 AI 模型线上推理延迟高时，如何用量化、剪枝、TensorRT 和服务链路优化提速？｜Cider 算法面经解析

60 秒回答模板

我不会一上来就量化，先用 profiling 把延迟拆成预处理、模型前向、后处理、排队、网络和冷启动，并分别看 P50、P95、P99、吞吐、GPU 利用率、显存和错误率。模型侧可以做 FP16、INT8 或 INT4 量化，配合校准集验证精度损失；剪枝要区分结构化剪枝和非结构化剪枝，最好和微调、蒸馏一起做，否则稀疏不一定带来真实加速。部署侧可用 TensorRT 做算子融合、kernel 选择、常量折叠和 engine 编译，注意动态 shape、算子不支持和精度回退。服务侧要优化 batch、异步队列、并发模型实例、缓存、预热、连接复用、超时降级和自动扩缩容。验证时不能只看平均延迟，还要看精度回归、P99、峰值流量、冷启动、成本和回滚方案。

考点 先 profiling 再优化

难度 真实面经题

回答目标 先定位瓶颈，再说明模型、引擎和服务链路的优化取舍与验证方法。

深入解析

先定位延迟来源

线上延迟可能来自模型计算，也可能来自排队、输入解码、特征读取、后处理、网络、序列化或下游依赖。第一步应打点拆分端到端链路，记录 pre-process、inference、post-process、queue wait、RPC、cache、GPU kernel 时间和 batch 等待时间。只有确认瓶颈在模型前向时，量化、剪枝和 TensorRT 才是主战场。

量化、剪枝和蒸馏解决模型本体成本

量化通过降低权重和激活精度减少计算和访存，常见有 FP16、BF16、INT8、INT4。INT8 通常需要代表性校准集或量化感知训练，低比特量化要重点验证长尾输入和边界类别。剪枝通过删除不重要的通道、层、头或神经元降低计算量，但非结构化稀疏如果硬件和引擎不支持，可能只减少参数不减少延迟。蒸馏适合用小模型逼近大模型输出，在延迟要求很硬时比单纯剪枝更可控。

TensorRT 和推理引擎优化执行效率

TensorRT 的价值在于把训练框架图转换成更适合 GPU 推理的 engine，做算子融合、内存规划、kernel auto-tuning、精度选择和常量折叠。它对固定 shape 或少量 profile 的场景效果更稳定；动态 shape 很多时，engine 数量、编译时间和性能回退都要管理。还要关注不支持算子、插件实现、CPU fallback、输入输出拷贝和预处理是否仍在 Python 层。

服务链路决定 P99 和可用性

模型变快不代表线上体验一定变好。批处理能提升吞吐，但 batch 等待会拉高单请求延迟；并发实例能提升利用率，但会争抢显存和导致上下文切换；缓存能省计算，但要处理版本和一致性。服务层要有请求队列上限、超时、熔断、降级模型、预热池、连接复用、异步后处理和弹性扩容。验收时应在真实流量分布下压测，确认精度下降在可接受范围内，P99 达标，成本下降，异常时能自动回滚。

易错点

不做 profiling，直接回答量化、剪枝、TensorRT 三件套。
只看平均延迟，不看 P95/P99、吞吐、冷启动和错误率。
认为参数少就一定快，忽略硬件 kernel、访存和稀疏支持。
优化后不做精度回归和线上 A/B，导致速度提升但业务效果下降。
把 batch 调得越大越好，忽略 batch 等待对实时请求延迟的影响。

面试官追问

量化会不会一定降低效果？

不一定。FP16/BF16 通常影响较小，INT8 需要校准集或量化感知训练，INT4 风险更高。关键是用代表线上分布的样本做回归，分整体指标和长尾切片看精度、召回、置信度校准和业务指标变化。

剪枝为什么有时不加速？

如果只是非结构化地把权重置零，普通 GPU kernel 仍然按 dense 矩阵计算，就不会明显变快。真正推理加速通常需要结构化剪枝、稀疏 kernel 支持、重新导出模型和引擎重编译。

TensorRT 优化失败常见原因是什么？

常见问题包括动态 shape 太多、存在不支持算子、插件实现慢、精度回退到 FP32、CPU fallback、输入输出拷贝过多，以及 engine 没有预热。排查时要看 engine 构建日志、layer profile 和实际 kernel 时间。

如果只有 P99 很高，平均延迟正常怎么办？

重点查排队、冷启动、batch 等待、显存抖动、GC、下游依赖超时和流量突刺。P99 问题常常不是模型单次计算慢，而是资源竞争和队列控制不好，需要限流、隔离、预热和超时降级。