企业官网建设流程全解析

最近有同事来找我，说机器上明明有32G显存，跑Llama-3-8B的LoRA微调还是一直CUDA OOM。他把模型加载上去看nvidia-smi，显存才用了不到6GB，可训练器一启动就报错。这个场景我见过太多次了，很多人对LoRA有一个误解，觉得“7B模型量化一下才4GB，32G怎么着都够了吧”。但训练时的显存账单远不止模型权重这一项，梯度、优化器状态、激活值、临时缓冲区、CUDA上下文，个个都是吞显存的大户。这篇文章就围绕32GB这块短板，把LoRA和QLoRA微调时的显存构成、优化手段、实战参数和排查路径一次讲清楚。

文章不会讲太多理论，重点是“算得清账、控得住峰值、看得懂报错、调得动参数”，适合那些手里正好有30系/40系或V100/A6000这类单卡，想本地微调7B左右模型的朋友。看完之后，你可以自己评估手头模型该跑什么配置，也能在OOM时快速判断是权重问题、激活值问题还是碎片问题，不再瞎调batch size。

1. 显存都去哪了？LoRA/QLoRA的显存账本

1.1 LoRA 省掉的不是权重而是梯度与优化器状态

先纠正一个常见误解：LoRA并不会减少模型权重本身占用的显存。原始权重仍然要完整地加载进显存用于前向和反向计算，除非你同时用了量化（QLoRA）。LoRA真正省的是梯度和优化器状态。

如果要训练全量模型，7B模型的每个参数都需要保存梯度，还需要为AdamW维护一阶动量（exp_avg）和二阶动量（exp_avg_sq）。按fp32算，每个参数至少占4字节梯度 + 8字节优化器状态，折算下来仅这两项就是84GB。加上fp16权重14GB，32GB连个零头都不够。而LoRA把可训练参数限制在新增的低秩矩阵上，假设7B模型只训练约20M参数，那梯度和优化器状态从GB级别直接掉到几十MB级别，这才是LoRA最大的价值。

所以LoRA解决的是“训练参数太多导致梯度/优化器爆显存”的问题，不是“模型权重太大放不下”的问题。想真正把权重显存压下来，必须上量化，这就轮到QLoRA了。

1.2 一张32GB显存的预算表

我习惯在训练前先估算一遍显存，把任务拆成四块：权重、梯度/优化器状态、激活值、临时开销。以7B模型QLoRA微调为例：

这样初步估算在10~15GB左右，32GB确实没问题。但如果序列长度拉到4096，batch设为2，激活值马上会翻到15GB以上；如果用了fp32优化器或全量的AdamW，预算表又会变脸。这就是为什么很多人上来OOM，不是模型太大，而是几个开关没有打开。

1.3 为什么省了这么多还 OOM

最隐蔽的大头是激活值。模型前向计算时每一层都要保存中间输出用于反向传播，层数越深、序列越长、batch越大，激活值的占用越夸张。在7B模型上，单条batch且seq=1024时激活值可能只要2GB，但seq=2048时可能会到5GB，再叠加attention矩阵的中间项，峰值增长非常快。

另一个常见问题是padding浪费。数据加载器在batch内按最长样本补零，如果样本长度差异大，显存里塞了大量无效token，而且这些token同样会参与矩阵运算、同样产生激活值。很多新手把max_seq_length设成模型支持的4096，实际数据平均才800个token，结果激活值白白多算好几倍。OOM不是凭空出现，几乎每一条都有对应的账可以查。

2. 动手前先做的显存体检

2.1 别只盯着 nvidia-smi

训练时大家习惯开个watch -n 1 nvidia-smi盯着看，但这里有个坑：nvidia-smi显示的是当前进程占用的显存总量，包括PyTorch的caching allocator提前缓存下来的块。PyTorch为了减少cudaFree的调用，会把释放的显存留在自己的缓存池里，所以显存使用率高不一定是真不够，使用率低也不代表平安，因为可能只是碎片化导致分配不到连续空间。

更准确的做法是看PyTorch自己的统计，它知道哪些已经分配给了张量，哪些只是缓存。举例来说，torch.cuda.memory_reserved()是缓存池大小，torch.cuda.memory_allocated()是实际张量占用。两者的差就是缓存但没在用的部分。如果差值很大，可以通过empty_cache()释放缓存，但这只影响后续分配，不影响当前峰值。

2.2 用 PyTorch 拿到真实峰值

在训练脚本里，我最常用的一个组合是：

torch.cuda.reset_peak_memory_stats() # 训练代码 # ... peak_memory = torch.cuda.max_memory_allocated() print(f"Peak memory allocated: {peak_memory / 1024**3:.2f} GiB") print(torch.cuda.memory_summary())

max_memory_allocated()返回的是整个进程至今出现的最高实际张量占用，这比nvidia-smi能更真实地反映训练峰值。memory_summary()会输出一段很详细的报告，包括每个分配段的地址、大小、状态，适合看到底有多少碎片、哪些块被缓存占用。

如果用Hugging Face Trainer，可以在回调里做同样的事情：

from transformers import TrainerCallback class MemCallback(TrainerCallback): def on_step_end(self, args, state, control, **kwargs): if state.global_step % 10 == 0: print(torch.cuda.max_memory_allocated() / 1024**3)

这样每训练10步打一次峰值，能清楚看到显存是稳定、上升还是突然跳变。

2.3 从 OOM 报错反推占用源头

OOM报错其实透露了很多信息。比如：

• CUDA out of memory. Tried to allocate 4.00 GiB (GPU 0; 31.7 GiB total capacity; 24.1 GiB already allocated; 5.2 GiB free; 26.3 GiB reserved in total by PyTorch)说明当前需要一次分配4GB，但只剩5.2GB。如果剩余空间小于请求量但有连续碎片问题，往往调用expandable_segments或减小batch即可。

• RuntimeError: CUDA error: device-side assert triggered这种不是显存不足，而是越界访问，和OOM没关系，别混为一谈。

• 尖峰位置也可能从堆栈里看出来：如果OOM发生在self-attention的torch.bmm或flash_attn_varlen_kernel，说明激活值或attention矩阵超预算。如果发生在optimizer.step()，说明优化器状态分配失败，优先检查优化器类型和可训练参数量。

把OOM当成一个日志来读，比乱调batch有效得多。

3. 32GB 微调的关键优化开关

3.1 bf16/fp16 与 8bit 优化器

混合精度不只是“省一半显存”那么简单，它还会影响激活值精度和训练稳定性。建议优先开bf16，因为它和fp32一样有8位指数，对小学习率场景更稳，不会像fp16那样容易出现梯度溢出。在transformers的TrainingArguments里直接写：

TrainingArguments( bf16=True, fp16=False, )

如果显卡比较老，不支持bf16，再用fp16，同时必要时加上fp16_opt_level="O1"之类（O1是apex的用法，transformers直接fp16=True即可）。

优化器方面，强烈建议用paged_adamw_8bit。它来自bitsandbytes，核心是把优化器状态保存成8bit整型，同时用分页机制把部分状态换到CPU内存。对LoRA这种可训练参数很少的场景，8bit优化器状态省不了几GB，但它能把优化器状态从fp32的8字节/参数降到2字节/参数，也减少了OOM风险。实际上，对于LoRA，如果你坚持用标准AdamW，优化器状态是几GB级别，可能也不会爆，但8bit是更稳的选择。

3.2 梯度检查点：用时间换空间的王牌

激活值是32GB训练中的一个主要变量，梯度检查点（gradient checkpointing）是压激活值最直接的手段。它的原理是：正常训练时每一层激活值都保存，用于反向计算梯度；开启后，只保留少数中间层的输出，其他层的前向激活不保存，反向时再临时重新算一遍。这样把存储开销从“每个batch峰值”摊到“计算时间”上，训练变慢30%~50%，但显存可能掉接近一半。

在transformers中一行开启：

TrainingArguments( gradient_checkpointing=True, )

如果直接用PEFT，可以：

model = prepare_model_for_kbit_training(model, use_gradient_checkpointing=True)

还有一个细节：开启gradient_checkpointing后，model.config.use_cache必须设为False，否则会报兼容性问题，而且训练阶段本就不需要KV cache。Trainer一般会自动处理，但手写训练循环时容易漏。

3.3 QLoRA 量化参数的正确姿势

用QLoRA时，BitsAndBytesConfig里的参数决定你真省了多少钱。下面是我常用的配置：

import torch from transformers import BitsAndBytesConfig bnb_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_quant_type="nf4", bnb_4bit_use_double_quant=True, bnb_4bit_compute_dtype=torch.bfloat16, )

• bnb_4bit_quant_type="nf4"表示用NF4类型，相比普通4bit整数类型，它对近似正态分布的权重保留精度更好。QLoRA论文在大多数任务上用的就是NF4。
• bnb_4bit_use_double_quant=True表示对量化常数再做一次8bit量化，能再省一部分显存。7B模型大概能省0.5GB左右。
• bnb_4bit_compute_dtype=torch.bfloat16表示计算时权重从4bit反量化为bf16做矩阵乘，这个值和训练精度建议一致。

注意，load_in_4bit=True后模型结构里会有许多torch.nn.Linear被替换为bnb.nn.Linear4bit，但PEFT在创建LoRA层时只会绑定在有目标的Linear上，不会给量化层带来额外显存压力。

3.4 LoRA 超参如何再抠一点显存

LoRA的显存开销和可训练参数量成正比，所以降低r是有效的。很多人一上来就设r=16甚至r=32，在7B模型上可训练参数会从20M涨到80M，状态显存也会翻倍。实际效果不一定比r=8好，尤其数据量不大时，r=8已经能提供足够的表达能力。

另一个容易被忽略的是target_modules。如果只挂["q_proj", "v_proj"]，参数量会明显减少，但表达能力可能受限；如果挂["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"]，效果通常更好，但参数量和显存都上去了。我的建议是先从4个基础投影开始，验证效果后再决定要不要扩展到全连接层。

from peft import LoraConfig lora_config = LoraConfig( r=8, lora_alpha=16, target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM", )

bias="none"也是减少可训练参数的一种方式，因为模型bias数量不多，但全设成all也会增加一点显存和过拟合风险。

4. 实战配置：7B 模型 QLoRA 微调全过程

4.1 可直接修改的脚本骨架

下面这个配置我已经在多个7B模型上验证过，单卡32GB、batch=1、序列长度2048时显存峰值大约在13GB左右，离OOM还很远，甚至还能往上涨一点batch。代码基于transformers和peft，注释里写了每个参数为什么这么设。

import os os.environ["PYTORCH_CUDA_ALLOC_CONF"] = "expandable_segments:True" import torch from transformers import ( AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig, TrainingArguments, Trainer, ) from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training model_path = "Qwen/Qwen2.5-7B-Instruct" bnb_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_quant_type="nf4", bnb_4bit_use_double_quant=True, bnb_4bit_compute_dtype=torch.bfloat16, ) model = AutoModelForCausalLM.from_pretrained( model_path, quantization_config=bnb_config, device_map="auto", torch_dtype=torch.bfloat16, attn_implementation="flash_attention_2", # 支持的话优先开 ) model.config.use_cache = False model = prepare_model_for_kbit_training(model, use_gradient_checkpointing=True) lora_config = LoraConfig( r=8, lora_alpha=16, target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM", ) model = get_peft_model(model, lora_config) model.print_trainable_parameters() training_args = TrainingArguments( output_dir="./lora_qwen7b", per_device_train_batch_size=1, gradient_accumulation_steps=8, gradient_checkpointing=True, optim="paged_adamw_8bit", learning_rate=2e-4, bf16=True, max_length=2048, logging_steps=10, save_steps=200, num_train_epochs=1, ) trainer = Trainer( model=model, args=training_args, train_dataset=dataset, # 需要提前构造好 ) trainer.train()

per_device_train_batch_size=1配合gradient_accumulation_steps=8可以得到相当于batch size=8的更新效果，同时不会突然把激活值翻8倍。attn_implementation="flash_attention_2"也很关键，FlashAttention能显著降低attention部分的内存和计算，但在部分老卡上可能不支持，需要装对应的库。

4.2 训练过程中的显存变化

我在一台3090（24GB）和一台V100（32GB）上分别测过一组数据。V100不支持bf16，只测fp16；3090支持bf16但不支持FlashAttention的某些版本。整体规律很稳定：

32GB卡上，我甚至可以把batch提到2、seq长度保持在2048，显存大约到19GB，仍然安全。所以32G没有想象中紧张，前提是开关都开对。

4.3 遇到 OOM 时的降级顺序

如果按上面的脚本仍然OOM，我一般按这个顺序逐项放宽/收紧：

1. 先降序列长度：max_length=2048改成1536或1024。显存对sequence length通常是线性起步，降一步省一大块。
2. 再降batch：per_device_train_batch_size=1本来就是底，确保没有设成2。
3. 关闭flash_attention_2，因为某些环境下它反而因为反量化产生额外峰值，但一般不建议关。
4. 检查数据集的padding策略，打开group_by_length=True减少padding浪费。
5. 如果还不行，考虑把r降到4，或者从target_modules里去掉某些projection。
6. 最后再考虑换更小的基座模型，比如3B或1.5B。

很多人的OOM其实是前四步就能解决的，根本轮不到换模型。

5. OOM 排查实录与避坑清单

5.1 请求4GB但可用6GB的假 OOM

有类报错特别迷惑：错误信息说“Tried to allocate 4.00 GiB ... 5.2 GiB free”，理论上执行者的可用显存还剩5.2GB，怎么连4GB都分配不了？原因多半是CUDA缓存分配器只能在预留的空闲segment里分配连续块，而这时显存已经被切成一堆碎片，找不到单个4GB的连续空间。PyTorch 2.x之后提供了一个缓解方案：

export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True

这个设置会让CUDA缓存使用可扩展段，减少碎片。实际效果取决于显卡驱动和PyTorch版本，但值得作为第一手环境变量加上。另外，max_split_size_mb参数也可以调节缓存块最大切割大小，不过在expandable_segments面前，这个参数的历史权重已经没那么大了。

5.2 padding 和序列长度带来的隐性浪费

训练数据长度不一，如果每个batch都按最长样本padding，短样本的显存全被浪费。例如一个batch里有两条数据，长度分别是512和4000，那所有样本都会补到4000的长度，短样本的3488个token全是无效填充，但一样参与矩阵计算、一样产生激活值。这可能是OOM的一个巨大来源。

解决办法：

• 在DataCollator里设置padding="longest"确实会有这个问题，但这是必要的；关键是用group_by_length=True让Trainer把长度相近的样本凑到一个batch，减少最长和最短的差距。
• 如果数据集长度分布太散，可以自定义一个分段排序的dataset，或者直接用packing将短样本拼接成长样本。Packing能最大化利用序列长度，但实现稍复杂，需要处理attention mask和token type。
• truncation要设，不能为了保留信息让长文本全部进入，序列长度一高，激活值直接爆。

5.3 优化器状态为什么还是会占满显存

理论上LoRA只更新少量参数，优化器状态应该很小。但有些情况下你会看到实际占用还是很大。几个常见原因：

• 忘了调用prepare_model_for_kbit_training，导致原权重没有被冻结，优化器中包含了全部参数状态。
• optim参数还是"adamw_torch"，它最少保留fp32的exp_avg和exp_avg_sq，虽然只针对LoRA参数，但如果你把r设得很大、target_modules很多，可训练参数也会到百M级，优化器状态跟着到GB级。
• 有部分参数被设置为requires_grad=True，比如一些embedding或者layer norm。LoRA默认不更新这些，但如果你手动改了，状态就会增加。

建议打印：

model.print_trainable_parameters()

如果trainable params不是“几M”级别，而是几百M，这就解释了为什么显存不够。

5.4 显存一直上涨不释放的排查

有时训练刚开始显存正常，几万步后逐步爬升直到OOM。这种长期增长通常是代码里把某些张量缓存在了列表或dict里，比如为了写日志而保存了每个step的loss、针对可视化保存了中间的hidden state、或者data collator重复生成大数组没有释放。排查方法是定期打印max_memory_allocated()和memory_reserved()，如果reserved在涨，allocated也在涨但不回落，注意清掉不再用的引用。torch.cuda.empty_cache()只能释放空闲的缓存块，如果确实有张量还引用着，内存不会真正还回去。

另外，eval阶段如果也开predict_with_generate=True，模型会在验证时做生成，max_new_tokens设置过大会瞬间吃掉大量显存并在每个epoch累积。建议eval时单独用小batch，或者把generation_max_length调低。

6. 极限场景还能怎么救

6.1 CPU Offload 与虚拟内存的误区

有些朋友一看OOM就想把部分层放到CPU，用device_map="auto"时模型确实会自动把放不下的层offload到内存，但训练过程会频繁进行CPU-GPU数据搬运，速度能慢到让人怀疑人生。如果只在推理场景，CPU offload是可选方案；训练场景里，除非你只微调LoRA并且offload的是底座的量化权重，否则我建议谨慎使用。

还有一个很常见的误区是把Linux swap当“虚拟显存”。swap本身是内存的扩展，不是显存的扩展，CUDA驱动不会自动把显存换到swap里。强行调大swap的唯一结果就是整个系统卡死。Windows的“共享GPU内存”同理，它把系统内存的一部分当成显存扩展，可用但性能极差，训练任务用它只会让OOM变成死机。

6.2 多卡或加速库的出路

如果真的一块32G扛不住，多卡是最直接的出路。但单机多卡也有配置复杂度，尤其是之前体验过掉卡、NCCL超时问题的话，学习成本并不低。比较轻量的方案是DeepSpeed ZeRO Stage-2，它只把优化器状态、梯度分片到多卡，配合LoRA也不会太夸张。但这里要提醒，LoRA本来参数就少，多卡的收益主要体现在batch并行上，而不是显存翻倍。

另一个值得试的是Unsloth这个库。它把注意力、LoRA算子做了底层融合，声称可以提升训练速度并降低显存占用。我在7B模型上实测同样的QLoRA配置，Unsloth在相同的batch和seq下确实比原生HF实现更省显存，且速度更快。如果你是刚开始接触微调，直接用它提供的notebook模板会省很多力气。

6.3 工具链选择建议

现在微调LoRA/QLoRA的工具有很多，列举几个常见的供参考：

我的观点是，如果你只是想验证“这个模型适不适合我的任务”，先用LLaMA-Factory最快；如果你要写论文或产品化，需要精确控制训练流程，那就用PEFT自己写训练脚本。别一开始就上Axolotl，参数复杂度会把你拖进config文件的泥潭。

在32GB显存这个量级上，我认为真正的瓶颈不是显存大小，而是你能否精确掌握每个环节的消耗。多跑几次实验，把memory_summary()和print_trainable_parameters()当成固定动作，时间久了自然知道哪个模型该配什么参数。我们拿7B模型做一次完整的QLoRA微调，正常优化后峰值也就13GB左右，32GB还有很大余力去调大batch或seq len。但如果不去控制激活值，不量化权重，不选8bit优化器，32G就算翻倍也一样会被OOM追着跑。

我个人踩坑最多的地方是序列长度和padding，每次觉得已经调得很小时，总会发现某个data collator又把所有样本pad到了4096。后来我把打印每个batch的input_ids shape写进了日志，才彻底改掉这个毛病。如果你也正在被OOM折磨，建议先从打印shape开始，很多问题比你想的要简单得多。