3、常见批次不一致问题类型

调试 LFQ 算法，最让我头疼的就是批次不一致。说白了，就是同样的代码，换个批次跑，结果不一样。明明没改模型结构，没换数据集，可推理出来的 logits 就是对不上。我当初刚接手 LFQ 时，被这种问题折磨了不少日子。后来摸清了门道，其实大多都能归类到下面几个类型里。

3.1 输入数据差异

这是最容易被忽视的一类。我遇到过不止一次，两个批次明明用的同一个数据集，但 shuffle 后的顺序不一样，导致 LFQ 的 token 序列构建出现细微偏差。你想想看，LFQ 对输入顺序是敏感的——一旦输入数据的排列不同，后面的因果掩码计算路径就可能产生微小误差，累积起来 logits 就对不上了。

• 文件列表顺序：不同机器上 os.listdir 的返回顺序不一定相同。我习惯在数据加载时显式排序，或者固定一个 shuffle 种子。
• 数据增强随机性：如果每个批次独立调用 augmentation pipeline，没有锁种子，那么增强后的图像/文本会有差异。我曾经因此在两个 GPU 卡上测出了 0.5% 的精度偏差。
• padding 策略：动态 batch 时，padding 到相同长度可能因为 batch 内样本排列不同导致 mask 不一样。记得检查 tokenizer 的 padding side 是否一致。

3.2 模型权重差异

这个问题不难理解——模型压根没加载同一个 checkpoint。但实际场景中往往更隐蔽。举个例子，我调试过一个 LFQ 模型，训练时保存的 checkpoint 里包含了优化器状态，而推理时只用 weight，却在不同 batch 里误用了不同的保存副本。

• 权重路径不一致：A 批次加载了 model_epoch10.pt，B 批次加载了 model_best.pt。这可能是脚本中硬编码路径导致的。
• 权重转换精度：如果某个批次作了 FP16 转 FP32，而另一个没转，低比特量化带来的截断误差在 LFQ 的 softmax 层会被放大。我建议在加载后统一打印 model.state_dict().keys() 和每个 key 的 dtype 来比对。
• EMA 与原始权重混淆：有的代码里同时维护了 ema 和 raw 权重，加载时很容易弄混。我曾经在一次框架升级后，误将 ema 权重当作原始权重加载，导致两个批次产生约 0.3% 的 logit 差异。

# 检查权重一致性（Python 代码示意）
import torch
ckpt_a = torch.load("checkpoint_batchA.pt", map_location="cpu")
ckpt_b = torch.load("checkpoint_batchB.pt", map_location="cpu")
for key in ckpt_a["model"].keys():
    if not torch.equal(ckpt_a["model"][key], ckpt_b["model"][key]):
        print(f"差异发现于: {key}")

3.3 环境依赖差异

环境问题是最难定位的，因为差异往往不在你的控制范围内。我印象很深的一次，同一个 docker 镜像，一个跑在 V100 上，一个跑在 A100 上，LFQ 的注意力计算出现了完全不同的数值结果。

• CUDA 和 cuDNN 版本：不同 GPU 架构对卷积和矩阵乘法的实现有细微差异。即使是同一个 CUDA 版本，不同 sm 版本的算子融合策略也不同。
• PyTorch 或 TensorFlow 版本：我建议两个批次使用完全相同的 Python 环境，包括 patch 版本。曾经因为 PyTorch 1.12 和 1.13 的 torch.topk 实现调整，导致 LFQ codebook 选择不一致。
• 第三方库依赖：比如 transformers、accelerate 的版本差异，可能改变 tokenizer 的分词结果或模型的 forward hook 行为。

import torch, sys, transformers, accelerate
print(f"Python: {sys.version}")
print(f"PyTorch: {torch.__version__}")
print(f"CUDA available: {torch.cuda.is_available()}")
print(f"CUDA version: {torch.version.cuda}")
print(f"Transformers: {transformers.__version__}")
print(f"Accelerate: {accelerate.__version__}")

3.4 随机性控制差异

嗯，这里要注意。LFQ 内部用到了大量随机操作——codebook 初始化、采样时的 top-k 筛选、dropout 等。如果随机种子没锁死，两次推理结果自然不一样。

• 种子未全局固定：只固定了 torch.manual_seed，却没固定 numpy.random.seed 和 Python 的 random.seed。这三个层面都要锁。
• Dataloader worker 随机：如果你使用多进程数据加载，每个 worker 的随机种子需要额外设置。我一般会设置 worker_init_fn 来确保每个 worker 的种子随主种子变化。
• Torch 的确定性模式：即使锁了种子，某些 CUDA 核函数仍然是确定性不明的。可以开启 torch.backends.cudnn.deterministic = True，但要注意这样会损失一些性能。

# 推荐在 LFQ 调试时使用以下固定设置
import torch, numpy as np, random

seed = 42
torch.manual_seed(seed)
torch.cuda.manual_seed_all(seed)
np.random.seed(seed)
random.seed(seed)

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

3.5 综合对比表

下面这张表我经常贴在工位上，调试时扫一眼就知道该查哪个方向。

表格里的概率是我个人统计的，不一定精确，但方向值得参考。遇到批次不一致，我会按照“数据 → 权重 → 环境 → 随机”的顺序逐一排查。大部分情况下，走到第二步就能找到问题。