训练稳定性
旗舰训练 Run 的日常巡检：十几万指标与梯度极值 token 审问
顶级模型的训练（业界常称"炼丹"）本质上是持续修 BUG 的过程。 月之暗面团队启动旗舰训练任务（Flagship Run）后，每天第一件事是刷新十几万个内部监控指标，任何一条曲线的异常上扬都要归因：优化器问题、架构缺陷还是数值精度未对齐。 数据侧同样有调试手段：从训练语料中筛出梯度极值过大的 token，逐个打印出来审问其跳动剧烈的原因——异常 token 往往是语料脏污、格式错误或分布偏移的信号。 这反映了大规模训练工程的一个常识：loss 曲线只是最终症状，定位问题需要把监控粒度下沉到分指标面板与原始 token 两个层级。
训练中途的数值精度热切换：bf16 → fp32
月之暗面在一次旗舰训练中遇到关键参数数值异常飙升：这些参数一直以半精度（bf16）存储，眼看训练失控，团队在训练中途切换到全精度（fp32）才稳住局面——如同马拉松跑到一半换跑鞋，代价是显存占用与训练速度，收益是避免整个 Run 崩盘。 工程上应认识到，半精度的累积舍入误差会在超长训练中持续放大，对数值敏感的关键参数应预留精度切换（或关键层保持 fp32 的混合精度）预案，而不是等到 loss spike 不可挽回才处理。 这与 OPT-175B 公开训练日志中多次因 loss spike 回滚 checkpoint 的记录互为印证：数值稳定性是大模型训练的一等问题，而非事后补救项。
长上下文能力攻关的三次回撤：MoBA 案例
月之暗面 2023 年攻关 128K 长文本（当时业界普遍仅支持 4K）的过程，展示了架构级改动的典型代价。 第一版 MoBA（Mixture of Block Attention，块混合注意力）v0.5 因需重写底层训练框架、且主模型已训练过半，成本过高被迫搁置。 v1 改为可基于现有模型继续训练的方案，小模型验证成功，但在大模型上遭遇 loss spike，调试无果后项目第二次退回，长达半年； 公司随后启动"饱和救援"，调动多路技术专家集体攻关、重写底层逻辑，v2 才稳定通过"大海捞针"（needle in a haystack）检索测试。 上线前的第三次回撤出现在 SFT 阶段：长文本总结任务因训练信号过于稀疏导致模型表现不佳，最终通过调整最后几层注意力机制解决。 这反映了长上下文能力的真实成本结构：架构创新（稀疏注意力）、训练稳定性（loss spike）、后训练信号设计（稀疏监督）是三道独立的坎，每一道都可能让整个项目回撤数月。