简介面向植物病害识别与计算机视觉迁移学习实践者的ResNet152项目资料包适合具备一定深度学习基础、希望复现高精度图像分类流程的高校学生与算法开发者。包内标注文件总数2000主要类型为5412张植物叶片jpg图像、6个py训练与推理脚本、2个pth模型权重及json、txt配置说明压缩包约503.25MB图像覆盖健康与多种病害状态可直接用于分类任务的数据组织与校验。已有1433人学习下载。内容围绕ImageNet预训练ResNet152的微调展开可参考数据预处理、随机翻转与缩放等增强策略输出层改为38类病害分类的改造方式以及优化器、学习率与损失函数配置权重与脚本配合便于核对训练、验证和测试指标也可作为移动端或Web端病害识别应用的模型基础。描述中给出的99.6%识别准确率可作为复现目标参照对数据增强、模型评估与部署环节形成较完整的闭环参考。1. 从一张叶片照片说起resnet152_plant 能解决什么去年帮一个做种植管理的朋友梳理他们的巡检流程最耗时的环节不是打药而是人工在几千张叶片照片里翻找可疑样本一天下来眼睛都花了。resnet152_plant这个压缩包解决的正是这一段给一张叶片图输出它属于哪一类品种、病害类型或健康状态并给出置信度。它属于典型的计算机视觉图像分类任务核心是深度学习里的迁移学习打法不从头训而是拿 ImageNet 上预训练好的 ResNet152 当骨架只重训最后的分类头几百到几千张图就能跑出可用模型。它适合两类人手里已经有一批按类别分好文件夹的图片、想快速拿到可运行基线的算法初学者以及想拿一套结构完整、主干随时能换的训练脚手架做二次开发的工程同学。数据采集和标注不在它的范围内进来之前你得先把data/train按类别分好目录。2. 技术栈与目录结构解开压缩包后的前十分钟拿到压缩包先别急着python train.py花十分钟把依赖和目录看清楚能省掉后面一大半莫名其妙的报错。这类项目之所以能跑通靠的是 PyTorch 生态里几件配合得很稳的零件torchvision.models提供带 ImageNet 权重的 ResNet152torchvision.datasets.ImageFolder负责按目录名自动生成标签torch.utils.data.DataLoader负责批处理和多进程加载torch.cuda.amp负责混合精度省显存。额外再挂上scikit-learn做分层划分、pyyaml读配置、tqdm看进度、onnx/onnxruntime做导出验证一套完整的训练加交付链路就齐了。2.1 依赖与运行环境CUDA 版本对上比什么都重要ResNet152 参数量约 60M输入 224×224单卡 8G 显存跑batch_size16加混合精度是能撑住的但前提是 torch 和 CUDA 版本对得上。我一般先确认驱动支持的 CUDA 上限再去装对应 wheel而不是反过来。装完立刻跑一行检查比后面在训练脚本里猜要快得多# 建议 Python 3.9torch 2.x pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 pip install scikit-learn pyyaml tqdm onnx onnxruntime pillow# 环境自检三步确认 torch 能用 GPU import torch, torchvision print(torch.__version__, torchvision.__version__) # 版本号要对得上 print(torch.cuda.is_available(), torch.cuda.device_count()) print(torch.cuda.get_device_name(0) if torch.cuda.is_available() else CPU only)torch.cuda.is_available()返回False是最常见的开局翻车点原因八成是装成了 CPU 版 wheel 或者驱动版本太旧跟代码逻辑没关系。torch.cuda.get_device_name(0)则用来确认拿到的是不是你以为的那张卡多卡机器上 CUDA_VISIBLE_DEVICES 设置不当会让程序默默跑在另一张卡上。另外torchvision和torch必须版本配套版本错位时ResNet152_Weights.IMAGENET1K_V2这个枚举可能根本不存在报错信息还挺绕。2.2 目录结构与每个文件的职责压缩包解开后的结构一般长这样不管作者怎么排版核心角色都是这几个resnet152_plant/ ├── data/ │ ├── train/ # 每个子目录名 一个类别 │ │ ├── class_a/*.jpg │ │ └── class_b/*.jpg │ └── val/ # 结构与 train 完全一致 ├── configs/ │ └── default.yaml # 超参、路径、图像尺寸集中在这里 ├── src/ │ ├── dataset.py # transforms DataLoader 构建 │ ├── model.py # ResNet152 改造与主干解冻 │ ├── train.py # 训练主循环、checkpoint 保存 │ ├── eval.py # 验证集评估、混淆矩阵 │ └── export_onnx.py # 导出与数值对齐 ├── weights/ │ └── resnet152-imagenet.pth ├── predict.py # 单图/批量推理入口 └── requirements.txtdata/的层级约定是这个项目的地基ImageFolder会把data/train下每个子目录当成一个类别并按目录名的字母序生成class_to_idx这个映射决定了模型输出第 0 维对应哪个类别。src/里的四个脚本职责切得很干净dataset.py只管张量怎么来model.py只管网络怎么搭train.py只管循环怎么转eval.py和export_onnx.py只管交付。configs/default.yaml把所有会调的数字集中起来改超参不用去翻代码。这里有个值得先记住的点weights/里的 ImageNet 权重是可选的。torchvision的weights参数会自动下载并缓存到~/.cache/torch/hub/checkpoints/离线环境下才需要手动放。所以判断项目能不能直接跑先看model.py里写的是weightsIMAGENET1K_V2还是weightsNone前者需要网络或预置权重文件后者就是从零训练两者收敛速度差一个数量级。跑起来的标准动作是先小样本过一遍把data/train里每个类别只留 20 张图epochs设成 2确认 loss 在动、checkpoint 能存、验证集能出准确率。这一步通了再换全量数据跑长训练否则你可能在 8 小时后才发现保存路径写错了。3. 数据管道拆解从原始图片到 DataLoader 的完整链路分类任务跑不出效果七成问题出在数据侧而不是模型侧。ResNet152 已经把特征提取这件事做得足够好真正决定上限的是你的图片有没有被正确喂进去。这一章把dataset.py拆成三块看目录怎么组织、transforms 怎么写、DataLoader 怎么调。3.1 ImageFolder 的目录约定与分层划分如果压缩包给的data/已经分好了train和val那ImageFolder直接接管就行。但实际拿到的原始数据通常是一整个平铺目录需要一个划分脚本。这里有个血泪经验别用随机划分。同一个植株、同一批次拍的多张照片如果被拆到 train 和 val 两边验证准确率能虚高十几个点上线立刻打回原形。# src/split_data.py from pathlib import Path from collections import defaultdict import shutil from sklearn.model_selection import train_test_split raw Path(data/raw) # 约定文件名前缀是分组 id例如 plot03_leaf012.jpg - 分组 plot03 groups defaultdict(list) for p in raw.rglob(*.jpg): groups[p.stem.split(_)[0]].append(p) paths [str(p) for g in groups.values() for p in g] labels [p.parent.name for g in groups.values() for p in g] # 按类别分层划分test_size0.2 表示验证集占两成 tr, va train_test_split(paths, test_size0.2, stratifylabels, random_state42) for split, items in ((train, tr), (val, va)): for src in items: src Path(src) dst Path(data) / split / src.parent.name / src.name dst.parent.mkdir(parentsTrue, exist_okTrue) shutil.copy2(src, dst) # 图不多时复制图多时改软链接 print(ftrain{len(tr)} val{len(va)})stratifylabels保证每个类别在 train/val 里的比例一致否则小类别可能全被分到一边验证集上直接看不到它。random_state42固定划分结果方便复现。如果图片量上万shutil.copy2会很慢改成dst.symlink_to(src.resolve())更合适。真正严谨的做法是按分组 id 做GroupShuffleSplit同一分组只出现在一侧代价是验证集分布会更难但得到的指标才可信。3.2 train/val 两套 transforms 的差异与参数含义transforms 这块最容易出的问题是 train 和 val 用了同一套。训练时要随机增强提升泛化验证时必须确定性变换保证指标可复现两者混用等于在考试时给学生换题目。叶片图像还有个特点拍摄角度不固定所以垂直翻转是合理的增强而水平翻转在文字类数据上就要慎用。# src/dataset.py from torchvision import transforms from torchvision.datasets import ImageFolder from torch.utils.data import DataLoader # 必须与 ImageNet 预训练时的统计量一致否则迁移效果会打折 MEAN, STD (0.485, 0.456, 0.406), (0.229, 0.224, 0.225) def build_transforms(img_size224, trainTrue): if train: return transforms.Compose([ # scale(0.6,1.0) 控制裁剪后主体占比叶片类不宜裁太狠 transforms.RandomResizedCrop(img_size, scale(0.6, 1.0)), transforms.RandomHorizontalFlip(p0.5), transforms.RandomVerticalFlip(p0.2), # 叶片方向不固定 transforms.ColorJitter(0.2, 0.2, 0.2, 0.05), # 模拟不同光照 transforms.ToTensor(), transforms.Normalize(MEAN, STD), transforms.RandomErasing(p0.25, scale(0.02, 0.1)), # 遮挡增强 ]) return transforms.Compose([ transforms.Resize(int(img_size * 1.14)), # 224 - 256先放大 transforms.CenterCrop(img_size), # 再中心裁回 224 transforms.ToTensor(), transforms.Normalize(MEAN, STD), ]) def build_dataloaders(rootdata, img_size224, batch_size16, num_workers4): train_ds ImageFolder(f{root}/train, transformbuild_transforms(img_size, True)) val_ds ImageFolder(f{root}/val, transformbuild_transforms(img_size, False)) # 类别顺序不一致会导致标签错位必须断言 assert train_ds.class_to_idx val_ds.class_to_idx, train/val 类别目录不一致 train_loader DataLoader(train_ds, batch_sizebatch_size, shuffleTrue, num_workersnum_workers, pin_memoryTrue, drop_lastTrue, persistent_workersnum_workers 0) val_loader DataLoader(val_ds, batch_sizebatch_size, shuffleFalse, num_workersnum_workers, pin_memoryTrue) return train_loader, val_loader, train_ds.class_to_idxRandomResizedCrop(224, scale(0.6, 1.0))的意思是随机裁出原图 60% 到 100% 面积的区域再缩放scale下限设太低会把病斑裁掉对那些靠局部特征区分的细粒度类别是负增强。ColorJitter的四个参数依次是亮度、对比度、饱和度、色相色相扰动控制在 0.05 以内否则叶片颜色失真会干扰基于颜色的判别。RandomErasing放在Normalize之后因为它作用在张量上而不是 PIL 图上位置写错会直接报类型错误。验证集的Resize(256) CenterCrop(224)是 ImageNet 评估的标准做法先把短边缩到 256再中心裁 224保证主体完整且变换确定。有人图省事直接Resize((224, 224))拉伸变形会改变叶片的长宽比细长叶片的分类精度会掉。assert train_ds.class_to_idx val_ds.class_to_idx这行别删两个目录里类别文件夹名字稍有差异比如多了个空格、大小写不同标签就会静默错位指标看着正常但预测全是乱的。3.3 DataLoader 的 worker、pin_memory 与 sampler 配置num_workers的取值是个玄学不是越大越好。图像解码是 CPU 密集操作worker 数一般设成物理核数的 0.5 到 1 倍设太大反而因为进程切换拖慢速度还会把内存吃满。在容器里跑的时候共享内存--shm-size不够会直接抛Bus error这时候要么调小 worker 数要么给容器加共享内存。pin_memoryTrue配合non_blockingTrue能把 CPU 到 GPU 的拷贝做成异步吞吐能提一截但前提是num_workers 0worker 为 0 时这个选项没意义还占内存。drop_lastTrue只在训练集上开丢掉最后不满一个 batch 的样本避免 BatchNorm 在只有一两张图时统计量剧烈抖动。验证集不能丢否则指标统计会漏样本。类别不均衡时shuffleTrue的随机采样会让小类别在一个 epoch 里被看到很多次或几乎看不到。常见做法是挂一个WeightedRandomSamplerfrom torch.utils.data import WeightedRandomSampler import numpy as np targets np.array(train_ds.targets) counts np.bincount(targets, minlengthlen(train_ds.classes)).astype(float) class_weight 1.0 / np.maximum(counts, 1) sample_weight class_weight[targets] sampler WeightedRandomSampler(sample_weight, num_sampleslen(train_ds), replacementTrue) # 用它时 DataLoader 的 shuffle 必须设成 False两者互斥 train_loader DataLoader(train_ds, batch_size16, samplersampler, num_workers4)class_weight取类别频次的倒数频次越低的类别权重越高replacementTrue表示有放回采样总样本数保持和原数据集一致。这个方案和损失函数里加weight二选一就行同时用会重复补偿反而让模型过度偏向小类。如果某个类别只有十几张图权重采样也救不回来那就得考虑数据增广或者干脆合并相近类别。4. 模型改造与训练链路ResNet152 从冻结到解冻的具体操作迁移学习的价值在于把 ImageNet 上 120 万张图学到的通用特征搬过来但搬的方式有讲究。全冻结只训分类头收敛快但精度有天花板全解冻精度上限高但小数据集上极易过拟合。这套项目的做法是两阶段先冻结主干把分类头训到稳定再放开最后一两个 stage 用很小的学习率微调。4.1 换掉 fc 层2048 维特征到 num_classesResNet152 的结构是conv1 → bn1 → relu → maxpool → layer1..layer4 → avgpool → fc其中 layer1 到 layer4 的 Bottleneck 数量分别是 3、8、36、3最后的fc是Linear(2048, 1000)。我们要做的就是把这个 1000 换成自己的类别数。# src/model.py import torch.nn as nn from torchvision.models import resnet152, ResNet152_Weights def build_model(num_classes, pretrainedTrue, freeze_backboneTrue, dropout0.3): # IMAGENET1K_V2 权重更强top-1 约 82%比 V1 高几个点 weights ResNet152_Weights.IMAGENET1K_V2 if pretrained else None model resnet152(weightsweights) if freeze_backbone: for p in model.parameters(): p.requires_grad False # 冻结主干只保留前向 in_features model.fc.in_features # 2048 model.fc nn.Sequential( nn.Dropout(dropout), # 小数据集上必加 nn.Linear(in_features, num_classes), ) return model def unfreeze_last_stage(model, blocks2): 放开 layer4 最后 blocks 个 Bottleneck 分类头 for p in model.fc.parameters(): p.requires_grad True for p in model.layer4.parameters(): p.requires_grad False for block in list(model.layer4.children())[-blocks:]: for p in block.parameters(): p.requires_grad True这里有个细节值得说清楚for p in model.parameters(): p.requires_grad False之后新建的model.fc是全新的模块默认requires_gradTrue所以冻结不会误伤分类头。in_features从模型里读而不是写死 2048是为了将来换成resnet50也是 2048或resnet34512时不用改代码。Dropout(0.3)在样本量小于每类 500 张时基本是标配样本充足可以降到 0.1 或者去掉。unfreeze_last_stage的粒度控制是这套代码里比较讲究的地方。整个layer4有 3 个 Bottleneck全放开参数量约 8M对小数据集偏多只放开最后 1 到 2 个既能适配目标域的高层语义又不会把底层通用特征冲掉。如果验证集准确率在解冻后不升反降把blocks调回 1或者把主干学习率再降一个量级。4.2 分组学习率与两阶段解冻分类头是随机初始化的主干是训练好的两者用同一个学习率是典型误用。分类头需要大步走主干只能小步挪。PyTorch 的优化器支持参数分组把两拨参数的lr分开设就行。from torch.optim import AdamW def build_optimizer(model, lr1e-3, backbone_scale0.1, weight_decay0.05): head_params [p for p in model.fc.parameters() if p.requires_grad] head_ids {id(p) for p in head_params} backbone_params [p for p in model.parameters() if p.requires_grad and id(p) not in head_ids] groups [{params: head_params, lr: lr, weight_decay: weight_decay}] if backbone_params: # 主干学习率是分类头的 1/10避免把预训练特征带偏 groups.append({params: backbone_params, lr: lr * backbone_scale, weight_decay: weight_decay}) return AdamW(groups)backbone_scale0.1意味着分类头用 1e-3、主干用 1e-4这个比例在多数迁移学习场景下都能用。weight_decay0.05是 AdamW 的常见取值比 SGD 时代的 5e-4 大不少因为 AdamW 的衰减是解耦的不作用于梯度。用id(p)做集合判断而不是直接比较张量是因为参数对象在分组后可能出现重复引用set去重更稳妥。两阶段的调度一般这么排阶段一冻结主干训 5 到 10 个 epoch学习率 1e-3等验证准确率不再涨了阶段二调用unfreeze_last_stage重建优化器必须重建旧的参数组里没有新放开的参数学习率整体降到 1e-4再训 10 到 20 个 epoch。阶段二的学习率调度用余弦退火比较稳from torch.optim.lr_scheduler import CosineAnnealingLR scheduler CosineAnnealingLR(optimizer, T_maxepochs, eta_min1e-6)T_max设成阶段二的总 epoch 数eta_min是学习率下限别设 0否则最后几个 epoch 模型几乎不动。4.3 训练循环AMP、label smoothing 与 checkpoint 保存训练循环里真正影响结果的几个点混合精度、梯度裁剪、标签平滑、checkpoint 里存什么。混合精度能把显存占用降三到四成让batch_size从 8 提到 16 甚至 24梯度裁剪防的是个别 batch 梯度爆炸把权重带飞标签平滑在类别边界模糊时比如两种相似病害能明显降低过拟合。import torch from torch.amp import autocast, GradScaler from tqdm import tqdm def train_one_epoch(model, loader, criterion, optimizer, scaler, device, schedulerNone, clip1.0): model.train() total_loss, correct, total 0.0, 0, 0 for imgs, labels in tqdm(loader, leaveFalse, desctrain): imgs imgs.to(device, non_blockingTrue) labels labels.to(device, non_blockingTrue) optimizer.zero_grad(set_to_noneTrue) with autocast(cuda, dtypetorch.float16): logits model(imgs) loss criterion(logits, labels) scaler.scale(loss).backward() # 梯度按 loss 放大 scaler.unscale_(optimizer) # 裁剪前必须还原 torch.nn.utils.clip_grad_norm_( [p for p in model.parameters() if p.requires_grad], clip) scaler.step(optimizer) scaler.update() if scheduler is not None: scheduler.step() total_loss loss.item() * labels.size(0) correct (logits.argmax(1) labels).sum().item() total labels.size(0) return total_loss / total, correct / total # 标签平滑 0.1把 one-hot 的 1 摊成 0.9 和 0.1/(C-1) criterion torch.nn.CrossEntropyLoss(label_smoothing0.1) scaler GradScaler(cuda)autocast只包前向和损失计算反向由scaler.scale(loss).backward()自动处理。scaler.unscale_(optimizer)这行不能漏梯度裁剪必须作用在真实的梯度值上直接裁放大后的梯度等于没裁。clip1.0是常用值训练前期如果 loss 抖动剧烈可以降到 0.5。torch 2.0 之前的写法是from torch.cuda.amp import autocast, GradScaler参数里不用传cuda遇到TypeError就往回改。checkpoint 里存什么直接决定后面能不能复用。只存model.state_dict()是最省事也最容易出问题的做法torch.save({ model: model.state_dict(), class_to_idx: class_to_idx, # 关键类别映射必须存 img_size: 224, # 推理时的预处理尺寸 arch: resnet152, epoch: epoch, val_acc: val_acc, }, fweights/plant_ep{epoch}_acc{val_acc:.4f}.pth)class_to_idx是这套 checkpoint 里最容易被忽略的字段。ImageFolder按字母序生成映射如果你的推理脚本里手写了一个类别列表顺序一旦和训练时不一致模型输出的 argmax 是对的但映射到类别名就全错了而且错得很隐蔽——准确率看着有 80%实际业务全乱。img_size同理训练用 224 推理用 384精度会因为位置编码和感受野不匹配而下降。把这两个字段和权重绑在一起存是给自己留后悔药。5. 避坑与排查验证集虚高、显存打满和权重加载的三类典型问题这套代码跑通不难跑出可信的结果难。下面这几条是我在不同项目里反复撞上的每条按现象、原因、解决三步说清楚遇到类似症状可以对着排查。5.1 验证准确率虚高数据泄漏与 transforms 错配现象训练两个 epoch 验证集就到 98%但拿新拍的照片一测准确率掉到 50% 以下混淆矩阵里几乎全预测成样本量最大的那个类。原因八成是划分方式有问题。同一植株、同一拍摄批次的多张照片被随机分到 train 和 val 两边模型学到的是“这张图的背景和角度”而不是叶片本身的特征。另一成原因是验证集误用了训练集的 transforms随机裁剪让同一样本每次评估结果都不一样指标不可复现还容易碰巧蒙对。解决先按分组 id 做GroupShuffleSplit保证同一分组只出现在一侧再检查build_dataloaders里 val 传的是不是trainFalse最后打印一次验证集前 8 张图的labels和文件名肉眼确认没有重复样本。如果这些都做了指标还是高得离谱那就去看混淆矩阵某一类精确率 100% 而召回率 0基本可以断定这一类在验证集里根本不存在。5.2 显存打满与 BN 层翻车现象batch_size32时报CUDA out of memory降到 8 能跑但验证准确率忽高忽低同一个 checkpoint 两次评估能差 5 个点。原因ResNet152 在 224 分辨率下batch_size32的激活值占用大约 12G 以上8G 卡必然爆。而降到 8 之后BatchNorm 层每个 batch 只有 8 个样本参与统计running_mean和running_var抖动剧烈评估时用的统计量和训练时对不上指标自然不稳。解决显存不够优先开混合精度再上梯度累积把等效 batch 补回来# 等效 batch_size 8 * 4 32 accum_steps 4 optimizer.zero_grad(set_to_noneTrue) for i, (imgs, labels) in enumerate(loader): with autocast(cuda, dtypetorch.float16): loss criterion(model(imgs.to(device)), labels.to(device)) / accum_steps scaler.scale(loss).backward() if (i 1) % accum_steps 0: scaler.unscale_(optimizer) torch.nn.utils.clip_grad_norm_(model.parameters(), 1.0) scaler.step(optimizer) scaler.update() optimizer.zero_grad(set_to_noneTrue)注意 loss 要除以accum_steps否则梯度是累加值等效学习率被放大了 4 倍。冻结主干训练时还有个额外的坑BN 层虽然requires_gradFalse但前向仍然会更新running_mean/var小 batch 下能把统计量带偏。稳妥做法是在每个 step 后强制把 BN 切回 evaldef set_bn_eval(module): if isinstance(module, torch.nn.BatchNorm2d): module.eval() model.train() model.apply(set_bn_eval) # 冻结阶段专用5.3 权重加载与类别错位现象加载预训练权重时报size mismatch for fc.weight: copying a param with shape [1000, 2048] from checkpoint, the shape in current model is [N, 2048]或者换了数据集之后推理结果全是同一个类。原因前者是直接load_state_dict了完整权重没过滤掉分类头后者是推理脚本里的类别顺序和训练时的class_to_idx不一致或者推理时的Normalize用了别的 mean/std。解决加载预训练权重时过滤掉fc开头的键用strictFalse允许缺失ckpt torch.load(path, map_locationcpu, weights_onlyTrue) state ckpt.get(model, ckpt) state {k: v for k, v in state.items() if not k.startswith(fc.)} missing, unexpected model.load_state_dict(state, strictFalse) print(missing:, missing) # 应该只有 fc.* print(unexpected:, unexpected) # 应该为空weights_onlyTrue是新版本 torch 的推荐写法防止加载不可信 pickle。missing里如果出现layer4.xxx说明权重文件不完整unexpected非空说明键名对不上通常是版本差异导致的前缀不同。推理脚本这边类别名一律从 checkpoint 里读不要手写idx_to_class {v: k for k, v in ckpt[class_to_idx].items()} pred_name idx_to_class[logits.argmax(1).item()]5.4 Windows 与容器环境下的 DataLoader 报错现象Linux 上跑得好好的换到 Windows 直接抛RuntimeError: An attempt has been made to start a new process before the current process has finished its bootstrapping phase容器里则报Bus error或进程被 kill。原因Windows 的多进程启动方式是spawn构建 DataLoader 的代码如果在模块顶层执行子进程会重新导入模块造成递归。容器的Bus error则是共享内存/dev/shm默认只有 64Mworker 往共享内存写 batch 时直接撑爆。解决把训练入口包进if __name__ __main__:Windows 上num_workers建议先设 0 验证逻辑通了再往上加。容器里加--shm-size4g启动参数或者把num_workers降到 2。另外persistent_workersTrue在 worker 数为 0 时会报错写成persistent_workersnum_workers 0就避开了。6. 二次开发换主干、导 ONNX 和量化部署的改造路径这套代码真正有价值的地方不是 ResNet152 本身而是它把“数据进、模型出、结果交付”这条链路切成了几个低耦合的模块。想换主干只需要动model.py里的工厂函数想上线export_onnx.py加一个 FastAPI 外壳就能跑。我一般按这个顺序改先确认基线指标再换主干对比最后才做导出和压缩否则一旦出问题分不清是模型换了还是导出错了。model.py里的build_model可以抽成按名字分发的工厂用timm统一管理主干换efficientnet_b3、convnext_tiny都是一行参数的事import timm def build_timm_model(nameresnet152, num_classes10, pretrainedTrue, drop_path_rate0.1): # timm 的 num_classes 会自动替换分类头drop_path 是结构化的随机深度 return timm.create_model(name, pretrainedpretrained, num_classesnum_classes, drop_path_ratedrop_path_rate)drop_path_rate对 ConvNeXt、ViT 这类结构有效对 ResNet 影响很小换主干时顺手带上。接口统一之后训练脚本里只改一个字符串就能跑 A/B 对比注意不同主干的输入尺寸不一样EfficientNet 系列常用 300 或 384img_size要跟着改Resize(int(img_size * 1.14))会自动适配。导出 ONNX 的关键是动态 batch 和数值对齐验证只导出不校验等于没验证import numpy as np, torch, onnxruntime as ort model.eval().to(cpu) dummy torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy, plant_resnet152.onnx, input_names[input], output_names[logits], dynamic_axes{input: {0: batch}, logits: {0: batch}}, opset_version17, do_constant_foldingTrue, ) sess ort.InferenceSession(plant_resnet152.onnx, providers[CPUExecutionProvider]) with torch.no_grad(): torch_out model(dummy).numpy() onnx_out sess.run([logits], {input: dummy.numpy()})[0] print(max abs diff:, np.abs(torch_out - onnx_out).max()) # 应小于 1e-4dynamic_axes把第 0 维标成动态服务端才能一次推多张。opset_version17兼容性比较好低于 11 的版本对某些算子支持不全。数值对齐这一步是必须的差值超过 1e-3 通常意味着导出时模型没切eval()Dropout 和 BN 还在随机状态。导出后还要拿一张真实图片走完整预处理再比一次因为服务端的归一化参数写错是另一类高频问题。量化这块要泼点冷水。ResNet152 的主体是卷积动态量化torch.quantization.quantize_dynamic只量化 Linear 层对这个结构基本没收益静态量化能压到 FP32 的四分之一大小、CPU 上提速两三倍但需要几百张校准图而且细粒度分类任务的精度损失可能到 2 到 4 个点。我的做法是先量化然后在同一份验证集上重跑一遍eval.py掉点超过 2 个就放弃量化改用 ONNX Runtime 的 FP16 或者直接上 GPU 推理。别为了省几毫秒把业务指标赌进去。从那以后我每次导出模型都强制拿同一张图跑一遍 torch 和 onnx 的输出对比差值打印出来贴在提交记录里谁改的谁负责。这个习惯帮我拦下过三次“导出成功但结果全错”的事故比任何文档都管用。希望帮到你。本文还有配套的精品资源点击获取