老实说我第一次听到“大模型微调”这五个字时脑子里浮现的全是动辄几十亿参数的庞然大物、成排的A100显卡和按小时计费的云集群。但真正把一个NLP项目从想法推到生产环境之后我的结论变了大部分业务场景根本用不着那种规模的模型。用Hugging Face生态微调一个亿级参数以下的小型NLP模型把它训练成你所在行业的“专家”才是绝大多数人真正需要掌握的能力。这篇文章就记录我用Hugging Face的transformers、datasets、peft、trl这一套工具链把通用预训练模型微调成指定场景专用模型的全过程。内容包括选型逻辑、数据准备、LoRA实战训练、评估部署以及我踩过的几个比较典型的坑。适合那些刚开始接触大模型微调、手头GPU资源不算充裕、想把模型真正用起来而不是停在“跑通demo”阶段的读者。1. 为什么我不直接调大模型API而是选择微调小型模型1.1 API方案看起来很香但账不是这么算的先声明立场我不是反对用大模型API。对于通用问答、知识检索、文档摘要这类开放域任务API确实是最省事的路径。拿Key一调几行代码出结果效果好得惊人。但如果你面对的是一个具体的业务场景——比如把客服工单分成“物流投诉、质量问题、退换货意愿、其他”四类或者从维修报告里抽取故障部位和原因——API方案有三个绕不开的问题。第一是成本随调用量线性增长。单次调用看似只要几分钱但生产环境的日请求量上去之后这是一笔每月都在扣的固定开销。我之前接手过一个电商客服工单分类项目上线当天涌进五万条工单。每条都走外部API意味着每一条都要付出延迟和费用还得盯着并发配额够不够。微调完模型之后就完全不同了模型就是本地几个文件推理消耗的是自己的CPU或GPU边际成本几乎为零。第二是数据出境和合规问题。金融、医疗、政务类的项目用户数据能不能发到第三方API是个硬性红线。客户合同、病例描述、内部工单这些内容过一遍外部服务即使对方承诺不留存合规部门也不会给你签字。本地微调开源模型数据从头到尾不出内网这是API给不了的。第三是可控性。API模型是黑盒你没法固定它的行为。今天调用是这个效果明天官方更新一版权重你的分类结果可能就变了你还不知道哪里变了。开源模型微调完你可以锁死版本、冻结参数、做完整的回归测试这是生产系统非常看重的一点。1.2 什么情况下“小型模型”够用这里说的“小型模型”指参数量在亿级以下的预训练模型。典型代表是BERT系列约1.1亿参数、DistilBERT约6600万参数、RoBERTa-base以及中文场景常用的bert-base-chinese、chinese-roberta-wwm-ext。它们放在今天的大模型语境里确实显得“传统”但正因为参数量小在特定场景下有实打实的优势推理快纯CPU环境也能跑到毫秒级单条延迟不用依赖GPU服务器。显存门槛低8G显存的消费级显卡就能完成微调和推理学生党也玩得起。行为稳定参数规模小、输出形式可控基本不会出现幻觉式回答。你可能会问现在流行的是LLM怎么还在推这种小模型我的判断标准很简单——看任务的输出类型。如果你的业务输出是“分类标签”“抽出来的字段”“相似度分数”这类结构化结果而且场景文本的语言比较固定工单、合同、评价、公告小型模型微调就是性价比最高的方案。反过来如果任务需要开放式生成、多轮对话、复杂推理那确实得上更大的模型但那是另一套技术栈和成本模型了。1.3 微调的本质让预训练模型“转行”要理解微调先要理解预训练模型是什么。可以把它想成一个读过海量通用文本的实习生懂语法、懂常识、词汇量很大但完全不懂你业务里的行话、规则和判断逻辑。微调就是拿一批标注好的业务数据让这个实习生在你指定的任务上“转行”。从技术角度拆解预训练模型的主体是Transformer编码器或解码器它把输入文本编码成一组语义向量模型的顶部接一个任务头把这个向量映射到你的输出空间。分类任务就是加一个线性分类层序列标注任务就是加一个token级别的分类层。训练时损失函数计算模型预测与标注之间的差异然后反向传播更新权重。更新全部参数叫全量微调Full Fine-tuning只额外学习一小批低秩矩阵的参数叫LoRA后者资源和时间开销都小得多也是我这次采用的主要方法。2. 微调前的准备硬件、环境、数据集和模型选型2.1 硬件门槛没有A100也能跑很多人一听“训练模型”就以为必须搞一张几万块的卡。实测下来微调小型NLP模型的硬件门槛远低于你的想象。我第一次跑这个项目用的是一张RTX 3060 12G全量微调BERT分类模型batch size控制在16左右显存占用约9-10G。如果改用LoRA12G显存能轻松开更大的batch size甚至可以尝试参数量再大一些的模型。如果你的机器只有CPU也不是不能跑。6核8核的CPU配合16G以上内存微调一个BERT分类模型、几千条样本、20个epoch大概需要几个小时到十几个小时。慢是真的慢但足以把整个流程走通。我的建议是第一次接触微调先在CPU上用小数据集把transformers的Trainer机制跑顺确认数据和代码都没问题再上GPU训练这样能省下一大把排查时间。内存方面建议16G起步。因为PyTorch加载模型、构造DataLoader、做tokenize的时候内存开销比模型参数本身要大得多。我试过8G内存的机器跑Bert-base的训练经常在数据预处理阶段直接把内存吃满进程被杀掉。2.2 环境安装Hugging Face生态四件套微调需要安装的库就是Hugging Face生态里的几个组件各有分工transformers模型架构、预训练权重加载、Tokenizer都在这里。datasets负责数据集的加载和预处理自带缓存和内存映射几万条数据也不会撑爆内存。peft参数高效微调库LoRA、IA3等方法的实现都在里面。trl针对强化学习和SFT监督式微调的高层封装如果是做生成式模型的指令微调会用到。安装命令一行搞定pip install transformers datasets peft trl accelerate evaluateaccelerate看起来不起眼但特别重要。它统一管理设备、混合精度、多卡并行这些底层调度没有它你写训练脚本时要自己处理model.to(cuda)、no_grad、混合精度开关这一堆细节有了它Trainer内部自动处理。版本兼容性是个容易栽跟头的点。建议安装时不要无脑pip install最新版而是先建一个干净的conda环境再装PyTorch官方推荐的版本组合。我在不同机器上遇到过transformers和accelerate版本不匹配导致的报错最典型的是Trainer在构造时就提示Accelerator相关的属性错误。解决方案很简单查看transformers的README里标注的依赖版范围把peft和accelerate降到对应版本区间。2.3 训练数据的准备格式、数量与质量微调的效果数据质量说了算这比模型选型的影响大得多。我第一次做的时候就栽过跟头以为找个开源数据集跑通代码就等于完成了微调结果在真实业务数据上表现稀烂。后来总结出一套准备数据的流程。首先是数据格式。分类任务最常用的是CSV或JSONL每条数据包含“文本”和“标签”两个字段。JSONL的灵活性更好因为可以方便地加字段比如来源渠道、时间戳、标注人ID后面做错误分析时这些信息能帮大忙。示例如下{text: 你们的快递三天了还没到客服电话也打不通什么情况, label: 物流投诉} {text: 这件衣服洗了一次就掉色质量太差了要求退货, label: 质量问题}其次是数量。很多教程说“几百条就行”这个说法有误导性。几百条能跑通流程但效果大概率不稳定。以我的经验一个四五分类的任务每类至少准备500-1000条样本整体数据量在3000-5000条以上微调出来的模型才比较可信。数据量不够时优先保证每个类别的样本分布和真实业务分布接近而不是盲目追求总数。然后是质量。几个常见问题标签给错标注员理解不一致、文本和标签不匹配文本内容与类别无关、重复样本同一用户重复提交导致训练集和测试集泄漏。我现在的做法是数据准备阶段先花时间做一次抽样人工复核随机抽100条看标签一致性。如果发现某个类别的标注分歧率超过5%就先回头修正标注规范而不是急着训练。2.4 基础模型选型中文场景我常用的几个选模型要看三个维度参数量、预训练语料、下游任务适配度。英文场景我常用distilbert-base-uncased做基线又快又小。中文场景选择多一些说说我实际用过的模型参数量优点适合场景bert-base-chinese1.1亿经典通用生态成熟分类、匹配、抽取的通用基线chinese-roberta-wwm-ext1.1亿全词掩码中文理解更强中文语义分类、阅读理解hfl/chinese-macbert-base1.1亿语法纠错预训练边界感知好序列标注、分词类任务uer/roberta-base-finetuned-jd-binary-chinese1.1亿在京东评论上微调过评论情感分类速测选型建议很直接没有特殊需求就从bert-base-chinese或chinese-roberta-wwm-ext开始。这两个模型的资料最多出了问题好查。不要一上来就追求“更大更强”小型模型本身就是本文的主题先把流程跑通、把评估体系建起来再去对比其他候选模型才有意义。3. 核心环节用LoRA把模型拉进你的业务场景3.1 为什么选LoRA而不是全量微调全量微调看起来最简单加载模型、调Trainer、开训为什么我最后选了LoRA原因有三。第一是显存。全量微调时要保存梯度、优化器状态、中间激活值显存开销大约是模型参数量的几倍到十几倍。BERT-base参数量1.1亿FP32下模型本身400多MB但训练时轻松吃满10G显存。LoRA冻结原模型权重只训练插入的低秩矩阵这些矩阵的参数占比通常不到1%中间激活值仍然要存但优化器状态和梯度的开销大幅缩水8G显存也能跑。第二是训练时间。全量微调需要更新所有参数每次反向传播的计算量远高于LoRA。LoRA在数据量不大的情况下训练速度大约是全量微调的2-3倍。第三是灾难性遗忘控制。全量微调在业务数据量不足时很容易把模型原本的通用语言能力“冲掉”出现越训越差的现象。LoRA因为只改低秩子空间对原有权重的扰动小泛化能力保留得更好。这也是LoRA能成为当前微调主流方法的原因。LoRA的原理可以这么理解在原始权重矩阵旁边并联一条“旁路”。旁路由两个低秩矩阵A和B的乘积构成训练时只更新A和B原权重不变。前向计算时输出等于原权重输出加上旁路输出。推理时再把旁路和原权重合并成一个矩阵不增加任何推理延迟。3.2 数据预处理和Data Collator的细节数据处理是微调代码里最容易被忽略、但最影响效果的部分。我拆开讲几个关键点。首先是Tokenizer。记得设置truncationTrue和max_length。小模型有最大序列长度限制BERT是512但并不意味着你要一直撑到512。你的业务文本如果平均只有50个字把max_length设成128就够了这样训练和推理都快很多。不要无脑用512序列越长注意力计算量越大训练时间成倍增加。其次是padding策略。Trainer会自动用Data Collator处理batch内的padding。我推荐用DataCollatorWithPadding而不是自己手动pad。区别在于手动pad会把所有样本pad到同一个固定长度浪费计算DataCollatorWithPadding只把当前batch内的样本pad到该batch最大长度更高效。第三是标签的编码。分类标签要先转成整数ID。用Hugging Face的map方法处理数据集时注意保持字段名一致文本字段喂给模型时叫input_ids、attention_mask标签字段叫labels。Trainer只认这几个名字不要自定义成label_ids之类的否则会报找不到键。3.3 微调代码逐段拆解下面这份代码是我实际跑通过的一个分类微调脚本基于LoRA数据集用的是本地JSONL文件。我把它压缩成核心部分逐段注释。import json from datasets import Dataset, DatasetDict from transformers import ( AutoTokenizer, AutoModelForSequenceClassification, DataCollatorWithPadding, TrainingArguments, Trainer ) from peft import LoraConfig, get_peft_model, TaskType import numpy as np from evaluate import load # 1. 加载数据集 def load_jsonl(path): with open(path, r, encodingutf-8) as f: data [json.loads(line) for line in f if line.strip()] return data train_data load_jsonl(train.jsonl) dev_data load_jsonl(dev.jsonl) dataset DatasetDict({ train: Dataset.from_list(train_data), validation: Dataset.from_list(dev_data), }) # 2. 加载模型和tokenizer model_name hfl/chinese-roberta-wwm-ext tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForSequenceClassification.from_pretrained( model_name, num_labels4 ) # 3. 标签映射 label2id {物流投诉: 0, 质量问题: 1, 退换货意愿: 2, 其他: 3} id2label {v: k for k, v in label2id.items()} def preprocess_func(examples): tokenized tokenizer( examples[text], truncationTrue, max_length128, ) tokenized[labels] [label2id[lab] for lab in examples[label]] return tokenized tokenized_dataset dataset.map(preprocess_func, batchedTrue) # 4. 配置LoRA lora_config LoraConfig( task_typeTaskType.SEQ_CLS, r8, lora_alpha16, lora_dropout0.1, target_modules[query, value], ) peft_model get_peft_model(model, lora_config) peft_model.print_trainable_parameters()这里重点说target_modules。它指定把LoRA旁路插到模型哪些模块上。对于BERT类模型最常见的做法是插到query和value两个投影矩阵上这是LoRA论文里的默认选择。有些教程会把key、output.dense也一起加上效果确实可能更好但可训练参数量会增加。我的经验是先用query和value跑一版基线再按需扩展不要一上来就全加上。# 5. 训练参数 training_args TrainingArguments( output_dir./lora-bert-ckpt, learning_rate2e-5, per_device_train_batch_size16, per_device_eval_batch_size32, num_train_epochs5, logging_steps50, eval_strategysteps, eval_steps200, save_strategysteps, save_steps500, load_best_model_at_endTrue, metric_for_best_modeleval_f1, greater_is_betterTrue, fp16True, ) # 6. 评估函数 accuracy load(accuracy) f1 load(f1) def compute_metrics(eval_pred): logits, labels eval_pred preds np.argmax(logits, axis-1) return { accuracy: accuracy.compute(predictionspreds, referenceslabels), f1: f1.compute(predictionspreds, referenceslabels, averagemacro), } # 7. Trainer训练 trainer Trainer( modelpeft_model, argstraining_args, train_datasettokenized_dataset[train], eval_datasettokenized_dataset[validation], tokenizertokenizer, data_collatorDataCollatorWithPadding(tokenizertokenizer), compute_metricscompute_metrics, ) trainer.train() # 8. 保存完整合并后的模型 peft_model.save_pretrained(./lora-bert-final)训练完成后LoRA的适配器文件adapter是单独保存的很小可能就几MB。部署时有两种选择一是用peft_model直接推理二是我更推荐的方式——先把LoRA权重合并回原模型再保存完整模型。合并用一行代码merged_model peft_model.merge_and_unload() merged_model.save_pretrained(./bert-final-full) tokenizer.save_pretrained(./bert-final-full)合并的好处是部署环境不用再装peft库用纯transformers就能加载减少依赖。4. 训练过程中的监控与调参两种焦虑都要处理4.1 训练日志怎么看loss不是唯一指标训练启动之后你会看到Trainer每50步打印一次日志里面包含loss、learning_rate、epoch等字段。新手最容易犯的错是只盯loss看它从2.0掉到0.3就以为训练成功了。其实训练loss下降只能说明模型在训练数据上学到了东西不能说明它在验证集上也好。真正的关键是验证集上的eval_loss和自定义指标。我习惯把日志数据存下来训练完画两条曲线一条是training loss一条是eval loss或f1。如果train loss持续下降、eval loss在某个点开始反弹那就是典型的过拟合信号应该在反弹点附近选择checkpoint。Trainer默认会保存每个save_steps间隔的checkpoint配合load_best_model_at_endTrue训练结束时会自动帮你加载验证集上最优的那份权重。注意metric_for_best_model要设成你真正关心的指标。我习惯用macro F1而不是准确率因为多数业务场景下类别不均衡准确率会被多数类带偏。4.2 学习率、batch size、epoch的联动调整微调小模型的参数基线如下这是我在多个项目里反复验证的起点值参数推荐起点调整方向learning_rate2e-5 ~ 3e-5数据少用1e-5起数据多用5e-5封顶per_device_train_batch_size16显存不够就降到8num_train_epochs3 ~ 5看eval曲线决定是否提前停weight_decay0.01防止过拟合保持默认即可warmup_ratio0.1避免前期loss剧烈波动学习率是最敏感的超参数。大模型微调圈子里有个共识预训练模型已经学到了很好的特征空间微调不需要也不应该用太大的学习率去“猛踩油门”。2e-5这个量级意味着每一步只对权重做微小的修正。如果你发现训练loss在几个step内就掉到接近0那大概率是学习率设高了模型在机械背诵训练样本。epoch的选择和你的数据量直接相关。数据量越大需要的epoch越少。数据5000条3-5个epoch一般够用数据只有1000条可能要跑到8-10个epoch才能看到明显效果但过拟合风险也随之上升。我现在的做法是先用5个epoch跑一版观察eval曲线的最低点出现在第几个epoch再决定是加量还是提前截断。4.3 过拟合的识别与干预过拟合在小数据量微调里太常见了。判断方法很简单训练集准确率接近100%验证集准确率却上不去或者训练loss和eval loss之间的差距越拉越大。我经历过最典型的一次训练集F1到了0.97验证集只有0.74差了一大截。干预手段按优先级排序增加数据尤其缺的类别。这永远是最有效的。降低学习率。学习率从3e-5降到1e-5让模型学得更慢更细。加正则。dropoutLoRA里有lora_dropout参数、weight_decay都值得调。提前截断。eval指标不再提升就停止训练可以用Trainer的EarlyStoppingCallback。EarlyStoppingCallback的使用是这样from transformers import EarlyStoppingCallback trainer.add_callback( EarlyStoppingCallback(early_stopping_patience3, early_stopping_threshold0.005) )patience3表示连续3次eval没有明显提升就停止threshold0.005是防止微小波动触发早停。这个机制在生产训练里非常实用能帮你省下不少GPU时间。5. 验证与部署从测试集指标到真正上线5.1 评估指标的选择准确率之外还看什么我看到太多人在微调项目里只报告准确率然后宣称“效果95%”。这在类别均衡的分类任务里勉强说得过去但真实业务几乎都是不均衡的。比如工单分类里“其他”类可能占60%“退款意向”只占5%。模型如果把所有样本都判成“其他”准确率也有60%但业务上毫无价值。我的建议是至少看三个指标macro F1、每类别的precision/recall、以及混淆矩阵。sklearn.metrics里都有现成实现from sklearn.metrics import classification_report, confusion_matrix y_pred trainer.predict(tokenized_dataset[test]) pred_labels np.argmax(y_pred.predictions, axis-1) true_labels y_pred.label_ids print(classification_report(true_labels, pred_labels, target_names[物流投诉, 质量问题, 退换货意愿, 其他])) print(confusion_matrix(true_labels, pred_labels))分类报告能直接暴露“哪个类别被模型牺牲了”。我曾经在一个四分类项目里发现“退换货意愿”的召回率只有0.31大量样本被误判成“质量问题”。根源是两个类别的文本高度相似——都提到了“退货”“质量问题”标注规范本身边界模糊。这个发现直接推动我们去重新梳理标注标准比调参有效得多。还要提醒一句评估集要和训练集做严格的用户级切分不要随机切分。同一个用户可能提交了多张重复工单如果这些重复样本同时出现在训练集和评估集你的指标会虚高上线后立刻现原形。5.2 模型导出与推理接入训练结束、评估通过之后下一步是把模型接进业务系统。我习惯另外写一个独立的推理脚本不依赖训练代码。核心加载逻辑如下from transformers import AutoTokenizer, AutoModelForSequenceClassification import torch model_path ./bert-final-full tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModelForSequenceClassification.from_pretrained(model_path) model.eval() def predict(text): inputs tokenizer(text, truncationTrue, max_length128, return_tensorspt) with torch.no_grad(): outputs model(**inputs) logits outputs.logits pred_id torch.argmax(logits, dim-1).item() return id2label[pred_id]这里有两个细节。第一加载后一定要调model.eval()否则模型保留训练时的dropout行为推理结果不稳定。第二保存完整模型时一定要连tokenizer一起保存因为分词器里的vocab.txt、tokenizer_config.json是推理端的必备文件丢了就得重新下载原版tokenizer万一版本不一致输入文本会被切得不一样效果直接打折。如果是线上服务可以包一层FastAPI接口from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class TextIn(BaseModel): text: str class TextOut(BaseModel): label: str score: float app.post(/classify, response_modelTextOut) def classify(req: TextIn): inputs tokenizer(req.text, truncationTrue, max_length128, return_tensorspt) with torch.no_grad(): logits model(**inputs).logits probs torch.softmax(logits, dim-1).squeeze() pred_id torch.argmax(probs).item() return TextOut(labelid2label[pred_id], scorefloat(probs[pred_id]))把模型加载放到模块加载时完成不要每次都重新加载。如果你用的是CPU服务单个BERT推理耗时大概在10-50毫秒之间取决于文本长度用gunicorn多worker就能扛住不小的QPS。5.3 量化与批量推理的进阶处理如果部署环境没有GPU只有CPU模型推理速度仍然可能成为瓶颈。两个常用优化手段ONNX Runtime和动态量化。ONNX导出很简单from transformers import AutoModelForSequenceClassification import torch model AutoModelForSequenceClassification.from_pretrained(./bert-final-full) dummy_input torch.randint(0, 1000, (1, 128), dtypetorch.long) torch.onnx.export( model, (dummy_input, torch.ones_like(dummy_input)), model.onnx, input_names[input_ids, attention_mask], output_names[logits], dynamic_axes{input_ids: {0: batch}, attention_mask: {0: batch}}, opset_version14, )导出后再用onnxruntime加载推理在CPU上的加速通常有2-4倍。如果还不够可以再做动态量化把权重从FP32压到INT8显存和内存占用降为原来的四分之一速度更快代价是精度通常损失1-2个百分点在分类任务里往往是可以接受的。6. 踩过的坑与沉淀下来的几点经验6.1 标签泄漏一个阴沟翻船的案例这是我犯过最隐蔽的错误。做合同要素抽取时我用一个“是否包含金额条款”的二分类来预筛文档。数据准备阶段我直接按“有没有金额字段”来打标签并把金额字段本身也保留在文本里没做脱敏。训练出来的模型在测试集上F1高达0.98上线后却惨不忍睹准确率掉到0.6。原因一目了然模型根本不是在学“什么是金额条款”而是学到了“看见符号就输出1”这属于典型的标签泄漏——标签信息被直接编码进了输入特征。处理办法是让输入字段里不包含与标签直接同源的内容。如果你的任务是从文本里抽某个字段训练输入就应该先把这个字段本身屏蔽掉。这类问题不会报错但会严重影响模型在真实场景的泛化能力只能靠复盘识别。6.2 类别不均衡别让模型学会偷懒前面说了不均衡的影响。再多说一个我踩过的具体场景工单分类里“其他”类占58%“退款意向”只有3%。直接训练的话模型会倾向把所有模糊样本都判进“其他”因为这样loss下降最快。解决办法是权重调整在Trainer里给每个类别设置不同的loss权重或者用class_weight参数。计算方式很简单某类的权重 总样本数 / (类别数 × 该类样本数)。这样少数类样本的loss会被放大模型不会“看不见”它们。还有一种更彻底的办法是重采样对少数类样本做过采样复制或做轻量扩增或者对多数类做欠采样。但重采样会改变原始分布上线时要做校准。我的优先级是先加类别权重再看效果决定要不要重采样。6.3 随机种子和版本一致性这算两个小坑但都让我白跑过训练。第一随机种子不固定。transformers训练涉及到模型初始化、数据shuffle、dropout如果没有固定种子同一次训练跑两份结果不会完全一样。虽然整体差距不大但复现问题和调试时会很头疼。记住在脚本开头加import random import numpy as np import torch def set_seed(seed42): random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) set_seed(42)第二模型保存和加载时的transformers版本不一致。我在公司服务器上训练transformers 4.38部署机器还是4.30结果加载模型时提示某些权重名不兼容直接报错。后来养成了两个习惯一是训练脚本里固定版本号README里写清楚二是保存模型时把transformers版本也写进配置文件的备注里。Hugging Face的from_pretrained对版本回退相对宽容但前向升级往往会有风险别忽视。6.4 LoRA的秩和alpha到底怎么调最后说说LoRA参数本身。r是低秩矩阵的秩决定旁路能表达多少新知识。alpha是缩放因子影响旁路对原输出的放大倍数。很多教程说“r8就好”但实际效果因任务而异。我的经验是数据量小千级用r4或8数据量大万级可以试r16。alpha通常设成r的两倍但如果训练loss下降太快把alpha降下来让微调更“收敛”一点。还有一个细节target_modules的配置在transformers新版本里支持通配符比如all-linear但这会把所有线性层都加上LoRA可训练参数量暴增。我仍然建议明确指定模块名称先打印model.named_modules()看一下结构再决定插在哪。微调小型NLP模型这件事本质上没有太多玄学。把数据质量管住、把评估体系建对、把训练参数落在合理区间剩下的就是耐心跑实验对比。和我最开始设想的完全不同最花时间的部分其实不在训练而是在数据清洗和指标定标上。这也是我建议每个刚入门的朋友不要急着跑代码的原因——先把“我的任务到底要什么指标”“我的数据边界在哪里”都想清楚再去碰GPU你会少走很多弯路。