VGG19图像分类迁移学习：冻结策略与验收避坑指南

简介面向智能计算系统课程实验与深度学习部署入门者这份实验4-1资料围绕VGG19图像分类任务提供从卷积网络推理到硬件加速评估的实践素材适合需要理解模型量化与不同计算平台性能差异的学习者。压缩包共4个文件由3个Python脚本和1个已训练模型文件组成整体约95.86MB脚本承担评估流程与初始化工作模型文件以INT8量化格式保存VGG19权重可降低内存占用并提升推理速度。已有2154人学习下载在课程实验场景中具备一定参考价值。读者可借助现成模型和CPU、MLU两套评估入口观察图像分类的完整推理结果与准确率表现进而理解量化模型在通用处理器和专用加速器上的部署取舍积累模型轻量化、硬件适配与性能对比的排错思路并形成可复用的实验记录。1. 准确率卡在 0.62 的那次实验VGG19 图像分类要先解决什么把 VGG19 的预训练权重取下来、换掉最后一层全连接、跑上二十轮是很多人做人工智能课程实验时图像分类的标准开局。结果通常不好看训练集准确率冲到 0.95验证集在 0.62 附近反复横跳损失曲线像心电图。问题不在 VGG19 本身而在「换个分类头就开训」这个动作它漏掉了迁移学习最要紧的三件事冻结策略、增强强度、学习率与可训练参数量的匹配。这套方案面向两类人要交智能计算系统实验报告、需要完整跑通并拿出指标的学生以及想在一周内搭出一个能用的图像分类基线、再往下迭代的从业者。下面按需求、设计、实现、验收的顺序走代码和参数可以直接抄进工程重点不在 VGG19 那十九层怎么堆而在管线怎么跑出稳定、可复现、能写进报告的结果。2. 需求拆解与技术选型为什么这套实验锁死 VGG19 加迁移学习2.1 把「做一个图像分类」拆成三个可验收的交付物拿到题目就写model vgg19()写到一半会卡住因为不知道该干什么了。我一般先把题目拆成交付物每个交付物带明确的验收口径这样实验报告里的「设计」「步骤」「结果分析」三节都有出处不会写成流水账。交付物具体内容验收口径数据管线训练、验证、测试三份索引固定的预处理与增强参数能吐出 (image, label) 批次的 DataLoader固定随机种子跑两次前三个批次的张量完全一致模型以 VGG19 为骨干、输出维度等于类别数的网络主干可冻结可解冻喂一个 4 张图的假批次输出形状为 (4, N)冻结状态下主干参数梯度为 None训练与评估epoch 级训练循环测试集指标报告每轮日志含 train_loss / train_acc / val_loss / val_acc测试集给出总体准确率与每类 F1拆完这三块一周的工期就有了节奏第一天到第二天做数据管线并验证可复现第三天搭模型跑通前向第四天到第五天训练调参第六天做评估和失败案例分析第七天写报告。顺序不能反先训后调数据是典型的血泪经验数据管线里一个标签错位能让后面所有调参白做。数据规模要提前确认。这类实验通常不会给很大的数据集几千张、五到十个类别是常见配置如果是自己攒的数据每类两百张起步比较稳低于一百张就得靠更强的增强或者干脆把学习率压到 1e-5 做全量微调否则分类头学不到东西。2.2 骨干网络选型VGG19 的堆叠结构值不值这份显存VGG19 的结构高度同构五个卷积段段内重复堆叠 3×3 卷积段间用最大池化把分辨率减半、通道翻倍通道数依次是 64、128、256、512、512最后接三层全连接输出 1000 类。这种「同一段里卷积核尺寸和通道数都不变」的设计让每一段的语义非常清楚前两段抓边缘和纹理中间两段抓局部结构最后一段抓整体形状。参数量分布值得算一遍。卷积主干大约 2000 万参数三层全连接大约 1.24 亿参数分类头一家就占了八成以上。所以把分类头换掉之后模型立刻瘦身到 2000 万量级这也是迁移学习在小数据集上能跑起来的直接原因之一真正需要重新学习的部分只有新分类头那十几兆。代价同样明显。224×224 输入下第一段卷积产生的激活图就有 224×224×64×4 字节 ≈ 12.8 MB 一张反向传播还要留着中间结果batch 一加到 32 显存就告急。推理速度也比同精度的小模型慢好几倍。真做产品我会选更轻的骨干但这个实验题指定 VGG19教学价值就在它的规整性每一段做什么一目了然可以逐段冻结做对照实验报告里「深度对特征抽象能力的影响」这类分析才有东西可写。换成带残差连接的网络注意力容易被 shortcut 分散反而不利于讲清楚「层数」这条主线。2.3 迁移学习策略冻结哪一段、替换哪一段预训练权重是在大规模通用图像数据上训出来的前几段学到的边缘、纹理、色块特征对绝大多数图像分类任务都通用越靠后的层越贴近原任务的类别可复用的程度越低。所以冻结策略的原则是越靠前越该冻越靠后越该放。策略可训练参数适用数据量收敛轮次主要风险A 只训分类头约 0.13 亿5000 张以下10 到 15特征不适应新域时上限低B 解冻第五段卷积 分类头约 0.22 亿5000 到 2 万张15 到 25学习率没降下来会破坏预训练特征C 全量微调约 1.4 亿2 万张以上30 轮以上小数据上极易过拟合我的习惯是先按 A 跑通拿到一个能复现的基线确认管线没问题后解冻第五段卷积学习率降到主干的十分之一做策略 B通常在基线上能涨三到五个百分点数据量真的够大再去碰 C。直接上 C 而数据只有几千张验证集准确率大概率在第一轮就到顶然后一路下滑这是最常见的翻车方式。3. 数据管线与工程骨架从原始图片到张量批次的四段流水3.1 目录结构与模块职责划分实验代码最怕全部塞进一个文件改一个参数要翻两百行。我一般按职责切成五块配置、数据、模型、训练引擎、脚本入口各管一摊报告里画模块图也直接照这个来。vgg19_cls/ ├── configs/ │ └── default.yaml # 类别数、输入尺寸、batch、学习率、轮次全部集中在这里 ├── data/ │ ├── train/ # 每类一个子目录目录名就是类别名 │ │ ├── class_a/ │ │ └── class_b/ │ ├── val/ │ └── test/ ├── src/ │ ├── dataset.py # 数据集构建、增强、DataLoader 组装 │ ├── model.py # VGG19 改造、冻结控制 │ ├── engine.py # 单轮训练、单轮验证、评估指标 │ └── utils.py # 随机种子、日志、检查点读写 ├── scripts/ │ ├── train.py │ └── evaluate.py └── outputs/ ├── ckpt/ # 权重文件 └── logs/ # 每轮的指标记录按子目录存放训练集、验证集、测试集是为了用框架自带的目录数据集类直接构建省掉手写索引文件这一步。但要注意三个目录必须是物理隔离的图片副本不能靠划分比例从同一个目录里随机切否则同源图片会同时出现在训练和验证里指标虚高得离谱。配置集中在一个 yaml 里的好处是答辩现场被问到「你 batch 用的多少」时能直接翻到那一行坏处是容易改完忘了同步所以训练脚本启动时要把整份配置打印到日志里事后复盘全靠这行记录。3.2 预处理与增强参数训练集和验证集为什么必须用两套训练集的预处理要带随机性验证集和测试集必须是确定性的这两套不能共用同一个 transforms否则评估结果每跑一次都不一样报告里没法写数字。import torch from torchvision import transforms # 与预训练权重配套的通道统计量直接决定输入分布是否落在权重期待的范围内 MEAN [0.485, 0.456, 0.406] STD [0.229, 0.224, 0.225] train_tf transforms.Compose([ transforms.RandomResizedCrop(224, scale(0.7, 1.0)), # 随机裁剪加缩放模拟拍摄距离变化 transforms.RandomHorizontalFlip(p0.5), # 左右翻转类别语义不变时才能开 transforms.ColorJitter(brightness0.2, contrast0.2, saturation0.2), transforms.ToTensor(), transforms.Normalize(MEAN, STD), ]) val_tf transforms.Compose([ transforms.Resize(256), # 先短边缩到 256 transforms.CenterCrop(224), # 再中心裁 224保证评估口径完全一致 transforms.ToTensor(), transforms.Normalize(MEAN, STD), ])RandomResizedCrop的scale(0.7, 1.0)控制裁剪面积占比取值越小模型越依赖局部特征小数据集上能给到 0.6 到 0.8数据量大就收窄到 0.8 到 1.0。ColorJitter三个参数都取 0.2 是温和档如果类别是靠颜色区分的比如不同成熟度的果实这项一定要关掉或者压到 0.05否则等于在训练模型忽略关键线索。Normalize的那组均值方差来自预训练权重训练时的统计量不是随便填的。换了权重来源就得换这组数用错了不会报错只会让收敛变慢、最终精度掉一两个点排查起来非常玄学。还有一点容易忽略翻转增强能不能开取决于类别语义在翻转后是否保持不变。车牌、文字、方向指示这类数据翻了就变味训练集标签会变得自相矛盾。3.3 DataLoader 与可复现性配置可复现不是加一行torch.manual_seed就完事随机性来自四处Python 的 random、numpy、torch 的 CPU 与 GPU、以及 DataLoader 每个 worker 各自的随机状态。少一处两次训练的曲线就对不上。import random import numpy as np import torch from torch.utils.data import DataLoader def seed_everything(seed: int 42): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) torch.backends.cudnn.deterministic True # 固定卷积算法牺牲少量速度换结果稳定 torch.backends.cudnn.benchmark False g torch.Generator() g.manual_seed(42) train_loader DataLoader( train_set, batch_size32, shuffleTrue, num_workers4, pin_memoryTrue, # 锁页内存配合 GPU 训练能明显减少数据搬运等待 drop_lastTrue, # 丢掉最后一个不满批次避免小批次拉偏均值 worker_init_fnlambda wid: np.random.seed(42 wid), # 每个 worker 独立且可复现的增强序列 generatorg, ) val_loader DataLoader(val_set, batch_size32, shuffleFalse, num_workers4, pin_memoryTrue)num_workers不是越大越好超过 CPU 物理核心数之后进程切换的开销会盖过并行收益一般取 4 到 8。pin_memoryTrue只在用 GPU 训练时有意义纯 CPU 环境开着反而占内存。drop_last在训练集上建议开验证集上必须关否则最后一批样本被丢掉算出来的准确率不是全量口径。如果换了机器跑第一次训练出来的曲线和之前不一样先查cudnn.deterministic有没有打开、worker_init_fn有没有传这两处漏一个结果就是玄学。4. 模型改造与训练主循环把 1000 类头换成自己的分类器4.1 分类头替换与参数冻结的代码落地VGG19 原始分类头的第一层输入维度是 25088也就是 512 通道乘 7 乘 7 的特征图展平结果这个数字跟输入尺寸绑死改动输入分辨率就得同步改它。新分类头我一般用「降维层 Dropout 输出层」的三段式中间维度取 512参数量约 1300 万显存和表达力都够用。import torch.nn as nn from torchvision import models class VGG19Classifier(nn.Module): def __init__(self, num_classes: int, head_dim: int 512, freeze_backbone: bool True): super().__init__() backbone models.vgg19(weightsmodels.VGG19_Weights.DEFAULT) self.features backbone.features # 只取卷积主干丢掉原来的三层全连接 self.freeze_backbone freeze_backbone in_features 512 * 7 * 7 # 25088与 224 输入尺寸绑定 self.classifier nn.Sequential( nn.Linear(in_features, head_dim), nn.ReLU(inplaceTrue), nn.Dropout(p0.5), nn.Linear(head_dim, num_classes), ) if freeze_backbone: for p in self.features.parameters(): p.requires_grad False # 冻结后反向传播不计算这部分的梯度 def train(self, mode: bool True): super().train(mode) if self.freeze_backbone: self.features.eval() # 关键覆盖递归切换保住 BN 的滑动统计量 return self def forward(self, x): x self.features(x) x torch.flatten(x, 1) return self.classifier(x)重写train()这一段是必须的。父类的model.train()会把所有子模块递归切成训练模式如果骨干里带 BN 层冻结之后 BN 的滑动均值和方差仍在被每个批次更新等于用一个不断漂移的归一化去喂固定的卷积核验证指标会莫名其妙地抖。原版 VGG19 没有 BN这个坑不明显一旦换成带 BN 的变体不重写train()就得在训练循环里手动补一句model.features.eval()。head_dim从 512 调到 1024 能增加表达力参数量翻到 2600 万显存紧张时往下调到 256 也够跑。Dropout取 0.5 是小数据集的常规值数据上万之后可以降到 0.3。4.2 优化器、损失与学习率调度的配置逻辑冻结训练和解冻微调学习率必须分开设这件事用参数组做最干净新分类头是随机初始化的需要大步长预训练主干是已经收敛的特征只能小步挪。import torch def build_optimizer(model, lr_head1e-3, lr_backbone1e-4, weight_decay1e-4): head_params [p for p in model.classifier.parameters() if p.requires_grad] backbone_params [p for p in model.features.parameters() if p.requires_grad] groups [{params: head_params, lr: lr_head}] if backbone_params: # 冻结策略下这里为空只有分类头一组 groups.append({params: backbone_params, lr: lr_backbone}) return torch.optim.SGD(groups, momentum0.9, weight_decayweight_decay) criterion torch.nn.CrossEntropyLoss(label_smoothing0.1) # 标签平滑抑制小数据集上的过拟合 scheduler torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max20, eta_min1e-5)主干的lr_backbone设成分类头的十分之一是解冻微调时的经验比例设成一样大前几轮就能把预训练特征冲垮验证准确率会先掉一大截再慢慢爬白白浪费算力。weight_decay用 1e-4 是分类任务的通用起点如果发现训练损失下降快而验证不涨可以先加到 5e-4 试试。label_smoothing0.1让目标分布不再是一个 one-hot 尖峰模型不会拼命把 logits 往极端推泛化通常更稳。用不用看数据量样本过万之后收益不明显。优化器选 SGD 而不是自适应方法是因为微调预训练卷积网络时SGD 加动量在最终精度上通常更占优如果只是快速跑通看效果Adam 配 1e-4 收敛更快报告里注明用的是哪个就行。4.3 训练过程的可观测性日志、曲线与检查点训练循环除了前向反向还得负责三件事累计指标、按验证集挑最优轮、把足够多的元信息塞进检查点。最后这件事最容易被省也最容易在答辩现场出事。def run_epoch(model, loader, criterion, optimizer, device, trainTrue): model.train(train) total_loss, correct, total 0.0, 0, 0 with torch.set_grad_enabled(train): for imgs, labels in loader: imgs, labels imgs.to(device, non_blockingTrue), labels.to(device, non_blockingTrue) if train: optimizer.zero_grad(set_to_noneTrue) logits model(imgs) loss criterion(logits, labels) if train: loss.backward() optimizer.step() total_loss loss.item() * imgs.size(0) # 乘回样本数最后才不会被末批拉偏 correct (logits.argmax(dim1) labels).sum().item() total imgs.size(0) return total_loss / total, correct / total # 保存时把推理需要的全部上下文一起写进去 torch.save({ model: model.state_dict(), class_to_idx: val_set.class_to_idx, # 类别名到索引的映射推理时顺序错了结果全反 input_size: 224, mean: MEAN, std: STD, epoch: epoch, val_acc: val_acc, }, outputs/ckpt/best.pth)指标累计时乘回批大小是为了处理最后一个不满批次如果直接用批次均值再平均末批样本少权重却被算成一样大准确率会偏一点数据量小时偏差能被看出来。检查点里存class_to_idx是硬要求。只存state_dict的话推理脚本得靠人肉记住「索引 0 对应哪个类」换台机器、换个人接手标签顺序一错准确率能从 0.9 掉到随机水平而且报错信息里什么都没有纯黑匣子。5. 避坑与排查VGG19 图像分类实验里最容易翻车的五个点5.1 数据侧的两个隐形错误现象一验证集准确率从第一轮就固定在 1/N之后几乎不动。原因通常是标签和文件没对上。用目录数据集类时class_to_idx是按文件夹名的字典序分配的如果预处理脚本按文件名排序生成标签两套顺序不一致模型学的就是一个错位映射。另一种可能更隐蔽训练集和验证集是从同一个目录随机切出来的同一张图的近似副本同时进了两边验证集失去意义。 解决方法是打印前三个批次把图片还原成可视化图旁边标上标签名人眼看一遍同时统计训练集和验证集的图片哈希重复的直接剔除。这一步五分钟能省掉后面两天的调参。现象二训练损失正常下降验证损失先降后升准确率卡住。小数据集上 VGG19 这种量级的模型过拟合是默认状态而不是意外。原因多半是增强太弱加上可训练参数太多。 解决顺序是先确认增强真的生效RandomResizedCrop有没有被后续的Resize覆盖掉再把学习率降一半最后才考虑加数据或解冻更少的层。反过来做先加数据再调学习率很容易把「学习率太大导致的震荡」误判成过拟合。5.2 模型与显存侧的三个高频问题现象三batch 加到 16 就显存不足日志里连第一轮都没跑完。VGG19 的激活占用远大于参数占用224 输入下前两段的特征图非常大反向传播还要留着中间结果。 解决手段按性价比排序开混合精度训练显存能省三到四成速度也快、冻结主干减少梯度存储、用梯度累积把等效批大小凑上去而显存只按小批次算、最后才是降输入分辨率。改分辨率要同步改分类头的输入维度 25088改漏了会直接报形状不匹配。现象四换成带 BN 的变体并冻结主干后验证准确率每轮抖三到五个点。原因在第 4.1 节提过model.train()把冻结的骨干也切回了训练模式BN 的滑动统计量被小批次数据不停改写。 解决办法是重写train()或者在每个 epoch 开始训练前补一句model.features.eval()。判断有没有踩这个坑看验证集指标是否在很小范围内震荡、且训练损失下降异常平滑。现象五训练日志里准确率 0.9写好的推理脚本跑同一批图只有 0.3。八成是推理脚本的预处理和训练时不一致少做了Normalize、Resize用了 224 直接拉伸而训练用的是 256 加中心裁剪、或者class_to_idx顺序读错。这类问题在评估脚本里自带指标时不会暴露只有分离出独立推理脚本才会现形。 解决办法是把验证集的预处理代码抽成一个函数训练和推理共用同一份检查点里存class_to_idx推理时从文件读而不是手写上线前强制用磁盘上的原图跑一遍端到端链路。提示这五个现象里有四个不会抛异常只表现为「效果不好」。所以训练前把管线自检做成脚本比事后猜要省事得多。6. 验收与答辩用一张指标表证明模型真的学明白了验收这一步我建议先把评估脚本写死指标口径固定下来再去调模型否则每次改评估方式前面所有对比都白做。测试集只用一次调参全程看验证集这是纪律问题。验收项合格线采集方式测试集总体准确率五到十类任务不低于 0.85评估脚本一次性输出每类 F1 最低值不低于 0.70分类报告逐类打印训练与验证准确率差不超过 0.10最后一轮日志相减单张推理时延GPU 上不超过 50 ms预热十次后取均值结果可复现性同种子两次训练验证准确率差不超过 0.5 个百分点重跑一次对比表里最容易被忽略的是最后两行。时延要预热第一次推理包含显存分配和算子编译直接计时能差出好几倍可复现性要真跑第二遍我见过太多「固定了种子但两次结果差三个点」的情况最后查出来是num_workers的随机状态没管。答辩演示控制在三分钟按这个顺序走先用一句话说清任务和类别数再放混淆矩阵指出哪两类最容易混然后挑三张分错的测试图现场分析——是背景干扰、是类别本身边界模糊、还是训练集里这类样本太少。这三张图讲完比念十页准确率曲线有说服力得多。最后现场跑一次单张推理从磁盘读图到输出类别名全程不碰训练代码证明整条链路是通的。如果被问到「为什么准确率是 0.87 而不是 0.95」别硬解释模型容量直接给数据每类样本数、增强强度、冻结策略、训练轮次然后说明如果再给一倍数据或解冻第五段卷积预期还能涨多少。这种答法比背结论稳。从那以后我每次交实验前都强制走一遍换台机器用同一种子重跑一次、拿测试集图片从磁盘读进来走完整推理链路、把class_to_idx从检查点里读出来核对一遍。这三步十分钟能挡掉九成的翻车剩下的那一成通常是真的模型不行而不是流程有问题。需要照着改的话这套实验的工程骨架、配置文件和验收记录表可以直接拿去用。希望帮到你。本文还有配套的精品资源点击获取