从深度学习课程到跑通代码：PyTorch最小实验与MLP训练闭环

深度学习的学习曲线，很少卡在“看不懂公式”这一层，更多卡在“看懂了但写不出来”。纽约大学的深度学习课程在 2021 年由 Yann LeCun 与 Alfredo Canziani 讲授，讨论的主题集中在基于能量的模型、卷积网络、自监督与表示学习这些方向，理论密度高、推导多，很多人看完一遍能复述概念，却仍然写不出一个能收敛的训练脚本。问题不在于课程讲得不够细，而在于从“听”到“跑”之间少了一条可执行的主线。

这篇内容围绕这条主线展开：把课程里的抽象概念拆成几个可以动手验证的小实验，从环境准备、张量操作、自动求导，一路写到一个完整的两层 MLP 训练闭环，然后补上参数调优、训练排查和工程化整理。适合已经具备 Python 基础、了解一点点 NumPy、准备系统学习深度学习并希望真正跑通代码的读者。读完应该能做到：在任何一台有独立显卡或纯 CPU 的机器上把训练脚本跑起来，看懂 loss 曲线为什么不动，知道去哪个环节找原因，并且把实验代码整理成别人能复现的结构。具体到每一讲的细节，以课程实际发布的内容为准，本文只负责把工程侧的部分补齐。

1. 深度学习课程光看视频不够：先搭一条能跑通的主线

课程视频的价值在于把概念讲透，但它的组织形式天然是“一条线往下讲”，而真正动手时遇到的是“多线程同时出问题”。一个训练脚本跑不起来，可能同时牵扯环境版本、数据形状、设备不一致、梯度没清零、损失函数选错这五件事。看视频时这五件事被拆在不同讲里，动手时它们全部堆在一个报错上。这就是为什么很多人看完课程觉得懂了，一写代码就懵。

解决办法不是把视频再看一遍，而是先给自己定一条主线：每一个理论主题，都必须配一个能运行、能改参数、能观察到结果变化的最小实验。主线不需要宏大，能把“输入—前向—损失—反向—更新—验证”这条链路跑通，就已经覆盖了深度学习工程中最常见的 80% 问题。

1.1 从“听懂”到“跑通”之间缺的三件事

第一件缺的是形状意识。课程里讲矩阵乘法时，符号是 $y = Wx + b$，看上去很干净。但到了代码里，一个 batch 的输入是 [B, D]，权重是 [D, H]，偏置是 [H]，输出是 [B, H]，一旦 B 或 D 对不上，报错信息通常是 mat1 and mat2 shapes cannot be multiplied。能读懂这句话，比能推导梯度公式更影响当天的工作效率。

第二件缺的是数值直觉。理论课上讲学习率太大导致发散，只是一句话；代码里看到 loss 从 0.69 跳到 3.2 再到 nan，是另一回事。知道“学习率 1e-1 在 Adam 上偏大”“1e-5 可能半天不动”这种量级判断，只能靠反复实验建立。

第三件缺的是可复现意识。同一个脚本，今天跑准确率 0.91，明天跑 0.87，如果你不知道随机种子、数据打乱顺序、dropout、BatchNorm 的滑动统计都会影响结果，就会误以为是模型改了有效。可复现不是学术要求，是排错的前提：结果不可复现，你就无法判断某次修改到底有没有用。

下面这张表把这三件事对应的具体能力和验证方式对齐，方便自查：

1.2 把课程主题映射成可执行的小实验

理论主题和实验之间不是一一对应关系，一个实验往往同时验证多个概念。按下面的映射来组织，学习效率会高很多：

这张表不是课程大纲的替代品，而是一个检查表：每学完一个主题，就在表里找到对应行，把实验跑一遍。跑通了打个勾，跑不通就说明这一块还没真正掌握。

1.3 学习环境、实验环境、生产环境的边界

这一点必须提前说清楚，否则后面会反复踩坑。很多人在自己的笔记本上跑通了实验，就以为代码可以直接上服务器，结果发现显存不够、依赖版本不一致、多卡逻辑完全没写。

学习环境的目标是“快速看到结果”，允许用合成数据、小模型、单卡、不做任何工程封装。实验环境的目标是“对比不同配置”，需要固定种子、记录超参、保存日志。生产环境的目标是“稳定可回滚”，需要考虑数据版本、模型版本、推理性能、异常兜底。三者的要求差别很大：

注意：学习阶段可以随意试错，但一旦要对比两个方案的效果，就必须切到实验环境的标准，否则你比较的可能是随机种子带来的差异，而不是方案本身的差异。

2. 环境准备：Python、PyTorch 和 GPU 的最小可用组合

环境这一步最容易被人轻视，也最容易在半夜卡住。深度学习框架对 Python 版本、CUDA 驱动、cuDNN 版本都比较敏感，随意 pip install 一个最新版，很可能和机器上的驱动对不上。合理的做法是先确认硬件和驱动，再选框架版本，最后装依赖。

原则只有一条：先验证驱动，再装框架，最后才装业务依赖。顺序反了，出了问题就分不清是驱动、框架还是业务包的问题。

2.1 版本选择和依赖清单

如果材料里没有明确指定版本，落地前一定要先确认自己机器的驱动情况，再决定装哪个 CUDA 版本对应的 PyTorch。常见做法是先看驱动支持的最高 CUDA 版本，再选择不超过它的框架版本。下面是一份通用的依赖清单，具体版本号要以实际查询到的官方发布为准：

text复制Python       3.9 - 3.11      建议 3.10，兼容性较好
PyTorch      2.x              与 CUDA 版本对应
NumPy        1.24+            很多科学计算库的硬依赖
Matplotlib   3.7+             画 loss 曲线
tqdm         4.x              训练进度

用 requirements.txt 固定下来，比在命令行里逐个 pip install 可靠得多：

text复制torch>=2.0
numpy>=1.24
matplotlib>=3.7
tqdm>=4.65

这里不建议把 torch 的版本写成完全固定的小版本号。因为不同操作系统和 CUDA 组合下，可用的 wheel 不一样，写死之后换一台机器就装不上。比较稳妥的方式是：在 requirements.txt 里写下限，在实验记录里写清楚实际使用的完整版本。可以用下面的命令导出真实环境：

bash复制python -c "import torch, numpy; print(torch.__version__, numpy.__version__)"

2.2 建独立环境并验证 CUDA 是否真的可用

不要往系统 Python 里装框架。用 conda 或 venv 建独立环境，出问题直接删掉重建，成本很低。

bash复制conda create -n dl-study python=3.10 -y
conda activate dl-study
pip install torch numpy matplotlib tqdm

装完之后必须验证，而且不能只看 import torch 是否成功，那只能说明包装上了，说明不了 GPU 能用：

python复制import torch

print("torch version:", torch.__version__)
print("cuda available:", torch.cuda.is_available())
print("cuda version:", torch.version.cuda)
print("device count:", torch.cuda.device_count())
if torch.cuda.is_available():
    print("device name:", torch.cuda.get_device_name(0))
    x = torch.randn(1024, 1024, device="cuda")
    y = x @ x
    torch.cuda.synchronize()
    print("matmul ok, result shape:", y.shape)

这段代码的预期输出是版本号、True、CUDA 版本、设备数量、显卡名称，最后一行打印矩阵乘法结果。最后那步矩阵乘法不能省，因为有些环境的 CUDA 初始化是延迟的，只调 is_available() 会返回 True，真正分配显存时才报错。显式做一次运算并 synchronize()，才能确认整条链路通。

常见的三种失败现象和处理方式：

2.3 目录结构和随机种子的约定

目录结构在项目还小的时候看不出价值，等你有三份不同的实验脚本时就会感谢自己。一个够用的结构：

text复制dl-study/
├── configs/
│   └── mlp_base.yaml
├── data/
│   └── .gitkeep
├── src/
│   ├── __init__.py
│   ├── data.py
│   ├── model.py
│   ├── train.py
│   └── utils.py
├── outputs/
│   └── .gitkeep
├── requirements.txt
└── README.md

configs 放超参，src 放代码，outputs 放日志和权重，data 放数据。outputs 和 data 加进 .gitignore，只保留 .gitkeep 占位。这样做的好处是所有路径都可以用相对项目根目录的方式写，换机器不会因为绝对路径挂掉。

随机种子的固定写成一个函数，统一调用：

python复制import os
import random
import numpy as np
import torch

def set_seed(seed: int = 42, deterministic: bool = False) -> None:
    random.seed(seed)
    np.random.seed(seed)
    torch.manual_seed(seed)
    torch.cuda.manual_seed_all(seed)
    os.environ["PYTHONHASHSEED"] = str(seed)
    if deterministic:
        os.environ.setdefault("CUBLAS_WORKSPACE_CONFIG", ":4096:8")
        torch.use_deterministic_algorithms(True)
        torch.backends.cudnn.benchmark = False

几个细节值得说明。torch.manual_seed 管 CPU，torch.cuda.manual_seed_all 管所有 GPU，只调前者在多卡环境下不够。PYTHONHASHSEED 影响哈希相关的顺序，数据管道里如果用了 set 就需要它。deterministic=True 会开启确定性算法，代价是部分算子变慢，而且某些操作在确定性模式下会直接报错说不支持，所以只在需要严格复现时才打开，日常训练保持 False。

注意：固定种子只能保证在相同硬件、相同框架版本、相同算子实现下结果一致。换显卡型号或换框架小版本，结果仍可能有微小差异，这是浮点累加顺序导致的，属于正常现象。

3. 从张量到自动求导：把课程里的符号落成代码

理论课上写的 $f(x) = \sigma(Wx+b)$，在代码里被拆成了形状、设备、数据类型、是否需要梯度这几个维度。这一章的目的是把这几个维度讲清楚，因为后面所有报错几乎都能追溯到这几个属性上。

3.1 张量不是数组：形状、dtype、device 三个属性

把张量当成“多维数组”会在前两周很顺手，第三周开始出问题。张量除了数值，还带着三个属性：形状决定运算是否合法，dtype 决定精度和显存占用，device 决定计算发生在哪里。三者任意一个不匹配，运算就会失败。

python复制import torch

a = torch.randn(4, 3)            # float32, cpu
b = torch.randn(3, 5)            # float32, cpu
print((a @ b).shape)             # torch.Size([4, 5])

try:
    a @ torch.randn(4, 5)
except RuntimeError as e:
    print("shape error:", e)

try:
    a @ torch.randn(3, 5, dtype=torch.float64)
except RuntimeError as e:
    print("dtype error:", e)

第一次报错信息类似 mat1 and mat2 shapes cannot be multiplied (4x3 and 4x5)，直接指出了两个操作数的形状。第二次报错是 expected m1 and m2 to have the same dtype。这两个错误在真实项目里出现频率极高，认出它们就省下了大量时间。

device 不匹配的报错更隐蔽一些，通常是 Expected all tensors to be on the same device。解决办法不是到处 .cuda()，而是把设备选择收敛到一个变量：

python复制device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
model = model.to(device)
batch = {k: v.to(device) for k, v in batch.items()}

这样 CPU 和 GPU 环境都能跑，调试时在 CPU 上验证逻辑，训练时切到 GPU，代码不用改。这里还有个容易忽略的点：模型的 .to(device) 是原地修改并返回自身，但张量的 .to(device) 在设备不同时返回新对象，不修改原对象。所以 x.to(device) 单独写一行是没有效果的，必须写成 x = x.to(device)。

3.2 计算图、requires_grad 和 detach 的正确用法

自动求导的核心是：前向计算时记录一张计算图，反向传播时沿图回传梯度。requires_grad=True 的张量会被记录，requires_grad=False 的不会。模型参数默认是 True，输入数据默认是 False，这个默认值设计得很合理——我们不需要对输入求导。

python复制x = torch.tensor([2.0, 3.0], requires_grad=True)
y = (x ** 2).sum()
y.backward()
print(x.grad)   # tensor([4., 6.])

y.backward() 之后，梯度累加到 x.grad 上，而不是覆盖。这一点是新手最容易踩的坑：如果在一个循环里反复 backward() 而不清零，梯度会不断累加，表现为 loss 前期正常、后期突然爆炸。所以训练循环里必须写 optimizer.zero_grad()，而且位置要在 backward() 之前。

detach() 的作用是把张量从计算图上摘下来，返回一个共享内存但不再追踪梯度的新张量。典型用途是在评估阶段或者计算指标时避免显存泄漏：

python复制with torch.no_grad():
    logits = model(x)
    pred = logits.argmax(dim=1)
    acc = (pred == y).float().mean().item()

torch.no_grad() 比逐个 .detach() 更彻底，它让整个代码块内的运算都不构建计算图。评估阶段一定要用，否则验证集的显存占用会和训练集一样高，很容易在大模型上触发 OOM。

还有一个常被误用的写法是 loss.item()。.item() 把单元素张量转成 Python 浮点数，同时脱离计算图。日志里记录 loss 必须用 .item()，如果直接把这个张量存进列表，整个计算图会被一直持有，跑几百步就 OOM。

3.3 手写一次梯度下降，验证对反向传播的理解

用框架的高级 API 之前，手写一遍线性回归的梯度下降很有必要。它能让你确认自己真的理解“梯度指向上升最快的方向，所以更新时要减”。

python复制import torch

set_seed(42)

# 构造 y = 3x + 2 + 噪声
n = 200
x = torch.randn(n, 1)
true_w, true_b = 3.0, 2.0
y = true_w * x + true_b + 0.1 * torch.randn(n, 1)

w = torch.zeros(1, 1, requires_grad=True)
b = torch.zeros(1, requires_grad=True)
lr = 0.1

for step in range(200):
    pred = x @ w + b
    loss = ((pred - y) ** 2).mean()
    loss.backward()
    with torch.no_grad():
        w -= lr * w.grad
        b -= lr * b.grad
    w.grad.zero_()
    b.grad.zero_()
    if step % 50 == 0:
        print(f"step {step:3d} loss {loss.item():.4f} w {w.item():.3f} b {b.item():.3f}")

预期输出里 loss 会快速下降，w 逼近 3、b 逼近 2。注意更新那一步包在 torch.no_grad() 里，因为参数更新本身不应该被记录进计算图，否则每次迭代都会往图上加节点，显存一路涨。同时 w.grad.zero_() 用的是原地操作，不能用 w.grad = None 之外的方式随意替换，否则可能丢失引用。

如果把这个例子的 lr 改成 1.5，会看到 loss 迅速变成 inf 或 nan。这就是“学习率过大导致发散”的具体形态：参数一步跨过了最优点，损失反而变大，下一步梯度更大，形成正反馈。亲眼看一次这个现象，比看十遍公式更有效。

注意：手动更新参数时要 with torch.no_grad()，用 optimizer.step() 时不需要，因为优化器内部已经处理了。两种写法不要混着用，容易漏掉梯度清零或者重复更新。

4. 最小可运行案例：两层 MLP 跑通一个完整的训练闭环

前面都是零件，这一章把它们装成一台能转的机器。为了不依赖网络下载数据集，用一个合成的二分类任务，数据可控、跑得快、结果可预期，适合反复改参数观察变化。

整个闭环包含五步：造数据、建模型、定义损失和优化器、写训练和验证循环、保存结果。每一步都可以单独验证，出了问题也容易定位。

4.1 先造一份可控的合成数据

合成数据的好处是完全掌握分布，模型学不到东西时能立刻判断是代码问题还是数据问题。设计上让正负样本有线性可分部分，再加一点非线性扰动，这样单层线性模型能拿到不错的基线，MLP 能明显更好，两者对比就能看出非线性层的作用。

python复制import torch
from torch.utils.data import TensorDataset, DataLoader

def make_dataset(n=6000, dim=20, seed=0):
    g = torch.Generator().manual_seed(seed)
    x = torch.randn(n, dim, generator=g)
    w = torch.randn(dim, 1, generator=g)
    logits = (x @ w).squeeze(1) + 0.8 * torch.sin(3 * x[:, 0])
    y = (logits > 0).long()
    return x, y

x, y = make_dataset()
n_train = int(len(x) * 0.8)
train_ds = TensorDataset(x[:n_train], y[:n_train])
val_ds = TensorDataset(x[n_train:], y[n_train:])

train_loader = DataLoader(train_ds, batch_size=64, shuffle=True, drop_last=True)
val_loader = DataLoader(val_ds, batch_size=256, shuffle=False)
print("train batches:", len(train_loader), "val batches:", len(val_loader))

关键点在 drop_last=True。训练集最后一批可能只剩几个样本，如果模型里有 BatchNorm，batch size 为 1 时会直接报错 Expected more than 1 value per channel when training。加 drop_last=True 是最省事的处理方式，代价是丢掉少量样本，对训练影响可以忽略。

另外 shuffle=True 只给训练集加，验证集不需要打乱，打乱反而让结果不可比对。batch_size 训练用 64、验证用 256，是因为验证阶段不需要反传，显存占用小得多，用大 batch 能明显加快速度。

4.2 模型、损失函数、优化器三件套

模型定义虽然简单，但层的顺序有讲究。Linear -> BatchNorm -> ReLU -> Dropout 是常见组合，BatchNorm 放在激活前，Dropout 放在激活后。顺序错了不会报错，但效果会打折扣。

python复制import torch.nn as nn

class MLP(nn.Module):
    def __init__(self, in_dim, hidden=64, num_classes=2, dropout=0.1):
        super().__init__()
        self.net = nn.Sequential(
            nn.Linear(in_dim, hidden),
            nn.BatchNorm1d(hidden),
            nn.ReLU(inplace=True),
            nn.Dropout(dropout),
            nn.Linear(hidden, hidden),
            nn.BatchNorm1d(hidden),
            nn.ReLU(inplace=True),
            nn.Linear(hidden, num_classes),
        )

    def forward(self, x):
        return self.net(x)

注意最后一层不加激活也不加 BatchNorm，因为输出的是 logits，交给 CrossEntropyLoss 处理。如果这里手贱加了 Softmax，损失会算错但不会报错，表现为 loss 一直卡在 0.69 附近不动——这正是二分类随机猜测的损失值，是一个非常经典的错误信号。

损失函数用 CrossEntropyLoss，它内部已经包含 log_softmax，输入必须是未归一化的 logits，标签是 long 类型的类别索引。优化器先用 Adam 起步：

python复制device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
model = MLP(in_dim=20).to(device)

criterion = nn.CrossEntropyLoss()
optimizer = torch.optim.Adam(model.parameters(), lr=1e-3, weight_decay=1e-4)

weight_decay=1e-4 是 Adam 上比较常见的起点，相当于 L2 正则。lr=1e-3 是 Adam 的经典默认值，在这个规模的数据上通常几步内就能看到 loss 下降。

4.3 训练循环和验证循环要分开写

训练和验证的逻辑差别很大：训练要清零梯度、反向传播、更新参数，还要处理 dropout 和 BatchNorm 的训练模式；验证不需要反传，要用 eval() 切换模式，并且包在 no_grad() 里。把两者硬塞进一个函数，后面加功能会非常痛苦。

python复制def train_one_epoch(model, loader, criterion, optimizer, device):
    model.train()
    total_loss, total_correct, total = 0.0, 0, 0
    for xb, yb in loader:
        xb, yb = xb.to(device), yb.to(device)
        optimizer.zero_grad(set_to_none=True)
        logits = model(xb)
        loss = criterion(logits, yb)
        loss.backward()
        optimizer.step()

        total_loss += loss.item() * xb.size(0)
        total_correct += (logits.argmax(1) == yb).sum().item()
        total += xb.size(0)
    return total_loss / total, total_correct / total


@torch.no_grad()
def evaluate(model, loader, criterion, device):
    model.eval()
    total_loss, total_correct, total = 0.0, 0, 0
    for xb, yb in loader:
        xb, yb = xb.to(device), yb.to(device)
        logits = model(xb)
        loss = criterion(logits, yb)
        total_loss += loss.item() * xb.size(0)
        total_correct += (logits.argmax(1) == yb).sum().item()
        total += xb.size(0)
    return total_loss / total, total_correct / total

三个细节值得单独说。optimizer.zero_grad(set_to_none=True) 比默认的置零更省显存，因为它把梯度设为 None 而不是填一个全零张量，PyTorch 2.x 里这是推荐写法。loss.item() * xb.size(0) 是这个 batch 的总损失，累加后除以总样本数才是真正的平均损失，如果直接累加 loss.item() 再除以 batch 数量，最后一批不足一个 batch 时结果会偏。model.train() 和 model.eval() 必须显式调用，dropout 和 BatchNorm 的行为依赖这个开关，忘了切会得到一个莫名其妙偏低的验证指标。

主循环：

python复制best_acc = 0.0
for epoch in range(1, 21):
    tr_loss, tr_acc = train_one_epoch(model, train_loader, criterion, optimizer, device)
    va_loss, va_acc = evaluate(model, val_loader, criterion, device)
    flag = ""
    if va_acc > best_acc:
        best_acc = va_acc
        torch.save({"model": model.state_dict(), "epoch": epoch, "acc": va_acc}, "outputs/best.pt")
        flag = " *"
    print(f"epoch {epoch:02d} train_loss {tr_loss:.4f} train_acc {tr_acc:.4f} "
          f"val_loss {va_loss:.4f} val_acc {va_acc:.4f}{flag}")

预期输出大概是这样，前几轮指标快速上升，之后趋于平缓：

text复制epoch 01 train_loss 0.3821 train_acc 0.8234 val_loss 0.3105 val_acc 0.8652 *
epoch 02 train_loss 0.2714 train_acc 0.9145 val_loss 0.2501 val_acc 0.9134 *
epoch 03 train_loss 0.2117 train_acc 0.9402 val_loss 0.2130 val_acc 0.9367 *
...
epoch 20 train_loss 0.0821 train_acc 0.9821 val_loss 0.1145 val_acc 0.9681 *

如果在自己的环境里训练集准确率上到 0.98 而验证集卡在 0.88 不动，那就是过拟合，回头去调 weight_decay 和 dropout。这一步的价值在于：你有了一个能观察、能修改、能对比的基线，后面所有参数实验都围绕它做。

4.4 保存、加载与结果复现

保存 state_dict 而不是整个模型对象。整个 pickle 模型依赖代码里的类定义路径，换目录或者重命名类就加载失败，而 state_dict 只是一个参数字典，配合结构定义就能恢复。

python复制def load_checkpoint(path, in_dim=20, device="cpu"):
    ckpt = torch.load(path, map_location=device)
    model = MLP(in_dim=in_dim).to(device)
    model.load_state_dict(ckpt["model"])
    model.eval()
    print(f"loaded epoch {ckpt['epoch']}, val_acc {ckpt['acc']:.4f}")
    return model

map_location 必须显式指定。如果在 GPU 上保存、在 CPU 上加载，不指定会报 Attempting to deserialize object on a CUDA device。指定为 cpu 之后，即使没有显卡也能顺利恢复。

复现的完整条件包括：固定种子、固定数据生成逻辑、固定依赖版本、固定超参、固定代码。缺任何一条，两次结果都会有差异。实际对比实验时，更可靠的做法是每次运行把配置和结果写进一个 JSON 文件，后面用脚本汇总，而不是靠记忆：

python复制import json
record = {"seed": 42, "lr": 1e-3, "bs": 64, "hidden": 64, "best_val_acc": best_acc}
with open("outputs/exp_log.jsonl", "a", encoding="utf-8") as f:
    f.write(json.dumps(record, ensure_ascii=False) + "\n")

每行一条记录，追加写入，几十次实验之后可以直接读进来排序找最优配置。这个习惯成本很低，收益很高。

5. 参数详解：学习率、batch size、正则化到底改什么

调参这件事被神秘化了。实际上在中小规模任务上，能显著影响结果的参数就那么几个，其余多是微调。理解每个参数在优化过程中起的作用，比记住一组“最佳配置”有用得多，因为换一个数据集，最佳配置大概率就变了。

5.1 学习率和调度策略

学习率决定每一步沿梯度方向走多远。它的影响非常直观：太小则收敛慢，在有限轮次内看不到效果；太大则震荡甚至发散。判断方法很简单，固定其他条件，把学习率按数量级跑几组，看 loss 曲线：

调度策略是让学习率随训练进程变化。最常用的是余弦退火和阶梯衰减：

python复制scheduler = torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max=20, eta_min=1e-5)

for epoch in range(20):
    train_one_epoch(...)
    evaluate(...)
    scheduler.step()
    print("current lr:", optimizer.param_groups[0]["lr"])

T_max 要和总 epoch 数匹配，设成 20 表示在 20 轮内从初始学习率降到 eta_min。如果设成比实际训练轮次大很多，学习率几乎不降，等于没加调度。另外，PyTorch 2.x 之后 scheduler.step() 的位置有变化，在旧版本里需要在优化器更新之后按 batch 调用，新版推荐按 epoch 调用。版本不一致时表现出“学习率不按预期变化”，检查版本比改代码更快。

还有一个实用的做法是先用小规模数据做一次“学习率扫描”，从 1e-5 到 1e-1 每隔 3 倍取一个值，每个跑几十步，选 loss 下降最快的那个量级。这个方法比凭感觉猜靠谱得多。

5.2 batch size 与显存的取舍

batch size 影响三件事：梯度估计的噪声水平、显存占用、每轮的迭代次数。batch 越大，梯度估计越准，但泛化未必更好；batch 越小，噪声越大，有时反而有正则效果，但训练慢且 BatchNorm 的统计量不稳定。

经验关系是：batch size 翻倍时，学习率可以适当放大，但不要简单线性放大，先用 1.2 到 1.5 倍试试。这条规律在大 batch 训练里更明显，小规模任务上影响有限。

显存估算的粗略方法是：参数量 × 4 字节 × 若干倍（梯度、优化器状态、激活值）。Adam 会额外保存一阶和二阶动量，所以优化器状态大约是参数量的两倍。一个百万参数的模型，光参数和优化器状态就要十几 MB，真正吃显存的是中间激活值，所以 batch size 的影响远大于模型规模。

真正吃紧的时候可以上混合精度，把部分运算降到 float16，显存占用通常能降三到四成：

python复制scaler = torch.amp.GradScaler("cuda", enabled=torch.cuda.is_available())

for xb, yb in train_loader:
    xb, yb = xb.to(device), yb.to(device)
    optimizer.zero_grad(set_to_none=True)
    with torch.amp.autocast("cuda", enabled=torch.cuda.is_available()):
        logits = model(xb)
        loss = criterion(logits, yb)
    scaler.scale(loss).backward()
    scaler.step(optimizer)
    scaler.update()

GradScaler 的作用是对损失做放大，避免 float16 下梯度过小变成 0。这套写法在 CPU 上需要 enabled=False，否则会报错，所以上面用 torch.cuda.is_available() 做了开关。混合精度在小模型上收益不明显，主要针对显存吃紧的场景。

5.3 权重衰减、Dropout、BatchNorm 的配合

这三个都是正则化手段，但作用机制完全不同，混用时要理解各自的副作用。

权重衰减在损失里加参数的 L2 惩罚，抑制参数变得过大。Adam 上的 weight_decay 实现是 L2 正则，而 AdamW 用的是解耦的权重衰减，效果更接近理论预期。如果需要精细控制，优先用 AdamW：

python复制optimizer = torch.optim.AdamW(model.parameters(), lr=1e-3, weight_decay=0.01)

Dropout 在训练时随机把一部分神经元的输出置零，相当于每次训练一个子网络，推理时关闭。它的副作用是训练和推理行为不一致，如果忘了 model.eval()，推理结果会偏小且带有随机性。

BatchNorm 用 batch 内的统计量归一化，训练时用当前 batch 的均值和方差，推理时用滑动平均。它的副作用是对 batch size 敏感：batch 太小统计量不准，batch 为 1 直接报错。另外在序列长度差异大的任务上表现可能不好，需要考虑 LayerNorm。

三者叠加时的推荐顺序和量级：

实际项目里最常见的错误是三个一起上、每个都调很大，结果模型学不动，然后怀疑是数据问题。正确顺序是：先不加正则跑一版看能不能过拟合，能过拟合说明模型容量够，再逐步加正则压验证集差距。上来就加满正则，你连模型能不能拟合都判断不了。

注意：判断“模型容量是否足够”的方法是在小批量训练集上把 loss 打到接近 0。如果几十个样本都拟合不了，问题在模型结构或者代码，不在正则化，加正则只会更糟。

6. 训练不收敛、loss 变 NaN、显存爆掉怎么查

排错的关键是缩小范围。深度学习的链路很长，但每一环都有明确的检查点，按顺序查比凭感觉改参数快得多。下面这套排查顺序是按“最可能出错且最容易验证”排列的，实际遇到问题时从上往下走。

6.1 先看现象分类表

拿到一个异常，先把现象归类，比直接改代码有效。大部分问题都能落进下面几类：

这张表覆盖了绝大多数新手会遇到的问题。真正排查时，先对照现象找到最可能的一行，验证一下，不对再往下走。不要一上来就大改模型结构，那是最难验证的改动。

6.2 按数据、前向、损失、反向、更新的顺序排查

顺序很重要，因为前面的环节出错会污染后面所有的观察结果。

第一步查数据。取一个 batch，打印形状、dtype、取值范围、标签分布：

python复制xb, yb = next(iter(train_loader))
print("x shape", xb.shape, "dtype", xb.dtype, "device", xb.device)
print("y shape", yb.shape, "dtype", yb.dtype)
print("x min/max", xb.min().item(), xb.max().item())
print("label counts", torch.bincount(yb))

要确认的点：x 的形状和模型输入维度一致，y 是 long 类型，标签不是全 0 或全 1，数值范围没有异常（比如出现 nan 或者上万的值）。标签全 0 会导致模型直接学会永远输出 0，准确率看起来有 0.5 以上但完全没有意义。

第二步查前向。单独跑一次模型，看输出形状和数值范围：

python复制model.eval()
with torch.no_grad():
    logits = model(xb.to(device))
print("logits shape", logits.shape)
print("logits sample", logits[0].tolist())

输出形状应该是 [B, num_classes]。如果数值范围特别大，比如上万，说明初始化有问题或者输入没归一化，这时候损失会很大，梯度也容易爆。

第三步查损失。用随机标签算一次损失，理论值应该是 ln(num_classes)。二分类就是 0.693，十分类就是 2.303。如果算出来差很远，说明损失函数和数据格式不匹配。

第四步查梯度。在 backward() 之后、step() 之前打印梯度范数：

python复制total_norm = 0.0
for p in model.parameters():
    if p.grad is not None:
        total_norm += p.grad.data.norm(2).item() ** 2
total_norm = total_norm ** 0.5
print("grad norm:", total_norm)

正常情况下梯度范数应该在 1e-3 到 1e1 之间。如果是 0，说明梯度断了，检查有没有误用 detach() 或者把参数设成了 requires_grad=False。如果是几百上千，说明梯度爆炸，需要降低学习率或者加裁剪。

第五步查更新。在 step() 前后对比某个参数的实际值：

python复制before = model.net[0].weight[0, 0].item()
optimizer.step()
after = model.net[0].weight[0, 0].item()
print("param delta:", after - before)

如果 delta 恰好是 0，参数根本没更新。可能原因是优化器传入的参数列表为空（比如模型被重新赋值但优化器还指向旧对象），或者梯度全是 0。这类问题不会报错，只能靠主动检查发现。

6.3 日志、可视化与最小复现

日志的价值在于事后能回答“当时到底发生了什么”。最低要求是每轮记录训练损失、验证损失、学习率、耗时。想更进一步，记录梯度范数和参数范数：

python复制import math

def log_epoch(epoch, tr_loss, va_loss, lr, grad_norm, elapsed):
    print(f"[{epoch:03d}] tr={tr_loss:.4f} va={va_loss:.4f} "
          f"lr={lr:.2e} gnorm={grad_norm:.3f} time={elapsed:.1f}s")

# 梯度范数出现异常时可以预警
if not math.isfinite(grad_norm) or grad_norm > 100:
    print("warning: gradient anomaly")

梯度裁剪是应对爆炸最直接的手段，在 backward() 之后、step() 之前调用：

python复制torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=1.0)

max_norm 设成 1.0 是常见起点，它的作用是把梯度总范数限制在这个值以内，超过就等比缩小。这个操作对正常训练的模型几乎无影响，但对偶发的梯度尖峰有很好的抑制作用。

最小复现是排错的终极手段。当问题复杂到理不清时，把代码精简到能复现问题的最少行数：去掉数据增强、去掉正则、用一个固定 batch、只跑一步。很多问题在这个精简过程中就自己暴露了，因为你被迫看清楚了每一行在做什么。

还有一个容易被忽略的点是环境差异。同一份代码在本地能跑、在服务器上报错，八成是版本或设备差异。用下面的命令把两边的环境信息打出来对比：

bash复制python -c "import torch, sys; print(sys.version); print(torch.__version__, torch.version.cuda)"
nvidia-smi

对比 Python 版本、PyTorch 版本、CUDA 版本、驱动版本这四项，基本能定位到差异来源。

注意：不要在报错时第一反应是升级或降级包。先把完整报错信息和复现步骤记下来，确认改动和问题相关，否则很容易把环境搞乱，最后连原来的错误都复现不出来。

7. 把课程实验变成可复用的工程习惯

学习阶段的代码和工程代码之间，差的不只是封装，还有对“别人能不能接手”的考虑。课程实验的代码通常是一个脚本从头写到尾，路径写死、超参硬编码、没有日志。这种代码自己当天能跑，一周后回来看就要重新读一遍。把几个习惯固定下来，成本不高，收益持续。

7.1 实验前中后的检查清单

这份清单可以直接照着用，每次跑实验前过一遍，能避免大部分低级错误：

实验前：确认数据集版本和划分方式，确认输入维度与模型定义一致，确认设备选择逻辑正确，确认随机种子已固定，确认输出目录存在且可写，确认超参写在配置文件而不是代码里。

实验中：每轮记录训练和验证指标，定期打印学习率和梯度范数，保存最优模型而不是最后一个模型，日志写到文件而不是只打印到终端，异常时保留现场不要直接覆盖输出目录。

实验后：对比配置和结果的对应关系，记录本次实验的结论而不只是数字，把失败配置也记下来避免重复踩坑，把可复用的代码抽到 src 里，把一次性的实验脚本单独放在 experiments 目录。

配置外置化可以用一个 YAML 文件承载：

yaml复制seed: 42
device: cuda
data:
  n_samples: 6000
  dim: 20
model:
  hidden: 64
  dropout: 0.1
train:
  batch_size: 64
  epochs: 20
  lr: 0.001
  weight_decay: 0.0001
output:
  dir: outputs/exp_001

读进来就是一个字典，传给各个模块。这样改实验只需要复制一份 YAML 改几个值，代码文件一个字都不用动，对比实验也不会因为手改代码引入意外差异。

7.2 从实验代码到生产代码要补的东西

学习环境的代码跑通就算成功，生产环境还差得远。下面这些是必须补的：

一个具体要求：推理阶段必须显式调用 model.eval()，并且用 torch.no_grad() 或 torch.inference_mode() 包住。少了这两步，一是 dropout 还在生效导致结果不稳定，二是会构建不必要的计算图浪费显存。这一点在实验阶段经常被忽略，因为训练脚本里已经切过 eval()，部署时单独抽推理函数就容易漏。

另一个要求是输入预处理必须和训练时完全一致。归一化参数、类别映射、文本分词方式，任何一项不同都会让效果莫名其妙变差，而且不报错。稳妥做法是把预处理逻辑写成独立模块，训练和推理共用同一份代码，而不是各写一遍。

7.3 继续深入的两个方向

跑通这个最小闭环之后，往两个方向走收获最大。

第一个方向是往模型结构深入。把 MLP 换成卷积网络，观察参数量怎么随卷积核大小和通道数变化，感受“局部连接 + 权值共享”带来的效率差异；再换成带残差连接的结构，观察深层的梯度是否还健康。每换一次结构，就回到第 6 章的排查链路走一遍，形状和设备的坑会以新的形式出现，但在同一套框架下都能定位。

第二个方向是往训练流程深入。把单次训练扩展成带早停、带学习率调度、带多组配置对比的小型实验框架，用配置文件驱动，用 JSON 记录结果。这个投入大概一两天的量，但它把“调参靠感觉”变成“调参靠数据”，后面所有实验都受益。

课程里的理论推导解决的是“为什么这么设计”，而上面这两个方向解决的是“这么设计之后怎么落地”。两者缺一不可，但顺序上建议先把能跑的代码跑顺，带着具体问题再回看理论，理解会快很多。深度学习这门东西，很多时候是想不明白但跑得明白，跑通之后再回头看公式，才会真正有感觉。