手头正好有一张32GB显存的GPU想着终于能跑点像样的模型微调了结果刚把7B模型的数据加载进去一个torch.cuda.OutOfMemoryError直接把我打回原形。屏幕上的红色报错看了无数遍相信你也一样。在本地大模型微调这件事上OOM显存溢出几乎是每个人都会撞上的墙尤其是用LoRA、QLoRA这类参数高效微调方法时很多人以为换个显卡就万事大吉结果32GB也不够用问题不在显存大小而在于显存怎么花。这篇内容主要想和你聊清楚一件事在32GB单卡环境下LoRA和QLoRA微调到底为什么还会OOM以及怎么通过一系列实操手段把显存占用压下来让训练稳定跑完。这篇文章适合所有在本地折腾模型微调的同学不管是做科研实验、给学生在课堂上演示大模型训练还是自己研究了几天想把手头的开源模型调成自己想要的样子只要你手上是24GB32GB区间的显卡这篇文章的内容应该能帮你省下不少折腾时间。1. 为什么LoRA和QLoRA能在32GB显卡上跑大模型1.1 全参数微调的显存账单是怎么算出来的先说一个基础账目。你要微调一个7B参数的模型如果用全参数微调Full Fine-tuning显存里要同时放下模型权重、梯度、优化器状态这三样东西。以AdamW优化器 混合精度训练为例业界有个粗略估算公式每1B参数大约需要16GB显存。7B模型就是112GB左右这还只是静态部分没算中间过程的激活值Activations。所以全参数微调7B模型即使是32GB的显卡也远远不够这就是为什么大家都不怎么建议在单卡上全量微调大模型。而LoRALow-Rank Adaptation的思路很直接原始模型权重冻结不动只训练一小部分新增的低秩矩阵。7B模型可能只需要训练几十万到几百万个参数相比7B这个量级可训练参数通常只有0.1%1%。算力开销和显存开销都降下来了梯度、优化器状态只针对这部分新增参数自然不需要动辄上百GB显存。1.2 LoRA把哪部分省下来了LoRA的核心操作是在模型的线性层旁边并联两个低秩矩阵 (A) 和 (B)前向计算时把 (A \times B) 的结果加到原始输出上原始权重完全冻结。这样优化器只用维护 (A) 和 (B) 的梯度显存里不需要存7B参数的梯度也不需要给7B参数准备AdamW的动量项和方差项。举个例子如果你在7B模型上用LoRA且只攻target modules里的 q_proj、k_proj、v_proj、o_proj、gate_proj、up_proj、down_proj 这些线性层r16时每个线性层的可训练参数规模大概是 4096×16 16×4096按7B模型隐藏层4096估算一个层大约13万参数二三十个层加起来也就几百万参数。这几百万参数用AdamW优化器换算下来可能只占几十MB显存相比全参数微调的几十GB省掉的不是一点半点。但这里要明确一个容易被忽略的点LoRA节省的是梯度和优化器状态的显存模型权重本身如果以BF16/FP16格式加载仍然要占14GB左右7B模型。也就是说LoRA能在32GB显卡上跑但跑不了特别离谱的batch size和序列长度因为激活值仍然存在且波动很大。1.3 QLoRA再进一步把底座权重压到4bitQLoRA是LoRA的加强版它在LoRA的基础上把底座模型用4bit量化加载。7B模型用NF4NormalFloat4量化后权重占用从14GB左右降到3.5GB左右省出来的空间全部留给激活值和batch size这就是为什么QLoRA特别适合单卡微调。所谓NF4量化简单理解就是用一种更聪明的4bit表示方式去近似原始浮点数权重它比普通的int4好在分布贴近神经网络权重的真实分布精度损失更小。推理时QLoRA会先把4bit权重反量化为BF16再参与计算所以训练速度会受一点影响但换来的是显存占用大幅下降。实测下来在32GB显卡上QLoRA微调7B模型把序列长度拉到2048甚至4096通常都能跑得动全量LoRA如果不借助其他手段在同样的长度下可能就会碰到瓶颈。做个更直观的对比方案7B模型权重占用约训练所需显存约能否在32GB单卡跑全参数微调14GB (BF16)80GB以上否LoRA BF1614GB (BF16)18GB30GB临界取决于序列和batchQLoRA NF43.5GB (4bit)12GB20GB是且余量明显这个表格可以当作选型参考但实际显存还跟序列长度、batch size、是否开gradient checkpointing强相关接下来我会把每一块讲透。2. 显存到底都花在哪了OOM前的精细化拆账2.1 显存分配四件套在动手优化之前你得先搞清楚显存花在了哪些地方。一次训练forward backward过程中显存消耗主要分四块模型权重、梯度、优化器状态、激活值。前三个在中低batch size时相对固定第四个激活值是个“动态变量”最容易被低估。以QLoRA微调7B模型为例模型权重3.5GB左右LoRA参数和优化器状态加起来可能只有几百MB梯度只对LoRA参数有所以也很小。真正的不确定因素在激活值每一层Transformer的中间输出都要保留供给backward时计算梯度用。序列长度越长、batch size越大激活值按线性甚至超线性增长。这就是为什么同一个模型别人跑得好好的你把max_seq_length从1024改到2048直接OOM。2.2 动态峰值来自激活值很多人都只盯着“模型多大”来判断显存够不够这是最常见的误区。激活值的大小取决于batch size × sequence length × hidden size × 层数还要乘以各种中间变量系数。以一个7B模型hidden size 409632层为例假设batch size 1sequence length 2048每一层大概要保存几十MB到上百MB的激活值取决于是否使用flash attention和gradient checkpointing32层叠加起来就是几个GB到十几个GB的量级。这还没完反向传播时如果某些算子需要重算输入比如没有开gradient checkpointing激活值会在显存里一直存到backward执行完毕。开启gradient checkpointing之后前向过程会丢弃中间激活值backward时再用一个额外前向重新计算出来相当于“用算力换显存”。这是一个在32GB单卡上特别关键的开关我后面还会详细展开。2.3 三个容易被忽略的隐形内存池除了上面的“四件套”实际训练时还有三个看不见的显存开销第一是CUDA context。只要PyTorch初始化CUDA就会预留一部分显存通常在300MB800MB取决于驱动和CUDA版本。第二是PyTorch的缓存分配器Caching Allocator。PyTorch为了加速显存分配会缓存一部分之前释放过的显存块不立刻还给CUDA。这个过程会导致显存看起来只增不减即使你删掉了某个tensornvidia-smi里也不一定马上降下来。第三是CUDA malloc碎片的额外预留。当显存分配不连续时缓存分配器会额外向CUDA申请更大的显存块有时会多占用好几个GB这种碎片问题在长序列训练中尤其明显。这几项加起来可能已经吃掉2GB4GB显存你还没开始训练可用空间就已经打了折。理解了这些再做优化才有方向感。3. 32GB GPU上的显存优化实操3.1 基线配置先让程序跑起来在优化之前最好先建立一个能稳定运行的基线配置然后再逐步加大规模。我的习惯是先以最小可运行配置起步把训练流程打通再往上涨batch size和序列长度。初始配置建议如下模型7B量化底座QLoRA或BF16底座LoRA数据类型BF16如果显卡支持或FP16梯度检查点gradient_checkpointing开启batch size1gradient_accumulation_steps8让梯度更稳max_seq_length1024优化器AdamW 8bit或paged_adamw_8bitLoRA rank16为什么从这个配置起步因为batch size 1和1024序列长度几乎不挑显卡开启了gradient checkpointing后7B模型的QLoRA显存占用能压到10GB以下。先用这个配置跑一个step确认forward/backward都正常再看显存余量决定要不要提高batch size或序列长度。3.2 梯度检查点与梯度累积的正确用法梯度检查点Gradient Checkpointing是LoRA/QLoRA微调中最经济实惠的显存优化方式没有之一。它不需要牺牲精度只是把前向过程中间激活值删掉backward时重新算一遍。代价是训练时间大约增加20%30%但换来的是显存需求可能下降一半以上。训练代码里开启方式很简单model.gradient_checkpointing_enable()配合transformers的Trainer还要在TrainingArguments里设置training_args TrainingArguments( per_device_train_batch_size1, gradient_accumulation_steps8, gradient_checkpointingTrue, ... )梯度累积则是为了弥补batch size太小带来的梯度估计不准的问题。batch size 1时梯度波动太大模型容易震荡。用梯度累积每8个step的梯度累加后再更新一次参数效果近似于batch size 8但显存消耗只有batch size 1的水平。这是内存不够时的标准解法代价是训练时间变长。一个很容易踩的坑开启了梯度累积后偶尔会发现loss曲线波动奇怪。排查后发现是模型里的BatchNorm层或某些算子对batch size敏感。Transformer架构一般没有这个问题但如果你用的是带BatchNorm的模型结构梯度累积时要额外小心。3.3 量化加载与计算类型的避坑组合QLoRA的核心是bitsandbytes库的4bit量化加载加载时一般用下面这种方式from transformers import BitsAndBytesConfig bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_quant_typenf4, bnb_4bit_use_double_quantTrue, bnb_4bit_compute_dtypetorch.bfloat16, )这里有几个容易出问题的点第一bnb_4bit_compute_dtype建议设置为torch.bfloat16前提是你的GPU支持BF16RTX 30系及之后基本都支持。如果老卡只支持FP16就设成torch.float16。计算类型不匹配会导致精度损失甚至训练崩溃。第二加载4bit模型后冻结所有原模型参数只保持LoRA参数可训练。代码模式基本固定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, lora_dropout0.05, biasnone, task_typeCAUSAL_LM, target_modules[q_proj, k_proj, v_proj, o_proj], ) model get_peft_model(model, lora_config)第三prepare_model_for_kbit_training会把模型设置为可训练状态并处理量化层在训练时需要的一些梯度特殊处理这个函数不能漏。漏了它LoRA参数虽然能训练但底层量化权重可能会在反向传播时报错或者训练一段时间后loss变成nan。第四混合精度要统一。如果你用了torch.bfloat16计算那么training_args里的bf16True要对应开启如果用FP16就设置fp16True。不一致时显存占用和训练精度都会出问题。3.4 序列长度、batch size与attention实现的取舍在32GB显卡上如果已经用了QLoRA gradient checkpointing那么显存的主要压力就从模型权重转移到了激活值。这时候最关键的两个旋钮是batch size和序列长度。最直观的感受是模型权重固定后显存占用大约等于“模型权重 激活值”。激活值又跟序列长度的平方成正比因为attention的计算图里attention矩阵是L×L的。也就是说把序列长度从1024翻到2048激活值可能不只翻一倍而可能是翻三四倍。优化attention显存有个成熟方案Flash Attention / Flash Attention 2。它通过分块计算和重计算把attention部分的显存复杂度从O(L²)降到O(L)并且速度还更快。目前在transformers的modeling_qwen2.py等代码里已经内置了use_flash_attention_2True的选项。32GB显卡建议开启不仅省显存还能加速。如果不方便用Flash Attention也可以通过限制attention计算范围来降低开销。对于长文档场景可以用Sliding Window Attention每次只关注最近的若干位置显存占用大幅下降代价是远距离依赖能力变弱。日常训练对话数据时序列长度不超过2048已经够用不必强行拉长。实际操作时我的建议顺序是先固定序列长度比如2048调整batch size到能稳定运行的临界值然后如果需要更长序列再降低batch size。不要同时把batch size和序列长度一起拉满否则很容易OOM而且不好定位到底是谁导致的。4. 单卡训练从OOM到稳定收敛的完整实验记录4.1 实验环境与模型选择前段时间我需要给学生做一次大模型微调演示手头正好是32GB V100不支持BF16只能FP16和另一台32GB显卡机器。考虑到之前踩过deepseek-r1:1.5这种超小模型的坑——效果不够明显学生看完没什么感觉——这次我直接选用了一个7B量级的中文对话模型作为演示对象既能跑得动又能在微调后看出明显的行为变化。实验环境大概是这样的GPU32GB显存单卡模型7B中文对话模型微调方法QLoRANF4量化训练框架transformers peft bitsandbytes显存工具nvidia-smi PyTorch的torch.cuda.memory_summary()一开始我信心满满觉得32GB显存跑7B QLoRA应该绰绰有余于是直接把batch_size设成了4max_seq_length设成2048还顺手把梯度检查点给关了。结果训练刚开始就爆出红色的CUDA out of memory连第一个step都没跑完。4.2 逐步调整记录从batch size 4爆显存到稳定训练我把调整过程记录下来了也符合大多数人遇到OOM后的排查路径第一步复现OOM。保持batch size 4序列长度2048关闭梯度检查点训练脚本启动后报错。用torch.cuda.memory_summary()查看发现激活值占用异常高占了大头。第二步开启梯度检查点。在模型加载后增加model.gradient_checkpointing_enable()重新启动显存压力立刻减小但batch size 4依然勉强卡在32GB边缘偶尔在一个特别长的样本处爆掉。第三步减小batch size到2开启梯度累积。设置梯度检查点后batch size 2已经能跑但显存占用依然在28GB左右比较危险。我干脆把batch size降到1用gradient_accumulation_steps8来模拟batch size 8的效果。这下稳定了显存占用降到14GB左右非常安全。第四步调整序列长度和LoRA参数。稳定后我把序列长度从2048提高到3072显存占用上升到20GB左右依然可跑。最后为了演示效果好我固定在用batch size 1序列长度2048梯度检查点开启NF4量化LoRA rank 16lora_alpha32模型表现和显存占用取得了很好的平衡。4.3 实测显存数据与效果对比下面这组数据是我在同一台机器上记录的QLoRA微调7B模型序列长度2048配置是否开启梯度检查点显存占用约能否稳定训练batch size 4否超出32GB否直接OOMbatch size 4是30GB左右临界长样本会爆batch size 2是22GB左右是batch size 1是14GB左右是余量充足从这张表能看出梯度检查点带来的收益非常明显而batch size对显存的影响同样巨大。如果你用的也是32GB显卡建议先从batch size 1或2起步开启梯度检查点然后再根据剩余显存慢慢加序列长度。训练完成后我特意用几个微调前的测试问题去问模型模型给出的还是通用回答再用微调后的模型试同样的输入回答风格明显贴近了训练数据的表达习惯。对于学生演示来说这种前后对比已经足够直观。4.4 一个能直接抄的QLoRA训练脚本如果你也想像我一样快速跑通这里有一份可以直接参考的训练脚本核心部分。数据格式用简单的conversation格式训练目标是常规的文本生成任务。import torch from transformers import ( AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig, TrainingArguments, Trainer, ) from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training model_name your-7b-model tokenizer AutoTokenizer.from_pretrained(model_name) tokenizer.pad_token tokenizer.eos_token bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_quant_typenf4, bnb_4bit_use_double_quantTrue, bnb_4bit_compute_dtypetorch.bfloat16, # 不支持BF16就用torch.float16 ) model AutoModelForCausalLM.from_pretrained( model_name, quantization_configbnb_config, device_mapauto, use_flash_attention_2True, # 取决于transformers版本也可用attn_implementationflash_attention_2 ) model prepare_model_for_kbit_training(model) model.gradient_checkpointing_enable() lora_config LoraConfig( r16, lora_alpha32, lora_dropout0.05, biasnone, task_typeCAUSAL_LM, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], ) model get_peft_model(model, lora_config) training_args TrainingArguments( output_dir./lora_output, per_device_train_batch_size1, gradient_accumulation_steps8, gradient_checkpointingTrue, num_train_epochs3, logging_steps10, save_steps200, learning_rate2e-4, bf16True, # 如果用fp16改成fp16True max_grad_norm0.3, warmup_ratio0.03, lr_scheduler_typecosine, report_tonone, ) trainer Trainer( modelmodel, argstraining_args, train_datasettrain_dataset, tokenizertokenizer, ) trainer.train()这个脚本我第一次跑的时候就成功了。需要注意target_modules里的参数名要根据实际模型结构改Qwen系列通常有这些keyLlama系列也一样但有些模型只有q_proj、v_proj或者名字不同得自己看模型配置。还有一个细节use_flash_attention_2True和梯度检查点在部分transformers版本里可能有冲突如果报错优先保留梯度检查点去掉Flash Attention因为显存上的收益梯度检查点更明显速度上的损失可以接受。5. 训练中常见OOM问题与排查技巧5.1 典型报错速查表训练过程中如果遇到OOM不要急着盲目调参先读报错信息。下面这个表格基本覆盖了我在实际训练中碰到的典型场景和解决办法报错信息原因解决办法CUDA out of memory. Tried to allocate ...显存确实不够减小batch size或序列长度开启梯度检查点torch.cuda.OutOfMemoryError出现在第二个step前一个step显存没有释放或者缓存分配器异常显存碎片问题尝试torch.cuda.empty_cache()或者降低batch sizeCUDA error: device-side assert triggered数据标签越界或模型参数NaN检查tokenizer、标签范围降低学习率bitsandbytes相关报错量化配置或CUDA版本不匹配确认bitsandbytes版本和CUDA toolkit版本匹配NCCL相关报错单卡也可能出现可能是CUDA初始化或多进程环境问题检查CUDA_VISIBLE_DEVICES或者换用单进程启动训练过程中显存逐渐增长直到OOM显存泄漏或缓存分配器缓存过多检查是否在循环中反复创建数据集或模型定期torch.cuda.empty_cache()5.2 显存碎片与缓存分配器很多人不知道OOM不一定代表你的模型真的需要超过32GB显存有时只是显存碎片太多分配不出连续块。这种情况在长序列训练里尤其常见。解决办法有几个第一训练脚本开头设置环境变量PYTORCH_CUDA_ALLOC_CONFmax_split_size_mb:128这个配置能让PyTorch的显存块更小一些减少碎片化分配失败的概率。这个参数不是万能药但实测能解决一部分莫名其妙的OOM。第二在关键节点调用torch.cuda.empty_cache()把缓存分配器手中空闲的显存归还给CUDA。但这招不要频繁使用因为频繁释放和重新分配反而增加开销。第三如果条件允许优先用性能更好、显存更大的显卡或者减少batch size。显存碎片问题本质上还是因为显存余量不够如果余量充足一般不会触发碎片导致的分配失败。5.3 几条独家避坑经验最后分享几条踩过多次坑才总结出来的经验希望能帮你少走弯路。第一不要过分迷信量化。4bit确实省显存但bnb_4bit_compute_dtype设置不对比如FP16下使用BF16计算会导致loss异常波动甚至NaN。如果你发现loss曲线一开始就非常离谱优先检查量化配置和模型加载是否一致。第二gradient_checkpointing开启后model.gradient_checkpointing_enable()的位置要在get_peft_model之后或之前都行但确保没有把原始模型重新设置为requires_grad_(False)后漏掉LoRA参数。简单检查方法调model.print_trainable_parameters()如果显示的可训练参数只有LoRA的几百万说明设置正确。第三用nvidia-smi看显存占用其实不够精确因为PyTorch的缓存分配器会隐藏一部分真实状态。调torch.cuda.memory_summary(deviceNone, abbreviatedFalse)能看到更详细的分配情况定位OOM时特别有用。第四数据长度不均匀很容易导致“偶尔OOM”。如果你的训练数据里大多很短只有几条特别长batch size 2可能在多数step都没事偏偏在长样本上爆掉。解决方法是在数据预处理时统一截断到固定长度或者对超长样本做二次切分。我个人在实际操作中的体会是32GB显卡配合QLoRA应该是目前本地微调大模型性价比最高的组合之一但前提是你把显存分配思路搞清楚了。最怕的不是显卡不够用而是一上来就把batch size、序列长度、全量模型权重全拉满然后被一个OOM搞得怀疑人生。踩过几次坑之后现在我做任何微调实验都会先跑一个最小配置基线确认能跑通再往上加资源这个习惯帮我省了很多时间。最后再分享一个小技巧如果你只是做教学演示或者快速验证某个数据集是否有效可以把LoRA rank设成8甚至4效果可能在可接受范围内显存会更宽裕训练速度也会明显提升。等验证完思路再上rank 16或32跑正式版本。这个内容后续还可以这样扩展把QLoRA换成GPTQ或者AWQ量化底座或者在多卡环境下配合DeepSpeed ZeRO Stage 3做更大的模型微调优化的思路和方法都是一脉相承的——先搞清楚显存花在哪再对症下药。