企业官网建设流程全解析

1. 我为什么要在Kaggle社区做LLM分类微调

最近大半年，我一直在Kaggle社区里折腾大语言模型（LLM）的分类任务微调。从最初的比赛跟榜、复现别人的方案，到自己动手跑通一套完整的分类微调流程，踩过的坑不说上百个也有几十个。今天这篇就是想把这套经验整理出来，给那些准备入坑LLM微调、或者正在Kaggle上打分类赛的朋友一个可以直接参考的路径。

先说说这个方向到底是干什么的。LLM Classification Finetuning，翻译过来就是用大语言模型做文本分类任务，并且通过微调让模型在特定领域、特定数据集上表现更好。实践中常见的场景包括：情感分类、意图识别、垃圾内容检测、新闻主题分类、客服工单自动打标等。Kaggle社区里这类比赛非常多，有的是纯文本二分类，有的是多标签分类，有的还带着时序信息。

有人可能会问：现在LLM这么强，直接调用商用接口，或者用现成的提示词模板不就行了，为什么还要自己微调？这个问题我一开始也在想，后来在几个实际项目里彻底想明白了。商用接口虽然方便，但每千条文本的成本不低，尤其你如果是做批量数据处理，几百万条文本跑下来，账单会让你怀疑人生。更重要的是，很多垂直领域的数据，商用模型并没有针对性地优化过，直接推理的分类效果往往也就七八十个点的准确率，根本达不到业务落地标准。

微调这个路径，本质上是让模型在“通用能力”的基础上，再学一层“领域知识”。通用模型像一个读过万卷书的通才，他能听懂你说什么，但未必知道你们行业里“客户报障”和“客户投诉”之间的微妙差别。微调就是让这个通才进入你的行业，读你给的资料，学会你的语言习惯和分类规则。这比从零训练一个模型省太多资源，也比纯粹的提示词工程在效果上更稳、更可控。

这也就是Kaggle社区里LLM分类微调如此火热的原因：比赛提供标准数据集和评估指标，社区里有大量可复现的公开方案，新手可以通过复现别人的工作快速上手，老手则可以在baseline上不断优化，拼精度也拼推理效率。这篇文章会从整体思路、数据准备、模型选型、实操脚本、问题排查五个维度，把整个流程完整拆开来讲。

2. 方案设计：为什么微调优于传统方法和零样本推理

2.1 传统分类模型与LLM微调的边界在哪里

传统文本分类最常用的路线是TF-IDF或Word2Vec做特征，再接一个LightGBM或逻辑回归；进阶一点，用TextCNN、BiLSTM，再到预训练模型BERT做序列分类。这些方案并不是不能用，在一些数据量小、标签清晰的场景下，它们甚至比LLM更快更省。

但它的天花板也很明显。第一是特征表达能力的限制，传统方法很难处理长距离依赖和复杂的语义关系；比如“这家餐厅的菜洗得真干净”这种带有反讽意味的句子，TF-IDF基本无能为力。第二是迁移能力差，换一个领域，特征工程和模型都要重新设计。第三是鲁棒性不足，遇到拼写错误、口语化表达、网络新词，传统模型的性能会掉得很快。

LLM微调方案走的是另一条路线：模型本身就具备了很强的语言理解能力，微调只是把它的输出头或者参数做局部调整，让它更适配具体任务。以目前主流的开源LLM为例，它们在大量通用语料上做过预训练，对语言规律、常识知识、逻辑关系都有一定程度的掌握。微调之后，模型学到的是“这个特定数据集的分类边界”，而不是从零开始理解语言。

所以我的判断是：如果你手头只有几千条标注数据、对延迟和资源成本敏感、任务本身也比较简单，用BERT级别的模型微调就够了；但如果你是处理长文本、多标签、语义复杂的任务，同时希望有更好的泛化能力，那就得直接上更大型的LLM做微调。

2.2 零样本推理看起来很香，但生产环境里不推荐

很多人觉得，既然ChatGPT这类模型啥都能干，那我直接把文本拼到提示词里，问“这个句子属于哪个类别”，不就行了吗？零样本（zero-shot）推理确实方便，连训练都省了。但你没有大规模试过，就不会意识到这里面有多少坑。

第一是输出不稳定。同样一句话，你今天问和明天问，给出的分类结果可能不一样，这在需要稳定标签的生产系统里是致命的。第二是格式化输出困难。你需要它返回一个JSON，它可能给你一段散文；你需要它只输出类别编号，它偏要加上一句解释。第三是长文本处理成本高。很多分类任务的文本长度在几百字到上千字，零样本推理要完整把文本塞进提示词里，Token数上去了，费用也跟着上去。

我实际测试过一次：用零样本方式对一组中文评论进行情感分类（正向/负向/中性），准确率大概在82%左右，看起来还行。但同一批数据，我用一个7B级别的模型微调了三个epoch之后，准确率直接到了94%。这12个百分点的差距，在业务上就是天壤之别。更关键的是，微调后的模型推理非常快，也不依赖外部接口，可以在本地或内网环境下部署。

所以我的结论是：零样本推理适合快速验证想法、做小批量预标注、或者搭一个demo给业务方看效果；但如果你要跑比赛、要上线服务、要稳定输出，微调是必由之路。

2.3 微调方案的整体架构

这里我画一下我常用微调方案的逻辑结构，方便大家对后面几个章节有整体认识。

整个流程可以拆成四层。第一层是数据处理层，负责把原始文本清洗、截断、编码成模型需要的输入格式，同时划分训练集和验证集。第二层是模型层，包括基础模型选择、分类头的构建、以及是否引入LoRA等参数高效微调技术。第三层是训练层，涉及学习率策略、损失函数、批大小等训练超参的设置。第四层是推理与评估层，负责加载训练好的模型、跑推理、生成提交结果或者评估指标。

每一层都有不少细节。比如数据处理层，很多人觉得直接把文本丢给模型不就行了，但其实文本长度分布、标签分布、数据泄漏这些坑都在这一层。模型层里，选什么基础模型、用全参微调还是LoRA，也直接影响你能买得起几个GPU。训练层的学习率设置稍有不慎，模型要么收敛太慢，要么直接训飞。评估层也一样，用准确率还是F1，是单次评估还是K折交叉验证，不同选择会对你的final score产生很大影响。

后面几个章节我会按这个四层结构展开，每一步都给出可以直接落地的配置和代码参考。

3. 数据准备：文本分类微调的第一步也是最重要的一步

3.1 原始数据清洗的几条铁律

数据清洗这事儿，看起来简单，真正做起来才是最磨人的。我在Kaggle比赛里见过不少队伍，模型结构非常先进，结果因为数据里有几万条空文本和重复样本，最后得分还没有一个简单模型高。所以这块儿我建议大家一定要重视。

第一，去重。这里的去重不只是完全相同的文本去重，而是要做模糊去重。比如两句话只有一个标点符号不同，内容完全一样，这种在大型数据集里非常常见。我在项目中一般用MinHash算法做近似去重，速度快、效果好，十几万条数据几分钟就能跑完。

第二，处理空值和超短文本。空值直接删除或者填充一个特殊标记，这个看数据量而定。超短文本（比如只有一个字、一个符号）如果数量不大，建议直接过滤掉；如果数量不小，那就单独作为一个类别来处理，不要强行让它和其他正常样本混在一起。

第三，标签一致性检查。有时候数据是多个标注员标注的，同一个内容可能被标成两个不同的类别。这种标签噪声会直接干扰模型学习。我的处理方式是：如果是二分类且分歧较大，直接删除这些样本；如果是多分类，则保留置信度更高的一次标注，或者用投票机制处理。

第四，文本截断策略。现在的LLM大多有最大输入长度限制，比如512个Token或者2048个Token。如果原始文本超长，直接暴力截断会损失关键信息。我常用的做法是根据数据集的长度分布，选取一个能覆盖95%样本的长度阈值，然后用“头部+尾部”拼接的方式截断：即保留前128个Token和后256个Token，中间用分隔符连接。这种方式在很多长文本分类任务上比单纯的头部截断高2到3个点。

3.2 验证集怎么划分才不会吃亏

验证集划分看起来是小事，但做不好会直接让你的竞赛名次雪崩。最常见的问题就是随机划分，把同一用户、同一来源的文本切到了训练集和验证集里，结果验证集分数虚高，线上评分却直接掉好几个点。

正确做法是先看看你的数据有没有分组结构。比如文本来自不同的用户、不同的文章、不同的时间段，这些都可能成为信息泄漏的来源。我在实际项目中会优先使用GroupKFold而不是普通的StratifiedKFold，以保证同一个组的样本不会同时出现在训练集和验证集里。

另外，对于类别不均衡的数据集，验证集划分也必须做分层抽样，保证每个类别在训练集和验证集中的比例大致一致。否则如果你的A类样本在验证集中占比过高，模型在这个验证集上的分数会很有误导性。

我在Kaggle比赛里经常看到有人只用SingleFold就提交，我觉得这实在过于激进。一般稳妥做法是至少做5折交叉验证，取平均分作为模型调优的参考线。虽然训练时间会变成五倍，但换来的是你对模型稳定性的信心。比赛阶段，如果你的训练时间可控，强烈建议上5折。

3.3 类别不均衡：别让你的模型变成“复读机”

分类任务里类别不均衡是常态。比如欺诈检测中，正常样本占99%，欺诈样本占1%。如果直接拿原始分布去训练，模型很容易学成“永远预测多数类”，这样也能有不错的准确率，但召回率惨不忍睹。

处理不均衡有几个常用办法。第一是重采样，对少数类做上采样，对多数类做下采样。但上采样不是简单复制文本，这样容易过拟合，我一般用人工构造同义改写的方式来扩充少数类。第二是损失函数调整，比如在CrossEntropyLoss里给少数类加权重，让模型把更多注意力放在少数类上。第三是对预测阈值做调整，训练完之后，在验证集上搜索一个概率阈值，使得F1分数最大化。

我个人的经验是：如果最大类占比超过90%，那一定要做处理；如果只是60%对40%这种程度的不均衡，其实不用太折腾，用分层K折和合适的评估指标就够了。

3.4 你应该知道的“数据泄漏”隐患

数据泄漏是Kaggle比赛中最常见的翻车原因之一。它是说，你在训练阶段有意无意地接触到了本不该见到的测试集信息，于是验证集分数很好，真正预测时却崩盘。

举一个很典型的例子：某个文本分类比赛，文本里包含用户ID，而用户ID和标签之间有很强的相关性。如果你的模型“记住”了用户ID到标签的映射，那么在测试集上，只要出现没见过的用户ID，模型就会瞬间不知所措。所以清洗数据时，需要把这类具有“身份标识”性质的特征单独剥离，或者脱敏处理后再进入模型。

另外还有一种隐蔽的泄漏，是当你用了外部数据集做预训练或数据增强时，外部数据里可能已经包含了一部分测试集的内容。这种情况很难完全避免，我的建议是：使用外部数据前，先做一次文本相似度筛查，把与测试集样本高度相似的文本剔除。

4. 模型选型与微调策略：从BERT到7B级LLM的实战对比

4.1 如何选择适合你任务的基础模型

选模型这事儿没有标准答案，但我可以分享一套判断框架。

首先要看你的文本语言。如果你处理的是英文，那选择面很宽：DeBERTa-v3、RoBERTa-large、Mistral-7B、Llama-3-8B都是社区验证过的靠谱选择。如果处理的是中文，那就要优先考虑中文预训练模型，比如BERT-wwm-ext、RoBERTa-wwm-ext-large、Chinese-Alpaca系列，以及各类中文指令微调模型。

其次要看文本长度。如果平均长度只有几十个Token，那用BERT级别的模型就够了，速度快、显存占用小。如果文本长度在512 Token以上，那么你需要支持长文本的模型，比如Longformer、BigBird，或者直接用支持8K上下文窗口的LLM。

最后要看你的算力资源。这部分我放在4.3节详细说，这里先提醒一句：不要看到榜单上别人用7B模型就盲目跟进，如果自己的GPU显存只有16G，还是应该先从小模型入手，把整个流程跑通，再考虑扩大规模。

我用一个表格来总结不同模型规模的特点，方便大家按需选择：

4.2 全参微调 vs LoRA：显存与效果之间如何取舍

在LLM分类微调下，训练方式大致分为两种：全参数微调（Full Fine-tuning）和参数高效微调（PEFT，如LoRA）。

全参微调效果好，因为它可以调整模型所有层级的参数，让模型充分适应目标任务。但它对显存的压力非常大。一个7B模型，即使bf16精度下，单是模型权重就需要14G显存；再加上优化器状态、梯度、激活值，实际训练一个batch就得40G起步。没有多张高端显卡，基本上跑不动。

LoRA的思路是在模型旁边加一路低秩分解的旁路参数，训练时只更新这些旁路参数，原始权重全部冻结。这样一来，可训练参数量往往只有原始模型的1%到2%，显存占用大幅下降。比如我的实际测试中，对Mistral-7B做LoRA微调，16G显存就可以跑起来，效果比全参微调只差1到2个百分点。

所以在目前Kaggle社区的环境下，LoRA已经成为LLM分类微调的事实标准。大家常用的库是PEFT和Hugging Face的Transformers，二者配合使用非常顺滑。下面我会给一个可以直接跑的LoRA微调脚本，这部分重点讲配置，代码作为参考。

4.3 Kaggle环境下的GPU策略与分布式训练

Kaggle Notebook每周提供30小时GPU额度，但可选的是T4 x2或P100，偶尔会有TPU。T4只有16G显存，说实话，单卡跑7B模型经LoRA都很勉强，建议优先选择双卡T4变体，用数据并行方式训练。

我在Kaggle比赛里的一个典型做法是：先在一张T4上跑通一到两个epoch，验证代码没有问题、loss在下降；然后切到双卡配置，用分布式数据并行做全量训练。这样做的好处是，能在30小时额度内尽量多跑几轮实验。

如果你的文本数据非常大，Kaggle的磁盘IO会成为瓶颈。建议提前把预处理好的数据保存成Hugging Face的Dataset格式（arrow文件），这样加载速度快很多，不用每次启动都重新做一遍清洗和编码。

4.4 一个可以直接跑的LoRA微调分类脚本

下面这个脚本是我在多个Kaggle分类比赛里用过的精简版，基于Transformers和PEFT库，模型层面用的是Mistral-7B，你也可以把模型名换成其他合适的LLM。

import torch from datasets import load_dataset from transformers import ( AutoTokenizer, AutoModelForSequenceClassification, TrainingArguments, Trainer, DataCollatorWithPadding, ) from peft import LoraConfig, get_peft_model, TaskType # 1. 加载数据（这里假设你已经把csv处理成了hf dataset格式） dataset = load_dataset("csv", data_files={"train": "train.csv", "val": "val.csv"}) label_list = dataset["train"].unique("label") id2label = {i: label for i, label in enumerate(label_list)} label2id = {label: i for i, label in enumerate(label_list)} # 2. 加载tokenizer和模型 model_name = "mistralai/Mistral-7B-v0.1" tokenizer = AutoTokenizer.from_pretrained(model_name) tokenizer.pad_token = tokenizer.eos_token # 很多LLM没有pad token，需要手动设置 model = AutoModelForSequenceClassification.from_pretrained( model_name, num_labels=len(label_list), id2label=id2label, label2id=label2id, torch_dtype=torch.bfloat16, device_map="auto", ) # 3. LoRA配置 lora_config = LoraConfig( task_type=TaskType.SEQ_CLS, r=16, lora_alpha=32, lora_dropout=0.05, target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], ) model = get_peft_model(model, lora_config) model.print_trainable_parameters() # 输出：trainable params: 8,388,608 || all params: 3,543,447,552 || trainable%: 0.2367 # 4. tokenize处理 def tokenize_function(examples): return tokenizer(examples["text"], truncation=True, max_length=512) tokenized_dataset = dataset.map(tokenize_function, batched=True) # 5. 训练参数 training_args = TrainingArguments( output_dir="./checkpoints", evaluation_strategy="epoch", save_strategy="epoch", learning_rate=2e-4, per_device_train_batch_size=4, per_device_eval_batch_size=8, num_train_epochs=3, weight_decay=0.01, logging_steps=50, fp16=False, bf16=True, gradient_accumulation_steps=8, load_best_model_at_end=True, metric_for_best_model="eval_loss", report_to="none", ) # 6. Trainer trainer = Trainer( model=model, args=training_args, train_dataset=tokenized_dataset["train"], eval_dataset=tokenized_dataset["val"], tokenizer=tokenizer, ) # 7. 开始训练 trainer.train() # 8. 保存模型 model.save_pretrained("./lora-classifier-final") tokenizer.save_pretrained("./lora-classifier-final")

这段代码有几个地方值得展开讲。

第一是tokenizer.pad_token = tokenizer.eos_token，这一步非常关键。很多LLM的tokenizer默认没有pad_token，而分类任务需要同一个batch内的样本长度一致，必须补齐padding。如果不设置pad_token，Trainer会在运行时报错，或者用了错误的padding标记影响训练效果。

第二是device_map="auto"。这个配置让Transformers自动把模型权重分配到可用的GPU或CPU上。在Kaggle双卡环境下，它会自动把一部分层放在GPU0，另一部分放在GPU1，减少单卡显存压力。

第三是LoRA的target_modules。不同模型的模块命名不同，Mistral用的是q_proj、k_proj、v_proj、o_proj，Llama系列也是类似；但如果是BERT、RoBERTa这类模型，模块名是query、key、value。如果你不确认模块名，可以先打印模型结构，或者用peft库里的get_peft_model自动扫描。目标模块选多少，直接决定可训练参数量和效果：选多了显存压力大，选少了效果可能不够。

4.5 超参数调优：学习率、批大小和Epoch的博弈

LLM微调的超参设置和我们熟悉的CNN训练有差异，我一个个说。

学习率是整个训练过程中最敏感的参数。LLM微调里，LoRA部分的学习率一般建议在1e-4到5e-4之间，比全参微调的1e-5到3e-5要高不少。原因在于LoRA只更新旁路参数，优化空间相对受限，需要用更大一点的学习率来加速收敛。但学习率太大会导致模型在验证集上震荡，甚至直接训飞（loss变成NaN）。我的经验是：先用2e-4跑一个epoch看看loss曲线，如果loss波动剧烈就降一半；如果loss下降太慢，可以试着翻倍。

Batch size方面，大batch_size训练更稳定，但受限于显存，LLM的batch_size通常不会太大。我的做法是用gradient_accumulation_steps来模拟大batch，比如每设备batch_size=4，梯度累计8步，等效batch_size就是32。这样既保证了训练的稳定性，又不至于显存溢出。

Epoch数量上，如果是单任务分类、数据量不大（几万条），2到3个epoch就足够了。LLM的拟合能力极强，再多几个epoch很容易过拟合，验证集分数不升反降。如果你发现训练loss还在下降但验证集loss已经回升，那基本就是过拟合了，可以提前终止。

5. 完整实操：从Kaggle数据到提交文件的端到端流程

5.1 搭建Kaggle Notebook环境

Kaggle Notebook是个很香的环境，预装了大多数常用库，GPU也是免费额度，但它有个特点：内核不是持久化的，每过一段时间会自动断开。所以我每次开始实验前都会做三件事：

第一，设置环境变量，确保每次跑出来的随机种子一致，方便实验对比。我的做法是在代码最顶部加上os.environ["PL_TORCH_DISTRIBUTED_BACKEND"] = "gloo"和PYTHONHASHSEED=42，然后在Python里固定random.seed(42)、np.random.seed(42)、torch.manual_seed(42)。

第二，把数据集保存为Hugging Face Dataset格式，放在/kaggle/working/目录下，因为这个目录在会话期间是可写的（其他目录如/kaggle/input/是只读的）。

第三，启用加速器。在Notebook编辑界面右上角点击“Settings”，在Accelerator里选择GPU T4 x2，然后保存，重启内核。这样才能跑双卡训练。

5.2 数据预处理全流程参考

这里假设我们的任务是一个三分类的中文文本情感分类，数据量30万条，文本平均长度200字。我通常会把预处理流程封装成一个Python脚本，方便反复调用。

第一步，读取原始CSV，只保留我们需要的列：文本列和标签列。第二步，清理文本：去掉HTML标签、URL、多余空格，统一全半角符号。第三步，长度统计：画出文本长度的分布图，决定max_length。第四步，去除异常值：文本为空、标签为空、标签不在预设范围内的样本全部过滤。第五步，分层抽样划分训练集和验证集，比例9比1。第六步，样本量调整：如果训练集超过20万条，我会先随机采样一部分来做基线实验，等模型结构确定后再用全量数据训练，节省时间和资源。

Sampling这一条非常实用。我见过太多人拿着40万条数据直接开工，每跑一次实验要一两个小时，一天顶多跑十个实验。而如果你先用5万条数据快速验证模型结构、学习率和batch size，一天能跑三五十个实验，效率完全不一样。等所有超参都确定了，再上全量数据做最终训练，这样反而更快。

5.3 推理与生成提交文件的正确姿势

训练完模型后，下一步是推理。这里有个容易被忽略的点：你在训练时设置的max_length、pad_token等，在推理时也必须保持一致，否则会出现性能下降。

我的推理脚本逻辑大致如下：

from transformers import AutoTokenizer, AutoModelForSequenceClassification import torch import numpy as np import pandas as pd model_path = "./lora-classifier-final" tokenizer = AutoTokenizer.from_pretrained(model_path) model = AutoModelForSequenceClassification.from_pretrained( model_path, torch_dtype=torch.bfloat16, device_map="auto", ) test_data = pd.read_csv("/kaggle/input/test.csv") predictions = [] batch_size = 32 for i in range(0, len(test_data), batch_size): batch_texts = test_data["text"].iloc[i:i+batch_size].tolist() inputs = tokenizer( batch_texts, return_tensors="pt", padding=True, truncation=True, max_length=512, ).to("cuda") with torch.no_grad(): outputs = model(**inputs) probs = torch.softmax(outputs.logits, dim=-1).cpu().numpy() predictions.append(probs) pred_probs = np.concatenate(predictions, axis=0) pred_labels = np.argmax(pred_probs, axis=-1) submission = pd.DataFrame({ "id": test_data["id"], "pred_label": pred_labels, }) submission.to_csv("submission.csv", index=False)

这个脚本里值得注意的一点是：我输出的是概率值预测，后面的比赛指标如果要求Log Loss，你可以直接提交概率矩阵；如果要求Accuracy，就提交预测标签。所以先把预测概率存下来，永远不要只保存argmax后的标签，因为做阈值调整时你会后悔。

另外，Kaggle比赛为了防止作弊，通常会对提交文件和提交频率有严格限制。提交前一定要先跑通一次虚拟提交，确保CSV格式、列名和字段数量都没问题。

5.4 K折交叉验证：如何把单模型效果压榨到极致

单折训练虽然快，但它的分数波动比较大。你可能这个折跑了85%，下一折变成82%，完全不知道模型真实水平。稳健的做法是K折交叉融合，我用的是5折。

具体流程是这样的：把训练数据划分成5份，每次用4份训练、1份验证，重复5次，得到5个模型。在推理阶段，把测试数据分别喂给这5个模型，得到5组预测概率，取平均值作为最终预测。这个过程能明显降低方差，通常能比单模型提高1到2个点。

但K折的代价是训练时间乘以5。如果你的训练时长已经很大，也可以考虑用早停策略：每一折只跑2到3个epoch，或者把5折改成3折。我用这个策略在多个竞赛中稳定提升排名，强烈推荐大家试试。

5.5 TTA（测试时增强）到底要不要用

测试时增强（TTA）的思路是对测试样本做轻微扰动（比如同义词替换、随机删除某个词），然后多次预测取平均，以此提升鲁棒性。对于图像分类任务，TTA是家常便饭；但对于文本分类，LLM微调模型对输入扰动比较敏感，TTA的效果因数据集而异。

我自己测试过一次：在一组法律文本分类任务上做同义词替换的TTA，结果准确率反而下降了0.8%。原因可能是替换后的文本改变了原有语义，导致模型预测偏差。所以我的建议是：TTA可以作为备选项在验证集上测试，如果验证集分数没有提升，果断去掉，不要为了“看起来高级”而牺牲效率。

6. 常见问题：我在微调过程中踩过的那些坑

6.1 训练loss不降反升怎么办

遇到这种情况，先不要慌，按顺序排查。

第一步看学习率。如果学习率过大，loss曲线会在高位震荡，甚至出现NaN。降到1e-4或5e-5再试。

第二步看数据预处理。确认label是否都从0开始连续编号，有没有出现索引越界问题。很多框架的CE Loss要求标签范围在0到num_labels-1之间，如果标签从1开始，loss会直接错。

第三步看是否混入了脏数据。比如文本里有大量空字符串，模型学到的是空文本与某一类别的强关联，导致训练缓慢。这个在数据清洗环节就应该过滤掉。

第四步看梯度。如果用了bf16混合精度，某些老显卡不支持会导致数值不稳定，建议关闭混合精度或改用fp16。

6.2 训练时显存不够，程序崩溃

这个问题在Hugging Face Trainer中非常常见。显存不够时，优先做三件事：

第一，降低per_device_train_batch_size，从4降到2，如果还不行就降到1。第二，打开gradient_accumulation_steps，用累计梯度来模拟更大的batch，弥补batch_size下降带来的抖动。第三，检查是否有模型参数被设置为需要梯度。如果使用了LoRA，确认requires_grad只对LoRA参数为True，其他全部冻结。

如果以上都无效，还有一个终极办法：用bitsandbytes库做4bit量化加载模型，这样模型权重显存占用能降低75%左右。Kaggle环境里预装了bitsandbytes，可以直接用load_in_4bit=True加载模型。

from transformers import BitsAndBytesConfig bnb_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_use_double_quant=True, bnb_4bit_quant_type="nf4", bnb_4bit_compute_dtype=torch.bfloat16, ) model = AutoModelForSequenceClassification.from_pretrained( model_name, num_labels=len(label_list), quantization_config=bnb_config, device_map="auto", )

6.3 过拟合：验证集分数高得离谱，线上一塌糊涂

这是分类微调最让人崩溃的时刻。验证集分数很高，但提交到线上评分工具里，分数反而下跌。可能的原因有三个。

第一是数据泄漏。测试集与训练集之间存在重合，但验证集没有泄漏，所以验证集分数虚高，线上崩了。解决方法是做GroupKFold，并仔细检查是否存在时间戳、ID等泄漏源。

第二是验证集划分和线上分布不一致。如果你的验证集是从训练集里随机抽的，而线上测试集的时间和来源不同，那么分布偏移会导致验证集分数失真。这时你应该按时间排序划分，把靠后的时间段作为验证集。

第三是模型过拟合了验证集。如果你在同一个验证集上反复调参和早停，最终模型会“记住”验证集的样本分布，遇到测试集自然表现不佳。这种问题的解决办法是每隔几次调参就换一次验证集划分，或者用嵌套交叉验证。

6.4 Kaggle TPU能用来训练LLM吗

Kaggle提供TPU（一般是TPUv3-8），理论上也能训练Transformer模型，但实践中我真心不建议在TPU上做LLM分类微调。原因有两点：

第一，TPU和PyTorch生态的兼容性不如TensorFlow/JAX顺畅，Hugging Face的Trainer虽然支持TPU，但很多第三方库（比如PEFT）对TPU的支持不完善，经常报错。第二，TPU更适合大规模分布式矩阵运算，对小batch的分类任务优势不明显，反而多了一层调试成本。

如果你的项目只能在TPU上运行，建议用JAX/Flax版本的模型，但如果你能选GPU，尽量选GPU，省心太多。

6.5 推理太慢：如何加速线上分类速度

当你的模型训练完毕要上线时，推理速度就变得关键了。一个7B模型即使使用bf16推理，每秒大概只能处理几十条短文本，对于高并发场景是不够的。

加速手段按效果排序：第一，使用模型量化，将模型从bf16降到int8甚至int4，速度提升2到4倍，准确率损失一般在1到2个点以内。第二，使用vLLM或者TensorRT-LLM这类推理框架，它们支持continuous batching和PagedAttention，可以大幅提升吞吐量。第三，如果文本长度允许，可以设置max_length更小的截断值，减少attention计算量。

我在实际项目里，经常用一套“组合拳”：训练时用bf16，推理时转成int8，再用vLLM部署到内网。这样单卡就能扛住每秒几百条文本的分类请求，准确率只比原始模型低了不到1个百分点，但成本省了一大截。

7. 经验沉淀：从一个比赛到多个实战项目的总结

写到这里，LLM分类微调的主要流程和坑都已经讲得差不多了。最后再分享一点我自己在多个项目里的体会。

第一个体会是“不要为了上大模型而上大模型”。我见过太多人一上来就选13B甚至70B的模型，结果训练时间爆炸，效果还不一定比一个好调参的DeBERTa-large强。模型规模只是其中一个变量，数据的质量、标签的一致性和训练策略的稳定性，在分类任务里往往比模型本身的影响力还要大。

第二个体会是“能复现的方案才是好方案”。Kaggle社区里强大的公开方案很多，与其自己闷头造轮子，不如先把别人的高分方案完整复现一遍，理解每一步的输入输出，然后在此基础上做改进。这样做有一个好处：你手里会有一个可靠的baseline，之后任何改动都能用分数来量化验证，而不是靠感觉。

第三个体会是“把流程工具化”。我一开始做微调，所有步骤都在一个Notebook里手动跑，改一个参数就要从头开始训练，非常痛苦。后来我把数据预处理、训练、推理、提交拆成了四个脚本，每个脚本都可以独立运行，互不干扰。这样每次调参只需要改一个配置文件，跑完一个脚本再跑下一个，实验效率至少提升五倍。

第四个体会是关于时间管理的。Kaggle比赛的GPU额度是有限的，训练之前一定要先在少量数据上快速验证模型能收敛，再上全量数据。好的实验节奏应该是：一个小时跑通代码，三个小时用小数据跑出baseline，然后花大量的时间在调参和做交叉验证上，而不是反复全量训练然后等结果。

LLM分类微调这个方向，技术门槛确实存在，但并不是高不可攀。数据、模型、训练、推理，四个环节环环相扣，只要每一个环节都做到位，你完全可以在有限资源下做出满意的结果。这篇文章里的代码和配置，都是我实际跑过、验证过的，希望能帮大家少走一些弯路。如果你在实操中遇到了别的问题，也欢迎在评论区交流——踩坑不可怕，关键是踩完要长记性。