摘要：随着人工智能技术的飞速发展，大语言模型及相关应用正成为推动科技变革的核心力量。然而，背后支撑这些模型高效运行的基础设施（Infra）却鲜为人知。本文将深度解读DeepSeek开源周的内容，通过通俗易懂的语言，剖析DeepSeek在模型训练、推理优化以及基础设施

随着人工智能技术的飞速发展，大语言模型及相关应用正成为推动科技变革的核心力量。然而，背后支撑这些模型高效运行的基础设施（Infra）却鲜为人知。本文将深度解读DeepSeek开源周的内容，通过通俗易懂的语言，剖析DeepSeek在模型训练、推理优化以及基础设施建设方面的创新成果。

本篇内容是对DeepSeek Infra开源周内容的一次费曼学习结果

阅读前最好能看过前置内容《万字长文：DeepSeek 647天铸就的登神长阶》。否则虽然也能看懂，但会无法建立全局视野，摄入的知识产生折扣。

阅读的时候可以先跳过每个章节的“术语说明”，看不懂了，再回去翻术语说明。不然没有上下文硬啃术语是挺难受的。

地址：https://github.com/deepseek-ai/FlashMLA，11.2K stars

术语说明

项目特点

① 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的研发推进当中。

地址：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”

地址：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内 部正在讨论是否发布可用于预训练的相关内核。（相关信源）

https://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架构的训练流水线设计，能够显著减少大型玩家的训练成本，但对于小玩家训练成本或推理成本而言没有帮助。

地址：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）。

地址：https://zhuanlan.zhihu.com/p/27181462601（官方中文版！五星好评）

这篇内容我就不解读了，是前述多个项目的整合说明版本，对大模型推理成本感兴趣的可以自己去看一下。

重点说说很多媒体无脑转发的成本收益率545%，其实是存在一些偏差的（DeepSeek自己也有说明）：

① 整个计算混合了V3和R1两个模型，而V3价格比R1价格要低，但最终按R1计算收入，所以偏高。

② 把免费服务和降价的夜间服务都按满额费用计算了，所以也偏高了。

来源：人人都是产品经理