1. 为什么我建议用Trainer而不是手写训练循环做NLP这两三年微调BERT几乎是家常便饭。很多人第一次动手都会习惯性地照着PyTorch的标准写法自己搭一个训练循环for epoch in range(3)里面再套一个for batch in dataloader一会儿要处理梯度清零一会儿又要搞eval、保存checkpoint、恢复训练……代码写到一半就没心情调参了。后来我切到HuggingFace的Trainer之后整个人就轻松很多——这个工具其实相当于把一套经过实战检验的训练样板给你封装好了你要做的只是填上模型、数据和训练参数剩下的事它自己处理。这篇文章只讲一件事怎么用HuggingFace生态里的Trainer把BERT模型稳稳地微调一次。用一句话概括就是“面向对象地微调”跟手写训练循环相比最大的价值不是代码量变少而是所有跟训练生命周期相关的细节都被统一标准化了分布式训练、混合精度、断点续训、日志回传、评估流程、checkpoint选择……你不用再跟这些坑较劲。什么场景下适合读这篇如果你是第一次微调BERT或者之前只会Copy网上的训练脚本但一改就报错又或者你手里已经有一个PyTorch的旧项目想往HuggingFace这套上迁移这篇文章都能帮你少走不少弯路。我会用一个IMDB情感二分类作为贯穿案例把从数据准备到训练评估的完整链路拆开讲。1.1 手写训练循环的隐藏成本先算一笔账。一个“看似完整”的手写微调脚本里你至少需要自己实现这几块学习率和warmup调度BERT微调对warmup很敏感直接用常数学习率效果经常很差梯度累积、梯度裁剪、AMP混合精度验证集的定时评估以及best model的记录断点保存与恢复多GPU下还要处理主进程的日志逻辑分布式训练的初始化、数据sampler的适配、reduce操作这些每一块单独都不难但凑在一起极其耗时间。我见过不少团队花在“把训练脚本跑通”上的时间比真正调模型的时间还多。Trainer存在的意义就是把这些工程层面的重复劳动全部接管让研究者把精力放回到模型和数据上。1.2 Trainer帮你做了什么Trainer不是一个花架子它在底层就是基于PyTorch的一层封装不过把很多细节做得非常成熟。简单列几个我最常用的能力传入TrainingArguments之后它会自动生成训练器配置处理设备分配内置Optimizer、LR Scheduler、warmup逻辑默认AdamW配linear schedule在训练过程中按提前设好的step间隔执行eval并把指标记录下来可以自动加载历史checkpoint断电了也不怕多卡训练、TPU训练都能用一个接口启动自带train(),evaluate(),predict()三个核心调用整个使用体验非常清晰。很多人担心Trainer是不是太“黑盒”了。实际上它完全支持自定义数据加载器、优化器、计算指标、回调函数、模型forward的包装它都有对应的入口。你完全可以把它当成一个可以修改的开源项目来用而不是只能接受的封闭框架。接下来我会从一个可复现的角度把每一步都落地给你看。2. 环境准备与数据处理别急着写trainer开始写代码之前先把环境打稳。Trainer的依赖其实很明确绝大部分深度学习绕不开的那些包它都要。我的建议是用conda建一个干净的环境避免掉进“某个依赖版本冲突一跑就崩”的坑。2.1 安装与镜像配置创建环境后建议一次性把下面这些装齐conda create -n bert-nlp python3.10 conda activate bert-nlp pip install torch --index-url https://download.pytorch.org/whl/cu118 pip install transformers datasets evaluate acceleratetransformers提供模型和Trainerdatasets负责数据集的加载与缓存evaluate用来加载像accuracy、f1这类指标accelerate是Trainer在分布式和混合精度场景下要用的后端。版本选择上建议transformers4.30新版对Trainer的稳定性有明显提升太低的老版本某些参数名都对不上。国内环境下载预训练模型经常卡住这里有个很实用的经验设置HuggingFace镜像站点为官方镜像地址模型、tokenizer、数据集都会走国内可达的下载通道。具体做法是给你当前的shell设置一个环境变量export HF_ENDPOINThttps://hf-mirror.com注意这个只是替换下载源跟代码本身没有任何关系也不需要修改你的from_pretrained路径。实测下来BERT这种size的模型镜像下载几分钟就能完成比起默认源动不动超时要舒服太多。以后每次新开终端都要记得重新设别嫌麻烦可以写进~/.bashrc里。2.2 数据集加载与tokenize我用IMDB影评情感分类来做演示原因是这个数据集够经典、规模合适、能说明问题又不会等太久。用datasets库加载只需要一行from datasets import load_dataset raw_datasets load_dataset(imdb) print(raw_datasets) # DatasetDict({ # train: Dataset({features: [text, label], num_rows: 25000}) # test: Dataset({features: [text, label], num_rows: 25000}) # unsupervised: ... # })IMDB的train和test各有25000条都是以text列存储影评。我们用电影评论来微调一个bert-base-uncased做情感分类这个案例既简单又贴近真实工作流。接下来是tokenize。这里最容易踩的坑是不知道truncation和padding该在哪里做。我的建议是只在dataset样本上做truncation把padding留给后面的data collator。from transformers import AutoTokenizer tokenizer AutoTokenizer.from_pretrained(bert-base-uncased) def tokenize_func(examples): return tokenizer(examples[text], truncationTrue, max_length512) tokenized_datasets raw_datasets.map(tokenize_func, batchedTrue)map函数默认会对整个数据集执行而且会缓存到磁盘第二次运行就能直接复用。用batchedTrue可以显著加速一条条处理太慢。处理完之后train和test每条样本都会多出input_ids、token_type_ids和attention_mask这三列后面做模型输入就靠它们。2.3 DataCollator的作用Padding很讲究如果在这里一股脑把整条样本都padding到512训练内存几乎会翻倍尤其对IMDB这种长评论场景非常不划算。正确写法是用DataCollator在组成batch时动态把当前batch内最长的样本填充到一致长度。from transformers import DataCollatorWithPadding data_collator DataCollatorWithPadding(tokenizertokenizer)这个collator会根据当前batch的长度分布决定最终pad到哪儿短样本不会为长样本买单。我实测过同样的batch size下用动态padding比固定512长度的内存占用有明显的下降整体训练速度也要快不少。如果你的任务是句子对分类需要keep的字段会多一些但核心思路一样能动态就别预设。3. 核心训练参数与Trainer搭建数据准备好了接下来就是Trainer的重头戏。很多人一上来就复制网上的TrainingArguments参数但光一个save_strategy就有好几种值用错会让你辛辛苦苦跑的模型到最后选不到最好的score。这一节我会把关键参数讲透。3.1 TrainingArguments参数解读TrainingArguments是Trainer的灵魂它控制训练轮数、学习率、batch size、保存策略、日志间隔、是否加载最优模型等一大堆选项。下面给一个我自己常用、适合在单卡或双卡上微调BERT的参数清单from transformers import TrainingArguments args TrainingArguments( output_dir./bert-imdb-checkpoints, evaluation_strategysteps, eval_steps500, save_strategysteps, save_steps500, logging_steps100, num_train_epochs3, per_device_train_batch_size16, per_device_eval_batch_size32, learning_rate2e-5, weight_decay0.01, warmup_ratio0.1, load_best_model_at_endTrue, metric_for_best_modeleval_accuracy, greater_is_betterTrue, fp16True, dataloader_num_workers4, report_tonone, )逐项拆开说几个容易忽略的evaluation_strategy和save_strategy建议都用steps然后用eval_steps和save_steps指定间隔。训练过程中持续记录eval指标将来画曲线也方便。如果你把两个strategy设成不同步的会出现“模型保存了但eval指标却没更新”的迷惑局面。load_best_model_at_end: 这个参数要跟metric_for_best_model配合使用。训练结束时它会基于指定的指标从checkpoint里把得分最高的那个模型重新加载回来用于后面的推理。fp16True: 在支持半精度的GPU上非常好用显存占用直接减半速度也会有提升。Ampere架构之后的卡基本都能开如果数据敏感或出现loss抖动再考虑关掉。report_tonone: 很多人忽略这一项。不设置的话Trainer默认会尝试连接tensorboard或wandb如果本地没有对应环境会在训练前打印一堆警告甚至报错。这里有个计算warmup的小技巧。我上面用了warmup_ratio0.1它表示训练总步数的前10%做学习率线性爬坡这对BERT类模型来说是一套很稳妥的默认值。如果你更习惯精确控制也可以用warmup_steps直接指定比如训练共1000步就设100。两者别同时设以warmup_steps优先。3.2 评估指标与compute_metricsTrainer默认不会自己评判模型好坏需要手动传入一个compute_metrics函数。这个函数接收一个EvalPrediction对象里面有predictions和label_ids返回一个指标字典。import numpy as np from evaluate import load accuracy_metric load(accuracy) f1_metric load(f1) def compute_metrics(eval_pred): predictions, labels eval_pred preds np.argmax(predictions, axis-1) accuracy accuracy_metric.compute(predictionspreds, referenceslabels)[accuracy] f1 f1_metric.compute(predictionspreds, referenceslabels, averagebinary)[f1] return {accuracy: accuracy, f1: f1}如果想偷懒完全可以把accuracy和f1的加载放在函数外面这样每次eval只会执行计算而不会重复加载指标。Trainer在预测时会输出原始logits所以必须用np.argmax先转成预测类别再和labels比对。3.3 实例化Trainer并开始训练实例化Trainer之前需要先加载模型。注意这里要用任务对应的带分类头的模型类不能直接加载BertModel否则你得不到一个可以直接做分类输出的模型。对于二分类任务from transformers import AutoModelForSequenceClassification model AutoModelForSequenceClassification.from_pretrained( bert-base-uncased, num_labels2, )from_pretrained第一次运行的时候会下载模型权重大概400多MB下载完之后会缓存到本地下次加载就不用再拉了。接下来把前面准备的东西一次性塞进Trainerfrom transformers import Trainer trainer Trainer( modelmodel, argsargs, train_datasettokenized_datasets[train], eval_datasettokenized_datasets[test], data_collatordata_collator, tokenizertokenizer, compute_metricscompute_metrics, )当你执行trainer.train()之后训练就正式开始了。我建议第一次跑的时候把训练集稍微切小一点比如只用2000条目的是先把流程跑通再上全量数据。全量IMDB在单张消费级GPU上大约要十几分钟到半小时如果是从没跑过的代码一上来就全量很容易把时间浪费在调试日志上。先把速度拉起来、确认loss在下降再谈规模。实际训练过程中你会看到Trainer打印类似这样的日志{loss: 0.412, learning_rate: 1.6e-05, epoch: 0.8}训练结束时如果load_best_model_at_endTrue它会提示已经加载了最优checkpoint这时trainer.model就是整个训练过程中表现最好的那一版。4. 训练收尾指标、模型保存与推理模型训练完了后面这几步很多人会忽略导致模型白跑。比如评估要把结果落盘、保存模型要把tokenizer一起存、推理时要搞清楚Trainer的predict到底返回什么。下面一次说清楚。4.1 evaluate与predict用Trainer做评估很简单eval_result trainer.evaluate() print(eval_result) # {eval_loss: 0.221, eval_accuracy: 0.912, eval_f1: 0.912}它的输出是一个字典key名称由你传入的compute_metrics里返回的键决定。比如这里我们返回了accuracy和f1前面的eval_是Trainer自动加上的前缀方便后续和metric_for_best_model对准。trainer.predict(test_dataset)同样可以用来产出预测结果返回的对象里有三个属性predictions是logits矩阵label_ids是真实labelmetrics是测试集指标。如果我们只是要一张提交表或者做线下分析直接从predictions里argmax即可。这里有个实际用过的细节如果你在训练时没有传入eval数据集evaluate()会直接报错因为它根本不知道要评估谁。遇到这种情况就在TrainingArguments里把evaluation_strategy设成no然后手动指定eval_dataset来调predict()。4.2 模型保存与重新加载Trainer训练结束后会自动在output_dir里保存checkpoint但最后一个checkpoint不一定是你想要的那版。如果开了load_best_model_at_endTrue推荐用下面这套姿势来保存trainer.save_model(./bert-imdb-final) tokenizer.save_pretrained(./bert-imdb-final)第一行会把模型结构和权重一起存下来第二行把tokenizer的词典和配置一起存下来。为什么tokenizer也要存因为推理时重新加载数据tokenizer如果版本或词表不一致输入token都会被编码错结果自然对不上。我见过有人在生产环境只存模型不存tokenizer下游一换环境全乱套的例子。之后无论何时要重新做推理只需要from transformers import AutoTokenizer, AutoModelForSequenceClassification model AutoModelForSequenceClassification.from_pretrained(./bert-imdb-final) tokenizer AutoTokenizer.from_pretrained(./bert-imdb-final)加载回来之后model.eval()和torch.no_grad()别忘了否则模型参数还处于training状态推理行为会有差异。4.3 训练过程日志怎么看训练过程中那一串loss和learning_rate的日志不是摆设。我一般重点关注三点loss下降趋势前几十个step如果loss不降反升先检查学习率和warmup配置大多数时候是学习率太大。eval指标与loss是否同步如果loss下降但accuracy不涨大概率是过拟合信号或者标签噪声太大。learning_rate的曲线Trainer的scheduler默认是linear decay加warmup日志里如果能确认learning_rate从极小的初始值爬升再下滑说明调度正常。另外一个很多新手不知道的地方如果你设置了save_steps500训练到第500、1000步时会自动创建checkpoint文件夹。这些文件夹里的内容就是完整可用的模型你完全可以在训练中断时直接把路径传给Trainer的resume_from_checkpointTrue来续训练。实际我做过一次实验断电后恢复训练loss曲线能很好地接上几乎零损失。5. 踩坑记录与排查思路写到这里训练流程基本闭环了。但任何框架在真实环境里都会有几个高频坑这一节我用FAQ的形式把遇到过的和同事遇到过的问题列出来每个都附排查思路省得你再去搜索引擎里翻。5.1 显存不足怎么办最常见的就是CUDA out of memory。BERT base的模型本身不大但序列长、batch一加大就容易爆。排查顺序建议如下先把per_device_train_batch_size降到8、4确认能跑通再往上加打开fp16True显存几乎能砍半用gradient_accumulation_steps保持“等效batch size”不变比如原来batch size 16现在batch size 4 accumulation 4等效训练效果接近但峰值显存大幅下降检查是不是被固定padding坑了用了DataCollatorWithPadding之后短样本的batch实际tensor会小很多这也是为什么我在第2节反复强调动态padding。假如是序列本身太长比如文本平均长度超过400那还得考虑max_length截断策略。直接截断尾部对情感分析这类任务影响通常不大但如果是阅读理解可能需要更精细的stride策略。5.2 过拟合与精度异常微调BERT在小数据集上特别容易过拟合。我有一阵用几千条数据做意图分类训练loss降到0.1以下验证loss却越走越高然后精度在0.8附近震荡。那一次的经历让我把几个技巧刻进DNA里增大weight_decay从0.01往0.05试减少训练轮数BERT微调往往3轮以内就够传统“训20轮”的思路不要套过来在TrainingArguments里使用EarlyStoppingCallback这是我最喜欢的功能之一from transformers import EarlyStoppingCallback, IntervalStrategy args TrainingArguments( output_dir./bert-imdb-checkpoints, evaluation_strategysteps, eval_steps300, save_strategysteps, save_steps300, num_train_epochs5, load_best_model_at_endTrue, metric_for_best_modeleval_accuracy, greater_is_betterTrue, ) trainer Trainer( ..., callbacks[EarlyStoppingCallback(early_stopping_patience2)], )early_stopping_patience2表示连续2个eval_steps间隔评估指标都没有改善时就会提前终止训练。用这个回调还有个好处不用为了“碰运气多训几轮”而浪费算力。另外如果你的任务类别极度不均衡accuracy会变得“虚高”光看accuracy根本判断不了好坏。这种情况建议用F1、AUC之类的指标或者在compute_metrics里同时输出混淆矩阵相关的统计值。5.3 环境与下载问题Run时报错里多数人会碰到两类比较典型的加载模型时连接超时上面已经提过用HF_ENDPOINThttps://hf-mirror.com。module transformers has no attribute Trainer这通常是transformers版本太老。升级到新版本即可pip install -U transformers。还有一小部分情况是环境里同时存在旧版安装路径建议重新建conda环境而不是原地覆盖。有些朋友喜欢把checkpoint直接传到网盘再从网盘下载到别的机器加载。但跨机器加载时如果两边的transformers版本不一样偶而会出现“weights key mismatch”的告警。正式部署前最好统一依赖版本或者至少保证from_pretrained时torch_dtype、device_map等参数符合目标环境。还有一个很容易被忽略的怪问题训练正常但eval时卡住不动。我排查过几次最后发现是dataloader_num_workers设得过高机器内存不够数据加载线程一直排队。降到0或2就能恢复。这个参数不是越高越好数据小或单机环境用默认值更稳。如果后续要扩展到更大模型比如把BERT换成RoBERTa、DeBERTa甚至做Llama这类生成模型的SFTTrainer这套流程依然是通用的。只想微调部分参数、节省显存的话可以在模型外再套一层PeftModelLoRATrainer同样能配合使用。我记得在HuggingFace的PEFT生态里一个peft_model get_peft_model(model, lora_config)就能把模型包装好剩下的Trainer调用完全不变。这一点也很适合在做完普通全参微调后进一步探索低资源微调方案。我个人现在的工作习惯是凡是标准分类/回归/抽取类任务一律用Trainer起步只有在对训练流程有定制化需求、或者需要逐层控制梯度时才会手写训练循环。用Trainer并不是因为它“高级”而是因为它把一个可复现、可维护的训练流程标准化了。团队协作里新人拿到这样一个代码结构一眼就能看出训练参数、数据、指标在哪省掉的沟通成本远超那点封装带来的“黑盒感”。最后再分享一个小技巧微调之前先用原始BERT在自己任务的小样本上跑一次甚至不微调直接拿[CLS]特征做逻辑回归得到一个“下限分数”。有了这个baseline你微调后如果提升不大至少能判断是不是任务本身太难而不是代码写得不对。这个习惯帮我避免了很多次“明明在跑代码其实在浪费时间”的尴尬。 HuggingFace Trainer微调BERT实战：参数配置与避坑指南
1. 为什么我建议用Trainer而不是手写训练循环做NLP这两三年微调BERT几乎是家常便饭。很多人第一次动手都会习惯性地照着PyTorch的标准写法自己搭一个训练循环for epoch in range(3)里面再套一个for batch in dataloader一会儿要处理梯度清零一会儿又要搞eval、保存checkpoint、恢复训练……代码写到一半就没心情调参了。后来我切到HuggingFace的Trainer之后整个人就轻松很多——这个工具其实相当于把一套经过实战检验的训练样板给你封装好了你要做的只是填上模型、数据和训练参数剩下的事它自己处理。这篇文章只讲一件事怎么用HuggingFace生态里的Trainer把BERT模型稳稳地微调一次。用一句话概括就是“面向对象地微调”跟手写训练循环相比最大的价值不是代码量变少而是所有跟训练生命周期相关的细节都被统一标准化了分布式训练、混合精度、断点续训、日志回传、评估流程、checkpoint选择……你不用再跟这些坑较劲。什么场景下适合读这篇如果你是第一次微调BERT或者之前只会Copy网上的训练脚本但一改就报错又或者你手里已经有一个PyTorch的旧项目想往HuggingFace这套上迁移这篇文章都能帮你少走不少弯路。我会用一个IMDB情感二分类作为贯穿案例把从数据准备到训练评估的完整链路拆开讲。1.1 手写训练循环的隐藏成本先算一笔账。一个“看似完整”的手写微调脚本里你至少需要自己实现这几块学习率和warmup调度BERT微调对warmup很敏感直接用常数学习率效果经常很差梯度累积、梯度裁剪、AMP混合精度验证集的定时评估以及best model的记录断点保存与恢复多GPU下还要处理主进程的日志逻辑分布式训练的初始化、数据sampler的适配、reduce操作这些每一块单独都不难但凑在一起极其耗时间。我见过不少团队花在“把训练脚本跑通”上的时间比真正调模型的时间还多。Trainer存在的意义就是把这些工程层面的重复劳动全部接管让研究者把精力放回到模型和数据上。1.2 Trainer帮你做了什么Trainer不是一个花架子它在底层就是基于PyTorch的一层封装不过把很多细节做得非常成熟。简单列几个我最常用的能力传入TrainingArguments之后它会自动生成训练器配置处理设备分配内置Optimizer、LR Scheduler、warmup逻辑默认AdamW配linear schedule在训练过程中按提前设好的step间隔执行eval并把指标记录下来可以自动加载历史checkpoint断电了也不怕多卡训练、TPU训练都能用一个接口启动自带train(),evaluate(),predict()三个核心调用整个使用体验非常清晰。很多人担心Trainer是不是太“黑盒”了。实际上它完全支持自定义数据加载器、优化器、计算指标、回调函数、模型forward的包装它都有对应的入口。你完全可以把它当成一个可以修改的开源项目来用而不是只能接受的封闭框架。接下来我会从一个可复现的角度把每一步都落地给你看。2. 环境准备与数据处理别急着写trainer开始写代码之前先把环境打稳。Trainer的依赖其实很明确绝大部分深度学习绕不开的那些包它都要。我的建议是用conda建一个干净的环境避免掉进“某个依赖版本冲突一跑就崩”的坑。2.1 安装与镜像配置创建环境后建议一次性把下面这些装齐conda create -n bert-nlp python3.10 conda activate bert-nlp pip install torch --index-url https://download.pytorch.org/whl/cu118 pip install transformers datasets evaluate acceleratetransformers提供模型和Trainerdatasets负责数据集的加载与缓存evaluate用来加载像accuracy、f1这类指标accelerate是Trainer在分布式和混合精度场景下要用的后端。版本选择上建议transformers4.30新版对Trainer的稳定性有明显提升太低的老版本某些参数名都对不上。国内环境下载预训练模型经常卡住这里有个很实用的经验设置HuggingFace镜像站点为官方镜像地址模型、tokenizer、数据集都会走国内可达的下载通道。具体做法是给你当前的shell设置一个环境变量export HF_ENDPOINThttps://hf-mirror.com注意这个只是替换下载源跟代码本身没有任何关系也不需要修改你的from_pretrained路径。实测下来BERT这种size的模型镜像下载几分钟就能完成比起默认源动不动超时要舒服太多。以后每次新开终端都要记得重新设别嫌麻烦可以写进~/.bashrc里。2.2 数据集加载与tokenize我用IMDB影评情感分类来做演示原因是这个数据集够经典、规模合适、能说明问题又不会等太久。用datasets库加载只需要一行from datasets import load_dataset raw_datasets load_dataset(imdb) print(raw_datasets) # DatasetDict({ # train: Dataset({features: [text, label], num_rows: 25000}) # test: Dataset({features: [text, label], num_rows: 25000}) # unsupervised: ... # })IMDB的train和test各有25000条都是以text列存储影评。我们用电影评论来微调一个bert-base-uncased做情感分类这个案例既简单又贴近真实工作流。接下来是tokenize。这里最容易踩的坑是不知道truncation和padding该在哪里做。我的建议是只在dataset样本上做truncation把padding留给后面的data collator。from transformers import AutoTokenizer tokenizer AutoTokenizer.from_pretrained(bert-base-uncased) def tokenize_func(examples): return tokenizer(examples[text], truncationTrue, max_length512) tokenized_datasets raw_datasets.map(tokenize_func, batchedTrue)map函数默认会对整个数据集执行而且会缓存到磁盘第二次运行就能直接复用。用batchedTrue可以显著加速一条条处理太慢。处理完之后train和test每条样本都会多出input_ids、token_type_ids和attention_mask这三列后面做模型输入就靠它们。2.3 DataCollator的作用Padding很讲究如果在这里一股脑把整条样本都padding到512训练内存几乎会翻倍尤其对IMDB这种长评论场景非常不划算。正确写法是用DataCollator在组成batch时动态把当前batch内最长的样本填充到一致长度。from transformers import DataCollatorWithPadding data_collator DataCollatorWithPadding(tokenizertokenizer)这个collator会根据当前batch的长度分布决定最终pad到哪儿短样本不会为长样本买单。我实测过同样的batch size下用动态padding比固定512长度的内存占用有明显的下降整体训练速度也要快不少。如果你的任务是句子对分类需要keep的字段会多一些但核心思路一样能动态就别预设。3. 核心训练参数与Trainer搭建数据准备好了接下来就是Trainer的重头戏。很多人一上来就复制网上的TrainingArguments参数但光一个save_strategy就有好几种值用错会让你辛辛苦苦跑的模型到最后选不到最好的score。这一节我会把关键参数讲透。3.1 TrainingArguments参数解读TrainingArguments是Trainer的灵魂它控制训练轮数、学习率、batch size、保存策略、日志间隔、是否加载最优模型等一大堆选项。下面给一个我自己常用、适合在单卡或双卡上微调BERT的参数清单from transformers import TrainingArguments args TrainingArguments( output_dir./bert-imdb-checkpoints, evaluation_strategysteps, eval_steps500, save_strategysteps, save_steps500, logging_steps100, num_train_epochs3, per_device_train_batch_size16, per_device_eval_batch_size32, learning_rate2e-5, weight_decay0.01, warmup_ratio0.1, load_best_model_at_endTrue, metric_for_best_modeleval_accuracy, greater_is_betterTrue, fp16True, dataloader_num_workers4, report_tonone, )逐项拆开说几个容易忽略的evaluation_strategy和save_strategy建议都用steps然后用eval_steps和save_steps指定间隔。训练过程中持续记录eval指标将来画曲线也方便。如果你把两个strategy设成不同步的会出现“模型保存了但eval指标却没更新”的迷惑局面。load_best_model_at_end: 这个参数要跟metric_for_best_model配合使用。训练结束时它会基于指定的指标从checkpoint里把得分最高的那个模型重新加载回来用于后面的推理。fp16True: 在支持半精度的GPU上非常好用显存占用直接减半速度也会有提升。Ampere架构之后的卡基本都能开如果数据敏感或出现loss抖动再考虑关掉。report_tonone: 很多人忽略这一项。不设置的话Trainer默认会尝试连接tensorboard或wandb如果本地没有对应环境会在训练前打印一堆警告甚至报错。这里有个计算warmup的小技巧。我上面用了warmup_ratio0.1它表示训练总步数的前10%做学习率线性爬坡这对BERT类模型来说是一套很稳妥的默认值。如果你更习惯精确控制也可以用warmup_steps直接指定比如训练共1000步就设100。两者别同时设以warmup_steps优先。3.2 评估指标与compute_metricsTrainer默认不会自己评判模型好坏需要手动传入一个compute_metrics函数。这个函数接收一个EvalPrediction对象里面有predictions和label_ids返回一个指标字典。import numpy as np from evaluate import load accuracy_metric load(accuracy) f1_metric load(f1) def compute_metrics(eval_pred): predictions, labels eval_pred preds np.argmax(predictions, axis-1) accuracy accuracy_metric.compute(predictionspreds, referenceslabels)[accuracy] f1 f1_metric.compute(predictionspreds, referenceslabels, averagebinary)[f1] return {accuracy: accuracy, f1: f1}如果想偷懒完全可以把accuracy和f1的加载放在函数外面这样每次eval只会执行计算而不会重复加载指标。Trainer在预测时会输出原始logits所以必须用np.argmax先转成预测类别再和labels比对。3.3 实例化Trainer并开始训练实例化Trainer之前需要先加载模型。注意这里要用任务对应的带分类头的模型类不能直接加载BertModel否则你得不到一个可以直接做分类输出的模型。对于二分类任务from transformers import AutoModelForSequenceClassification model AutoModelForSequenceClassification.from_pretrained( bert-base-uncased, num_labels2, )from_pretrained第一次运行的时候会下载模型权重大概400多MB下载完之后会缓存到本地下次加载就不用再拉了。接下来把前面准备的东西一次性塞进Trainerfrom transformers import Trainer trainer Trainer( modelmodel, argsargs, train_datasettokenized_datasets[train], eval_datasettokenized_datasets[test], data_collatordata_collator, tokenizertokenizer, compute_metricscompute_metrics, )当你执行trainer.train()之后训练就正式开始了。我建议第一次跑的时候把训练集稍微切小一点比如只用2000条目的是先把流程跑通再上全量数据。全量IMDB在单张消费级GPU上大约要十几分钟到半小时如果是从没跑过的代码一上来就全量很容易把时间浪费在调试日志上。先把速度拉起来、确认loss在下降再谈规模。实际训练过程中你会看到Trainer打印类似这样的日志{loss: 0.412, learning_rate: 1.6e-05, epoch: 0.8}训练结束时如果load_best_model_at_endTrue它会提示已经加载了最优checkpoint这时trainer.model就是整个训练过程中表现最好的那一版。4. 训练收尾指标、模型保存与推理模型训练完了后面这几步很多人会忽略导致模型白跑。比如评估要把结果落盘、保存模型要把tokenizer一起存、推理时要搞清楚Trainer的predict到底返回什么。下面一次说清楚。4.1 evaluate与predict用Trainer做评估很简单eval_result trainer.evaluate() print(eval_result) # {eval_loss: 0.221, eval_accuracy: 0.912, eval_f1: 0.912}它的输出是一个字典key名称由你传入的compute_metrics里返回的键决定。比如这里我们返回了accuracy和f1前面的eval_是Trainer自动加上的前缀方便后续和metric_for_best_model对准。trainer.predict(test_dataset)同样可以用来产出预测结果返回的对象里有三个属性predictions是logits矩阵label_ids是真实labelmetrics是测试集指标。如果我们只是要一张提交表或者做线下分析直接从predictions里argmax即可。这里有个实际用过的细节如果你在训练时没有传入eval数据集evaluate()会直接报错因为它根本不知道要评估谁。遇到这种情况就在TrainingArguments里把evaluation_strategy设成no然后手动指定eval_dataset来调predict()。4.2 模型保存与重新加载Trainer训练结束后会自动在output_dir里保存checkpoint但最后一个checkpoint不一定是你想要的那版。如果开了load_best_model_at_endTrue推荐用下面这套姿势来保存trainer.save_model(./bert-imdb-final) tokenizer.save_pretrained(./bert-imdb-final)第一行会把模型结构和权重一起存下来第二行把tokenizer的词典和配置一起存下来。为什么tokenizer也要存因为推理时重新加载数据tokenizer如果版本或词表不一致输入token都会被编码错结果自然对不上。我见过有人在生产环境只存模型不存tokenizer下游一换环境全乱套的例子。之后无论何时要重新做推理只需要from transformers import AutoTokenizer, AutoModelForSequenceClassification model AutoModelForSequenceClassification.from_pretrained(./bert-imdb-final) tokenizer AutoTokenizer.from_pretrained(./bert-imdb-final)加载回来之后model.eval()和torch.no_grad()别忘了否则模型参数还处于training状态推理行为会有差异。4.3 训练过程日志怎么看训练过程中那一串loss和learning_rate的日志不是摆设。我一般重点关注三点loss下降趋势前几十个step如果loss不降反升先检查学习率和warmup配置大多数时候是学习率太大。eval指标与loss是否同步如果loss下降但accuracy不涨大概率是过拟合信号或者标签噪声太大。learning_rate的曲线Trainer的scheduler默认是linear decay加warmup日志里如果能确认learning_rate从极小的初始值爬升再下滑说明调度正常。另外一个很多新手不知道的地方如果你设置了save_steps500训练到第500、1000步时会自动创建checkpoint文件夹。这些文件夹里的内容就是完整可用的模型你完全可以在训练中断时直接把路径传给Trainer的resume_from_checkpointTrue来续训练。实际我做过一次实验断电后恢复训练loss曲线能很好地接上几乎零损失。5. 踩坑记录与排查思路写到这里训练流程基本闭环了。但任何框架在真实环境里都会有几个高频坑这一节我用FAQ的形式把遇到过的和同事遇到过的问题列出来每个都附排查思路省得你再去搜索引擎里翻。5.1 显存不足怎么办最常见的就是CUDA out of memory。BERT base的模型本身不大但序列长、batch一加大就容易爆。排查顺序建议如下先把per_device_train_batch_size降到8、4确认能跑通再往上加打开fp16True显存几乎能砍半用gradient_accumulation_steps保持“等效batch size”不变比如原来batch size 16现在batch size 4 accumulation 4等效训练效果接近但峰值显存大幅下降检查是不是被固定padding坑了用了DataCollatorWithPadding之后短样本的batch实际tensor会小很多这也是为什么我在第2节反复强调动态padding。假如是序列本身太长比如文本平均长度超过400那还得考虑max_length截断策略。直接截断尾部对情感分析这类任务影响通常不大但如果是阅读理解可能需要更精细的stride策略。5.2 过拟合与精度异常微调BERT在小数据集上特别容易过拟合。我有一阵用几千条数据做意图分类训练loss降到0.1以下验证loss却越走越高然后精度在0.8附近震荡。那一次的经历让我把几个技巧刻进DNA里增大weight_decay从0.01往0.05试减少训练轮数BERT微调往往3轮以内就够传统“训20轮”的思路不要套过来在TrainingArguments里使用EarlyStoppingCallback这是我最喜欢的功能之一from transformers import EarlyStoppingCallback, IntervalStrategy args TrainingArguments( output_dir./bert-imdb-checkpoints, evaluation_strategysteps, eval_steps300, save_strategysteps, save_steps300, num_train_epochs5, load_best_model_at_endTrue, metric_for_best_modeleval_accuracy, greater_is_betterTrue, ) trainer Trainer( ..., callbacks[EarlyStoppingCallback(early_stopping_patience2)], )early_stopping_patience2表示连续2个eval_steps间隔评估指标都没有改善时就会提前终止训练。用这个回调还有个好处不用为了“碰运气多训几轮”而浪费算力。另外如果你的任务类别极度不均衡accuracy会变得“虚高”光看accuracy根本判断不了好坏。这种情况建议用F1、AUC之类的指标或者在compute_metrics里同时输出混淆矩阵相关的统计值。5.3 环境与下载问题Run时报错里多数人会碰到两类比较典型的加载模型时连接超时上面已经提过用HF_ENDPOINThttps://hf-mirror.com。module transformers has no attribute Trainer这通常是transformers版本太老。升级到新版本即可pip install -U transformers。还有一小部分情况是环境里同时存在旧版安装路径建议重新建conda环境而不是原地覆盖。有些朋友喜欢把checkpoint直接传到网盘再从网盘下载到别的机器加载。但跨机器加载时如果两边的transformers版本不一样偶而会出现“weights key mismatch”的告警。正式部署前最好统一依赖版本或者至少保证from_pretrained时torch_dtype、device_map等参数符合目标环境。还有一个很容易被忽略的怪问题训练正常但eval时卡住不动。我排查过几次最后发现是dataloader_num_workers设得过高机器内存不够数据加载线程一直排队。降到0或2就能恢复。这个参数不是越高越好数据小或单机环境用默认值更稳。如果后续要扩展到更大模型比如把BERT换成RoBERTa、DeBERTa甚至做Llama这类生成模型的SFTTrainer这套流程依然是通用的。只想微调部分参数、节省显存的话可以在模型外再套一层PeftModelLoRATrainer同样能配合使用。我记得在HuggingFace的PEFT生态里一个peft_model get_peft_model(model, lora_config)就能把模型包装好剩下的Trainer调用完全不变。这一点也很适合在做完普通全参微调后进一步探索低资源微调方案。我个人现在的工作习惯是凡是标准分类/回归/抽取类任务一律用Trainer起步只有在对训练流程有定制化需求、或者需要逐层控制梯度时才会手写训练循环。用Trainer并不是因为它“高级”而是因为它把一个可复现、可维护的训练流程标准化了。团队协作里新人拿到这样一个代码结构一眼就能看出训练参数、数据、指标在哪省掉的沟通成本远超那点封装带来的“黑盒感”。最后再分享一个小技巧微调之前先用原始BERT在自己任务的小样本上跑一次甚至不微调直接拿[CLS]特征做逻辑回归得到一个“下限分数”。有了这个baseline你微调后如果提升不大至少能判断是不是任务本身太难而不是代码写得不对。这个习惯帮我避免了很多次“明明在跑代码其实在浪费时间”的尴尬。