简介一套围绕RepVgg骨干网络展开图像分类实战的完整资源包面向有一定深度学习基础、希望从原理走向项目落地的开发者。RepVgg采用plain前馈架构、仅使用3x3卷积和ReLU激活在训练与推理阶段通过结构重参数化兼顾精度与速度这套资源正是该思路的动手实践。包体约986.61MB共2000个文件主要包含12个Python脚本、2个pth权重文件、2个json配置、1个txt说明与2435张png图像样本py文件覆盖数据加载、模型定义和训练流程png图片用于构建分类数据集pth权重可直接加载做推理或迁移学习。已有990人学习下载资源同时提供result.json等训练输出方便对照指标验证复现效果。通过完整项目可掌握RepVgg结构重参数化实现、图像分类任务的数据组织与训练调优流程是一份难得的端到端复现资料。1. RepVgg实战前先搞懂一件事VGG式到底指什么我最近拿到一份图像分类算法实战资源主题是RepVgg——这个把VGG的简洁和训练时的多分支优势合在一起的模型正好覆盖我手上那个森林图像分类需求的推理速度线。整个包看下来的感受是它不是文档拼凑而是把训练、推理、转换三段串成了能直接跑的流程class.json、result.json以及一批样例图都给你备齐跑完能自己核对不用瞎猜模型到底学没学会。适合谁呢刚把PyTorch跑熟、想换一个更快更轻的图像分类模型的新手以及被最近一批最新的图像分类模型惯坏了、想回到可控结构的老手。这篇我按自己能复现的标准拆给你。2. RepVGG结构与重参数化原理训练和推理为什么是两套图2.1 从VGG到RepVGGplain架构和3x3卷积的执念做图像分类的人对VGG都不陌生一路3x3卷积叠下去没有任何分支结构简单到一眼能画出计算图。RepVGG把这种VGG式原则重新捡了起来定义也很硬核没有分支即plain或feed-forward架构只使用3x3卷积只使用ReLU激活函数。没有了残差连接没有了Inception那类多尺度分支也没有了注意力机制。这不代表RepVGG是倒退。它想解决一个很现实的问题像ResNet这样的多分支模型在推理时加法、拼接、跳跃连接这些操作会占用显存、打断内存连续访问对部署和延迟都不友好而VGG式模型虽然推理快但训练精度上不去因为缺少梯度回传的捷径。RepVGG的做法是训练时用多分支结构把精度撑上去推理时通过结构重参数化把多分支等价合并成单路3x3卷积。这套思路在你拿到手跑一遍之后会特别有体感——训练图和部署图确实是两套图代码也是两套流程。我在实际选择模型时常常在ResNet和RepVGG之间纠结。ResNet生态成熟预训练权重好找但一旦到了边缘设备或者要上ONNX做定点量化RepVGG这条单路径结构的优势就体现出来了。因为单路径卷积可以完整映射到cuDNN的卷积算子不用为shortcut分支额外拷贝内存。这个资源包的代码里也保留了不同depth配置的构造入口你可以直接换A0、A1甚至B0这些变体改动只在两个列表上。2.2 重参数化实现多分支变单分支的数学推导训练时一个标准的RepVGG Block由三个分支组成一个3x3卷积加BN、一个1x1卷积加BN、以及一个identity分支加BN。在stride1时这三条分支全开stride2时为了对齐尺寸只保留3x3卷积分支。推理时要做的事情就是把每个分支里的Conv和BN先融合成带偏置的卷积再把1x1卷积pad成3x3、把identity写成单位卷积核最后把三个卷积核和三个偏置按位相加。这段逻辑不复杂难在每一步的向量维度对齐。Conv加BN融合是重参数化的基础。BN在训练时维护一批数据的均值μ和方差σ²同时有两个可学习参数γ和β。推理时BN的计算是y γ*(x-μ)/sqrt(σ²ε)β这正好可以吸收到卷积里权重W乘γ/sqrt(σ²ε)偏置变成β - μ*γ/sqrt(σ²ε)。注意原来的卷积如果不带偏置融合后偏置不为零这就是为什么重参数化之后所有层都带bias。下面这段是三个分支融合的完整算子import torch import torch.nn as nn import torch.nn.functional as F def fuse_conv_bn(conv, bn): # 把一层ConvBN等价转换为带偏置的Conv gamma bn.weight.data beta bn.bias.data mean bn.running_mean var bn.running_var eps bn.eps w conv.weight.data * (gamma / torch.sqrt(var eps)).view( -1, 1, 1, 1) if conv.bias is None: b beta - mean * gamma / torch.sqrt(var eps) else: b conv.bias.data * (gamma / torch.sqrt(var eps)) \ beta - mean * gamma / torch.sqrt(var eps) fused_conv nn.Conv2d(conv.in_channels, conv.out_channels, conv.kernel_size, strideconv.stride, paddingconv.padding, biasTrue) fused_conv.weight.data w fused_conv.bias.data b return fused_conv def merge_block(conv3, bn3, conv1None, bn1None, bn_idNone): # 3x3卷积分支 c3, b3 fuse_conv_bn(conv3, bn3) if conv1 is not None and bn1 is not None: # 1x1卷积融合后pad成3x3形状 c1, b1 fuse_conv_bn(conv1, bn1) pad_w F.pad(c1.weight.data, [1, 1, 1, 1]) c1 nn.Conv2d(c1.in_channels, c1.out_channels, 3, stride1, padding1, biasTrue) c1.weight.data pad_w c1.bias.data b1 else: c1, b1 None, None if bn_id is not None: # identity分支写成一个中心为1的单位卷积核 gamma bn_id.weight.data beta bn_id.bias.data mean bn_id.running_mean var bn_id.running_var kernel torch.zeros(conv3.in_channels, conv3.in_channels, 3, 3) for i in range(conv3.in_channels): kernel[i, i, 1, 1] 1.0 kernel kernel * (gamma / torch.sqrt(var eps)).view(-1, 1, 1, 1) bias beta - mean * gamma / torch.sqrt(var eps) else: kernel, bias None, None out_w c3.weight.data.clone() out_b c3.bias.data.clone() if c1 is not None: out_w c1.weight.data out_b c1.bias.data if kernel is not None: out_w kernel out_b bias conv nn.Conv2d(conv3.in_channels, conv3.out_channels, 3, strideconv3.stride, paddingconv3.padding, biasTrue) conv.weight.data out_w conv.bias.data out_b return conv这段代码有两个关键参数你要盯住。一个是eps它来自BN层的配置通常默认1e-5融合时一定要和BN层里的一致否则精度对不上。另一个是1x1卷积pad时的四个1这对应3x3卷积核四周补一圈零保证卷积中心对齐。我在第一次复现时把pad写成了[0,0,1,1]结果融合后的输出和原训练模型对不上排查了半天才发现是左右没补全。2.3 用代码验证重参数化结果张量级对比重参数化最容易踩的坑是改完结构精度掉了但很多情况不是模型学坏了而是融合代码本身有bug。我的习惯是在转换前存一份训练态模型和一份随机输入转换后再喂同样的输入用torch.allclose做张量级对比误差小于1e-4就算合格。import torch model_train RepVGG(num_classes10) model_train.eval() x torch.randn(4, 3, 224, 224) with torch.no_grad(): y_train model_train(x) model_deploy repvgg_to_deploy(model_train) # 转换入口 model_deploy.eval() with torch.no_grad(): y_deploy model_deploy(x) diff (y_train - y_deploy).abs().max().item() assert diff 1e-4, f重参数化前后输出差异过大: {diff:.6f}这段验证逻辑要跑在转换之后、任何训练或微调之前。因为重参数化是一个不可逆过程一旦把多分支合并成单分支你就再也没办法把梯度传回三个分支了。所以我一般在训练流程的最后做转换转换前保存一份原始权重做备份这就是我的后悔药。后面第5章会专门讲这个操作的各种翻车现场。3. 用RepVgg跑通图像分类数据准备、训练配置与checkpoint说明3.1 数据集目录结构与class.json/result.json的作用这份资源包里没有附带大型数据集但给了两个标注文件和一个样例图集合这是我认为整套资源最贴心的部分。class.json是类别映射文件格式一般是{forest_a: 0, forest_b: 1, ...}它决定了分类头的输出维度也决定了训练时DataLoader从文件夹名读到的标签如何变成Tensor。result.json是模型推理结果的输出样例通常长这样{ 77291b3ad.png: {class: forest_a, score: 0.982}, 5a8b75712.png: {class: forest_b, score: 0.014} }训练和推理都要以这两个文件为锚点训练前检查类别数和class.json的key数量是否一致推理后检查results的key是否和待测图片一一对应。我给森林图像分类项目做数据处理时最常用的是ImageFolder结构因为PyTorch原生支持按文件夹名生成标签。data/ train/ forest_a/ img_001.jpg img_002.jpg forest_b/ img_003.jpg val/ forest_a/ img_101.jpg forest_b/ img_103.jpg如果原始数据不是这个结构转换脚本也很简单读class.json为每个类别建文件夹把图片复制进去。注意文件后缀要统一我之前混用了jpg和png两种格式训练过程没什么异常但到了部署阶段用OpenCV读图时颜色通道错位排查了三小时才发现是后缀欺骗了读取逻辑。3.2 训练脚本参数详解与日志怎么看RepVGG训练时是有三条分支的所以显存占用会比同参数量的VGG高但这是预期内的毕竟精度是靠多分支撑起来的。训练脚本的核心结构如下你可以直接照着这个骨架改import argparse, json, torch from torch import nn from torch.utils.data import DataLoader from torchvision.datasets import ImageFolder from torchvision.transforms import Compose, Resize, CenterCrop, ToTensor, Normalize parser argparse.ArgumentParser() parser.add_argument(--data, default./data) parser.add_argument(--epochs, typeint, default120) parser.add_argument(--batch-size, typeint, default64) parser.add_argument(--lr, typefloat, default0.1) parser.add_argument(--num-classes, typeint, default2) args parser.parse_args() transform Compose([ Resize(256), CenterCrop(224), ToTensor(), Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]), ]) train_set ImageFolder(args.data /train, transformtransform) train_loader DataLoader(train_set, batch_sizeargs.batch_size, shuffleTrue, num_workers4, pin_memoryTrue) val_set ImageFolder(args.data /val, transformtransform) val_loader DataLoader(val_set, batch_size64, shuffleFalse) model RepVGG(num_classesargs.num_classes) optimizer torch.optim.SGD(model.parameters(), lrargs.lr, momentum0.9, weight_decay1e-4) scheduler torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_maxargs.epochs) criterion nn.CrossEntropyLoss()这段配置有几个点要展开说。batch size我用64而不是更大的128是因为RepVGG训练态每个block有三个卷积分支反向传播时需要保存三份中间激活在8G显存的卡上64配224输入是比较稳的。学习率0.1搭配SGD是图像分类任务的常见组合配合cosine退火可以见到后期loss稳稳下降如果你换成Adam学习率建议降到1e-3附近。训练循环本身和常规分类任务没什么区别唯一要注意的是一定要全程保持model.train()因为BN层在训练态和推理态的逻辑完全不同。BN的running_mean和running_var是在训练时滚动更新的这些统计量最终会被融合进卷积核。如果中途为了做验证切到model.eval()再切回来只要optimizer步进正常问题不大但如果忘了切回train模式BN的统计量停更训练出来的模型在融合后精度会明显下降。3.3 断点续训和提交测试完整流程训练日志里你需要关注的不只是loss。我一般每5个epoch跑一次验证集准确率同时保存一份ckpt_last.pth用于断点续训。断点续训的代码很简单但要把模型、优化器、scheduler和epoch数都存下来checkpoint { model: model.state_dict(), optimizer: optimizer.state_dict(), scheduler: scheduler.state_dict(), epoch: epoch, } torch.save(checkpoint, ckpt_last.pth)续训时加载后还需要手动恢复四项状态缺了schedulercosine退火的学习率就会从头开始算相当于训练过程被割裂了。资源包里提到的result.json就派上用场了训练完拿val图跑一遍推理和包里的result.json做格式对齐——字段名、类别名、score的取值范围都要一致这样提交到评测平台时才不会因为格式问题被打回。4. 把训练模型变成部署模型推理转换的完整实现4.1 重参数化转换函数代码与逐步解释训练完的模型不能直接上生产原因前面说过三个分支在推理时是纯浪费。转换的过程在源码实现上通常叫repvgg_to_deploy它遍历模型的每一层找到带三个分支的Block调用merge_block完成融合然后把模型结构替换成单分支版本。def repvgg_to_deploy(model): for name, module in list(model.named_modules()): if hasattr(module, merge) and callable(module.merge): module.merge() # Block内部自行完成分支融合 return model这种实现的假设是每个Block内部自己实现了merge方法。如果你拿到的源码里Block结构是显式的conv3、bn3、conv1、bn1、bn_id那转换逻辑就应该显式遍历def repvgg_block_to_deploy(block): if block.stride 1: return merge_block(block.conv3, block.bn3, block.conv1, block.bn1, block.bn_id) else: # stride2时只有3x3分支 return fuse_conv_bn(block.conv3, block.bn3)需要注意merge()调用一次就够了。因为融合后的Block结构里不再有conv1和bn_id第二次调用时会走分支判断逻辑可能报KeyError如果你的转换代码允许重复执行一定要在第一次转换后把结构标志位置为False或者直接重建一个部署模型。4.2 模型验证PyTorch推理与ONNX导出转换完成后别急着上服务先做三件验证第一是输入输出张量对比这在2.3节已经做过第二是单张图推理和整图分类结果是否合理第三是导出ONNX再检查一遍算子结构。import torch.onnx model_deploy.eval() dummy torch.randn(1, 3, 224, 224) torch.onnx.export( model_deploy, dummy, repvgg_deploy.onnx, input_names[input], output_names[output], opset_version12, dynamic_axes{input: {0: batch}, output: {0: batch}}, )ONNX导出时我习惯加上dynamic_axes这样导出的模型能接受任意batch。但有个代价动态维度下某些推理框架的优化会变保守如果你的部署环境是固定的batch1干脆去掉dynamic_axesTensorRT或OpenVINO能做得更好的图优化。opset_version我一般选12兼容性和新算子支持都平衡。ONNX导出后还要做一次数值对齐这里有个容易被忽略的点用torch.onnx.export导出的模型默认走的是PyTorch的跟踪模式如果你的转换函数里有任何控制流比如for循环里判断stride跟踪会把所有分支都展开执行这可能让导出的模型结构和你预想的不一样。解决方法是导出一个已经完成重参数化的模型而不是在导出时动态做转换。4.3 推理脚本与内存/速度表现部署推理的完整流程我一般拆成四段读图、预处理、前向、解析。预处理必须和训练时完全一致——Resize(256)、CenterCrop(224)、标准化——任何一步不一样都会让精度崩掉。import json, torch from PIL import Image from torchvision.transforms import Compose, Resize, CenterCrop, ToTensor, Normalize transform Compose([Resize(256), CenterCrop(224), ToTensor(), Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225])]) def single_infer(model, image_path, class_map): img Image.open(image_path).convert(RGB) x transform(img).unsqueeze(0) with torch.no_grad(): logits model(x) prob torch.softmax(logits, dim1) cls_id logits.argmax(dim1).item() return class_map[str(cls_id)], prob[0, cls_id].item()推理时的显存占用相比训练态会显著下降因为多分支的相关计算和中间激活都被合并了。如果你在GPU上做批量推理建议把torch.no_grad()和model.eval()放在循环外避免每次都切换模型状态产生额外开销。CPU推理时线程数也可以用torch.set_num_threads控制通常在4到8个线程时性能收益最大。5. 避坑记录RepVgg训练和转换中的五个常见翻车点5.1 转换后精度暴跌差点以为模型废了现象重参数化完成后跑验证集准确率从90%掉到50%接近随机猜测。 原因转换前模型没有切到eval模式。训练态BN用于计算批统计量此时running_mean和running_var不会更新但卷积融合使用的是running统计量如果模型处于train模式个别模块还在走训练路径融合出的核就和实际推理行为不一致。 解决在repvgg_to_deploy之前强制model.eval()并且用torch.no_grad()包住转换过程。这个习惯我后来固定成模板转换、验证、导出都写在同一个脚本里不给中间状态留操作空间。5.2 排除到最后发现1x1卷积pad错了现象融合前后输出对比差异在1e-2量级肉眼能看出是全局偏置不对。 原因1x1卷积核向3x3扩展时四周补零的padding参数顺序写错。PyTorch的F.pad参数顺序是左、右、上、下我直觉以为先上后下实际上把左右和上下写反了导致卷积核的响应位置偏移。 解决写了一个专门的单元测试用随机初始化的1x1卷积和BN融合后和原分支逐元素对比。从那以后凡是涉及维度变换的算子我都会先跑一次单测再进入正式模型。5.3 用clip_grad_norm后融合模型完全不一样现象在训练脚本里加了梯度的全局裁剪训练loss正常下降loss曲线也算好看但转换后验证精度远低于转换前。 原因梯度裁剪本身不直接影响BN统计量但它改变了训练轨迹如果模型没有训练到充分收敛BN的running_mean和running_var还在大幅变化融合时对统计量的依赖就会放大误差。本质上不是融合的错是模型没训好。 解决检查转换前模型回头的验证精度是否和训练时一致。如果训练态模型本身在验证集上就低于90%先延长训练或调整学习率再进行转换。融合能等价保留精度但不会帮你修复没有收敛的模型。5.4 ONNX导出的动态batch和固定batch精度不一致现象同一个ONNX模型在固定batch1时输出完全正确一旦设置dynamic_axes并传入batch4某些输出的score顺序和PyTorch不一致。 原因动态维度下算子融合的保守策略不同尤其是当模型里存在Reshape和Transpose组合时优化器生成的等效计算图可能引入数值舍入差异。 解决在torch.onnx.export后用onnxruntime的OrtSession加载模型分别以batch1和batch4做对齐测试设定tolerance为1e-3。如果你部署侧只用到单图推理就直接删掉dynamic_axes少一个变量少一个坑。5.5 result.json格式错位导致评测白跑现象提交评测后准确率正常但报告里的混淆矩阵和本地验证完全不同部分图片的类别名对不上。 原因class.json里的类别顺序和模型输出logits的通道顺序不一致。比如class.json按字母序排序而模型输出头是按文件夹遍历顺序生成的两者的映射错位所有预测结果整体平移了一个索引。 解决推理脚本里不再手写数字到类别的映射一律在预测后读取class.json做查表。训练时也要把class.json的构建逻辑和数据集目录遍历逻辑统一用同一个函数生成避免两套排序。6. 验证模型有没有学对用混淆矩阵和特征图收尾训练结束、转换完成、推理接口也通了最后一个步骤我强烈建议你补上跑一遍混淆矩阵。我见过太多模型验证集准确率96%实际业务场景里对特定类别几乎全错的案例。准确率只有一个数字它掩盖了模型对某些类别的系统性偏见。这份资源后来我拿到手里的第一件事就是用它跑森林图像分类的混淆矩阵。import json, numpy as np, torch from sklearn.metrics import confusion_matrix def evaluate_cm(model, loader, class_map, device): model.eval() y_true, y_pred [], [] with torch.no_grad(): for x, y in loader: x, y x.to(device), y.to(device) logits model(x) y_pred.extend(logits.argmax(dim1).cpu().tolist()) y_true.extend(y.cpu().tolist()) cm confusion_matrix(y_true, y_pred) names list(class_map.keys()) print( .join(f{n[:4]:6} for n in names)) for i, row in enumerate(cm): print(f{names[i][:4]:6} .join(f{v:6} for v in row))这段代码里class_map的key顺序必须和模型输出通道一致这就是第5章第5条踩坑记录的现成应用。混淆矩阵的读法有一个优先级先看对角线再看紧邻类别的非对角线值。对森林图像分类来说如果草地和灌木频繁互相误判说明它们在颜色纹理上太接近模型没能学到区分性特征这种情况下可以考虑给这两个类别加权重或者做数据增强时叠加色彩扰动。我每次跑完混淆矩阵还会顺手做一件事把预测置信度最低的20张图单独输出到一个文件夹。这些图就是模型最犹豫的样本往往能暴露标注错误和类别边界的真实问题。比如有一次我发现低置信度样本里大量是逆光拍摄的树冠图数据增强里加一个随机亮度扰动后这类样本的预测就明显变好了。特征图的可视化比混淆矩阵更深一层但可以作为补充手段取最后一层卷积输出的每个通道做全局平均池化后画成热力图叠加在原图上。这个能快速确认RepVGG是不是把注意力放在了正确区域。如果目标树区域完全没被激活那说明训练存在更根本的分布偏移调参已经没用了回头查数据更实际。从那以后我每次训练完都不急着导出ONNX也不急着写部署接口先跑一遍混淆矩阵和低置信度样本检查确认模型是真的学对了才敢说可以上线。这个过程只需要十几分钟却能让后面的部署阶段少踩一半坑。希望帮到你。本文还有配套的精品资源点击获取 RepVGG实战：结构重参数化原理、训练与部署转换全攻略
简介一套围绕RepVgg骨干网络展开图像分类实战的完整资源包面向有一定深度学习基础、希望从原理走向项目落地的开发者。RepVgg采用plain前馈架构、仅使用3x3卷积和ReLU激活在训练与推理阶段通过结构重参数化兼顾精度与速度这套资源正是该思路的动手实践。包体约986.61MB共2000个文件主要包含12个Python脚本、2个pth权重文件、2个json配置、1个txt说明与2435张png图像样本py文件覆盖数据加载、模型定义和训练流程png图片用于构建分类数据集pth权重可直接加载做推理或迁移学习。已有990人学习下载资源同时提供result.json等训练输出方便对照指标验证复现效果。通过完整项目可掌握RepVgg结构重参数化实现、图像分类任务的数据组织与训练调优流程是一份难得的端到端复现资料。1. RepVgg实战前先搞懂一件事VGG式到底指什么我最近拿到一份图像分类算法实战资源主题是RepVgg——这个把VGG的简洁和训练时的多分支优势合在一起的模型正好覆盖我手上那个森林图像分类需求的推理速度线。整个包看下来的感受是它不是文档拼凑而是把训练、推理、转换三段串成了能直接跑的流程class.json、result.json以及一批样例图都给你备齐跑完能自己核对不用瞎猜模型到底学没学会。适合谁呢刚把PyTorch跑熟、想换一个更快更轻的图像分类模型的新手以及被最近一批最新的图像分类模型惯坏了、想回到可控结构的老手。这篇我按自己能复现的标准拆给你。2. RepVGG结构与重参数化原理训练和推理为什么是两套图2.1 从VGG到RepVGGplain架构和3x3卷积的执念做图像分类的人对VGG都不陌生一路3x3卷积叠下去没有任何分支结构简单到一眼能画出计算图。RepVGG把这种VGG式原则重新捡了起来定义也很硬核没有分支即plain或feed-forward架构只使用3x3卷积只使用ReLU激活函数。没有了残差连接没有了Inception那类多尺度分支也没有了注意力机制。这不代表RepVGG是倒退。它想解决一个很现实的问题像ResNet这样的多分支模型在推理时加法、拼接、跳跃连接这些操作会占用显存、打断内存连续访问对部署和延迟都不友好而VGG式模型虽然推理快但训练精度上不去因为缺少梯度回传的捷径。RepVGG的做法是训练时用多分支结构把精度撑上去推理时通过结构重参数化把多分支等价合并成单路3x3卷积。这套思路在你拿到手跑一遍之后会特别有体感——训练图和部署图确实是两套图代码也是两套流程。我在实际选择模型时常常在ResNet和RepVGG之间纠结。ResNet生态成熟预训练权重好找但一旦到了边缘设备或者要上ONNX做定点量化RepVGG这条单路径结构的优势就体现出来了。因为单路径卷积可以完整映射到cuDNN的卷积算子不用为shortcut分支额外拷贝内存。这个资源包的代码里也保留了不同depth配置的构造入口你可以直接换A0、A1甚至B0这些变体改动只在两个列表上。2.2 重参数化实现多分支变单分支的数学推导训练时一个标准的RepVGG Block由三个分支组成一个3x3卷积加BN、一个1x1卷积加BN、以及一个identity分支加BN。在stride1时这三条分支全开stride2时为了对齐尺寸只保留3x3卷积分支。推理时要做的事情就是把每个分支里的Conv和BN先融合成带偏置的卷积再把1x1卷积pad成3x3、把identity写成单位卷积核最后把三个卷积核和三个偏置按位相加。这段逻辑不复杂难在每一步的向量维度对齐。Conv加BN融合是重参数化的基础。BN在训练时维护一批数据的均值μ和方差σ²同时有两个可学习参数γ和β。推理时BN的计算是y γ*(x-μ)/sqrt(σ²ε)β这正好可以吸收到卷积里权重W乘γ/sqrt(σ²ε)偏置变成β - μ*γ/sqrt(σ²ε)。注意原来的卷积如果不带偏置融合后偏置不为零这就是为什么重参数化之后所有层都带bias。下面这段是三个分支融合的完整算子import torch import torch.nn as nn import torch.nn.functional as F def fuse_conv_bn(conv, bn): # 把一层ConvBN等价转换为带偏置的Conv gamma bn.weight.data beta bn.bias.data mean bn.running_mean var bn.running_var eps bn.eps w conv.weight.data * (gamma / torch.sqrt(var eps)).view( -1, 1, 1, 1) if conv.bias is None: b beta - mean * gamma / torch.sqrt(var eps) else: b conv.bias.data * (gamma / torch.sqrt(var eps)) \ beta - mean * gamma / torch.sqrt(var eps) fused_conv nn.Conv2d(conv.in_channels, conv.out_channels, conv.kernel_size, strideconv.stride, paddingconv.padding, biasTrue) fused_conv.weight.data w fused_conv.bias.data b return fused_conv def merge_block(conv3, bn3, conv1None, bn1None, bn_idNone): # 3x3卷积分支 c3, b3 fuse_conv_bn(conv3, bn3) if conv1 is not None and bn1 is not None: # 1x1卷积融合后pad成3x3形状 c1, b1 fuse_conv_bn(conv1, bn1) pad_w F.pad(c1.weight.data, [1, 1, 1, 1]) c1 nn.Conv2d(c1.in_channels, c1.out_channels, 3, stride1, padding1, biasTrue) c1.weight.data pad_w c1.bias.data b1 else: c1, b1 None, None if bn_id is not None: # identity分支写成一个中心为1的单位卷积核 gamma bn_id.weight.data beta bn_id.bias.data mean bn_id.running_mean var bn_id.running_var kernel torch.zeros(conv3.in_channels, conv3.in_channels, 3, 3) for i in range(conv3.in_channels): kernel[i, i, 1, 1] 1.0 kernel kernel * (gamma / torch.sqrt(var eps)).view(-1, 1, 1, 1) bias beta - mean * gamma / torch.sqrt(var eps) else: kernel, bias None, None out_w c3.weight.data.clone() out_b c3.bias.data.clone() if c1 is not None: out_w c1.weight.data out_b c1.bias.data if kernel is not None: out_w kernel out_b bias conv nn.Conv2d(conv3.in_channels, conv3.out_channels, 3, strideconv3.stride, paddingconv3.padding, biasTrue) conv.weight.data out_w conv.bias.data out_b return conv这段代码有两个关键参数你要盯住。一个是eps它来自BN层的配置通常默认1e-5融合时一定要和BN层里的一致否则精度对不上。另一个是1x1卷积pad时的四个1这对应3x3卷积核四周补一圈零保证卷积中心对齐。我在第一次复现时把pad写成了[0,0,1,1]结果融合后的输出和原训练模型对不上排查了半天才发现是左右没补全。2.3 用代码验证重参数化结果张量级对比重参数化最容易踩的坑是改完结构精度掉了但很多情况不是模型学坏了而是融合代码本身有bug。我的习惯是在转换前存一份训练态模型和一份随机输入转换后再喂同样的输入用torch.allclose做张量级对比误差小于1e-4就算合格。import torch model_train RepVGG(num_classes10) model_train.eval() x torch.randn(4, 3, 224, 224) with torch.no_grad(): y_train model_train(x) model_deploy repvgg_to_deploy(model_train) # 转换入口 model_deploy.eval() with torch.no_grad(): y_deploy model_deploy(x) diff (y_train - y_deploy).abs().max().item() assert diff 1e-4, f重参数化前后输出差异过大: {diff:.6f}这段验证逻辑要跑在转换之后、任何训练或微调之前。因为重参数化是一个不可逆过程一旦把多分支合并成单分支你就再也没办法把梯度传回三个分支了。所以我一般在训练流程的最后做转换转换前保存一份原始权重做备份这就是我的后悔药。后面第5章会专门讲这个操作的各种翻车现场。3. 用RepVgg跑通图像分类数据准备、训练配置与checkpoint说明3.1 数据集目录结构与class.json/result.json的作用这份资源包里没有附带大型数据集但给了两个标注文件和一个样例图集合这是我认为整套资源最贴心的部分。class.json是类别映射文件格式一般是{forest_a: 0, forest_b: 1, ...}它决定了分类头的输出维度也决定了训练时DataLoader从文件夹名读到的标签如何变成Tensor。result.json是模型推理结果的输出样例通常长这样{ 77291b3ad.png: {class: forest_a, score: 0.982}, 5a8b75712.png: {class: forest_b, score: 0.014} }训练和推理都要以这两个文件为锚点训练前检查类别数和class.json的key数量是否一致推理后检查results的key是否和待测图片一一对应。我给森林图像分类项目做数据处理时最常用的是ImageFolder结构因为PyTorch原生支持按文件夹名生成标签。data/ train/ forest_a/ img_001.jpg img_002.jpg forest_b/ img_003.jpg val/ forest_a/ img_101.jpg forest_b/ img_103.jpg如果原始数据不是这个结构转换脚本也很简单读class.json为每个类别建文件夹把图片复制进去。注意文件后缀要统一我之前混用了jpg和png两种格式训练过程没什么异常但到了部署阶段用OpenCV读图时颜色通道错位排查了三小时才发现是后缀欺骗了读取逻辑。3.2 训练脚本参数详解与日志怎么看RepVGG训练时是有三条分支的所以显存占用会比同参数量的VGG高但这是预期内的毕竟精度是靠多分支撑起来的。训练脚本的核心结构如下你可以直接照着这个骨架改import argparse, json, torch from torch import nn from torch.utils.data import DataLoader from torchvision.datasets import ImageFolder from torchvision.transforms import Compose, Resize, CenterCrop, ToTensor, Normalize parser argparse.ArgumentParser() parser.add_argument(--data, default./data) parser.add_argument(--epochs, typeint, default120) parser.add_argument(--batch-size, typeint, default64) parser.add_argument(--lr, typefloat, default0.1) parser.add_argument(--num-classes, typeint, default2) args parser.parse_args() transform Compose([ Resize(256), CenterCrop(224), ToTensor(), Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]), ]) train_set ImageFolder(args.data /train, transformtransform) train_loader DataLoader(train_set, batch_sizeargs.batch_size, shuffleTrue, num_workers4, pin_memoryTrue) val_set ImageFolder(args.data /val, transformtransform) val_loader DataLoader(val_set, batch_size64, shuffleFalse) model RepVGG(num_classesargs.num_classes) optimizer torch.optim.SGD(model.parameters(), lrargs.lr, momentum0.9, weight_decay1e-4) scheduler torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_maxargs.epochs) criterion nn.CrossEntropyLoss()这段配置有几个点要展开说。batch size我用64而不是更大的128是因为RepVGG训练态每个block有三个卷积分支反向传播时需要保存三份中间激活在8G显存的卡上64配224输入是比较稳的。学习率0.1搭配SGD是图像分类任务的常见组合配合cosine退火可以见到后期loss稳稳下降如果你换成Adam学习率建议降到1e-3附近。训练循环本身和常规分类任务没什么区别唯一要注意的是一定要全程保持model.train()因为BN层在训练态和推理态的逻辑完全不同。BN的running_mean和running_var是在训练时滚动更新的这些统计量最终会被融合进卷积核。如果中途为了做验证切到model.eval()再切回来只要optimizer步进正常问题不大但如果忘了切回train模式BN的统计量停更训练出来的模型在融合后精度会明显下降。3.3 断点续训和提交测试完整流程训练日志里你需要关注的不只是loss。我一般每5个epoch跑一次验证集准确率同时保存一份ckpt_last.pth用于断点续训。断点续训的代码很简单但要把模型、优化器、scheduler和epoch数都存下来checkpoint { model: model.state_dict(), optimizer: optimizer.state_dict(), scheduler: scheduler.state_dict(), epoch: epoch, } torch.save(checkpoint, ckpt_last.pth)续训时加载后还需要手动恢复四项状态缺了schedulercosine退火的学习率就会从头开始算相当于训练过程被割裂了。资源包里提到的result.json就派上用场了训练完拿val图跑一遍推理和包里的result.json做格式对齐——字段名、类别名、score的取值范围都要一致这样提交到评测平台时才不会因为格式问题被打回。4. 把训练模型变成部署模型推理转换的完整实现4.1 重参数化转换函数代码与逐步解释训练完的模型不能直接上生产原因前面说过三个分支在推理时是纯浪费。转换的过程在源码实现上通常叫repvgg_to_deploy它遍历模型的每一层找到带三个分支的Block调用merge_block完成融合然后把模型结构替换成单分支版本。def repvgg_to_deploy(model): for name, module in list(model.named_modules()): if hasattr(module, merge) and callable(module.merge): module.merge() # Block内部自行完成分支融合 return model这种实现的假设是每个Block内部自己实现了merge方法。如果你拿到的源码里Block结构是显式的conv3、bn3、conv1、bn1、bn_id那转换逻辑就应该显式遍历def repvgg_block_to_deploy(block): if block.stride 1: return merge_block(block.conv3, block.bn3, block.conv1, block.bn1, block.bn_id) else: # stride2时只有3x3分支 return fuse_conv_bn(block.conv3, block.bn3)需要注意merge()调用一次就够了。因为融合后的Block结构里不再有conv1和bn_id第二次调用时会走分支判断逻辑可能报KeyError如果你的转换代码允许重复执行一定要在第一次转换后把结构标志位置为False或者直接重建一个部署模型。4.2 模型验证PyTorch推理与ONNX导出转换完成后别急着上服务先做三件验证第一是输入输出张量对比这在2.3节已经做过第二是单张图推理和整图分类结果是否合理第三是导出ONNX再检查一遍算子结构。import torch.onnx model_deploy.eval() dummy torch.randn(1, 3, 224, 224) torch.onnx.export( model_deploy, dummy, repvgg_deploy.onnx, input_names[input], output_names[output], opset_version12, dynamic_axes{input: {0: batch}, output: {0: batch}}, )ONNX导出时我习惯加上dynamic_axes这样导出的模型能接受任意batch。但有个代价动态维度下某些推理框架的优化会变保守如果你的部署环境是固定的batch1干脆去掉dynamic_axesTensorRT或OpenVINO能做得更好的图优化。opset_version我一般选12兼容性和新算子支持都平衡。ONNX导出后还要做一次数值对齐这里有个容易被忽略的点用torch.onnx.export导出的模型默认走的是PyTorch的跟踪模式如果你的转换函数里有任何控制流比如for循环里判断stride跟踪会把所有分支都展开执行这可能让导出的模型结构和你预想的不一样。解决方法是导出一个已经完成重参数化的模型而不是在导出时动态做转换。4.3 推理脚本与内存/速度表现部署推理的完整流程我一般拆成四段读图、预处理、前向、解析。预处理必须和训练时完全一致——Resize(256)、CenterCrop(224)、标准化——任何一步不一样都会让精度崩掉。import json, torch from PIL import Image from torchvision.transforms import Compose, Resize, CenterCrop, ToTensor, Normalize transform Compose([Resize(256), CenterCrop(224), ToTensor(), Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225])]) def single_infer(model, image_path, class_map): img Image.open(image_path).convert(RGB) x transform(img).unsqueeze(0) with torch.no_grad(): logits model(x) prob torch.softmax(logits, dim1) cls_id logits.argmax(dim1).item() return class_map[str(cls_id)], prob[0, cls_id].item()推理时的显存占用相比训练态会显著下降因为多分支的相关计算和中间激活都被合并了。如果你在GPU上做批量推理建议把torch.no_grad()和model.eval()放在循环外避免每次都切换模型状态产生额外开销。CPU推理时线程数也可以用torch.set_num_threads控制通常在4到8个线程时性能收益最大。5. 避坑记录RepVgg训练和转换中的五个常见翻车点5.1 转换后精度暴跌差点以为模型废了现象重参数化完成后跑验证集准确率从90%掉到50%接近随机猜测。 原因转换前模型没有切到eval模式。训练态BN用于计算批统计量此时running_mean和running_var不会更新但卷积融合使用的是running统计量如果模型处于train模式个别模块还在走训练路径融合出的核就和实际推理行为不一致。 解决在repvgg_to_deploy之前强制model.eval()并且用torch.no_grad()包住转换过程。这个习惯我后来固定成模板转换、验证、导出都写在同一个脚本里不给中间状态留操作空间。5.2 排除到最后发现1x1卷积pad错了现象融合前后输出对比差异在1e-2量级肉眼能看出是全局偏置不对。 原因1x1卷积核向3x3扩展时四周补零的padding参数顺序写错。PyTorch的F.pad参数顺序是左、右、上、下我直觉以为先上后下实际上把左右和上下写反了导致卷积核的响应位置偏移。 解决写了一个专门的单元测试用随机初始化的1x1卷积和BN融合后和原分支逐元素对比。从那以后凡是涉及维度变换的算子我都会先跑一次单测再进入正式模型。5.3 用clip_grad_norm后融合模型完全不一样现象在训练脚本里加了梯度的全局裁剪训练loss正常下降loss曲线也算好看但转换后验证精度远低于转换前。 原因梯度裁剪本身不直接影响BN统计量但它改变了训练轨迹如果模型没有训练到充分收敛BN的running_mean和running_var还在大幅变化融合时对统计量的依赖就会放大误差。本质上不是融合的错是模型没训好。 解决检查转换前模型回头的验证精度是否和训练时一致。如果训练态模型本身在验证集上就低于90%先延长训练或调整学习率再进行转换。融合能等价保留精度但不会帮你修复没有收敛的模型。5.4 ONNX导出的动态batch和固定batch精度不一致现象同一个ONNX模型在固定batch1时输出完全正确一旦设置dynamic_axes并传入batch4某些输出的score顺序和PyTorch不一致。 原因动态维度下算子融合的保守策略不同尤其是当模型里存在Reshape和Transpose组合时优化器生成的等效计算图可能引入数值舍入差异。 解决在torch.onnx.export后用onnxruntime的OrtSession加载模型分别以batch1和batch4做对齐测试设定tolerance为1e-3。如果你部署侧只用到单图推理就直接删掉dynamic_axes少一个变量少一个坑。5.5 result.json格式错位导致评测白跑现象提交评测后准确率正常但报告里的混淆矩阵和本地验证完全不同部分图片的类别名对不上。 原因class.json里的类别顺序和模型输出logits的通道顺序不一致。比如class.json按字母序排序而模型输出头是按文件夹遍历顺序生成的两者的映射错位所有预测结果整体平移了一个索引。 解决推理脚本里不再手写数字到类别的映射一律在预测后读取class.json做查表。训练时也要把class.json的构建逻辑和数据集目录遍历逻辑统一用同一个函数生成避免两套排序。6. 验证模型有没有学对用混淆矩阵和特征图收尾训练结束、转换完成、推理接口也通了最后一个步骤我强烈建议你补上跑一遍混淆矩阵。我见过太多模型验证集准确率96%实际业务场景里对特定类别几乎全错的案例。准确率只有一个数字它掩盖了模型对某些类别的系统性偏见。这份资源后来我拿到手里的第一件事就是用它跑森林图像分类的混淆矩阵。import json, numpy as np, torch from sklearn.metrics import confusion_matrix def evaluate_cm(model, loader, class_map, device): model.eval() y_true, y_pred [], [] with torch.no_grad(): for x, y in loader: x, y x.to(device), y.to(device) logits model(x) y_pred.extend(logits.argmax(dim1).cpu().tolist()) y_true.extend(y.cpu().tolist()) cm confusion_matrix(y_true, y_pred) names list(class_map.keys()) print( .join(f{n[:4]:6} for n in names)) for i, row in enumerate(cm): print(f{names[i][:4]:6} .join(f{v:6} for v in row))这段代码里class_map的key顺序必须和模型输出通道一致这就是第5章第5条踩坑记录的现成应用。混淆矩阵的读法有一个优先级先看对角线再看紧邻类别的非对角线值。对森林图像分类来说如果草地和灌木频繁互相误判说明它们在颜色纹理上太接近模型没能学到区分性特征这种情况下可以考虑给这两个类别加权重或者做数据增强时叠加色彩扰动。我每次跑完混淆矩阵还会顺手做一件事把预测置信度最低的20张图单独输出到一个文件夹。这些图就是模型最犹豫的样本往往能暴露标注错误和类别边界的真实问题。比如有一次我发现低置信度样本里大量是逆光拍摄的树冠图数据增强里加一个随机亮度扰动后这类样本的预测就明显变好了。特征图的可视化比混淆矩阵更深一层但可以作为补充手段取最后一层卷积输出的每个通道做全局平均池化后画成热力图叠加在原图上。这个能快速确认RepVGG是不是把注意力放在了正确区域。如果目标树区域完全没被激活那说明训练存在更根本的分布偏移调参已经没用了回头查数据更实际。从那以后我每次训练完都不急着导出ONNX也不急着写部署接口先跑一遍混淆矩阵和低置信度样本检查确认模型是真的学对了才敢说可以上线。这个过程只需要十几分钟却能让后面的部署阶段少踩一半坑。希望帮到你。本文还有配套的精品资源点击获取