1. 大模型微调到底在做什么先把话说直白一点大模型微调不是从头训练一个模型也不是给模型“灌知识”而是拿一个已经具备通用能力的基座模型用你自己的数据让它“偏”向你的任务。你可以把它理解成一位已经读完大学的毕业生现在要让他快速适应你公司的业务规范——他不需要重新读一遍小学到大学只需要在你的业务场景里做针对性训练。这件事为什么这两年这么火因为通用大模型虽然什么都懂一点但在具体行业里往往“不够专业”。比如你让它处理医疗病历结构化它可能给你写出一段通顺但格式完全不对的文字你让它做法律合同要素抽取它可能漏掉关键条款。微调就是解决这个“最后一公里”问题的核心手段。但问题来了显存。这是几乎所有人在跑通第一个微调任务时撞上的第一堵墙。一个 7B 参数的模型全量微调动辄需要 80G 以上的显存普通开发者手里只有一张 8G、12G 或 24G 的卡根本跑不起来。于是LoRA、QLoRA这些参数高效微调方法就成了破局的关键。这一讲我围绕“基础理论 显存破局”这条主线把微调的底层逻辑、显存到底被什么吃掉了、LoRA 和 QLoRA 是怎么把显存压下来的以及实际跑通第一个微调任务时你会遇到什么全部拆开讲清楚。适合刚接触微调、手里显卡不算宽裕、想真正跑通一个LoRA 微调实战的读者。2. 微调的核心思路与方案选型2.1 全量微调、LoRA、QLoRA 到底差在哪在动手之前必须先把三条路线的本质区别搞清楚否则你会在选型上反复摇摆。全量微调Full Fine-tuning是最直接的方式把模型所有参数都拿出来用你的数据更新一遍。效果上限最高但代价也最大。一个 7B 模型FP16 精度下光权重就占 14GB加上梯度、优化器状态、激活值实际训练显存需求通常在 80GB 以上。这不是普通设备能承受的。LoRALow-Rank Adaptation的思路非常巧妙既然全量更新参数太贵那我就不动原来的权重而是在每一层旁边“挂”一对小矩阵只训练这对小矩阵。原始权重冻结梯度只流过这些小矩阵。这样一来可训练参数量能降到原来的千分之一甚至更低显存需求大幅下降。QLoRA则是在 LoRA 基础上再加一层量化把冻结的基座模型用 4-bit 量化加载进一步压缩显存占用。它让“单张 8G 显存微调 7B 模型”从不可能变成了可能。我用一个表格把三者的关键差异列清楚方案可训练参数比例7B 模型训练显存约效果上限适用场景全量微调100%80GB最高数据充足、算力充裕LoRA0.1%~1%16~24GB接近全量大多数业务微调QLoRA0.1%~1%6~12GB略低于 LoRA显存受限、快速验证注意这里的显存数字是经验值具体取决于序列长度、batch size、梯度累积等配置不是绝对值。2.2 为什么我优先推荐从 LoRA 入手很多人一上来就想搞全量微调觉得“参数更新得多效果肯定好”。这个直觉在微调场景里往往是错的。第一大多数业务场景的数据量根本喂不饱全量微调。你可能只有几千条甚至几百条标注数据全量微调在这种数据量下极易过拟合效果反而不如 LoRA 稳定。第二LoRA 的产物是一个很小的适配器文件通常只有几十到几百 MB方便保存、切换、组合。你可以为不同任务训练不同的 LoRA推理时按需加载这在工程上极其灵活。第三LoRA 的训练门槛低让你能把精力放在数据质量和任务设计上而不是天天和显存报错搏斗。所以我的建议很明确除非你有明确证据表明 LoRA 效果不够否则先从 LoRA 或 QLoRA 开始。这也是当前大模型微调实战里最主流的选择。2.3 显存到底被什么吃掉了要破局先要知道敌人是谁。训练时的显存占用主要来自四块模型权重FP16 下每个参数占 2 字节7B 模型约 14GB。梯度每个可训练参数对应一份梯度全量微调时同样是 14GB。优化器状态以 Adam 为例每个参数要存一阶矩和二阶矩FP32 下是 8 字节/参数7B 模型约 56GB。激活值前向传播过程中每层的中间输出和 batch size、序列长度强相关。把这四项加起来全量微调 7B 模型轻松突破 80GB。而 LoRA 把梯度、优化器状态这两块大头压缩到了只针对小矩阵QLoRA 又把权重压到 4-bit显存自然就下来了。3. 显存破局的核心原理拆解3.1 LoRA 的低秩分解为什么有效LoRA 的核心假设是模型在适应新任务时权重的变化量具有“低秩”特性。什么意思就是说虽然原始权重矩阵很大比如 4096×4096但真正需要调整的方向其实很少可以用两个小矩阵相乘来近似。具体做法是对于原始权重 W维度 d×kLoRA 引入两个矩阵 Ad×r和 Br×k其中 r 远小于 d 和 k通常取 8、16、32 这种量级。前向传播变成h Wx BAx训练时 W 冻结只更新 A 和 B。可训练参数量从 d×k 降到 r×(dk)。以 4096×4096 为例全量是 1600 万参数r16 时 LoRA 只有约 13 万参数差了 100 多倍。这就是 LoRA 能把显存压下来的根本原因梯度和优化器状态只针对这 13 万参数而不是 1600 万。3.2 QLoRA 的 4-bit 量化是怎么做的QLoRA 在 LoRA 基础上做了三件事第一4-bit NormalFloat 量化。它把基座模型的权重从 FP16 压到 4-bit显存直接降到原来的四分之一。7B 模型的权重占用从 14GB 降到约 3.5GB。第二双重量化。量化本身会产生一些常数QLoRA 对这些常数再做一次量化进一步省显存。第三分页优化器。当显存不够时把优化器状态临时挪到内存需要时再调回来避免直接 OOM。这三招组合下来8G 显存本地部署并微调 7B 模型就成了现实。代价是训练速度会慢一些因为量化和反量化有额外计算开销。3.3 关键参数怎么选LoRA 有几个参数直接决定效果和显存我逐个说r秩越大表达能力越强但显存和过拟合风险也越高。一般从 8 或 16 起步数据复杂可以上 32 或 64。lora_alpha缩放系数通常设为 r 的 1~2 倍。经验上 alpha/r 的比值比绝对值更重要。lora_dropout防止过拟合小数据集建议 0.05~0.1。target_modules决定给哪些层挂 LoRA。通常挂 attention 的 q、k、v、o 投影层效果和成本的平衡最好。实操心得如果你不确定 target_modules 怎么选先用 q_proj 和 v_proj 跑一版再逐步加上 k_proj、o_proj 对比效果。不要一上来就全挂那样显存和调参成本都会上去。4. 跑通第一个 LoRA 微调的完整实操4.1 环境准备与依赖安装先把环境搭起来。我以主流的 transformers peft trl 技术栈为例这套组合对新手最友好文档也全。pip install torch transformers peft trl datasets accelerate bitsandbytes这里每个包的作用transformers加载模型和分词器。peft实现 LoRA、QLoRA 的核心库。trl提供 SFTTrainer简化监督微调流程。datasets加载和处理数据。accelerate管理设备分配和混合精度。bitsandbytesQLoRA 的 4-bit 量化依赖。注意bitsandbytes 对 CUDA 版本有要求装完最好跑一句python -c import bitsandbytes验证一下报错的话优先检查 CUDA 和驱动版本匹配。4.2 数据准备从原始文本到训练样本微调效果的上限由数据决定。很多人模型跑通了但效果差问题几乎都出在数据上。数据格式上指令微调通常用“指令-输入-输出”三元组。我建议你先把原始数据整理成 JSONL每行一个样本{instruction: 提取以下文本中的驾驶员要素, input: 张三男35岁驾龄10年, output: 姓名张三性别男年龄35驾龄10年}如果你手里只有一堆 txt 文档可以用脚本批量转成这种结构。核心思路是把文档按段落切分为每段设计一个合适的指令把原文作为 input把你要的答案作为 output。实操心得数据量不是越多越好。500~2000 条高质量、格式统一的样本往往比几万条脏数据效果好得多。清洗数据时重点检查三件事格式是否统一、答案是否准确、有没有重复样本。4.3 模型加载与 LoRA 配置加载模型时QLoRA 需要指定量化配置from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig import torch bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_quant_typenf4, bnb_4bit_compute_dtypetorch.bfloat16, bnb_4bit_use_double_quantTrue, ) model AutoModelForCausalLM.from_pretrained( Qwen/Qwen2.5-7B, quantization_configbnb_config, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-7B)然后配置 LoRAfrom peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training model prepare_model_for_kbit_training(model) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) model get_peft_model(model, lora_config) model.print_trainable_parameters()跑完最后一行你会看到可训练参数占比通常在 0.1%~1% 之间。这个数字就是 LoRA 省显存的直接证据。4.4 训练参数配置与启动用 SFTTrainer 把训练流程串起来from transformers import TrainingArguments from trl import SFTTrainer training_args TrainingArguments( output_dir./lora_output, per_device_train_batch_size1, gradient_accumulation_steps8, num_train_epochs3, learning_rate2e-4, fp16False, bf16True, logging_steps10, save_strategyepoch, optimpaged_adamw_8bit, ) trainer SFTTrainer( modelmodel, argstraining_args, train_datasettrain_dataset, tokenizertokenizer, ) trainer.train()几个关键点解释一下per_device_train_batch_size1 gradient_accumulation_steps8单步显存不够时用梯度累积模拟大 batch。等效 batch size 是 8。optimpaged_adamw_8bit分页 8-bit 优化器QLoRA 的标配能显著降显存。bf16True比 fp16 更稳定不容易出现梯度溢出。注意如果训练中报 OOM优先降 batch size 或序列长度其次考虑降 r。不要一上来就换更小的模型先榨干现有配置的潜力。4.5 训练产物与推理验证训练结束后输出目录里会有 adapter 文件。加载推理时先加载基座模型再挂上 adapterfrom peft import PeftModel base_model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2.5-7B, device_mapauto) model PeftModel.from_pretrained(base_model, ./lora_output)然后就可以用你的测试样本验证效果了。重点看三件事格式是否稳定、答案是否准确、有没有出现重复或截断。5. 常见问题与排查技巧实录5.1 显存相关问题的排查顺序显存报错是微调路上最高频的问题。我整理了一个排查顺序按这个走基本能定位现象可能原因解决方向加载模型就 OOM没用 4-bit 量化加 BitsAndBytesConfig训练几步后 OOM激活值累积降 batch size 或序列长度训练中途突然 OOM内存碎片设 PYTORCH_CUDA_ALLOC_CONF推理时 OOMadapter 和基座重复加载检查加载逻辑实操心得设置环境变量PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True能有效缓解内存碎片导致的 OOM这个技巧很多人不知道但实测很管用。5.2 效果不达预期的常见原因模型跑通了但效果差通常不是模型的问题而是这几个地方数据格式不统一训练样本里有的用冒号有的用等号模型学出来的格式就会乱。学习率过高LoRA 常用 1e-4 到 3e-4太高会导致训练不稳定。训练轮数过多小数据集跑 3 轮以上很容易过拟合表现为训练 loss 降但验证效果变差。target_modules 选少了只挂 q、v 有时表达能力不够可以试试加上 k、o。5.3 训练速度太慢怎么办QLoRA 因为量化开销速度会比 LoRA 慢。如果速度是瓶颈可以考虑用 LoRA 替代 QLoRA显存够的话。开启 gradient_checkpointing用时间换显存。用 flash attention 加速注意力计算。适当增大 batch size 提高 GPU 利用率。6. 关于显存破局的几点个人体会跑过几十次微调任务之后我最大的体会是显存问题从来不是靠堆硬件解决的而是靠理解原理后做对选择。很多人一遇到 OOM 就想着换更大的卡其实只要把 QLoRA 的配置调对8G 显存跑 7B 模型微调完全可行。另一个体会是不要迷信参数。r 设成 64 不一定比 16 好target_modules 全挂不一定比挂四个好。真正决定效果的是数据质量和任务设计。我见过太多人把精力花在调参上却不愿意花时间清洗数据最后效果上不去还找不到原因。最后说一个容易被忽略的点微调不是终点部署才是。训练出来的 adapter 怎么和推理服务集成、怎么控制推理显存、怎么处理并发这些是下一讲要展开的内容。这一讲先把基础理论和显存破局的逻辑打牢后面的事情会顺很多。 大模型微调显存破局：LoRA与QLoRA实战指南
1. 大模型微调到底在做什么先把话说直白一点大模型微调不是从头训练一个模型也不是给模型“灌知识”而是拿一个已经具备通用能力的基座模型用你自己的数据让它“偏”向你的任务。你可以把它理解成一位已经读完大学的毕业生现在要让他快速适应你公司的业务规范——他不需要重新读一遍小学到大学只需要在你的业务场景里做针对性训练。这件事为什么这两年这么火因为通用大模型虽然什么都懂一点但在具体行业里往往“不够专业”。比如你让它处理医疗病历结构化它可能给你写出一段通顺但格式完全不对的文字你让它做法律合同要素抽取它可能漏掉关键条款。微调就是解决这个“最后一公里”问题的核心手段。但问题来了显存。这是几乎所有人在跑通第一个微调任务时撞上的第一堵墙。一个 7B 参数的模型全量微调动辄需要 80G 以上的显存普通开发者手里只有一张 8G、12G 或 24G 的卡根本跑不起来。于是LoRA、QLoRA这些参数高效微调方法就成了破局的关键。这一讲我围绕“基础理论 显存破局”这条主线把微调的底层逻辑、显存到底被什么吃掉了、LoRA 和 QLoRA 是怎么把显存压下来的以及实际跑通第一个微调任务时你会遇到什么全部拆开讲清楚。适合刚接触微调、手里显卡不算宽裕、想真正跑通一个LoRA 微调实战的读者。2. 微调的核心思路与方案选型2.1 全量微调、LoRA、QLoRA 到底差在哪在动手之前必须先把三条路线的本质区别搞清楚否则你会在选型上反复摇摆。全量微调Full Fine-tuning是最直接的方式把模型所有参数都拿出来用你的数据更新一遍。效果上限最高但代价也最大。一个 7B 模型FP16 精度下光权重就占 14GB加上梯度、优化器状态、激活值实际训练显存需求通常在 80GB 以上。这不是普通设备能承受的。LoRALow-Rank Adaptation的思路非常巧妙既然全量更新参数太贵那我就不动原来的权重而是在每一层旁边“挂”一对小矩阵只训练这对小矩阵。原始权重冻结梯度只流过这些小矩阵。这样一来可训练参数量能降到原来的千分之一甚至更低显存需求大幅下降。QLoRA则是在 LoRA 基础上再加一层量化把冻结的基座模型用 4-bit 量化加载进一步压缩显存占用。它让“单张 8G 显存微调 7B 模型”从不可能变成了可能。我用一个表格把三者的关键差异列清楚方案可训练参数比例7B 模型训练显存约效果上限适用场景全量微调100%80GB最高数据充足、算力充裕LoRA0.1%~1%16~24GB接近全量大多数业务微调QLoRA0.1%~1%6~12GB略低于 LoRA显存受限、快速验证注意这里的显存数字是经验值具体取决于序列长度、batch size、梯度累积等配置不是绝对值。2.2 为什么我优先推荐从 LoRA 入手很多人一上来就想搞全量微调觉得“参数更新得多效果肯定好”。这个直觉在微调场景里往往是错的。第一大多数业务场景的数据量根本喂不饱全量微调。你可能只有几千条甚至几百条标注数据全量微调在这种数据量下极易过拟合效果反而不如 LoRA 稳定。第二LoRA 的产物是一个很小的适配器文件通常只有几十到几百 MB方便保存、切换、组合。你可以为不同任务训练不同的 LoRA推理时按需加载这在工程上极其灵活。第三LoRA 的训练门槛低让你能把精力放在数据质量和任务设计上而不是天天和显存报错搏斗。所以我的建议很明确除非你有明确证据表明 LoRA 效果不够否则先从 LoRA 或 QLoRA 开始。这也是当前大模型微调实战里最主流的选择。2.3 显存到底被什么吃掉了要破局先要知道敌人是谁。训练时的显存占用主要来自四块模型权重FP16 下每个参数占 2 字节7B 模型约 14GB。梯度每个可训练参数对应一份梯度全量微调时同样是 14GB。优化器状态以 Adam 为例每个参数要存一阶矩和二阶矩FP32 下是 8 字节/参数7B 模型约 56GB。激活值前向传播过程中每层的中间输出和 batch size、序列长度强相关。把这四项加起来全量微调 7B 模型轻松突破 80GB。而 LoRA 把梯度、优化器状态这两块大头压缩到了只针对小矩阵QLoRA 又把权重压到 4-bit显存自然就下来了。3. 显存破局的核心原理拆解3.1 LoRA 的低秩分解为什么有效LoRA 的核心假设是模型在适应新任务时权重的变化量具有“低秩”特性。什么意思就是说虽然原始权重矩阵很大比如 4096×4096但真正需要调整的方向其实很少可以用两个小矩阵相乘来近似。具体做法是对于原始权重 W维度 d×kLoRA 引入两个矩阵 Ad×r和 Br×k其中 r 远小于 d 和 k通常取 8、16、32 这种量级。前向传播变成h Wx BAx训练时 W 冻结只更新 A 和 B。可训练参数量从 d×k 降到 r×(dk)。以 4096×4096 为例全量是 1600 万参数r16 时 LoRA 只有约 13 万参数差了 100 多倍。这就是 LoRA 能把显存压下来的根本原因梯度和优化器状态只针对这 13 万参数而不是 1600 万。3.2 QLoRA 的 4-bit 量化是怎么做的QLoRA 在 LoRA 基础上做了三件事第一4-bit NormalFloat 量化。它把基座模型的权重从 FP16 压到 4-bit显存直接降到原来的四分之一。7B 模型的权重占用从 14GB 降到约 3.5GB。第二双重量化。量化本身会产生一些常数QLoRA 对这些常数再做一次量化进一步省显存。第三分页优化器。当显存不够时把优化器状态临时挪到内存需要时再调回来避免直接 OOM。这三招组合下来8G 显存本地部署并微调 7B 模型就成了现实。代价是训练速度会慢一些因为量化和反量化有额外计算开销。3.3 关键参数怎么选LoRA 有几个参数直接决定效果和显存我逐个说r秩越大表达能力越强但显存和过拟合风险也越高。一般从 8 或 16 起步数据复杂可以上 32 或 64。lora_alpha缩放系数通常设为 r 的 1~2 倍。经验上 alpha/r 的比值比绝对值更重要。lora_dropout防止过拟合小数据集建议 0.05~0.1。target_modules决定给哪些层挂 LoRA。通常挂 attention 的 q、k、v、o 投影层效果和成本的平衡最好。实操心得如果你不确定 target_modules 怎么选先用 q_proj 和 v_proj 跑一版再逐步加上 k_proj、o_proj 对比效果。不要一上来就全挂那样显存和调参成本都会上去。4. 跑通第一个 LoRA 微调的完整实操4.1 环境准备与依赖安装先把环境搭起来。我以主流的 transformers peft trl 技术栈为例这套组合对新手最友好文档也全。pip install torch transformers peft trl datasets accelerate bitsandbytes这里每个包的作用transformers加载模型和分词器。peft实现 LoRA、QLoRA 的核心库。trl提供 SFTTrainer简化监督微调流程。datasets加载和处理数据。accelerate管理设备分配和混合精度。bitsandbytesQLoRA 的 4-bit 量化依赖。注意bitsandbytes 对 CUDA 版本有要求装完最好跑一句python -c import bitsandbytes验证一下报错的话优先检查 CUDA 和驱动版本匹配。4.2 数据准备从原始文本到训练样本微调效果的上限由数据决定。很多人模型跑通了但效果差问题几乎都出在数据上。数据格式上指令微调通常用“指令-输入-输出”三元组。我建议你先把原始数据整理成 JSONL每行一个样本{instruction: 提取以下文本中的驾驶员要素, input: 张三男35岁驾龄10年, output: 姓名张三性别男年龄35驾龄10年}如果你手里只有一堆 txt 文档可以用脚本批量转成这种结构。核心思路是把文档按段落切分为每段设计一个合适的指令把原文作为 input把你要的答案作为 output。实操心得数据量不是越多越好。500~2000 条高质量、格式统一的样本往往比几万条脏数据效果好得多。清洗数据时重点检查三件事格式是否统一、答案是否准确、有没有重复样本。4.3 模型加载与 LoRA 配置加载模型时QLoRA 需要指定量化配置from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig import torch bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_quant_typenf4, bnb_4bit_compute_dtypetorch.bfloat16, bnb_4bit_use_double_quantTrue, ) model AutoModelForCausalLM.from_pretrained( Qwen/Qwen2.5-7B, quantization_configbnb_config, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-7B)然后配置 LoRAfrom peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training model prepare_model_for_kbit_training(model) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) model get_peft_model(model, lora_config) model.print_trainable_parameters()跑完最后一行你会看到可训练参数占比通常在 0.1%~1% 之间。这个数字就是 LoRA 省显存的直接证据。4.4 训练参数配置与启动用 SFTTrainer 把训练流程串起来from transformers import TrainingArguments from trl import SFTTrainer training_args TrainingArguments( output_dir./lora_output, per_device_train_batch_size1, gradient_accumulation_steps8, num_train_epochs3, learning_rate2e-4, fp16False, bf16True, logging_steps10, save_strategyepoch, optimpaged_adamw_8bit, ) trainer SFTTrainer( modelmodel, argstraining_args, train_datasettrain_dataset, tokenizertokenizer, ) trainer.train()几个关键点解释一下per_device_train_batch_size1 gradient_accumulation_steps8单步显存不够时用梯度累积模拟大 batch。等效 batch size 是 8。optimpaged_adamw_8bit分页 8-bit 优化器QLoRA 的标配能显著降显存。bf16True比 fp16 更稳定不容易出现梯度溢出。注意如果训练中报 OOM优先降 batch size 或序列长度其次考虑降 r。不要一上来就换更小的模型先榨干现有配置的潜力。4.5 训练产物与推理验证训练结束后输出目录里会有 adapter 文件。加载推理时先加载基座模型再挂上 adapterfrom peft import PeftModel base_model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2.5-7B, device_mapauto) model PeftModel.from_pretrained(base_model, ./lora_output)然后就可以用你的测试样本验证效果了。重点看三件事格式是否稳定、答案是否准确、有没有出现重复或截断。5. 常见问题与排查技巧实录5.1 显存相关问题的排查顺序显存报错是微调路上最高频的问题。我整理了一个排查顺序按这个走基本能定位现象可能原因解决方向加载模型就 OOM没用 4-bit 量化加 BitsAndBytesConfig训练几步后 OOM激活值累积降 batch size 或序列长度训练中途突然 OOM内存碎片设 PYTORCH_CUDA_ALLOC_CONF推理时 OOMadapter 和基座重复加载检查加载逻辑实操心得设置环境变量PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True能有效缓解内存碎片导致的 OOM这个技巧很多人不知道但实测很管用。5.2 效果不达预期的常见原因模型跑通了但效果差通常不是模型的问题而是这几个地方数据格式不统一训练样本里有的用冒号有的用等号模型学出来的格式就会乱。学习率过高LoRA 常用 1e-4 到 3e-4太高会导致训练不稳定。训练轮数过多小数据集跑 3 轮以上很容易过拟合表现为训练 loss 降但验证效果变差。target_modules 选少了只挂 q、v 有时表达能力不够可以试试加上 k、o。5.3 训练速度太慢怎么办QLoRA 因为量化开销速度会比 LoRA 慢。如果速度是瓶颈可以考虑用 LoRA 替代 QLoRA显存够的话。开启 gradient_checkpointing用时间换显存。用 flash attention 加速注意力计算。适当增大 batch size 提高 GPU 利用率。6. 关于显存破局的几点个人体会跑过几十次微调任务之后我最大的体会是显存问题从来不是靠堆硬件解决的而是靠理解原理后做对选择。很多人一遇到 OOM 就想着换更大的卡其实只要把 QLoRA 的配置调对8G 显存跑 7B 模型微调完全可行。另一个体会是不要迷信参数。r 设成 64 不一定比 16 好target_modules 全挂不一定比挂四个好。真正决定效果的是数据质量和任务设计。我见过太多人把精力花在调参上却不愿意花时间清洗数据最后效果上不去还找不到原因。最后说一个容易被忽略的点微调不是终点部署才是。训练出来的 adapter 怎么和推理服务集成、怎么控制推理显存、怎么处理并发这些是下一讲要展开的内容。这一讲先把基础理论和显存破局的逻辑打牢后面的事情会顺很多。