LoRA微调显存不够？一文读懂显存估算与32GB GPU配置

显存不够，是所有LoRA微调新手和老手都绕不开的坎。很多人手里明明有一张32GB显存的GPU，结果训练刚跑起来就报CUDA out of memory，或者batch size只敢设1，速度慢到怀疑人生。说实话，LoRA已经是大模型微调里最省显存的手段了，但如果你不知道显存到底被谁吃了、怎么估算、各个配置项之间怎么取舍，32GB照样不够用。

这篇内容我就把LoRA微调的显存账一笔一笔算给你看：从模型权重、梯度、优化器状态到激活值，再到一套可以直接套用的估算公式，最后给出一份能在32GB显存上稳定跑起来的训练配置，以及我实际踩过的几个高频问题。适合准备做7B/13B级模型微调、打算租云GPU或者用本地单卡做LoRA训练的朋友，看完你至少能回答三个问题：我这个模型要多少显存？batch size能开多大？爆显存了先从哪下手？

1. 显存到底花在哪？先看懂这四块开销

1.1 模型权重不是全部，激活值才是隐形大户

很多人算显存的时候习惯盯着模型权重，觉得7B模型用FP16加载不才14GB嘛，32GB绰绰有余。这个算法的确没错，但它只算了“显卡把模型装下”的钱。真正训练的时候，显存里同时住着四样东西：模型权重、梯度、优化器状态、激活值。

模型权重好理解，就是网络的参数。梯度是反向传播时算出来的，理论上一份参数对应一份梯度，全参数微调时光是梯度就是一份权重的量级。优化器状态更狠，AdamW这类优化器要为每个可训练参数保存一阶动量、二阶动量和权重副本，混合精度下每个参数大概要额外占12字节，这比参数本身还大。激活值则是前向传播过程中每一层输出的中间结果，反向传播算梯度时要拿它们回去做链式求导。激活值的大小和模型层数、隐藏维度、序列长度、batch size直接挂钩，而且不会因为你只训练一小部分参数就消失。

所以训练时显存占用不是“权重+一点杂项”，而是“权重+梯度+优化器状态+激活值+临时缓冲区+CUDA上下文”。CUDA上下文一般固定吃掉几百MB到1GB，临时缓冲区比如attention计算、allocator碎片等也会带来10%~20%的额外开销。你打开nvidia-smi看到的占用率，其实是这些总和，不是单纯某一个模块。

1.2 LoRA到底省了哪部分？它并没有省激活值

LoRA的原理是在冻结的预训练权重旁边插入低秩矩阵，让原权重保持不动，只训练这些极小的旁路矩阵。比如一个7B模型，原本7B参数都要更新，现在可能只训练几千万个参数，训练参数量缩到1%甚至更少。

这样一来梯度变小了，优化器状态也变小了，这是LoRA省显存的核心。我算过一笔账：7B模型全参数微调，FP16权重14GB，梯度再算14GB，AdamW的32位优化器状态大概要84GB，这还没算激活值，单卡32GB根本没有任何机会。但如果用LoRA，假设LoRA参数只有5000万，梯度约占100MB，AdamW状态约占600MB，和权重一比就是个零头。

很多人会误以为LoRA连激活值也一起省了，这是个常见误区。激活值主要取决于前向传播的中间结果，模型结构没变、序列长度没变、batch size没变，激活值就不会因为“只训练旁路”而变小。所以LoRA减掉的主要是优化器状态和梯度这两块，激活值该多大还是多大。这也是为什么即使你用LoRA微调，序列长度太长或者batch size太大，照样会在激活值上爆显存。

2. 手把手估算：一张32GB卡到底能跑多大模型

2.1 先背下这三个数字，显存估算就完成一半

估算显存的第一步，是搞清楚参数在不同精度下占几个字节。FP32是4字节，FP16/BF16是2字节，INT8是1字节，4bit量化是0.5字节。

预训练权重加载进显存后，静态占用可以按“参数量×字节数”直接算。7B模型用FP16加载是7×2/1024=13.7GB，用8bit加载是7GB，用4bit加载是3.5GB。13B模型FP16是26GB，8bit是13GB，4bit是6.5GB。70B模型FP16是140GB，8bit是70GB，4bit是35GB。这里还没把多卡负载均衡、模型并行时的冗余考虑进去，单卡的话就这么算。

LoRA新增参数很小，但也要计入。假设你在q、k、v、o等线性层各挂一个rank为16的LoRA，7B模型大概会多出2000万到5000万参数。以5000万参数为例，FP16权重占100MB，AdamW状态占5000万×12字节≈600MB，整体也就0.7GB左右。所以LoRA部分基本可以按0.5GB~1GB做预留，不同rank和target modules范围会有浮动，但量级就是“小”。

权重、LoRA参数和优化器状态都是相对固定的，最难算的是激活值。很多人就是因为没算这一块，才在训练启动后被打个措手不及。

2.2 激活值怎么估？一个粗略公式加一个经验口诀

激活值的精确大小依赖具体模型结构和代码实现，很难用一个万能公式完全算准，但做粗略规划足够用了。对常见decoder-only Transformer，可以按下面这个简化的上限方向估算：

单卡激活显存约等于：batch_size × seq_len × hidden_size × layers × 字节数 × 系数。

这个系数取决于是否使用gradient checkpointing、是否保存中间激活、attention实现等。沿着这个公式，你看一眼模型config里的hidden size和layer数量，就能知道关键变量是什么。以7B模型为例，常见配置是hidden size 4096、层数32。假设batch size=1、seq_len=2048、FP16，那么“batch×序列×隐藏维度×层数”算出来是1×2048×4096×32×2字节≈512MB，这只是最底层的中间状态，乘上实际Transformer里多头注意力、FeedForward、LayerNorm等各类缓冲系数后，通常会到2GB~4GB。如果batch size提到4、seq_len加到4096，这个数字会涨到16GB上下，属于质变。

所以我的经验口诀是：LoRA微调时，基础模型权重加上1GB~2GB的固定开销，再加上“batch×seq_len×hidden×层数”放大几倍后的激活值，基本就是你的总显存需求。梯度检查点如果打开，激活值能降到原来的四分之一到五分之一，代价是大约20%~30%的额外计算时间。这个取舍在下文会再展开。

2.3 拿起nvidia-smi和torch.cuda.memory_summary，把显存看穿

估算归估算，真正落地时建议直接看工具读数。训练开始前，用nvidia-smi看整卡的可用显存；训练启动后，用下面的命令持续监控：

watch -n 1 nvidia-smi

这会每秒刷新一次显存占用、GPU利用率、温度等。但注意nvidia-smi显示的是整个进程占用的显存，不区分权重、梯度、激活值分别用了多少。想看细粒度分布，可以在PyTorch代码里打印：

import torch # 在训练脚本中适当位置插入 print(torch.cuda.memory_summary(device='cuda', abbreviated=False))

memory_summary会输出allocated bytes、reserved bytes、active bytes、segment大小、碎片情况，还会列出是哪些函数分配了大块显存。我第一次跑LoRA时就是靠这个发现，某次OOM并不是真的显存不够，而是activation checkpointing没有真正生效，导致激活值一直占着巨大空间。这种细粒度信息只靠nvidia-smi是看不出来的。

另外提醒一句，torch.cuda.memory_summary最好在训练的中段或者报错之前调用，因为它本身也要占用显存来生成统计。若你已经OOM了，可以先手动清空缓存再打印，配合torch.cuda.empty_cache()看allocated和reserved的差距。

3. 32GB GPU上的LoRA训练配置参考

3.1 一份可以直接跑的LoraConfig + TrainingArguments

下面这份配置是我在32GB单卡上跑7B/13B模型时经常用的基准配置，经过多个项目的验证，稳定性和收敛速度都比较均衡。使用transformers + peft + bitsandbytes，PyTorch版本2.1以上。

from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments, Trainer from peft import LoraConfig, get_peft_model import torch model = AutoModelForCausalLM.from_pretrained( "your-model-path", torch_dtype=torch.bfloat16, device_map="cuda:0", ) lora_config = LoraConfig( r=16, lora_alpha=32, target_modules=["q_proj", "v_proj", "k_proj", "o_proj", "gate_proj", "up_proj", "down_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM", ) model = get_peft_model(model, lora_config) model.enable_input_require_grads() model.gradient_checkpointing_enable() training_args = TrainingArguments( output_dir="./lora_output", per_device_train_batch_size=2, gradient_accumulation_steps=8, gradient_checkpointing=True, max_length=2048, bf16=True, optim="paged_adamw_8bit", logging_steps=10, save_steps=500, num_train_epochs=3, learning_rate=2e-4, lr_scheduler_type="cosine", warmup_ratio=0.03, dataloader_num_workers=4, remove_unused_columns=False, ) trainer = Trainer( model=model, args=training_args, train_dataset=train_dataset, tokenizer=tokenizer, ) trainer.train()

几个关键参数我说下心路历程。r=16是性能和效果的折中，如果你只想做指令跟随微调，16已经足够，rank太高并不会带来明显收益，反而增加显存和过拟合风险。lora_alpha一般设为r的2倍，如果r=32，alpha可以设64，这个比例在多数情况下都work。target_modules尽量把FFN层的投影也加进去，很多人只动attention层，效果差一截。

optim="paged_adamw_8bit"是bitsandbytes提供的优化器，它把优化器状态放到分页内存里，能够暂时借用CPU内存缓解显存尖峰。实测在13B模型、batch size=2、seq_len=2048的情况下，这个开关能省出1GB到2GB的显存，代价是训练速度略有下降。

3.2 四个开关，按你的模型规模决定开不开

gradient_checkpointing建议直接打开。它用重新计算激活值来换显存，原先需要15GB的激活过程，打开后可能只需要3GB到5GB。从实际训练时间看，7B模型大概慢10%到20%，13B模型最多慢30%。如果你显存已经紧巴巴，这几乎是必须开的。开启后注意要和模型里已有的use_cache配置冲突，Transformer生成模式下需要把use_cache=False或交给Trainer处理，否则可能报错或者前向传播行为异常。

bf16和fp16的选择很关键。A100、H100、RTX 4090、A6000这类新卡建议直接用bf16=True，bf16的指数范围大，训练更稳定，基本不会出现梯度溢出。V100 32GB这种老卡不支持bf16，只能用fp16=True，同时建议加上稍微小一点的学习率，并且留意loss是否频繁出现NaN。如果你的卡两种都支持，优先bf16。

FlashAttention很多人容易忽略，但它对激活值和速度的优化非常明显。实现上可以通过model = AutoModelForCausalLM.from_pretrained(..., attn_implementation="flash_attention_2")来启用，前提是已安装flash_attn库并且显卡支持。经过FlashAttention处理后的attention不需要保留完整的attention矩阵，长序列场景能省下几个GB，这比什么超参调整都来得直接。

最后是降低max_length。Sequencelength对激活值的影响是线性的，而batch size的影响也是线性的。如果你训练数据里大多数样本只有500到800个token，那完全没必要把max_length设成4096。我习惯先统计数据集的token分布，然后取80%分位数作为max_length，这样显存往往能直接砍半。

3.3 不同模型规模在32GB卡上的配置对照

理论讲完，直接上对照表。以下配置基于单张32GB显存、LoRA微调、启用梯度检查点、使用8bit优化器的情况，模型为常见开源底座，数值是大概估算，实际会因实现细节有浮动：

所以结论很清楚：7B模型在32GB卡上空间其实很富余，batch size开到4到8都没问题；13B如果不动量化就必须压缩batch和序列长度，勉强能跑；70B这种量级，4bit权重的理论体积35GB已经超过32GB，单卡基本无望，想要跑只能考虑多卡或者更强力卸载，这不是LoRA能解决的问题。

4. 常见问题排查实录

4.1 CUDA out of memory？按顺序检查这五步

如果训练刚开始就报CUDA out of memory，我建议不要盲目调低batch size，按下面顺序排查。

第一步看nvidia-smi里是否真的显存满了。有时候是其他进程把显存占了，尤其是你在云主机上同时开了Jupyter、TensorBoard或者其他推理服务。排查方法很简单，看GPU进程列表里有没有别人的进程。如果是这种情况，杀掉无关进程，batch size根本不用动。

第二步看allocated和reserved的差距。PyTorch的显存分配器有缓存机制，它reserve的显存会大于实际allocated。如果某个尝试的batch size导致reserved超过显存上限，报的就是OOM。这种时候可以在训练脚本最前面设置环境变量：

export PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:128

这个设置能降低显存碎片化，让小的空闲块可以被合并利用。我碰到过一种情况：nvidia-smi显示只剩2GB空闲，但总占用其实才20GB，碎片太多，调低max_split_size_mb后batch从1提到了4。

第三步看是不是gradient_checkpointing没生效。可以在模型前向传播前后各打印一次torch.cuda.memory_allocated()，如果差值巨大，说明激活值还是全量保存。常见原因是Trainer的某个参数覆盖了它，比如你在TrainingArguments里又传了gradient_checkpointing=True，但模型里的use_cache没关，依然缓存了每一层的KV。

第四步检查max_length是否远大于实际数据长度。很多数据集里混着几万token的超长样本，一个样本就能把batch显存顶爆。用tokenizer统计训练数据token长度，把max_length卡在分位数上，比调batch更有效。

第五步才轮到降batch和开8bit优化器。都是直接省显存的手段，但也有副作用：batch太小会导致梯度噪声大，收敛不稳定；8bit优化器会增加一点点CPU内存和传输开销。

4.2 Loss不降、震荡、NaN，各自对症下药

Loss完全不动，先检查是不是只有embedding和lm_head被训练，而你的target_modules根本没有命中模型的实际层名。有些模型的层名不是常见的q_proj、v_proj，比如“qkv_proj”合并在一个模块里。可以用model.print_trainable_parameters()或者for name, param in model.named_parameters()打印一下，确认LoRA确实挂到了正确的层上。我见过有人target_modules写错，训练了半天可训练参数为零，loss纹丝不动，还以为是学习率问题。

Loss剧烈震荡通常和学习率过大有关。LoRA微调虽然只训练小参数，但2e-4到5e-4之间是比较安全的区间，超过1e-3很容易震荡。如果你的base模型之前已经经过SFT或RLHF，学习率还要再降一档，1e-4左右更稳。另外warmup_ratio不要太低，至少3%，让模型先稳定探索。

Loss变成NaN，最常见原因是FP16梯度溢出。7B以上模型用FP16训练时，激活值和梯度的数值范围很容易突破65504上限。换成bf16基本能解决，如果卡不支持bf16，那就只能降低学习率、增加梯度裁剪，比如max_grad_norm=1.0。另外一个隐蔽原因是数据里本身有NaN或脏数据，比NaN更讨厌的是inf，会在梯度里传染，建议在dataset预处理时过滤一遍。

4.3 LoRA模型保存和加载的坑

很多人训练结束后只保存adapter权重，结果部署时发现根本不起作用。最稳妥的保存方式是保存adapter本身，然后加载时再套回base模型。

# 保存 model.save_pretrained("./lora_adapter") tokenizer.save_pretrained("./lora_adapter") # 加载 from peft import PeftModel base_model = AutoModelForCausalLM.from_pretrained("your-base-model-path", torch_dtype=torch.bfloat16) lora_model = PeftModel.from_pretrained(base_model, "./lora_adapter")

如果要把LoRA合并回原模型权重，可以用model = lora_model.merge_and_unload()，然后保存合并后的完整模型。这里有个经验：合并后一定跑一遍验证集，确认输出差异正常。我踩过一次坑，合并后推理结果和adapter模式下差别巨大，最后发现是合并时base模型被加载成了FP32，数值精度变化导致结果漂移。合并前检查base模型的dtype，保持一致再操作。

另外一个坑是保存目录权限和磁盘空间。LoRA adapter虽然小，但合并后模型按FP16存储也有几十GB，云盘空间不足时保存会静默失败，下次加载才发现文件不完整。建议保存完立即ls -lh检查文件大小是否合理。

4.4 训练速度很慢，不一定是显卡不行

显存没爆但速度极慢，先看GPU利用率。如果nvidia-smi里GPU utilization不到80%，而CPU占用很高，问题通常出在数据加载上。dataloader的num_workers、prefetch_factor调大一点能明显提升，另外检查数据处理里是否有自定义的collate_fn在GPU计算前做了太多Python循环，比如重复tokenize每个batch，应该提前把数据tokenize好存成内存或磁盘格式。

如果GPU利用率和显存占用都很高，但每步时间依然夸张，可能是梯度检查点带来的重计算开销被放大了。可以试试只在部分层开启检查点，或者减少序列长度。还有一个容易忽略的点：训练进程里如果有其他推理任务在跑，比如同时加载了多个embedding模型做数据增强，显存和算力都会被分走。我跑LoRA时习惯单独开一个干净的环境，只保留训练进程。

如果卡支持FP16但系统里没有正确安装对应的CUDA库，PyTorch可能回退到FP32计算，速度直接掉一半。用torch.cuda.is_bf16_supported()和torch.backends.cuda.matmul.fp16_available检查一下，确保混合精度真的生效。

5. 我踩坑后留下的几条默认配置

做LoRA微调做了这么久，我现在的默认配置基本稳定成一套：7B模型用BF16加载，LoRA的rank设16到32，alpha设成rank的两倍，只训q/k/v/o和FFN层，梯度检查点打开，8bit优化器开着，序列长度取数据分布80%分位数，batch size从2起步，能加就往上加。这套配置在32GB卡上几乎不需要额外折腾，7B模型通常还能吃到显存红利，多开一点并行数据。

如果是13B模型，我会优先考虑8bit加载而不是强行塞BF16，剩下的显存留给激活值。相比之下，8bit加载对效果的影响其实很小，损失的主要是推理时的一点精度，训练收敛出来的LoRA反而可以用回BF16推理，两全其美。

再分享一个小技巧：不管用什么配置，第一次训练时都先跑一两步，然后立刻看torch.cuda.memory_summary。如果显存占用离上限只差不到2GB，八成训练到中途会被长序列样本顶爆。这时宁可早点降max_length或batch，也不要赌后面的数据都短。真正的老手不是能把32GB压榨到极致，而是能提前预判峰值出现在哪一步。显存估算做得到不到位，直接决定了你是花一个晚上调参，还是花一个晚上等OOM报错。