DeepSeek 开源基础设施全景¶

更新日期：2026-04-16

2025.02.24-28，DeepSeek 在 Open Source Week 连续开源了 5 个生产级基础设施项目。这些不是"demo"——它们是 DeepSeek-V3/R1 实际训练和推理的核心组件。合计 50K+ GitHub stars。

理解这 5 个项目 = 理解 DeepSeek 如何用 $5.5M 训出 671B 模型。每个项目解决一个具体的工程瓶颈。

一、全景：每个项目解决什么问题¶

飞书 add-on（待手动转 mermaid / 图）

component: blk_631fefbbae02400430b8f9f4

项目	解决的问题	核心指标	GitHub
FlashMLA	MLA decode 的 KV Cache 效率	3000 GB/s 带宽、580 TFLOPS	deepseek-ai/FlashMLA
DeepEP	MoE 的 All-to-All 通信	153 GB/s NVLink、163μs 延迟	deepseek-ai/DeepEP
DeepGEMM	FP8 矩阵乘法	1550 TFLOPS (H800)	deepseek-ai/DeepGEMM
DualPipe	流水线并行气泡	消除 75% 气泡、93% GPU 利用率	deepseek-ai/DualPipe
EPLB	MoE 专家负载均衡	动态 expert cloning	deepseek-ai/EPLB
3FS	大规模数据 IO	6.6 TiB/s 读取、省 $2.8M/月	deepseek-ai/3FS

二、DeepGEMM：FP8 矩阵乘法的极致¶

2.1 为什么需要它¶

矩阵乘法占 LLM 训练/推理计算的 >90%。H100 的 FP8 Tensor Core 理论 4000 TFLOPS，但 cuBLAS 的 FP8 GEMM 在实际的 MoE 形状下远达不到。DeepGEMM 专门为 DeepSeek-V3 的矩阵形状优化。

2.2 核心设计¶

2.3 关键技术：FP8 的精度问题¶

FP8 Tensor Core 的累加器精度有限。连续做很多 FP8 乘加后误差会累积。 DeepGEMM 的解法：两级累加（promotion）。

内循环用 FP8 Tensor Core 做乘加（快），但每隔 N 步把中间结果"提升"到 FP32 CUDA Core 上累加（准）。这样既利用了 FP8 的速度，又避免了精度崩坏。

# 概念伪代码（简化，实际是 CUDA kernel）
def fp8_gemm_with_promotion(A_fp8, B_fp8, scale_A, scale_B):
    acc_fp32 = zeros(M, N)  # FP32 累加器

    for k_block in range(0, K, BLOCK_K):
        # FP8 Tensor Core 乘法 (极快)
        partial = tensor_core_mma(
            A_fp8[:, k_block:k_block+BLOCK_K],
            B_fp8[k_block:k_block+BLOCK_K, :])

        # 每隔几个 k_block 做一次 FP32 promotion (修正精度)
        if k_block % PROMOTION_INTERVAL == 0:
            acc_fp32 += partial.float()  scale_A  scale_B
            partial = zeros(...)

    return acc_fp32

2.4 性能¶

1550 TFLOPS 是 H800 的 BF16 理论峰值（990 TFLOPS）的 1.56 倍——因为 FP8 Tensor Core 算力是 BF16 的 2 倍（理论 ~2000 TFLOPS），DeepGEMM 达到了理论的 ~78%。

三、DeepEP：MoE 通信的"血管系统"¶

3.1 为什么需要它¶

MoE 的 EP（Expert Parallelism）需要 All-to-All 通信：每个 GPU 上的 token 要发到对应专家所在的 GPU。这是 MoE 训练和推理的主要通信瓶颈。NCCL 的通用 All-to-All 对 MoE 的 token routing 模式优化不足。

3.2 两类 kernel¶

为什么两种？训练时 batch 大，关心的是单位时间传多少数据（带宽）。推理 decode 时 batch 小甚至 batch=1，关心的是一个 token 多快能到专家那里（延迟）。

3.3 核心技术¶

NVLink → RDMA 桥接

问题：H800 节点内 GPU 之间有 NVLink（高带宽），但跨节点只有 InfiniBand RDMA。某些 token 需要从 GPU0 出发，经 NVLink 到 GPU4（因为 GPU4 有 RDMA 网卡），再经 RDMA 到远端。 DeepEP 自动优化这个"跨域转发"路径，根据 token 分布选择最优中转 GPU。

Hook-based 通信计算重叠

关键创新：通信不占用 SM（Streaming Multiprocessor）资源！传统方式：通信和计算抢 SM → 互相拖慢。DeepEP 用 hook 机制让 RDMA 传输在后台进行（通过 NIC 的 DMA 引擎），SM 完全留给计算。

实现"双 batch 重叠"：处理 batch N 的计算时，同时传输 batch N+1 的数据。

3.4 性能¶

3.5 FP8 支持¶

DeepSeek-V3 的 EP 通信策略：dispatch 用 FP8，combine 用 BF16。 dispatch（发 token 给专家）：精度不那么关键，用 FP8 省一半带宽。combine（收专家结果）：影响最终输出质量，用 BF16 保精度。

四、FlashMLA：DeepSeek 推理的核心 kernel¶

4.1 为什么需要专门的 MLA kernel¶

MLA（Multi-head Latent Attention）的 KV Cache 是压缩的——不是标准的 K、V 矩阵，而是低维潜向量 $c_{kv}$。推理时需要从 $c_{kv}$ 即时恢复 K 和 V 再做注意力。标准 FlashAttention 不支持这种操作。

4.2 性能¶

FlashMLA 是 DeepSeek 推理速度的关键——MLA 的 KV Cache 比标准 MHA 小 57x，但需要专门的 kernel 才能高效利用这个优势。

五、DualPipe：消除流水线气泡¶

5.1 问题¶

标准 1F1B 流水线并行有 warmup 和 cooldown 气泡——流水线前几步只有部分 GPU 在工作，最后几步也是。气泡占比约 $(PP-1)/\text{total\_microbatches}$。

5.2 DualPipe 的解法¶

双向流水线：同时从两端开始，一端做前向、另一端做反向。

flowchart LR
    subgraph standard["1F1B (标准)"]
        s1["Stage 1<br/>F→B 顺序"] --> s2["Stage 2"] --> s3["Stage 3"] --> bubble1["bubble<br/>(P-1)/M"]
    end
    subgraph dual["DualPipe (V3)"]
        d1["Stage 1<br/>双向同时"] --> d2["Stage 2"] --> d3["Stage 3"] --> nobubble["bubble ≈ 0"]
    end

    classDef stage fill:#fff,stroke:#cc785c,color:#1a1a1a;
    classDef bubble fill:#f5f3eb,stroke:#cc785c,color:#1a1a1a;
    class s1,s2,s3,d1,d2,d3 stage
    class bubble1,nobubble bubble

DualPipe 让两条数据流（forward / backward）"对穿"，每个 GPU 在任意时刻同时处理两个 micro-batch（一个 forward 一个 backward），通信和计算精心交错完全重叠。

5.3 效果¶

六、EPLB：MoE 推理的动态负载均衡¶

6.1 问题¶

推理时不同 batch 的 token routing 不同 → 某些专家突然过载、某些闲置。训练时的 Aux-Loss-Free 均衡对推理不适用（推理没有 bias 更新循环）。

6.2 解法：动态专家克隆¶

过载专家 → 临时克隆到空闲 GPU → 均衡负载。

# EPLB 概念
def rebalance(expert_loads, expert_replicas):
    for expert_id in range(n_experts):
        if expert_loads[expert_id] > 1.5 * average_load:
            # 找到最空闲的 GPU
            idle_gpu = find_least_loaded_gpu()
            # 克隆过载专家到空闲 GPU
            clone_expert(expert_id, to=idle_gpu)
        elif expert_loads[expert_id] < 0.3 * average_load:
            # 移除多余的副本
            remove_replica(expert_id)

6.3 和训练时负载均衡的区别¶

七、3FS (Fire-Flyer File System)：AI 的"血液循环"¶

7.1 问题¶

万卡训练的数据 IO 是隐藏瓶颈。TB 级数据集从磁盘读到 GPU 的带宽不够 → DataLoader 成为瓶颈 → GPU 等数据 → MFU 下降。传统文件系统（NFS/Lustre）不是为 AI 训练设计的。

7.2 核心指标¶

7.3 用途¶

训练数据加载：TB 级 .bin/.idx 文件的高速读取
Checkpoint：万卡 checkpoint 的快速写入/恢复
KV Cache 持久化：推理时把 KV Cache 缓存到 SSD（比 DRAM 便宜 10x）
数据预处理：大规模数据清洗流水线的 IO

八、这些项目如何串联在一起¶

flowchart LR
    data["3FS<br/>(数据加载)"]
    deepgemm["DeepGEMM<br/>(FP8 matmul)"]
    deepep["DeepEP<br/>(MoE all-to-all)"]
    dualpipe["DualPipe<br/>(pipeline)"]
    eplb["EPLB<br/>(推理负载)"]
    flashmla["FlashMLA<br/>(推理 attention)"]

    data --> deepgemm
    deepgemm --> deepep
    deepep --> dualpipe
    dualpipe --> flashmla
    flashmla --> eplb

    classDef stage fill:#fff,stroke:#cc785c,color:#1a1a1a;
    class data,deepgemm,deepep,dualpipe,eplb,flashmla stage

阶段	组件	解决的问题
数据	3FS	TB 级数据 IO
计算	DeepGEMM	FP8 矩阵乘
MoE	DeepEP	跨节点 all-to-all
流水	DualPipe	pipeline bubble
推理	FlashMLA	KV Cache 极致压缩
部署	EPLB	MoE 动态负载

这不是 5 个独立工具，而是一套完整的训练/推理基础设施栈。每个环节都被优化到接近硬件极限。

九、我能用这些吗？¶

这些项目都是为 DeepSeek 的特定架构（MoE + MLA）优化的。如果你训 Dense 模型，DeepGEMM 和 FlashMLA 仍然有用，但 DeepEP 和 EPLB 不需要。

十、追问¶

问题	方向
为什么 DeepGEMM 不用 CUTLASS？	CUTLASS 模板太重，针对特定形状手写 kernel 更优
DeepEP 和 NCCL 的 All-to-All 比怎样？	DeepEP 专门优化了 MoE 的 token routing 模式，NCCL 是通用方案
DualPipe 和 Zero Bubble PP 什么关系？	两者都消除气泡，但方法不同：DualPipe 双向，Zero Bubble 拆分反向传播
3FS 在非 DeepSeek 集群能用吗？	可以，但需要高端 NVMe SSD 集群
FlashMLA 和 TileLang FlashMLA 什么关系？	TileLang 是用高级 DSL 重写的版本，性能接近原始 CUDA

参考文献¶

[1] DeepGEMM. GitHub
[2] DeepEP. GitHub | 官网
[3] FlashMLA. GitHub
[4] DualPipe. GitHub
[5] EPLB. GitHub
[6] 3FS (Fire-Flyer File System). GitHub
[7] DeepSeek Open Source Week Overview. Index
[8] DeepSeek-V3 Technical Report. 论文
[9] Microsoft. DeepEP on Azure. 博客
[10] LMSYS. DeepSeek PD Disaggregation with EP. 博客

↑ 上级 · C. 分布式训练基础设施