我见过不少刚入门的同学，跑通一个模型时特别开心，但过了一周再跑同一个脚本，结果对不上了。或者在自己电脑上训练得好好的模型，换到同事的机器上一跑，指标掉了一截。这种问题跟模型结构无关，代码也没有致命 bug，纯粹是“可复现性”没做好。

“从 0 到 1 训练一个稳定、可复现的深度学习模型”，这件事的核心其实不在于怎么把准确率刷上去，而在于怎么让你的实验结果值得信任。同样的代码、同样的数据、同样的环境，跑出来就必须是同样的结果。这里的关键词是“稳定”和“可复现”。这篇文章我会按自己实际训练模型的经验，从环境准备、数据管理、随机性控制、训练稳定性设计，到实验记录与问题排查，完整走一遍。

如果你正准备认真训练自己的第一个模型，或者已经被“结果随机”折腾得头疼，这篇内容应该能帮你省下不少时间。

1. 整体设计：为什么“能跑”不等于“可复现”

很多入门项目跑通是跑通了，但实验结果是“薛定谔的指标”——每次跑都不一样。这背后其实是深度学习的天然随机性在作怪。你要面对的不只是模型初始化那一次随机，还有数据加载的顺序、数据增强的随机裁剪、随机翻转、GPU 底层并行算法的选择，这些环节都充满了随机数。

可复现性不是学术洁癖，是工程底线。试想一下，你辛辛苦苦调了一个晚上，把验证集准确率从 80% 提到了 82%，结果第二天重新训练，发现最好成绩只有 80.5%，那昨晚的调参到底是成功了还是没成功？你根本无法判断。反过来，如果模型训练结果稳定可复现，改一个超参数带来的变化就是真实的、可信的，调参效率会高很多。

从 0 到 1 建立一个训练流程，我建议把可复现性拆成三个层次来理解。

1.1 三个可复现层次

第一层是完全确定性复现：固定随机种子、固定环境、固定硬件，跑出来的结果一模一样。这是入门阶段最应该先做到的事，也是这篇文章重点讲的部分。

第二层是跨环境复现：同样的代码，换一台机器，甚至换一个 GPU，结果在可接受的误差范围内（比如验证集准确率波动在 0.1% 以内）。这需要你把环境依赖锁得很死，同时对精度设置有清晰的预期。

第三层是统计意义复现：不管随机种子怎么换，多次实验的结果分布是稳定的，均值能体现模型的真实水平。这是做学术实验或者正式对比实验时必须具备的，也是调参时判断“哪个超参数更好”的真正依据。

刚入门的时候，先把第一层做到位，后面的层次才有的谈。

1.2 设计训练流程时的核心原则

我在搭建训练流程时，会遵循几条硬性原则。

第一条，所有可能影响结果的输入都要被记录。数据版本、代码版本、环境版本、超参数，一个都不能漏。

第二条，随机性要集中管理。不要到处散落随机数调用，能固定种子就在入口统一固定，数据集的 shuffle、数据增强、模型初始化这些随机源，都要能通过一个开关一键固定。

第三条，训练过程要可观测。每个 epoch 的损失、指标、学习率都要有记录，出了问题能回溯到具体是哪一步开始撕裂的。

这三条原则听起来朴素，但真正执行起来，能帮你避开很多后续的坑。尤其是第一条，很多同学训练完模型，过两周问自己“这个结果是用哪个版本的数据跑的”，完全答不上来。

2. 环境准备与数据管理：复现的底座

可复现的大楼建在地基上，地基就是你的环境和数据。环境版本对不上，再好的代码也白搭。

2.1 环境锁定：从 Python 版本到 CUDA 驱动

我自己踩过一个很经典的坑。有一次在机器 A 上用 Python 3.8 训练一个模型，当时完全正常。后来换到机器 B，装了 Python 3.11，并没用任何新特性，只是顺手装了个新环境，结果损失曲线形状都不一样了。排查到最后才发现是 Python 小版本差异导致某个第三方库行为变了，进而影响了数据加载。

所以环境锁定的第一件事，就是创建独立的虚拟环境，并且把依赖版本全部固定。

conda create -n myproject python=3.10 conda activate myproject pip install torch==2.1.0 torchvision==0.16.0 pip install numpy==1.26.2 pandas==2.1.4

安装完后，一定要导出依赖清单，方便以后重建。

pip freeze > requirements.txt

这只是最基础的一层。深度学习项目还有一个更隐蔽的变量：GPU 驱动、CUDA 版本、cuDNN 版本。这三个东西不在 pip 的管理范围里，但直接影响 GPU 上卷积等操作的计算方式。比如 cuDNN 版本不同，同一个卷积可能选择不同的底层算法，数值结果就会有细微差别。

我的建议是，如果你在学校或公司做项目，统一用 Docker 镜像来跑训练。Docker 可以把操作系统、CUDA、cuDNN、Python 环境一次性打包，换机器只需要把镜像拉起来就能跑，可复现性会好很多。如果暂时不用 Docker，至少要把下面这些信息记录在项目说明里：

• 操作系统版本
• GPU 驱动版本（nvidia-smi 第一行就是）
• CUDA 版本（Docker 镜像内通常是固定的）
• cuDNN 版本（可以通过 torch.backends.cudnn.version() 查询）
• Python 版本
• 核心库版本（torch、torchvision、numpy 等）

2.2 数据版本管理：别让数据悄悄变掉

很多入门项目的数据集就是下载一次，然后一直在本地用。看起来没问题，但实际上一旦你手动删了一些坏图、重新整理过文件夹结构，数据的分布就变了，模型的结果也就跟着变了。

我处理数据的时候，习惯在项目里建一个 data 目录，并且给整个数据集算一个哈希值，记录下来。这样不管过了多久，我都能确认当前用的数据是不是当初那份。

find data/train -type f -print0 | sort -z | xargs -0 sha256sum | sha256sum

这条命令能对 data/train 下所有文件的内容生成一个整体校验值，数据有任何变动，校验值就会不一样。

数据集本身的版本也要区分。比如你清洗过图片、做过人脸对齐、或者对文本做了新的预处理，这些都应该有版本号或者日期标记，不要直接覆盖原目录。

除了数据集本身，数据加载顺序同样重要。深度学习中，我们通常每个 epoch 都要 shuffle 数据，shuffle 用的随机数如果不受控，训练结果就会抖动。解决方式是固定数据加载器的随机种子。

def worker_init_fn(worker_id): np.random.seed(42 + worker_id) random.seed(42 + worker_id) train_loader = DataLoader( dataset, batch_size=64, shuffle=True, num_workers=4, worker_init_fn=worker_init_fn, )

注意，shuffle=True 配合固定 PyTorch 的全局随机种子之后，训练数据在 epoch 之间的顺序是可复现的。但 DataLoader 的子进程有自己独立的随机数空间，所以需要 worker_init_fn 把每个 worker 的随机源也固定住。加了这个函数之后，数据增强（如果写在 Dataset 里）产生的随机性也能对齐。

有一个我实际操作中遇到的细节：不同机器上 num_workers 设置不一样，可能导致 DataLoader 的子进程分配方式不同，即便用了 worker_init_fn，某些复杂流水线也可能出现差异。最稳妥的做法是，涉及最终结果对比的实验，所有机器的 num_workers 尽量保持一致。

3. 代码层面的随机性控制：种子要“连锅端”

环境搞定了，数据管理也做了，接下来进入代码层面的控制。这里最大的误区是：随机种子只设一个就完事了。实际情况比这复杂得多。

3.1 随机种子全家桶

如果你想做到完全确定性复现，至少下面这几个随机源都要设上：

import random import numpy as np import torch def set_seed(seed): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed(seed) torch.cuda.manual_seed_all(seed) # 下面的设置很关键，后面细说 torch.backends.cudnn.deterministic = True torch.backends.cudnn.benchmark = False

random.seed 管的是 Python 标准库的随机数，np.random.seed 管的是 NumPy 的随机数，torch.manual_seed 管的是 CPU 上的 PyTorch 随机数，而 torch.cuda.manual_seed_all 管的是所有 GPU 上的 PyTorch 随机数。一个都不能少。

有些库还会用自己的随机数生成器，比如某些数据增强库、某些模型初始化方法。如果遇到这种情况，通常可以在库的文档里找到固定随机源的方法，或者通过传递 seed 参数来控制。

3.2 cuDNN 的确定性设置

torch.backends.cudnn.deterministic 和 torch.backends.cudnn.benchmark 这两个设置是新手最容易忽视的。

cuDNN 在运行卷积的时候，会自动尝试多种算法，选一个在“当前设备”上最快的。这个算法搜索过程是非确定性的，哪怕你在语义完全相同的两个 GPU 上训练，它可能给你挑出不同的实现，导致数值结果有微小差异。

当设置 torch.backends.cudnn.deterministic = True 时，PyTorch 会限制 cuDNN 使用确定性的算法；而 torch.backends.cudnn.benchmark = False 则是关掉那个“自动挑最快算法”的搜索机制。二者配合起来，就能保证卷积运算的确定性。

代价是训练速度会慢一点。官方文档里说 deterministic 模式下的卷积算法可能比 benchmark 模式慢一些，但通常不会慢到不可接受。我个人在实际项目里，训练阶段为了稳定结果，一直开着 deterministic；推理部署阶段再关掉 benchmark，让速度跑满。如果你准备做大规模训练，可以先用 benchmark 模式快速看趋势，最终跑正式结果时再切回确定性模式。

3.3 混合精度与 TF32 的潜在影响

混合精度训练（AMP）是现在的主流做法，但 AMP 本身有两个随机性来源。第一个是 loss scaling 的动态调整过程，第二个是某些 GPU 上卷积默认使用 TF32 精度。

TF32 是某些 GPU 提供的一种计算模式，它用较少的位宽来加速卷积和矩阵乘法，结果就是数值精度比 FP32 稍微低一点。PyTorch 在某些环境里默认开启 TF32，这会导致同样的代码在不同配置下结果不一样。

如果你追求精确可复现，可以显式控制：

torch.backends.cuda.matmul.allow_tf32 = False torch.backends.cudnn.allow_tf32 = False

关闭 TF32 之后，精度会更高，但速度也可能变慢。如果你只是想保持稳定复现，我建议至少先把 cudnn.allow_tf32 关掉，再观察卷积运算是否还有波动。混合精度本身还能不能做到完全确定性？在官方支持的环境里，配合上述种子设置是可以做到的，但确实更依赖具体的版本和硬件。你在做正式对比实验时，如果发现结果还是抖，可以先关掉 AMP 试试，排除混合精度带来的变量。

4. 训练过程的稳定性设计：让损失曲线“平躺”

环境、数据、代码层面的随机性都控制住了，接下来要解决的是“稳定性”这个词的核心——让训练过程本身不剧烈震荡。

4.1 超参数先求稳定，再求指标

我见过太多同学上来就抄论文里的超参数，结果在自己数据上直接发散。超参数对稳定性的影响是有优先级的：学习率是最敏感的一个，其次是 batch size，然后是优化器。

学习率过大，损失会震荡甚至爆掉；学习率过小，收敛又太慢。一个稳妥的做法是先用一组“保守”的超参数把流程跑通，比如用小学习率 1e-4 配 Adam，观察损失曲线能够稳定下降，再逐步调大。

如果你用 SGD + Momentum，稳定性问题会更明显。SGD 对学习率和初始化非常敏感，新手很容易调崩。Adam 系列优化器自带自适应机制，对学习率的敏感度低很多，入门阶段做实验非常合适。我的经验是：跑正式结果用 AdamW，配上权重衰减 0.01 或 0.05，先保证训练过程稳定收敛，再考虑性能优化。

4.2 学习率预热与余弦衰减

稳定训练还有一个很实用的技巧：学习率预热。训练刚开始时，模型参数离最优点很远，导数方向可能是错的，这时候如果直接上大学习率，很容易走偏。预热阶段让学习率从 0 或很小的值，线性增长到设定值，相当于让模型先“热身”。

预热之后，常见的做法是余弦退火，让学习率可以平滑衰减到接近 0。下面是一个简单的实现：

def get_lr(epoch, total_epochs, base_lr, warmup_epochs=5): if epoch < warmup_epochs: return base_lr * (epoch + 1) / warmup_epochs progress = (epoch - warmup_epochs) / (total_epochs - warmup_epochs) return base_lr * 0.5 * (1 + math.cos(math.pi * progress))

这种方式可以避免训练后期因为学习率太大而绕过损失函数的局部低点，导致验证指标忽高忽低。实际使用中，我建议训练至少 50 到 100 个 epoch，热身 5 个 epoch，余弦衰减到 0，整体损失曲线会非常平滑。

4.3 梯度裁剪

对 NLP 模型和部分图像模型，训练过程中可能会出现梯度爆炸。梯度爆炸的直接表现就是损失突然跳到一个非常大的值，然后再也不回来。梯度裁剪可以限制梯度的最大范数，防止这种突然失稳。

clip_grad_norm_(model.parameters(), max_norm=5.0)

放在 loss.backward() 之后、optimizer.step() 之前。max_norm 从 1.0 到 10.0 都可能适合，具体要看任务，但 5.0 是个不错的起点。我自己做 Transformer 类任务时都会加上这个，几乎成了固定动作。

有一种情况很坑：梯度裁剪加上了，但损失还是偶发跳高或跳低。这时候要回头检查数据有没有异常样本，比如某个 label 手抖标错了。异常样本会带来异常大的梯度，单靠裁剪不一定能完全压住，还是要清洗数据。

4.4 模型初始化与归一化

模型初始化方式对稳定性影响很大。大多数人直接使用 PyTorch 的默认初始化，这通常够用。但如果你想完全可复现，初始化也需要固定种子。理论上，设置了全局种子再初始化模型，初始化就是确定的；但如果代码里任何地方多调用了一次随机数，模型初始化就会偏移。

BatchNorm 层有一个值得注意的特性：训练模式下它统计的是当前 batch 的均值方差，推理模式下用的是训练时累积的全局统计量。如果 batch size 很小，BatchNorm 的统计量噪声会比较大，训练和推理指标差异也会更大。入门阶段的经验是，batch size 别小于 16，实在资源有限，可以考虑 GroupNorm 之类的替代方案。

4.5 如何判断训练是否“稳”

判断稳定性不能只看最终那一个数字。我训练时一定会画两条曲线：训练损失曲线和验证指标曲线。如果验证指标是准确率，我会同时关注每个 epoch 的值和整个训练过程最好值的波动范围。

一个真正稳定的训练过程，验证指标曲线整体应该单调上升，后期在小范围内波动。如果出现“大幅上蹿下跳”，说明要么学习率太高，要么 batch size 太小，要么数据里有噪声。不要拿“某个 epoch 最好”就当作最终结果，要多看最后几十个 epoch 的稳定水平。

我的一个习惯是：做一个实验时，同一组配置至少跑 3 次不同随机种子（在可复现模式下），如果三次结果的验证集最好值相差不超过 0.5%，我才认为这个配置是可信的。这既是稳定性检查，也是下一步调参的依据。

5. 实验记录与配置管理：把“盲人摸象”变成有据可查

训练稳定了、可复现了，还差最后一公里：把每次实验的来龙去脉全部记录下来。否则你过两周回来看自己的结果，根本不知道哪些超参数造成了好效果。

5.1 用配置文件管理超参数

初学者最容易犯的错，是超参数散落在训练脚本里到处写死。改一次 batch size，就得在代码里搜一遍。正确做法是抽出一个配置文件，训练脚本从配置文件读取。

# config.yaml model: name: resnet50 pretrained: false training: batch_size: 64 learning_rate: 0.001 optimizer: adamw weight_decay: 0.01 epochs: 100 warmup_epochs: 5 lr_schedule: cosine grad_clip_norm: 5.0 data: dataset_path: ./data/train image_size: 224 augmentation: true shuffle_seed: 42

每次实验启动前，把配置文件和代码版本记录下来。代码版本最好记一个 git commit hash，而不是笼统地说“今天这版代码”。因为 git commit hash 是唯一的，能够精确追溯到代码的某一个状态。

echo "git: $(git rev-parse HEAD)" > experiment_log.txt cat config.yaml >> experiment_log.txt

5.2 实验记录与指标追踪

我习惯单独建一个 experiments 目录，每一次实验放一个子目录，里面包含：

• config.yaml（本次实验的配置）
• 环境信息（pip freeze、GPU 信息、Python 版本）
• 指标记录（每个 epoch 的 train loss、val loss、精确率等，保存为 CSV）
• 最优模型权重

为什么要存 CSV？因为 CSV 是通用的、可读的、永远打不开的格式最少的。TensorBoard 或者专业实验管理工具当然更好，但 CSV 能让你在不依赖任何库的情况下快速画图分析。

记录指标时，我还会把“验证集指标最好的那个 epoch”单独记下来。这是因为有些模型后期会过拟合，最好的验证结果出现在中间某个 epoch，而最后保存的模型不一定是验证集上最好的模型。

几个重要的细节：

• 模型保存时，不要只保存 state_dict，最好把完整训练状态（optimizer 状态、epoch 数、随机数状态）也存下来。这样你能从一个 checkpoint 精确恢复训练，而不是只能从头开始。
• 记录中要有 ran 的硬件 ID，比如 GPU 的 PCI ID 或者主机名。这能帮你快速判断两台机器的硬件差异。
• 如果你有精力，用实验管理工具选一个好用的，可以自动记录配置和指标，对后续大量对比实验帮助很大。

6. 常见问题与排查技巧实战

到这里，训练流程的框架已经完整了。但实际训练中你大概率还会遇到下面这些问题。我把踩过的坑整理成一份速查清单，你遇到类似情况可以直接对照。

6.1 “我在两台机器上结果不一样”

先别急着怀疑玄学。排查顺序如下：

先检查环境差异，确认 Python、PyTorch、CUDA、cuDNN 版本是否一致。如果用的是不同型号的 GPU，比如一张 A 卡和一张 B 卡，算法实现可能不同，结果会有细微差异。这种情况不一定能做到完全一致，但通常误差应该在可接受范围内。

再检查数据加载顺序。数据文件在文件系统里的排列顺序不同，可能导致 DataLoader 返回的第一个 batch 不同。确认数据集校验值一致后，再检查 shuffle_seed 是否一致。

最后检查是否开了确定性模式。没开的话，两台机器之间的随机差异会被进一步放大。

6.2 “同一台机器，同一份代码，跑两次结果怎么不一样？”

这种情况 90% 是随机种子没固定全。按顺序核对：

• 是否调用了 set_seed
• 是否在 DataLoader 创建之前就设置好种子
• 是否设置了 worker_init_fn
• 是否有其他库（比如某些数据增强库）在内部使用了随机数但没有被种子控制
• 是否设置了 deterministic 模式

如果都设了还是不一样，十有八九是某个第三方库在导入时或运行中偷用了随机数。这类问题排查起来最头疼，我通常用二分法：从数据处理、模型创建、前向传播、反向传播逐段隔离，看哪一段开始产生不同的结果。

有一个我实际遇到的场景：某次实验结果偶尔小幅抖动，查了很久都没找到原因，最后发现是我们内部用的一个图像预处理库在 C++ 层面用了全局随机数，不受 Python 种子控制。解决办法是把预处理改成确定性函数，或者直接给那个库传种子。

6.3 “损失不降，或者降至某个平台期就是下不去”

先看是不是学习率太大导致的震荡。把学习率降到原来的十分之一再试，如果曲线变得平滑，说明之前确实太大了。

再看梯度分布。计算一下每层梯度的范数，如果某一层的梯度总是特别大或者特别小，就检查是否需要有梯度裁剪、初始化是否正确。

然后看数据。检查训练集里有没有 NaN 像素、错误标签、未归一化的特征。如果数据出现问题，模型再怎么调都稳不了。

最后检查 BatchNorm 的行为。如果训练和验证指标差异巨大，很可能是训练/推理模式切换没做好，比如忘了调用 model.eval()。

6.4 常见问题速查表

这张表是我自己经常翻阅的，每次排查问题都能快速定位方向。

6.5 一个排查技巧

如果你的模型怎么都不稳定，试一下从“最笨”的配置开始：关闭所有数据增强、使用固定顺序不 shuffle、固定种子、关闭混合精度、关闭 TF32。如果这个最保守的配置能稳定复现，那么每次往里面加一个特性（先加 shuffle，再加增强，再加 AMP），你就知道是哪个环节引入了不稳定因素。这种排除法比瞎猜高效得多。

我在给团队里新人做指导时，也一直强调这个思路：遇到不可复现的问题，不是去找更复杂的解释，而是先把所有“高级特性”全关掉，从最简单的确定性流程开始一步步还原。

写在最后的实操体会

训练一个稳定可复现的模型，本质上不是掌握某个超参魔法，而是养成一套严谨的流程习惯。环境固定、数据固定、随机源固定、配置可追溯，这四件事做好了，你在深度学习这条路上会走得远比同龄人稳。

我自己的体会是，前期多花 15% 的时间在可复现性建设上，后期省的可能是几倍的返工时间。不要觉得记录环境、固定种子这些事“很基础很无聊”，它们恰恰是模型结果能否让人信服的分水岭。

最后分享一个小技巧：每次启动训练前，把命令和配置写进一个脚本，让训练过程一键启动。这个脚本执行之后，把所有信息打印出来，同时保存到日志文件里。这样哪怕你一周后翻看，也能清楚地知道自己当时做了什么。等你跑完一次完整实验，你会发现这份“仪式感”其实是非常强大的生产力工具。