做模型微调这行的朋友，大概都经历过这样一种憋屈：明明数据质量不差，训练脚本也跑得通，可模型就是在某几个特定任务上反复横跳——要么回答变得极其模板化，要么在长序列上梯度突然炸开，loss 曲线像心电图一样上下乱窜。更让人头疼的是，单路径的监督微调（SFT）往往把模型往一个固定的输出分布上拽，遇到稍微偏离训练分布的输入，表现就断崖式下滑。我最近在复现一个叫 GFT 的框架思路时，针对这两个老毛病做了不少实验，核心就是用对比学习打破单路径依赖，再配合自适应优化把梯度爆炸按住。这篇就把我踩过的坑、调过的参数、以及那些文档里不会写的细节，完整摊开讲一遍。

1. 单路径依赖到底是怎么把模型带偏的

1.1 从 SFT 的损失函数说起

要理解问题，得先回到 SFT 的本质。标准的监督微调用的是交叉熵损失，给定输入 x 和目标输出 y，模型要最大化 log P(y|x)。这个目标本身没毛病，但它隐含了一个假设：对于每个输入，存在一个"正确"的输出序列，模型只需要学会复现它。问题在于，真实场景里同一个问题往往有多种合理回答，而 SFT 只给了模型一条路径。

我拿一个简单的指令跟随任务做过对比实验：同一批 prompt，人工标注了三种不同风格但都正确的回答，SFT 训练完之后，模型对这三种风格的覆盖率不到 40%，剩下 60% 的输出全都塌缩到了训练集中出现频率最高的那种表达上。这就是单路径依赖的典型表现——模型不是学会了"怎么回答"，而是记住了"该背哪句话"。

从梯度角度看更清楚。交叉熵对 logits 的梯度是 softmax 概率减去 one-hot 标签，当模型对某个 token 的预测概率接近 1 时，梯度趋近于 0，模型就"锁死"在这个 token 上不再更新。训练越久，这种锁定越严重，输出分布越尖锐，多样性越差。这不是模型笨，是损失函数在结构上就鼓励它走独木桥。

1.2 单路径依赖在实测中的三种症状

我把实际遇到的单路径依赖问题归了三类，方便你对号入座。

第一类是表达塌缩。模型对所有输入都用同一套句式开头，比如永远以"这是一个很好的问题"起手，或者所有代码回答都套同一个模板。这种最容易被发现，但也最难根治，因为它是全局性的分布偏移。

第二类是任务间干扰。多任务混合训练时，某个任务的梯度会压制另一个任务的学习。我做过一个实验，把分类任务和生成任务混在一起 SFT，结果生成任务的 BLEU 掉了 8 个点，原因是分类任务的短输出把生成任务的长序列分布带偏了。

第三类是分布外脆弱。训练集里没见过的输入格式，模型直接崩。这个最隐蔽，因为验证集上指标看着还行，一上真实流量就露馅。我印象很深的一次，验证集准确率 92%，上线后遇到带特殊符号的输入，正确率直接掉到 60% 出头。

提示：判断是否中招单路径依赖，别只看 loss。跑一个"同义改写测试"——把验证集输入用三种不同方式改写，看输出方差。方差越小，依赖越重。

1.3 为什么加数据解决不了根本问题

很多人第一反应是"数据不够多，多标点不就行了"。我试过，把标注量翻三倍，表达塌缩确实缓解了一些，但分布外脆弱几乎没改善。原因很简单：数据量增加只是让模型见过更多路径，但交叉熵的目标函数依然在鼓励它收敛到单一路径上。换句话说，你喂再多数据，损失函数的形状没变，模型还是会往最陡的那个坡滑。

真正要动的是训练目标本身。这就引出了对比学习的思路——不再只告诉模型"这个答案对"，而是告诉它"这个答案比那个答案更对"，通过相对关系来塑造一个更平滑、更有结构的输出空间。

2. 对比学习怎么把输出空间撑开

2.1 从"绝对正确"到"相对优劣"的目标重构

对比学习的核心思想，是把训练目标从"最大化正确输出的概率"改成"最大化正确输出与错误输出之间的间隔"。用 InfoNCE 损失的思路来理解：给定一个锚点样本，一个正样本（合理回答），若干负样本（不合理或次优回答），模型要学会把锚点和正样本在表示空间里拉近，和负样本推远。

放到 GFT 框架里，具体做法是对每个输入构造多个候选输出，用奖励模型或人工规则给它们打分，然后以分数最高的作为正样本，分数低的作为负样本。这样模型学到的不是"唯一答案"，而是"什么样的回答更好"这个相对关系。我实测下来，这个改动对表达多样性的提升非常明显——同义改写测试的输出方差从 0.12 提到了 0.31，接近翻倍。

这里有个关键细节：负样本的构造质量直接决定效果。我一开始图省事，随机采样负样本，结果模型学到的间隔很模糊，多样性提升有限。后来改成"难负样本"策略——专门挑那些分数接近正样本、但确实有缺陷的候选，模型才真正学会了区分细微差别。这个改动让分布外测试的准确率提升了 6 个点。

2.2 温度系数与负样本数量的联动调参

对比学习里有两个参数最要命：温度系数 τ 和负样本数量 K。这两个不是独立的，得联动调。

温度系数控制的是分布的尖锐程度。τ 太小，模型对负样本过于敏感，训练不稳定；τ 太大，间隔拉不开，对比学习退化成普通分类。我一开始用默认的 0.07，训练到中期 loss 开始震荡，后来调到 0.1 才稳住。经验值是：负样本越多，τ 可以适当调小，因为大 K 本身提供了足够的区分信号。

负样本数量 K 则受显存限制。K 从 4 加到 16，多样性指标持续上升，但到 32 之后边际收益递减，显存却翻了一倍。我最后定在 K=12，配合 batch size 64，单卡 40G 显存刚好跑得动。

下面是我实测的一组参数对照，供参考：

从表里能看出来，τ=0.10、K=12 是性价比最高的组合。再往上加 K，收益已经很小了，不如把显存省下来做别的优化。

2.3 表示空间的坍缩陷阱与规避

对比学习有个著名的坑叫表示坍缩——所有样本的表示都挤到一个小区域里，模型看起来收敛了，实际上啥也没学到。我在第一版实现里就踩了这个坑，训练 loss 降得很漂亮，但下游任务一测全崩。

排查过程挺折腾的。我先怀疑是学习率太大，调小之后没改善；又怀疑是负样本太少，加到 32 还是坍缩。最后定位到问题出在投影头上——我用的两层 MLP 投影头维度设得太小（128 维），表示空间被压得太扁。把投影头维度提到 512，同时加了一个 stop-gradient 操作（类似 BYOL 的做法），坍缩问题才解决。

判断是否坍缩有个简单办法：定期算一下 batch 内所有样本表示的协方差矩阵，看它的秩。如果秩远小于维度，基本就是坍缩了。我现在的训练脚本里加了这个监控，每 500 步打印一次，心里有底。

注意：对比学习的 loss 下降不代表学好了。一定要配一个下游任务的快速验证集，每轮训练后跑一次，别被 loss 曲线骗了。

3. 梯度爆炸的成因与自适应优化的介入点

3.1 长序列训练里梯度爆炸的真实触发条件

梯度爆炸在长序列场景下特别常见，但触发条件比想象中具体。我做了系统的压力测试，发现三个因素叠加时最容易炸：序列长度超过 2048、学习率大于 2e-5、以及注意力层没有做数值稳定处理。

从原理上讲，反向传播时梯度要穿过每一层的雅可比矩阵连乘，序列越长，连乘的项越多，梯度范数呈指数级增长。我在一次实验中记录到，序列长度从 1024 加到 4096，梯度范数的峰值从 3.2 飙到了 1800 多，直接导致参数更新步长过大，loss 瞬间变成 NaN。

有意思的是，梯度爆炸往往不是均匀发生的，而是集中在少数几个注意力头上。我打印过每层的梯度范数，发现大部分层都在正常范围，但有两三个头会突然爆到几百。这说明问题不是全局的，而是局部的数值不稳定。这个观察直接影响了后面的优化策略——与其全局裁剪，不如做更精细的自适应控制。

3.2 梯度裁剪的局限：为什么全局阈值不够用

最朴素的方案是全局梯度裁剪，设一个阈值，超过就按比例缩放。我一开始用这个，阈值设 1.0，确实能防住 NaN，但副作用明显：正常层的梯度也被一起缩放了，学习效率下降，收敛变慢。

问题在于全局裁剪是"一刀切"。梯度范数 1800 的层和范数 2 的层，被同一个阈值约束，前者被砍到 1.0，后者纹丝不动，但实际上前者的信息可能更重要。我做过对比，全局裁剪下训练步数比不裁剪多了 30%，而且最终指标还略低一点。

更麻烦的是，全局裁剪掩盖了问题的根源。梯度爆炸的本质是局部数值不稳定，全局裁剪只是把症状压住了，没有解决为什么某些层会爆。这就需要一个能感知局部状态、动态调整的优化器。

3.3 自适应优化器的分层梯度缩放策略

GFT 框架里我采用的是分层自适应缩放，思路是给每一层（甚至每个注意力头）维护一个梯度范数的滑动平均，然后根据当前范数与该层历史均值的比值来动态缩放。

具体实现上，我用的是类似 Adafactor 的思路做二阶矩估计，但加了一个分层归一化。伪代码大概是这样：

# 分层梯度自适应缩放（简化示意） for name, param in model.named_parameters(): if param.grad is None: continue grad_norm = param.grad.norm() # 维护每层的梯度范数滑动平均 state[name].ema = 0.99 * state[name].ema + 0.01 * grad_norm # 计算缩放因子，限制在 [0.5, 2.0] 之间防止过度调整 scale = torch.clamp(state[name].ema / (grad_norm + 1e-8), 0.5, 2.0) param.grad.mul_(scale)

这个策略的好处是，梯度突然爆掉的层会被压下来，而正常层几乎不受影响。实测下来，序列长度 4096 时，梯度范数峰值从 1800 降到了 45 左右，而且训练步数只比理想情况多了 8%，比全局裁剪好太多。

有个细节要注意：滑动平均的衰减系数 0.99 不是随便定的。太小（比如 0.9）会让缩放因子对噪声过于敏感，训练抖动；太大（比如 0.999）则反应迟钝，爆炸发生了还没压住。我试了几组，0.99 在稳定性和响应速度之间平衡得最好。

4. 把对比学习和自适应优化拼起来的完整训练流程

4.1 训练阶段的划分与损失权重调度

对比学习和自适应优化不是简单叠加，得安排好训练节奏。我的做法是分三个阶段：

第一阶段是预热，只用标准 SFT 损失，让模型先建立基本的任务能力，同时让自适应优化器把各层的梯度统计量积累起来。这个阶段大概占总步数的 15%。

第二阶段引入对比损失，但权重从 0.1 开始线性升到 0.5。为什么要渐进？我试过一上来就用 0.5 的权重，模型直接不收敛，因为对比损失和 SFT 损失的梯度方向冲突太剧烈。渐进升温给了模型适应的时间。

第三阶段是稳定期，两个损失权重固定，学习率做余弦衰减。这个阶段最长，占总步数的 60% 左右。

损失权重的调度曲线我调了好几版，最后定的是：

这个调度不是拍脑袋定的。过渡阶段之所以给 25%，是因为对比损失的梯度方差比 SFT 大，需要更长的适应期。我试过压缩到 10%，结果过渡期结束时 loss 有个明显的反弹。

4.2 显存与吞吐的实测权衡

对比学习要构造多个候选输出，显存开销比纯 SFT 大不少。我实测的数据：同样 batch size 64、序列长度 2048，纯 SFT 占 28G 显存，加上 K=12 的对比学习后占到 38G。如果显存不够，有几个降本手段。

第一个是梯度检查点，能省 30% 左右的显存，代价是训练速度慢 20%。第二个是负样本的延迟编码——正样本正常前向，负样本先缓存表示，分步计算，这样能把峰值显存压下来。第三个是混合精度，用 bf16 代替 fp32，显存直接减半，而且 bf16 的动态范围比 fp16 大，不容易溢出，特别适合有梯度爆炸风险的场景。

我最后用的是 bf16 加梯度检查点的组合，显存降到 26G，吞吐从每秒 12 个 batch 降到 9 个，但换来的是能跑更大的 K 和更长的序列，整体性价比更高。

提示：bf16 在梯度爆炸场景下比 fp16 稳得多。fp16 的指数范围窄，梯度一大就 inf，bf16 基本不会。如果你的硬件支持，优先上 bf16。

4.3 一个完整的配置示例与启动命令

把上面的东西串起来，我给一份可以直接抄的配置骨架。这里用 YAML 描述训练参数，具体框架无关，逻辑通用：

training: total_steps: 20000 warmup_ratio: 0.15 transition_ratio: 0.25 stable_ratio: 0.60 batch_size: 64 max_seq_len: 2048 precision: bf16 gradient_checkpointing: true contrastive: enabled: true temperature: 0.10 num_negatives: 12 loss_weight_start: 0.1 loss_weight_end: 0.5 hard_negative_mining: true adaptive_optim: ema_decay: 0.99 scale_min: 0.5 scale_max: 2.0 base_lr: 2.0e-5 lr_schedule: cosine

启动的时候，我习惯先跑一个 200 步的 dry run，专门看梯度范数的分布和显存占用。dry run 里我会打开逐层梯度监控，确认没有哪一层的范数异常突出。这个习惯帮我提前发现过好几次配置错误，比如有一次忘了开梯度检查点，dry run 直接 OOM，省得正式训练跑到一半崩掉。

5. 实测中那些文档不会写的坑

5.1 对比损失与 SFT 损失的梯度冲突排查

前面提过两个损失会冲突，但具体怎么冲突、怎么排查，值得单独说。我遇到的现象是：训练到过渡阶段中期，SFT 损失开始上升，对比损失正常下降，总 loss 看着在降，但下游指标停滞。

排查思路是分别监控两个损失对共享参数的梯度余弦相似度。如果相似度为负，说明两个损失在往相反方向拉。我实测发现，在过渡阶段初期，相似度确实在 -0.3 左右，随着训练推进慢慢转正。这说明冲突是暂时的，渐进升温的策略是对的。

但如果相似度长期为负，就得调整了。我的处理办法是给对比损失加一个梯度投影，把它投影到与 SFT 梯度正交的方向上，避免直接对抗。这个操作在 PyTorch 里用torch.autograd.grad配合手动投影就能实现，代价是训练慢一点，但能救回不收敛的配置。

5.2 难负样本挖掘的采样偏差问题

难负样本能提升效果，但有个隐蔽的坑：采样偏差。如果负样本总是从某几类错误里挑，模型会过度拟合这些错误类型，导致对其他类型错误的区分能力下降。

我的解决办法是分层采样——先把候选负样本按错误类型分组，每组内按分数排序取 top，再在各组之间均匀采样。这样保证了负样本的多样性。实测下来，分层采样比纯 top-k 采样的分布外准确率高 4 个点。

还有个细节：难负样本的"难度"要动态调整。训练初期模型能力弱，太难的负样本它分不出来，反而干扰学习。我的做法是难度随训练步数递增，初期只取中等难度的负样本，后期才引入最难的。这个课程学习的思路让收敛更平滑。

5.3 自适应缩放与学习率调度的相互干扰

自适应梯度缩放和学习率调度会相互影响，这个我踩过坑。现象是：余弦衰减到后期，学习率很小，但自适应缩放还在根据梯度范数调整，导致有效学习率忽大忽小，loss 在最后阶段抖动。

根因是缩放因子和基础学习率的作用叠加了。解决办法是在学习率衰减到峰值的 10% 以下时，冻结自适应缩放的 scale，让它保持常数。或者更简单，把 scale 的作用范围限制在 [0.8, 1.2]，后期影响就很小了。

我现在的配置里，scale 范围设的是 [0.5, 2.0]，但在稳定阶段后期会收窄到 [0.8, 1.2]。这个细节在文档里基本找不到，是实打实调出来的。

6. 效果验证与上线前的检查清单

6.1 三个必须跑的验证维度

训练跑完别急着上线，我固定跑三个维度的验证。

第一个是多样性验证，用同义改写测试，看输出方差是否达到预期。我的及格线是方差大于 0.25，低于这个说明对比学习没起作用。

第二个是鲁棒性验证，构造一批分布外输入，包括特殊符号、超长文本、格式错乱的情况，看准确率下降幅度。我的要求是下降不超过 10 个点。

第三个是梯度健康度验证，在验证集上跑前向和反向，记录梯度范数分布，确认没有异常尖峰。这个能提前发现潜在的数值不稳定。

三个维度都过了，才进入灰度。我见过太多只盯验证集 loss 就上线的案例，结果线上翻车。

6.2 灰度阶段的监控指标设置

灰度阶段我重点盯三个指标：输出重复率、响应长度分布、以及异常输出比例。输出重复率突然上升，往往是单路径依赖复发的信号；响应长度分布偏移，说明模型对输入的理解出了问题；异常输出（比如空回复、乱码）比例超过 0.5%，就得回滚。

这些指标我都是实时算的，每 1000 条请求统计一次。有一次灰度时发现重复率从 3% 悄悄爬到了 11%，追查下去是对比学习的权重在增量更新时被覆盖了，及时修了配置才没酿成大问题。

说到底，GFT 这套框架的价值不在于某个单点技术，而在于它把"让模型学会多样表达"和"让训练过程数值稳定"这两件事放到了同一个优化框架里考虑。对比学习负责撑开输出空间，自适应优化负责守住训练底线，两者配合才能在长序列、多任务的真实场景里跑得稳。我个人的体会是，参数调优的功夫八成花在这两者的耦合上，单独调任何一个都容易顾此失彼。上面这些配置和排查思路，都是我在反复实验里磨出来的，你拿去用的时候，建议先从小规模 dry run 开始，把梯度监控和多样性验证跑通，再逐步放大，别一上来就全量开跑。