如何评价 deepseek 的 deepseek-V3 模型？
我觉得 deepseek v3 主要做成了 2 件事：
- 继 flash attention 之后，又一个相信自己比英伟达懂 GPU 计算，并且做到了的团队；
- 找到了 pretrain 的一个 10x 变化。
这里前者是指 fp8 训练，后者是指 pretrain batch size 的扩展。
fp8 训练应该算是各个工程团队长久的痛。大家都明白 fp8 的计算峰值是 bf16 的两倍，但是除了 23 年 Yi 团队对外宣传成功做了 fp8 的 pretrain，fp8 这里一直都没有一个相对公开的 recipe，更多地是 “训练极其不稳定” 的流言。而英伟达官方的 transformer engine 似乎也没有解决这个问题，并且如同英伟达的其他开源软件库一样，变得愈发笨重和冗杂。
deepseek 团队有这个勇气和能力直接抛开英伟达提出的 fp8 实践，给出了例如正反向都使用 e4m3，attention 后的 linear 输入的精度需要提升这样的细节，以及独立实现 per-group scaling 的训练（这部分也可以解读为受 B 系列显卡的 microscaling 启发），真的是非常令人佩服。就像是 Tri Dao 大大告诉大家 attention 的 kernel 应该这样写一样，deepseek 团队正在告诉大家，fp8 应该这样用。
相较于 fp8 这个可以被看做是相对独立的工程问题，我更喜欢的是他们通过扩大 batch size，提升工程效率的这种算法和工程的联调。相信很多朋友都听说过，系统领域的一个常见思路就是去考虑在某个维度放大 10 倍之后，会有哪些新的 trade-off，从而获取更充分的设计空间。deepseek 提出的将 pretrain batch size 从传统的 4M~8M tokens，提升至 4K * 15360 = 60M tokens 就是这样的变化。超大的 batch size 可能可以 makes pipeline parallel great again。
在此之前，我一直认为 pp 是相对鸡肋的并行方式，因为不管怎么优化 pp 算法，减小 bubble 的前提总是 micro batch 足够多，划分足够细。以 deepseek v3 这个 671B 模型为例，目前的设置是 2048 卡分 16 路 pp，没有 tp，也就是 2048 / 16 = 128 路 dp。那么在 context length 为 4k 的情况下，如果 batch size 为 4M，也就是 1024 条 sample，每一组 pp 的 16 张卡只能分到 1024 / 128 = 8 个 sample，连让 16 张卡同时运行都做不到。
而当 batch size 扩到 15360 个 sample 时，每一组 pp 的 16 张卡就能分到 120 个 sample，那么 bubble 就可以压下来，pp 也就变成了一个不错的候选：因为它通信较小，而且部分通信相较于 tp 更好隐藏。由此，引出了论文中 dualpipe 这样的新设计，这部分我估计这个问题下面会有很多细致解读，我就不展开了。
考虑到现在工业界的 sft 也走到了一个 epoch 10B token 这个量级，我觉得这种 batch size 上的调整会对 25 年训练框架的设计带来比较大的影响。
我倾向于扩大 batch size 会有一定程度的掉点（实际上最近还在和同事聊，是不是 llm 到了一个需要上 lamb 的时候），所以如之前 character.ai 的那个回答中提到的，我非常钦佩能够牺牲一点模型性能，换取工程效率提升的团队。真的太优秀了，太 nb 了！
最后，还要感谢 deepseek 让资源少的团队又燃起了从零训 sota 的火苗！
P.S. 刚刚发现其实 deepseek v2 的时候 batch size 就已经很大了，是我后知后觉了...
