深度学习实验复现：随机数种子设置与排查指南

自己跑深度学习项目时，最怕遇到什么？不是说网络不收敛，而是同一个脚本昨天跑出92.5%的准确率，今天跑就变成91.8%，代码一行没动，结果却对不上。新手第一反应是怀疑环境被改了，或者数据读取出了bug，折腾半天最后发现，罪魁祸首就是随机数种子（random seed）没有固定。“随机撒种子”这件事，听上去就是一行代码的事，实际做起来暗坑非常多。

这篇文章我用自己踩过的坑，把随机数种子到底是什么、它怎么影响训练结果、怎么设置才算真正锁死、设完之后还不稳定又该怎么排查，一次性讲清楚。适合正在做机器学习实验、经常训练模型、或者写论文需要复现结果的朋友，也适合刚入门深度学习、对随机性还没概念的初学者。你不用全看懂，照着后面的代码抄，就能解决90%的可复现性问题。

1. 先搞懂一件事：为什么程序里的随机数不随机

1.1 伪随机的本质：一台能预测的“数字播种机”

很多初学者以为random函数每次调用都从宇宙里抓一个随机数回来，其实不是。计算机里的随机数生成器（PRNG，Pseudo-Random Number Generator）本质上是一个确定性算法，它吃进去一个初始状态，然后通过数学计算不断往外吐数字。这个初始状态就是种子（seed）。

我们拿最简单的线性同余生成器来举例：

python复制X_{n+1} = (a * X_n + c) % m

只要确定了X_0（也就是种子）、乘数a、增量c和模数m，后面整串数字就全部确定了。Python的random模块虽然用的是更复杂的梅森旋转算法，但原理完全一样——种子的作用就是给这台“数字播种机”定一个起点。

你可以把种子理解成一片土地的初始条件。同一片地，撒下同样的种子，在同等条件下长出来的庄稼肯定一样。程序里也一样，种子值相同，PRNG吐出的随机数序列就完全相同；种子不同，哪怕是连续的两个整数，吐出来的序列也会天差地别。

1.2 深度学习训练里的随机性到底从哪来

很多初学者以为随机数只和“生成随机样本”有关，实际上深度学习训练的每一个环节都在消费随机数：

• 模型参数的初始化：torch.nn.Linear的权重初始值全靠随机数生成，种子不同，初始参数就不同。
• 训练集/验证集的划分：train_test_split、random_split都依赖随机数决定哪些样本进训练集。
• DataLoader的batch顺序：每个epoch取样顺序不同，梯度更新轨迹就会不同。
• Dropout层：每次前向传播随机丢弃哪些神经元，直接改变模型输出。
• 数据增强：随机裁剪、翻转、色彩抖动，全都要靠随机数。

所以你会看到，哪怕只是一次简单的MLP训练，只要有一处随机源没锁住，两次训练的结果就可能差出一个百分点甚至更多。固定随机种子的本质，就是把所有这些随机源全部锁到同一个起点上，让整片“庄稼地”按照同一套节奏生长。

2. 五步把种子撒齐：主流框架的种子设置指南

2.1 Python、NumPy、PyTorch要各管各的

先给一个结论：只设一个库的seed是远远不够的。

Python的random、NumPy的numpy.random、PyTorch的torch.manual_seed各自维护一套独立的随机状态，互不干涉。你设了np.random.seed()但没设torch.manual_seed()，那么模型初始化和DataLoader的数据顺序仍然每次都不一样。

我目前项目里用的是一套统一的种子设置函数：

python复制import random
import numpy as np
import torch

def set_all_seeds(seed: int):
    random.seed(seed)                # Python 内置随机库
    np.random.seed(seed)             # NumPy 随机库
    torch.manual_seed(seed)          # PyTorch CPU/GPU 通用
    torch.cuda.manual_seed_all(seed) # 如果用了多块 GPU，这句不能漏
    # 下面两项涉及 cuDNN 的确定性设置，后面单独讲
    torch.backends.cudnn.deterministic = True
    torch.backends.cudnn.benchmark = False

调用的时候直接set_all_seeds(42)就行。42不是魔法，因为《银河系漫游指南》里说“生命、宇宙以及一切的答案是42”，程序员圈子里用42当默认种子已经成了一种习惯——它只是一个约定俗成的起点，并不代表42跑出来的效果最好。你完全可以用0、1、2024，只要全程统一就行。

2.2 新版NumPy：建议直接换Generator

如果你用的NumPy是1.17以上版本，官方更推荐用新的随机API：

python复制rng = np.random.default_rng(42)
data = rng.normal(0, 1, size=(100, 4))

default_rng()返回一个Generator对象，它和老的np.random.seed体系是两套东西。老接口的全局随机状态容易在大型项目里被不小心覆盖，新接口则是独立的，更安全也更清晰。

这里要特别注意一个坑：如果项目里既有老代码用np.random.seed()，又有新代码用default_rng()，哪怕你两边都设了同样的seed，它们产生的随机数序列也是完全不同的。所以项目里最好统一用一种风格，别混着用。

2.3 PyTorch和TensorFlow各自的细节

PyTorch 2.x里，torch.manual_seed同时覆盖CPU和GPU，这点比早期版本方便了。但如果你用CUDA，建议再加上torch.cuda.manual_seed_all(seed)，尤其是多卡训练时，每张卡的随机状态都要单独初始化。

TensorFlow这边，2.x版本用tf.random.set_seed(seed)设置全局种子。但要注意，TensorFlow还区分全局种子和操作级种子，某些情况下需要在具体操作上再指定seed参数才能完全锁定。比如：

python复制import tensorflow as tf
tf.random.set_seed(42)
# 某些op级别还需要再声明一次
tf.random.uniform((3, 3), seed=42)

Keras里如果用tf.keras.utils.set_random_seed(42)，它会一次性把Python、NumPy、TensorFlow的随机状态都设好，比手动逐个设置省事很多。

2.4 设置顺序有没有讲究

有。虽然最终效果是各库各管各的，但建议按“Python -> NumPy -> PyTorch/TensorFlow -> CUDA/cuDNN”的顺序来设置。这样做的意义在于，如果你在设置种子之后又有任何代码动态导入或初始化了其他随机源，你可以清楚地追踪到是哪一个库还没锁死。

另外，这个设置函数一定要在模型实例化、数据加载、训练开始之前调用，越早越好。放在import之后、业务逻辑之前是最稳妥的。

3. 实操复现：从代码层面锁定一版可重复的实验

3.1 一个完整可复现的MNIST手写数字分类脚本

空谈没用，直接上一个我常用的最小可复现模板。这个脚本以PyTorch为例，训练一个简单的多层感知机在MNIST上做分类，保证连续运行三次，最终准确率完全一致。

python复制import random
import numpy as np
import torch
from torch import nn
from torch.utils.data import DataLoader, TensorDataset
from torchvision import datasets, transforms

SEED = 42

def set_all_seeds(seed):
    random.seed(seed)
    np.random.seed(seed)
    torch.manual_seed(seed)
    torch.cuda.manual_seed_all(seed)
    torch.backends.cudnn.deterministic = True
    torch.backends.cudnn.benchmark = False

set_all_seeds(SEED)

# 数据准备
transform = transforms.Compose([
    transforms.ToTensor(),
    transforms.Normalize((0.1307,), (0.3081,))
])

train_data = datasets.MNIST(
    root="./data", train=True, download=True, transform=transform
)
test_data = datasets.MNIST(
    root="./data", train=False, download=True, transform=transform
)

# 注意：这里用固定种子做数据集划分
train_data, val_data = torch.utils.data.random_split(
    train_data, [50000, 10000],
    generator=torch.Generator().manual_seed(SEED)
)

train_loader = DataLoader(train_data, batch_size=64, shuffle=True)
val_loader = DataLoader(val_data, batch_size=64, shuffle=False)


# 模型定义
class MLP(nn.Module):
    def __init__(self):
        super().__init__()
        self.fc1 = nn.Linear(28 * 28, 256)
        self.fc2 = nn.Linear(256, 128)
        self.fc3 = nn.Linear(128, 10)
        self.dropout = nn.Dropout(0.2)

    def forward(self, x):
        x = x.view(x.size(0), -1)
        x = torch.relu(self.fc1(x))
        x = self.dropout(x)
        x = torch.relu(self.fc2(x))
        x = self.dropout(x)
        x = self.fc3(x)
        return x


model = MLP()
optimizer = torch.optim.Adam(model.parameters(), lr=1e-3)
loss_fn = nn.CrossEntropyLoss()

# 训练
for epoch in range(5):
    model.train()
    for images, labels in train_loader:
        optimizer.zero_grad()
        outputs = model(images)
        loss = loss_fn(outputs, labels)
        loss.backward()
        optimizer.step()

    # 验证
    model.eval()
    correct = 0
    total = 0
    with torch.no_grad():
        for images, labels in val_loader:
            outputs = model(images)
            _, predicted = torch.max(outputs, 1)
            total += labels.size(0)
            correct += (predicted == labels).sum().item()
    print(f"Epoch {epoch+1}, Val Accuracy: {correct / total:.4f}")

运行三次，你会看到每一次打印的Validation Accuracy完全相同。如果没改成随机源，哪怕是同一个脚本，五轮训练下来验证集准确率都会有小幅波动。

3.2 验证可复现性的标准做法

实操时不要只看最后一次准确率，建议把每个epoch的loss都记录下来，画成曲线去对比。因为有时候两次训练的最终准确率碰巧一样，但中间的收敛过程完全不同，这说明还有随机源没锁死。

我习惯的做法是最少连续跑三次，然后看三个维度：

最后一条是终极验证。即使前两条都通过，如果模型权重还有差异，说明某个初始化步骤还是随机了。可以写几行代码验证：

python复制model2 = MLP()
model2.load_state_dict(torch.load("run1.pt"))
model1 = MLP()
model1.load_state_dict(torch.load("run2.pt"))

for (k1, v1), (k2, v2) in zip(model1.state_dict().items(), model2.state_dict().items()):
    if not torch.equal(v1, v2):
        print(f"参数 {k1} 不一致")
        break
else:
    print("两份模型参数完全一致")

如果打印出“完全一致”，说明这次实验的复现性已经锁得很死了。

3.3 版本环境也可能破坏复现结果

很多人只锁了代码里的种子，却忽略了环境版本。PyTorch的小版本更新、cuDNN版本变化、GPU型号不同，都可能导致随机数序列变化。原因很简单，同一个算法在不同硬件上的浮点运算顺序可能不同，比如并行归约的求和顺序不同，最终结果就会有微小差异。

所以在做严肃实验时，我还会把环境信息一并记录下来，方便日后回溯：

python复制import platform
import sys
print("Python:", sys.version)
print("PyTorch:", torch.__version__)
print("CUDA:", torch.version.cuda if torch.cuda.is_available() else "CPU only")
print("系统:", platform.platform())
print("GPU:", torch.cuda.get_device_name(0) if torch.cuda.is_available() else "无")

这些信息加上种子值，一起写进实验日志。以后哪怕模型跑丢了，也能根据日志快速判断是环境变更还是随机源泄漏。

4. 设了种子还是对不上？八成是踩了这些坑

4.1 漏掉cuDNN的设置，GPU上结果照样飘

很多人在CPU上复现得好好的，一到GPU就崩。这个问题的源头通常是cuDNN的自动调优算法。

torch.backends.cudnn.benchmark = True时，PyTorch会在第一次运行时测试多种卷积算法，选择最快的那一个。问题在于，不同算法的数值精度不完全相同，而且这个“最快”的选择结果在不同硬件、不同输入尺寸下可能不一样。为了可复现性，必须设置：

python复制torch.backends.cudnn.deterministic = True
torch.backends.cudnn.benchmark = False

第一行让cuDNN选择确定性的算法，第二行关闭自动调优。代价是某些卷积网络会慢一点，但对于实验复现来说完全值得。

4.2 DataLoader的num_workers会导致数据顺序变动

DataLoader(num_workers=4)这种写法和可复现性之间也有冲突。原因在于多进程加载数据时，每个worker进程的启动顺序、数据采样顺序都可能受系统调度影响，尤其是在Windows平台上，多进程的并发行为完全不可控。

如果要用num_workers > 0，建议同时设置：

python复制def seed_worker(worker_id):
    worker_seed = torch.initial_seed() % 2**32
    np.random.seed(worker_seed)
    random.seed(worker_seed)

train_loader = DataLoader(
    train_data,
    batch_size=64,
    shuffle=True,
    num_workers=4,
    worker_init_fn=seed_worker,
    generator=torch.Generator().manual_seed(SEED),
)

worker_init_fn会在每个worker进程启动时执行，确保每个worker里的Python和NumPy随机状态都源自同一个torch.initial_seed()。这样设置之后，多进程数据加载也能复现。

另一种更偷懒但同样有效的方法：复现实验统一用num_workers=0。数据规模不大时性能差异完全可以接受，省去一堆多进程的破事。

4.3 训练循环里反复调seed，结果反而更随机

这是我见过最隐蔽的坑。有些同学看到每个epoch的loss波动很大，就想“那我每个epoch都重新设一次seed，强制它固定下来”。结果训练出来的模型不仅没有更稳定，反而更差了。

原因在于，反复调用torch.manual_seed()会让随机数生成器不断回到同一个起点，DataLoader每个epoch的batch顺序完全一样，Dropout每次丢掉的神经元也完全一样。模型相当于在同一个固定的数据顺序上反复打磨，泛化能力反而被削弱了。正确做法是：整个训练过程只设一次种子，然后让随机数生成器按自己的节奏走完。

4.4 哈希、路径、时间戳这些“动态种子”是大坑

偶尔有人觉得每次都设同一个种子太死板，于是用当前时间做种子，或者用文件路径哈希做种子，美其名曰“增加随机性”。这种做法的直接后果就是实验结果完全无法复现，而且出了bug也完全无法回滚。

如果确实需要多样化的实验，我建议用固定基础种子+递增编号的方式。比如跑5次消融实验，就用seed=100+exp_id，既保证了实验间的差异性，又能从日志里精准定位每次实验的种子值。这种方式比用时间戳当种子要规范得多。

4.5 不同框架混用，种子会互相覆盖

有些项目同时用了PyTorch和TensorFlow，或者一边用NumPy老接口一边用新接口。这种情况最容易出现“我明明设了seed，结果还是不一样”的诡异问题，因为两个框架都拿到一样的种子，但它们内部会各自维护独立的随机状态，互不影响本来没问题，怕的是第三方库在import时也初始化了自己的随机状态，把你的全局状态覆盖了。

我的排查经验是：在关键节点打印随机状态来验证。比如在数据加载前打印一个随机数，模型初始化后再打印一个，看看两次运行时是否一致：

python复制print("加载数据前 random:", random.random())
print("加载数据前 numpy:", np.random.rand())
print("加载数据前 torch:", torch.rand(3))

每一步都能对上，说明随机源是真的锁死了；如果某一步开始对不上，就往对应环节去找问题。

5. 不只是复现：随机数种子在实验设计里的正确用法

5.1 做算法对比时，固定种子是基本底线

很多同学写论文或者做技术方案对比时，只跑一遍模型，然后拿着一个数字说“我的方法比baseline高2%”。这其实是站不住脚的。正确的做法是：固定同一组种子，让所有对比方法在完全相同的随机序列下跑，然后再比较结果。

比如你想对比两个优化器的效果，那就在[42, 2024, 7, 8888, 666]这5个种子上分别跑，最后报告平均值和标准差。这样既不受单次运气影响，又能保证每个算法都经历了相同的数据顺序和数据增强，对比才公平。

5.2 固定种子不等于固定一切：这些场景要保留随机性

固定种子解决的是“可复现性”问题，但有些场景刻意保留随机性是更好的设计。

第一，超参搜索。不管是随机搜索还是贝叶斯优化，每一步实验都应该用不同种子，否则多次搜索会陷入同一个局部区域，搜索效率极低。

第二，强化学习。RL的环境、策略初始化、探索过程都高度依赖随机性，只用单一种子评估一个RL算法非常危险，经常会出现“这个种子下表现好，换一个种子就崩了”的情况。业界通行做法是至少用10个以上种子跑完整实验，报告中给出均值±方差。

第三，线上推理。生产环境里的模型推理一般不需要固定种子，反而是希望每次预测的随机性与训练阶段保持一致，这样才能让模型在真实场景里发挥预期效果。

5.3 我的实验日志模板

最后分享一个我一直在用的实验日志模板，每次跑严格实验都会先填这张表：

有这张表，哪怕实验跑了三个月再回来看，也能轻松定位问题出在哪一步。

5.4 从“能复现”到“方便地复现”：把种子做成配置参数

临时脚本里写死seed=42没问题，但项目做大之后，我建议把种子做成命令行参数或者配置文件里的一个字段，而不是硬编码在代码里。这样每次实验的种子值会跟着配置文件一起归档，不会被无意间改动。

python复制import argparse
parser = argparse.ArgumentParser()
parser.add_argument("--seed", type=int, default=42)
args = parser.parse_args()
set_all_seeds(args.seed)

再加上权重文件和训练日志都带上seed标记，比如model_seed42_epoch5.pt、log_seed42.txt。仪式感虽然强了点，但真正找问题的时候，你会发现这个习惯能救大命。

我个人实际做项目时的习惯是，每个新实验一开始就创建一套标准的set_all_seeds函数和日志模板，再在代码里插入随机状态检查点。这个过程多花十分钟，但能帮你省下后面排查“为什么结果复现不了”的好几天时间。

最后再分享一个小技巧：如果你在论文或者技术报告中写“所有实验基于seed=42”，最好把固定种子这段代码放到附录里，超链接到在线代码仓库。因为审稿人或者合作者拿到论文后，第一件事就是会试着复现你的结果。你能提供一套完整的、经过验证的复现方案，信任感会提升非常多。随机种子这件事，表面上是为了让实验“可复现”，更深层的意义是让每一次实验决策都变得可追溯、可辩护。