搞大模型的人有一种奇怪的习惯喜欢把训练过程描述得云淡风轻。“我们在256块H800上训练了两个月”——一句话就带过去了。听的人觉得好像就是点个运行然后等结果实际上呢说多了都是泪。我认识一个在类似规模团队待过的朋友他说训一次千亿参数模型的过程可以概括为百分之十的时间在算百分之九十的时间在救火。今天这卡挂了明天那梯度炸了后天发现数据有一半是脏的。DeepSeek训V2的过程虽然我没有一手资料但从他们公开的信息和一些边角料里可以拼出一个大概。先说算力规模。DeepSeek-V2的训练动用了数千块GPU具体数量他们没有明确说但考虑到236B总参数和8.1T tokens的训练数据量这个规模至少是千卡级别。千卡集群是什么概念意味着你的故障率会高到让你怀疑人生。GPU这东西单卡跑一个月出问题的概率可能就百分之零点几。但一千块卡同时跑两个月几乎每天都有一两块卡出幺蛾子。显存报错、NVLink断连、散热不良自动降频、甚至干脆整卡掉线。处理过大规模分布式训练的人都知道你的训练脚本里至少百分之三十的代码是在处理各种异常情况断点续训、故障卡自动隔离、梯度同步超时重试等等。DeepSeek的解决方案大概率是自己写了一套训练框架或者对现有框架做了深度定制。因为这个规模的MoE模型训练现成的框架根本搞不定。PyTorch Distributed在百卡级别还能撑住到千卡级别各种边界条件问题全冒出来了。我猜他们大概率是在Megatron或者类似框架基础上做了大量魔改特别是针对MoE的通信模式做了优化。说到通信MoE训练有个特别头疼的问题叫“all-to-all通信”。传统的数据并行训练各卡之间只需要同步梯度通信模式是规整的all-reduce。但MoE不一样每个token要被路由到不同的专家那里而不同专家可能在不同GPU上。这就意味着你需要把token从当前卡发送到目标专家所在的卡处理完再发回来。这个过程叫all-to-all通信量巨大且不规整很容易成为训练瓶颈。DeepSeek在这里做了一个我觉得挺巧妙的事情让专家尽量“本地化”。通过优化路由策略让相邻的token尽量落在同一组GPU内的专家上减少跨节点通信。这需要修改训练时的数据分发逻辑让shuffle的时候考虑数据局部性。听起来简单实现起来全是细节。再说数据。8.1T tokens的训练语料光存储就要几十TB。数据清洗更是个无底洞。网页文本要去HTML标签、去广告、去导航栏代码要去注释里的许可声明、去重复的模板文件多语言数据要分语种、做质量过滤。每一道工序都有无数决策要做每一个决策都会影响最终模型的表现。我特别想知道他们数据配比是怎么调的。中文多少、英文多少、代码多少、多语言多少这个比例稍微动一下模型的能力分布就会有明显变化。调这个配比基本靠经验和试错没有什么理论指导。训一次两个月试错成本高得离谱。据我所知大部分团队在这件事上都是“差不多就行”然后看结果再微调DeepSeek应该也不例外。还有一个很少被提及的事情训练过程中的监控。你不可能两个月不看不管得实时盯着各种指标。Loss曲线是不是正常下降有没有突然跳变各专家负载是否均衡有没有专家被“饿死”梯度的范数有没有爆炸需要不需要调整学习率。这些监控项加起来可能有几十个而且往往是某个不起眼的指标先发出警告告诉你三天后可能会出大问题。DeepSeek团队在这方面应该是下了功夫的。从他们最终放出来的模型质量来看训练过程的稳定性控制得很好。没有出现明显的灾难性遗忘不同能力之间的平衡也不错。这在第一次训这么大规模的MoE模型时是很难做到的。还有成本。千卡集群跑两个月光算力成本就在千万人民币级别。这还没算数据处理、人力、试错轮次的消耗。大模型训练本质上是一场豪赌赌的是你训出来的模型比别人好那么一点点这一点点能在市场上换来多少回报。DeepSeek背后有足够的资源支撑这场赌博这也是他们能持续迭代的重要原因。最后说说一个很微妙的事情训练过程中的人为干预。虽然大家都在强调自动化训练但实际上关键节点还是需要人来做决策。学习率什么时候衰减衰减多少检测到异常波动是继续训还是回滚到上一个checkpoint要不要提前停止训练。这些决策直接影响最终模型质量而且很大程度上依赖团队的直觉和经验。训大模型这件事说到底是个工程能力的较量。算法创新当然重要但把算法稳定高效地在超大规模上跑通需要的是一整套工程体系。从DeepSeek-V2的表现来看他们的这套体系已经相当成熟了。这个护城河比单个算法的创新要深得多。