32GB显卡跑LoRA微调：显存计算与OOM排查实战手册

LoRA 微调现在已经成了大模型定制的默认选项但我这两年帮人调训练脚本听到最多的反倒不是“LoRA 怎么配”而是“我这卡到底够不够跑”。尤其当手里是一张 32GB 显存的 GPU比如 RTX 4090 或者 A6000大家会在 7B、13B、甚至 30B 模型之间反复横跳最后因为一次 OOM 就劝退。这篇文章我打算把显存这笔账彻底算明白——LoRA 微调时显存到底花在哪几块32GB 卡怎么配置最稳以及训练中遇到 OOM、Loss 不降、速度奇慢时该怎么排查。内容适合刚要入门的同学也适合已经在跑微调但经常被显存问题折腾的老手当个排查手册用。1. LoRA 微调时显存花在哪别把注意力全放在模型权重上很多人的显存估算思路是“模型多大显存就要多大”这在推理场景勉强成立但训练场景完全不是这套算法。LoRA 微调的本质是冻结原始模型权重只训练注入的小规模低秩矩阵所以你真正需要算的账远比“模型参数总量 × 精度字节数”要复杂。我把这账拆成四块基础模型权重、可训练参数带来的梯度和优化器状态、前向计算产生的激活值、以及 CUDA 上下文和计算库临时分配。1.1 基础模型权重LoRA 省的就是这一块基础模型权重的显存占用取决于你用的是什么精度加载。全量 FP16/BF16 加载时每个十亿参数大约占 2GB 显存如果是 INT8 量化加载大约 1GB 每十亿参数QLoRA 常用的 4bit NF4 量化加载大约 0.6GB 每十亿参数。所以一个 7B 模型BF16 全量加载是 14GB4bit 加载可能只有 4GB 左右。这就是很多人为什么用 QLoRA 技术在 8GB 显卡上也能跑 7B 甚至 13B 模型微调的原因模型权重这一块的显存被压到了极低。1.2 激活值和 KV Cache真正的显存刺客如果只看模型权重你觉得 14GB 也没啥32GB 卡跑 7B 全量微调都够。但你实际一跑就发现爆了问题往往出在激活值上。训练和推理不一样推理是一遍前向算出结果就完事训练为了反向传播必须把每一层每一 batch 的中间计算结果都保留下来。这个占用和模型层数、隐藏维度、序列长度、batch size 都成正比尤其是序列变长之后自注意力部分要存 attention 矩阵理论空间复杂度随序列长度平方增长。说句扎心的话我见过很多人拿 7B 模型在 32GB 卡上全量微调seq_length 拉到 4096batch size 设成 4结果模型权重才占 14GB激活值和其他临时缓存却逼近 25GB最后照样 OOM。这也是 LoRA 在显存和训练成本上的真正价值它让可训练参数大幅减少于是你不需要给全部参数保留梯度和优化器状态把显存预算大头留给了激活值。1.3 梯度和优化器状态LoRA 地盘的数学账LoRA 微调时只有注入的 LoRA 矩阵参与梯度计算但优化器仍然要维护这些可训练参数的动量等状态。如果你用 AdamW每个参数通常要存两份优化器状态加一份梯度按 FP32 算就是 4 字节 × 3。假设一个 7B 模型你 LoRA 化了全部 attention 层和 MLP 层可训练参数约占总参数量 0.1% 到 0.5%也就是 7M 到 35M 个参数那优化器状态顶多几百 MB。听着很少吧确实少这也是 LoRA 的优势之一——但要注意如果你手滑把requires_gradTrue放到了全部模型参数上或者用 LoRA 时没冻结 base model那这笔账瞬间会按全量微调计算56GB 起跳32GB 卡必炸。注意微调中真正决定你显存够不够的往往不是 LoRA 层而是激活值和训练策略。模型权重和优化器状态反而相对可控。2. 显存估算公式与快速算账方法既然知道显存花在哪接下来就能算账了。我平时用的是一套粗粒度预算方法不追求精确值但能在跑训练前把“会不会 OOM”判断个八九不离十。2.1 一套能用的“显存预算公式”我习惯把训练时的显存占用写成这样总占用 ≈ 模型权重显存 可训练参数显存含梯度与优化器状态 前向激活显存 临时计算缓存 CUDA上下文其中模型权重只要按加载精度乘参数量就行加载方式每十亿参数显存占用FP32约 4GBBF16 / FP16约 2GBINT8约 1GB4bit NF4QLoRA约 0.6GB可训练参数显存对 LoRA 而言取决于实际可训练参数量。公式是可训练参数显存 ≈ LoRA参数量 × 字节数注意这里有个容易混淆的点梯度本身不管你要不要只要参与反向传播就会计算所以你可以按“每参数字节数 × 3”来粗算参数权重、梯度、优化器状态也可以更保守地按 4 字节 × 3 来算。实际上很多框架会用混合精度处理BF16 梯度加上 FP32 优化器状态总字节数会略小于这个值。2.2 激活值的“玄学”估算激活显存是最难精确算的但经验上有几个规律同等精度和模型参数量下激活显存大约是模型权重显存的三分之一到一半而且这个比例会随着序列长度增加而快速膨胀。如果开了 gradient checkpointing激活显存通常能压缩一半以上但会多花约 20%-30% 的训练时间这是个典型的时间换空间选择。至于临时计算缓存和 CUDA 上下文我一般直接预留 2GB 到 4GB。CUDA 环境启动、cuBLAS 的 kernel launch、torch 的缓存分配器都会在显存里占一块地方这部分你平时用nvidia-smi看到的“小几 GB 占用”就是这么来的。2.3 7B 模型在 32GB 卡上的粗算实例举个例子假设你要用 QLoRA 微调 Qwen2.5-7B。4bit 加载模型权重约 4.5GBLoRA 可训练参数假设是 20MAdamW 优化器状态按每参数 12 字节算也就是 0.24GB几乎可以忽略。接着是激活值如果你设了per_device_train_batch_size1、max_seq_length2048、开 gradient checkpointing我实测激活加临时缓存大概在 8GB 到 12GB。全部加起来大概 15GB 到 18GB 波动。所以这块 32GB 卡跑 7B 是绰绰有余的。但如果你贪心一点batch size 调到 4max_seq_length 拉到 4096又没开 gradient checkpointing激活值会从 8GB 飚到 25GB 以上这时候 32GB 卡就开始告急。很多 OOM 事故不是算力不够而是“算账时只算了模型权重没算激活值”。3. 32GB GPU 上的具体训练配置从环境到超参数知道了“预算线”在哪就可以放心操练了。这一节我给出一套在 32GB 显卡上实测过很稳的训练配置并解释每个关键选择的理由。3.1 硬件与基础环境准备32GB 常见卡有三种RTX 4090、RTX 6000 Ada、A6000。这三张卡跑 LoRA 都够但要注意 4090 是消费级卡散热和持续稳定性在长时间训练时不如专业卡机箱风道不好容易掉驱动。基础软件环境我一般这么搭CUDA Toolkit 12.x 以上配对应版本的 PyTorch2.1建议 2.3 之后对 flash attention 支持更好transformers、peft、bitsandbytes、accelerate、datasets训练框架可以用原生 PyTorch 配accelerate也可以用 TRL个人小项目用transformers的Trainer最省事装完环境先跑一段import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0)) print(torch.__version__)能正常打印出显卡名字就算过了环境关。3.2 用 QLoRA 把模型加载显存压到最低模型加载我强烈建议直接上 4bit 量化加载配合 QLoRA 方案。在 7B-13B 规模上4bit 加载的精度损失完全可接受而且 LoRA 微调本身就是对这部分量化误差做一定程度的修正。具体写法from transformers import AutoModelForCausalLM, AutoTokenizer import torch model AutoModelForCausalLM.from_pretrained( Qwen/Qwen2.5-7B-Instruct, load_in_4bitTrue, bnb_4bit_quant_typenf4, bnb_4bit_use_double_quantTrue, bnb_4bit_compute_dtypetorch.bfloat16, device_mapauto, )这里bnb_4bit_use_double_quantTrue是嵌套量化省一点显存compute_dtype用 bf16 是为了训练中计算的稳定性避免 fp16 在部分数值范围溢出。要特别提醒一句device_mapauto在多卡环境下会把层自动分配到多张卡上如果后续要做 LoRA 训练建议显式指定到一张卡或者用max_memory限制否则 Trainer 在判断模型并行时可能出幺蛾子。3.3 Peft 与 TrainingArguments 的可抄作业配置模型加载完下一步是注入 LoRA 层和准备训练参数。下面这套配置在 A6000 上跑 Qwen2.5-7B 很稳显存占用大概 16GB 左右留出了不少余量from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training model prepare_model_for_kbit_training(model) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) model get_peft_model(model, lora_config) model.config.use_cache False model.config.gradient_checkpointing True model.print_trainable_parameters()几个细节解释一下。use_cache False在训练中必须关掉因为训练根本不需要 KV Cache留着只会占显存拖速度。gradient_checkpointing True是这个配置的核心等于用少量计算时间换回几个 GB 显存。我测试过开了这个之后Qwen2.5-7B、seq 2048、batch size 1训练时显存从 22GB 掉到 15GB 左右性价比极高。训练参数建议如下from transformers import TrainingArguments training_args TrainingArguments( per_device_train_batch_size1, gradient_accumulation_steps8, learning_rate2e-4, bf16True, optimadamw_8bit, logging_steps10, save_steps100, num_train_epochs3, gradient_checkpointingTrue, max_grad_norm1.0, output_dir./lora_out, )为什么per_device_train_batch_size1配合gradient_accumulation_steps8很多人不理解。显存瓶颈在激活值batch size 每翻倍激活显存几乎翻倍而梯度累积只是把多个小 batch 的梯度攒起来再更新一次效果上和“大 batch”近似但显存占用不会叠加。所以 32GB 卡上宁可 batch size 小一点、梯度累积多一点也别去赌大 batch。在 7B 模型上batch1 再加累积基本稳跑如果模型是 13B 或者序列长度要求长可以把累积加到 16效果一样。3.4 训练中显存占用怎么看开训之后建议另开一个终端实时盯显存watch -n 1 nvidia-smi或者用nvidia-smi -l 1在写代码时如果你想在日志里输出显存信息可以这样import torch print(torch.cuda.memory_summary(deviceNone, abbreviatedTrue))这个会输出当前 PyTorch 缓存分配器的详细情况能看出哪些显存是模型占的、哪些是激活值占的、哪些只是 torch 的缓存池没有释放。还有个偏方是设环境变量让 PyTorch 的显存分配更灵活export PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True这个设置适合显存碎片化严重、总占用不高却 OOM 的诡异情况实测对 OOM 有一定缓解作用。4. 常见问题排查OOM、Loss 不降、速度慢、精度异常训练过程中会碰到的问题翻来覆去就那么几类。我把这一年里踩过的坑和排查顺序都列出来。4.1 CUDA OOM 的排查顺序OOM 是最常见的报错。看到CUDA out of memory先别慌按这四步走确认爆掉的是哪部分看报错日志里的try to allocate ... MiB如果在加载模型阶段就爆说明是模型量化精度不够低或模型本身太大32GB 跑 70B 的 4bit 量化本来就勉强能跑但很危险建议先用 13B 模型试。如果是训练开始几秒后爆优先检查per_device_train_batch_size和max_seq_length。我见过有人把 seq_length 直接设成 8192结果激活值吃到 30GB当然爆。确认是否真的开了gradient_checkpointing。配置项有两处容易忘TrainingArguments里要设model.config里也要设且调用完get_peft_model之后最好再设一次因为 PEFT 包模型后 config 可能被重建。最后用model.print_trainable_parameters()确认可训练参数占比。如果打印出来的是 100%说明你的模型没有被冻结LoRA 微调已经变成全参微调32GB 卡跑 7B 全参基本是撞墙。4.2 Loss 不降、NaN 和梯度爆炸Loss 不降最常见的误区是把 LoRA 当“万能药”。LoRA 能降低显存和优化器状态开销但它不会自动提升模型的拟合上限。如果你数据集质量差、answer 模板混乱或者 LoRA 层只加在了q_proj和v_proj上在某些任务上可训练容量不够loss 就是降不下去。我自己调 ad-hoc 数据集时第一反应不是调参而是先用一个小数据集跑几百步看 loss 能不能降到接近 0如果小数据都过拟合不了说明配置或数据有问题再大训练集也救不回来。NaN 问题则要分情况。BF16 训练下偶发 NaN 往往与学习率太高或max_grad_norm没限制有关。LoRA 的典型学习率区间是 1e-4 到 3e-4如果你用了 1e-3 甚至更高loss 很容易冲飞。调整思路先把learning_rate降到 1e-4把max_grad_norm设为 1.0然后把bf16True确认打开不是 fp16。BF16 的指数范围和 FP16 不同在强数值波动下更不容易溢出这点对 QLoRA 尤其重要。4.3 训练速度慢、GPU 利用率低有些人的 32GB 卡跑 LoRA显存还剩一半但训练速度就是上不去。这种情况通常不是卡不行而是 GPU 在“空转”。最常见的原因是 tokenizer 和数据处理速度太慢。如果你的数据是磁盘上几万条 JSON每次训练前实时分词而没有提前 tokenize 缓存GPU 会一直等 CPUnvidia-smi看到的利用率就会出现周期性跳到个位数。解决办法是把数据集预先处理成 token ids 的二进制缓存save_to_disk读进去就是 tensor。其次是序列长度和矩阵计算效率的问题。LoRA 微调 7B 模型如果max_seq_length512GPU 的并行度上不去大模型的小 round 会被损耗占满。实测里同样数据量seq 2048 比 seq 512 的吞吐量反而更高因为 GPU 单次计算的规模更饱和。如果你任务确实只需要短文本可以考虑把per_device_train_batch_size往上调把并行度补回来。第三个问题是训练时开了use_cacheTrue。有些框架默认把这个打开了推理是省了算力训练却白占显存。你可以在 training args 里临时加一句model.config.use_cache False4.4 其他杂项问题量化加载与混合精度QLoRA 偶尔会遇到加载后模型输出全是乱码或 loss 很高的情况。这是 4bit 量化 LLM.int8 或 NF4 在部分 CUDA 版本下与 bf16 计算不兼容导致的。排查时先用朴素加载bf16不量化跑一次同样数据如果 loss 正常那再去bitsandbytes的版本兼容性表里对一下 transformers 版本。我常用的组合是 transformers 4.40、bitsandbytes 0.43、PyTorch 2.1三个月没出过兼容问题。如果还不行就手动指定model AutoModelForCausalLM.from_pretrained( ..., bnb_4bit_compute_dtypetorch.float16, )把计算精度从 bf16 换到 fp16虽然数值稳定性略差但兼容性更广。另外还有一个反直觉的坑理论上 4bit 量化后模型权重只占 4.5GB但nvidia-smi看到的占用却可能高达 10GB。这不一定是 bug很可能是 PyTorch 的缓存分配器把之前用过的显存碎片留在进程里并不代表真实需要。判断方法是看torch.cuda.memory_summary()里的 “allocated” 和 “reserved” 字段实际分配远小于保留显存的话不用管它。5. 从 32GB 卡扩展到其他显存大小预算思维迁移标题是 32GB 卡但我猜不少读者会想我只有 8GB 或 12GB 卡能跑吗能不能用同样方法估算能而且思路完全一样只是要把显存预算进一步压紧。8GB 显存跑 7B 模型 QLoRA模型权重 4.5GB可训练参数和优化器状态 0.5GB剩余 3GB 给激活值。这种情况下只能做三件事把max_seq_length压到 512 或 1024per_device_train_batch_size保持 1把梯度累积提到 16同时打开 gradient checkpointing。勉强能跑但训练速度会让你难受。如果 8GB 卡上尝试 13B 模型我建议直接放弃因为 4bit 加载 13B 就要 8GB 左右留给激活值的空间几乎为零。反过来如果你有 64GB 甚至 80GB 卡也别把 LoRA 那套直接照搬可以考虑更大 rank比如 r64或更多 module 加 LoRA甚至对较小模型做全量微调。显存预算的思路不变只是“底气”更足了。我自己的习惯是显存越大越应该优先加大 batch size 或序列长度而不是盲目增大 LoRA rank。batch size 和序列长度直接影响训练质量和吞吐量LoRA rank 到 32 之后收益就边际递减了。实操心得租卡之前先用上面那套粗算公式算一遍在本地拿小模型跑通流程再上大卡。云 GPU 按小时计费调试阶段全在远程卡上摸爬滚打既浪费时间也浪费钱。我其实特别理解“看到有 32GB 卡就想跑大模型”的心情但 LoRA 微调的尽头往往不是显存而是数据工程。显存估计这件事本质上就是花五分钟把预算算清楚把 batch size、序列长度、gradient checkpointing 这三个旋钮转到位剩下的大多数问题都是配置和习惯问题。调试中我建议你把model.print_trainable_parameters()和torch.cuda.memory_summary()的输出留在日志里每次训练都扫一眼——这两个输出比任何显存预测工具都靠谱能直接告诉你“哪里花多了、哪里还省得住”。后边遇到问题先从这两个数据入手定位基本不会走弯路。