这套大模型训练营二期的第三次作业我前后做了三版从最开始“脚本能跑完、日志不报错”就交差到后来逼着自己把每个超参数为什么这么设、每一条评测分数为什么长这样都讲清楚中间踩的坑基本覆盖了单卡做指令微调会遇到的大多数问题。这篇就把我这一版作业的完整思路和实操过程摊开写一遍包括数据怎么处理、LoRA 参数怎么算、显存怎么估、评测怎么做、报错怎么查。如果你正在做大模型训练营二期第三次作业或者手头有一个 7B 级别的中文基座模型想做领域适配这篇可以直接当施工图看如果你只是想搞清楚“微调到底在调什么”前面两节也足够让你建立整体认知。需要先说明一点这篇不讨论“哪个模型最强”这种没有标准答案的问题只讨论在我手上的硬件条件下怎么用最稳的方式把一个基座模型调成能干活的样子并且能拿出可复现的证据证明它确实变好了。第三次作业的核心难点从来不在代码量而在判断力——你得能分辨“loss 降了”和“模型学会了”是两件完全不同的事。1. 第三次作业到底在考什么任务拆解与整体设计思路1.1 从“跑通脚本”到“讲清理由”作业设计的真实意图训练营前两次作业解决的是“环境能不能起来”“推理能不能出字”到了第三次重心明显发生了转移。作业要求里那些看起来零散的小任务——数据构造、参数配置、训练日志、评测对比、部署验证——拼在一起其实是一条完整的链路你得自己造一批带监督信号的数据让基座模型在这批数据上发生定向改变然后用可量化的方式证明这个改变是真的。这条链路上任何一环糊弄最后的结果都对不上。我见过最多的失败模式是数据随手凑了三百条配置照抄教程默认值训练跑完 loss 从 2.4 降到 0.9兴致勃勃去测发现模型说话的语气变了但能力没变甚至原来会做的题现在不会做了。这种情况不是训练失败是训练目标定义失败。你压根没有想清楚希望模型在哪一类输入上产生什么样的输出变化自然也谈不上验证。所以我在动手前做的第一件事是把作业拆成四个必须回答的问题模型现在缺什么能力、用什么数据补、用什么方式注入、用什么指标验收。这四个问题对应的就是后面四章的内容。把它们写在纸上贴在显示器边上比任何教程都管用因为中途你一定会想改数据、改参数这时候抬头看一眼能避免大量无效折腾。1.2 全参微调、LoRA、QLoRA三条路线怎么选路线选择这件事很多人是看别人用什么就跟什么这是最容易返工的地方。三条路线的差别不只是显存还包括可解释性、可迁移性和调试成本。我按自己的实测经验整理了一张对照表参数以 7B 级别模型、bf16 精度为基准估算实际会因实现细节浮动方案可训练参数占比训练显存粗估训练速度适合场景主要风险全参微调100%80GB 以上慢数据量大、要彻底改变模型分布显存炸、灾难性遗忘严重LoRAr16约 0.5%–1%20–28GB快单卡、数据几千条级别效果上限受 rank 限制QLoRA4bit 基座约 0.5%–1%10–14GB较慢24GB 以下显卡、实验迭代频繁量化误差、合并权重需注意我最终选的是 LoRA理由很实在单卡 24GB 的环境下全参微调需要把优化器状态、梯度、激活值全塞进去怎么调都紧张一旦 OOM 就要反复重启调试节奏彻底断掉QLoRA 虽然显存最省但 4bit 量化后的基座在训练过程中会引入额外噪声对于我这种要观察小数据集上细微能力变化的场景等于给自己加了一层干扰。LoRA 在这两者中间显存可控、效果可解释、adapter 可以单独存下来做多版本对比做作业最需要的就是这种“能反复试”的灵活性。选 LoRA 还有一个隐性好处adapter 文件只有几十 MB你可以同时保留五个不同超参数的版本评测的时候一起跑横向对比非常方便。全参微调一个 checkpoint 就是十几个 GB光是磁盘管理就够烦的。做作业不是做生产迭代速度本身就是一种能力。1.3 先把显存账算清楚再决定动手显存估算这件事我的建议是自己拿笔算一遍不要依赖框架的自动提示。算过一次之后你对“为什么 batch size 只能开到 2”这类问题会彻底祛魅。训练显存大致由四块构成模型权重、梯度、优化器状态、激活值。用 7B 模型、bf16 权重来算权重70 亿参数 × 2 字节 ≈ 14GB梯度如果是全参同样是 14GBLoRA 只算 adapter几十 MB 可以忽略优化器状态Adam 需要维护一阶和二阶动量fp32 精度下是参数量的 8 倍字节全参时约 56GBLoRA 时按 adapter 参数量算同样可以忽略激活值跟 batch size、序列长度、层数成正比这一块才是 LoRA 场景下的主要开销所以 LoRA 的显存基本可以写成基座权重 14GB 激活值 框架开销。激活值的粗估公式是激活 ≈ batch_size × seq_len × hidden_size × num_layers × 系数7B 模型 hidden 约 4096、层数 32序列长度 2048、batch 为 1 时粗略算下来单层激活在几十 MB 量级乘以层数就是几个 GB。再叠加梯度检查点gradient checkpointing的开启激活值可以被压到原来的三分之一左右代价是训练速度下降 20%–30%。我的经验值7B LoRA bf16 序列 2048 batch 1 梯度检查点稳定在 18–20GB24GB 卡能留出余量如果关掉梯度检查点基本会顶到临界点跑几十步就可能 OOM。提示显存估算里的“框架开销”经常被忽略但它在实际中占 1–3GB包括 CUDA 上下文、cuBLAS 工作区、通信缓冲区等。预留这个余量的意义在于你后面的评测、推理都要在同一张卡上跑别把显存吃干净。2. 数据准备作业里最容易翻车也最容易拉开差距的环节2.1 对话模板对齐一个符号错位就能让模型学不会停这一节我建议你逐字看完因为它是第三次作业里出现频率最高的隐形故障。指令微调的数据通常是有角色结构的比如 system、user、assistant 三段。训练框架会用一个chat_template把这些角色拼成一条字符串再转成 token。问题在于训练时用的模板必须和推理时用的模板完全一致包括空格、换行、特殊符号、结束标记的位置。哪怕只差一个换行模型学到的“该在哪里停下来”这个信号就会错位。我自己第一版就栽在这里。数据里 assistant 的回答末尾手动加了结束符但训练脚本在拼接时又在末尾补了一个结果模型学到了“说完了还要再说一遍”的习惯推理时输出无限循环。当时看 loss 曲线完全正常甚至下降得很漂亮因为模型把重复的结束符也当成要拟合的目标了。这种 bug 光看曲线永远发现不了只有实际生成才能暴露。正确的做法是把数据构造过程写成显式代码自己控制 prompt 部分和 answer 部分的分界并且把 prompt 部分的 label 全部置为 -100不计算损失只让 answer 部分参与反向传播。原因是 prompt 是用户给的模型不需要学习“怎么提问”它需要学习的是“怎么回答”。如果 prompt 也参与损失计算模型会花相当一部分容量去拟合用户措辞的分布在小数据集上这会明显稀释学习信号。def build_supervised_example(messages, tokenizer): # 最后一条是 assistant 的回答前面是上下文 prompt_text tokenizer.apply_chat_template( messages[:-1], tokenizeFalse, add_generation_promptTrue ) answer_text messages[-1][content] tokenizer.eos_token prompt_ids tokenizer(prompt_text, add_special_tokensFalse)[input_ids] answer_ids tokenizer(answer_text, add_special_tokensFalse)[input_ids] input_ids prompt_ids answer_ids labels [-100] * len(prompt_ids) answer_ids return {input_ids: input_ids, labels: labels}构造完之后一定要做抽样验证把labels里非 -100 的部分解码回文本看它是不是恰好等于回答内容。这个检查只要两分钟能省掉后面两小时的困惑。我现在的习惯是每次改完数据格式先跑三条样本打印出来肉眼核对确认无误再启动训练。2.2 数据清洗的实操清单先砍量再谈质第三次作业的数据一般要求自建几百到几千条不等。这里有个很反直觉的经验在这个量级下数据质量的重要性远超数量。你拿五百条高质量样本效果通常比拿两千条一半是噪声的样本好得多因为小数据集上模型对每条样本的权重都很敏感噪声样本会把决策边界拽歪。我用的清洗清单大致是这样几层按顺序过第一层是格式层检查字段是否完整、角色顺序是否合法、有没有空的回答、有没有超长截断导致句子断裂。这一层用脚本批量过规则明确。第二层是内容层检查回答是否真的回答了问题。这一步很多人跳过但实测问题不少有些样本的问题是“解释某个概念”回答却在复述问题有些是多轮数据第二轮的回答和第一轮上下文对不上。这类样本会让模型学到“答非所问”的模式。第三层是重复层做近似去重。完全相同的样本好处理难的是语义重复比如同一个问题换了三种问法、回答几乎一样。这类样本会让模型对某个特定话题过拟合表现是遇到相关问题时输出高度模板化。第四层是长度层统计回答的 token 长度分布把极端长尾的样本挑出来单独看。特别长的回答有两种可能一种是真的内容丰富另一种是模型生成时的啰嗦重复被当成正样本收进来了后者必须删掉否则会把啰嗦学到手。注意清洗不要追求“一步到位”。我的流程是粗洗一遍就开始小规模试训用 200 条数据跑 1 个 epoch看生成效果再回头针对性地洗。因为很多数据问题只有模型训出来才能看见纯靠人工读是读不完的。2.3 数据规模、轮次与过拟合之间的平衡小数据集微调最容易犯的错是把 epoch 开太大。三千条数据、batch 有效大小 16一个 epoch 大概是 190 步三个 epoch 就是 570 步。对 LoRA 来说这个步数在 r16 的配置下已经足以让模型把训练集背下来了。表现就是训练 loss 一路降到 0.3 以下训练集上的回答完美换一个问法就崩。我的经验区间是数据在 1000–3000 条量级时1 到 2 个 epoch 通常就够了配合 cosine 学习率衰减。判断该不该继续训不能只看 loss要看验证集上的生成质量。我的做法是从数据里留 5% 做验证每 100 步生成几条固定 prompt 的回答人工扫一眼。如果发现回答开始变得高度雷同、或者开始出现训练集里的原句照搬说明过拟合已经开始了该停。还有一个容易被忽略的点是验证集的构造方式。如果验证集和训练集是从同一批模板生成的只是换了具体内容那验证分数会虚高因为模型学到的是模板而不是能力。我一般会刻意让验证集在问法风格上和训练集有差异哪怕只有二十条也能起到预警作用。3. 微调实操从配置文件到第一个 epoch 跑完3.1 关键超参数的取值逻辑与计算过程超参数这块我不打算给你一套“万能配置”因为不存在。但我可以把每个参数背后的权衡讲清楚你自己对着硬件和数据量调。学习率是影响最大的一个。LoRA 的学习率通常比全参微调高一个量级因为可训练参数少、每个参数需要走更远。常见区间是 1e-4 到 3e-4。我最终取 2e-4理由是数据量中等、训练步数在 500 步左右、配合 cosine 衰减这个值在前期能快速把 adapter 拉离初始状态后期衰减又能稳住不飘。如果你把 rank 调大到 64学习率要相应降一点因为参数空间变大了。LoRA rank 和 alpha是一对。rank 控制低秩矩阵的秩决定表达能力上限alpha 是缩放系数实际生效的缩放是alpha / rank。很多人只改 rank 不改 alpha结果缩放系数跟着变效果波动很大还以为是自己数据的问题。我的习惯是固定alpha 2 × rankr16 配 alpha32这样缩放系数恒为 2改 rank 时行为可预期。target modules 我选 all也就是注意力层的 q、k、v、o 和 FFN 层的 gate、up、down 全挂上原因是只挂 q、v 在老版本实现里是省显存的妥协现在有梯度检查点全挂的显存代价可以接受效果明显更稳。有效 batch size用per_device_batch × 梯度累积 × 卡数算。单卡 24GB、序列 2048 的情况下per_device 只能开到 2梯度累积设 8有效 batch 就是 16。这个值不是随便定的太小比如 4会让梯度噪声大、训练抖动太大比如 64在几千条数据上意味着一个 epoch 只有几十步根本训不透。16 对我来说是个平衡点一个 epoch 约 190 步。序列长度cutoff_len要按数据的实际分布定。我统计了训练集回答长度的 95 分位大约是 1100 token加上 prompt 平均 300 token取 2048 有充足余量。如果你盲目设 4096显存翻倍但绝大多数样本用不到纯属浪费。3.2 配置文件逐行拆解与显存实测我的配置文件大致长这样逐项说明放在后面model_name_or_path: ./base_model stage: sft do_train: true finetuning_type: lora lora_rank: 16 lora_alpha: 32 lora_dropout: 0.05 lora_target: all dataset: round3_train template: default cutoff_len: 2048 max_samples: 3000 preprocessing_num_workers: 8 per_device_train_batch_size: 2 gradient_accumulation_steps: 8 learning_rate: 2.0e-4 num_train_epochs: 2.0 lr_scheduler_type: cosine warmup_ratio: 0.1 bf16: true gradient_checkpointing: true logging_steps: 10 save_steps: 200 output_dir: ./output/round3lora_dropout设 0.05 是为了在小数据集上提供一点正则设 0 在三千条数据上过拟合会更快设 0.1 又会让收敛变慢训练步数不够时效果反而差。warmup_ratio0.1 意味着前 10% 的步数用来线性升温避免一开始学习率太大把 adapter 直接推到坏区域。bf16优先于 fp16因为 bf16 的动态范围更大不容易出现梯度溢出导致的 loss 变 NaN代价是部分老卡不支持那就只能退回 fp16 并配合 loss scaling。实测算显存启动后我用nvidia-smi持续观察稳定在 19.2GB 左右峰值出现在第一个 step 的预处理和第一次反向传播约 21GB。这个余量足够我在同一张卡上挂一个小的推理进程做在线抽样。如果你的卡是 24GB 且显存峰值顶到 23GB 以上第一件事是确认梯度检查点真的生效了——有些框架需要同时关掉use_cache否则检查点不生效显存会白白多占几个 GB。3.3 训练曲线怎么读loss 下降不等于学会了训练日志里我最关注的三个量是 loss、学习率和梯度范数。loss 的绝对值没有太大参考意义因为不同数据、不同 mask 策略下基线完全不同有意义的是下降的形状。健康的曲线是前 50 步快速下降然后进入缓慢下降的平缓段偶尔有小幅波动。如果曲线是阶梯状每隔一段突然掉一大截那多半是数据里有长度差异极大的样本一个 batch 里混进了超长样本导致梯度突变。梯度范数grad_norm是我判断训练是否稳定的主要依据。正常范围在 0.5 到 5 之间波动如果持续超过 10说明学习率偏大或者数据里有异常样本如果长期低于 0.1说明学习率太小或者 adapter 已经饱和继续训下去收益很低。我在第一版里遇到过 grad_norm 突然飙到 30 然后又恢复的情况排查下来是某条样本里有大量重复符号tokenize 后产生了异常长的序列。删掉那几条之后曲线立刻平滑了。还有一个必须做的检查每 200 步保存 checkpoint 的时候顺手生成几条固定 prompt 的回答存档。这样训练结束后你可以回看“第 200 步的模型长什么样、第 400 步长什么样”从而判断最佳停止点在哪。只看最终 checkpoint 是很浪费的很多时候中间某一版的泛化能力反而最好。4. 评测与部署让作业从“能跑”变成“能看”4.1 客观评测与主观评测的组合拳评测这一环是第三次作业里最容易被写成流水账的地方。我见过很多提交只有一句“效果明显提升”没有数据支撑这在评审视角下等于没做。评测要做扎实得两条腿走路客观题看能力有没有退化主观题看风格有没有对齐。客观评测我用的是一批学科知识类的选择题格式固定、答案唯一、可以自动判分。它的作用不是证明你的微调让模型变聪明了——几千条数据不可能提升知识储备——而是监控灾难性遗忘。基座模型原本能答对的题微调后如果错了一大片说明你的数据分布太窄把模型带偏了。我的实测是微调后在客观题上的准确率相比基座下降了约 1.5 个百分点这个幅度可以接受如果超过 5 个点就要回头检查数据是不是太单一。主观评测我用的是自己构造的 30 条开放式 prompt覆盖训练数据涉及的场景和未涉及的场景各一半。评分维度拆成三项指令遵循有没有按要求回答、内容准确性说的是不是对的、表达自然度像不像人话。每项 1–5 分我自己打一遍隔一天再打一遍取平均减少主观漂移。未涉及场景的那一半尤其重要它是检验泛化能力的唯一手段。评测维度样本量基座得分微调后得分变化客观选择题准确率200 题基准值基准值 -1.5pt轻微退化可接受指令遵循30 条2.84.3明显提升内容准确性30 条3.53.9小幅提升表达自然度30 条3.14.1明显提升未涉及场景泛化15 条3.43.3基本持平看这张表能得出一个很清晰的结论这次微调主要改善的是“听话程度”和“说话方式”知识层面没有实质变化泛化能力守住了。这个结论比“效果显著提升”有价值得多因为它明确了这次训练的能力边界。4.2 权重合并与推理服务搭建LoRA 训练产出的是 adapter推理时有两种用法一是加载基座再挂 adapter二是把 adapter 合并进基座存成完整权重。做作业验证时我用第一种因为切换不同版本的 adapter 只需要改一个路径要做交付或者部署时用第二种因为合并后推理没有额外开销。合并这一步有个细节要注意合并必须在 fp32 或者与训练一致的精度下做如果基座是 bf16、adapter 是 fp32直接合并会产生精度损失累积尤其当 rank 较大时。稳妥做法是先按训练精度加载合并后再统一转成推理精度。# 合并 adapter 到基座输出完整权重 python merge_adapter.py \ --base_model ./base_model \ --adapter_path ./output/round3 \ --output_path ./merged_round3 \ --dtype bf16推理服务我起了一个 OpenAI 兼容接口方便用脚本批量跑评测。启动参数里最关键的是max_new_tokens和停止符。停止符必须和训练时的结束标记完全一致这一条前面提过在推理侧同样致命。max_new_tokens我设 512比训练数据里回答长度的 95 分位略高既能覆盖绝大多数情况又不会让异常生成拖太久。温度我评测时用 0贪心解码保证结果可复现演示时用 0.7输出更自然。python -m serving.api_server \ --model ./merged_round3 \ --dtype bfloat16 \ --max_new_tokens 512 \ --temperature 0.0部署完成后用同一批 prompt 分别请求基座和微调后的服务把结果落成对照表这就是你作业报告里最有说服力的材料。4.3 评测报告怎么写才像内行报告写得好不好直接决定评审对你工作量的判断。我的写法是固定四段做了什么、怎么验证、结果如何、结论边界在哪。前两段是事实陈述后两段是判断缺一不可。“做了什么”部分要写清楚数据来源、规模、构造方式、训练配置把关键参数列成表别让读者去翻配置文件。“怎么验证”部分要说明评测集怎么来的、评分标准是什么、有没有做重复评分来降低主观偏差。“结果如何”用表格呈现基线和微调后排在一起变化量标清楚。“结论边界”是区分内行和外行的关键你得明确说出这次微调解决了什么、没解决什么、在什么条件下可能失效。我这一版的结论边界写的是本次微调显著提升了指定场景下的指令遵循和表达自然度客观知识能力基本持平对训练分布外的开放问题没有明显改善当输入长度超过 2048 token 时由于训练时做了截断表现可能不稳定。把局限写出来不会显得工作没做好反而说明你真的跑过、真的测过。5. 踩坑实录报错、异常与排查速查5.1 显存与精度相关的硬报错OOM 是这类作业里最常见的报错但它的成因有好几种处理方法完全不同。第一种是启动即 OOM通常在加载模型阶段就炸原因往往是精度没设对比如误加载成 fp327B 模型光权重就 28GB24GB 卡必然失败。第二种是训练几步后 OOM这类最典型的原因是序列长度不均某个 batch 里混进了超长样本激活值瞬间涨上去。第三种是评测时 OOM因为推理进程和训练进程抢显存或者max_new_tokens设太大导致 KV cache 膨胀。对应的排查顺序我固定为先看报错栈出现在哪个阶段再看nvidia-smi的占用曲线最后看当前 batch 的序列长度。有一个特别隐蔽的坑日志里显示 OOM但实际原因是 CPU 内存被 dataloader 吃满了preprocessing_num_workers开太大每个 worker 都持有一份数据副本。这种情况报错信息会误导你往显存方向查其实把 worker 数降到 4 就好了。另一个高频问题是 loss 变 NaN。bf16 下比较少见fp16 下很常见因为 fp16 的表示范围窄梯度稍大就溢出。解决办法要么换 bf16要么开 loss scaling 并降低学习率。我遇到过一例是数据里存在极长的重复字符串tokenize 后产生了超长序列模型在前向时激活值爆掉最终表现为 NaN。删掉那几条样本就好了所以 NaN 出现时先查数据再查精度。5.2 数据与模板相关的软故障软故障指的是不报错但结果不对的情况排查成本远高于硬报错。最常见的是模型不停下来一直生成直到max_new_tokens耗尽。原因几乎总是模板不一致训练时的结束符在推理时没被识别或者训练数据里根本没加结束符。排查方法很直接把训练样本拼好的完整字符串打印出来和推理时构造的字符串逐字符对比差异一眼就能看出来。第二种是模型开始复读同一句话反复说。这在小数据集、高 epoch 的情况下很典型本质是过拟合到了某个高频句式。缓解手段是降 epoch、加 dropout、清洗掉高度重复的样本。我实测下来清洗数据比调参数有效得多。第三种是回答开头出现奇怪的符号或者角色标签比如模型自己输出“assistant:”。这说明训练数据里角色标签的位置和 label mask 的位置错开了模型把角色标签也当成了要生成的内容。回到 2.1 节那段代码检查labels里非 -100 部分的解码结果问题必然在那里。5.3 训练不稳定与效果不达预期有时候一切正常就是效果不行。这种情况我按下面的顺序排查基本能定位到原因现象最可能原因验证方法处理方式loss 正常但生成质量差模板不一致 / label mask 错误解码 labels 非 -100 部分修正数据构造训练集好、换问法就崩过拟合 / 数据多样性不足对比验证集生成结果降 epoch、补数据多样性输出风格变了但能力下降数据分布过窄客观题准确率对比混入通用数据做回放训练几十步后 loss 不降学习率过小 / adapter 未生效打印可训练参数数量检查 target modules 配置生成内容冗长啰嗦训练数据里长回答占比过高统计回答长度分布清洗长尾、加长度惩罚样本“adapter 未生效”这个坑值得单独说一句。有些框架在lora_target配置不匹配模型结构时会静默地不挂任何 adapter训练照跑loss 照降因为可能有其他层被训练但效果完全没有。验证方法是训练开始前打印可训练参数的数量和占比7B 模型挂 r16 全模块可训练参数应该在两千万到四千万量级。如果打印出来是 0 或者几百万配置肯定有问题别急着跑先修。最后分享一个我反复验证过的小技巧每次改动配置或者数据之后先只用 100 条样本跑 20 步看能不能正常启动、loss 是否在动、显存是否在预期范围。这个“冒烟测试”只要三分钟能挡掉八成以上的低级错误。真正花时间的是跑完几小时之后发现方向错了那种返工才叫难受。这套作业做下来我最大的体会是微调这件事的技术门槛其实不高框架已经把大部分脏活封装好了真正拉开差距的是你有没有在每一步都问自己“我怎么知道这一步是对的”。数据构造时问一遍参数设置时问一遍训练过程中问一遍评测时再问一遍。这四个问题答得出来作业就稳了答不出来跑得再顺也只是运气好。