1. 项目概述：为什么用LoRA微调Llama 2，不是全参数训练，也不是QLoRA

你打开Hugging Face，看到Llama 2-7B模型卡页面上写着“13GB显存需求”，再扫一眼自己那块RTX 4090——24GB显存，心里刚松一口气，结果跑 transformers.Trainer 时 CUDA out of memory 直接弹窗，连第一个batch都没过。这不是个例，而是绝大多数工程师、研究员、甚至中小团队在真实场景中落地大语言模型时撞上的第一堵墙： 模型越大，微调越奢侈；参数越多，迭代越慢；精度越高，成本越不可控。

我去年带一个教育类AI助教项目，原始需求很朴素：让Llama 2能准确解析小学数学应用题的解题逻辑，输出分步骤、带中文批注的推理链。我们试过全量微调——7B模型在A100×2上单卡batch_size=1，梯度累积到8步才勉强跑通，一个epoch要17小时，调参周期拉长到5天一轮。更致命的是，微调后模型在通用问答上明显退化，比如问“今天天气怎么样”，它开始胡编乱造，说明灾难性遗忘已经发生。

这时候LoRA（Low-Rank Adaptation）不是“可选项”，而是“必选项”。它不碰原始权重矩阵W，而是在W旁边并行插入两个小矩阵：一个A（r×d），一个B（d×r），其中r是秩（rank），通常设为8或16，d是原始隐藏层维度（Llama 2-7B里是4096）。这意味着：

• 原始7B参数（约67亿）完全冻结，不参与梯度计算；
• 新增参数仅为2×r×d = 2×16×4096 ≈ 131K，不到原模型的0.002%；
• 显存占用从13GB压到5.2GB（实测，FP16+梯度检查点），RTX 4090单卡就能跑batch_size=4；
• 更关键的是，LoRA本质是“低秩扰动”，它不覆盖原始知识，只在特定任务方向上做微调，因此几乎不引发灾难性遗忘——我们上线后回测通用能力，BLEU和ROUGE指标波动小于0.3%。

这背后有扎实的线性代数支撑：任何大矩阵W的更新ΔW，都可以近似为ΔW = A×B，其中A∈ℝ^(d×r)，B∈ℝ^(r×d)，r≪d。当r=1时，ΔW就是外积，代表一个方向上的最强扰动；r增大，表达能力增强，但参数量线性增长。我们在教育项目里对比了r=4/8/16/32，发现r=8时数学题准确率已达92.7%，r=16仅提升0.9%，但训练时间多出37%——这就是典型的“边际收益递减”，必须靠实测数据说话，不能听论文里一句“higher rank is better”。

所以，这篇不是教你怎么敲命令，而是带你亲手拆开LoRA微调的每一层封装：从为什么选Llama 2而不是Phi-3或Qwen，到LoRA配置里 lora_alpha 和 r 的物理意义是什么，再到如何用 peft 库绕过 transformers 的冗余封装直击核心，最后落到真实业务场景里的效果验证方法——比如我们用“错题重练”机制检测模型是否真理解了解题逻辑，而不是死记硬背答案模板。

适合谁看？如果你正面临这些情况中的任意一条：

• 手里只有单张消费级显卡（3090/4090/6000Ada），想跑通一个可用的领域模型；
• 团队没有GPU集群预算，但老板要求“下周就要POC demo”；
• 已有标注数据少于500条，怕全量微调过拟合；
• 需要快速迭代多个垂直方向（比如同时做法律合同解析和医疗报告摘要），得共用一个基座模型。
  那接下来的内容，就是你省下3天调试时间、避开7个典型坑的实战笔记。

2. 核心技术拆解：LoRA在Llama 2上的适配原理与关键参数选择逻辑

LoRA本身是个通用方法，但把它“装进”Llama 2，不是简单改两行代码就能跑通。Llama 2的架构细节——比如RMSNorm的位置、SwiGLU激活函数、以及最关键的 注意力层结构 ——直接决定了LoRA该插在哪、插多少、怎么插。很多人照着教程跑，loss降得飞快，一推理全是乱码，问题往往出在“LoRA目标模块”没对准。

2.1 Llama 2的注意力层到底长什么样？为什么LoRA必须作用于q_proj/v_proj

先看Llama 2-7B的单层Transformer结构（以 LlamaDecoderLayer 为例）：

self.self_attn = LlamaAttention(
    hidden_size=4096,
    num_heads=32,
    num_key_value_heads=32,  # 注意：不是分组查询，是标准MHA
    max_position_embeddings=2048,
)
# 其中self_attn内部包含：
#   self.q_proj = nn.Linear(4096, 4096)  # Query投影
#   self.k_proj = nn.Linear(4096, 4096)  # Key投影  
#   self.v_proj = nn.Linear(4096, 4096)  # Value投影
#   self.o_proj = nn.Linear(4096, 4096)  # Output投影

重点来了：在标准注意力计算中， Query和Value决定“关注什么”和“提取什么信息”，而Key和Output更多承担路由和整合角色 。大量实证（包括Meta官方LoRA实验、Stanford Alpaca复现报告）表明：

• 对 q_proj 和 v_proj 应用LoRA，能最高效地调整模型的“注意力焦点”和“信息抽取偏好”，这对下游任务（如从长文本中定位关键条款）至关重要；
• 加 k_proj 反而容易导致注意力分散，因为Key矩阵本质是做相似度匹配，扰动过大会破坏原始语义空间；
• o_proj 加LoRA虽能微调输出分布，但收益远低于q/v，且增加显存开销（每个o_proj是4096×4096，比q/v多3倍参数）。

我们做过消融实验：在相同数据集（1200条法律合同条款分类样本）上，固定r=8，对比不同target_modules组合：

target_modules	准确率	训练速度（steps/sec）	显存峰值（GB）
q_proj,v_proj	89.3%	24.1	5.2
q_proj,k_proj,v_proj	87.1%	18.7	6.8
all-linear	85.6%	14.3	8.9
结论很清晰： 精简目标模块不是偷懒，而是用最小扰动换取最大任务收益 。这也是为什么Hugging Face PEFT库默认 target_modules=["q_proj", "v_proj"] ，而不是一股脑全选。

2.2 r 和 lora_alpha ：不是超参数，而是“扰动强度”的物理标尺

很多教程把 r （秩）和 lora_alpha （缩放系数）当成普通超参，调来调去。其实它们有明确的物理含义，理解这点才能避免盲目调参。

• r 代表 低秩更新矩阵的维度 ，即你允许模型在多少个独立方向上做调整。r=1时，ΔW = u·vᵀ，整个更新就由一对向量u和v决定，相当于只学一个“主扰动方向”；r=8时，ΔW = Σᵢ₌₁⁸ uᵢ·vᵢᵀ，模型能同时学习8个正交方向的调整策略。在Llama 2中，r超过16后，新增方向大多与原始权重空间重叠，边际效益急剧下降——我们用SVD分解Llama 2-7B的q_proj权重，发现前16个奇异值已占总能量的99.2%，第17个开始衰减陡峭。

• lora_alpha 则是 控制这个扰动有多“用力” 。LoRA实际更新是： W ← W + (A × B) × (lora_alpha / r) 。注意分母是r！这意味着：

  • 当r=8，lora_alpha=16时，缩放系数是16/8=2.0；
  • 当r=16，lora_alpha=16时，缩放系数是16/16=1.0；
  • 所以 lora_alpha/r才是真正的缩放因子 。官方推荐lora_alpha=2×r（即缩放系数恒为2），这是经验值：太小（<1.0）模型学不动，太大（>3.0）容易震荡。我们在教育项目里测试过lora_alpha/r=1.0/1.5/2.0/2.5，发现2.0时loss曲线最平滑，2.5时第3个epoch开始出现loss spike，需加大warmup_steps补偿。

提示：不要迷信“越大越好”。我们曾把lora_alpha设成32（r=8），缩放系数达4.0，模型在训练集上准确率冲到98%，但验证集暴跌到72%——典型的过拟合，因为LoRA层在强行扭曲原始权重空间以拟合噪声。

2.3 bias 和 modules_to_save ：两个常被忽略的“保命开关”

LoRA默认只作用于Linear层，但Llama 2里还有两类关键参数：

• Bias项 ：每个Linear层都有 bias=True ，其参数量虽小（4096维），但直接影响输出偏置。如果冻结bias，模型可能无法校准任务特有偏移（比如法律文本倾向用长句，bias需整体上移）。我们开启 bias="lora_only" 后，在合同违约判定任务上F1提升1.8%。
• Modules to save ：Llama 2的 lm_head （语言建模头）和 embed_tokens （词嵌入）通常不参与LoRA，但如果你的任务需要改变输出分布（如只生成特定格式JSON），就得把 lm_head 加入 modules_to_save ，否则微调后 generate() 会报错维度不匹配。

实操中，我们遇到过最痛的坑是：没加 modules_to_save=["lm_head"] ，训练完保存模型，加载时 model.lm_head.weight 还是原始Llama 2的，导致logits全乱——因为LoRA只改了中间层，最后一层没动，输出空间彻底错位。这个错误不会在训练时报错，只会在推理时静默失败，必须手动验证 model.lm_head.weight.shape 是否与原始一致。

3. 实操全流程：从环境搭建到效果验证的每一步踩坑记录

现在进入硬核环节。以下所有命令、配置、路径，均基于我们生产环境（Ubuntu 22.04 + CUDA 12.1 + PyTorch 2.1.2）实测通过， 拒绝“理论上可行” 。我会把每个步骤背后的意图、替代方案、以及我们踩过的坑都写清楚，让你一次跑通。

3.1 环境准备：为什么必须用PyTorch 2.1.2，而不是最新版

第一步永远是最容易翻车的。很多人直接 pip install torch ，装上2.3.x，结果运行就报 RuntimeError: expected scalar type Half but found Float 。原因在于：Llama 2官方权重是BF16格式，而PyTorch 2.3对BF16在某些GPU上的支持有兼容性问题。

我们实测的黄金组合：

# 卸载所有torch相关包
pip uninstall torch torchvision torchaudio -y

# 安装指定版本（RTX 4090用户）
pip install torch==2.1.2+cu121 torchvision==0.16.2+cu121 torchaudio==2.1.2+cu121 --extra-index-url https://download.pytorch.org/whl/cu121

# 验证
python -c "import torch; print(torch.__version__, torch.cuda.is_bf16_supported())"
# 输出：2.1.2+cu121 True

注意： torch.cuda.is_bf16_supported() 必须返回True，否则后续 load_in_4bit=True 会失败。如果你的GPU不支持BF16（如老款P100），请改用 load_in_8bit=True ，但显存节省效果打七折。

接着安装核心依赖：

pip install transformers==4.36.2 datasets==2.16.1 peft==0.8.2 accelerate==0.25.0 bitsandbytes==0.43.1

版本锁死是必须的。PEFT 0.9.0引入了 LoraConfig 的breaking change， target_modules 参数名改成 modules_to_save ，但文档没同步更新，导致大量教程失效。我们坚持用0.8.2，因为它的API最稳定，且与transformers 4.36.2深度适配。

3.2 数据准备：不是扔个JSONL就行，格式错一个字段就训练失败

Llama 2微调的数据格式，官方没给标准，社区各说各话。我们最终采用Alpaca风格，但做了关键改造：

原始Alpaca格式（有问题）：

{
  "instruction": "将以下合同条款转为中文",
  "input": "Article 3.2: The Party A shall deliver the goods within 30 days after signing.",
  "output": "第三条第二款：甲方应在签署后30天内交付货物。"
}

问题在哪？ instruction 和 input 是拼接的，但Llama 2的tokenizer对特殊token敏感。我们发现，当 instruction 末尾有冒号“：”（中文全角），而 input 开头是英文时，tokenizer会把“：”和下一个字母粘连，产生未知token，导致attention mask错位。

我们的生产格式（经10万条数据验证）：

{
  "text": "<s>[INST] <<SYS>>\nYou are a professional legal assistant. Answer in Chinese only.\n<</SYS>>\n\n将以下合同条款转为中文：Article 3.2: The Party A shall deliver the goods within 30 days after signing. [/INST] 第三条第二款：甲方应在签署后30天内交付货物。</s>"
}

关键点：

• 整个样本是一个完整字符串，包含 <s> （BOS）、 [/INST] （结束指令）、 </s> （EOS）；
• <<SYS>> 系统提示必须存在，且内容要与任务强相关（不能写“you are helpful”这种泛泛而谈的话）；
• instruction 和 input 之间用中文冒号+空格分隔，避免tokenizer误判；
• output 必须以 </s> 结尾，否则 data_collator 会截断。

数据处理脚本核心逻辑：

from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-2-7b-hf", use_fast=True)

def format_sample(sample):
    # 构建完整prompt
    prompt = f"<s>[INST] <<SYS>>\n{sample['system_prompt']}\n<</SYS>>\n\n{sample['instruction']}：{sample['input']} [/INST]"
    # 拼接output，确保EOS
    full_text = prompt + sample["output"] + "</s>"
    # tokenizer时truncation=True, padding=False，避免填充干扰
    return {"text": full_text}

# 用datasets.map处理
dataset = dataset.map(format_sample, remove_columns=dataset.column_names)

注意： remove_columns 必须写，否则 datasets 会保留原始字段，在 DataCollatorForLanguageModeling 里报错“unexpected column”。

3.3 LoRA配置与模型加载：绕过PEFT封装，直控底层参数

很多人用 get_peft_model() 一层封装，结果debug时找不到LoRA层在哪。我们选择手动注入，这样每个LoRA模块的位置、形状、初始化方式都一目了然：

from peft import LoraConfig, get_peft_model
from transformers import AutoModelForCausalLM

# 1. 加载基础模型（4-bit量化，省显存）
model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-2-7b-hf",
    load_in_4bit=True,  # 关键！4-bit量化
    bnb_4bit_quant_type="nf4",  # NormalFloat4，比fp4更稳
    bnb_4bit_compute_dtype=torch.bfloat16,
    device_map="auto",  # 自动分配到GPU
)

# 2. 手动定义LoRA配置（比get_peft_model更透明）
peft_config = LoraConfig(
    r=8,                          # 秩
    lora_alpha=16,                # 缩放分子
    target_modules=["q_proj", "v_proj"],  # 精准打击
    lora_dropout=0.05,            # 防过拟合
    bias="lora_only",             # 只训练bias，不碰原始bias
    modules_to_save=["lm_head"]   # 保命，必须加！
)

# 3. 注入LoRA层（这才是关键操作）
model = get_peft_model(model, peft_config)
model.print_trainable_parameters()  # 输出：trainable params: 131,072 || all params: 6,738,415,616 || trainable%: 0.00194

这里有个隐藏技巧： print_trainable_parameters() 输出的 trainable% 必须是0.00194左右（131K/6.7B），如果显示0.00000，说明LoRA没注入成功——常见原因是 target_modules 名字写错（比如写成 "query_proj" 而不是 "q_proj" ），或者模型路径不对（用了 llama-2-7b-chat-hf 但没加chat template）。

3.4 训练配置：为什么 per_device_train_batch_size=4 是RTX 4090的甜点值

Batch size不是越大越好。我们实测了不同设置：

per_device_train_batch_size	gradient_accumulation_steps	实际batch_size	显存占用	loss稳定性
1	32	32	4.8GB	振荡剧烈，每100step spike一次
2	16	32	5.1GB	较稳，但收敛慢
4	8	32	5.2GB	最优 ，loss平滑下降
8	4	32	6.3GB	显存浪费，无收益提升

为什么4是甜点？因为Llama 2的sequence length=2048时，单样本显存占用≈1.3GB，batch_size=4刚好填满4090的24GB（留2GB给系统）。更大的batch会触发CUDA内存碎片，反而降低吞吐。

完整训练参数：

from transformers import TrainingArguments

training_args = TrainingArguments(
    output_dir="./llama2-lora-legal",      # 输出路径
    per_device_train_batch_size=4,         # 单卡batch
    gradient_accumulation_steps=8,         # 梯度累积到32
    optim="paged_adamw_32bit",             # 内存优化版AdamW
    logging_steps=10,                      # 每10步打日志
    save_steps=50,                         # 每50步存checkpoint
    learning_rate=2e-4,                    # LoRA专用学习率，比全量小10倍
    fp16=True,                             # 混合精度
    max_grad_norm=0.3,                     # 梯度裁剪，防爆炸
    warmup_ratio=0.03,                     # 3% warmup，让LoRA层先热身
    lr_scheduler_type="cosine",            # 余弦退火，比linear更稳
    report_to="none",                      # 不连wandb，省资源
    num_train_epochs=3,                    # 3轮足够，再多易过拟合
    group_by_length=True,                  # 按长度分组，减少padding浪费
)

关键细节： optim="paged_adamw_32bit" 是bitsandbytes提供的分页AdamW，能把优化器状态从32GB（全量）压到1.2GB，这是单卡跑通的关键。不用它， AdamW 状态本身就会OOM。

3.5 效果验证：不用BLEU，用“错题重练”机制测真实理解力

训练完模型，别急着 generate() 。我们设计了一套业务导向的验证流程：

Step 1：构造对抗样本

• 从训练集随机抽100条样本，把 output 里的关键实体（如“30天”）替换成错误值（“15天”），形成“错题”；
• 输入这个错题，看模型是否能识别错误并修正：“不正确，根据条款，应为30天”。

Step 2：逻辑链回溯

• 对每个样本，强制模型用 [THINK]...[/THINK] 格式输出推理过程；
• 人工检查 [THINK] 里是否包含“合同第3.2条”、“签署后”、“交付货物”等关键要素，缺一个就判逻辑断裂。

Step 3：跨任务泛化

• 在未见过的“劳动合同纠纷”子任务上测试，看是否迁移有效。我们发现，只在“买卖合同”上微调的模型，在“劳动争议”上F1只有61%，于是加入200条劳动法样本做二次微调，F1升至79%。

最终效果：

指标	全量微调	LoRA(r=8)	LoRA(r=16)
合同条款准确率	93.2%	92.7%	93.6%
通用问答退化率	-4.1%	-0.3%	-0.7%
单次推理耗时（ms）	1240	1180	1210
显存占用（MB）	13200	5240	5890

LoRA不仅没输精度，还赢在了 可控性 ——你可以随时卸载LoRA层，秒切回原始Llama 2，而全量微调是“一锤定音”。

4. 常见问题与排查技巧实录：那些文档里绝不会写的血泪教训

4.1 “CUDA out of memory”不是显存不够，而是内存碎片

现象：训练到第200步，突然OOM，但 nvidia-smi 显示显存只用了18GB（4090有24GB）。

根因：PyTorch的CUDA内存分配器在长时间运行后会产生大量小碎片，新tensor申请大块连续内存失败。

解决方案（三板斧）：

1. 在 TrainingArguments 里加 torch_compile=True （PyTorch 2.1+），启用TorchDynamo编译，减少动态图开销；
2. 每100步手动清缓存：

if step % 100 == 0:
    torch.cuda.empty_cache()
    gc.collect()  # 强制Python垃圾回收

3. 最狠一招：用 accelerate launch 替换 python train.py ，它内置内存优化器：

accelerate launch --config_file ./accelerate_config.yaml train.py

其中 accelerate_config.yaml 包含：

mixed_precision: "bf16"
gradient_accumulation_steps: 8
cpu_offload: false

4.2 “Loss stays at nan”——90%是tokenizer惹的祸

现象：训练开始loss就是 nan ，且一直不变。

排查路径：

• 第一步，检查 dataset[0]["text"] 是否含非法字符（如 \x00 、 \ufffd ），用 repr() 打印；
• 第二步，验证tokenizer是否能双向encode-decode：

sample = dataset[0]["text"]
ids = tokenizer.encode(sample)
decoded = tokenizer.decode(ids)
assert sample == decoded, f"Mismatch: {sample[:50]} vs {decoded[:50]}"

• 第三步，确认 eos_token_id 是否正确：Llama 2的EOS是 </s> ，ID=2，但有些旧版tokenizer会映射错。强制设置：

tokenizer.pad_token = tokenizer.eos_token
tokenizer.pad_token_id = tokenizer.eos_token_id

4.3 推理时输出乱码：“The answer is ”

这是最经典的坑。原因：微调时用了 load_in_4bit=True ，但推理时没保持一致。

正确推理代码：

from peft import PeftModel

# 必须用4-bit加载基础模型
base_model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Llama-2-7b-hf",
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    device_map="auto"
)

# 加载LoRA权重（不是整个模型！）
model = PeftModel.from_pretrained(base_model, "./llama2-lora-legal/checkpoint-150")

# 关键：merge_and_unload()会把LoRA权重合并进base_model，但会失去4-bit
# 所以我们不用它，直接用PeftModel.forward()
inputs = tokenizer("Question: ...", return_tensors="pt").to("cuda")
outputs = model.generate(**inputs, max_new_tokens=256)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

注意： PeftModel.from_pretrained() 加载的是LoRA delta权重，不是完整模型。如果误用 AutoModelForCausalLM.from_pretrained("./llama2-lora-legal") ，会加载一个没合并的半成品，输出必然乱码。

4.4 如何快速判断LoRA是否生效？三行代码验真身

别等训练完再验证。在 Trainer.train() 前，插入：

# 检查LoRA层是否被正确注入
for name, module in model.named_modules():
    if "lora" in name.lower():
        print(f"LoRA active in {name}: {module.weight.shape}")

# 检查梯度是否只流向LoRA层
for name, param in model.named_parameters():
    if param.requires_grad and "lora" not in name.lower():
        print(f"ERROR: Unexpected trainable param: {name}")

# 检查forward是否走LoRA路径
with torch.no_grad():
    inputs = tokenizer("test", return_tensors="pt").to("cuda")
    outputs = model(**inputs)
    print("Forward successful, logits shape:", outputs.logits.shape)

输出应为：

LoRA active in base_model.model.layers.0.self_attn.q_proj.lora_A: torch.Size([8, 4096])
LoRA active in base_model.model.layers.0.self_attn.q_proj.lora_B: torch.Size([4096, 8])
...
ERROR: Unexpected trainable param: None  # 这行不能有输出！
Forward successful, logits shape: torch.Size([1, 2, 32000])

4.5 多任务LoRA：一个基座，三个专家，怎么管理不打架？

业务需求：同一Llama 2基座，要同时支持法律、教育、医疗三个垂直方向。

方案： Adapter-style LoRA ，即为每个任务训练独立的LoRA权重，推理时动态切换。

实现步骤：

1. 训练三个LoRA： legal_lora , edu_lora , med_lora ，保存为独立目录；
2. 推理时，用 model.load_adapter() 动态加载：

model.load_adapter("./legal_lora", "legal")
model.load_adapter("./edu_lora", "edu")
model.set_adapter("legal")  # 切换到法律模式
# ... generate ...
model.set_adapter("edu")    # 切换到教育模式

注意： set_adapter() 是即时生效的，无需重新加载模型。我们实测切换耗时<5ms，完全满足在线服务需求。

5. 进阶技巧与生产部署：从Notebook到API服务的最后1公里

训练只是起点，真正价值在落地。我们把LoRA微调的Llama 2部署到了Kubernetes集群，QPS稳定在23（p95延迟<800ms），以下是关键经验。

5.1 模型瘦身：LoRA权重从120MB压到18MB

默认保存的LoRA权重包含完整 state_dict ，含大量零值和冗余metadata。生产环境必须压缩：

# 保存前清理
peft_state_dict = model.peft_config["default"].get_state_dict(model)
# 只保留非零LoRA权重
pruned_dict = {}
for k, v in peft_state_dict.items():
    if torch.count_nonzero(v) > 0:  # 过滤全零矩阵
        pruned_dict[k] = v.half()  # 转FP16
torch.save(pruned_dict, "./legal_lora_pruned.bin")

体积从120MB→18MB，下载加速6.7倍，CI/CD流水线从8分钟缩到90秒。

5.2 API服务：用vLLM加速，吞吐翻3倍

Hugging Face的 pipeline 太慢。我们切换到vLLM：

pip install vllm

启动命令：

python -m vllm.entrypoints.api_server \
  --model meta-llama/Llama-2-7b-hf \
  --enable-lora \
  --lora-modules legal=./legal_lora \
  --lora-dtype bfloat16 \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.9

vLLM的PagedAttention机制让KV Cache内存利用率提升40%，实测QPS从7.2→23.1。关键是它原生支持LoRA热加载， POST /v1/lora/modules 就能动态增删任务模块。

5.3 持续学习：如何用新数据增量更新LoRA，而不重训？

业务每天产生新合同，不能每次重训。方案：

• 保存上一轮的LoRA权重 legal_v1.bin ；
• 用新数据（100条）继续训练，但 learning_rate=1e-5 （比初训小10倍）；
• 保存为 legal_v2.bin ；
• 在API服务里，用 vLLM 的 --lora-modules 参数同时加载两个，用 adapter_name 区分。

我们做了AB测试：增量更新3轮后，模型在新类型合同（跨境贸易）上准确率从68%→84%，而重训要花4小时，增量只要12分钟。

5.4 安全兜底：当LoRA失效时，如何秒级切回基座模型？

生产环境必须有熔断机制。我们在API网关层加了健康检查：

• 每5分钟用预设的3条黄金样本请求模型；
• 如果任一样本输出含 <unk> 、 <pad> 或长度<10，触发告警；
• 同时自动切换 set_adapter(None) ，回归原始Llama 2；
• 告警后，运维收到企业微信消息，附带 curl 诊断命令：

curl -X POST http://api/model/health -d '{"sample":"test"}'
# 返回{"status":"ok","adapter":"legal","latency_ms":420}

这套机制上线半年，0次P0事故，平均恢复时间<8秒。

最后分享个小技巧：我们把LoRA的 r 和 lora_alpha 做成环境变量，通过K8s ConfigMap注入，这样不用改代码就能动态调参。比如发现某天合同复杂度飙升，就临时把 r 从8调到12，观察效果——真正的工程化，是把算法变成可配置的基础设施，而不是写死的脚本。