1. 可复现性问题的本质：同样一段代码，为什么换台机器结果就对不上
我之前在一个项目里接过一个任务：把几个月前训练出来的某图像分类模型完整复现一遍。代码是从仓库里拉出来的，环境照着文档装好，训练也能顺利跑完，结果一看验证集精度，比历史记录低了将近0.4个点。我第一反应是数据下载错了，反复核对文件哈希、检查超参数配置、确认训练脚本没有改动，可训练曲线就是和原来不完全一样。那段时间我几乎把能查的地方都翻了一遍，也是从那时起，我开始认真研究AI可复现性挑战背后的系统性问题：为什么同一套代码，在看起来相同的条件下，结果就是不能完全对齐？
先说一个容易让人绷不住的结论：深度学习训练过程的很多环节天生就带随机性，而且训练过程中的数值计算路径也不是严格确定的。权重不是手写的，而是从某个随机分布里初始化出来；训练数据也不是每次都按同一个顺序进入模型，shuffle本身就是一个随机过程；如果还用了随机裁剪、随机翻转、色彩抖动这类增强，那每一次前向计算看到的样本都不完全一样。这些随机性单拎出来，每个都不至于让实验结果无法解释，迭代几百步之后模型往往能收敛到差不多的位置。真正麻烦的是另一个容易被忽视的因素：浮点数运算。数学上a+b和b+a永远相等，浮点运算却不是。GPU并行计算时，数据会被拆成很多块，不同块内部的加法顺序不一样，中间舍入误差也就不一样。单个数字上的差异极小，但放进几百万步的梯度更新里，就可能被逐渐放大。用一句不严谨但容易记的话说：训练过程不是一条稳定直线，而是一个对初始条件非常敏感的迭代系统。
1.1 训练结果为什么是“非确定性”的
很多人以为训练脚本写完了，结果就应该像普通程序一样每次都跑得一模一样，但实际上模型训练是一个充满随机选择的过程。我一向建议从“随机性来源”梳理问题，而不是一上来就怀疑模型代码写错了，常见的来源包括这么几类：
- 参数初始化。权重和偏置通常从随机分布中采样，采到什么初始状态直接决定了后续优化路径。
- 数据加载顺序。
shuffle=True时，每个epoch的数据顺序会不同，等价于改变了梯度更新的走向。 - 数据增强。随机裁剪、旋转、亮度调整都依赖随机数生成器，输入样本一变，梯度自然就变了。
- 多进程数据加载。数据加载器里的多个子进程各自持有随机状态，子进程的调度顺序会影响数据拼接和采样的结果。
- 并行计算的归约顺序。GPU上矩阵乘法和卷积会把数据切成多块并行计算，块的划分和合并顺序在不同硬件、不同算法下不一样。
这些因素累加在一起，最终表现出来就是两条“看起来应该一样”的训练曲线，可能在某个中间节点开始分叉，然后各自走向不同的区域。这不是玄学，而是浮点运算特性、随机数生成机制和并行计算策略共同作用的结果。
1.2 随机种子不是万能的“定海神针”
最早我以为只要写一个seed=42就都解决了，后来发现这只是一个起点。Python的random、科学计算库里的随机数生成器、深度学习框架自身的随机数流，是各自独立维护的，得分别设置种子才能覆盖到不同模块。我在一些项目里看到初始化脚本里确实写了随机种子，但一涉及GPU算子，又会引入新的随机源，单靠固定全局种子根本管不住。
更隐蔽的是，框架底层加速库会在默认情况下做自动调优。训练开始前，加速库会先用一小段数据试跑多种卷积算法，挑出当前硬件上看起来最快的那种，然后整个训练都用这个算法。问题是，这个“最快算法”的选择结果在不同GPU型号、不同驱动版本甚至不同负载状态下可能都不一样。不同卷积算法在数学上等价，但内部计算的拆分和累加顺序不同，数值结果就会有细微差别。所以代码要往“可复现”方向收敛，通常需要把自动调优关掉，再开启确定性模式，同时固定数据加载器的随机源。这一整套做下来，只是把不确定性压低，并不意味着任何环境下都能做到完全一致。如果项目里还开了分布式并行，那么数据分发顺序和梯度聚合顺序本身就可能成为新的不确定性来源。
2. 一次复现失败的完整排查链路：从环境指纹到数据管线
那次复现失败之后，我没有急着改模型结构，而是把整个过程当成一次案发现场来排查。下面这些步骤是我实际走下来的，每一条都指向一类常见问题。如果你也遇到“代码一样但结果对不上”，可以照着这个顺序自查一遍。
2.1 把环境指纹拉出来逐项对比，而不是只看Python版本
我一开始只对比了依赖列表和Python版本，结论是“差不多”。后来发现这个“差不多”害死人。正确的做法是把两边的完整环境快照导出来，逐项对比：Python版本、环境管理工具里的包列表、加速库版本、GPU驱动版本、显卡型号、CPU型号，甚至系统库版本和关键环境变量都不能放过。我发现的问题很典型：历史记录用的是Python 3.8和某个框架的旧版本，新环境却升到了Python 3.10和新版本框架。光这一步，就足以让很多算子的默认行为和数值实现发生变化。
把新环境回退到原环境的完整版本组合之后，我重新跑了一次，结果确实往历史值靠近了一部分，但还没有完全对齐。说明环境差异只是问题的一部分，还需要继续往下查。
| 环境维度 | 需要对比的内容 | 常见坑 |
|---|---|---|
| Python运行时 | 大版本、小版本、发行版 | 3.8和3.10在哈希随机化、字符串处理上都有差异 |
| 依赖包列表 | 核心框架版本、数据处理库版本 | 版本号看着接近，内部实现可能已经变更 |
| 加速底层库 | 加速库版本、驱动版本 | 不同版本对同一算子的实现不同，浮点结果不同 |
| 硬件信息 | GPU型号、CPU型号、内存架构 | 并行归约顺序和线程调度策略不一样 |
| 环境变量 | 可见设备编号、哈希种子、线程数 | 多进程加载数据时线程数会影响数据顺序 |
2.2 锁定数据管线里的隐式随机性
环境对齐之后，我开始怀疑数据管线。很多“复现不成功”最后都定位在这一层。我比对了训练脚本里的shuffle实现，发现它直接用了数据加载器默认的随机源，没有传入独立的随机数生成器。这种写法的结果是：每次程序启动，数据顺序都不同。如果只是顺序不同，影响还不算致命，但数据增强库的版本差异更隐蔽。同一个随机裁剪算法，在两个版本里可能因为边界处理方式或插值算法不同而生成略微不同的图像；输入图像差一点点，梯度方向就会差一截，几百步之后整个训练轨迹就被带偏了。
当时的修复方式并不复杂：为shuffle单独创建一个随机数生成器并设置好种子，再把它传给数据加载器；自定义增强流程里所有用到随机数的地方，都基于这个生成器统一播种。这样改完，在相同配置下，两次运行的数据顺序终于能保持一致。但保留这个细节很关键，因为你不知道哪一天会有人在另一台机器上复现你的实验。
2.3 在相同迭代点对齐模型状态，找到分叉位置
环境和数据都固定了，不代表最终精度就一定能对齐。为了搞清楚两次训练是“始终接近”还是“在中途分叉”，我让每次运行都在固定的迭代步数里保存检查点，然后写脚本逐层对比两个检查点之间的权重差异。观察结果是：前几百步差异很小，到中间某个节点开始逐步拉开。这说明初始随机状态已经基本一致，剩余差异很可能来自浮点运算在不同软硬件路径上的累积误差。
为了防止误判，我进一步比较了同一批数据前向计算后的激活值差异。如果激活值在第某个迭代步出现明显分叉，而前面梯度范数都处于同一量级，基本可以判定问题不在代码和数据，而是数值层面的微小抖动被训练过程放大了。这个“定位分叉点”的方法在以后排查类似问题时也一直很好用，至少能帮你把问题范围从“整个项目”缩小到“某个环节”。
2.4 多数“复现不了”问题，根源都在环境与数据
排查完这三步，结论和大多数类似项目一样：环境版本和数据管线的差异导致复现失败，模型代码本身没有致命问题。真正难的地方在于，排查过程中容不得半点“差不多”心态。环境版本差一个小版本、数据加载顺序差一次shuffle、增强库版本差一个补丁，都可能让最终精度差出零点几个点。如果一开始就养成记录环境指纹和固定数据管线的习惯，这次排查至少能省下一半时间。这也是为什么我坚持认为，可复现性不是某个框架的功能，而是从实验设计到工程实现的整体约束。
3. 那些自欺欺人的“伪复现”：种子、日志和论文里的假象
排查过几次实际问题之后，我开始留意一个更扎心的现象：很多实验记录里的“复现成功”其实经不起推敲。不是说大家都故意造假，而是实验记录方式本身存在漏洞，导致结果看起来能复现，实际上换个环境就破功。
3.1 只固定了随机种子，版本却没人管
我经常看到实验文档里写着“seed=2022”，但代码运行环境装的是当时的最新依赖。半年之后有人来复现，重新安装依赖时，某个库升了几个小版本，浮点算子实现变了，精度稍微差了一点。这时候没人能说清差异是怎么来的，最后只能把它归结成“深度学习玄学”。其实真不是玄学，是版本没被锁住。固定的随机种子只对同一环境有效，环境版本和随机种子必须放在一起记录才有意义。只记种子不记环境，就像只保存了保险箱的密码，却把保险箱钥匙丢了。
3.2 日志对得上，不代表结果对得上
我还见过一种情况：项目只留了训练日志，没有保存完整检查点、配置和环境信息。日志里写着“loss降到了0.02”，看起来一切正常，但有人拿到模型之后做前向推理，输出和当初报告的完全不同。原因可能是训练代码和评估代码用了不同版本，模型结构改动后没有同步提交，或者批量归一化层在训练和推理模式下的行为差异被忽略了。
更隐蔽的情况是，两个模型在精度指标上完全相同，但逐层对比权重后发现内部参数分布并不一致。这说明它们可能是通过不同初始化路径收敛到了相似的最终指标，本质上并不是同一个模型。只看日志、只比精度，这些问题一个都发现不了。所以我把“权重文件+配置结构+测试脚本”当作复现的基本单元，日志只是辅助材料，不能作为结论的唯一凭据。
3.3 “最好的一次结果”不是复现标准
不少人在做调参实验时会连续跑多次，然后从里面挑一个最高分写进结果。这个做法本身没问题，问题出在报告里只写最高分，不写运行次数和方差。后面的人拿同样的配置跑一次，如果结果低于那个最高分，就开始怀疑自己哪里搞错了。其实可能只是运气问题。
正确的做法是：记录多次运行的完整结果，报告均值±标准差；比较不同配置时，最好使用相同的多个随机种子交替运行，避免“某一组特别走运”的偶然因素干扰判断。可复现不是能重复出一次最高分，而是能在合理波动范围内重复出同一个分布。
4. 一套能管住复现的基础设施：环境锁定、实验追踪与数据版本化
与其每次遇到复现问题都从头排查，不如在工程层面把复现性做成默认能力。这几年我在团队里沉淀下来一套比较有效的基础设施组合，成本不高，但对结果的可信度提升非常大。
4.1 把环境当源代码一样管理
如果只是个人写脚本，用一份依赖锁定文件勉强够用。但团队协作时，一份简单清单往往不够，因为它会漏掉系统库、加速库驱动等非Python依赖。更可靠的做法是把环境整体固化成镜像，用“基础镜像+版本标签”来对应每次实验的代码提交。这样训练和推理都跑在同一个环境里，任何人拿到标签就能还原出完全一致的软件栈。
没有条件上容器的话，至少要把环境管理工具的完整导出文件提交到仓库里，并额外保留一份构建脚本。我个人的习惯是同时保留锁文件和构建脚本，然后克制地升级依赖。做历史实验复现时，优先重建旧环境，而不是在新环境里硬跑旧代码。把环境当作和源代码一样重要的一等资产，这是可复现性基建的第一步。
4.2 实验追踪：让每次运行都有“身份证”
我会给每一次训练运行生成一条独立的实验记录，里面至少包含提交哈希、未提交的改动、启动时间、运行主机、GPU型号、随机种子、超参数、依赖版本、数据集哈希和最终指标。这些信息手工记很容易漏，最好交给实验追踪平台自动完成。平台会在每次运行时采集环境信息，把指标、参数和产出文件关联到一起。
有了这套记录之后，好处是实实在在的。几天后别人拿着结果来问“这个数字怎么来的”，我能直接给出完整上下文。遇到复现失败时，把两次运行的记录拉出来对比，第一步就能发现环境或数据差异，不用再从头猜。我现在看到“某个结果复现不了”的求助，第一反应都是先问：你有那次实验的实验记录吗？
4.3 数据版本化与配置入仓
最后容易被忽略的是数据和配置。数据集新增几个样本、替换预处理脚本、修改测试集切分方式，都会让相同代码跑出不同结果。最稳妥的做法是给数据版本一个可引用的标识，比如把数据集的哈希记录到实验日志里；数据量大的项目可以考虑引入数据版本管理工具，让训练脚本通过数据版本标识拉取对应数据。
配置也一样。训练用的所有超参数、路径、增强策略，都应该放在版本控制的配置文件里，和代码一起走评审和回滚。运行脚本只负责读取配置，不在代码里硬编码参数。这样做的价值是，任何一次实验结果都能精确回答“当时是用什么配置跑的”，而不是靠记忆力拼凑当时的设置。
5. 跨硬件与跨平台的复现边界：哪些差异能接受，哪些不能忍
即便环境锁了、数据固定了、实验追踪也做了，还有一个绕不开的话题：换硬件之后结果能不能复现。我在这方面的实测经验是，完全一致的字节级复现几乎做不到，但有办法把差异控制在可接受范围内。
5.1 换GPU后的精度漂移是浮点特性的正常表现
我做过一个实验：代码、环境、数据全部相同，只把GPU换成不同型号，最终验证集精度就有零点几个点的差异。这不是谁的代码出了问题，而是不同显卡在并行计算时，矩阵乘法和卷积的归约顺序不同，浮点累加误差被放大了。如果启用混合精度训练，数值范围的截断还会进一步增加差异。
框架底层的自动调优机制也会在换卡后重新选择最快算法，算法一变，数值结果就有细微差别。所以在需要尽量复现的场景里，我会关掉自动调优并开启确定性模式。即便如此，在不同架构的GPU之间还是很难保证bit级一致。做对比实验时，我会尽量用相同型号的GPU；换机器跑之前，先在老机器上跑一个基线，确认误差在预期范围内再继续。
5.2 分布式训练里存在更棘手的确定性困境
单机多卡和集群训练的复现难度，比单卡高一个量级。数据被切分到多个进程，每个进程的数据加载顺序受系统调度影响；梯度在各个节点之间做聚合时，归约顺序受到网卡、通信拓扑和通信库实现的影响。使用非阻塞通信时，只要一次运行中消息到达顺序不同，梯度累加结果就可能不同。
对于这类场景，我的建议是调整期望值：分布式训练里追求bit级精确复现是非常奢侈的，大多数时候做不到。更现实的目标是记录完整的训练配置、固定随机种子、关闭有损优化，然后报告多次运行的均值和方差。如果项目要求强复现，比如论文复现或者审计场景，那就优先用单卡或固定进程拓扑来跑，避免引入不必要的随机性。
5.3 给“可复现”一个科学且可操作的标准
经过这些折腾，我对“可复现”的理解已经变了。它不等于“每次跑出来都一模一样”，而是在给定条件下，结果能落在分布允许的区间内。我一般会把复现分成两个层次：
| 复现层次 | 含义 | 适用场景 |
|---|---|---|
| 精确复现 | 多次运行结果逐位一致，模型权重完全对齐 | 审计、合规、严格科学复现 |
| 统计复现 | 多次运行结果落在相近分布内，指标在可接受范围波动 | 绝大多数工业和学术项目 |
在报告里，我要求团队至少写清楚这几项：代码提交哈希、环境版本信息、GPU型号、随机种子、数据集版本、运行次数、均值与标准差。别人拿到这些信息，才能判断一个结论到底可不可靠。也就是在这个过程中，我把“AI可复现性挑战”从一次实验室里的意外事故，变成了自己每次都主动解决的设计问题。我养成的习惯很简单：每次训练脚本启动时，把关键环境信息打印到日志开头；每个实验运行结束，随手写一行可复现信息摘要。这件事几乎不花时间，但能在以后省下很多个加班的夜晚。
