ResNet152植物图像分类：迁移学习分类头改造与训练排错

简介：这份压缩包面向计算机视觉入门到进阶学习者、农业人工智能方向的学生与开发者，提供一套基于 ResNet152 与迁移学习的植物病害识别实践材料，可用于 38 类叶片病害分类的训练、复现与课程项目参考。包内标注文件总数 2000，类型明细以 5412 张 JPG 叶片图像为主体，配有 6 个 Python 脚本、2 个 pth 模型权重以及 json、txt 标签配置各 1 个，压缩包约 503.25MB，兼顾数据、代码与权重，便于直接搭建实验环境。已有 1433 人学习或下载，具备一定参考热度。材料覆盖数据准备与增强、替换输出层、优化器与学习率策略、验证集调优及准确率、精确率、召回率、F1 评估等环节，并保留可运行的训练脚本与权重，读者可据此理解 ResNet152 残差结构在迁移学习中的微调方式，复现高精度植物病害分类流程，并迁移到目标检测、语义分割等相近视觉任务中。

1. 从一张叶片照片说起：resnet152_plant.zip 里到底装了什么

把一张手机拍的叶片照片丢进去，几百毫秒后返回一个类别名——这是 resnet152_plant.zip 最直接的能力。它做的是植物图像分类，底座是计算机视觉里被反复验证过的 ResNet152，训练路线走迁移学习：先借助在 ImageNet 上收敛好的卷积特征，再把最后那层分类头换成自己的植物类别重新训。对做深度学习落地的人来说，这个包的价值不在「又一份模型」，而在于它把 152 层网络在植物这类细粒度数据上最容易翻车的几个环节——输入尺寸、类别映射、冻结粒度、预训练权重加载——摊开成了可以直接改的脚本。适合两类人：一类是想完整跑通一次图像分类流程的新手，另一类是有自己数据集、需要一个强 backbone 当起点的从业者。前提是你手上至少得有一批按类别分好文件夹的照片，单类几十张起步。

2. 换掉 fc 层：ResNet152 迁移学习的分类头改造与参数分层

拿到这个包，第一件要弄清楚的事是：为什么是 152，而不是更轻的 50 或 101。ResNet 系列的层数不是随便堆的，152 由 1 个 7×7 卷积、1 个最大池化、4 个 stage 和一个全连接层组成，stage 内部全部是 bottleneck 结构。bottleneck 的典型形态是「1×1 降维 → 3×3 提特征 → 1×1 升维」，输出通道是输入的 4 倍，stage1 到 stage4 的 block 数分别是 3、8、36、3，算下来正好 1 + 3×(3+8+36+3) + 1 = 152。参数总量约 60M，224×224 输入下的计算量在 11 GFLOPs 上下，比 ResNet50 贵出一大截。

代价换来的是更深的特征层次。植物分类很多时候是细粒度问题——同属不同种的叶片，差别可能只在叶缘锯齿、叶脉走向、绒毛分布这些纹理细节上。浅层网络靠局部纹理还能撑一撑，但要区分几十个形态相近的类别，stage3、stage4 那几十个 bottleneck 堆出来的高层语义就有用了。常见做法是：数据量在每类几百张以上、类别数不超过几百，用 152 做 backbone 是合理的；每类只有二三十张，152 很容易过拟合，反而不如 50 稳。这一点在选型阶段就要想清楚，不要等到训完发现验证集曲线一路抖。

2.1 152 层到底深在哪：把 bottleneck 的通道账算一遍

把每个 stage 的输出通道列出来，后面调参时心里才有数：

关键看最后一列：不管前面怎么卷，进全连接层之前，特征已经被全局平均池化压成一个 2048 维向量。所以替换分类头时，新的nn.Linear输入维度写死是 2048，输出维度才是你的类别数。很多人第一次改这里会把输入写成 512 或 1024，那是因为参考了 ResNet18/34 的代码，那两个用的是 basic block，最后一层通道是 512——搬到 152 上直接维度不匹配，报错还算好的，最怕的是加载权重时 strict=False 把错悄悄吞掉。

理解这一点，也就理解了迁移学习的操作本质：ResNet152 在 ImageNet 上学到的，是把任意图片映射成 2048 维语义向量的能力；你要做的只是在这个向量后面接一个从 2048 维到「你的类别数」的线性映射，并且让这个映射在冻结或半冻结的状态下学起来。前面的卷积层几乎不动，这就把「从零训练 60M 参数」变成了「训练一个 2048×N 的矩阵加少量微调」，对数据量的要求直接降一个量级。

2.2 预训练权重加载与分类头替换

包里用的是 torchvision 那套 resnet152 结构，权重文件一般是.pth。加载时有两个细节要处理：一是官方保存的可能是被state_dict包裹的字典，二是fc层维度跟你的类别数对不上，必须手动剔除。下面这段是我一般会先跑的检查代码：

import torch import torch.nn as nn from torchvision import models num_classes = 12 # 换成你自己的植物类别数 weights_path = "weights/resnet152.pth" model = models.resnet152(weights=None) # 先建空结构，避免联网下载 state = torch.load(weights_path, map_location="cpu") # 有的权重文件外面包了一层 {"state_dict": ...} 或 {"model": ...} if isinstance(state, dict) and "state_dict" in state: state = state["state_dict"] if isinstance(state, dict) and "model" in state: state = state["model"] # 关键一步：把预训练的分类头摘掉，否则维度和 num_classes 对不上 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 keys:", missing) # 预期只剩 fc.weight / fc.bias print("unexpected keys:", unexpected) # 预期为空列表 # 再替换分类头，注意输入维度是 2048 in_features = model.fc.in_features model.fc = nn.Linear(in_features, num_classes)

这段代码的逻辑是「先摘头、再换头」。strict=False不是让你无脑容忍缺失，而是用来做自检的：如果missing里出现了layer4.2.conv3.weight这类骨干层参数，说明权重文件本身不完整或者键名对不上，这时候继续训就是在拿随机初始化当预训练，精度会莫名其妙地低。unexpected同理，出现非空说明权重结构和 torchvision 定义有出入，得先对齐。我见过最隐蔽的一次翻车，是权重文件其实来自另一套实现，键名带module.前缀，加载时全被当成 unexpected 忽略，训练照样能跑，loss 也降，但验证集就是上不去——这种问题不看日志根本发现不了。

2.3 参数分层：为后面的冻结和解冻做准备

换完头，参数实际上分成两组，后面学习率要区别对待，所以提前拆出来：

backbone_params, head_params = [], [] for name, p in model.named_parameters(): if name.startswith("fc."): head_params.append(p) else: backbone_params.append(p) print(len(backbone_params), len(head_params)) # 152 层大约 160+ 组，head 只有 2 组 print(sum(p.numel() for p in backbone_params) / 1e6, "M")

参数分层的意义在于：骨干网络是「已经学会提取特征的人」，只需要很小的学习率微调；分类头是「刚上岗的新人」，需要大一点的学习率快速收敛。把这两组混在一个优化器里用同一个 lr，结果通常是 head 收敛太慢或者 backbone 被带偏。常规做法是 head 用 1e-3 量级，backbone 用 1e-4 甚至 1e-5，差一个数量级。这个比例不是玄学，背后是梯度量级和参数初始化状态的差异：head 是随机初始化的，梯度大；backbone 已经接近局部最优，梯度小，学习率一大就把好不容易学到的特征打散了。

3. 数据管线落到 224×224：植物图像的采样、增强与分桶

ResNet152 的结构决定了输入必须是 224×224 的三通道张量，这一条没有商量余地。但真实拍到的植物照片什么样都有：手机竖拍的长图、带大量背景的远景、逆光欠曝的、单叶特写占满画面的。数据管线要做的事，就是把这些形态各异的图，稳定地变成网络能吃的张量，同时别把有判别力的信息在上采样、裁剪的过程中弄丢。

我习惯把数据组织成root/train/类别名/图片和root/val/类别名/图片两级目录，类别名直接用中文或拉丁名都行，脚本里靠sorted(os.listdir())保证每次读出来的顺序一致。这一点看着不起眼，但类别索引和标签的映射必须可复现，否则训练时 label 0 是「某植物A」、推理时 label 0 变成「某植物B」，模型输出全乱，你还找不到原因。

3.1 数据集类：把目录读成 (路径, 标签) 列表

import os from PIL import Image from torch.utils.data import Dataset class PlantDataset(Dataset): def __init__(self, root, split="train", transform=None): self.transform = transform self.samples = [] self.classes = sorted(os.listdir(root)) # 固定类别顺序 self.class_to_idx = {c: i for i, c in enumerate(self.classes)} split_dir = os.path.join(root, split) for cls in self.classes: cls_dir = os.path.join(split_dir, cls) if not os.path.isdir(cls_dir): continue # 跳过非目录文件 for fn in os.listdir(cls_dir): if fn.lower().endswith((".jpg", ".jpeg", ".png", ".bmp")): self.samples.append( (os.path.join(cls_dir, fn), self.class_to_idx[cls]) ) def __len__(self): return len(self.samples) def __getitem__(self, idx): path, label = self.samples[idx] img = Image.open(path).convert("RGB") # 统一三通道，防灰度图报错 if self.transform: img = self.transform(img) return img, label

.convert("RGB")这行别省。植物数据集里经常混进带 alpha 通道的 PNG 或者单通道灰度扫描图，不转换的话，ToTensor出来是 1 通道或 4 通道，进conv1第一次前向就报维度错。这种错在训练跑到第几十个 batch 才出现时特别难查，因为前面的样本都是正常的 RGB。

3.2 transform 组合：训练和验证必须分开写

数据增强是迁移学习里性价比最高的一环，但很多人把训练和验证的 transform 写成同一套，验证集也跟着随机裁剪、随机翻转，导致每次评估结果都在抖，根本判断不了模型有没有变好。

from torchvision import transforms # 训练：随机性拉满，让模型见过各种拍摄条件 train_tf = transforms.Compose([ transforms.RandomResizedCrop(224, scale=(0.6, 1.0)), # 随机裁一块再缩放 transforms.RandomHorizontalFlip(p=0.5), transforms.RandomRotation(15), # 手机拍摄角度不固定 transforms.ColorJitter(brightness=0.2, contrast=0.2, saturation=0.2, hue=0.02), # 模拟光照差异 transforms.ToTensor(), transforms.Normalize(mean=[0.485, 0.456, 0.406], std=[0.229, 0.224, 0.225]), # ImageNet 统计量 ]) # 验证：确定性，只做 resize + 中心裁剪 val_tf = transforms.Compose([ transforms.Resize(256), transforms.CenterCrop(224), transforms.ToTensor(), transforms.Normalize(mean=[0.485, 0.456, 0.406], std=[0.229, 0.224, 0.225]), ])

参数背后有讲究。RandomResizedCrop的scale=(0.6, 1.0)控制裁剪面积比例，下限设太小（比如 0.08，ImageNet 训练常用值）会把叶片裁得只剩一小块纹理，植物分类里反而丢掉了整体形态；0.6 是个折中，既保留了完整叶片，又能让模型见到部分遮挡的情况。Normalize的均值方差必须和预训练权重一致，因为那 60M 参数是在这个输入分布下学出来的，你换一套统计量，等于把输入整体平移缩放，预训练特征的优势会被抵消掉一部分。这是个特别容易被忽略的点：有些人为了「适配自己的数据」重新算了 mean/std 填进去，结果精度掉两个点还找不到原因。

3.3 DataLoader：worker 数量和内存的平衡

from torch.utils.data import DataLoader train_loader = DataLoader( PlantDataset("data/plant", "train", train_tf), batch_size=32, shuffle=True, num_workers=8, pin_memory=True, drop_last=True, persistent_workers=True, ) val_loader = DataLoader( PlantDataset("data/plant", "val", val_tf), batch_size=64, shuffle=False, num_workers=8, pin_memory=True, )

batch_size=32对 152 来说不算大，224 输入下 32 张图在 16G 显存的卡上大约占 8～10G，留了余量给混合精度和梯度累积。drop_last=True是为了避免最后一个不足 32 的 batch 让 BatchNorm 的统计量产生波动——训练模式下的 BN 用当前 batch 的均值方差，batch 太小会不稳。num_workers设成 CPU 核数的 1/2 到 2/3，设太高反而因为进程调度拖慢吞吐；如果发现 GPU 利用率忽高忽低，先看是不是数据加载成了瓶颈，把persistent_workers=True打开能省掉每个 epoch 重建 worker 的开销。

还有一件事得提前确认：类别是否均衡。植物数据集常见的问题是某些品种照片特别好找、某些只有十几张，直接训会让模型偏向多数类。简单做法是在 Dataset 里统计每类样本数，用WeightedRandomSampler给少数类加权；或者至少先跑一遍混淆矩阵，看看召回率是不是集中在某几个类上。这件事放到训练之后再做，代价就大了。

4. 训练循环的可调参数：冻结策略、学习率与混合精度

迁移学习训 ResNet152，最容易出问题的不是网络结构，而是「什么时候冻、什么时候解、学习率给多少」。这三个决定直接决定了你是花几个小时收敛到一个不错的精度，还是训了两天发现验证集卡在 60% 不动。

我一般的节奏是两段式。第一段只训分类头，骨干全部冻结，让新的 fc 层先找到一个大致方向；第二段解冻骨干，用很小的学习率整体微调。为什么不能一上来就全解冻？因为 fc 是随机初始化的，最初几个 batch 的梯度会非常大，如果骨干也参与更新，这些大梯度会顺着反向传播把预训练好的卷积核冲乱，等于白拿了 ImageNet 权重。先冻住，等 head 稳定了再放开，是花最少时间买到最多精度的做法。

4.1 第一段：冻结骨干，只训分类头

import torch from torch.optim import AdamW from torch.cuda.amp import autocast, GradScaler device = torch.device("cuda" if torch.cuda.is_available() else "cpu") model.to(device) # 冻结除 fc 外的全部参数 for name, p in model.named_parameters(): p.requires_grad = name.startswith("fc.") optimizer = AdamW( [{"params": model.fc.parameters(), "lr": 1e-3}], weight_decay=1e-4, ) criterion = torch.nn.CrossEntropyLoss(label_smoothing=0.1) scaler = GradScaler() for epoch in range(5): model.train() running_loss, correct, total = 0.0, 0, 0 for imgs, labels in train_loader: imgs = imgs.to(device, non_blocking=True) labels = labels.to(device, non_blocking=True) optimizer.zero_grad(set_to_none=True) with autocast(): # 前向用 fp16，省显存提速 logits = model(imgs) loss = criterion(logits, labels) scaler.scale(loss).backward() # 梯度缩放，防 fp16 下溢 scaler.step(optimizer) scaler.update() running_loss += loss.item() * imgs.size(0) correct += (logits.argmax(1) == labels).sum().item() total += imgs.size(0) print(f"epoch {epoch} loss {running_loss/total:.4f} acc {correct/total:.4f}")

requires_grad = name.startswith("fc.")这一行把「冻结」写成了基于参数名的判断，比按模块手动遍历干净。label_smoothing=0.1在类别间形态相近时很有用，它防止模型对某个类输出过高的置信度，等价于给标签加了点噪声，泛化通常能涨零点几个点。GradScaler是 fp16 训练的标配，不加的话小梯度会在 fp16 下变成 0，表现为 loss 卡住不动，是个典型的「看起来像学习率问题、其实是精度问题」的坑。

这一段通常跑 3～5 个 epoch，验证集准确率会快速爬到某个平台，然后趋于平缓。看到平台出现，就该进第二段了。

4.2 第二段：解冻骨干，分组学习率

from torch.optim.lr_scheduler import CosineAnnealingLR # 全部解冻 for p in model.parameters(): p.requires_grad = True optimizer = AdamW([ {"params": backbone_params, "lr": 1e-4}, # 骨干小步走 {"params": head_params, "lr": 1e-3}, # 头部大步走 ], weight_decay=1e-4) scheduler = CosineAnnealingLR(optimizer, T_max=30, eta_min=1e-6) for epoch in range(30): model.train() for imgs, labels in train_loader: imgs = imgs.to(device, non_blocking=True) labels = labels.to(device, non_blocking=True) optimizer.zero_grad(set_to_none=True) with autocast(): loss = criterion(model(imgs), labels) scaler.scale(loss).backward() scaler.unscale_(optimizer) torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=5.0) # 防梯度爆炸 scaler.step(optimizer) scaler.update() scheduler.step() # 每个 epoch 结束后跑一遍 val_loader，记录 acc 和 loss

分组学习率是这段的核心。clip_grad_norm_的max_norm=5.0不是必需，但解冻初期梯度偶尔会尖峰，裁一下能避免某一步把权重带偏。注意unscale_要在裁剪之前调用，否则裁的是被缩放过的梯度，尺度不对。这个顺序错了不会报错，只是效果打折，属于那种「代码能跑、精度差一点」的隐性问题。

CosineAnnealingLR的T_max设成总 epoch 数，让学习率平滑衰减到接近 0。eta_min=1e-6留个下限，避免最后阶段学习率太小、BN 统计量还在变但权重几乎不动。

4.3 什么时候停：看验证集，不看训练集

训练集准确率到 99% 而验证集在 80% 附近晃，是 152 在这个数据量下的常态，不是 bug。判断该不该停，我一般看两个信号：验证集 loss 连续 5 个 epoch 不降反升，或者验证准确率连续 8 个 epoch 没有刷新最好值。满足其一就停，回到表现最好的那个 checkpoint。包里如果带了保存逻辑，确认它是按验证集指标保存，而不是按最后一个 epoch 保存——后者等于把过拟合的模型交出去。

5. 排查五个翻车现场：loss 不降、验证虚高、显存溢出与权重错位

同样的脚本，不同人跑出来的结果能差十几个点，多数不是模型问题，是流程里某一步悄悄错了。下面这几条是我在复现这类植物分类包时踩过或者见别人踩过的，按「现象 → 原因 → 解决」记下来，遇到时对照着查。

5.1 loss 从第一个 epoch 就纹丝不动

现象：训练日志里 loss 一直在 2.48 附近小幅波动，准确率等于类别数的倒数，看起来像模型完全没学。

原因通常有三个。一是标签全错位了——数据集类里class_to_idx用sorted生成，但保存 checkpoint 时没把classes列表一起存下来，推理时又用os.listdir的原始顺序重建，两边对不上。二是学习率太大，AdamW 配 1e-2 直接让 head 在第一步就飞出去了。三是 fp16 训练没加GradScaler，小梯度全变 0。

解决：先把 batch 里的图存几张出来肉眼看看标签对不对；再把学习率从 1e-3 往下试到 1e-4；确认autocast外面套了GradScaler。我一般会在训练前先跑一个极小规模的过拟合测试——拿 2 个类、每类 8 张图，关掉增强，看能不能在 50 步内把 loss 压到接近 0。压不下去说明管线本身有问题，跟数据量无关。

5.2 验证集准确率高得离谱

现象：验证集准确率第一轮就 97%，比训练集还高。

原因基本可以锁定为数据泄漏：训练集和验证集里有重复图片，或者同一张原图的不同裁剪被分到了两边。植物数据集尤其容易这样，同一株植物连拍十几张，随机划分时全跑进训练集，验证集里剩的都是几乎一样的图。另一个可能是验证集的 transform 里混进了随机增强，评估时带了随机性。

解决：按「拍摄对象」而不是「图片文件」划分，同一株、同一场景的图只进一边。划分完做一次哈希去重，把 md5 相同的文件清掉。验证 transform 单独写一份，跟训练那份物理隔离，不要复用同一个Compose。

5.3 第二个 epoch 显存溢出

现象：第一个 epoch 正常跑完，第二个 epoch 刚开始就 OOM。

原因多半是num_workers > 0时 worker 进程没释放，加上persistent_workers=True又没配好，内存越积越多；或者是验证阶段忘了torch.no_grad()，把计算图存下来了。

解决：验证循环外面套@torch.no_grad()或者with torch.no_grad():，这是硬要求，不是优化。worker 数量从 8 降到 4 试试，同时把pin_memory关掉对比一下。如果显存本身吃紧，把batch_size减半、用梯度累积补回来：

accum_steps = 4 for i, (imgs, labels) in enumerate(train_loader): with autocast(): loss = criterion(model(imgs.to(device)), labels.to(device)) / accum_steps scaler.scale(loss).backward() if (i + 1) % accum_steps == 0: scaler.step(optimizer) scaler.update() optimizer.zero_grad(set_to_none=True)

注意 loss 要除以accum_steps，否则等效学习率被放大，前面调好的参数全废。

5.4 加载权重后精度反而比随机初始化低

现象：用了预训练权重，验证集准确率比不用还低几个点。

原因：权重加载失败但被strict=False静默吞掉了。missing里如果有大量骨干层参数，说明键名不匹配，实际训练的是随机初始化的 152。还有一种情况是权重是在 RGB 通道顺序为 BGR 的数据上训的，而你按 RGB 读图，输入分布整体偏了。

解决：加载后强制打印missing和unexpected的长度，骨干层缺失数大于 0 就直接报错退出，不要继续训。通道顺序问题可以做个对照实验：同一批图分别按 RGB 和 BGR 读入，各训 2 个 epoch 看 loss 下降速度，差很多就说明对不上。

5.5 保存的 checkpoint 换了机器加载不了

现象：训练机上好好的权重，拷到推理机上load_state_dict报 key 不匹配。

原因：训练时用了nn.DataParallel或者分布式，保存的 state_dict 键名带module.前缀。

解决：保存时统一剥掉前缀，或者在加载端做兼容：

state = torch.load(ckpt_path, map_location="cpu") state = {k.replace("module.", "", 1): v for k, v in state.items()}

更稳妥的做法是保存成一个完整字典，把model_state、classes、num_classes、input_size、normalize_mean/std一起塞进去。少了这些元信息，模型文件就是个黑匣子，换个环境就得靠猜。

6. 从 checkpoint 到推理接口：一次可复现的验证怎么做

训完模型只是开始，真正决定这个包能不能用的是推理端和训练端能不能对上。我见过太多情况：训练日志漂亮，交付出去的推理脚本一跑，类别名全串了，或者同一张图两次预测结果不一样。根因几乎都是预处理不一致——训练时用RandomResizedCrop，推理时用了Resize(224)直接压扁，长宽比变了，特征分布就变了。

我习惯在推理脚本里把 transform 写死，并且和验证集那份逐行对齐，不共用变量、不 import 训练脚本，宁可复制一份出来。同时把类别顺序固定写进一个classes.json，训练结束时导出，推理时读它，彻底断掉「靠目录顺序推类别」这条不可靠的路。

import json import torch from PIL import Image from torchvision import transforms @torch.no_grad() def predict(model, img_path, classes, device="cuda"): model.eval() tf = transforms.Compose([ transforms.Resize(256), transforms.CenterCrop(224), transforms.ToTensor(), transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225]), ]) x = tf(Image.open(img_path).convert("RGB")).unsqueeze(0).to(device) prob = torch.softmax(model(x), dim=1)[0] conf, idx = prob.max(0) return classes[idx.item()], round(conf.item(), 4)

验证阶段还有一件事值得做：不要只看总体准确率，把混淆矩阵和每类召回率打出来。植物分类里经常出现某一对类别互相混淆，总体 88% 看着不错，实际上那两个类各错一半。定位到具体类别对，再回去看这几类的训练样本是不是风格太单一（比如全是同一背景、同一光照），针对性补数据比调参有效得多。

model.eval()这句是硬性的。漏掉它，BatchNorm 会用当前 batch 的统计量而不是训练时累积的滑动平均，单张图推理时 batch 只有 1，BN 的方差估计完全失真，输出会非常随机。这类问题不带报错，只能靠「同一张图跑十次结果是否一致」这种笨办法发现。

从那以后，我每次交付一个分类模型，都会强制走一遍固定流程：拿 20 张训练时没见过的图，在训练机和目标机器上各跑一次，逐条比对类别和置信度，差值超过 0.01 就停下来查预处理。这个习惯帮我拦下过好几次「权重没问题、管线错了」的交付事故。希望帮到你。

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