摘要:随着人工智能技术的飞速发展,大语言模型及相关应用正成为推动科技变革的核心力量。然而,背后支撑这些模型高效运行的基础设施(Infra)却鲜为人知。本文将深度解读DeepSeek开源周的内容,通过通俗易懂的语言,剖析DeepSeek在模型训练、推理优化以及基础设施
随着人工智能技术的飞速发展,大语言模型及相关应用正成为推动科技变革的核心力量。然而,背后支撑这些模型高效运行的基础设施(Infra)却鲜为人知。本文将深度解读DeepSeek开源周的内容,通过通俗易懂的语言,剖析DeepSeek在模型训练、推理优化以及基础设施建设方面的创新成果。
本篇内容是对DeepSeek Infra开源周内容的一次费曼学习结果
阅读前最好能看过前置内容《万字长文:DeepSeek 647天铸就的登神长阶》。否则虽然也能看懂,但会无法建立全局视野,摄入的知识产生折扣。
阅读的时候可以先跳过每个章节的“术语说明”,看不懂了,再回去翻术语说明。不然没有上下文硬啃术语是挺难受的。
DAY1 FlashMLA地址:https://github.com/deepseek-ai/FlashMLA,11.2K stars
术语说明
MLA(Multi-Head Latent Attention),DeepSeek-V2中首次提出,用以取代他们在DeepSeek-67B中使用的GQA。是一种成本低,效果好的注意力算法。Flash,来自FlashAttention这个项目,Flash是闪光、快速,Attention是注意力。这是一个老牌的,专门优化注意力计算/内存效率的项目。FlashMLA,所以FlashMLA,就是DeepSeek开源的,借鉴了FlashAttention项目中的一些理念,然后专门针对他们自研MLA进行优化的CUDA内核。所以,通俗来讲,MLA是MLA,FlashMLA是“如何更好在机器上跑MLA”的优化方法。SM(Streaming Multiprocessor,流式多处理器),这是GPU上的计算单元,H800上有132个SM。Wrap,是SM上线程调度的基本单位,你可以想象为流水线。所以GPU→SM→Wrap,DeepSeek很多精细化的工作是在Wrap层级上进行的。项目特点
① Hopper专用
Hopper是英伟达的显卡系列名称,换成耳熟能详的就是H800、H100。
也就是说这个项目如果在其他卡上直接运行,例如华为昇腾、英伟达的A100,都是行不通的。至于为什么,下面会说。
② 对KV缓存进行分块
每块大小64。分块后,整个计算和内存的效率会得到相当大的提升。
这就像以前以订单为单位去做仓库管理,有的订单10000个货品,有的订单100个货品,这时候可能出现某个卡车1订单装不下或者1订单装不满的情况,利用率很低。
这个时候平台推动了改革,不再以订单为单位做管理,而是跟踪到每个SKU。那么这个时候你的管理颗粒度上升,虽然会带来更多管理成本,但整体的物流仓管效率也会因为细粒度而得到巨额提升。
不过这个不是DeepSeek的独特发明,而是来自FlashAttention的理念。
③ 极致利用共享内存
共享内存(Shared Memory)的访问速度很快,但容量很小,英伟达的Hopper系列,每个SM(GPU计算单元)上最大的共享内存为228K(数据来源英伟达官网)。
而DeepSeek在项目中将KV计算的中间结果都放在共享内存上了,每个SM单元下利用其中的224K(此数据来源知乎ling ye),从而实现了224/228=98.2%的利用率。
一方面,这极大利用了共享内存的高速特性,但也将这个项目牢牢限定在Hopper系列上,因为别的系列很难支持228K/SM的共享内存(例如A100仅有164KB)。
④ Wrap级别的精雕细琢
前面讲到DeepSeek将每个SM的共享内存利用得淋漓尽致,那么这里讲的就是他对每个SM计算、内存通信上的性能压榨。
DeepSeek将整个KV的计算分为两个Wrap Group,其中一个主要负责计算,一个主要负责加载内存,在64分块大小下,刚好每次完成一个分块的计算。
如下图所示,warp0负责Gemm1 这个矩阵的计算+Gemm2一半的计算。Wrap1则负责整个计算过程Q、K、V的内存加载搬运+Gemm2另一半的计算。
p.s,请记住Gemm这个概念,在两天后的第三个项目就会提到他。
⑤ 动态输入序列的适配
在实际的场景中,输入的序列是长度不一的,特别是R1类推理模型或阅读理解类任务,输入序列会很长。
在这个项目里DS采用了双线程缓冲的模式,会进行一个动态负载进行计算。如果短序列就采用计算优先模式,长序列就采用内存优先模式。(此部分细节需要要看代码,我的参考来自ZOMI酱的解说)
总结
最终,在H800 SXM5这个卡上,FlashMLA实现了内存带宽3000GB/S(上限是3.2TB,利用率已经接近90%了),计算浮点数580 TFLOPS的表现
DeepSeek利用了KV分块+共享内容利用+精细化的Wrap设计把H800的性能压榨得一干二净。
有趣的点
我翻了一下issue和fork,已经有人复现了基于A100的 FlashMLA出来了,我相信基于升腾、H20、V100等其他卡的应该也在路上。
项目最末有一堆社区支持,我看了一下,国内芯片很多都在,唯一一个海外的芯片厂商就是AMD了。
另外知名推理框架vLLM也已经完成对FlashMLA的集成支持。
这也是开源的优势所在,MLA一下子从DeepSeek独家的一个注意力机制,变为热门方案,社区涌现出的许多创意方案又能再次反哺到DeepSeek的研发推进当中。
DAY2 DeepEP地址:https://github.com/deepseek-ai/DeepEP?tab=readme-ov-file,7.1Kstars
术语说明
EP(expert parallelism),专家并行性。大参数的Moe模型必须部署在多机多卡上。而训练或推理的时候,要把输入的Token分发给各个专家处理,处理完后要重新合并。可是分发和合并的专家们却分布在多个GPU上,这就是专家并行性。
全对全通信(ALL to ALL),全对全通信和点对点通信(P2P)是计算机通信里的两种概念。
如下图,某张卡的数据要发给4个专家处理,这4个专家又在四张卡上,这就需要黄色的这个“0卡”,与4张卡进行4次通讯。以此类推,1、2、3卡也要做这样的事情,这就产生了4X4=16次通讯。
点对点就简单了,0卡把数据发给1卡,结束。所以全对全通信的通信压力是非常大的。
但偏偏,全对全通信在大参数的Moe架构必定会发生,这是因为两点:① Moe架构的输入需要分发给多个专家处理,然后再从多个专家中回收结果合并输出;② 而大参数的Moe模型,必定需要部署在多机多卡上,所以专家们是分布在多个GPU上的,这就导致整个分发和合并的过程必定要跨GPU进行。
Dispatch&combine(分发和整合)。在DeepSeek V2中提到一个门控路由,可以对输入的序列进行处理,然后只分发给TOP-N个专家进行处理(在V3中是TOP-8),这个分发就是Dispatch。当专家们处理完后,再对结果进行回收,统一输出结果,这个整合过程就是combine。
NCCL(NVIDIA Collective Communications Library)& NVSHMEM。NCCL是英伟达开发的集合通信库,专门用于多节点和多GPU的通信。而NVschmen则把多节点的内存地址做了统一,可以将多个节点上的GPU内存视为一个虚拟的超大GPU,从而直接对多个不同节点的内存进行操作。这一段应该比较晦涩,可以放到后面的项目亮点中一起理解。参考内容:英伟达NVschmen技术文档
NVlink&RDMA。NVlink是一台服务器内多个GPU的通信方式,H800的带宽名义双向400GB/s,DeepSeek实测单向160GB/s,其延迟是纳米级别的。而RDMA则是多个服务器之间的通信方式,带宽50GB/s,延迟为微米级别。
项目特点
① 放弃中台,完全贴合业务定制
我们能够看得出来,这个项目是为了解决Moe模型在训练、推理过程中的全对全通信问题。而这个问题过去是通过NCCL或其他类似通信库来解决的。为什么DeepSeek非要自己用NVSHMEM自己手写呢?
如果我们将计算机通信比作物流(同样是搬运,区别只是搬运数据/商品),NCCL就像是淘宝、京东搭建的通用物流平台,已经能够便捷地帮你发货了。可是你现在创业了,做了一个去中心的跳蚤平台,每个人即是卖家,也是卖家,NCCL中的很多设计和封装对你来说都是冗余的。
偏偏你非常在乎这个通信效率,想压榨出最极致的性能。所以你选择NVshcmen,把每个用户的地址都统一映射为一个巨大无比的虚拟地址簿,然后在这个基础上进行完全贴合你业务的改写。
再用一个互联网中比较常见的概念——中台之殇。中台的原意是抽象通用业务,加快新业务的建立。但中台越维护,就越不好用,越发在业务竞争中陷入技术劣势。尤其在LLM这种耗资巨大的明星项目中,更是无法忍受一丝一毫的效益浪费。
更直观的概念可以看下面这张图(左边变成右边),整个系统中过去常用、完善的通信库,被DeepSeek用NVSHMEM直接重写,改成了完全适配自己Moe模型的通信(物流)方法了。
② 训练&推理全兼容
在训练中,输入序列通常固定且长,例如4096Token。在推理的预填充阶段,会一次性对所有输入Token进行并行计算(例如一次性把“你好,请帮我解释一下xxx”这几个字并行计算)。这两个场景中都会要求极大的吞吐量。
而在推理的解码阶段(即一字一字往外输出),则要求低延迟性,以保证用户体验。
为此这个项目中DeepSeek准备了两种CUDA内核方案。
第一种,通过NVlink(160GB/s)+RDMA网卡(50GB/s)结合进行,适配训练+推理预填充阶段的需求
第二种,则是纯粹RDMA网卡进行,适应推理解码阶段的低延迟需求(因为减少了NVlink到RDMA的转发)。
③ 原生支持FP8数据分发
随着DeepSeek的开源(包括论文和Github项目),FP8训练越来越成为业内的共识。
但这可能也是DeepSeek选择 NVSHMEM手搓通信的一个原因,因为NCCL 对FP8精度的支持不是那么
p.s 这条不保真,原文来自英伟达24年4月的一条技术博客——“NVIDIA NCCL 仅支持高精度规约操作 (reduction),所以现在仍然需采用 FP16 进行 reduction,完成后再转化为 FP8。”
④ 计算与通信重叠
在旧的方案里,我们正常的顺序是:
获取注意力结果→分发给不同专家(通信)→专家们计算→将专家们结果合并(通信)→decode解码。
其中通信部分可以理解为数据传输,数据没到,流水线就得等,不能计算——流水线就跑不满,效率下降。
而在新的方案里,DeepSeek将同时计算两个批次的结果。所有通信的行为,都发生在计算中,从而消除流水线气泡。
如果用通俗例子说,可以用在厨房做两道菜来举例:
第一种是,我在厨房里进行备菜+炒菜,要完成番茄炒蛋+宫保鸡丁。我先完成番茄炒蛋的备菜,然后炒熟它,再进行宫保鸡丁的备菜,再炒熟它。
资本家看不下去了,于是提出第二种方案。我先做番茄炒蛋的备菜,然后炒它,在等它熟的时候,我就去做宫保鸡丁的备菜。等宫保鸡丁备菜好了,番茄炒蛋也熟了,就紧跟着把宫保鸡丁炒了。
当然Deepseek会更邪恶,他会把备菜(通信)和炒菜(计算)的时间对得刚刚好,让我一个时间单位就做完两道菜。
如下图所示,原本dispatch(分发)和combine(整合)都是通信,是要浪费整个流水线上用于计算的时间的,现在转换后,都隐藏到计算的背后去了。
总结
DeepEP,说白了就是DeepSeek抛弃了传统的NCCL通信库,自己用更底层的NVSHMEM自己手搓了一套通信方法。
这套方法可能不如NCCL那么全面,但在独特的Moe大模型场景下,却是绝对效率最好的。
本章节参考文档:
英伟达NVschmen技术文档
B站Zomi的解读,再次推荐这个博主
有趣的点
我在找NVSHMEN资料的时候,不小心看到下面这张图,来自2022年5月。两位GIT佬在交流NCCL和MVSHMEM的看法。这个对话或许有助于你理解两者的区别。截图来源:https://github.com/NVIDIA/nccl/issues/679
DeepSeek在项目中声明了一个“未定义的PTX用法”。PTX可以理解为CUDA再往下的一层语言,通常是CUDA/C++→PTX→SASS(机器码)。
所谓未定义即,英伟达官方文档中没有说可以这样用,但结果发现可以用,性能还提升了。
这下真的诠释了什么叫“你只是个做显卡的,你懂什么芯片”。
最后,这个DeepEP在DeepSeek-v3论文中提及过,原文是:“In order to ensure sufficient computational performance for DualPipe, we customize efficient cross-node all-to-all communication kernels (including dispatching and combining) to conserve the number of SMs dedicated to communication”
DAY3 DeepGEMM地址:https://github.com/deepseek-ai/DeepGEMM,4.9Kstars
术语说明
GEMM(General Matrix Multiplication,通用矩阵乘法)。是大模型训练推理中经常用到的一种计算方式,在门控路由(推荐TOP-N专家),注意力分数的计算,专家前馈网络,训练梯度的反向更新等等都会用到。
GEMM操作几乎占大模型推理计算量的70%以上。所以只要优化GEMM,就能将计算效率推高一截。
项目特点
① 削履适足
事实上GEMM在过去有一个经典的库,即英伟达的CUTLASS。但和上个项目DeepEP一样,CUTLASS太过经典通用,在极致的业务适配上并没有达到极限。
在项目的说明中,他提及了大量相对于CUTLASS项目的改进,我们在下面展开。事实上DeepGEMM相对CUTLASS的性能改进,正是这些细细碎碎的改进叠加起来的。
② JIT设计
传统的编译方式,最终执行的代码是固定的。而JIT则是边运作边生成代码。
在这个生成过程中,他可以根据情况选择更好的内存分配、减少条件判断等等,他的代码性能会比传统方式更好。
③ 支持非2次方的块
SM通常只支持2的幂次方块大小,例如256,128等。但这回答导致工作效率拉不满(经典的DeepSeek资本家邪恶风格)。
DeepGEMM通过支持非2幂次的块大小来优化特定形状的效率。
例如传统128分块,在M=256,N=7168(M可以近似理解为输入序列长度,N是FNN的维度)时,(256 / 128) * (7168 / 128) = 112个块。但H800中有132个SM(计算单元),只分到112个块,利用率就太小了(112/132=84%)。
而如果采用112分块,同样情况下,则(256 / 128) * (7168 / 112) = 128个分块结果,利用率为128/132=96%。
④ 针对最底层的SASS机器码动刀
还记得我们前面说到的,CUDA/C++>PTX>SASS(机器码)吗?
在V3/R1论文中,DeepSeek动了PTX,就被人惊呼绕过了CUDA,英伟达已死(全是bullshit言论)。而在这里他们干脆对最底层的SASS二进制编码动刀了。
他们的发现过程很有意思,先是注意到NVCC 在12.2和12.3之间,传统GEMM项目 CUTLASS FP8的内核提升了。
啊?这是为什么呢?他们进一步比对了最底层的SASS二级制编码,发现FADD这个指令中会发生周期性交错反转。进一步调研后,怀疑这个指令通过控制warp线程的释放提高了效率。
于是他们借鉴这个思路,干脆开发了一个二进制的脚本来控制另一个指令FFMA,让他也能实现类似的效果。最后发现某些情况能够提升10%以上的性能!
说实在的,这段话,我只能理解一个大概。但是什么FADD、FFMA指令,什么yield位,reuse位是真的不懂,我打算学习Infra,但真没想过我要学到二进制机器码这个地步。
但透过这个记录,我好像看到一个得意的研究员,美滋滋地敲下这段GITHUB说明。
这个世界真正的光芒,总是闪耀在细微之地啊,干杯!
总结
针对大模型训练推理中占据计算资源最多的GEMM操作,DeepSeek仍然自己做了更底层(甚至到机器码)的实现以追逐最极致的性能
他们在不同尺寸的矩阵中做了测试,这也是网上很多媒体所说“2.7倍提升”的由来。
但实际上,在Dense(稠密)模型上是1.0倍~2.7倍,其中2.7倍只是极特别的一个场景。
看这个M,N,K的数据,大概是一个低输入长度,低参数的模型。例如向deepseek-7B提问:”你好呀”。(此条举例可能有错,欢迎指出)
事实上我更关心他在Moe结构上的效果
结合下图来看,在连续布局(预填充)和掩码布局下基本上都有1.1X的提升,这已经非常了不起了!
这就类似突然有人和你说全中国的电力成本,能再下降10个百分点…那我马上把全屋空调开起来!(广东开始进入夏天了T T)
有趣的点
这个GEMM库虽然了不起,但需要特别注意的是:他并不支持训练环节,因为训练环节不仅需要GEMM,还需要其他的融合内核,而他们希望这个库干净整洁,所以仅仅发布了面向推理的GEMM内核。
但——DeepSeek内 部正在讨论是否发布可用于预训练的相关内核。(相关信源)
DAY4 DualPipe&EPLBhttps://github.com/deepseek-ai/DualPipe , 2.6K stars
https://github.com/deepseek-ai/eplb 1.1Kstars
DualPipe
DualPipe,双向流水线。区别于单线流水线。在DeepSeek-V3中有一个专门的篇幅提及这个方法。
事实上Dualpipe并非DeepSeek首创,根据知乎Fazzie在文章中的说法,其最早可以追溯到 21年SC奇美拉Chimera: Efficiently Training Large-Scale Neural Networks with Bidirectional Pipelines 这篇文章。
但为什么直到今天才由DeepSeek重新提出并发扬光大呢?
① 在过去,双向流水线,意味着显存要加载双份模型的参数,这个成本太高了,显存X2。
② 但是现如今大参数的MOE模型,其模型专家是稀疏的,并且可以通过加大专家并行规模来进一步缓解显存消耗(即每个GPU放更少专家,增加集群的规模)。这就导致在今天特别针对大参数量的MOE模型时,其显存成本并非2倍,而只是1倍多
具体数据我没找到,DeepSeek-V3论文中的原文是:”尽管DualPipe要求保留模型参数的两个副本,但由于我们在训练期间使用了较大的EP大小,因此这并没有显著增加内存消耗”
③ 如果仅仅是显存开支不大,也不是决定性因素。更重要的是Moe架构需要进行的全对全通信(前面DeepEP项目中提到)。这个全对全通信恰好可以让模型训练在进行后向传播(更新权重)时,把另一个Moe的全对全通信(Dispatch或者combine)给做了,从而实现近乎1:1的计算-通信全覆盖。
本部分参考内容来自知乎Fazzie
但是Dualpipe注定只能成为大玩家的工具。
① 只有在训练期间,才需要做backward(后向传播),才能有空余精力去做全对全通信,从而实现计算-通信全覆盖。
② 只有大参数、MOE架构的模型,才配得上用这个方法,所有单机/少量卡能训的模型,非MOE架构的模型,都不适用。
所以这个项目的issue只有可怜的三个,实在是受众太少了。
EPLB
EPLB(Expert Parallelism Load Balancer),专家并行负载均衡器。这个内容也在V3论文中有提及。
大概原理是:在多级多卡条件下,每个GPU会托管不同的MOE专家,但可能有一些专家总是被访问(例如deepseek Moe方案中独特的共享专家)。
于是Deepseek就给这些劳累的专家做一下克隆,准备多一个备份放到同个机器上备用,称之为冗余专家。
在预填充阶段,他们会将专家平均分配到每个机器上(一个服务器8张GPU)。然后将复制的冗余专家平均分配给每个GPU。以V3为例,最后每个GPU托管8个专家+1个冗余专家。
在解码阶段,由于内存的高要求,部署的最小单元从32个GPU,变为320个GPU,从而每个GPU只托管一个专家,其中64个GPU托管冗余专家和共享专家。
其实这个项目我不是很感兴趣,有点乏味了。唯一有趣的点在于,在V3论文中,他们提及正在尝试动态冗余专家方案,例如每个GPU托管16个专家,但只激活9个。
如果这个尝试能够成功,成本应该会进一步下降。
总结
专用于大参数、Moe架构的训练流水线设计,能够显著减少大型玩家的训练成本,但对于小玩家训练成本或推理成本而言没有帮助。
DAY5 3FS文件系统地址:https://github.com/deepseek-ai/3FS,7.8Kstars
术语
Fire-Flyer File System (3FS)
这是一个专用于大模型场景的分布式文件系统,我们先拿U盘举例子,搞明白文件系统是什么。
我之前买过一个1T的固态硬盘,结果发现插到MAC上识别不了。百度一下才发现原来U盘用的是Windows特有的NTFS格式,而MAC只支持FAT32等,就是不支持NTFS。这里的NTFS,FAT32就是文件系统对应的文件格式。
每个文件系统都有自己进行读、写操作的方法,不同的平台也会有不同的文件系统。
而比起我们日常用电脑的场景,现代大数据会有进一步的奇葩的要求:要求极大吞吐,例如PB级别的内容,要求高频操作,例如1S内读写10000次。所以就产生了如HDFS, Lustre这种针对分布式场景的文件系统。
而DeepSeek的3FS,是对如HDFS这类分布式文件系统的再升级,专门定制以用于大模型训练推理。
DRAM、VRAM、SSD
DRAM就是CPU的内存,VRAM是显卡的内存,SSD可以理解为硬盘
这三者的价格,我给一个不精准的数字:
① VRAM: 4090显卡 24G 18000元,H100显卡 80G 25万元;
② DRAM: 32G DRAM,320元
③ SSD: 1T 300元
很显然,显存最贵,内存其次,SSD(硬盘)便宜如土。
项目特点
① 有助于预训练的一些改进
DeepSeek实测在180节点集群中吞吐6.6TiB/s,25节点集群中吞吐3.66TiB/min。我不了解传统分布式文件系统如HDFS在同等规模节点的性能表现如何(因为DeepSeek没做对比,我也找不到资料)。
但从社区的反馈来看,这个结果非常棒,甚至认为建立了大模型训练文件系统的新标准。
② 我更感兴趣的是推理成本的改进!
我们先了解一个概念叫KVCache。例如你进行了一个20轮的上下文对话,或者有很多人预置了Prompt模板
那么这部分输入是可以重复利用的,只需要把他先存起来,就可以节约每次重复计算的成本。大概的示例可以看下面这张图
在过去,这部分KV缓存一般会放在内存或显存中,而DeepSeek通过几个方法的结合将他放到了SSD。
Deepseek依靠的方法:
① 基于MLA注意力机制,可以将KV缓存压缩为低秩数据,从而降低93.3%的内存占用(来自DeepSeek-V2论文数据)
② 而收益于MLA带来的内存空间减少,使得KV缓存可以利用本项目的3FS实现在SSD上的高速读取,吞吐速度为50GB/s
在3月1日DeepSeek公布的推理成本说明中,实际上服务部署运行中KV缓存的命中率为56.3%。也就是有将近一半的KV缓存成本,可以实现90%+的降本。
总结
3FS是一个专门针对大语言模型模型训练&推理所开发的文件系统。其性能提升有助于训练提速
但基于3FS+KVCache所带来的推理成本降低对我来说更有趣。
有趣的点
网友查看开源的3FS文件,发现他最早的开发时间是2014年5月。
但是…2014年幻方还没成立呢。
按照网上检索的信息,2008年到2014年间,梁文锋通过自己的量化算法,实现亿万身家。2015年幻方才成立,2016年幻方才上线第一个完全基于深度学习的量化模型。2019年幻方的深度学习平台萤火一号才上线。
所以,这行14年的代码不会是梁文锋亲自写的吧?
我又找出来一篇我漏掉的DeepSeek论文,关于3FS的,论文标题为:Fire-Flyer AI-HPC: A Cost-Effective Software-Hardware Co-Design for Deep Learning,其中梁文锋真的在作者清单里。
2014年5月,我的朋友们,你们在做什么呢?
我当时应该在大学宿舍里打英雄联盟。
这个事情的玄幻程度就像1644年崇祯上吊,而同时期英国爆发了资产阶级革命(摊手.jpg)。
3月1日 Deep推理成本公布地址:https://zhuanlan.zhihu.com/p/27181462601(官方中文版!五星好评)
这篇内容我就不解读了,是前述多个项目的整合说明版本,对大模型推理成本感兴趣的可以自己去看一下。
重点说说很多媒体无脑转发的成本收益率545%,其实是存在一些偏差的(DeepSeek自己也有说明):
① 整个计算混合了V3和R1两个模型,而V3价格比R1价格要低,但最终按R1计算收入,所以偏高。
② 把免费服务和降价的夜间服务都按满额费用计算了,所以也偏高了。
来源:人人都是产品经理