复现问题是深度学习工程里最常见的坑之一。明明代码没改、数据没换、模型权重文件一模一样，两次推理输出的结果却存在肉眼可见的差异，有时候top1分类结果甚至完全不同。造成这种现象的根源在于整个计算链路中存在大量随机性和非确定性操作，包括随机数生成、GPU并行归约顺序、cuDNN算法选择等。本文从随机性来源分析入手，给出系统性的确定性配置方案。
一、先搞清楚结果不可复现的随机性来源
很多工程师一上来就直接设置torch.manual_seed(42)，结果发现还是不可复现，原因就是随机性的来源远不止Python层面。完整的随机性来源可以分成四层：Python内置随机数、NumPy随机数、框架自身随机数、CUDA设备端随机数。这三套随机数生成器相互独立，只固定其中一个是不够的。
除了随机数，还有一个更容易被忽略的问题是非确定性算子。GPU为了性能，某些操作（比如原子加法、reduce sum）的并行归约顺序在不同批次之间可能不同，浮点数加法又不满足结合律，导致最终结果出现微小偏差。这点偏差经过多层网络传播放大后，输出就可能明显不同。cuDNN在反向传播中的非确定性尤为明显，推理阶段则主要受卷积算法选择的影响。
此外，数据加载也是一个变量。DataLoader在shuffle=True时依赖随机数打乱顺序，多进程worker各自又有一份独立的随机状态，如果不在worker初始化时固定种子，即使主进程种子固定了，每个epoch的数据顺序仍然不确定。
二、固定随机种子的完整代码方案
下面这段代码覆盖了Python、NumPy、PyTorch和CUDA四个层面的种子设置，可以直接作为工具函数放到项目里使用：
import os
import random
import numpy as np
import torch
def set_seed(seed: int = 42):
# Python 内置随机数
random.seed(seed)
# NumPy 随机数
np.random.seed(seed)
# PyTorch CPU 随机数
torch.manual_seed(seed)
# PyTorch CUDA 随机数，当前设备和所有设备都会设置
torch.cuda.manual_seed_all(seed)
# 控制 Python 哈希种子，影响 dict/set 遍历顺序等
os.environ["PYTHONHASHSEED"] = str(seed)需要注意的是，哈希种子必须在解释器启动前设置才生效，最稳妥的做法是在启动命令中加上PYTHONHASHSEED=42 python main.py，而不是只在代码里设置环境变量。如果模型中使用了dropout，推理时务必调用model.eval()，否则dropout层会继续按概率随机丢弃神经元，这是新手最常犯的错误之一。
对于DataLoader，除了主进程设置种子外，还要给每个worker传入独立的种子函数：
def seed_worker(worker_id):
worker_seed = torch.initial_seed() % 2**32
np.random.seed(worker_seed)
random.seed(worker_seed)
g = torch.Generator()
g.manual_seed(42)
loader = torch.utils.data.DataLoader(
dataset,
batch_size=32,
shuffle=True,
num_workers=4,
worker_init_fn=seed_worker,
generator=g,
)这样配置后，每个worker的随机状态是确定且可复现的，同一份数据在多轮训练中的加载顺序完全一致。
三、启用确定性算法模式
固定种子只能解决随机数问题，非确定性算子需要通过确定性模式来解决。PyTorch提供了两种方式，旧版本使用torch.backends.cudnn.deterministic = True配合torch.backends.cudnn.benchmark = False，新版本（1.8及以上）推荐使用更彻底的开关：
import torch # 新版推荐做法 torch.use_deterministic_algorithms(True) # 关闭 cuDNN 自动选择算法，固定卷积实现 torch.backends.cudnn.benchmark = False torch.backends.cudnn.deterministic = True # 某些操作需要这个环境变量才能完全确定性 os.environ["CUBLAS_WORKSPACE_CONFIG"] = ":4096:8"
torch.use_deterministic_algorithms(True)会强制所有操作选择确定性实现，如果某个操作没有确定性版本，会直接抛出异常，这反而是好事，能帮你定位到具体是哪个算子造成了不确定性。此时必须设置CUBLAS_WORKSPACE_CONFIG环境变量，否则cuBLAS的矩阵乘法在CUDA 10.2及以后版本上仍是非确定性的，这也是很多人设置了确定性模式仍然复现失败的原因。
TensorFlow用户对应的配置如下，思路一致：
import tensorflow as tf tf.keras.utils.set_random_seed(42) # 开启确定性操作 tf.config.experimental.enable_op_determinism()
值得一提的是，确定性模式会带来性能损失。因为GPU要放弃一些速度更快的并行策略，改用顺序确定的计算方式，训练速度下降10%到30%是常见现象。所以工程实践上通常的做法是：开发调试阶段开启确定性模式验证正确性，生产部署阶段根据业务对一致性的要求决定是否保留。像金融风控、医疗诊断这类对结果可审计性要求高的场景，建议生产环境也保持确定性配置。
四、其他容易踩的坑与验证方法
除了上述主流配置，还有几个细节容易导致复现失败。一是混合精度训练中的loss scaling是动态的，会引入不确定性，建议复现实验时先切回FP32。二是多卡训练时，分布式通信的归约顺序、AllReduce的实现都可能导致差异，需要结合分布式确定性配置处理。三是不同版本的CUDA、cuDNN、PyTorch本身计算结果就有细微差别，跨环境复现需要锁死整个依赖版本，建议用Docker镜像把驱动之外的整套软件栈固化下来。
验证复现是否成功，可以写一个简单的对比脚本：连续运行两次推理，比较输出张量是否完全相等：
out1 = model(dummy_input)
out2 = model(dummy_input)
assert torch.equal(out1, out2), "两次推理结果不一致，仍存在非确定性因素"
print("结果完全一致，复现配置生效")如果断言失败，可以逐层排查：先在CPU上运行排除GPU因素，再逐层hook中间输出，找到第一个出现差异的层，基本就能定位到具体的算子。总结来说，可复现的核心就是三件事：固定所有随机数种子、启用确定性算法、锁定运行环境版本。把这三点做到位，模型结果就能稳定复现了。