DeepSeek开源周 Day02：从DeepEP开源趋势重新审视大模型Infra

致Great

发布于 2025-02-26 08:12:10

1370

文章被收录于专栏：自然语言处理自然语言处理

DeepEP

今天DeepSeek开源周第二天，开放了DeepEP仓库，属实看了下源码，和昨天FlashMLA一样，C++权重（包括CUDA）还是占据了绝对部分，作为调包侠的我，看到之后望而却步，想看原理或者实现也是完全看不懂了！

DeepEP 是一个为混合专家 (MoE) 和专家并行 (EP) 量身定制的通信库。它提供高吞吐量和低延迟的全到全 GPU 内核，也称为 MoE 调度和组合。该库还支持低精度操作，包括 FP8。
Github地址：https://github.com/deepseek-ai/DeepEP

为了与DeepSeek-V3论文中提出的组限制门控算法保持一致，DeepEP 提供了一组针对非对称域带宽转发（例如将数据从 NVLink 域转发到 RDMA 域）进行优化的内核。这些内核提供高吞吐量，使其适合训练和推理预填充任务。此外，它们还支持 SM（流式多处理器）数量控制。

对于延迟敏感的推理解码，DeepEP 包含一组具有纯 RDMA 的低延迟内核，以最大限度地减少延迟。该库还引入了一种基于钩子的通信计算重叠方法，该方法不占用任何 SM 资源。

陌生词汇很多，感觉很陌生，下面咱们借英伟达博客稍微复习下FP8吧！

FP8介绍

浮点数值表示

如下图为 NVIDIA GPU 常见的浮点数表示方式，其中 sign 表示符号位，exponent 表示指数位（决定了动态范围），mantissa 表示尾数位（决定了表示精度）。

相比 FP32：

FP16的指数位和尾数位都更小。因此，通常 FP32 转 BF16 时会带来较大的精度损失。
BF16的指数位和 FP32 相同，尾数位更少。因此，通常 FP32 转 BF16 只需要做尾数位的截断，损失相对较小。现在的 LLM 预训练中通常都会使用 BF16。

相比 FP16：

FP8 E4M3 的指数位和尾数位都更小。因此，通常 FP16 转 FP8 E4M3 时会带来较大的精度损失。
FP8 E5M2 的指数位和 FP16 相同，尾数位更少。因此，通常 FP16 转 FP8 E5M2 只需要做尾数位的截断，损失相对较小。

需要说明的是，虽然都是 E5M2 或者 E4M3，不同公司的硬件可能采用不同的格式。比如 NVIDIA GPU 上的 E5M2 符合 IEEE 754 Style，而 E4M3 却不符合 IEEE 754 Style，本文中没有特殊说明都以 ARM-Intel-Nvidia Style 为例。如下图所示，IEEE 754 Style 的 E4M3 的范围为 [-240, 240]，而 ARM-Intel-Nvidia Style 的 E4M3 的范围是 [-448, 448]：

什么是FP8

来源：https://developer.nvidia.com/zh-cn/blog/fp8-challenges-best-practices/

在介绍 FP8 格式之前，我们需要回答一个问题：**为什么需要讨论 FP8？**从图中可以看出，近年来大模型所需的算力急剧增长，从 GPT-1 到 GPT-3，再到类似 GPT-4 的 GPT MOE 1.8T，算力需求增长了数万倍。这种增长速度的背后是硬件算力的提升。训练过程中的一个重要指标是训练时间。如果训练一个模型需要半年甚至一年，这在实际操作中是不可行的，因为实际训练时间可能是理论值的两到三倍。因此，算力基础设施的提升是大模型迅速发展的基础。

从算力角度来看，近年来 GPU 的单卡算力提升了大约一千倍，这包括工艺制程的改进、硬件结构的优化以及更低的训练精度。随着 FP8 的引入，其 Tensor Core 算力是 FP16 的两倍，为探索更大规模的模型提供了算力支持。

具体来说，FP8 的优势包括：

对于计算密集型算子，FP8 的 Tensor Core 相对于 BF16/FP16 能提供两倍的算力，从而大大缩短计算时间；
对于 Memory Bound 的算子，FP8 格式所需的数据量更少，可以节省缓存量，加快计算；
如果将通信算子中的数据类型也替换成 FP8，也可以获得一定的加速。
最后，FP8 训练的模型可以更好地与推理相结合，因为如果模型在训练时的精度是 FP8，那么可以更快地部署到推理侧，而不需要额外的 PTQ 量化过程。

FP8 数据格式包含两种：E5M2 和 E4M3。E 代表指数位，M 代表尾数位。E5M2 包含五个指数位和两个尾数位，而 E4M3 包含四个指数位和三个尾数位。E5M2 由于有更多的指数位，动态范围更大；E4M3 有更多的尾数位，数值精度更好。这两种数据格式在训练时都有各自的应用场景。

在大模型训练中使用FP8

FP8 带来了更快的训练速度，但也对训练精度提出了挑战。接下来将介绍在大模型训练中如何兼顾模型精度和训练速度。

在介绍 FP8 之前，我们先回顾一下 16 位精度训练中如何通过混合精度训练来维持精度。这里列出了四种混合精度训练的方法。

第一种和最后一种严格来说不算混合精度，因为第一种是纯 FP32 训练，精度最好；
最后一种是纯 16 位精度训练，速度最快。

为了兼顾速度和精度，我们列出了额外的两种模式：AMP-O1 和 AMP-O2。

AMP-O1 相对于 O0 的不同点在于它会维护一份白名单，白名单中的 OP 会以低精度进行计算，如矩阵乘法和卷积算法，其他算子仍用高精度计算和存储。
AMP-O2 方案与 AMP-O3 更接近，不同点在于它会保留一些 unsafe 的 OP，这些 OP 会以 FP32 精度进行存储和计算，如 LayerNorm 和 Softmax 等。

此外，还会保留一份 FP32 类型的 Master Weight，因为在模型训练后期，参数更新通常较慢，梯度值较小，容易出现大数加小数的问题，小数被吃掉，所以需要保留一份 FP32 的 Master Weight。目前 16 位精度训练基本上都是采用 AMP-O2 的混合精度方法来训练的。

FP8 训练可以认为是一种 O1+O2 的混合模式。上边这幅图包含了前向和反向计算过程中的一些算子。**红色连接线表示高精度数据，绿色连接线表示低精度数据。无论是前向还是反向，整体训练流程的精度仍然是 BF16 的，但会维护一份白名单，白名单中的 OP 以 FP8 精度计算，如 Linear Layer 中的矩阵乘法和 GELU。FP8 的 FMHA 目前在功能上是支持的，但在实际训练过程中通常还是用高精度的 FMHA，以保证更好的收敛性。**对于 FP8，我们看到它是以 O1 的模式嵌入 BF16 训练的，BF16 训练本身又是一个 O2 的混合精度方法，所以我们称它为一种 O1+O2 的混合精度模式。

在训练过程中，前向和反向采用了不同的数据精度。前向用 E4M3，因为前向时数值的动态范围变化不大，用 E4M3 提供更好的精度；反向的梯度需要更大的动态范围，所以反向用 E5M2 数据格式。这个流程图中，蓝色框表示从 BF16 到 FP8 的 Cast 过程。这个过程不像 FP32 到 BF16 那样简单直接。

要将 FP8 应用于 LLM 的训练和推理，其中的一个关键问题是如何克服表示范围和精度下降相关的挑战。其中的一个关键技术就是张量缩放（Tensor Scaling），如下图 Figure 9 所示（图片来自 [2310.18313] FP8-LM: Training FP8 Large Language Models），其核心是将不在 FP8 表示范围内的数据缩放到 FP8 的表示范围内。

早期在 V100 和 A100 GPU 上的 FP16 混合精度训练会广泛采用全局损失缩放技术（Global Loss Scaling），很适合一些中小模型的训练。然而，在处理一些超大模型或复杂任务时（例如 DALL-E 等模型），Global Loss Scaling 仍然会遇到严重的下溢问题（Underflow）。因此，越来越多采用 Block-wise 和 Layer-wise 的 Gradient 缩放。在 FP8 的 Per Tensor Scaling 技术中，有两种常见方案：Just-in-time Scaling 和 Delayed Scaling（NVIDIA 在 Transformer Engine 中也有实现 Using FP8 with Transformer Engine）。

Just-in-time Scaling（即时 Scaling）：要做 Tensor 的 Scaling，首先需要计算 Tensor 绝对值的最大值（amax），然后得到 Scaling 值，再对 Tensor 进行 Scaling。中间的临时存储都是高精度的，可能要多次读写，计算和访存开销很大；此外，如果是分布式场景，比如梯度的 AllReduce，还要涉及分布式通信开销。整体来说，额外引入的开销会大幅降低 FP8 带来的收益。
Delayed Scaling（延迟 Scaling）：其核心思路是使用额外的 Tensor 来存储之前的 amax 历史，然后根据历史最大值决定当前的最大值。

如下图为 NVIDIA Transformer Engine 中的 Delayed Scaling 实现方案，其 amax history 最多可以存储 1024 个 history。在进行当前 Tensor 的 Scaling 操作时，会使用当前 Tensor 之前的 amax history 来预测当前的 amax（比如之前 history 的最大值），然后进行 Scaling 操作；Scaling 操作的同时会计算当前的 amax，并更新 amax history（PS：不确定这里是分成了两个 Kernel 同时 Scaling 和计算 amax，还是融合为一个 Kernel）。

到这里已经看不懂了，更多想了解以及接触Infra的同学可以看看这篇文章：
FP8 训练的挑战及最佳实践，https://developer.nvidia.com/zh-cn/blog/fp8-challenges-best-practices/

关于大模型Infra思考

LLM Infra 简介

LLM Infra（大语言模型基础设施，LLM Infrastructure）是 LLM 实践和应用的底座。通过优化硬件、软件和网络架构，它能够提高大语言模型的训练和推理效率，推动自然语言处理技术的创新，并在搜索引擎、智能助手和自动化客户服务等领域广泛应用，为 AI 发展提供了强大的支持。

LLM AI Infra广义上包含了基础模型和基础软件栈两层，本篇报告核心关注其中和工作流相关的基础软件工具栈。工作流的视角下，LLM的开发应用主要涉及数据准备、模型训练、模型部署、产品整合四个主要环节，每个环节都有对应的点工具，亦有集大成的LLMOps平台型产品。

行业的 AI 工作流在传统 ML 模型阶段就已逐渐成型，这一领域由于整体的非标属性，很难出现统一的 MLOps 平台。而是主要分为从 0 到 1（离线数据准备+模型搭建）和从 1 到 100（模型上线和部署）两部分。随着 LLM 趋势的确定，从 1 到 100 的部分将成为之后重头的发展模块。LLMOps 的发展将为未来大模型的部署和推理提供重大的助推作用。

LLM Infra从业建议

在知乎看到一篇非常有意思的文章，分享给大家：

大模型Infra这些年，从黑铁时代到黄金时代再到白银时代
https://zhuanlan.zhihu.com/p/708594043

我们直接看建议，下面画了一些重点:

大家常说七年一个周期，2016年Alpha-Go用深度学习开启了一个周期，到2022年ChatGPT用大模型开启了一个新周期。

很多人现在抱着有超额回报期望来入行大模型Infra，在白银时代这个预期需要降低。能过踩中周期的注定是少数人，因为有分歧才有风险，有风险才有超额收益。现在大模型的共识早就凝聚了，这个领域也注定会供需平衡，变成用市场规律说话。就好比你看买菜大妈就开始买某股票时候，这支股票已经挣不到钱了。

大模型注定会深刻改变我们的世界，但资源和信息向头部集中的趋势非常可怕。一方面，大模型核心技术被一小撮人掌握，比如OpenAI。另一方面，面对巨大信息差和算力差，普通人无法参与到大模型的开发体系中。就像萝卜快跑正在代替网约车司机，AI总有一天会也代替程序员。如何在生产力进步后的世界里找到自己的位置，不要沦为AGI世界的二等公民，是我们每个人焦虑的根源。

让社会不恐惧AI，让社会理性规划和AI融洽相处的未来，一方面要有对巨头有监管，另一方面，让更多人有平等了解大模型技术的机会。这个世界还是很有人在为后者努力，通过代码开源和公开论文，扩散大模型的技术。作为想入行的同学，可以借助开源力量，来让自己和也业界保持同步。这里也有大量还没有解决的技术挑战等待你来解决。另外，像Agent等，多模态，具身智能等技术方向方兴未艾，也可以提前布局下一个时代潮流。

作为大模型Infra从业者，白银时代需要的是苦练基本功。 在2023年，有很多人是在用信息差体现自己价值，某件事我知你不知，你试还得花时间，很多人在极度激烈竞争中也原意为信息差知识付费。今年这种机会会大幅减少，大家比拼的就是真本领了，是否能快速follow新技术，是否能独立搞定一个复杂大系统，是否有更大的技术视野和其他合作方对话的能力，这要求不仅了解Infra还解一些算法、云计算的知识，总体来说传统工程师素养变得尤为重要。

LLM Infra技术栈

从业相关人员来回答感觉这些领域还是比较有机会的，比如下面的技术栈：

使用 smaller LLM 进行应用构建
- 面向垂类领域或者特定 task 的 SFT + RLHF
- 使用 smaller LLM 进行 plugin 和 function call 的功能构建
- 洗数据
- 搜索增强
inference
- 通用模型
  - 硬件 op 适配
  - op 融合加速
  - 量化
  - 蒸馏（非策略蒸馏）
  - 其他加速方法
- 向量数据库
train
- 做分布式训练框架的
- 云计算服务的
- op 运维
hardware
- 销售、采购、囤积显卡（别把眼光只局限在技术）
- hardware design？这部分不太了解
backend
- MLOps
- pipeline
- codeless 平台建设
- QA 等

应用层面在各个场景 LLM+ 落地的工程化开发，包括：构建/管理知识库、tools 接入集成到被 LLM Agent 识别、串场景化流程、形成场景化自定义能力集市等等。而这里各个实现场景的厮杀下来的赛道王者会提供持续的岗位需求。
infra 层面 (类似 Spring 的快速开发体系) 形成自然语言编程体系以及 IDE 能力，实现底层的 prompt 框架/lib (以及 mutic-agent、RAG、React 的框架)，配套的 DevOps 体系，模型本身的推理/训练加速。这里为大公司的基础模型提供上层的快速接入开发包及基础设施保障，应该一直会有岗位需求，就像现在的云计算的上层配套能力一样。
数据工程层面模型的数据准备、自动化标注、提炼训练测试验证集、做 ETL 流程，以及配套工具/模型的开发等。大数据平台及数据开发人员可以往这里靠。

以上是工程化的能切入的点。其实本身如果在做算法，也有门槛低一点的切入点：

过拟合形成的领域模型/小模型
开源模型部署和魔改，在一定期间内肯定会持续有需求（由于大家长期彼此不互信，一模统一不太可能）
向量化的算法也有点小空间，直到形成标准化解决方案

下面是LLMs推理技术栈

图片来自：https://zhuanlan.zhihu.com/p/14062776627
影响LLM推理性能的因素有很多，包括但是不限于：模型配置、硬件类型、数据分布、优化算法、推理策略等。

算法

LLM
参数建模
大模型计算建模

LLMs 位置编码

Transformer

FlashAttention 系列优化

MoEs 算法 & 部署概述

量化

LLMs 量化算法概述

框架开源的 LLM 推理框架有 TensorRT-LLM、FasterTransformer、TGI、vLLM、NanoFlow、SGLANG 等，以 vLLM 为例简单介绍下推理框架：

vLLM 框架

Serving 策略
Orca-Continuous Batching 策略
SGLang-Prefix Prompt Cache 设计
LoRA & Multi-LoRA
Prefill Decode 分离部署

RLHF 算法以及部署概述

Engine 部署

PP & TP LLMs 部署
CPP (TODO)
LLMs 图编译概述

高性能算子

软件栈
- 算子编程模型
算子优化
- GEMM 算子优化
- FlashAttention 系列优化

中间件 (TODO)

硬件系统

计算
- AI 模型部署硬件综述
LLMs 存储
集群通信

场景优化

LLM 长文本优化策略

LLM Infra学习资料

[1] Attention is All you Need: https://proceedings.neurips.cc/paper/2017/hash/3f5ee243547dee91fbd053c1c4a845aa-Abstract.html
[2] ELMo: https://arxiv.org/abs/1802.05365
[3] MoE: https://arxiv.org/abs/1701.06538
[4] GShard: https://arxiv.org/abs/2006.16668
[5] MeshTensor: https://proceedings.neurips.cc/paper/2018/hash/3a37abdeefe1dab1b30f7c5c7e581b93-Abstract.html
[6] Gopher: https://arxiv.org/abs/2112.11446
[7] Chinchilla: https://arxiv.org/abs/2203.15556
[8] FlexFlow: https://proceedings.mlsys.org/paper_files/paper/2019/hash/b422680f3db0986ddd7f8f126baaf0fa-Abstract.htm
[9] GPipe: https://proceedings.neurips.cc/paper_files/paper/2019/hash/093f65e080a295f8076b1c5722a46aa2-Abstract.htm
[10] Parameter Server: https://proceedings.neurips.cc/paper/2014/hash/1ff1de774005f8da13f42943881c655f-Abstract.html
[11] Oneflow: https://arxiv.org/abs/2110.15032
[12] M6: https://arxiv.org/abs/2103.00823
[13] GLM: https://arxiv.org/abs/2210.02414
[14] Pangu-alpha: https://arxiv.org/abs/2104.12369
[15] PatrickStar: https://arxiv.org/abs/2108.05818
[16] FasterTransformers（FT）: https://github.com/NVIDIA/FasterTransformer
[17] TurboTransformers: https://github.com/Tencent/TurboTransformers
[18] ORCA: https://www.usenix.org/conference/osdi22/presentation/yu
[19] Paged Attention: https://dl.acm.org/doi/abs/10.1145/3600006.3613165
[20] text-generation-inference: https://github.com/huggingface/text-generation-inference
[21] LMDelopyer: https://github.com/InternLM/lmdeploy
[22] vLLM: https://github.com/vllm-project/vllm