尧图网站建设 
LoRA 微调最让人心里没底的一步往往不是写训练脚本而是按下回车之前那句“这卡到底吃不吃得下”。我见过太多人拿着 32GB 显存的卡要么保守到只敢跑 rank4、序列长度 256白白浪费算力要么一上来就 rank64、seq2048、batch8结果 OOM 报错刷屏然后开始怀疑人生。这篇就围绕 32GB 显存这个具体档位把 LoRA 微调的显存估算逻辑、训练配置怎么定、以及跑起来之后各种报错怎么排查从头到尾捋一遍。不管你是刚拿到一张 32GB 卡想跑通第一个 LoRA 的新手还是已经跑过几轮但总在显存边缘反复横跳的老手下面这些估算方法和踩坑经验应该都能直接用上。1. 先把显存账算明白LoRA 到底吃在哪几块很多人对 LoRA 有个误解觉得“既然只训练一小部分参数那显存应该很省”。这话对了一半。LoRA 省的是优化器状态和梯度这两块大头但基座模型权重和激活值这两块该占还是占而且激活值往往才是真正把显存顶爆的元凶。所以估算显存得先把账拆成四块来看。1.1 基座权重跟训练方式无关的固定开销基座模型权重是加载进来就要占的地方跟你用不用 LoRA 没关系。它的显存占用有个很朴素的公式权重显存 ≈ 参数量 × 每参数字节数每参数字节数取决于精度FP32 是 4 字节FP16/BF16 是 2 字节INT8 是 1 字节INT4 是 0.5 字节。举个例子一个 7B 参数的模型用 BF16 加载光权重就是 7 × 2 14GB。如果是 13B 模型BF16 下就是 26GB已经逼近 32GB 的天花板了这时候你几乎没剩多少空间给激活值。这里有个特别容易忽略的点加载精度和计算精度可以不一样。你可以用 4bit 量化把权重压到 3.5GB 左右加载进来但前向计算时反量化回 BF16 参与运算。这就是 QLoRA 的核心思路也是 32GB 卡能跑 13B 甚至更大模型的关键。我实测下来7B 模型 4bit 加载大约占 3.5~4GB13B 大约 7~8GB这个数字比很多人想象的要小得多。1.2 激活值真正决定你能不能跑起来的变量激活值是前向传播过程中每一层产生的中间结果反向传播时还要用所以必须留在显存里。它的大小跟批次大小、序列长度、隐藏层维度、层数都强相关而且随序列长度增长得非常快——大致是平方级的关系。粗略估算激活值的经验公式是这样的激活显存 ≈ batch_size × seq_len × hidden_size × num_layers × 系数这个系数跟具体实现有关通常在 10~20 之间浮动。拿一个 7B 模型举例hidden_size 约 4096num_layers 约 32。如果 batch1、seq512激活值大概在 1~2GB 量级但如果 seq 拉到 2048、batch 拉到 4激活值能轻松冲到 15GB 以上。这就是为什么很多人权重明明放得下一跑就 OOM——问题出在激活值上。梯度检查点gradient checkpointing是这里最有效的救命手段。它牺牲约 20%~30% 的计算时间换取激活值显存大幅下降通常能砍掉 60%~70%。开启之后上面那个 15GB 的场景可能直接降到 5GB 左右。代价是训练变慢但对于 32GB 这种“不上不下”的档位我基本建议默认打开。1.3 LoRA 自身的参数和优化器状态小但别忽略LoRA 只训练低秩矩阵 A 和 B参数量大概是原模型的 0.1%~1%。以 7B 模型、rank16 为例可训练参数大约几百万到千万级别BF16 下占几十 MB加上 AdamW 优化器状态每个参数 2 个动量FP32 下 8 字节总共也就几百 MB。相比权重和激活值这块基本可以忽略不计。但有个例外如果你把 LoRA 加在了所有线性层上q、k、v、o、gate、up、down 全加可训练参数会明显上升rank 再开到 64、128这时候 LoRA 参数加优化器状态可能到 1~2GB。所以 rank 不是随便开的后面会细说。1.4 一张表看懂 32GB 能跑什么把上面几块合起来我给一个实测参考表模型以 7B 和 13B 为例精度按常见配置模型规模加载精度权重占用激活值(seq1024,batch2,开checkpoint)LoRA优化器合计估算7BBF16~14GB~4GB~0.5GB~18.5GB7B4bit~4GB~4GB~0.5GB~8.5GB13B4bit~8GB~6GB~0.8GB~14.8GB13BBF16~26GB~6GB~0.8GB~32.8GB危险32B4bit~18GB~8GB~1GB~27GB从表里能看出几个结论7B 用 BF16 在 32GB 上跑 seq1024、batch2 是稳的13B 想上 32GB 基本必须走 4bit32B 用 4bit 勉强能跑但余量很小seq 和 batch 都得压。这张表是我自己反复跑出来的经验值实际会因框架实现、优化器选择有 10%~20% 浮动但用来做第一轮判断足够。2. 32GB 卡上的配置怎么定从保守到激进的调参路线知道了显存花在哪接下来就是怎么把配置定得既不浪费又不出事。我的习惯是先跑通最小配置再逐步往上加而不是一上来就冲极限。下面按参数重要性一个个说。2.1 批次大小与梯度累积显存和吞吐的平衡术batch_size 是显存最敏感的旋钮之一因为它直接乘在激活值上。32GB 卡上我的建议是7B BF16batch_size 从 1 或 2 起步seq1024 时 2 比较稳7B 4bitbatch_size 可以到 4~813B 4bitbatch_size 从 1 起步seq 控制在 1024 以内但 batch_size 太小会让训练不稳定、梯度噪声大。这时候用梯度累积来补设 batch_size1、gradient_accumulation_steps8等效批次就是 8显存只按 1 算。这是 32GB 卡上最实用的技巧之一代价只是训练时间变长显存压力几乎不变。注意梯度累积不会增加激活值显存但会让每个 step 的耗时线性增加。如果你的数据量不大这个交换非常划算。2.2 序列长度最容易被低估的显存杀手seq_len 对激活值的影响是平方级的很多人只盯着 batch 却忽略了它。我踩过最深的坑就是batch1 看着很安全结果 seq 设了 4096直接 OOM。后来才反应过来长序列下注意力矩阵本身就是 seq² 的增长。32GB 卡上的经验值7B BF16seq 建议 1024极限能到 2048 但 batch 必须压到 17B 4bitseq 可以到 2048batch2 也还行13B 4bitseq 建议 1024 以内如果你的任务确实需要长文本比如长文档理解、代码补全优先考虑降低 batch 而不是砍 seq因为 seq 砍了可能直接影响任务效果batch 砍了只是训练慢一点。2.3 LoRA rank 与 target_modules省显存还是保效果rank 决定了 LoRA 低秩矩阵的维度直接影响可训练参数量。常见取值 8、16、32、64。我的经验是简单任务风格迁移、格式对齐rank8 或 16 足够复杂任务领域知识注入、多任务rank32 或 6432GB 卡上 rank 开到 64 完全没问题LoRA 参数那点显存不是瓶颈真正影响显存的是target_modules。只加 q、v 两个投影层参数量最小加到 q、k、v、o 全部注意力层参数量翻倍如果连 MLP 层的 gate、up、down 都加上可训练参数会显著上升。我一般建议先从 q、v 起步效果不够再逐步加层而不是一上来就全加。2.4 优化器与精度选择省显存的隐藏开关优化器这块AdamW 是最常用的但它每个参数要存 2 个 FP32 动量显存开销是参数量的 8 倍。对于 LoRA 这种小参数量场景无所谓但如果你做了全参数微调或者 rank 开得很大可以考虑8bit AdamW能把优化器状态压到 1/4。精度方面BF16 优先于 FP16。BF16 动态范围大不容易出现梯度溢出训练更稳。FP16 虽然也能用但需要配合 loss scaling稍不注意就 NaN。32GB 卡基本都支持 BF16没理由不用。至于 4bit 量化加载配合bnb_4bit_compute_dtypebf16和bnb_4bit_quant_typenf4是我在 32GB 上跑 13B 的标配。nf4 比 fp4 在权重分布上更友好实测 loss 曲线更平滑。3. 跑起来之后的常见报错一份排查链路配置定好了不代表就万事大吉实际跑起来各种报错才是常态。我把 32GB 卡上最常遇到的几类问题按排查顺序列出来你可以对着自己的报错逐条比对。3.1 CUDA out of memory先分清是权重还是激活OOM 是最常见的但原因分两种处理方式完全不同。如果是加载模型时就 OOM说明权重放不下。这时候的解法是换 4bit 量化加载、换更小的模型、或者用device_mapauto让框架自动分片但单卡场景帮助有限。判断方法很简单看报错发生在加载阶段还是第一个 step。如果是训练中途 OOM基本是激活值的问题。解法优先级开 gradient checkpointing 降 batch_size 降 seq_len 降 rank。我一般按这个顺序试因为对效果的影响是从小到大。还有一个隐蔽的坑PyTorch 的显存缓存机制。有时候nvidia-smi显示显存占满但其实是缓存没释放不是真的 OOM。可以在代码里加torch.cuda.empty_cache()或者设置PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True来减少碎片。3.2 loss 变成 NaN 或不下降精度和学习率的问题NaN 通常有几个来源FP16 溢出、学习率过大、数据里有异常值。排查顺序确认用的是 BF16 而不是 FP16学习率从 2e-4 降到 1e-4 甚至 5e-5 试试检查数据里有没有空样本、超长样本、乱码loss 不下降则更可能是配置问题rank 太小、target_modules 加得不对、或者学习率太低。我遇到过一次 loss 死活不动最后发现是 LoRA 只加在了 q 层信息量不够加到 q、v 之后立刻正常。3.3 训练速度慢得离谱checkpoint 和 batch 的取舍开了 gradient checkpointing 之后训练变慢是正常的但如果慢到无法接受就要权衡了。我的做法是先用 checkpoint 保证能跑通跑通之后再尝试关掉它、同时降 batch 或 seq看能不能在显存和速度之间找到更好的平衡点。另一个拖慢速度的常见原因是dataloader 的 num_workers 设成了 0导致数据加载成为瓶颈。32GB 卡一般配 4~8 个 worker 比较合适具体看 CPU 核数。3.4 显存占用忽高忽低碎片化的锅有时候你会发现显存占用不稳定跑着跑着突然涨上去。这多半是显存碎片化。除了上面提到的expandable_segments还可以在训练循环里定期调用torch.cuda.empty_cache()。不过要注意频繁调用 empty_cache 本身也有开销一般每个 epoch 调一次就够。4. 工具链选型32GB 卡上我用什么跑 LoRA配置和排查都清楚了最后说说工具。现在 LoRA 微调的工具链已经很成熟选对了能省掉大量重复劳动。4.1 主流框架的取舍我主要用两类工具一类是命令行/配置驱动的比如 LLaMA-Factory优点是开箱即用、配置集中、社区活跃适合快速跑通和复现另一类是代码级的比如直接基于 transformers peft 写训练脚本优点是灵活、可控适合做定制化改动。LLaMA-Factory 在 32GB 卡上的体验很好它内置了显存优化选项配置文件里直接写gradient_checkpointing: true、flash_attn: true就能生效。对于不想折腾底层代码的人我强烈建议从这里起步。4.2 关键依赖的版本坑工具链最烦的是版本兼容。我踩过的坑包括peft 版本和 transformers 版本不匹配导致 LoRA 层加载失败、bitsandbytes 版本太老不支持 nf4、flash-attn 编译失败等。我的建议是用官方推荐的版本组合别自己乱升bitsandbytes 至少 0.41 以上才稳定支持 4bitflash-attn 能装就装对长序列的显存和速度都有帮助但编译确实折腾提示如果 flash-attn 装不上退而求其次用 PyTorch 自带的 scaled_dot_product_attention效果也不差只是长序列下略慢。4.3 从零跑通一个 7B LoRA 的最小配置给一个我在 32GB 卡上验证过的 7B 4bit 最小可用配置直接抄model_name_or_path: your-7b-model quantization_bit: 4 bnb_4bit_compute_dtype: bf16 bnb_4bit_quant_type: nf4 stage: sft lora_rank: 16 lora_target: q_proj,v_proj per_device_train_batch_size: 2 gradient_accumulation_steps: 4 cutoff_len: 1024 gradient_checkpointing: true learning_rate: 1e-4 num_train_epochs: 3 bf16: true这套配置在 32GB 上跑 7B 大概占 10~12GB余量充足可以放心加 batch 或 seq。跑通之后再根据任务效果调 rank 和 target_modules。5. 几个我反复验证过的实操心得最后分享几条从实际项目里攒下来的经验都是文档里不太会写、但真能省时间的。第一条先估算再动手别靠试。每次换模型或改配置我都会先用第 1 节的公式粗算一遍心里有个数再跑。这样 OOM 的时候能立刻判断是权重问题还是激活问题排查效率高很多。第二条显存监控要常态化。训练时开着nvidia-smi -l 1或者用 wandb 记录显存曲线能提前发现缓慢增长的显存泄漏。我遇到过一次显存每个 step 涨一点最后发现是日志里存了 tensor 没释放。第三条4bit 不是万能药。4bit 加载确实省显存但会带来轻微的效果损失而且训练速度可能变慢反量化有开销。如果 7B 用 BF16 能跑下就别急着上 4bit。量化是给放不下的时候用的不是默认选项。第四条数据质量比配置重要。我见过太多人花几天调 rank、调学习率结果数据里一半是重复样本。LoRA 微调对数据质量非常敏感几千条干净数据的效果往往好过几万条脏数据。动手调参之前先把数据过一遍。第五条保存和恢复要测。LoRA 权重保存下来之后一定要实际加载一次验证能正常推理别等到训练完才发现保存的格式有问题。这个坑我踩过一次白跑了一整晚。关于 32GB 卡跑 LoRA核心就一句话权重、激活、优化器三块账算清楚配置从保守往上加报错按权重/激活分类排查。剩下的就是多跑、多记录、多总结跑得多了自然就有手感了。 32GB显存LoRA微调实战：显存估算、配置调优与报错排查
LoRA 微调最让人心里没底的一步往往不是写训练脚本而是按下回车之前那句“这卡到底吃不吃得下”。我见过太多人拿着 32GB 显存的卡要么保守到只敢跑 rank4、序列长度 256白白浪费算力要么一上来就 rank64、seq2048、batch8结果 OOM 报错刷屏然后开始怀疑人生。这篇就围绕 32GB 显存这个具体档位把 LoRA 微调的显存估算逻辑、训练配置怎么定、以及跑起来之后各种报错怎么排查从头到尾捋一遍。不管你是刚拿到一张 32GB 卡想跑通第一个 LoRA 的新手还是已经跑过几轮但总在显存边缘反复横跳的老手下面这些估算方法和踩坑经验应该都能直接用上。1. 先把显存账算明白LoRA 到底吃在哪几块很多人对 LoRA 有个误解觉得“既然只训练一小部分参数那显存应该很省”。这话对了一半。LoRA 省的是优化器状态和梯度这两块大头但基座模型权重和激活值这两块该占还是占而且激活值往往才是真正把显存顶爆的元凶。所以估算显存得先把账拆成四块来看。1.1 基座权重跟训练方式无关的固定开销基座模型权重是加载进来就要占的地方跟你用不用 LoRA 没关系。它的显存占用有个很朴素的公式权重显存 ≈ 参数量 × 每参数字节数每参数字节数取决于精度FP32 是 4 字节FP16/BF16 是 2 字节INT8 是 1 字节INT4 是 0.5 字节。举个例子一个 7B 参数的模型用 BF16 加载光权重就是 7 × 2 14GB。如果是 13B 模型BF16 下就是 26GB已经逼近 32GB 的天花板了这时候你几乎没剩多少空间给激活值。这里有个特别容易忽略的点加载精度和计算精度可以不一样。你可以用 4bit 量化把权重压到 3.5GB 左右加载进来但前向计算时反量化回 BF16 参与运算。这就是 QLoRA 的核心思路也是 32GB 卡能跑 13B 甚至更大模型的关键。我实测下来7B 模型 4bit 加载大约占 3.5~4GB13B 大约 7~8GB这个数字比很多人想象的要小得多。1.2 激活值真正决定你能不能跑起来的变量激活值是前向传播过程中每一层产生的中间结果反向传播时还要用所以必须留在显存里。它的大小跟批次大小、序列长度、隐藏层维度、层数都强相关而且随序列长度增长得非常快——大致是平方级的关系。粗略估算激活值的经验公式是这样的激活显存 ≈ batch_size × seq_len × hidden_size × num_layers × 系数这个系数跟具体实现有关通常在 10~20 之间浮动。拿一个 7B 模型举例hidden_size 约 4096num_layers 约 32。如果 batch1、seq512激活值大概在 1~2GB 量级但如果 seq 拉到 2048、batch 拉到 4激活值能轻松冲到 15GB 以上。这就是为什么很多人权重明明放得下一跑就 OOM——问题出在激活值上。梯度检查点gradient checkpointing是这里最有效的救命手段。它牺牲约 20%~30% 的计算时间换取激活值显存大幅下降通常能砍掉 60%~70%。开启之后上面那个 15GB 的场景可能直接降到 5GB 左右。代价是训练变慢但对于 32GB 这种“不上不下”的档位我基本建议默认打开。1.3 LoRA 自身的参数和优化器状态小但别忽略LoRA 只训练低秩矩阵 A 和 B参数量大概是原模型的 0.1%~1%。以 7B 模型、rank16 为例可训练参数大约几百万到千万级别BF16 下占几十 MB加上 AdamW 优化器状态每个参数 2 个动量FP32 下 8 字节总共也就几百 MB。相比权重和激活值这块基本可以忽略不计。但有个例外如果你把 LoRA 加在了所有线性层上q、k、v、o、gate、up、down 全加可训练参数会明显上升rank 再开到 64、128这时候 LoRA 参数加优化器状态可能到 1~2GB。所以 rank 不是随便开的后面会细说。1.4 一张表看懂 32GB 能跑什么把上面几块合起来我给一个实测参考表模型以 7B 和 13B 为例精度按常见配置模型规模加载精度权重占用激活值(seq1024,batch2,开checkpoint)LoRA优化器合计估算7BBF16~14GB~4GB~0.5GB~18.5GB7B4bit~4GB~4GB~0.5GB~8.5GB13B4bit~8GB~6GB~0.8GB~14.8GB13BBF16~26GB~6GB~0.8GB~32.8GB危险32B4bit~18GB~8GB~1GB~27GB从表里能看出几个结论7B 用 BF16 在 32GB 上跑 seq1024、batch2 是稳的13B 想上 32GB 基本必须走 4bit32B 用 4bit 勉强能跑但余量很小seq 和 batch 都得压。这张表是我自己反复跑出来的经验值实际会因框架实现、优化器选择有 10%~20% 浮动但用来做第一轮判断足够。2. 32GB 卡上的配置怎么定从保守到激进的调参路线知道了显存花在哪接下来就是怎么把配置定得既不浪费又不出事。我的习惯是先跑通最小配置再逐步往上加而不是一上来就冲极限。下面按参数重要性一个个说。2.1 批次大小与梯度累积显存和吞吐的平衡术batch_size 是显存最敏感的旋钮之一因为它直接乘在激活值上。32GB 卡上我的建议是7B BF16batch_size 从 1 或 2 起步seq1024 时 2 比较稳7B 4bitbatch_size 可以到 4~813B 4bitbatch_size 从 1 起步seq 控制在 1024 以内但 batch_size 太小会让训练不稳定、梯度噪声大。这时候用梯度累积来补设 batch_size1、gradient_accumulation_steps8等效批次就是 8显存只按 1 算。这是 32GB 卡上最实用的技巧之一代价只是训练时间变长显存压力几乎不变。注意梯度累积不会增加激活值显存但会让每个 step 的耗时线性增加。如果你的数据量不大这个交换非常划算。2.2 序列长度最容易被低估的显存杀手seq_len 对激活值的影响是平方级的很多人只盯着 batch 却忽略了它。我踩过最深的坑就是batch1 看着很安全结果 seq 设了 4096直接 OOM。后来才反应过来长序列下注意力矩阵本身就是 seq² 的增长。32GB 卡上的经验值7B BF16seq 建议 1024极限能到 2048 但 batch 必须压到 17B 4bitseq 可以到 2048batch2 也还行13B 4bitseq 建议 1024 以内如果你的任务确实需要长文本比如长文档理解、代码补全优先考虑降低 batch 而不是砍 seq因为 seq 砍了可能直接影响任务效果batch 砍了只是训练慢一点。2.3 LoRA rank 与 target_modules省显存还是保效果rank 决定了 LoRA 低秩矩阵的维度直接影响可训练参数量。常见取值 8、16、32、64。我的经验是简单任务风格迁移、格式对齐rank8 或 16 足够复杂任务领域知识注入、多任务rank32 或 6432GB 卡上 rank 开到 64 完全没问题LoRA 参数那点显存不是瓶颈真正影响显存的是target_modules。只加 q、v 两个投影层参数量最小加到 q、k、v、o 全部注意力层参数量翻倍如果连 MLP 层的 gate、up、down 都加上可训练参数会显著上升。我一般建议先从 q、v 起步效果不够再逐步加层而不是一上来就全加。2.4 优化器与精度选择省显存的隐藏开关优化器这块AdamW 是最常用的但它每个参数要存 2 个 FP32 动量显存开销是参数量的 8 倍。对于 LoRA 这种小参数量场景无所谓但如果你做了全参数微调或者 rank 开得很大可以考虑8bit AdamW能把优化器状态压到 1/4。精度方面BF16 优先于 FP16。BF16 动态范围大不容易出现梯度溢出训练更稳。FP16 虽然也能用但需要配合 loss scaling稍不注意就 NaN。32GB 卡基本都支持 BF16没理由不用。至于 4bit 量化加载配合bnb_4bit_compute_dtypebf16和bnb_4bit_quant_typenf4是我在 32GB 上跑 13B 的标配。nf4 比 fp4 在权重分布上更友好实测 loss 曲线更平滑。3. 跑起来之后的常见报错一份排查链路配置定好了不代表就万事大吉实际跑起来各种报错才是常态。我把 32GB 卡上最常遇到的几类问题按排查顺序列出来你可以对着自己的报错逐条比对。3.1 CUDA out of memory先分清是权重还是激活OOM 是最常见的但原因分两种处理方式完全不同。如果是加载模型时就 OOM说明权重放不下。这时候的解法是换 4bit 量化加载、换更小的模型、或者用device_mapauto让框架自动分片但单卡场景帮助有限。判断方法很简单看报错发生在加载阶段还是第一个 step。如果是训练中途 OOM基本是激活值的问题。解法优先级开 gradient checkpointing 降 batch_size 降 seq_len 降 rank。我一般按这个顺序试因为对效果的影响是从小到大。还有一个隐蔽的坑PyTorch 的显存缓存机制。有时候nvidia-smi显示显存占满但其实是缓存没释放不是真的 OOM。可以在代码里加torch.cuda.empty_cache()或者设置PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True来减少碎片。3.2 loss 变成 NaN 或不下降精度和学习率的问题NaN 通常有几个来源FP16 溢出、学习率过大、数据里有异常值。排查顺序确认用的是 BF16 而不是 FP16学习率从 2e-4 降到 1e-4 甚至 5e-5 试试检查数据里有没有空样本、超长样本、乱码loss 不下降则更可能是配置问题rank 太小、target_modules 加得不对、或者学习率太低。我遇到过一次 loss 死活不动最后发现是 LoRA 只加在了 q 层信息量不够加到 q、v 之后立刻正常。3.3 训练速度慢得离谱checkpoint 和 batch 的取舍开了 gradient checkpointing 之后训练变慢是正常的但如果慢到无法接受就要权衡了。我的做法是先用 checkpoint 保证能跑通跑通之后再尝试关掉它、同时降 batch 或 seq看能不能在显存和速度之间找到更好的平衡点。另一个拖慢速度的常见原因是dataloader 的 num_workers 设成了 0导致数据加载成为瓶颈。32GB 卡一般配 4~8 个 worker 比较合适具体看 CPU 核数。3.4 显存占用忽高忽低碎片化的锅有时候你会发现显存占用不稳定跑着跑着突然涨上去。这多半是显存碎片化。除了上面提到的expandable_segments还可以在训练循环里定期调用torch.cuda.empty_cache()。不过要注意频繁调用 empty_cache 本身也有开销一般每个 epoch 调一次就够。4. 工具链选型32GB 卡上我用什么跑 LoRA配置和排查都清楚了最后说说工具。现在 LoRA 微调的工具链已经很成熟选对了能省掉大量重复劳动。4.1 主流框架的取舍我主要用两类工具一类是命令行/配置驱动的比如 LLaMA-Factory优点是开箱即用、配置集中、社区活跃适合快速跑通和复现另一类是代码级的比如直接基于 transformers peft 写训练脚本优点是灵活、可控适合做定制化改动。LLaMA-Factory 在 32GB 卡上的体验很好它内置了显存优化选项配置文件里直接写gradient_checkpointing: true、flash_attn: true就能生效。对于不想折腾底层代码的人我强烈建议从这里起步。4.2 关键依赖的版本坑工具链最烦的是版本兼容。我踩过的坑包括peft 版本和 transformers 版本不匹配导致 LoRA 层加载失败、bitsandbytes 版本太老不支持 nf4、flash-attn 编译失败等。我的建议是用官方推荐的版本组合别自己乱升bitsandbytes 至少 0.41 以上才稳定支持 4bitflash-attn 能装就装对长序列的显存和速度都有帮助但编译确实折腾提示如果 flash-attn 装不上退而求其次用 PyTorch 自带的 scaled_dot_product_attention效果也不差只是长序列下略慢。4.3 从零跑通一个 7B LoRA 的最小配置给一个我在 32GB 卡上验证过的 7B 4bit 最小可用配置直接抄model_name_or_path: your-7b-model quantization_bit: 4 bnb_4bit_compute_dtype: bf16 bnb_4bit_quant_type: nf4 stage: sft lora_rank: 16 lora_target: q_proj,v_proj per_device_train_batch_size: 2 gradient_accumulation_steps: 4 cutoff_len: 1024 gradient_checkpointing: true learning_rate: 1e-4 num_train_epochs: 3 bf16: true这套配置在 32GB 上跑 7B 大概占 10~12GB余量充足可以放心加 batch 或 seq。跑通之后再根据任务效果调 rank 和 target_modules。5. 几个我反复验证过的实操心得最后分享几条从实际项目里攒下来的经验都是文档里不太会写、但真能省时间的。第一条先估算再动手别靠试。每次换模型或改配置我都会先用第 1 节的公式粗算一遍心里有个数再跑。这样 OOM 的时候能立刻判断是权重问题还是激活问题排查效率高很多。第二条显存监控要常态化。训练时开着nvidia-smi -l 1或者用 wandb 记录显存曲线能提前发现缓慢增长的显存泄漏。我遇到过一次显存每个 step 涨一点最后发现是日志里存了 tensor 没释放。第三条4bit 不是万能药。4bit 加载确实省显存但会带来轻微的效果损失而且训练速度可能变慢反量化有开销。如果 7B 用 BF16 能跑下就别急着上 4bit。量化是给放不下的时候用的不是默认选项。第四条数据质量比配置重要。我见过太多人花几天调 rank、调学习率结果数据里一半是重复样本。LoRA 微调对数据质量非常敏感几千条干净数据的效果往往好过几万条脏数据。动手调参之前先把数据过一遍。第五条保存和恢复要测。LoRA 权重保存下来之后一定要实际加载一次验证能正常推理别等到训练完才发现保存的格式有问题。这个坑我踩过一次白跑了一整晚。关于 32GB 卡跑 LoRA核心就一句话权重、激活、优化器三块账算清楚配置从保守往上加报错按权重/激活分类排查。剩下的就是多跑、多记录、多总结跑得多了自然就有手感了。