deepseek开源一周资料整理笔记

nightli小记
26 阅读10分钟

deepseek开源一周资料整理笔记

对比openai 开源直播的12弹，本周deepseek发布的5次开源，但相对于用户来说，这次开源的能力更多的是给企业们使用，特别是开源one more thing 的第六弹开源，对于后面应用侧的会产生巨大影响 下面的整理主要来自deepseek官方,陈魏博士的知乎文档 github

1. FlashMLA

项目地址：github.com/deepseek-ai… FlashMLA 是适用于 Hopper GPU 的高效 MLA 解码内核，针对可变长度序列服务进行了优化。

FlashMLA借鉴FlashAttention分块Tiling 和显存优化的思想。通过以算代存减少对于显存带宽的要求，提升计算性能。FlashMLA的构建基于Cutlass和CUDA体系。 FlashMLA 主要用于大模型推断/推理（Inference），特别是在需要处理长序列的场景中，如聊天机器人或代码生成工具。通过优化GPU利用率，解决大模型在推理阶段的显存瓶颈问题。 FLashMLA 解析 文章

2. 开源MoE训练、推理EP通信库DeepEP

项目链接：github.com/deepseek-ai…

此次开源的 DeepEP 做到了：

  1. 高效优化的 All-to-All 通信
  1. 支持 NVLink 和 RDMA 的节点内 / 跨节点通信
  2. 训练及推理预填充阶段的高吞吐量计算核心
  3. 推理解码阶段的低延迟计算核心
  4. 原生支持 FP8 数据分发
  5. 灵活控制 GPU 资源，实现计算与通信的高效重叠 高效通信减少了数据传输的瓶颈，计算核心的优化提升了处理速度，灵活的资源调度让计算和通信不互相等待。

3. DeepGEMM

DeepGEMM，是一款支持密集型和专家混合（MoE）GEMM 的 FP8 GEMM 库，为 V3/R1 的训练和推理提供了支持，在 Hopper GPU 上可以达到 1350+ FP8 TFLOPS 的计算性能。 项目地址：github.com/deepseek-ai…

DeepGEMM主要特点包括：

  1. FP8 支持优化：DeepGEMM采用了 CUDA 核心两级累加。（换句话说这也是NV TensorCore的设计不足之处）FP8 是一种低比特浮点格式，能够在保持一定计算精度的同时大幅提升计算效率。FP8在大量累加时会累积出现随机误差。例如FP8 GEMM在英伟达H800 GPU上的累加精度保留14位左右，明显低于FP32累加精度。以K= 4096的两个随机矩阵的GEMM 运算为例，Tensor Core中的有限累加精度可导致最大相对误差接近 2%。DeepSeek将中间结果储存计算升级为FP32（32位浮点），实行高精度累加，然后再转换回 FP8，以降低大量微小误差累加带来的训练偏差。
  2. 支持分组GEMM：与 CUTLASS 中传统的分组 GEMM 不同，DeepGEMM 仅对 M 轴进行分组，而 N 和 K 可保持不变。（可专门针对 MoE 模型中的专家量身定制）
  3. 即时编译（Just-In-Time, JIT）：通过 JIT 技术，代码可以在运行时动态生成和优化，进一步提升性能和灵活性。这也是跟Cutlass的最大区别。
  4. 支持Hopper架构中的TMA加速：包括LHS、LHS 缩放因子和 RHS 矩阵的 TMA 负载，TMA 存储输出矩阵，TMA 多播（LHS 矩阵特有） 使用PTX指令进行性能优化：使用stmatrix PTX 指令。
  5. FFMA SASS 交错：DeepSeek深入分析了SASS编译结果，在FFMA/FADD中调整SASS指令，提高了细粒度 FP8 GEMM 的性能。（这一点很有趣，说明DeepSeek的编译/反编译团队做活儿很细，已然不是普通牛马）
  6. 高性能：在 Hopper GPU（例如H100）上，可达到 1350+ TFLOPS 的 FP8 计算性能，这表明DeepSeek针对Hopper进行了深度优化。（把英伟达编译团队该干的活儿干了）特别是对Dense模型的加速比MoE更明显。 仍在发展：DeepGEMM 在某些形状上的表现并不是很好。

4. DualPipe&EPLB

DualPipe 是由 DeepSeek-AI 团队开发的一种双向流水线并行通信算法，主要用于优化大模型（如 DeepSeek-V3/R1）的数据交互和训练效率。 DualPipe具有以下核心特点： 1）计算与通信重叠 DualPipe 的设计目标是最大化集群设备的计算性能，通过在前向传播（Forward）和后向传播（Backward）阶段实现计算与通信的完全重叠，显著减少传统流水线并行中的“气泡”（Pipeline Bubble，即空闲等待时间）。这对于需要跨节点协作的专家并行（Expert Parallelism）场景尤为重要。 2）双向调度 与传统的单向流水线并行不同，DualPipe 采用双向调度策略，从流水线的两端同时输入微批次（Micro-batches），充分利用硬件资源。这种方法在保持计算通信比例恒定的情况下，即使模型规模进一步扩大，也能维持接近零的通信开销。 3）高效扩展性 DualPipe 针对跨节点的混合专家模型（MoE）进行了优化，通过减少通信瓶颈，使得大规模分布式训练能够在相对有限的硬件资源（如 H800 GPU）上高效运行。 4）显存优化 DualPipe 将模型的最浅层（包括嵌入层）和最深层（包括输出层）部署在同一流水线级别（PP Rank），实现参数和梯度的物理共享，进一步提升内存效率。这种设计减少了高代价的张量并行（Tensor Parallelism）需求。

项目地址: github.com/deepseek-ai…

EPLB （Expert Parallelism Load Balancer，专家并行负载均衡器）则主要用于优化混合专家模型（MoE）的分布式部署，特别是在 DeepSeek-V3 和 DeepSeek-R1 等大规模语言模型的训练中。 EPLB具有如下核心特点： 1）负载均衡优化 EPLB 通过复制高负载专家（Redundant Experts Strategy）并对专家分配进行启发式调整，确保不同 GPU 之间的负载均衡。这种方法解决了专家并行中因专家负载不均导致的计算资源浪费问题。分层负载平衡策略也可用于预填充阶段，具有较小的专家并行规模。 2）跨节点通信优化 在 DeepSeek-V3 的技术报告中提到，EPLB 尝试将同一组的专家尽量分配到同一节点，减少跨节点的数据传输开销。这种分组限制路由（Group-Limited Expert Routing）策略显著提升了分布式训练的效率。 3）高效可扩展性 EPLB 支持灵活的专家复制和分配，能够适配不同规模的模型和硬件配置。例如，在一个包含 2 个节点、每个节点 4 个 GPU 的集群上，EPLB 可以动态规划16个个专家副本的分配。 4）开源与可重现性 EPLB 作为 DeepSeek 开源周的一部分发布，提供了一个易于复现的负载均衡方案，方便研究者和开发者在自己的 MoE 训练中应用。

项目地址:github.com/deepseek-ai…

-陈巍：DeepSeek 开源Day（4）DualPipe&EPLB深入分析（收录于：DeepSeek技术详解系列）

5. 3FS&smallpond

Fire-Flyer 文件系统 (3FS) 是一种高性能分布式文件系统，旨在应对 AI 训练和推理工作负载的挑战。它利用现代 SSD 和 RDMA 网络来提供共享存储层，从而简化分布式应用程序的开发。

3FS项目地址: github.com/deepseek-ai…

Smallpond定位为基于 3FS 和 DuckDB 构建，专注于 PB 级数据的快速处理。Smallpond定位为 AI 数据的辅助工具，能够无缝集成到 3FS 的存储生态中，支持数据清洗、转换和分析等任务。 smallpond项目地址：github.com/deepseek-ai…

6. deepseek 推理系统

deepseek 推理架构目标是尽可能提高吞吐量 主要做的事情：

  1. 大规模跨节点专家并行，Prefill和decode阶段的专家部署在不同的 gpu上达到并行目的
  2. 计算通信重叠：双 batch 重叠来掩盖通信开销，提高整体吞吐。 对于 prefill 阶段，两个 batch 的计算和通信交错进行，一个 batch 在进行计算的时候可以去掩盖另一个 batch 的通信开销； 对于 decode 阶段，不同阶段的执行时间有所差别，所以我们把 attention 部分拆成了两个 stage，共计 5 个 stage 的流水线来实现计算和通信的重叠。
  3. 尽可能地负载均衡
  • Prefill Load Balancer 核心问题：不同数据并行（DP）实例上的请求个数、长度不同，导致 core-attention 计算量、dispatch 发送量也不同 优化目标：各 GPU 的计算量尽量相同（core-attention 计算负载均衡）、输入的 token 数量也尽量相同（dispatch 发送量负载均衡），避免部分 GPU 处理时间过长
  • Decode Load Balancer 核心问题：不同数据并行（DP）实例上的请求数量、长度不同，导致 core-attention 计算量（与 KVCache 占用量相关）、dispatch 发送量不同 优化目标：各 GPU 的 KVCache 占用量尽量相同（core-attention 计算负载均衡）、请求数量尽量相同（dispatch 发送量负载均衡）
  • Expert-Parallel Load Balancer 核心问题：对于给定 MoE 模型，存在一些天然的高负载专家（expert），导致不同 GPU 的专家计算负载不均衡 优化目标：每个 GPU 上的专家计算量均衡（即最小化所有 GPU 的 dispatch 接收量的最大值）

最终达到效果 在 24 小时统计时段内，DeepSeek V3 和 R1：

输入 token 总数为 608B，其中 342B tokens（56.3%）命中 KVCache 硬盘缓存。 输出 token 总数为 168B。平均输出速率为 20~22 tps，平均每输出一个 token 的 KVCache 长度是 4989。 平均每台 H800 的吞吐量为：对于 prefill 任务，输入吞吐约 73.7k tokens/s（含缓存命中）；对于 decode 任务，输出吞吐约 14.8k tokens/s。

-DeepSeek-V3 / R1 推理系统概览

总结

这几个发布都是对于又大规模集群的玩家能的，对于小团队或者个人而言比较难，而且最低要求也是得又h800 的hopper GPU 而hopper GPU消费级显卡又没有，至少得等50系backwell架构GPU 再使用，对于个人做探索性的 会试着用 FlashMLA 和 DeepGEMM 这两个开源库，其中FlashMLA已经有社区在AMD ，摩尔线程，海光等GPU上做了适配。 deepseek在架构上的优化的确令人惊叹，这个推理系统架构是算法和工程高度的结合的产物，需要结合算法的特性 如多专家，多阶段等特性进行优化，然后再用工程上进行实现，如不同专家部署不同GPU，不同阶段部署不同GPU，还优化了通信和存储，deepseek内部的人真的强。

附录openai发布12弹

Day1 ：o1和o1 Pro发布
Day2：强化微调（Reinforcement Fine-Tuning）
Day3：sora发布
Day4：在画布上展现一切
Day5：chatGPT与苹果设备集成
Day6：实时视频中使用高级语音功能
Day7：在chatGPT中创建项目
Day8：ChatGPT Search升级
Day9：开发者的礼物，API升级
Day10：可以给chatGTP打电话了
Day11：chatGPT在Mac与其他APP协作完成任务
Day12：o3来了
引用

qrcode_for_gh_4f5df1890852_258.jpg

avatar
文章
阅读
粉丝