DeepSeek Open Infra Index：国产 AI 基础设施的「硬核开源」样本

开篇：一个「车库团队」的宣言

2025 年 2 月 24 日，DeepSeek 在 GitHub 上发起了一个名为 Open Source Week 的活动——连续 5 天，每天开源一个仓库。这不是什么精心策划的「开发者大会」，而是一支自称「tiny team」的团队，用他们自己的话说：「没有象牙塔，只有纯粹的车库极客精神。」

这个仓库叫 open-infra-index，是 DeepSeek 内部推理/训练基础设施工具的「索引页」。它本身不是一个可部署的应用，而是一个目录和文档入口，指向 FlashMLA、DeepEP、DeepGEMM、DualPipe、EPLB 等在内的一系列经过生产环境验证的内核级工具。截至 2025 年中，这些子项目累计获得超过 3 万 Star，已经成为全球 AI 基础设施领域最受关注的开源工具集之一。

为什么这些工具值得关注

理解 DeepSeek 开源的背景，才能理解这些工具的真正价值。

DeepSeek-V3 和 R1 的核心创新之一，是大规模采用 MoE（Mixture of Experts）架构——V3 有 256 个专家，每层只激活 8 个。这意味着推理时：

• 显存压力大：虽然每次只激活 8 个专家，但所有专家仍然需要常驻显存
• 通信成本高：跨节点路由专家需要极低的延迟
• 计算不均衡：不同专家被激活的概率不同，容易造成 GPU 负载倾斜

传统的训练/推理框架在这些场景下「力不从心」。DeepSeek 选择从底层内核入手，逐个解决上述问题。他们的做法不是「造一个新框架」，而是在内核层面优化，让现有框架（PyTorch、vLLM）跑得更快。

核心子项目解析

FlashMLA：Hopper GPU 的 MLA 解码加速

MLA（Multi-head Latent Attention） 是 DeepSeek-V2 引入的注意力机制创新，相比标准 MHA，MLA 通过低秩投影显著压缩了 KV cache 体积。FlashMLA 的核心贡献是：

• 分页 KV cache：块大小 64，适配 vLLM 的 PagedAttention 机制，大幅减少显存碎片
• 内存带宽优化：实测内存带宽 3000 GB/s（H800），BF16 算力 580 TFLOPS
• BF16 支持：兼顾精度与性能

FlashMLA 的本质是给 Hopper 的 Tensor Core 做「手工打磨」——不是用通用 CUDA 代码，而是直接写 PTX 汇编级别的手工优化。对于普通开发者，这意味着集成到 vLLM 后，DeepSeek 系列模型的推理速度会有明显提升。

DeepEP：MoE 时代的跨节点通信库

MoE 的 all-to-all 通信（每个专家需要接收来自所有节点的 token）是性能瓶颈之一。DeepEP 的解决方案：

• NVLink 节点内优化：节点内 8 卡 NVLink 带宽接近显存速度
• RDMA 节点间通信：跨节点使用 RoCEv2/Infiniband，延迟低至微秒级
• 双模式支持：训练 Prefill（高吞吐）与推理 Decode（低延迟）各有专用 kernel
• FP8 原生：通信数据使用 FP8 量化，传输量减少 50%

DeepEP 是目前唯一同时覆盖 MoE 训练和推理全流程的开源 EP 通信库。在此之前，厂商通常只开源训练版或推理版，DeepEP 填补了这个空白。

DeepGEMM：300 行的 FP8 矩阵乘「教科书」

DeepGEMM 最令人惊讶的不是它的性能数字（Hopper FP8 1350+ TFLOPS），而是它的代码量——核心逻辑只有 ~300 行。

这背后的设计哲学是 「JIT 编译」：不是在编译时生成 kernel，而是在运行时根据实际矩阵形状动态生成最优指令。相比 CUTLASS 等专家手动调优的库，DeepGEMM 用更少的代码实现了更广泛的覆盖——它能自动适配 Dense 和两种 MoE GEMM 布局，无需为每个形状写专门的 kernel。

DeepGEMM 的价值不仅是性能，更是一种教学价值——它让研究者和工程师能看懂「顶级优化是怎么做的」。

DualPipe 与 EPLB：分布式训练的「最后一块拼图」

大规模 MoE 训练面临的两大问题：流水线气泡（bubble）和专家负载不均，DualPipe 和 EPLB 分别解决：

• DualPipe：双向流水线，让前向和反向同时进行，气泡率接近 0
• EPLB：基于预测的负载均衡器，根据激活频率动态分配专家到 GPU，减少 GPU 空闲等待

两者配合，使得 DeepSeek-V3 能在数千卡规模下高效训练，是 V3 能够在 2048 卡 H800 集群上完成训练的关键基础设施。

DeepSeek-V3/R1 推理系统白皮书

这是整个仓库中最「重磅」的技术文档，详细描述了 V3/R1 在生产环境中的推理系统设计：

• Prefill-Decode 分离架构：Prefill 和 Decode 使用不同的并行策略（EP32 vs EP144）
• 跨节点 EP144：Decode 阶段 18 节点 × 8 GPU = 144 experts 并行，单 GPU 显存压力大幅降低
• 通信计算重叠：通过 DualPipe 风格的 overlap 机制，隐藏 RDMA 通信延迟

这份白皮书是目前公开资料中，对大规模 MoE 推理系统设计描述最详细的文献之一，ISCA 2025 已接收发表。

技术架构总览

DeepSeek open-infra-index 的整体架构可以概括为三层：

层级	代表项目	作用
计算层	FlashMLA, DeepGEMM	GPU 内核级优化
通信层	DeepEP	多节点 NVLink/RDMA 通信
编排层	DualPipe, EPLB	分布式并行策略

三层相互配合，构成了从单卡内核到多卡集群的完整优化链路。这种分层设计的好处是：每个模块都可以独立使用，不强制要求同时部署。

上手门槛：谁能用？

这是最需要坦诚的部分。DeepSeek open-infra-index 的目标用户是AI 基础设施工程师和研究员，而非普通应用开发者。

• FlashMLA：需要 CUDA 编程基础，适合集成到 vLLM 或自己修改 attention kernel 的团队
• DeepEP / DeepGEMM：需要 NCCL、CUDA 知识，建议有分布式训练经验
• DualPipe / EPLB：需要 PyTorch 分布式训练经验，理解流水线并行原理
• 推理系统白皮书：纯文档，无代码，适合架构设计人员参考

对于只是想「跑一个 DeepSeek 模型」的开发者，更好的选择是直接用 vLLM（已集成 FlashMLA）或 Hugging Face Transformers，不需要直接接触这些内核库。

部署与硬件需求

项目	硬件要求	部署方式
FlashMLA	Hopper (H100/H800)，BF16 支持	编译集成到 vLLM
DeepGEMM	Hopper (H100/H800)，FP8 支持	编译集成
DeepEP	多节点 + RDMA/IB 网络	MPI/NCCL 启动
DualPipe	多节点 GPU 集群	PyTorch DDP/FSDP

最小需求：单卡 Hopper 可编译测试 FlashMLA/DeepGEMM；但真正发挥价值需要多卡集群环境。

行业意义与局限

意义：

1. 打破了「大厂闭源」的惯例：DeepSeek 的选择是将生产验证的内核开源，而非只发论文
2. 推动 MoE 基础设施民主化：让学术团队和中小企业也能接触到顶级推理/训练优化技术
3. 生态建设：这些工具与 PyTorch、vLLM 深度集成，不另起炉灶，易于采用

局限：

1. Hopper only：目前所有工具均针对 NVIDIA Hopper 架构优化，AMD/国产 GPU 用户无法直接使用
2. 深度定制依赖：DeepEP 与 DeepSeek 内部集群环境紧耦合，迁移到其他集群需要调整
3. 文档深度不足：部分子项目缺乏使用示例和性能调优指南，新人上手有一定门槛
4. 维护资源有限：DeepSeek 团队规模小，长期维护和社区支持能力存疑

结语

DeepSeek open-infra-index 代表了一种新的开源策略——不是开源一个「产品」，而是开源「造产品的方法」。这些工具的核心价值不在于「拿来就能用」，而在于让整个 AI 基础设施生态向前推进。

对于 GPU 编程研究员，这些是难得一见的、生产级别的优化案例。对于 AI 工程师，这些是提升模型训练/推理效率的加速器。对于整个行业，这些开源项目正在证明：最前沿的 AI 基础设施，不一定要掌握在大公司手中。

相关链接： GitHub 仓库 | FlashMLA | DeepEP | DeepGEMM | ISCA 2025 Paper