这几年，大模型微调基本成了算法工程师的一个常规动作。无论你是想做一个行业问答助手，还是想让模型按固定格式输出结构化信息，最后大概率都会走到这一步：拿一个开源底座模型，用自己攒的数据重新训练一下。这篇文章把“大模型微调基础”这条路完整走一遍，从要不要调、调什么、怎么准备数据，到训练参数怎么设置、碰到loss不降怎么办、调完怎么评估和部署，全部过一遍。适合刚接触微调的同学，也适合已经跑通过一次、但感觉还差点细节的开发者。全文按实际操作顺序讲，不绕弯子。
1. 先想清楚：你真的需要微调吗
1.1 微调到底解决什么问题
大模型预训练阶段做的事情，说白了就是在海量文本上“把下一个词预测准”。模型学到的是通用语言规律和大量世界知识，像一个上了很多年学、知识面很广的人。但这个人没有专门练过你手头那件事，比如写某种格式的巡检报告、把客服对话归类到固定标签、用特定口吻回答医疗问题。微调做的事情，就是拿一批“输入-输出”的例子，让这个通用人才在你关心的任务上再多练一段时间，练到一看到类似输入就知道该按什么套路输出。
微调的全称叫监督微调，本质上还是用交叉熵损失继续训练。只不过数据从“网页文本”换成“你精心整理的任务数据”。你告诉模型：当用户问“XXX”的时候，正确答案不是模型随口编的那种，而是这种。模型会通过调整权重把这种映射刻进去。
这里有个很重要的区分：微调不是“从零学知识到脑子里”。底座模型该懂的知识基本都懂，微调更多是“调整输出的方式和边界”。所以不要指望用几十条数据往模型里灌新知识，有效果，但很有限，而且容易翻车。这也是很多人对微调的第一个误解。
1.2 先用提示词和检索，别急着微调
我见过太多人上来就问“这个任务是不是得微调一个模型”，我一般先反问一句：你试过把任务写成一段清晰的系统提示词吗？你试过把相关知识放到上下文里让模型先读一遍吗？这两个方案的成本几乎为零，却能在相当多场景里替代微调。
提示词工程解决的问题是“把话说明白”。比如你要模型输出JSON，你就把JSON结构、字段含义、枚举值全部写清楚，再给两个例子。现在底座模型的指令跟随能力很强，很多问题在提示词层面就解决了。
检索增强生成（RAG）解决的问题是“让模型看到最新或私有的资料”。你把文档切成片段，用户提问时先用向量检索找出最相关的几段，拼进Prompt里让模型基于这些内容回答。这种方式特别适合处理知识更新快、来源杂、需要引用的场景。
那什么时候才值得上微调？我的判断标准有三个：第一，提示词和RAG都试过了，效果仍然不达标；第二，任务要求非常固定的输出格式，比如特定报表、特定语气、特定结构化字段，模型在通用情况下稳定还原不了；第三，你希望模型的行为边界更可控，比如某些问题必须拒绝回答，某些问题必须用严谨措辞。满足其中一两条，再考虑微调。
微调的成本不只是训练那几小时，还包括数据清洗、标注、评估、后续维护。模型调坏一次，你得重新标注数据、重新训练、重新验证，时间成本远超一次提示词迭代。所以，把微调放在“低成本方案已经验证过、确实不行”之后，才是理性的技术路线。
2. 微调技术路线：全参数、LoRA、QLoRA 怎么选
2.1 三条路线的原理差异
圈内聊微调，默认都在聊“参数高效微调”。原因是底座模型动辄几十亿参数，全量更新一轮的成本太高。当前主流有三条路线，原理差异很大。
全参数微调（Full Fine-tuning）指的是把底座模型所有参数全部解冻，在任务数据上做完整更新。这种做法效果上限最高，因为它能最大程度重塑模型行为，但代价也最直观：需要很大的显存。除了模型本身的参数，还要存梯度、优化器状态，一个几十亿参数的模型可能直接吃掉几百GB显存。在普通单卡上基本不用想。
LoRA（Low-Rank Adaptation）是目前最常用的一种参数高效微调。它的思路很简单：冻结底座模型的原始权重，在每个需要调整的线性层旁边额外加两个低秩小矩阵，训练时只更新这两个小矩阵。推理时可以把这两个小矩阵合并回原权重，相当于给原模型做了一个“小补丁”。这个补丁里的参数量通常只有原模型的百分之一甚至更少，所以显存占用和训练成本大幅下降，效果在多数任务上和全参数微调差距不大。
QLoRA是在LoRA的基础上多做一个动作：先把底座模型以4bit量化加载进来，再在量化后的模型上挂LoRA矩阵训练。4bit量化让模型参数本身的显存占用缩小到原来的四分之一左右，比如一个7B模型用完整精度加载需要约14GB显存，4bit加载后大约4到5GB。这样一张普通的24GB消费级显卡就能训练十几B甚至更大一点的模型，对没有多卡资源的开发者来说几乎是当前最佳方案。
2.2 现实中的选择策略和参数规模计算
怎么选，关键看硬件和任务复杂度，我的建议如下：
| 场景 | 推荐路线 | 理由 |
|---|---|---|
| 任务复杂、领域差异大、有专业级GPU资源 | 全参数微调 | 效果上限最高，但需要大显存和更长训练时间 |
| 常规对话风格调整、格式控制、单卡资源 | LoRA | 性价比最高，绝大多数场景够用 |
| 单卡显存小、想跑大尺寸底座、快速试错 | QLoRA | 显存占用最低，但量化会带来轻微精度损失 |
我给一个直观的LoRA参数计算示例。假设底座的隐藏维度是4096，这个维度上的隐含层权重矩阵大小就是4096×4096。如果我们在这一层挂上秩为8的LoRA，新增两个矩阵分别是4096×8和8×4096，参数量是4096×8×2，也就是65536个参数。原本这一层的参数量是4096×4096约1678万，LoRA新增量只占大约0.4%。把全模型十几个线性层都挂上一遍，累计新增参数通常也只有几百万，和原模型几个B、几十个B的体量比，确实非常小。
这也解释了为什么LoRA能在单卡上训练：训练时只需要更新这几百万个LoRA参数，优化器状态和梯度也只跟这几百万参数相关，显存压力主要来自“底座模型本身要占的空间”和“前向计算时临时用到的中间激活值”，这两个可以用量化、梯度检查点进一步压缩。
我现在个人做项目，默认先跑一版QLoRA，确认数据本身没有大问题后，再决定要不要换LoRA或者全参数。这个小习惯能省掉大量无效训练时间。
3. 数据准备：微调中最花时间的部分
3.1 数据格式：先对齐底座的“语言习惯”
如果说微调是给模型上一个任务培训班，那数据就是培训班里的教材。教材格式不对，模型学得再多也是乱的。当前绝大多数底座模型在预训练和指令微调阶段都采用“对话式”训练模板，所以你准备的数据也最好跟它们保持一致。
单轮指令数据最常见的长这样：
{ "instruction": "把下面这句话翻译成英文", "input": "今天天气很好", "output": "The weather is nice today." }如果底座用的是Alpaca那类指令格式，这种结构直接用没问题。更通用的是消息对话格式，适合多轮场景：
{ "messages": [ {"role": "user", "content": "你是谁？"}, {"role": "assistant", "content": "我是一个经过微调的助手。"}, {"role": "user", "content": "你能做什么？"}, {"role": "assistant", "content": "我可以帮你处理文档、回答问题…"} ] }训练时，模型会把整段messages拼成一个序列，但损失只会计算在assistant回复的位置，这样模型才知道“用户说的话不用学，助手该怎么说才是重点”。
一个经常被忽略的点是：用什么模板并不取决于你自己喜欢什么格式，而是取决于底座在预训练和指令对齐时见惯了什么格式。格式越接近底座原生格式，模型越容易学进去。你在跑微调之前，最好先用该底座的对话模板手动拼一个样本，喂给底座模型生成一下，确认能正常对话，再开始处理数据。这一步花十分钟，能避免后面一个小时的“格式对不上”排查。
3.2 数据量与质量控制
我刚接触微调时也有个错觉：数据越多越好。后来被现实教育了。微调和预训练不同，预训练是海量无监督文本，几百G上千G都不嫌多；微调是高度有监督的任务数据，Python里跑几百条、几千条很常见，效果未必比几万条差。
更准确的说法是：可控的对话风格微调只需要几百到两三千条高质量样本；需要掌握复杂逻辑或专业推理的任务，可能需要上万条甚至更多。这里的核心不是“条数”，而是“覆盖度”。你要让模型见过的边界情况够多，而不是让同一个模式重复几百遍。
质量控制比数量重要得多。我在处理完一批数据后一定会跑一遍检查脚本，把明显有问题的样本挑出来。常见检查点包括：有没有空输出字段；答案是不是来自被截断的文本；同一问题有没有互相矛盾的答案；有没有包含真实隐私信息；有没有语义重复到几乎一模一样的样本。特别是重复样本，会让模型把某个高频答案当成万能输出，测试时不管用户问什么，都往那个方向带。
还有一个小技巧：把数据按任务类型做个分布统计。比如你是做客服助手，有“查订单”“改地址”“退款”“投诉”四类意图，那就看每类样本数量是否均衡。如果不均衡，模型会被多数类带跑偏，少数类要么频繁拒绝，要么用错误话术。少的那一类哪怕只有几十条，也要优先补齐，至少让每个关键分支都有基本量的代表。
3.3 构造指令数据的一些实用技巧
数据到底从哪来？几种常见途径：从生产环境日志里清洗真实对话；人工编写一批符合业务规范的样例；让更强的大模型帮你生成初稿，再人工校对。其中“模型生成+人工校对”效率最高，但我强烈建议每条都要过人工，否则错误答案会被模型当成“正确答案”学进去，形成隐性错误放大。
我常用的构造策略是这样：先定义任务边界，列出这个模型必须能处理的所有输入类型；再为每个类型写5到10个种子问题；然后基于种子问题扩展变体，比如换说法、换专有名词、换场景；最后补一批“边界问题”，也就是模型应该拒绝回答的问题。比如你做一个医疗问答，边界问题就是“请告诉我这个患者该用什么药”这类需要医生判断的内容，模型应该拒绝并引导用户线下就医。
拒绝类样本不要写得太单调。一个容易犯的错误是：所有拒绝样本都长得一样，“对不起，我无法回答”。模型学会的是“遇到不确定就念这句”，用户换个问法它还想不出来到底该不该拒绝。更好的做法是让拒绝回复多样化，并且给出解释：“关于具体用药，建议咨询执业医师，我不能代替医生做判断。”这样模型学到的不是一句套话，而是一个判断逻辑。
最后，一定要从全量数据里留出一部分作为验证集，比例5%到10%都行，不要让它参与训练。验证集的作用是判断模型“学没学过”过拟合，也是你后期评估模型的底稿。数据泄漏的事儿我吃过亏，有次偷懒直接用全部数据训练，模型在测试集上分数高得惊人，一上真实场景立刻现原形，就是因为验证样本跟训练样本太相似。
4. 实操：跑通一次LoRA微调
4.1 环境准备和坑
这套流程的基础环境其实不复杂：Python、PyTorch、transformers、peft、accelerate、datasets，一个都不能少。如果要用QLoRA，还需要bitsandbytes这个量化支持库。我的安装经验是不要用家里环境硬怼，新建一个虚拟环境干净很多。
pip install torch transformers peft accelerate datasets bitsandbytes版本方面有个经典坑：bitsandbytes的版本跟CUDA版本、PyTorch版本必须匹配。很多人装完库之后训练一启动就报“CUDA error：mismatch”，大概率就是这里不对。稳妥的做法是先去查当前PyTorch对应什么CUDA版本，再按这个来安装适配的bitsandbytes。如果你的显卡不支持4bit量化，也可以先用8bit，或者干脆退回纯LoRA。
多说一句：我不建议一上来就追最新的transformers版本。大模型生态更新快，一些老模型在新版本里接口会变，出现莫名其妙的问题。锁定一个自己验证过的版本组合，项目跑稳定之后再决定要不要升级，这是从业者的基本习惯。
4.2 加载模型、数据与LoRA配置
下面这段是QLoRA微调的核心代码骨架，我按实际项目的简化版写。先把底座和分词器加载进来：
from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_id = "./base_model" # 本地路径，也可以填社区模型路径 tokenizer = AutoTokenizer.from_pretrained(model_id) model = AutoModelForCausalLM.from_pretrained( model_id, load_in_4bit=True, torch_dtype=torch.bfloat16, device_map="auto" ) if tokenizer.pad_token is None: tokenizer.pad_token = tokenizer.eos_token这里最关键的是load_in_4bit=True，它让底座模型以4bit格式进入显存，大幅降低空间占用。device_map="auto"让库自动把各层分配到可用的设备上，单卡时就是全部放同一张卡，多卡时会自动切分。
pad_token的处理也要注意。很多开源底座只有eos_token没有pad_token，训练时batch内样本长度不一样，需要padding到相等长度，如果没有pad_token，程序会直接报错。最省事的方法是让pad_token等于eos_token，代价是会让一部分输入序列在训练时提前遇到结束符，但对大多数短文本任务影响不大。
接着挂上LoRA：
from peft import LoraConfig, get_peft_model lora_config = LoraConfig( r=8, lora_alpha=16, 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)r是低秩矩阵的秩，决定微调容量的“宽度”；lora_alpha是缩放系数，控制LoRA更新对原模型影响的程度。r=8、alpha=16是实践里一个兼顾效果和稳定性的常见起点。target_modules指定挂LoRA的层，一般注意力模块的四个投影都要挂上，有些项目也会挂FFN里的线性层，效果略好但训练量也略增。
4.3 启动训练、看日志、保存和合并
训练配置我用TrainingArguments实现。一个我验证过稳定不爆显存的起点配置如下：
from transformers import TrainingArguments, Trainer training_args = TrainingArguments( output_dir="./lora_out", per_device_train_batch_size=2, gradient_accumulation_steps=8, learning_rate=2e-4, num_train_epochs=2, logging_steps=20, save_strategy="epoch", bf16=True, report_to="none", ) trainer = Trainer( model=model, args=training_args, train_dataset=train_dataset, ) trainer.train()per_device_train_batch_size=2看着很小，但配合gradient_accumulation_steps=8，实际等效batch size是2×8=16，这是为了让小显存也能获得较大batch的稳定性。bf16需要显卡支持，如果不支持就改成fp16=True，但要留意数值溢出问题。
训练过程中把日志打开，观察loss曲线是否在合理区间下降。保存策略我习惯按epoch保存，这样哪怕最后一个epoch过拟合了，还能回退到前面某个checkpoint。
训练完有两种使用方式。一是推理时直接加载LoRA权重，适合调试期；二是把LoRA矩阵合并回底座权重，然后保存成一个完整的模型，适合部署。合并和保存的代码非常简单：
model = model.merge_and_unload() model.save_pretrained("./merged_model") tokenizer.save_pretrained("./merged_model")这里有个注意点：合并之前先把模型切回原精度或者你打算部署用的精度。如果你是用4bit底座训练的，合并后直接保存的是一个带着量化痕迹的模型，部署阶段性能可能会有波动。我一般会先用同一底座重新加载一次LoRA权重，再merge，这样可以手动控制加载精度，避免一些潜在大坑。
5. 训练过程中的关键监控与参数调优
5.1 学会看loss曲线
很多人第一次跑微调，盯着loss窗口疯狂刷新，感觉loss不降到0.5就是没学好。这其实是误区。对话生成任务的loss是一个句子里所有token的平均交叉熵，数值大小跟底座的初始化状态、数据难度、序列长度都有关系，一个7B模型在几百条指令数据上跑到loss=1.2已经算不错，强行压到很低，大概率是过拟合了。
我更关注的是两条曲线：训练loss和验证loss。训练loss持续下降是正常的，但如果你发现训练loss还在降，验证loss已经开始回升，那说明模型已经开始“背诵”训练集，而不是“学习”任务规律。这个转折点通常在第二个epoch附近出现。遇到这种情况，优先考虑减少epoch数量、增加验证集多样性、或者降低学习率。
还有一个小指标值得看：训练结束前最后一次eval的损失跟第一次eval的损失差距。如果差距很小，可能说明模型根本没怎么学进去，数据质量或者学习率有问题；如果差距很大，甚至验证loss比预训练底座还高，那过拟合基本实锤。
5.2 学习率、epoch 和灾难性遗忘
LoRA微调的我常用学习率是1e-4到3e-4，比全参数微调通常用的1e-5到2e-5高一截。原因也好理解：LoRA只动几个小矩阵，更新量本来就不大，学习率太低会让“补丁”更新得过慢，训练半天没效果。但学习率也不是越大越好，超过5e-4之后loss很容易发散，变成NaN或者震荡，模型输出也会开始胡言乱语。
epoch数我建议从1到3起步。没错，训练集只有几百条时，1个epoch有时候就够了，2个epoch能进一步稳定格式，3个epoch以上基本是在赌它不过拟合。你可以观察一个现象：到某个epoch之后，loss虽然还在降，但生成的内容开始变得“千篇一律”，开头结尾总是那几句固定话，这就是过度学习的信号。
为什么微调特别怕过拟合？因为底座模型的语言能力是千百亿token堆出来的，你微调的数据是几百万token都不到的小样本。训练太久，模型会把它原本学到的多样表达方式覆盖掉，也就是所谓的“灾难性遗忘”。表现是：模型回答你业务问题很标准，但一旦问个常识问题，它反而不如微调前聪明了。为了防止这一点，除了控制epoch和学习率，另一个常用技巧是在训练集里掺入一部分通用对话数据，让模型别把旧知识全忘光。
5.3 显存不够时的三板斧
单卡跑微调，显存是最容易卡脖子的地方。我的排查顺序是固定的：先看batch大小是不是太大；再看序列长度是不是太长；最后看有没有开梯度检查点。
第一板斧是减小per_device_train_batch_size，从8降到4再降到2。batch变小后梯度方差会变大，所以同时调大gradient_accumulation_steps，保证等效batch_size不变。等效batch_size=per_device_train_batch_size×gradient_accumulation_steps×显卡数，这个公式建议随手写在笔记里。
第二板斧是控制序列长度。有些指令数据特别长，比如把整个网页塞进input字段，序列长度直接飙到4096甚至8192。长序列意味着中间激活值占用巨大显存。先看一下训练集里的长度分布，如果大部分样本都在512到1024之间，那把max_length设成1024或者2048，能省出一大块显存。少数超长样本要么截断，要么拆分。
第三板斧是梯度检查点（gradient checkpointing）。它的原理是“用时间换空间”：前向传播时不保存所有中间激活值，反向传播时又重新计算一遍。开启后显存占用能明显下降，但训练速度会慢一些。DataCollator里设置padding=True时，也要小心一边倒的长padding浪费显存，必要时用动态padding，让模型只按当前batch最长的样本做padding。
6. 常见问题排查：一个人debug的经验清单
6.1 loss不降、NaN
训练到一半loss突然变成NaN，是最吓人的情况。我遇到过的原因主要有三类：学习率太高，梯度更新一步跨太大直接溢出；数据里有异常值，比如某个样本的input全是重复字符或长度畸形到爆；混合精度下bf16/fp16数值溢出，特别是fp16在Loss值高的时候不稳定。
排查顺序也别乱。先看一眼是第几步开始NaN的，如果刚开始几步就NaN，基本是学习率问题，降到1e-5试一把；如果跑了几百步才NaN，优先怀疑数据里混进了坏样本，抽出一条条过一遍；如果是fp16训练，换成bf16或者纯fp32再试。还有一个隐蔽情况：4bit量化层在某些显卡驱动版本下有数值问题，换新版本或关掉4bit能解决。
loss完全不降是另一类头疼问题。如果从头到尾loss都纹丝不动，先检查数据有没有真正加载进模型。有次我因为tokenizer的配置写错，所有的input都被截成了空序列，模型每个token的预测都模棱两可，loss自然降不下去。把训练集里那条实际输入打印出来看一眼，成本最低。
6.2 显存爆掉
显存爆掉（OOM）的报错信息基本是“CUDA out of memory”。如果你看到这个，八成不是程序有bug，而是配置超了物理限制。按我上面的三板斧先减batch、减长度、开梯度检查点。还有一个容易被忽略的地方：验证阶段同样占显存，如果训练正常验证OOM，就把eval的batch size也调小，或者减少验证集样本量。
多卡训练时，OOM经常不是所有卡一起爆，而是某一两张卡先爆，这是因为模型分布不均。device_map="auto"会自动分配，但有些层特别吃显存，比如embedding层。你也可以手动指定某些模块放在CPU上，把显存让给计算密集的Transformer层。不过CPU和GPU之间频繁通信会拖慢速度，只能在实在没办法的时候用。
6.3 模型变笨、复读、乱拒绝
训练完了，模型在你业务问题上表现可能很好，但问它一个基础常识它开始胡扯，或者不管问什么都回“我不能回答”。这很大概率不是模型坏了，而是数据配比出了问题。
“复读机”现象通常是因为训练集里的回答太单一，所有样本的输出结构都一模一样，模型学会了那个高频结构，不会变通。解决办法是在数据里引入更多样的表达方式，同一语义写在5到10种句式里。“乱拒绝”的根源往往是拒绝类样本太多或者太统一，模型被训练成“遇到不认识的输入就触发拒绝”。我之前做业务时加多了安全拒绝样本，结果正常问题也拦掉一部分，后来把拒绝类样本比例控制在10%以下，并且让拒绝回复多样化，情况才好转。
还有一种情况是模型“学到了格式但丢了逻辑”。比如要求输出JSON，模型确实输出JSON了，但JSON里的字段值全是胡编的。这说明数据里有不少逻辑错误的样本，模型把“答非所问”也当成了一种格式学会。回头检查数据质量比继续调参有用得多。
6.4 多轮对话能力退化
有些项目只准备了单轮指令数据进行微调，训练完成后发现模型在连续对话里没法正确引用上文，或者压根不记得用户之前说过什么。原因很简单：你在训练数据里根本没有让模型见过“历史消息”这种结构，它自然不擅长处理。
对策是在数据里混入多轮对话样本，比例建议至少20%到30%。多轮样本也不是越长越好，4到6轮比较合适。如果业务场景确实不需要多轮，那单轮无所谓；但只要你预期用户会在对话里继续追问，就必须在数据里体现多轮上下文。另一个细节：多轮训练时，前面轮次的assistant回复也会参与计算损失，如果你希望模型优先学习“最后一轮该怎么回”，可以使用只对最后一轮计算损失的策略，否则模型会把前期轮次的话术也一并学进去，整体风格容易变得冗长。
6.5 排查表
| 现象 | 优先排查方向 | 常用解法 |
|---|---|---|
| loss为NaN | 学习率、数据异常、fp16精度、量化层 | 降学习率、清洗数据、开bf16、升级库版本 |
| loss不降 | 数据是否为空/截断、学习率过低 | 打印训练样本、调大学习率、检查tokenizer |
| 显存OOM | batch过大、序列过长、激活值过大 | 减batch、开梯度检查点、限制max_length |
| 复读机 | 数据输出单一 | 扩样本句式多样性 |
| 乱拒绝 | 负样本过多且单一 | 调低负样本比例、丰富拒绝话术 |
| 多轮能力退化 | 数据全部是单轮 | 混入20%以上多轮样本 |
| 训练后常识变差 | epoch过多、学习率过大、数据太偏 | 早停、降低lr、混入通用对话数据 |
7. 微调完的评估与部署
7.1 怎么设计一套够用的评估集
微调的过程有意义，但很多人训练完只会看两眼loss，然后凭感觉说“好像变聪明了”。这种做法风险很大，因为你看到的几段示例可能恰好是训练里见过的模式，真实效果好不好根本没量化。
正确做法是单独留一份不用参与训练的评估集，数量和训练集保持同分布，但内容完全不同。评估时不能只看模型能不能说对，还要看它是不是“用符合业务要求的方式说对”。我给自己的项目打分会看五个维度：内容正确性，是否出现事实性错误；指令遵循度，用户要求JSON它给没给JSON；格式稳定性，字段名、枚举值、换行符是不是都按约定来；边界处理，不该回答的问题有没有克制；风格一致性，是否贴近业务想要的口吻。
自动指标可以用BLEU/Rouge这类文本相似度，但对话生成任务里它们经常失灵，两句话意思一样但词面不同，分数会很难看。我通常做的是“人工双盲对比”：把微调前后的模型各自生成20到50个回答，去掉来源标记，混在一起让人打分排序。别嫌土，这种方法最接近真实使用感受，而且能发现很多指标看不出来的问题。
7.2 合并权重、量化与部署
评估通过之后进入部署。如果你的推理服务不依赖开源生态，合并权重是最省事的方案。训练端执行model.merge_and_unload()再把完整模型存下来，部署端直接加载这个合并后的模型，不需要额外加载LoRA adapter。合并后的模型在参数量上等于一个完整底座，推理速度比“底座+adapter”的方式更快，因为少了一层动态计算分支。
部署时量化又是一个选择。如果你对显存依然敏感，可以把合并后的模型用量化工具压到4bit或8bit再部署，牺牲少量精度换吞吐量。但注意一点：训练阶段用的是QLoRA的4bit，底座的权重在训练中是被冻结的，量化误差是可控的；推理阶段的新量化是另一套量化参数，需要做一轮校准，不能直接照搬训练时的量化配置。
真正上线前还有两个细节值得检查：tokenizer的chat template是否和微调数据一致，否则部署后模型会以错误方式拼上下文，效果直线下降；生成参数比如温度、top_p是不是设置合理，我见过很多项目因为推理时temperature设太高，把微调学到的严谨风格全冲散了。这两个细节排查一遍，比继续训练三个epoch更有效。
我个人在实际操作中还有一个习惯：跑微调之前，先把训练数据里随机抽20条，让原始底座直接生成一遍。这一步能提前暴露模板写错、问题太刁钻、输出格式提示词不完整等一系列问题。有了这个baseline，微调后的效果才有真正的对照，而不是凭感觉觉得“模型变强了”。现在每次交测试报告，我都先贴出这20条的微调前回答和微调后回答，否则一切指标都像空中楼阁。这套流程跑顺了，以后再来新任务，半天内就能出一版可评估的微调模型。
