企业官网建设流程全解析

手头正好有一张32GB显存的GPU，想着终于能跑点像样的模型微调了，结果刚把7B模型的数据加载进去，一个torch.cuda.OutOfMemoryError直接把我打回原形。屏幕上的红色报错看了无数遍，相信你也一样。在本地大模型微调这件事上，OOM（显存溢出）几乎是每个人都会撞上的墙，尤其是用LoRA、QLoRA这类参数高效微调方法时，很多人以为换个显卡就万事大吉，结果32GB也不够用，问题不在显存大小，而在于显存怎么花。

这篇内容主要想和你聊清楚一件事：在32GB单卡环境下，LoRA和QLoRA微调到底为什么还会OOM，以及怎么通过一系列实操手段把显存占用压下来，让训练稳定跑完。这篇文章适合所有在本地折腾模型微调的同学，不管是做科研实验、给学生在课堂上演示大模型训练，还是自己研究了几天想把手头的开源模型调成自己想要的样子，只要你手上是24GB～32GB区间的显卡，这篇文章的内容应该能帮你省下不少折腾时间。

1. 为什么LoRA和QLoRA能在32GB显卡上跑大模型

1.1 全参数微调的显存账单是怎么算出来的

先说一个基础账目。你要微调一个7B参数的模型，如果用全参数微调（Full Fine-tuning），显存里要同时放下模型权重、梯度、优化器状态这三样东西。以AdamW优化器 + 混合精度训练为例，业界有个粗略估算公式：每1B参数大约需要16GB显存。7B模型就是112GB左右，这还只是静态部分，没算中间过程的激活值（Activations）。所以全参数微调7B模型，即使是32GB的显卡也远远不够，这就是为什么大家都不怎么建议在单卡上全量微调大模型。

而LoRA（Low-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 这些线性层，r=16时，每个线性层的可训练参数规模大概是 4096×16 + 16×4096（按7B模型隐藏层4096估算），一个层大约13万参数，二三十个层加起来也就几百万参数。这几百万参数用AdamW优化器，换算下来可能只占几十MB显存，相比全参数微调的几十GB，省掉的不是一点半点。

但这里要明确一个容易被忽略的点：LoRA节省的是梯度和优化器状态的显存，模型权重本身如果以BF16/FP16格式加载，仍然要占14GB左右（7B模型）。也就是说，LoRA能在32GB显卡上跑，但跑不了特别离谱的batch size和序列长度，因为激活值仍然存在且波动很大。

1.3 QLoRA再进一步：把底座权重压到4bit

QLoRA是LoRA的加强版，它在LoRA的基础上把底座模型用4bit量化加载。7B模型用NF4（NormalFloat4）量化后，权重占用从14GB左右降到3.5GB左右，省出来的空间全部留给激活值和batch size，这就是为什么QLoRA特别适合单卡微调。

所谓NF4量化，简单理解就是用一种更聪明的4bit表示方式去近似原始浮点数权重，它比普通的int4好在分布贴近神经网络权重的真实分布，精度损失更小。推理时，QLoRA会先把4bit权重反量化为BF16再参与计算，所以训练速度会受一点影响，但换来的是显存占用大幅下降。实测下来，在32GB显卡上QLoRA微调7B模型，把序列长度拉到2048甚至4096，通常都能跑得动，全量LoRA如果不借助其他手段，在同样的长度下可能就会碰到瓶颈。

做个更直观的对比：

这个表格可以当作选型参考，但实际显存还跟序列长度、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 4096，32层）为例，假设batch size = 1，sequence length = 2048，每一层大概要保存几十MB到上百MB的激活值（取决于是否使用flash attention和gradient checkpointing），32层叠加起来就是几个GB到十几个GB的量级。

这还没完，反向传播时如果某些算子需要重算输入（比如没有开gradient checkpointing），激活值会在显存里一直存到backward执行完毕。开启gradient checkpointing之后，前向过程会丢弃中间激活值，backward时再用一个额外前向重新计算出来，相当于“用算力换显存”。这是一个在32GB单卡上特别关键的开关，我后面还会详细展开。

2.3 三个容易被忽略的隐形内存池

除了上面的“四件套”，实际训练时还有三个看不见的显存开销：

第一是CUDA context。只要PyTorch初始化CUDA，就会预留一部分显存，通常在300MB～800MB，取决于驱动和CUDA版本。

第二是PyTorch的缓存分配器（Caching Allocator）。PyTorch为了加速显存分配，会缓存一部分之前释放过的显存块，不立刻还给CUDA。这个过程会导致显存看起来只增不减，即使你删掉了某个tensor，nvidia-smi里也不一定马上降下来。

第三是CUDA malloc碎片的额外预留。当显存分配不连续时，缓存分配器会额外向CUDA申请更大的显存块，有时会多占用好几个GB，这种碎片问题在长序列训练中尤其明显。

这几项加起来，可能已经吃掉2GB～4GB显存，你还没开始训练，可用空间就已经打了折。理解了这些再做优化，才有方向感。

3. 32GB GPU上的显存优化实操

3.1 基线配置：先让程序跑起来

在优化之前，最好先建立一个能稳定运行的基线配置，然后再逐步加大规模。我的习惯是先以最小可运行配置起步，把训练流程打通，再往上涨batch size和序列长度。初始配置建议如下：

• 模型：7B量化底座（QLoRA）或BF16底座（LoRA）
• 数据类型：BF16（如果显卡支持）或FP16
• 梯度检查点（gradient_checkpointing）：开启
• batch size：1
• gradient_accumulation_steps：8（让梯度更稳）
• max_seq_length：1024
• 优化器：AdamW 8bit或paged_adamw_8bit
• LoRA rank：16

为什么从这个配置起步？因为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_size=1, gradient_accumulation_steps=8, gradient_checkpointing=True, ... )

梯度累积则是为了弥补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_4bit=True, bnb_4bit_quant_type="nf4", bnb_4bit_use_double_quant=True, bnb_4bit_compute_dtype=torch.bfloat16, )

这里有几个容易出问题的点：

第一，bnb_4bit_compute_dtype建议设置为torch.bfloat16，前提是你的GPU支持BF16（RTX 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( r=16, lora_alpha=32, lora_dropout=0.05, bias="none", task_type="CAUSAL_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里的bf16=True要对应开启；如果用FP16，就设置fp16=True。不一致时，显存占用和训练精度都会出问题。

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_2=True的选项。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量级的中文对话模型作为演示对象，既能跑得动，又能在微调后看出明显的行为变化。

实验环境大概是这样的：

• GPU：32GB显存单卡
• 模型：7B中文对话模型
• 微调方法：QLoRA（NF4量化）
• 训练框架：transformers + peft + bitsandbytes
• 显存工具：nvidia-smi+ PyTorch的torch.cuda.memory_summary()

一开始我信心满满，觉得32GB显存跑7B QLoRA应该绰绰有余，于是直接把batch_size设成了4，max_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_steps=8来模拟batch size = 8的效果。这下稳定了，显存占用降到14GB左右，非常安全。

第四步，调整序列长度和LoRA参数。稳定后，我把序列长度从2048提高到3072，显存占用上升到20GB左右，依然可跑。最后为了演示效果好，我固定在用batch size = 1，序列长度2048，梯度检查点开启，NF4量化，LoRA rank = 16，lora_alpha=32，模型表现和显存占用取得了很好的平衡。

4.3 实测显存数据与效果对比

下面这组数据是我在同一台机器上记录的（QLoRA微调7B模型，序列长度2048）：

从这张表能看出，梯度检查点带来的收益非常明显，而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_4bit=True, bnb_4bit_quant_type="nf4", bnb_4bit_use_double_quant=True, bnb_4bit_compute_dtype=torch.bfloat16, # 不支持BF16就用torch.float16 ) model = AutoModelForCausalLM.from_pretrained( model_name, quantization_config=bnb_config, device_map="auto", use_flash_attention_2=True, # 取决于transformers版本，也可用attn_implementation="flash_attention_2" ) model = prepare_model_for_kbit_training(model) model.gradient_checkpointing_enable() lora_config = LoraConfig( r=16, lora_alpha=32, lora_dropout=0.05, bias="none", task_type="CAUSAL_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_size=1, gradient_accumulation_steps=8, gradient_checkpointing=True, num_train_epochs=3, logging_steps=10, save_steps=200, learning_rate=2e-4, bf16=True, # 如果用fp16，改成fp16=True max_grad_norm=0.3, warmup_ratio=0.03, lr_scheduler_type="cosine", report_to="none", ) trainer = Trainer( model=model, args=training_args, train_dataset=train_dataset, tokenizer=tokenizer, ) trainer.train()

这个脚本我第一次跑的时候就成功了。需要注意：target_modules里的参数名要根据实际模型结构改，Qwen系列通常有这些key，Llama系列也一样，但有些模型只有q_proj、v_proj，或者名字不同，得自己看模型配置。

还有一个细节：use_flash_attention_2=True和梯度检查点在部分transformers版本里可能有冲突，如果报错，优先保留梯度检查点，去掉Flash Attention，因为显存上的收益梯度检查点更明显，速度上的损失可以接受。

5. 训练中常见OOM问题与排查技巧

5.1 典型报错速查表

训练过程中如果遇到OOM，不要急着盲目调参，先读报错信息。下面这个表格基本覆盖了我在实际训练中碰到的典型场景和解决办法：

5.2 显存碎片与缓存分配器

很多人不知道，OOM不一定代表你的模型真的需要超过32GB显存，有时只是显存碎片太多，分配不出连续块。这种情况在长序列训练里尤其常见。解决办法有几个：

第一，训练脚本开头设置环境变量PYTORCH_CUDA_ALLOC_CONF=max_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(device=None, abbreviated=False)能看到更详细的分配情况，定位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做更大的模型微调，优化的思路和方法都是一脉相承的——先搞清楚显存花在哪，再对症下药。