这套大模型训练营二期的第三次作业，我前后做了三版，从最开始“脚本能跑完、日志不报错”就交差，到后来逼着自己把每个超参数为什么这么设、每一条评测分数为什么长这样都讲清楚，中间踩的坑基本覆盖了单卡做指令微调会遇到的大多数问题。这篇就把我这一版作业的完整思路和实操过程摊开写一遍，包括数据怎么处理、LoRA 参数怎么算、显存怎么估、评测怎么做、报错怎么查。如果你正在做大模型训练营二期第三次作业，或者手头有一个 7B 级别的中文基座模型想做领域适配，这篇可以直接当施工图看；如果你只是想搞清楚“微调到底在调什么”，前面两节也足够让你建立整体认知。
需要先说明一点：这篇不讨论“哪个模型最强”这种没有标准答案的问题，只讨论在我手上的硬件条件下，怎么用最稳的方式把一个基座模型调成能干活的样子，并且能拿出可复现的证据证明它确实变好了。第三次作业的核心难点从来不在代码量，而在判断力——你得能分辨“loss 降了”和“模型学会了”是两件完全不同的事。
1. 第三次作业到底在考什么：任务拆解与整体设计思路
1.1 从“跑通脚本”到“讲清理由”：作业设计的真实意图
训练营前两次作业解决的是“环境能不能起来”“推理能不能出字”，到了第三次，重心明显发生了转移。作业要求里那些看起来零散的小任务——数据构造、参数配置、训练日志、评测对比、部署验证——拼在一起，其实是一条完整的链路：你得自己造一批带监督信号的数据，让基座模型在这批数据上发生定向改变，然后用可量化的方式证明这个改变是真的。这条链路上任何一环糊弄，最后的结果都对不上。
我见过最多的失败模式是：数据随手凑了三百条，配置照抄教程默认值，训练跑完 loss 从 2.4 降到 0.9，兴致勃勃去测，发现模型说话的语气变了但能力没变，甚至原来会做的题现在不会做了。这种情况不是训练失败，是训练目标定义失败。你压根没有想清楚希望模型在哪一类输入上产生什么样的输出变化，自然也谈不上验证。
所以我在动手前做的第一件事，是把作业拆成四个必须回答的问题：模型现在缺什么能力、用什么数据补、用什么方式注入、用什么指标验收。这四个问题对应的就是后面四章的内容。把它们写在纸上贴在显示器边上，比任何教程都管用，因为中途你一定会想改数据、改参数，这时候抬头看一眼，能避免大量无效折腾。
1.2 全参微调、LoRA、QLoRA：三条路线怎么选
路线选择这件事，很多人是看别人用什么就跟什么，这是最容易返工的地方。三条路线的差别不只是显存，还包括可解释性、可迁移性和调试成本。我按自己的实测经验整理了一张对照表，参数以 7B 级别模型、bf16 精度为基准估算，实际会因实现细节浮动：
| 方案 | 可训练参数占比 | 训练显存（粗估） | 训练速度 | 适合场景 | 主要风险 |
|---|---|---|---|---|---|
| 全参微调 | 100% | 80GB 以上 | 慢 | 数据量大、要彻底改变模型分布 | 显存炸、灾难性遗忘严重 |
| LoRA（r=16） | 约 0.5%–1% | 20–28GB | 快 | 单卡、数据几千条级别 | 效果上限受 rank 限制 |
| QLoRA（4bit 基座） | 约 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
- 梯度：如果是全参，同样是 14GB；LoRA 只算 adapter，几十 MB 可以忽略
- 优化器状态：Adam 需要维护一阶和二阶动量，fp32 精度下是参数量的 8 倍字节，全参时约 56GB；LoRA 时按 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–20GB，24GB 卡能留出余量；如果关掉梯度检查点，基本会顶到临界点，跑几十步就可能 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], tokenize=False, add_generation_prompt=True ) answer_text = messages[-1]["content"] + tokenizer.eos_token prompt_ids = tokenizer(prompt_text, add_special_tokens=False)["input_ids"] answer_ids = tokenizer(answer_text, add_special_tokens=False)["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 来说，这个步数在 r=16 的配置下已经足以让模型把训练集背下来了。表现就是训练 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 × rank，r=16 配 alpha=32，这样缩放系数恒为 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.8 | 4.3 | 明显提升 |
| 内容准确性 | 30 条 | 3.5 | 3.9 | 小幅提升 |
| 表达自然度 | 30 条 | 3.1 | 4.1 | 明显提升 |
| 未涉及场景泛化 | 15 条 | 3.4 | 3.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，通常在加载模型阶段就炸，原因往往是精度没设对，比如误加载成 fp32，7B 模型光权重就 28GB，24GB 卡必然失败。第二种是训练几步后 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 模型挂 r=16 全模块，可训练参数应该在两千万到四千万量级。如果打印出来是 0 或者几百万，配置肯定有问题，别急着跑，先修。
最后分享一个我反复验证过的小技巧：每次改动配置或者数据之后，先只用 100 条样本跑 20 步，看能不能正常启动、loss 是否在动、显存是否在预期范围。这个“冒烟测试”只要三分钟，能挡掉八成以上的低级错误。真正花时间的是跑完几小时之后发现方向错了，那种返工才叫难受。
这套作业做下来，我最大的体会是：微调这件事的技术门槛其实不高，框架已经把大部分脏活封装好了，真正拉开差距的是你有没有在每一步都问自己“我怎么知道这一步是对的”。数据构造时问一遍，参数设置时问一遍，训练过程中问一遍，评测时再问一遍。这四个问题答得出来，作业就稳了；答不出来，跑得再顺也只是运气好。
