混合精度训练为什么一开动态 Loss Scaling 就开始频繁跳步：从 Overflow Window 到 Scale Hysteresis 的工程实战

很多团队把Dynamic Loss Scaling当成混合精度训练的标准配置，日志里一旦出现found_inf，第一反应就是再把scale调小一点。⚠️ 真正麻烦的地方在于，系统表面看上去没有直接NaN，训练也还在往前跑，但优化器会不断跳过更新，验证集曲线随之出现一段一段的空转。🎯

这种抖动最容易出现在FP16 + 梯度累积 + 长序列组合里。模型并不是一直算错，而是少量高范数 micro-batch 把瞬时 overflow 变成了控制信号，scale因此频繁收缩又恢复。🔍 从监控面板看，GPU 利用率没有明显塌掉，真正被拖慢的是“有效更新密度”，也就是单位时间里真正完成了多少次可信参数更新。🧠

跳步变多通常不是 scale 太大，而是 overflow 被处理得过于立即

很多实现把一次found_inf直接等价为“当前 loss scale 不可用”。📌 这在短样本场景里问题不大，但长序列训练经常会遇到局部激活峰值、稀有 token 聚集和累积边界放大，它们未必代表当前阶段整体不稳定。只要控制器按单次事件立刻回退，训练就会进入一次 overflow、一次 shrink、再慢慢长回去的来回摆动。📉

第二个隐蔽问题出在跨卡一致性和梯度裁剪顺序。🛠️ 如果先做clip_grad_norm_再unscale_，监控会误以为梯度已经被控制住；如果各个 rank 独立决定是否 skip step，就可能出现有的卡更新、有的卡回退，最终把抖动放大成参数漂移。🔒 所以真正该治理的不是单个张量，而是整个 step 的 overflow 观察窗口。✅

一组 13 B SFT 回放里，稳定收益来自窗口化回退而不是盲目降 scale

这次回放的是13 B指令微调任务，硬件为8 x A100 80 GB，序列长度8192，梯度累积步数16。🧪 基线组使用默认动态缩放；第二组把初始scale直接下砍一半；第三组保留较高初始值，但增加Overflow Window = 32和Scale Hysteresis = 2，只有窗口内连续命中过载阈值才触发真正回退。📊 结果说明，小心地“晚一点降”比粗暴地“立刻降”更稳。🚨

这里最值得注意的不是第三组把 overflow 完全消灭了，而是它把“偶发尖峰”和“持续不稳”区分开了。📍 默认策略会把每次异常都变成优化器空转，直接降初始scale虽然能少跳几步，却也牺牲了低幅梯度分辨率。只有窗口化观察加迟滞回退，才能让控制器对真正的坏趋势敏感、对短暂噪声迟钝。🔧

scaler_cfg={"init_scale":2**15,"growth_interval":256,"backoff_factor":0.5,"overflow_window":32,"overflow_trip_ratio":0.10,"scale_hysteresis":2,}

生产里应该把 Loss Scaling 做成门禁策略，而不是日志开关

更稳的做法，是把overflow_window_rate、consecutive_skip_steps和scale_recover_steps当成一组门禁指标持续看。📈 一旦连续多个窗口都在高位，再回退scale；反过来，恢复也不要每隔几十步就尝试放大，而要等验证损失和梯度范数都回到稳定区间。这样做的核心不是保守，而是避免控制环在噪声里来回误判。🧩

笔者认为，未来3 - 6个月混合精度训练链路会越来越少讨论“默认GradScaler好不好用”，越来越多讨论“overflow 该如何按集群、模型和序列长度分层治理”。🚀 如果系统回答不了一次 skip step 究竟来自哪类 batch、哪段累积窗口、哪组 rank 归约，它就还没有把动态缩放做成工程能力。💬