DeepSeek开源Infra全景地图：普通程序员该看懂什么

DeepSeek 的开源版图远不止模型权重。从 GPU 算子到通信库，从分布式文件系统到推理框架，它把支撑大模型运转的整套基础设施一层层摊开。但库太多、文档太散，普通程序员很难看清全貌。这篇内容基于 B 站 UP 主的梳理，结合多份公开资料交叉验证，尝试画一张不钻细节的完整地图：每个库解决什么问题，彼此怎么拼在一起，以及哪些思路能直接带走。

全景：把大模型当成一座工厂

理解这些库之前，先把大模型想象成一座工厂。最底层是算子，即 GPU 上每一道最基本的工序；往上是通信与并行，让成百上千张卡协同干活；再往上是存储，负责喂养数据、存放中间结果；最顶层是推理系统，把这一切变成对外的服务。

时间线上有两个节点值得记住。据 B 站 UP 主与 GitHub 项目页的交叉信息，DeepSeek^广告 曾办过为期一周的开源活动，每天放出一个库，此后这些库持续更新并新增了不少成员。另一个节点是 10 月 20 日，线上服务实际使用的推理框架 DeepInfer 被开源，采用宽松的 Apache 许可。

要看懂这些库，得先知道它们服务的模型长什么样。DeepSeek 用的是混合专家模型（MoE）：一层里有很多专家，每个词元只被路由到其中几个，所以总参数很大，单次真正参与计算的只是一小部分。这带来三个新问题——单个专家分到的词元少，要在 GPU 上跑满很难；专家分散在多张卡上，词元来回搬运让通信成为大头；有的专家忙有的闲，卡与卡之间还得负载均衡。后面几乎每个库，都对应这三件事之一。

混合专家模型（MoE） 是一种稀疏激活的模型架构。以 DeepSeek 的 MoE 为例，每个 Transformer 层里包含数十甚至上百个“专家”前馈网络，但每个词元只被一个轻量路由器（router）分配给其中少数几个专家（如 Top-2 或 Top-6）。因此模型总参数量可以做到极大，而单次前向传播真正参与计算的参数量却很小，推理成本大幅降低。代价是：专家分布在多张 GPU 上，词元需要跨卡路由，通信量激增；不同专家的负载天然不均，容易造成部分卡空转、部分卡过载。理解这一点，就能明白 DeepEP、EPLB、DualPipe 等库为何存在。

第一层：算子——把每一道工序做快

Flash MLA 解决的是 KV 缓存膨胀。大模型生成文字时要把此前每个词元的注意力中间结果存下来，这部分会吃掉大量显存。DeepSeek 用 MLA 先把它压缩成小向量再存，Flash MLA 就是专门高效读取这种压缩格式、并计算注意力的 GPU 算子。另一个麻烦是请求长短不一，按最大长度预留会浪费显存，Flash MLA 采用类似操作系统虚拟内存的分页管理，用多少给多少。

DeepGEMM 负责矩阵乘，这是大模型里最耗算力的工序。它用低精度 FP8 让同样的硬件算得更快，每块数值各带一个缩放系数，精度损失因此很小。内核在运行时才即时编译，对外只开放很少的核心函数，代码精简，适合阅读学习。针对 MoE，它还提供分组矩阵乘，把发给不同专家的词元分组排好一起算完；较新版本更进一步把分发、两层计算和合并融合成一个内核，称为 MegaMoE。

同层还有几个小而专的库：Tile Kernels 用 TileLang 这类更高层的语言写算子；DeepSelect 专做 TopK 选择；DeepJIT 是轻量即时编译库。据 UP 主与华为侧公开信息，DeepSeek 曾与华为合作把 TileLang 带到昇腾芯片上，于是也有了 DeepGEMM 和 DeepEP 的昇腾版本。

MLA（Multi-head Latent Attention，多头潜在注意力） 是 DeepSeek 提出的一种注意力变体，核心是把每个词元的 Key/Value 缓存先投影压缩成一个低维潜在向量再存储，推理时再解压还原。相比传统 MHA/GQA 需要为每个词元缓存完整的 K 和 V，MLA 的 KV 缓存体积可缩小到原来的几分之一，从而在相同显存下支持更长的上下文和更大的批处理。Flash MLA 则是针对这种压缩格式专门优化的 GPU 算子，它需要处理解压与注意力计算融合、分页读取等细节，通用注意力内核无法直接胜任。

第二层：通信与并行——让上千张卡不空转

MoE 每一层都要做一次全员对全员的数据交换：把词元送到对应专家所在的卡，算完再收回来。DeepEP 就是为此而写的通信库，同一台机器内走 NVLink，跨机器走 RDMA 网络，还支持用 FP8 传输以减少数据量。它有两种用法：训练和预填充追求高吞吐，解码时每次只有一个词元、追求低延迟。最新第二版把两者合并到一个接口，占用的计算单元也更少——通信少占一块算力，就能多留一块给计算。

光有通信库不够，通信时 GPU 不能闲着。DualPipe 是一种流水线并行调度：把层切成几段放在不同卡上，让两个方向的微批次同时从两头进入，并把一块的计算与另一块的通信错开重叠，大幅压缩“气泡”（空转时间）。

负载均衡方面，EPLB 的思路是把热门专家复制几份，再把所有副本尽量平均地装到各张卡上；预填充和解码策略不同，前者按机器分层，后者全局统一规划。此外还有两个早期项目：LPLB 用线性规划动态调整负载；Profile-Data 公开真实训练与推理的性能剖析数据，能直接看到计算和通信如何重叠。

NVLink 与 RDMA 是两类不同层级的互联技术。NVLink 是英伟达 GPU 之间的高带宽直连总线，同一台服务器内的多张 GPU 可通过 NVLink 交换数据，带宽远高于走 PCIe。RDMA（远程直接内存访问）则用于跨服务器通信，允许一台机器直接读写另一台机器的内存，绕过操作系统内核，延迟极低，常用于 InfiniBand 或 RoCE 网络。DeepEP 正是据此分层设计：机内走 NVLink，机间走 RDMA，从而在 MoE 的全员对全员通信中尽量压榨带宽、降低延迟。

第三层：存储——让整个集群像一块硬盘

训练要读海量数据，推理要存取缓存中间结果，普通文件系统满足不了。3FS 是 DeepSeek 的分布式文件系统，建立在 SSD 和 RDMA 网络之上，让整个集群的硬盘像一块高速大硬盘。它用链式复制写入，数据沿一条链从头传到尾，读取却可以从链上任何一个副本读，读压力被均匀摊开；文件切成小块分散到多条链上。3FS 有四类用途：数据预处理、训练时读数据、保存检查点、推理时的 KV 缓存。SmallPond 则建在 3FS 之上，是轻量数据处理框架，让人用熟悉的方式处理大规模数据。

顶层：推理系统——把一切组装成服务

DeepSeek 公开的推理做法核心是两点：把预填充和解码分开部署，因为前者吃算力、后者吃显存带宽；用大规模专家并行让每张卡只放少数专家，省出显存装更大的批次。官方还公开过一份成本推算：每个 H800 节点每秒约处理 73000 个输入词元或 14800 个输出词元，若所有流量按最贵价格计费，理论利润率约 545%——官方也强调这只是理论值。

10 月 20 日开源的 DeepInfer，最初基于 vLLM 改造，集成了前述内核，支持英伟达新一代 GPU 和华为昇腾，调度也做了优化。它有两个有意思的设计：推测解码先让小草稿模型一次猜出五个词元，再让大模型一次性验证，猜对就白赚；确定性模式保证同样输入每次输出逐位一致，方便调试复现。

需要如实说明边界：这次开源不是整个生产系统。KV 缓冲管理、跨机器的预填充与解码分离、副本间负载均衡这些与内部基础设施耦合很深的部分没有放出；目前只支持 V4.1 Flash 一个模型，且不支持 Hopper 及更早的显卡。

预填充（prefill）与解码（decode） 是大模型推理的两个阶段。预填充阶段一次性处理用户输入的整段提示词，所有词元可并行计算，属于算力密集型；解码阶段逐词生成输出，每步只处理一个新词元，但需要反复读取巨大的 KV 缓存和模型权重，属于显存带宽密集型。两者资源瓶颈截然不同，混在同一批处理里会互相拖累。因此 DeepSeek 采用分离部署：预填充集群专注算力，解码集群专注带宽，再配合大规模专家并行把每张卡上的专家数压到很少，腾出显存装更大批次，提升整体吞吐。

普通程序员能带走什么

能直接用的：内核库可单独安装、在 PyTorch 里调用；3FS 和 SmallPond 适合有大规模数据的团队；DeepInfer 适合在受支持的新显卡上部署 V4.1 Flash。但很多库要求 Hopper 或 Blackwell 显卡，普通显卡用不了。

更值得学的是思路：让计算和通信重叠；把长短不一的请求分页管理；低精度加细粒度缩放；用副本摊平热点；把两种性质不同的任务分开部署。这些写任何高并发系统时都用得上。最后一个建议是，别一上来就啃代码，先在这张地图上找到你的问题在哪一层，再去读对应那个库的说明。想继续深入，GitHub 上 DeepSeek 的开源组织页是最好的入口。