简介：面向植物病害识别与计算机视觉迁移学习实践者的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 权重的 ResNet152，torchvision.datasets.ImageFolder负责按目录名自动生成标签，torch.utils.data.DataLoader负责批处理和多进程加载，torch.cuda.amp负责混合精度省显存。额外再挂上scikit-learn做分层划分、pyyaml读配置、tqdm看进度、onnx/onnxruntime做导出验证，一套完整的训练加交付链路就齐了。

2.1 依赖与运行环境：CUDA 版本对上比什么都重要

ResNet152 参数量约 60M，输入 224×224，单卡 8G 显存跑batch_size=16加混合精度是能撑住的，但前提是 torch 和 CUDA 版本对得上。我一般先确认驱动支持的 CUDA 上限，再去装对应 wheel，而不是反过来。装完立刻跑一行检查，比后面在训练脚本里猜要快得多：

# 建议 Python 3.9+，torch 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.txt

data/的层级约定是这个项目的地基：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里写的是weights="IMAGENET1K_V2"还是weights=None，前者需要网络或预置权重文件，后者就是从零训练，两者收敛速度差一个数量级。

跑起来的标准动作是先小样本过一遍：把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_size=0.2 表示验证集占两成 tr, va = train_test_split(paths, test_size=0.2, stratify=labels, random_state=42) 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(parents=True, exist_ok=True) shutil.copy2(src, dst) # 图不多时复制，图多时改软链接 print(f"train={len(tr)} val={len(va)}")

stratify=labels保证每个类别在 train/val 里的比例一致，否则小类别可能全被分到一边，验证集上直接看不到它。random_state=42固定划分结果，方便复现。如果图片量上万，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_size=224, train=True): if train: return transforms.Compose([ # scale=(0.6,1.0) 控制裁剪后主体占比，叶片类不宜裁太狠 transforms.RandomResizedCrop(img_size, scale=(0.6, 1.0)), transforms.RandomHorizontalFlip(p=0.5), transforms.RandomVerticalFlip(p=0.2), # 叶片方向不固定 transforms.ColorJitter(0.2, 0.2, 0.2, 0.05), # 模拟不同光照 transforms.ToTensor(), transforms.Normalize(MEAN, STD), transforms.RandomErasing(p=0.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(root="data", img_size=224, batch_size=16, num_workers=4): train_ds = ImageFolder(f"{root}/train", transform=build_transforms(img_size, True)) val_ds = ImageFolder(f"{root}/val", transform=build_transforms(img_size, False)) # 类别顺序不一致会导致标签错位，必须断言 assert train_ds.class_to_idx == val_ds.class_to_idx, "train/val 类别目录不一致" train_loader = DataLoader(train_ds, batch_size=batch_size, shuffle=True, num_workers=num_workers, pin_memory=True, drop_last=True, persistent_workers=num_workers > 0) val_loader = DataLoader(val_ds, batch_size=batch_size, shuffle=False, num_workers=num_workers, pin_memory=True) return train_loader, val_loader, train_ds.class_to_idx

RandomResizedCrop(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_memory=True配合non_blocking=True能把 CPU 到 GPU 的拷贝做成异步，吞吐能提一截，但前提是num_workers > 0，worker 为 0 时这个选项没意义还占内存。drop_last=True只在训练集上开，丢掉最后不满一个 batch 的样本，避免 BatchNorm 在只有一两张图时统计量剧烈抖动。验证集不能丢，否则指标统计会漏样本。

类别不均衡时，shuffle=True的随机采样会让小类别在一个 epoch 里被看到很多次或几乎看不到。常见做法是挂一个WeightedRandomSampler：

from torch.utils.data import WeightedRandomSampler import numpy as np targets = np.array(train_ds.targets) counts = np.bincount(targets, minlength=len(train_ds.classes)).astype(float) class_weight = 1.0 / np.maximum(counts, 1) sample_weight = class_weight[targets] sampler = WeightedRandomSampler(sample_weight, num_samples=len(train_ds), replacement=True) # 用它时 DataLoader 的 shuffle 必须设成 False，两者互斥 train_loader = DataLoader(train_ds, batch_size=16, sampler=sampler, num_workers=4)

class_weight取类别频次的倒数，频次越低的类别权重越高，replacement=True表示有放回采样，总样本数保持和原数据集一致。这个方案和损失函数里加weight=二选一就行，同时用会重复补偿，反而让模型过度偏向小类。如果某个类别只有十几张图，权重采样也救不回来，那就得考虑数据增广或者干脆合并相近类别。

4. 模型改造与训练链路：ResNet152 从冻结到解冻的具体操作

迁移学习的价值在于把 ImageNet 上 120 万张图学到的通用特征搬过来，但搬的方式有讲究。全冻结只训分类头收敛快但精度有天花板，全解冻精度上限高但小数据集上极易过拟合。这套项目的做法是两阶段：先冻结主干把分类头训到稳定，再放开最后一两个 stage 用很小的学习率微调。

4.1 换掉 fc 层：2048 维特征到 num_classes

ResNet152 的结构是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, pretrained=True, freeze_backbone=True, dropout=0.3): # IMAGENET1K_V2 权重更强，top-1 约 82%，比 V1 高几个点 weights = ResNet152_Weights.IMAGENET1K_V2 if pretrained else None model = resnet152(weights=weights) 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, blocks=2): """放开 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_grad=True，所以冻结不会误伤分类头。in_features从模型里读而不是写死 2048，是为了将来换成resnet50（也是 2048）或resnet34（512）时不用改代码。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, lr=1e-3, backbone_scale=0.1, weight_decay=0.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_scale=0.1意味着分类头用 1e-3、主干用 1e-4，这个比例在多数迁移学习场景下都能用。weight_decay=0.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_max=epochs, eta_min=1e-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, scheduler=None, clip=1.0): model.train() total_loss, correct, total = 0.0, 0, 0 for imgs, labels in tqdm(loader, leave=False, desc="train"): imgs = imgs.to(device, non_blocking=True) labels = labels.to(device, non_blocking=True) optimizer.zero_grad(set_to_none=True) with autocast("cuda", dtype=torch.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_smoothing=0.1) scaler = GradScaler("cuda")

autocast只包前向和损失计算，反向由scaler.scale(loss).backward()自动处理。scaler.unscale_(optimizer)这行不能漏，梯度裁剪必须作用在真实的梯度值上，直接裁放大后的梯度等于没裁。clip=1.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, }, f"weights/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 传的是不是train=False；最后打印一次验证集前 8 张图的labels和文件名，肉眼确认没有重复样本。如果这些都做了指标还是高得离谱，那就去看混淆矩阵，某一类精确率 100% 而召回率 0，基本可以断定这一类在验证集里根本不存在。

5.2 显存打满与 BN 层翻车

现象：batch_size=32时报CUDA out of memory，降到 8 能跑但验证准确率忽高忽低，同一个 checkpoint 两次评估能差 5 个点。

原因：ResNet152 在 224 分辨率下，batch_size=32的激活值占用大约 12G 以上，8G 卡必然爆。而降到 8 之后，BatchNorm 层每个 batch 只有 8 个样本参与统计，running_mean和running_var抖动剧烈，评估时用的统计量和训练时对不上，指标自然不稳。

解决：显存不够优先开混合精度，再上梯度累积把等效 batch 补回来：

# 等效 batch_size = 8 * 4 = 32 accum_steps = 4 optimizer.zero_grad(set_to_none=True) for i, (imgs, labels) in enumerate(loader): with autocast("cuda", dtype=torch.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_none=True)

注意 loss 要除以accum_steps，否则梯度是累加值，等效学习率被放大了 4 倍。冻结主干训练时还有个额外的坑：BN 层虽然requires_grad=False，但前向仍然会更新running_mean/var，小 batch 下能把统计量带偏。稳妥做法是在每个 step 后强制把 BN 切回 eval：

def 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开头的键，用strict=False允许缺失：

ckpt = torch.load(path, map_location="cpu", weights_only=True) 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, strict=False) print("missing:", missing) # 应该只有 fc.* print("unexpected:", unexpected) # 应该为空

weights_only=True是新版本 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默认只有 64M，worker 往共享内存写 batch 时直接撑爆。

解决：把训练入口包进if __name__ == "__main__":，Windows 上num_workers建议先设 0 验证逻辑，通了再往上加。容器里加--shm-size=4g启动参数，或者把num_workers降到 2。另外persistent_workers=True在 worker 数为 0 时会报错，写成persistent_workers=num_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(name="resnet152", num_classes=10, pretrained=True, drop_path_rate=0.1): # timm 的 num_classes 会自动替换分类头，drop_path 是结构化的随机深度 return timm.create_model(name, pretrained=pretrained, num_classes=num_classes, drop_path_rate=drop_path_rate)

drop_path_rate对 ConvNeXt、ViT 这类结构有效，对 ResNet 影响很小，换主干时顺手带上。接口统一之后，训练脚本里只改一个字符串就能跑 A/B 对比，注意不同主干的输入尺寸不一样（EfficientNet 系列常用 300 或 384），img_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_version=17, do_constant_folding=True, ) 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-4

dynamic_axes把第 0 维标成动态，服务端才能一次推多张。opset_version=17兼容性比较好，低于 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 的输出对比，差值打印出来贴在提交记录里，谁改的谁负责。这个习惯帮我拦下过三次“导出成功但结果全错”的事故，比任何文档都管用。希望帮到你。

本文还有配套的精品资源，点击获取