好看吧

手机浏览器扫描二维码访问

437 傲慢的代价（第1页）

孟繁岐并不是第一次听说DeepSeek的名字，虽然此前DS在大众之中不能说是完全无人知晓，但说它是籍籍无名也不为过。

比起天然拥有海量客户的互联网大厂们推出的AI模型，DS即便免费，但终究天然地在积累用户方面有着巨大的劣势。

孟繁岐此前注意到DS，主要便是因为他们的技术路线与孟繁岐的几个设想相似。

由于在降低技术成本上颇有建树，DS的API价格要低于市场平均水平许多，这使得它慢慢积累了一些技术型的用户。

不过这个规模在孟繁岐眼中，还远远上不了桌。

前两个月，DeepSeek已经迭代到了第三代。

逐渐缩小的性能差异并没有引起孟繁岐足够的重视。

而今天，详细的技术报告以及R1版本的发布，才终于让他明白，自己实在是后知后觉。

震撼到孟繁岐的并不是单纯性能上的逼近，而是诸多技术细节透露出的海量信息。

比如，FP8的成功实现。

孟繁岐有些不相信这个事实。

半精度和FP8是他一直在大力推动的事情，而现在，DS反而成为了首个在超大规模模型上证明了FP8训练完全可行的公司。

孟繁岐沉着脸，翻阅着DS的技术报告，他们对框架内部的操作细节并不吝啬。

哪些核心操作做了FP8的量化，在什么步骤应该转回BF16，又在哪里应该使用全精度FP32计算，标注十分详细。

向量层、输出层、MoE门控模块、标准化运算和注意力运算模块进行了精度保留，而前向，激活反向，权重反向则用FP8执行。

针对前向反向采用FP8会带来的许多问题，报告中也知无不言。

在低精度训练框架中，由于FP8格式的指数位较少导致其动态范围受限，经常出现数值溢出和下溢的问题。

传统方法是将输入张量的最大绝对值映射到FP8格式的最大可表示值，将输入分布对齐到可表示范围内。

然而，这种方法使得低精度训练对激活值中的极端值特别敏感，可能导致量化精度显著下降。

孟繁岐也走到过这一步，部分FP8，部分BF16FP32。

仅仅如此是不够的。

DS最终采用的方案是在核心算子内部GEMM操作里引入缩放因子，这同样是孟繁岐曾经考虑过的事情。

但closeai最终没有这样做，因为英伟达显卡的FP8并不直接支持这一功能。

长期居于龙头位置的closeai程序员们并没有选择下苦工用其他的方式实现这一功能，而是选择了与英伟达沟通，以求让英伟达在下代硬件框架中支持细粒度缩放格式。

孟繁岐回忆起那个时候，欲言又止。

这称得上是错误吗？其实也不见得。

因为closeai的建议为英伟达提供了重要参考。

下一代硬件框架中支持该功能无疑是非常正确的决定。

但...没有它真的就做不了吗？很显然，DS回答了这个问题，现有的条件之下，技术并不是无法实现的。

另一件让孟繁岐感到扼腕叹息的事情，是双方在“稀疏”

这一概念上的分歧。