搞大模型的人有一种奇怪的习惯，喜欢把训练过程描述得云淡风轻。“我们在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的表现来看，他们的这套体系已经相当成熟了。这个护城河，比单个算法的创新要深得多。