几乎所有 OOM，都是“我以为还能再加一点”
如果你做过大模型微调，你一定经历过这种时刻：
- batch size 调小一点 → 能跑
- sequence length 加一点 → 还能跑
- 两个一起微调 → 显存直接炸
你看着监控面板，心里非常困惑：
“不对啊，我是算过的。”
这正是问题的关键。
你算的，是线性的；
而显存消耗，从来不是。
工程师心里计算的显存 vs 实际显存曲线对比
一个必须先说清楚的结论
在正式展开之前，我先把这篇文章最重要的一句话写出来：
batch size 和 sequence length，
不是两个独立的显存旋钮，
而是一个相互放大的乘法因子。
如果你还在用：
- “batch 翻倍，显存翻倍”
- “长度翻倍，显存翻倍”
这样的直觉来理解显存，
那你几乎一定会被 OOM 教育。
第一层误解：把显存消耗理解成“参数规模问题”
很多人一说显存，第一反应是：
- 模型多大
- 参数多少
- 是不是该用 LoRA / QLoRA
这些当然重要，
但它们只决定了显存的底座。
真正让你在训练时反复爆显存的，往往不是参数，而是：
中间态（activations）。
而 batch size 和 sequence length，
正是中间态的最大放大器。
第二层：为什么 sequence length 比你想象中“更贵”
很多人会觉得：
“sequence length 只是多几个 token，
显存应该线性增加吧？”
这是一个非常危险的直觉。
一个必须面对的事实
在 Transformer 里，sequence length 影响的不只是：
- embedding
- attention 输入
而是：
- attention score
- KV cache
- 每一层的中间激活
尤其是 self-attention，
它的计算和存储复杂度是：
O(L²)
也就是说：
- length 从 1024 → 2048
- token 数翻倍
- attention 相关显存，可能直接 ×4
这就是为什么你“只是把 max_length 调大了一点”，
显存却突然不讲道理。
sequence length ↑ → attention 显存平方增长
第三层：batch size 为什么会“乘上” sequence length
单看 batch size，好像也很直观：
- batch ×2 → 数据 ×2
但问题在于：
batch size 决定的是：
同一时间，有多少条序列在走完整前向和反向。
于是显存里同时存在的，是：
batch_size × sequence_length × hidden_dim × layer_count
这不是加法，是堆叠。
当你把 batch size 和 sequence length 同时往上拉时，
你做的事情其实是：
让显存同时承载更多、更长、而且还没释放的中间态。
第四层：非线性真正出现的地方——反向传播
如果只是前向，其实很多时候还能勉强扛住。
真正让显存爆炸的，是：
反向传播阶段。
原因很简单：
- 前向：可以边算边丢
- 反向：必须留住中间态
这意味着：
- batch 越大 → 需要保留的中间结果越多
- length 越长 → 每一层要保存的激活越重
于是显存曲线会出现一个非常典型的形态：
前向看着还行，
反向直接炸。
前向 vs 反向 显存占用对比
第五层：为什么“只加一点点”，却跨过了临界点
这是最让人崩溃的地方。
你可能经历过：
- batch=2，length=2048，OK
- batch=3，length=2048，OOM
你会觉得：
“就多了一条样本，怎么就炸了？”
原因在于：
显存不是连续可用的，
而是存在碎片和临界点的。
当你跨过某个阈值：
- CUDA 需要分配一整块新的 buffer
- allocator 找不到足够连续空间
- 于是直接失败
这就是为什么：
显存不是“慢慢用完”的，
而是“突然不够用”的。
第六层：梯度累积，为什么没你想得那么“省”
很多人会说：
“batch 太大？那我用 gradient accumulation。”
这确实能缓解一部分问题，
但它并不是免费午餐。
因为：
- accumulation 并不会减少单步的 activation 显存
- 它只是减少了一次 forward/backward 中的 batch
如果你的 OOM 来自：
- sequence length 太长
- attention 中间态太重
那梯度累积几乎救不了你。
这也是为什么有些人会困惑：
“我 batch 已经很小了，为什么还 OOM？”
答案往往是：
真正压垮显存的，是 length，不是 batch。
第七层：评估阶段为什么反而更容易炸显存
这是一个很多人没想到的坑。
在评估时，你可能会：
- 关掉 dropout
- 不算 loss
- 以为显存会更省
但实际情况是：
- 推理 batch 往往更大
- sequence length 往往更长
- KV cache 占用持续存在
于是你会看到：
训练能跑，评估反而 OOM。
这不是 bug，
而是你在评估阶段：
把 batch × length 推到了另一个非线性区域。
一个非常真实的“显存误判路径”
我算过参数显存 → 应该够
我减过 batch → 应该稳
我只加了点 length → 应该没事
OOM
注意：
每一步判断，单独看都“合理”。
错的是：
你在用线性思维，面对非线性系统。
那工程上该怎么“正确理解” batch 和 length？
不是给你一个公式，
而是给你一个更安全的判断方式：
sequence length 决定了“单样本的重量”，
batch size 决定了“同时搬多少个”。
当你不知道哪里该省的时候，优先问：
- 单条样本，是不是太重了？
- attention 的 L² 是否已经不可接受？
很多时候：
减 length，比减 batch 更有效。
一个非常实用的显存自检问题
在你准备调 batch 或 length 之前，可以问自己一句话：
如果显存炸了，
我更希望模型“少看几条”，
还是“每条看短一点”？
如果你无法回答，
说明你对当前显存结构还不够清楚。
很多团队在 batch size 和 sequence length 上反复试探显存上限，本质问题不是参数没算清，而是缺乏对“中间态显存结构”的直观感知。用LLaMA-Factory online观察不同 batch / length 配置下的训练行为，更容易理解：是哪一部分在非线性放大，而不是盲目试错。
总结：显存不是被“用完”的，而是被“触发”的
我用一句话，把这篇文章彻底收住：
batch size 和 sequence length
并不是慢慢吃掉显存的，
而是在某个点上，
一起把你推下悬崖。
当你开始：
- 把显存理解成结构问题
- 把 length 当成一等公民
- 放弃“线性估算”的安全感
你才真正开始工程化地调显存。
