最近一段时间我在几批模型训练和推理项目里反复遇到同一个问题明明代码没改数据没换训练脚本里的随机种子也固定了但换一台机器重新跑结果就是和上一次对不上。有时候是损失曲线在某个epoch后悄悄分叉有时候是同一段prompt两次调用模型给出不同的答案。起初我以为是代码写得不够严谨后来发现这就是AI开发绕不开的一个底层命题——可复现性。我在这里说的可复现性不是论文里的抽象原则而是工程上的实际问题一个实验跑了三天结果无法被别人或者未来的自己复现这个实验的价值就打折了。模型对比结论可能被推翻服务上线的效果评估可能失真甚至一个已经部署的模型在更新依赖库之后悄无声息地改变了行为。这篇文章把我这些年踩过的坑、总结的排查链路和一些能直接落地的固定策略整理出来。适合正在训练模型的工程团队、做实验横向对比的算法工程师、以及把大模型接入服务的开发同学参考。1. 复现性不是铁板一块实验级、过程级与结论级的差别1.1 一个“看得到但追不到”的差异先说个真实场景。有一次我们团队做两个模型的效果对比A模型在某数据集上比B模型高了0.5个点大家都准备写结论了。结果负责复现的同事换了一台机器重跑发现两个模型打平了。代码、数据集、随机种子都一样唯一差别是两台机器上的软件环境不同。一开始大家以为是B模型在某些随机种子下表现不稳定后来定位到根源数据增强库在两个版本之间改了实现方式同样的图像预处理在新版本里输出像素值有极小的偏移这个偏移经过几十个epoch的训练被放大最终影响了指标。这个例子说明可复现性不是一个“有或没有”的问题而是“在哪个层面上成立”的问题。1.2 三层定义bit级、路径级与统计级我在实际项目里习惯把复现分成三个层级来谈因为不同场景下要求完全不同混在一起讨论永远说不清第一层实验级复现bit级完全一致。意思是同样的输入、同样的代码、同样的环境跑出来的每一步数值都完全一致。在深度学习训练场景里这基本只在完全相同的硬件、驱动、算子库、编译选项和随机数序列下才可能做到。换一块GPU卡哪怕同型号但驱动版本不同数值就可能出现细微差异。第二层过程级复现路径级一致。允许浮点粒度的抖动但整个训练过程或推理输出的宏观表现一致。损失曲线能稳定复现推理结果分布能稳定复现最终指标在一个合理的小范围内波动。这是工程侧应该努力守住的目标。第三层结论级复现统计级一致。通过多个随机种子、多轮实验统计结论保持稳定。比如A模型在多次实验中始终比B模型高0.4到0.6个点且方差很小那么这个结论是可信的。这是论文和业务决策的最低要求。很多项目里吵架吵不明白就是因为两个人说的“复现不了”根本不在一个层级上。一个人要的是bit级一致另一个人觉得统计结论没问题就行这俩当然谈不拢。1.3 大多数团队真正应该守住的是“过程级”为什么大多数团队不需要死磕bit级因为追求bit级一致的成本极高要锁定硬件、驱动、编译器、算子库还要接受性能损失比如关闭算子自动调优这对快速迭代的团队来说不现实。但完全不设防也不行。只追求“结论方向一致”而不管指标波动会让实验对比失去意义。我的建议是日常实验守住过程级关键实验多跑几个种子守住结论级只有安全攸关或监管需求明确的场景才考虑bit级。有了这个坐标系后面讲的所有方案都是为了帮你在合适的层级上实现可复现而不是盲目把所有东西都锁死。2. 锁环境链路从随机种子到容器镜像的完整配置2.1 固定随机性是起点不是终点很多人的复现工作是从固定随机种子开始的。这是个正确的第一步但远远不够。我给你看我平时训练脚本里固定随机性的标准片段import random import numpy as np import torch def set_seed(seed: int 42): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) # 关闭 cudnn 自动调优选择确定性算法 torch.backends.cudnn.deterministic True torch.backends.cudnn.benchmark False这里有两个关键点一是torch.cuda.manual_seed_all(seed)不能少它负责所有GPU设备的随机状态二是cudnn.benchmark False。这个开关很隐蔽——如果保持benchmark True框架会在第一次运行时根据输入shape挑选最快的卷积算法不同机器、不同显存占用下挑出来的算法可能不一样结果自然就对不上。还有一个更严格的选项是torch.use_deterministic_algorithms(True)开启后某些非确定性的算子会直接报错。但要注意它会禁用一些算子训练速度会受影响不是所有场景都适用。2.2 环境指纹让每一台机器都有“身份证”固定了seed环境不同还是白搭。我遇到过一个典型的坑A机器用的CUDA 11.8B机器用的CUDA 12.1两边pip freeze出来的Python包版本完全一致但跑了同样的模型最后指标差了一个百分点。原因就是不同CUDA版本底层的算子实现不同浮点运算的归约顺序不一样。所以光有pip freeze是不够的。我现在的做法是给每台跑实验的机器生成一份“环境指纹”记录以下字段字段示例说明GPU型号NVIDIA GeForce RTX 4090不同架构浮点行为差异很大驱动版本535.104.05驱动影响算子库行为CUDA版本11.8编译和运行时的算子库版本cuDNN版本8.6.0卷积算子的具体实现Python版本3.10.12解释器行为差异核心框架版本torch 2.0.1框架层改动影响最大关键包哈希requirements.sha256锁定包内容的完整性随机种子42实验参数而非环境信息生成方式很简单在容器里跑一段脚本把环境信息写进JSON实验记录里直接关联这份文件。如果整个环境用Docker镜像管理那更简单记录镜像ID就行。# 环境冻结命令示例 pip freeze requirements_$(date %Y%m%d).txt conda env export environment_$(date %Y%m%d).yml docker images --digests | grep your-image-name2.3 为什么环境锁死后结果仍会漂移浮点与GPU架构就算你完全锁死了软件环境在不同GPU之间还是可能复现不了。这是很多人忽略的物理层问题。核心在于浮点运算不具备结合律。举个例子三个小数相加(a b) c和a (b c)在数学上等价但浮点表示下舍入顺序不同结果就可能差一个很小的值。千万别小看这个差值深度学习网络里有几百万甚至几亿次这样的运算每个差值都被一层层传递和放大最终在某个epoch后体现为loss曲线的肉眼可见分叉。GPU架构不同这种差异更明显。同一个算子在消费级显卡和数据中心级显卡上的内部实现可能完全不同有的用更宽的向量化指令有的在混合精度下采用不同策略。另外PyTorch里有个默认开启的torch.backends.cuda.matmul.allow_tf32选项控制矩阵乘法是否用TF32精度。不同时代的卡对这个格式的支持和默认行为都不一样这方面值得单独检查。2.4 锁定代码与数据版本复现的最后一块拼图最后是代码和数据。代码要锁定到commit级别不能用“我改了几行”这种模糊记录。数据更隐蔽一个CSV文件里行的顺序变了、一个图像预处理脚本更新了、一个标注文件被重新导出这些都可能悄悄改变实验结果。我的做法是给数据本身做一个manifest文件记录每个文件的路径、大小、SHA-256哈希以及预处理脚本的版本。任何一次数据变更比对manifest就知道谁动了什么。这不复杂但能避免很多“复现不了时怀疑人生”的时刻。3. 多卡训练里的三个隐蔽环节数据管道、分布式采样与梯度同步3.1 DataLoader的随机性与worker数量的隐藏影响单机单卡环境还算好控制多卡训练才是复现性问题的重灾区。先说最容易被忽略的DataLoader的worker进程。PyTorch的DataLoader默认每个worker拥有独立的随机数生成器。如果你设置了shuffleTrue数据在每个epoch的加载顺序会和worker数量、worker的初始随机状态有关。也就是说num_workers0和num_workers4跑出来的是两条不同的数据路径即使你设了全局seed也一样。更麻烦的是数据增强的随机性也发生在worker里。一个增强序列包含随机裁剪、翻转、色彩抖动每一步都在消耗随机数。worker数量变了随机数的分配方式就变了增强后的图像就完全不同。实操建议在实验报告里固定num_workers、batch_size和shuffle行为如果条件允许对关键实验把数据增强序列离线预生成并保存到磁盘训练时直接读取固定序列。这样虽然会占用存储但复现性是铁打的。3.2 分布式Sampler世界大小变化边界就变化分布式训练里DistributedSampler会根据world_size和当前rank把数据集切成多份。从4卡改成8卡同一个epoch里“同一批数据”会落在不同的GPU上梯度累积的路径因此改变全局更新的轨迹也就变了。这个坑非常隐蔽因为很多人只记录batch_size不记录world_size。我见过一个案例一个模型从单机4卡迁到单机8卡总batch_size保持不变通过调整per-GPU batch_size实现但训练结果就是不一样。排查了很久才发现数据集切分边界变了前几个batch喂给模型的样本组合完全不同模型初期的学习路径被改写。所以现在我的实验记录里world_size和per_gpu_batch_size是必填字段和总batch_size同等重要。跨配置对比时要特别小心最好固定world_size只做单一变量的调整。3.3 梯度同步的浮点累加顺序同一份模型的两条路径还有一个隐藏问题是梯度同步时的浮点累加顺序。多卡训练通常用AllReduce把各GPU的梯度合并起来。AllReduce在环拓扑下是按邻居顺序逐卡传递的在树拓扑下可能按层级归并不同拓扑意味着不同的浮点累加顺序。再加上混合精度训练里的梯度缩放器grad scaler它的行为在不同batch的梯度分布下会动态调整进一步引入不确定性。同样的模型、同样的数据用NCCL和Gloo两种后端或者不同的通信算法最终结果都可能出现微小的差异。我的实操纪律是重要实验固定通信后端、固定通信拓扑、固定多卡机型配置不拿“单机8卡”和“两机16卡”的配置做横向对比。如果你要做分布式扩展性实验那就接受结论级复现别追求过程级一致。3.4 多卡实验的几条实操纪律把上面这些总结成几条可执行的纪律用单卡小batch先跑通小规模样本验证训练逻辑和数据管道没有大问题再上多卡完整训练。固定DataLoader的worker数量、采样器和shuffle行为。实验记录里必须包含world_size、per-GPU batch size、通信后端、GPU型号和驱动版本。分布式训练的对照实验尽量在同一批机器上完成因为“同型号但不同机器”也可能存在细微差异。4. 推理端的非确定性采样、量化与并发请求的三重扰动4.1 temperature0并不等于确定logits扰动了解一下如果只做模型训练复现性问题已经够让人头疼了。但在大模型应用里推理端的可复现性更“迷”——因为同一个prompt问两次模型可能给出完全不同的答案。最常见的原因当然是采样参数temperature 0时模型每次从概率分布里抽样结果自然不同。即便是temperature 0很多推理框架的语义也不是“严格贪心解码”而是会让logits经过一个很小的随机扰动后再选最高分token。不同框架、不同版本对这个扰动的实现都不一样。还有一个边界情况服务端通常会做动态batching把多个并发请求拼在一个batch里执行。batch里其他请求的存在会改变矩阵乘法的内存布局甚至改变某些kernel的并行化路径导致本应相同的logits出现微小差异。这个影响在短文本上不明显在长文本生成上会被累积放大。4.2 批处理与量化的隐性问题量化推理更麻烦。同一个模型导出成INT8或INT4后不同推理框架的量化算子实现差异很大有的框架在反量化时用不同的舍入策略有的框架对注意力层保留更高精度有的框架在CPU和GPU上走完全不同的路径。这些差异在短回答里可能不体现但一旦生成序列超过一定长度token的累积偏差就会触发分叉一个回答结尾和另一个完全不同。我自己做过一次简单实验同一个量化模型同一个prompt在框架A的CPU后端和框架B的GPU后端上各跑20次结果有6次生成了不同的回答。这个比例相当惊人也说明如果要做模型服务的回流评测或A/B对比不控制推理环境结论基本不可信。4.3 让大模型评估结果“可复现”的几个固定策略针对推理端我现在的做法是建立一套“评估采样策略”每次跑评估都严格走同一套参数固定推理框架的版本号不用“最新版”或者“某个分支”。固定采样参数temperature、top_p、top_k、max_tokens、presence_penalty、frequency_penalty全部写死。固定随机种子虽然不是所有框架都完全遵循但至少能消除一部分随机性。评估基准测试时关闭动态batching让每个请求独立推理避免并发干扰。关键指标不要只跑一次至少跑3轮取聚合值观察波动范围。如果是线上服务无法关闭动态batching那就至少保证A/B两组在同一时间段、同一套服务参数下运行让环境差异被均匀分摊而不是让“网络波动”或“并发量差异”变成结论的干扰因素。5. 复现不了时怎么办搭建一套够用且不过度的验证机制5.1 快速分类这是环境问题、逻辑问题还是统计问题碰到复现不了的情况先别急着改代码。我习惯先做一个快速分类判断问题属于哪一类环境问题换了机器或版本后结果对不上。对策是比对环境指纹锁定容器或依赖版本。逻辑问题同一环境下两次执行结果不同且数值差异明显。对策是检查数据读取顺序、DataLoader随机性、采样参数排查是否误用了全局状态。统计问题多次执行结果有差异但指标在合理范围内波动。对策是接受它用多种子实验支撑结论。判断方法很简单先固定环境跑两次。如果两次差异明显说明问题出在代码或数据管道如果两次一致但换环境就不一致说明是环境问题如果两次本来就在合理范围内波动那可能只是统计噪声。5.2 回归基准集与容差让复现变成“可判定”“结果差不多”这种描述没法用于工程决策。我建议团队建立一个小的固定回归基准集每次环境或代码变更后先跑一遍基准集指标落在预设容差内就算通过。容差怎么定跑5个不同种子的基准实验计算指标的均值和标准差把2倍标准差作为预警线。举个例子一个分类任务F1的均值是0.832标准差是0.004那么0.008以内的波动属于正常范围。如果一次变更后F1变成了0.820即使方向是“变差”也要先确认是不是在统计波动范围内再做进一步分析。这个机制不复杂但能极大减少“复现不了”带来的主观争论让所有比较都有一个明确的判定标准。5.3 实验记录单从草稿本升级到结构化模板复现工作做得好不好很大程度上取决于实验记录的质量。我现在的做法是给每个重要实验建一张结构化记录单字段包括任务ID、目标、代码commit、环境指纹文件、数据manifest哈希、超参数、随机种子组、world_size、推理采样参数、结果指标、复现步骤、执行人和日期。每次实验结束把这份记录单和结果文件归档到同一个目录。看起来是增加了工作量但省去的返工时间绝对值得。我之前有一次要复现一个三个月前的实验靠的就是这份记录单里的容器镜像ID和数据manifest否则纯粹是从零开始。5.4 关于“追不追”的取舍我的个人经验最后说说取舍。不是所有抖动都值得追到bit级。训练类实验守住过程级就够了推理服务和业务结论守住结论级就够用只有遇到莫名其妙的大幅差异时才值得花力气往深处查。我现在开工做任何实验前都会先跑一段环境指纹脚本把GPU型号、驱动版本、CUDA版本、关键包哈希和随机种子写进一个文件实验结束后把结果和文件一起归档。这个习惯帮我省了很多返工时间。如果你也被“复现不了”折磨过我建议从一次简单的环境记录开始不需要一步到位先把最容易出问题的环境、数据、采样参数盯住后面会顺畅很多。