手里有一张 32GB 显存的卡无论是 RTX 4090 还是 A6000很多人第一反应是7B 模型的 LoRA 微调肯定随便跑。结果真把训练脚本搭起来batch size 调到 4序列长度拉到 2048没几步就 CUDA out of memory。我见过不少人在这一步直接放弃或者转身去租贵得多的 80GB 卡。实际上32GB 的 GPU 完全能胜任 7B 级别甚至 14B 量级模型的 LoRA 微调问题不是卡不够用而是你没搞清楚显存到底被谁吃掉了也不知道怎么估算训练峰值。这篇文章我想把这些年配训练环境的经验整理一下LoRA 微调到底省了什么、没省什么32GB GPU 上哪些模型能跑、参数怎么配以及报 OOM 之后按什么顺序排查最有效。1. 显存四巨头与 LoRA 的省显存真相先弄明白钱花在哪1.1 训练显存的四笔开销很多教程一上来就丢命令但从不解释显存被谁吃了。等你爆一次 OOM才明白该补这块知识。训练时显存占用大致可以分成四块模型权重、优化器状态、梯度、激活值中间状态。模型权重最简单就是当前参数占用的空间。推理时也要占只是训练时可能还需要额外副本。优化器状态是 Adams 这类自适应优化器的专属开销它要维护每个可训练参数的动量、方差和主权重副本。梯度是反向传播算出来的用来更新参数。最后是激活值前向传播过程中每一层的中间输出都要暂存反向传播还要拿它们算梯度这块是训练和推理差距最大的原因。用生活化的比喻模型权重是书架上的书本身优化器状态是你在书上贴的便利贴和笔记梯度是每次读书后临时写下的心得激活值则是读书过程中摊开在桌上的一堆参考资料。书本身不贵但参考资料越堆越多桌子就炸了。1.2 LoRA 能把训练显存压下来的真正原因LoRA 全称 Low-Rank Adaptation中文叫低秩适配。它的思路不是像全参微调那样去更新所有原始权重而是把原始权重冻结在旁边插入两个小的低秩矩阵让这两个小矩阵去学增量。更新完再把增量合并回原始权重。这里有个关键点LoRA 省的主要是优化器状态和梯度空间而不是模型权重本身。全参微调 7B 模型时AdamW 要给每个参数维护 fp32 的动量、方差和主权重副本每个参数大约 12 字节7B 参数就是 84GB 以上光这一项 32GB 的卡就吃不消。而 LoRA 让可训练参数骤降到几千万级别优化器状态从几十 GB 降到几百 MB这才是它能跑的低显存的核心原因。有个很常见的误解以为 LoRA 省显存是因为冻结了基座所以基座不用加载。不对。冻结的基座权重照样完整加载到显存里bf16 精度下 7B 模型大约占 15GB一分都不会少。LoRA 只是让你不需要为这 7B 参数额外准备梯度和优化器状态。1.3 三个新手最容易踩的认知误区误区一加了 LoRA 之后显存占用应该比纯推理高不了多少。实际上训练时的激活值开销远大于推理即使 LoRA 参数很少反向传播要保存的中间张量也很多。我用同样的 7B 模型做过对比推理峰值大概 16GB训练峰值轻松到 23GB差距就在这里。误区二梯度累积能省显存。很多人看教程说显存不够就把 gradient_accumulation_steps 调大以为显存占用会成倍下降。梯度累积只是在轮到更新前多攒几次梯度它改变的是更新频率不是前向反向的瞬时峰值。换句话说batch size 该多大还是多大峰值显存一点不变。它解决的是小 batch 导致训练不稳定和 BN 统计偏差的问题不解决 OOM。误区三GGUF、NF4 这种量化格式的显存要求可以直接用来估训练。GGUF 是推理格式NF4 是 bitsandbytes 的 4bit 量化这类格式能跑推理不代表能直接跑训练。因为反向传播需要梯度量化权重在做反向传播时要么反量化回高精度要么走自定义 kernel显存行为完全不同。2. 从公式到账单手把手估算 7B LoRA 的显存2.1 一条足够好用的估算公式显存估算不需要精确到 MB够用就行。我给出一条经验公式训练峰值显存 ≈ 基座权重字节 LoRA 权重字节 LoRA 优化器字节 激活值峰值 CUDA context 和碎片冗余其中基座权重参数量 × 2 字节bf16 或 fp16如果是 fp32 则 × 4如果是 NF4 4bit 量化则约 × 0.5有额外的 block 管理开销实际略高。LoRA 权重可训练参数量 × 2 字节。LoRA 优化器状态可训练参数量 × 12 字节AdamW 的 fp32 主权重 4 字节、一阶矩 4 字节、二阶矩 4 字节。激活值最粗的估法取前几项的 20%-40% 作为余量但这非常粗更细的估法要看 batch size、序列长度、层数。CUDA context 和碎片冗余留 1-2GB 比较稳。这套公式是我实际排障时用的主框架把所有变量列出来再逐项核对比瞎调 batch size 有用得多。2.2 手算 Qwen2.5-7B43M 可训练参数是怎么来的拿 Qwen2.5-7B 举例。它的关键参数是 hidden_size3584层数 28intermediate_size18944总参数量约 7.6B。假设 target_modules 包含 q_proj、k_proj、v_proj、o_proj、gate_proj、up_proj、down_proj 这 7 个线性层LoRA 的秩 r16。每个线性层的 LoRA 参数量是 in_features×r r×out_features。于是q/k/v/o每层 4 个模块每个 3584×16×2114,688合计 458,752。gate/up每个 3584×16 16×18944360,448两个合计 720,896。down18944×16 16×3584360,448。每层合计 1,540,09628 层合计约 43.1M。43.1M 就是 LoRA 的可训练参数量占模型总量的 0.57% 左右。这个数字的意义是即使你训练时把可训练参数增加一倍比如 r32对显存的影响也只有几百 MB真正的大头始终是基座权重。接下来套公式基座 bf167.6B × 2 15.2GB。LoRA 权重43.1M × 2 ≈ 86MB。LoRA 优化器AdamW43.1M × 12 ≈ 517MB。激活值开 gradient checkpointingbatch4、seq1024 时大约 3-5GB不开的话可能到 10GB 以上。CUDA context 和冗余1-2GB。合计在 20-24GB 之间。32GB 的卡跑这个配置是稳的剩下来八九 GB 余量可以拿来调 batch size 或序列长度。2.3 不同规模模型的显存参考表我整理了一张表直接对照就能知道自己手里 32GB 卡能碰哪些模型。这里的 LoRA 训练显存估算是按 r16、开启 gradient checkpointing、batch1-4 的常见范围给出的。模型规模典型参数量bf16 推理峰值bf16 LoRA 训练估算32GB 卡是否可行1.5B1.8B约 4GB约 6-8GB非常轻松3B3.8B约 8GB约 11-14GB很轻松7B/8B7.6B约 16GB约 20-24GB推荐最舒服13B/14B14.7B约 29GB40GB 以上bf16必须上量化32B32.8B约 65GB无法直接训练必须量化才有戏这里要特别说明13B 级别的模型bf16 光推理就超过 29GB32GB 卡训练非常勉强所以实际做法是上 NF4 4bit 量化把权重压到约 7-8GB训练峰值控制在 25GB 左右这才跑得动。32B 更是如此。2.4 容易被忽略的激活值与 KV Cache激活值这块很多人不重视但实际爆显存大多都是因为它。激活值的大小和 batch size、序列长度、层数强相关序列长度通常比 batch size 影响更大因为 Transformer 的注意力矩阵是序列长度的平方级增长。举个例子同样一个 7B 模型batch1、seq512 时激活值可能 1-2GBbatch4、seq2048 时激活值可能直接冲到 8-12GB。这也是为什么训练长文本任务时经常出现batch 明明设得不大还是 OOM的情况。KV Cache 在推理时的显存也是一个道理7B 模型 seq2048 时 KV Cache 大约是推理权重的一半左右如果你之前用过这类模型的推理配置再往上加训练需要的激活值就能理解为什么训练显存是推理的 1.3-1.6 倍了。3. 32GB GPU 上的三种实在配置从 7B 直接训到 14B 量化3.1 方案 A7B bf16 直接训容错率最高我自己最推荐的 32GB 卡日常配置就是 7B/8B 模型 bf16 全精度微调。好处是精度没有损失调试简单出问题容易定位而且显存余量足够支撑 batch4、seq2048 这种实际任务。参数大致如下基座Qwen2.5-7B-Instruct 或 Llama-3-8Btorch_dtypetorch.bfloat16。LoRAr16 或 32alpha 取 r 的 2 倍target_modules 覆盖 attention 和 MLP。batch size4不够用 gradient_accumulation_steps8 补不影响峰值显存。序列长度2048如果输入真的很长就降到 1024。gradient_checkpointing必须开。FlashAttention 2能装就装节省显存还能加速。这个配置我测过多次峰值稳定在 21-24GB32GB 卡即便同时开 WSL、浏览器都没问题属于稳如老狗级别。3.2 方案 B14B NF4 量化 QLoRA薅干显存也要够大如果想要更高上限的模型能力比如从 7B 升到 14B32GB 卡就必须上 QLoRA。QLoRA 是 LoRA 和 4bit 量化的结合用 bitsandbytes 把基座权重做成 NF4 格式训练时反量化计算梯度。14B 级别 NF4 后权重约 7-8GB加上激活值和 KV Cache训练峰值大概落在 25-28GB32GB 卡能跑但余量不多。这时候一般限制 batch1 或 2序列长度控制在 1024-2048 之间同时开 gradient checkpointing。代价是量化带来的精度损失和训练速度下降而且梯度经过 4bit 反量化微调效果会比全精度 LoRA 轻微打折。但换来的模型能力上限提升非常明显比如同样写代码或处理领域知识14B 和 7B 不是一个量级。3.3 方案 C32B 到底能不能跑我说实话很多人问 32B 模型在 32GB 卡上能不能 QLoRA 训练。我的回答是能跑但属于自虐级配置不建议作为日常方案。32B 模型 NF4 量化后推理权重约 18-20GB训练时你再叠加激活值和优化器状态余量非常小batch 只能等于 1序列长度稍长一点就 OOM。如果不做 CPU offload24GB 卡基本没戏32GB 卡也只是勉强在边缘试探。训练速度也让人崩溃可能一个 step 要好几分钟跑一轮就得一天起步。我的判断是32GB 卡老老实实训 7B 是性价比最高、体验最舒服的区间14B 量化是进阶选择真想训 32B直接租 48GB 或 80GB 云端卡省下的时间比显卡租金值钱。3.4 一份可以直接跑的训练脚本参数用 transformers 和 PEFT 搭一个最小可用的训练配置我贴一段核心代码import torch from transformers import AutoModelForCausalLM, BitsAndBytesConfig, TrainingArguments, Trainer from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training # 方案 A7B bf16 model AutoModelForCausalLM.from_pretrained( Qwen/Qwen2.5-7B-Instruct, torch_dtypetorch.bfloat16, device_mapauto, ) # 方案 B14B NF4 量化注释掉上面启用这段 # bnb_config BitsAndBytesConfig( # load_in_4bitTrue, # bnb_4bit_quant_typenf4, # bnb_4bit_use_double_quantTrue, # bnb_4bit_compute_dtypetorch.bfloat16, # ) # model AutoModelForCausalLM.from_pretrained( # Qwen/Qwen2.5-14B-Instruct, # quantization_configbnb_config, # device_mapauto, # ) # 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.print_trainable_parameters() # 输出示例trainable params: 43,122,688 || all params: 7,643,239,040 || trainable%: 0.5642 training_args TrainingArguments( output_dir./lora_out, per_device_train_batch_size4, gradient_accumulation_steps8, gradient_checkpointingTrue, optimadamw_torch, bf16True, learning_rate2e-4, num_train_epochs3, logging_steps10, save_strategysteps, save_steps500, dataloader_num_workers4, )两个关键点一是 print_trainable_parameters 输出的可训练参数量必须是几千万级别而不是几十亿级别否则优化器状态会把显存吃穿二是 bf16True 是 32GB 卡的默认选择如果你的 GPU 是老架构不支持 bf16再退回到 fp16。4. OOM 排查链路从报错信息到根因的五步定位法4.1 先读懂 PyTorch 的 OOM 报错别被误导遇到 CUDA out of memory 时PyTorch 通常打印的是一长串分配回溯包括 Tried to allocate 512.00 MiB 之类的话。很多人看到 allocate 512MB 就以为还差 512MB 就能跑这是错的。PyTorch 的显存由缓存分配器管理显存早就被各种大小的 block 占满了OOM 只是它尝试分配一个新 block 时失败。所以报错里显示的分配大小跟你实际差多少显存没有直接关系。另外还有一种 OOM 是 illegal memory access 或者 CUDA error: device-side assert triggered这种往往不是显存容量不够而是代码层面的问题比如索引越界、shape 算错、loss 变成了 NaN优先检查数据而非显存。4.2 二分法试出临界点算出和账单的差距拿到 OOM 后我习惯按下面的流程定位把 batch size 降到 1序列长度降到 128开满 gradient checkpointing先跑通一个最小用例。如果最小用例还 OOM基本可以排除激活值因素问题在权重、优化器、CUDA context 层面。如果最小用例能跑再逐步把 batch size 翻倍、序列长度加长直到 OOM记录临界点。用 torch.cuda.max_memory_allocated() 把峰值显存打出来和公式估算比对看多出来的部分最可能是哪一项。这里有个很实用的做法在脚本里加一段监控代码训练结束后打印峰值print(torch.cuda.max_memory_allocated() / 1024**3, GB)如果峰值和 nsys 或 nvidia-smi 看到的实际占用有巨大差距多半是模型权重和 KV Cache 之类的非 PyTorch 分配项在捣乱或者有第二个进程共享了 GPU。4.3 常见伪 OOMoptimizer 把整个模型吃了这个坑我见得特别多尤其是自己写训练循环的人。LoRA 的核心是只训练低秩部分但如果你在循环里把 model.parameters() 直接传给 AdamW而基座模型没有正确冻结那 optimizer 会为全部参数创建状态。7B 模型直接乘以 12 字节加上基座权重 15GB32GB 卡瞬间爆炸。排查方法很简单用 model.print_trainable_parameters() 确认可训练参数数量级以及在 get_peft_model 之后检查 requires_grad 的分布。用 HuggingFace Trainer 时一般不会犯这个错因为它只把 trainable 参数传给 optimizer但自定义训练脚本必须主动检查。另外还要检查是否加载了 fp32 的模型。有些脚本 from_pretrained 时忘了传 torch_dtype默认加载 fp327B 模型就是 28GB加上激活值32GB 卡哪怕训练 1.5B 都可能爆。这个看一眼 nvidia-smi 就能判断。4.4 碎片化、缓存与显存分配器参数这种 OOM 最让人抓狂明明总显存没满但就是分配不出一块连续的显存。PyTorch 的缓存分配器会缓存已释放的显存块训练过程中各种大小的 tensor 不断分配、释放显存会碎成一地小块。如果恰好遇到一个很大的 tensor 需要连续显存哪怕空闲总量够也可能分配失败。解决方式是在启动训练前设置环境变量export PYTORCH_CUDA_ALLOC_CONFexpandable_segments:Trueexpandable_segments 让显存按需扩展能显著减少碎片导致的神秘 OOM。另一个选择是 max_split_size_mb用来限制缓存块的最大分裂粒度避免大块被过度切碎。这两项我在 A100 和 4090 上都试过效果明显。另外如果训练脚本里在用完模型后没有显式释放显存或者用同一个进程反复加载、卸载模型也会导致缓存分配器里的显存一直不归还。可以试试在关键步骤前调用 torch.cuda.empty_cache()虽然它不能完全解决碎片问题但能把空闲缓存清回给驱动。4.5 环境与硬件层驱动、并发、物理移除最后别忘了显卡以外的因素。CUDA 版本、PyTorch 版本、显卡驱动版本三者之间存在兼容矩阵版本不匹配时可能出现各种诡异显存错误。比如老驱动对新架构的支持不完整OOM 报错信息可能完全失真。还要检查是不是 GPU 上同时有别的进程。nvidia-smi 看一眼显存占用如果别人的训练已经占了 20GB你自己明明估算只有 18GB结果一样 OOM。这类问题最简单但最容易忽略。还有一种报错是 GPU 被物理移除 或 driver lost 类信息这种情况重点检查电源功率、散热和 PCIe 连接而不是显存容量。训练时 GPU 瞬时功耗很高电源瓦数不够或者供电线没插紧就会触发这类硬件级错误。如果机器配置没问题还是频繁出现再去考虑驱动或者换卡。4.6 OOM 现象速查表我把几种高频现象整理成一个表方便快速定位现象最可能原因处理方向batch 调大后立即 OOM激活值峰值过高开 gradient checkpointing、降 seq lenbatch1 也 OOM基座权重/优化器状态超限检查是否 fp32、是否所有参数进了 optimizer训练一段时间后中途 OOM缓存碎片增长设置 expandable_segments、重启进程一个进程跑完后下一个进程 OOM显存未释放或他人占用检查 nvidia-smi、torch.cuda.empty_cache()报错显示 GPU 被移除电源、散热、PCIe检查硬件日志和功耗换机器/换驱动后开始 OOM环境版本不匹配对齐 CUDA-PyTorch-驱动兼容矩阵5. 把 32GB 再榨一点显存优化优先级与实操心得5.1 显存优化优先级排序差几 GB 显存的时候优先动哪些参数最见效我的经验排序是先开 gradient checkpointing再装 FlashAttention然后是降 batch size 或序列长度之后才考虑换量化精度最后才轮到 target_modules、r 值这类 LoRA 参数。这个顺序反过来就是性价比从低到高。gradient checkpointing 是收益最大的一项能把激活峰值砍到四分之一到六分之一代价是训练速度下降 20%-30%。对大多数场景来说这点速度损失完全能接受。FlashAttention 更猛既省显存又提速缺点是有些老卡和自定义模型结构兼容性不好。如果装了之后报错果断退回到普通 attention。LoRA 参数本身对显存的影响其实很小r 从 16 加到 64显存多一两 GB 到头了。所以不要为了省显存去刻意降 r该用多少用多少。5.2 容易忽略的细节padding、混合精度、多进程讲几个冷门但实际影响很大的细节。第一序列 padding 方式。如果做 SFT数据长度差异很大的时候把短样本 padding 到 max_seq_len 是非常浪费显存的做法因为激活值是按实际序列长度算的。用 packing 或者按长度分组训练显存占用能立省 20%-30%。HuggingFace Trainer 的 per_device_train_batch_size 背后没有自动做这个优化需要自己在 Dataset 里处理。第二混合精度类型。bf16 和 fp16 显存占用相同但 bf16 更稳不会频繁出现 fp16 的溢出问题。如果你的显卡是 RTX 30 系或更新的优先 bf16不需要额外调 loss scaling。第三多进程 DataLoader 的 num_workers 也会产生显存开销。有人把 num_workers 调得很大结果每个 worker 都复制了一份 GPU tensor显存莫名多了几 GB。这个通常没人提但我在实际操作中踩过。第四gradient_accumulation_steps 虽然不改变峰值显存但它间接影响 optimizer.step 的频率也就影响 optimizer 状态是否有机会整理和 compact。极端情况下每次 accumulate 后手动清缓存也有帮助但别把这个当常规手段。5.3 最后的经验之谈可以说一句显存问题本质是资源规划问题不是玄学。预估、监控、对照、调整这套流程走完90% 的 OOM 都能解决。剩下的 10%要么是环境版本错位要么是硬件本身扛不住跟配置技巧无关。我自己配过不少机器从 8GB 显存的老卡到 80GB 的 A100 都折腾过。最深的体会是训练配置一定要先算账再动手。不要一上来就照着网上的参数抄不同模型、不同量化方式、不同序列长度显存差距能到 2-3 倍。你先把本文这套估算方法用一遍把目标模型的数据算出来再决定用哪套方案成功率会比盲调高很多。如果非要用一句话总结32GB 卡不是 LoRA 微调的天花板而是最合适的甜点区间。7B 全精度随便跑14B 量化稳一稳也能上关键是别让优化器把显存吃掉也别让激活值偷偷超支。