深度剖析DeepSeek Infra开源全貌-精准获客

阅读时，可先跳过各章节的“术语说明”，遇到看不懂的地方，再回头查阅。否则，没有上下文地硬啃术语会很难受。

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：它是DeepSeek开源的CUDA内核，借鉴了FlashAttention项目的一些理念，针对自研的MLA进行优化。通俗来讲，MLA是核心算法，FlashMLA则是让MLA在机器上更好运行的优化方法。
SM（Streaming Multiprocessor，流式多处理器）：是GPU上的计算单元，H800上有132个SM。
Wrap：是SM上线程调度的基本单位，可类比为流水线。GPU、SM、Wrap存在层级关系，DeepSeek很多精细化工作在Wrap层级开展。

项目特点

① Hopper专用

Hopper是英伟达的显卡系列，常见的有H800、H100。该项目只能在Hopper系列显卡上运行，在华为昇腾、英伟达A100等其他显卡上无法直接运行，原因后续会说明。

② 对KV缓存进行分块

每块大小为64。分块后，计算和内存效率大幅提升。这就好比仓库管理，若以订单为单位，订单货品数量差异大，会出现卡车装不满或装不下的情况，利用率低。若跟踪到每个SKU，虽管理成本增加，但整体物流仓管效率因细粒度而显著提高。此理念源自FlashAttention，并非DeepSeek独创。

③ 极致利用共享内存

共享内存访问速度快但容量小，英伟达Hopper系列每个SM上最大共享内存为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另一半的计算。记住Gemm这个概念，两天后的第三个项目会提及。

⑤ 动态输入序列的适配

实际场景中，输入序列长度不一，尤其是R1类推理模型或阅读理解类任务，输入序列较长。该项目采用双线程缓冲模式进行动态负载计算，短序列采用计算优先模式，长序列采用内存优先模式（细节需看代码，参考来自ZOMI酱的解说）。

总结

最终，在H800 SXM5显卡上，FlashMLA实现了内存带宽3000GB/S（上限3.2TB，利用率接近90%），计算浮点数580 TFLOPS的表现。DeepSeek通过KV分块、共享内存利用和精细化的Wrap设计，充分发挥了H800的性能。

有趣的点

有人已基于A100复现了FlashMLA，基于升腾、H20、V100等其他显卡的复现可能也在进行中。项目末尾有众多社区支持，国内芯片大多在列，海外芯片厂商仅有AMD。此外，知名推理框架vLLM已完成对FlashMLA的集成支持。这体现了开源的优势，MLA从DeepSeek独家的注意力机制变为热门方案，社区的创意方案又能反哺DeepSeek的研发。

DAY2 DeepEP

地址：https://github.com/deepseek-ai/DeepEP?tab=readme-ov-file，7.1K stars

术语说明

EP（expert parallelism），即专家并行性。大参数的Moe模型需部署在多机多卡上，训练或推理时，要将输入的Token分发给各个专家处理，处理完后再合并。但专家分布在多个GPU上，这就是专家并行性。

全对全通信（ALL to ALL）和点对点通信（P2P）是计算机通信的两种概念。如图，某张卡的数据要发给4个分布在不同卡上的专家处理，这张卡需与4张卡进行4次通讯，以此类推，其他卡也如此，共产生4×4 = 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通信；NVshcmen将多节点的内存地址统一，可将多个节点的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。这两个场景都需要高吞吐量。而推理的解码阶段要求低延迟，以保证用户体验。为此，DeepSeek准备了两种CUDA内核方案：第一种，通过NVlink（160GB/s）+ RDMA网卡（50GB/s）结合，适配训练和推理预填充阶段；第二种，仅用RDMA网卡，满足推理解码阶段的低延迟需求（减少了NVlink到RDMA的转发）。

③ 原生支持FP8数据分发

随着DeepSeek的开源，FP8训练成为业内共识。这可能也是DeepSeek选择NVSHMEM手写通信的原因，因为NCCL对FP8精度的支持不足（参考英伟达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.9K stars

术语说明

GEMM（General Matrix Multiplication，通用矩阵乘法）：是大模型训练推理常用的计算方式，在门控路由、注意力分数计算、专家前馈网络、训练梯度反向更新等方面都会用到。GEMM操作占大模型推理计算量的70%以上，优化GEMM能提高计算效率。

项目特点

① 削履适足

过去GEMM有经典库英伟达的CUTLASS，但和DeepEP项目一样，CUTLASS过于通用，在业务适配方面未达极致。项目说明中提及了相对于CUTLASS的大量改进，这些改进叠加提升了DeepGEMM的性能。

② JIT设计

传统编译方式的执行代码固定，而JIT边运行边生成代码。生成过程中，可根据情况选择更好的内存分配、减少条件判断等，代码性能优于传统方式。

③ 支持非2次方的块

SM通常支持2的幂次方块大小，如256、128等，这会导致工作效率无法充分发挥。DeepGEMM支持非2幂次的块大小，优化特定形状的效率。例如，传统128分块，在M = 256，N = 7168时，(256 / 128) * (7168 / 128) = 112个块，H800有132个SM，利用率为112 / 132 = 84%；采用112分块，同样情况下(256 / 128) * (7168 / 112) = 128个分块结果，利用率为128 / 132 = 96%。

④ 针对最底层的SASS机器码动刀

之前提到CUDA/C++＞PTX＞SASS（机器码），DeepSeek在V3/R1论文中对PTX进行修改就引发关注，这里则直接对最底层的SASS二进制编码进行改进。他们发现NVCC在12.2和12.3之间，传统GEMM项目CUTLASS FP8的内核性能提升。经比对SASS二级制编码，发现FADD指令会周期性交错反转，怀疑该指令通过控制warp线程释放提高了效率。于是借鉴此思路，开发二进制脚本控制FFMA指令，某些情况下性能提升10%以上。虽不太理解具体指令，但能感受到研究人员的探索精神。

总结

针对大模型训练推理中计算资源占比最多的GEMM操作，DeepSeek进行了底层（甚至到机器码）的实现，以追求极致性能。在不同尺寸矩阵测试中，有媒体称“2.7倍提升”，但实际上在Dense（稠密）模型上是1.0倍 – 2.7倍，2.7倍是特殊场景。从M、N、K数据看，可能是低输入长度、低参数的模型。结合图来看，在连续布局（预填充）和掩码布局下基本有1.1X的提升，非常可观。