简介这是一份面向目标检测开发与部署工程师的YOLOv7量化部署资源聚焦PTQ训练后量化与QAT量化感知训练两种压缩方式并配套基于TensorRT的C推理实现解决模型体积与推理效率优化落地问题。压缩包共134个文件、约35.14MB其中35个Python脚本负责量化与训练流程33个YAML文件提供模型与训练配置5个C源文件、8个头文件和1个CUDA内核共同构成TensorRT部署示例另有14个Jupyter Notebook便于分步复现实验。已有486人学习下载说明该主题在目标检测部署场景中具备实用参考价值。内容涵盖模型加载、输入预处理、TensorRT引擎构建、推理执行、检测结果解析与NMS后处理等关键环节PTQ方案可快速压缩模型、降低存储与计算开销QAT方案则在训练中模拟量化效应以保留更高精度。代码注释对构建选项与量化参数作了详细说明便于根据实际场景在速度与精度之间调整实现从训练、量化到部署的完整闭环。1. 折腾YOLOv7的PTQ和QAT训练及TensorRT部署第一关往往不是模型而是被INT8精度打懵你刚拿到一张T4或一块Jetson Orin把yolov7.pt转成TensorRT的FP16引擎跑起来挺流畅可一算路数就慌了视频流一多立刻掉帧。这时大多会想上INT8可直接把模型转成INT8 enginemAP可能从50掉到40甚至输出一堆空心框。这不是操作问题而是没走量化部署的正规流程。YOLOv7的INT8部署主流路径就两条训练后量化PTQ和量化感知训练QAT。PTQ不重训模型靠校准集统计每层激活分布几十分钟出结果QAT让模型在训练阶段预习INT8的舍入误差精度更稳但要花训练时间。下面把完整链路拆开讲覆盖选型、导出、校准、推理代码和踩坑记录适合做视频检测、边缘盒子和多路推理服务的工程师。2. 选ptq还是qat量化原理、精度代价与选型边界把模型从FP32压到INT8本质上是要给每层的权重和激活找一个缩放系数scale把连续的浮点分布映射到-128到127的整数格点上。INT8量化误差主要来自两个地方一是动态范围没卡准二是小数值在量化后直接变零。PTQ和QAT的分歧就在scale怎么定PTQ靠统计QAT靠训练。2.1 ptq三步走校准、校准缓存、构建INT8引擎PTQ全称Post-Training Quantization不需要反向传播。在已训练好的yolov7.pt上用一小批能代表实际场景的图片跑前向统计每一层激活值的分布然后算出每个tensor的scale和zero_point。TensorRT内部的entropy calibration会通过信息熵选一个让分布失真最小的阈值而不是简单用min/max这也是为什么它比直接取最大最小值更稳。常见做法是写一个继承trt.IInt8EntropyCalibrator2的校准器给TensorRT提供校准数据再把校准结果缓存到calib.cacheimport numpy as np import tensorrt as trt import pycuda.driver as cuda class YOLOv7EntropyCalibrator(trt.IInt8EntropyCalibrator2): def __init__(self, calib_files, batch_size8, input_size(640, 640)): super().__init__() self.batch_size batch_size self.input_size input_size self.batches self._load_batches(calib_files) self.batch_idx 0 # 一个batch占用的显存batch_size * 3 * H * W * 4字节fp32 self.device_buffer cuda.mem_alloc( self.batch_size * 3 * input_size[0] * input_size[1] * 4 ) def _load_batches(self, files): batches [] for i in range(0, len(files), self.batch_size): group files[i : i self.batch_size] # letterbox 归一化必须与训练时的预处理保持一致 arr np.stack([preprocess(f) for f in group]).astype(np.float32) batches.append(arr) return batches def get_batch_size(self): return self.batch_size def get_batch(self, names): if self.batch_idx len(self.batches): return None, None cuda.memcpy_htod(self.device_buffer, self.batches[self.batch_idx].ravel()) self.batch_idx 1 return [int(self.device_buffer)], list(names) def read_calibration_cache(self): try: with open(calib.cache, rb) as f: return f.read() except FileNotFoundError: return None def write_calibration_cache(self, cache): with open(calib.cache, wb) as f: f.write(cache)这个类做的事分三步先把图片在CPU侧完成letterbox和归一化再通过pycuda.memcpy_htod拷到GPU显存最后把显存地址交给TensorRT。get_batch返回None时TensorRT就认为校准数据已喂完开始计算量化参数。batch_size不是越大越好显存紧张时8是常用值校准图总数建议100到300张太少统计出的分布不稳定太多也未必更准关键是覆盖你要部署的真实场景。一句话经验read_calibration_cache返回的cache文件最好进版本库。它是整个INT8部署的后悔药校准数据丢了或者想换参数重来留着cache能少跑一遍前向。2.2 QAT微调用pytorch-quantization给yolov7插入伪量化节点QAT全称Quantization-Aware Training和PTQ完全不同。它在训练图里插入伪量化节点让网络在前向传播时就模拟INT8的舍入误差反向传播时梯度穿过这些节点权重被推到一个对INT8更友好的分布上。QAT经常比PTQ稳因为它把量化误差这个对手提前拉进训练场模型学会了规避。做YOLOv7的QAT我一般用NVIDIA的pytorch-quantization。关键一步是初始化必须在import模型类之前# 1. 必须在import yolov7 model class之前执行 from pytorch_quantization import quant_modules quant_modules.initialize() # 2. 再正常创建yolov7模型并加载权重 model create_yolov7(num_classes80).cuda() model.load_state_dict(torch.load(yolov7.pt)[model].state_dict()) # 3. QAT阶段的学习率要比正常训练低一个数量级 optimizer torch.optim.SGD( [p for p in model.parameters() if p.requires_grad], lr1e-4, momentum0.937, weight_decay5e-4, ) # 4. 先跑30个epoch让模型适应量化再用余弦退火降到1e-5量化模块会在初始化时把普通卷积替换成QuantConv2d之后模型forward路径里就带上了量化节点。加载FP16预训练权重后继续微调通常30到50个epoch能稳定下来。QAT的epoch数不值得一上来就照搬大规模训练见过最快收敛的是10个epoch就已经超过PTQ但前提是数据集不能太小。QAT的代价主要在训练资源数据加载和计算都比普通微调重一些。2.3 精度、成本与场景选型一张表看清楚我不能给一个放之四海的mAP数字但可以给经验区间和判断依据。下表是YOLOv7系列模型含tiny在项目中的常见表现以FP16为基线INT8后在同一套验证集上重新评测方案mAP保留经验值额外耗时需要资源适合场景FP16100%无仅构建精度敏感、算力够用PTQ95% ~ 99%几十分钟校准集快速上线、场景数据单一QAT99% ~ 101%数小时到数天训练GPU目标小、长尾多、掉点不可接受mAP保留超过100%并不奇怪量化在某些层上相当于一种正则偶尔能涨点。选型时如果项目今天就要出demoPTQ先跑如果模型要长期在盒子或服务器上服役且验证集的mAP掉点超过2个点直接转QAT别在PTQ上反复调校准集。QAT不是必须100个epoch从头练大多数项目用预训练权重加一段小学习率微调就够了。3. 从yolov7.pt到onnx导出命令、算子精简与dynamic形状处理无论走PTQ还是QAT最后都要先把PyTorch模型导出成TensorRT能吃的中间格式。ONNX是目前最通用的选择但导出质量直接决定后面的engine能不能构建成功、算子能不能被TensorRT高效执行。3.1 用官方export.py导出onnxYOLOv7官方仓库自带export.py最常见的导出命令是python export.py \ --weights yolov7.pt \ --img-size 640 \ --batch-size 1 \ --simplify \ --dynamic \ --include onnx--img-size 640把输入固定成640x640这个尺寸要在后续TensorRT构建和推理时保持一致如果换尺寸就要重新导出、重新校准。--simplify会调用onnx-simplifier做常量折叠和冗余消除这个参数强烈建议开着。--dynamic给输入输出加dynamic axes用于后续跑动态batch或动态分辨率如果部署路径固定是单batch、640输入可以不开engine会更简单。有一点很多人会踩导出时如果模型没切到eval模式ONNX里的BN层统计和dropout状态可能不一致。所以导出前记得model.eval()并确认权重路径正确。我用yolov7.pt导出时习惯把输出形状打印出来对一眼。常规COCO模型不带NMS的输出是[1, 25200, 85]25200来自640分辨率在三个stride下的anchor总数。如果导出的ONNX是dynamic shape后面的trtexec构建时就需要显式指定--shapes否则TensorRT默认使用第一个binding的shape。这一条很容易被忽略很多人导出了dynamic模型却在构建时忘了给shape结果build出的engine是1x3x640x640实际送进去的是1x3x416x416运行时不报错但结果全乱。3.2 后处理留在哪里ONNX不带NMS的理由YOLOv7原生输出的是解码后的框信息每个anchor一行x1、y1、x2、y2、objectness、80个类别的分数。常见做法是让模型只导出到这一步NMS放到TensorRT的后续处理里。原因有两个一是TensorRT对NMS的支持在普通模型上要借plugin导成带NMS的ONNX容易引入版本匹配问题二是后处理放在外部数据流更透明方便调试每一个框是怎么被滤掉的。把NMS外置还有一个实际好处QAT导出的模型比普通模型更容易出现异常输出先看解码后的原始分数能快速分出是量化坏了还是NMS参数不对。我一般会在Python侧用非极大值抑制做后处理如果对吞吐要求很苛刻再考虑在TensorRT里接入Efficient NMS plugin把NMS也挪到GPU上但那是进阶优化先把外置NMS跑通再谈。NMS外置后有一个隐性参数要写死decode后的输出是[1, 25200, 85]85这个数字在后续解析时不能改。anchor数3stride8/16/32640输入时加起来是25200。一旦换输入尺寸25200要重新算它是部署时最容易写错的数字之一。3.3 版本与算子检查opset、onnxsim、onnxruntime验证导出之后立刻做三件事。第一件事是跑onnx.checker确认图结构合法import onnx m onnx.load(yolov7.onnx) onnx.checker.check_model(m) print(onnx.helper.printable_graph(m.graph))第二件事是确认opset大小合适。TensorRT对不同opset的支持范围有差异常见做法是用opset 11到13太新的算子可能不被当前TensorRT的onnx parser识别。第三件事是用onnxruntime在CPU或GPU上跑一张图先验证输出shape和预期的[1,25200,85]一致再检查有没有NaN。这个前置检查能拦掉相当一部分“TensorRT构建报错”的翻车——不是TensorRT的问题是ONNX早就坏了。注意如果导出后提示某些算子不支持先跑onnx-simplifier它能处理掉不少冗余结构。仍然不行再考虑升级TensorRT或换导出口径。QAT导出的模型会带Q/DQ节点这个必须保留不要用simplifier过度折叠把它们消掉否则后面INT8显式量化会失效。4. TensorRT部署engine构建、校准缓存与推理管线ONNX只是中间产物真正在GPU上跑的是TensorRT engine。构建engine时TensorRT会做层融合、精度选择、kernel autotuning这步耗时几分钟到十几分钟但换来的是推理延迟的大幅下降。4.1 用trtexec构建INT8/FP16引擎trtexec是快速验证的好工具不用写代码就能完成校准和engine构建。INT8的典型命令trtexec \ --onnxyolov7.onnx \ --int8 \ --fp16 \ --calibcalib.cache \ --saveEngineyolov7_int8.trt \ --avgRuns100--fp16和--int8同时给是让TensorRT对每一层自行选择精度--calib指定校准缓存如果标注了之前PTQ阶段生成的cache文件TensorRT会直接复用不再跑校准。若没有cacheTensorRT会要求你提供校准数据。老版本的--workspace参数在新版trtexec里改叫--memPoolSize我用--memPoolSizeworkspace:2048内存池太大编译反而变慢。构建完成后引擎是否可用用同一命令不带--saveEngine再跑一遍观察--avgRuns输出的平均延迟。trtexec默认用随机输入做性能测试所以这个延迟只代表纯推理耗时不含真实前处理和后处理。4.2 Python推理管线从预处理到后处理engine构建完成后部署侧写一个Python推理类是常见做法。核心代码是这样import numpy as np import tensorrt as trt import pycuda.driver as cuda import torchvision class YOLOv7TensorRT: def __init__(self, engine_path, input_size(640, 640), conf_thres0.25, iou_thres0.45): self.logger trt.Logger(trt.Logger.WARNING) runtime trt.Runtime(self.logger) with open(engine_path, rb) as f: self.engine runtime.deserialize_cuda_engine(f.read()) self.context self.engine.create_execution_context() self.input_size input_size self.conf_thres conf_thres self.iou_thres iou_thres # 绑定名在导出时确认过是 input / output self.input_idx self.engine.get_binding_index(input) self.output_idx self.engine.get_binding_index(output) self.input_shape (1, 3, *input_size) self.engine_out_shape (1, 25200, 85) # 分配GPU显存只分配一次不要在每帧里重组 self.input_buf cuda.mem_alloc(1 * 3 * 640 * 640 * 4) self.output_buf cuda.mem_alloc(int(np.prod(self.engine_out_shape)) * 4) self.output np.zeros(self.engine_out_shape, dtypenp.float32) self.stream cuda.Stream() def infer(self, img_rgb): # 1. letterbox 归一化rgb的通道序和归一化系数与训练时一致 input_data letterbox(img_rgb, self.input_size).astype(np.float32) cuda.memcpy_htod_async(self.input_buf, input_data.ravel(), self.stream) self.context.execute_async_v2( bindings[int(self.input_buf), int(self.output_buf)], stream_handleself.stream.handle, ) cuda.memcpy_dtoh_async(self.output, self.output_buf, self.stream) self.stream.synchronize() preds self.output.reshape(self.engine_out_shape) return self.postprocess(preds) def postprocess(self, preds): # 2. 按置信度过滤再做NMS boxes, scores decode_yolov7_output(preds) # [N,4] [N,80] keep scores.max(axis-1) self.conf_thres boxes, scores boxes[keep], scores[keep] return torchvision.ops.nms(boxes, scores, self.iou_thres)execute_async_v2是异步调用务必配套使用stream并做同步否则会读到未完成的输出。bindings列表里必须是GPU显存地址的整数形式不能直接传numpy数组。所有显存buffer分配一次、反复使用不要在每帧里重新malloc那是吞吐量的头号杀手。letterbox和decode_yolov7_output按你自己的训练实现来写重点是对齐预处理和后处理细节。4.3 多路吞吐预算T4 1080p25帧怎么算很多人关心“T4上1080p25帧每秒、YOLO 640分辨率检测能支持多少路”本质是一个乘法题。先跑一次干净benchmarktrtexec --loadEngineyolov7_int8.trt --shapesinput:1x3x640x640 --avgRuns100假设输出的纯推理latency是4ms。每路25fps意味着40ms内要完成一帧推理加上预处理、后处理、数据搬移通常至少再占推理耗时的1到2倍所以单路预算不是40ms而是20ms左右。用总预算除以单路耗时理论极限约4路。工程上按50%冗余设计2路更稳。如果瓶颈在预处理可以用多进程或GPU上的预处理缓解。不建议直接在trtexec的延迟上乘路数trtexec测的是单context串行延迟多路时涉及多个context并发或batch调度真实吞吐要拿自己的完整推理管线压测。5. yolov7量化部署避坑指南5个真实翻车现场与修复方法量化部署的坑往往不在量化本身而在数据、预处理和版本。下面5条都是实际项目中反复出现过的。5.1 校准集和部署场景差太远PTQ后输出全是空框现象PTQ构建成功跑起来准确率骤降甚至整帧检不出目标。 原因校准数据来源和部署数据分布不一致。常见错误是顺手从训练集里拿了一堆不含待检测目标或全是单类别物体的图去校准导致激活分布统计偏差。 解决从部署环境抽取代表性数据或从验证集按类别均匀抽样200到300张保证覆盖小目标、模糊目标和不同光照。校准集不一定要多但一定要像部署时的真实数据。5.2 预处理通道序写反FP16和INT8都掉点现象同一模型在PyTorch里正常TensorRT里无论哪个精度都明显掉点。 原因训练时用的是RGB归一化部署时读取的是BGR图或者归一化系数没对齐。TensorRT构建和推理本身不会纠正这些。 解决把训练代码里的预处理逻辑原样拷贝到部署端逐行对一遍通道顺序、归一化因子、letterbox的填充值。一个简单有效的验证方法是拿同一张图在PyTorch和TensorRT两端分别输出检测结果差异过大就逐层定位。5.3 per-channel配置不对mAP悄悄掉几个点现象PTQ整体精度能接受但某些类别明显变差同一天同一个模型两次校准精度不一样。 原因TensorRT的INT8校准支持per-tensor和per-channel两种粒度。per-tensor用一个scale描述整层遇到权重分布长尾就吃亏per-channel对每个输出通道单独统计精度更稳但计算和内存略高。 解决在trtexec或API构建时显式选择per-channel校准并固定随机种子、固定校准集顺序。校准本身有随机性不固定seed会得到不可复现的结果。5.4 QAT训练发散loss一路飘现象QAT阶段loss不降反升甚至到第几个epoch直接变成NaN。 原因学习率没有降下来或者加载预训练权重后多个量化节点让梯度尺度变化原来的SGD参数不再适用。 解决把初始学习率降到正常训练的十分之一加warmup再用余弦退火收敛到1e-5。另一个经验是先把BN层一起参与前几轮训练不要一上来就冻结BN冻结太早会让量化在激活分布上毫无适应空间。5.5 TensorRT版本与opset不匹配构建时直接报错现象TensorRT报不认识某个op或构建到一半就挂掉。 原因ONNX的opset版本太新当前TensorRT的onnx parser没实现对应算子也可能是simplifier把Q/DQ节点或多边形结构折叠得过于激进。 解决固定opset11或12导出先跑onnx-simplifier再检查。QAT导出后绝不要用默认强度把量化节点全折叠做simplify之前先确认Q/DQ还在。最后升级TensorRT或用对应版本的官方容器镜像构建能省掉一堆版本兼容的烦心事。6. QAT微调的正确姿势用更小学习率找回精度QAT不是把量化当成事后补救而是让模型在训练阶段就适应INT8的数值世界。这里分享几个省时间的做法。第一微调前先用FP16跑5到10个epoch把训练状态稳定下来再插入量化节点开始QAT。这样量化节点接入时模型已经处于一个比较平稳的loss盆地不容易在早期被扰动带飞。第二在数据集大、类别多的场景里不要把所有层都冻结backbone前几层可以解冻参与训练但检测头部分用更低的学习率多学一会儿。量化误差主要出在激活值范围大的层尤其是head部分值得给它更多适应空间。第三QAT的epoch不贪多30到50个epoch没有继续改善就手动早停别让它过拟合到训练集。做法上我每次改完量化配置后固定使用同一组验证集对比FP16和INT8两个enginetrtexec --loadEngineyolov7_fp16.trt --shapesinput:1x3x640x640 --avgRuns100 trtexec --loadEngineyolov7_int8.trt --shapesinput:1x3x640x640 --avgRuns100如果INT8的mAP与FP16差在1到2个点以内说明量化配置基本健康差得多了先回查校准集和preprocessing再考虑加QAT轮数。我现在的习惯是任何模型上线前都先留一版FP16 engine做回归基线量化方案动过任何参数都重跑一遍验证集不拿只跑了一次的INT8结果直接上生产。等这套流程跑顺了你会发现量化掉点不再是玄学而是一笔可以预估的工程成本。希望帮到你。本文还有配套的精品资源点击获取