AI可复现性挑战：固定随机种子、锁定环境，让训练结果稳定复现

1. 从一次“幽灵复现失败”说起：到底什么是AI的可复现性挑战

前阵子我把一台GPU服务器上的旧训练任务重新跑了一遍，用的确实是当时的代码、当时的数据文件、当时的依赖环境，结果AUC从0.713变成了0.704。当时我的第一反应不是“代码写错了”，而是心里咯噔一下：这个问题我已经不是第一次遇见了。行业里面对这类现象有一个专门的说法，就是AI的可复现性挑战。

所谓可复现性挑战，说白了就是：同一个AI模型实验，从数据准备、模型训练、调参到最终评估，很难在脱离原始环境之后被精确重演。你可能只是在另一台机器上重跑，或者把依赖升了个版本，甚至仅仅换了一张不同型号的GPU，最后拿到的Loss曲线和评估指标就变了。这听起来不像“Bug”那么刺眼，但它比Bug更棘手，因为它并不总是导致程序崩溃，而是让结果变得“似是而非”。

这篇文章我想把这五个字拆开，讲清楚可复现性到底卡在哪个环节，哪些随机源最容易坑人，以及我这些年在一线训练和团队协作里，是怎么一步步把“跑一次”变成“跑多少次都一样”的。无论你是刚接触深度学习的算法新人，还是要给团队定实验规范的负责人，下面这些内容都很实用。

1.1 我碰到的那次“指标蒸发”事件

那次出问题的任务本身不复杂，是一个点击率预估方向的模型。第一次训练跑了将近三十个小时，最后验证集AUC是0.713，我当时把权重、日志和代码都存了下来。两个星期以后，我用同一份训练数据、同一个commit的代码，在另一台机器上重新训练，出来的AUC却变成了0.704。

这个变化听起来只有零点零几，可放在线上A/B实验里，足以让一个本来“预期正向”的策略变得不可判断。我花了大半天时间排查，先把概率比较大的嫌疑排除了一遍：没有改数据、没有改预处理、没有改模型结构。后来我把两个实验的日志放到一起逐行对比，才发现两个运行在第三个epoch之后Loss曲线就出现了肉眼可见的分离，而且分离方向完全随机，不是谁高谁低，而是两边开始各走各的。

类似的经历，我相信很多跑过深度学习的同行都遇到过。问题不在于某个人的代码写得不好，而是整个训练链路里天然存在很多“随机变量”，它们平时不动声色，一旦环境变了就会一起发作。可复现性挑战真正难的地方就在这里：一堆微小的差异叠加起来，最后变成你完全认不出的结果。

1.2 “跑通了”其实有三个层次：运行、复现、追溯

在团队里，我经常听到有人说“这个模型我跑通了”。“跑通”这个词的歧义太大了。我习惯把实验结果分成三个层次：

很多项目和论文停在第一层，也就是“能运行”。模型训练完，指标记录在Excel里，代码可能还在某个人的本地分支上，依赖没锁。等到换人、换机、换季度，再想还原当初那个结果，基本只能靠运气。第二层“可复现”是绝大多数工业团队应该追求的下限：把随机种子固定好、依赖锁好、数据版本固定，至少自己隔三个月还能跑出接近的结果。第三层“可追溯”更难，它要求每一个实验都有完整的上下文，包括代码版本、数据版本、环境摘要、随机种子、甚至还包含CPU/GPU型号。只有到了这一层，你才敢在跨团队协作、审计、线上回滚的时候说一句“这事经得起问”。

我个人的判断是：AI的可复现性挑战，真正挑战的不是“重跑一次”，而是“重跑十次都说得清楚”。前者是工程纪律，后者是系统设计。

2. 三座随机性暗礁：种子、数据次序与GPU算子

要跟可复现性打交道，首先得知道“鬼”藏在哪。我排查过很多次复现失败，最后发现大部分问题都能归到三个随机源上。这三样东西几乎出现在每一次训练里，却极少被人认真对待。

2.1 随机数：固定种子不是“做做样子”

深度学习里的随机数几乎无处不在。模型参数初始化用的是随机数，Dropout要随机丢弃神经元，数据加载要随机打乱顺序，很多优化器也有内部的随机状态。你可以粗暴地理解成：整个训练过程就是一场大型随机实验，如果不把随机源锁住，每次实验都是不同宇宙里的平行事件。

最常见的做法是设一个固定种子，比如这样：

import random import numpy as np import torch seed = 20240512 random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed)

这几行代码要在任何数据读取、模型构建之前执行，因为随机状态一旦被消费，后面再怎么设种子都晚了。我见过不少人把种子设置在导入PyTorch之后、却在数据增强模块里用到了NumPy的随机数，于是模型本身的种子固定了，但数据增强还在随机抖动，最后照样复现不了。

这里还有一个很多人忽略的点：固定了Python、NumPy和PyTorch的种子，不等于把全世界的随机源都锁住了。有些扩展库会维护自己的随机状态，多进程数据加载里每个worker的随机状态也需要单独处理。所以固定随机种子是必要不充分条件，它能把大头稳住，但小头不解决，结果还是会有细微波动。

2.2 数据加载次序：多线程Shuffle里藏着状态问题

第二个随机源是数据加载顺序。同一个训练集，你按顺序喂给模型和打乱后喂给模型，训练出来的模型是完全不同的。这一点很好理解，可真正容易踩坑的是：你以为你设置了全局随机种子，数据顺序就一定固定，然而DataLoader里的多进程一开，事情就变了。

PyTorch的DataLoader在num_workers > 0时，每个worker进程的随机状态和主进程并不完全同步。如果你只设了全局种子，然后直接shuffle=True，那么每次启动训练时数据打乱的顺序仍然可能不同。更稳妥的做法是给DataLoader单独传一个Generator：

g = torch.Generator() g.manual_seed(seed) train_loader = DataLoader( dataset, shuffle=True, generator=g, num_workers=4, )

这个Generator本质上就是数据加载器的专属随机源，跟主进程的随机状态分开管理。这样你设置种子之后，打乱顺序的随机行为至少在同一个PyTorch版本里是确定的。如果你是做分布式训练，还要注意每个rank拿到的数据分片是否一致，因为分布式Sampler通常会重新划分数据，划分逻辑和shuffle的种子同样需要被固定和记录。

2.3 GPU算子里藏着的“非确定性缝隙”

这一条可能是最容易被忽略的。很多人把代码环境都固定好了，随机种子也都设了，结果跑两次还是差一点点，这时候八成是GPU算子的非确定性在作祟。

GPU上很多计算是并行的，比如矩阵乘法和卷积，底层会把一个大计算拆成很多小块并行执行。小块之间的计算顺序偶尔会不一样，浮点数加法的顺序一变，结果在最后几位上就有差异。这种差异本身极小，但会随着训练步数累积，最后在指标上表现出零点几甚至一个百分点的差距。

我一般会在训练代码里补上这两个设置：

torch.backends.cudnn.benchmark = False torch.backends.cudnn.deterministic = True

这里面的逻辑是：benchmark默认会为了性能去自动挑选卷积算法，挑的过程本身就是非确定的；关掉它，再强制使用确定性算法，能减少不少波动。但你也别指望这两个开关一开就万事大吉，不同型号的GPU、不同驱动版本的底层实现仍然可能存在差异，尤其是有Tensor Core参与的低精度计算，跨硬件完全复现的难度更高。可以说，GPU层面的非确定性是“可以被抑制，但很难被根除”的。

3. 环境漂移：版本号背后的版本，才是复现失败的第二主谋

随机性只解释“同一环境跑两次为什么不一样”。可复现性挑战还有另一半：换个环境跑，为什么结果差那么多？这一半的答案通常写在环境依赖里。

3.1 版本号不能担保行为一致

很多人认为，把requirements.txt里的版本号写清楚了，环境就锁定了。这个认知在简单场景下成立，在真实项目里却很危险。依赖不是孤立的，你的Python包会依赖别的包，那些包又依赖更底层的库。版本号只能说明“装了哪个版本”，不能说明“这个版本在当前环境里表现如何”。

举个很常见的例子：NumPy版本变了，某些随机数生成算法在不同版本里的实现可能不同；你用旧版本生成了一组数据增强的随机序列，队友用新版本跑，数据分布就微妙地变了。PyTorch或CUDA版本更新之后，某些算子的默认实现也可能调整，同样代码跑出来的数值就有偏差。版本号只能说明“装了哪个版本”，不能说明“这个版本在当前环境里表现如何”。

更麻烦的是，同一份代码可能在不同的Python版本、不同的操作系统、不同的GPU驱动下表现各异。一个在Python 3.8下跑得好好的训练脚本，到了Python 3.11环境里没准连随机数序列都变了。所以可复现性的环境问题，本质上不是“版本对不对”，而是“环境是否被完整定格”。

3.2 用依赖锁定和容器把环境变成“可搬运的现场”

我处理环境问题一般分两步走。

第一步，锁定直接依赖和间接依赖。pip freeze能把当前环境里所有安装的包和版本导出来，我通常保存成分requirements.lock.txt，而不是手写一个宽松的requirements.txt。关键区别在于：手写的版本列表往往只写了顶层依赖，比如torch==2.3.0，可torch依赖的几十个底层包版本没有被固定。pip freeze会把整棵依赖树都记录下来，别人拿到手才能重建一个差不多的环境。

第二步，用容器把整个环境连同基础镜像一起打包。我常用的做法是用Dockerfile固定训练环境，而且不是只固定镜像Tag，还会尽量固定镜像的摘要值：

# 一个可复现训练镜像的简化示例 FROM train-base:py310-cu121@sha256:2a459e5f8c4e1a... WORKDIR /workspace COPY requirements.lock.txt . RUN pip install --no-cache-dir -r requirements.lock.txt COPY code/ ./code/ CMD ["python", "-m", "train"]

这样做的好处是，别人拿到的不是一个模糊的“基于某个镜像”的承诺，而是一串可以校验的哈希值。镜像本身一旦被构建出来，只要Digest不变，里面所有二进制、系统库、Python包就都一致。环境从“玄学”变成了“可以搬走的现场”。

3.3 我推荐的低成本环境快照三件套

说句实话，并不是所有团队都有精力维护一套复杂的镜像发布流水线。如果你从小团队起步，我推荐先做这三件低成本的事情：

• 每次训练跑起来之前，导出一份requirements.lock.txt，跟代码一起提交；
• 写一个简单的Dockerfile，至少保证“给我这台机器，我能重建环境”；
• 把GPU驱动版本、CUDA版本、机器型号一行字写进实验记录里。

这三件事花不了半小时，却能解决大部分环境漂移问题。我在自己的项目里早期就是靠这三招，才把“换了机器没法复现”的频率从每周两三次降到了几乎为零。

4. 把实验追溯变成工程习惯：从单个Notebook到多人团队

如果说固定种子和锁定环境是“防意外”，那实验追溯就是“查真相”。一个可复现的AI项目，必须有足够的上下文信息，让任何人在任何时候都能回答三个问题：这个结果是什么时候产生的？用什么代码和数据产生的？当时的运行环境是什么？

4.1 每一次训练都要有“身世档案”

我之前也走过弯路，喜欢在训练脚本里随手改参数，每次跑完就在终端里瞄一眼指标，然后转头去写下一个版本。这种做法在当时很爽，可一旦要回头对比，就完全抓瞎。后来我养成一个习惯：每次训练启动前，生成一个实验卡片文件，连同训练日志一起保存。

这个卡片不需要很复杂，有下面这些字段就够了：

{ "project": "ctr_model_0426", "git_commit": "f7b2c3e9a1d4", "dataset_version": "recsys_v3@20240512", "seed": 20240512, "data_sha256": "a3f2d93b1c...", "environment": "train-base:py310-cu121@sha256:2a459e5f8c4e1a...", "cuda_version": "12.1", "gpu_type": "A100-40G" }

我自己会把这段JSON放在训练日志的第一行，这样即使模型文件散落各地，只要还有人留着日志，就能找到训练时的完整上下文。工程上更规范的做法是接入开源实验管理框架，把指标、参数、代码commit、环境信息自动记录成一条实验记录。两者不冲突：手动写卡片是最低保障，自动记录是锦上添花。

4.2 数据版本和模型注册：缺了哪一块都会被坑

很多人做实验追溯时只盯着代码和环境，却把数据版本这一环漏了。数据集文件在磁盘上的路径可能没变，但内容早被人悄悄换过一版。我现在要求团队里所有数据变更都要带版本标识，训练前先计算数据文件的SHA256，跟实验卡片里的值比对，不一致就直接中断训练。这听起来有点“矫枉过正”，但数据文件被覆盖导致实验结果莫名变化的事，我见得太多了。

模型层面也一样。一个项目跑上几个月，磁盘里会有几十个checkpoint，如果只靠文件名区分，你根本分不清哪个对应哪个实验、哪个是最终采用版本。我建议给模型注册增加最少四项元数据：模型版本号、训练代码commit、训练数据版本、关键评估指标。这样当你需要回溯“线上那个模型是怎么训出来的”时，就不用在硬盘里大海捞针了。

4.3 一次团队协作复现排查的真实过程

之前在某团队合作一个推荐模型项目，A同学和B同学分别独立复现同一个训练流程，结果A的验证集指标比B高了接近0.02。两人代码版本一致、环境镜像一致、随机种子一致，看起来什么都对得上。最后我让他们把数据文件的哈希值列出来，一查才发现：A机器上数据集是5月12号的版本，B机器上数据集的路径名虽然完全一样，但文件其实在5月20号被覆盖过。数据版本不一致，其他再对齐也没用。

这件事之后我们把数据校验从“靠人自觉”变成了“训练入口强制校验”，没有通过哈希校验的训练任务直接不给跑。排查过程本身不算复杂，但它说明一个道理：可复现性不是某一个环节的事，而是数据、代码、环境、随机状态四者的合力结果。少记录任何一块，排查时都要多花好几倍时间。

5. 可复现不等于“每次一分不差”：我们要复现的是边界，不是玄学

聊到这里，你可能会有个疑问：是不是把所有种子、环境、代码都固定了，模型训练就必须每次都给出完全一样的数字？从理论上讲，在一个完全确定的单机环境里，可以做到高度一致；但在真实工程里，我建议你换个目标：把结果稳定在可接受的容差范围内，而不是追求逐位相同。

5.1 什么时候可以接受微小的波动？

单机单卡训练通常能做到接近确定，只要算子没有太强的非确定性、依赖版本没有变化，两次训练结果往往能对齐到小数点后三四位。但一旦进入多卡并行或分布式训练，情况就不一样了。多卡训练中梯度在不同设备之间做归并，通信顺序、数值精度都会带来细微差异，这种差异在累积之后可能变成零点几个百分点的指标浮动。

所以我做实验对比时，会把“可复现”定义成一个区间：两次训练同一模型的指标差不超过某个阈值，比如相对误差0.5%，就认为可复现；超过阈值则视为异常，必须停下来排查。这个阈值不是拍脑袋定的，而是要结合你任务本身的波动来设。如果模型在固定数据上本身就有较大的随机波动，你硬要要求0.1%以内，那大概率是折腾自己。核心思想是：要复现的是“实验结论”，而不是“浮点数本身”。

5.2 把“可复现”变成持续回归测试

可复现性如果只在新实验启动时被想起来，那它永远是被动的。更好的做法是把它做成一类自动化回归测试：定期用同一份测试数据、同一个训练配置，把当前模型和上一版本的模型都跑一遍，对比评估指标。

我自己的习惯是，每次模型结构或数据处理逻辑有变动时，先跑一个“对照实验”：新代码、旧代码在相同数据子集上各训一个小规模版本，看指标差异方向是否与预期一致。如果新代码引入了不该有的变化，这个小规模对照实验能很快暴露出来，不需要等到完整训练结束才发现问题。

组件化分析、事故复盘、抽查抽查都是这里持续安装的场景。这样做的成本很低，收益却很高：可复现性从“临时救火”变成了“日常体检”。

5.3 我日常训练前常用的检查清单

这里分享一份我每次启动训练前都会在脑子里过一遍的清单，你可以直接抄走：

• 随机种子是否在数据加载和模型构建之前固定？
• DataLoader是否单独指定了Generator？
• cuDNN的确定性开关是否打开？
• 依赖是否通过锁文件固定并记录在实验卡片里？
• 数据版本是否经过SHA256校验？
• 代码commit和当前工作区是否干净？
• GPU型号和CUDA版本是否写进了训练日志？

这套清单不复杂，但它能把“可复现”从一句口号变成每天重复的动作。我大部分踩过的坑，最后回头都能对应上清单里的某一行。

6. 回头看“可复现性挑战”，我自己的坚持

做了几年训练和模型迭代之后，我看代码的眼光变了。拿到一份训练代码，我最先看的不是它的网络结构有多精巧，而是它敢不敢把随机种子、数据版本、环境指纹这些“出身信息”摆在明面上。敢摆出来的实验，至少经得起别人问一句“换台机器还行吗”；不敢摆的，哪怕指标再好看，我心里也会打个问号。

我不敢说我现在的每个实验都做到了百分之百可复现，但我至少养成了一些小习惯：每次训练前多写一行种子，每次跑完多导出一份环境锁文件，每次对比实验多记录一下数据版本的哈希值。这些动作单独看都不起眼，积累起来却能让整个项目的可复现性上一个台阶。

最后再多说一句，AI的可复现性挑战不是一个“一次就能解决”的问题，它更像是一个持续维护的实验纪律。你只要稍微松懈一点，那些隐藏的随机源和环境漂移就会悄悄回来。好在应对手段并不神秘——固定种子、锁定环境、记录上下文、设置合理容差，然后把它们变成日常惯性。做到这些，你会在某一天突然发现，那些曾经让你抓狂的“幽灵差异”，已经很久没有出现过了。