关于deepseek R1模型分布式推理效率分析

1、引言

       DeepSeek R1 采用了混合专家（Mixture of Experts，MoE）架构，包含多个专家子网络，并通过一个门控机制动态地激活最相关的专家来处理特定的任务 。DeepSeek R1 总共有 6710 亿个参数，但在每个前向传播过程中仅激活 370 亿个参数 。模型的每一层都包含 256 个专家 ，并且每个 token 会并行路由到其中 8 个不同的专家("num_experts_per_tok": 8)进行评估 。

2、DeepSeek R1 的混合专家架构

      DeepSeek R1 由 61 个 Transformer 层组成 。MoE 架构主要在 Transformer 模块的前馈网络（Feed-Forward Network，FFN）层中实现 。每个 FFN 层都包含 256 个专家 。理解 MoE 位于 Transformer 层的 FFN 中，有助于理解计算的结构以及如何应用分布式。Transformer 层是像 DeepSeek R1 这样的模型的基本构建模块。DeepSeek R1模型的671B总参数中，并不是所有参数都在专家层中。MoE模型的参数可以分为两类：

1. 稀疏参数：只在特定token激活的专家层参数
2. 密集参数：每个token都会使用的共享参数

• 在DeepSeek R1中每次激活的37B参数具体如下：
• 1个共享专家（所有token都激活同一个共享专家）
• 门控网络选择的8个普通专家（从255个普通专家中选择）
• 所以总共是9个专家

参数计算：

• 共享专家的参数量与普通专家相当（约2.6B参数）
• 总共激活的参数 = 1个共享专家(~2.6B) + 8个普通专家(~21B) + 稠密层参数(~13.4B) ≈ 37B

DeepSeek R1专家分布分析

从配置文件中可以看到关键参数：

1. MoE层的分布：

   • "moe_layer_freq": 1 - 这表明每一层都是MoE层，而不是我之前猜测的隔层分布
   • "num_hidden_layers": 61 - 总共有61层Transformer块
   • 所有61层都包含MoE结构

2. 专家配置：

   • "n_routed_experts": 256 - 256个常规路由专家
   • "n_shared_experts": 1 - 1个共享专家
   • "num_experts_per_tok": 8 - 每个token激活8个路由专家(不包括共享专家)

3. 专家参数量:

   • "hidden_size": 7168 - 隐藏层维度
   • "intermediate_size": 18432 - 稠密前馈网络的中间层大小
   • "moe_intermediate_size": 2048 - MoE专家内部的中间层大小

MoE计算细节

根据配置：

• 专家参数主要集中在FFN部分，计算每个专家大小约为：
  • 7168 × 2048 × 2 ≈ 29.4M参数（输入和输出矩阵）
• 257个专家(256常规+1共享)×61层 ≈ 约462B参数仅在专家部分

MoE层结构:
[共享专家(1个)] + [普通专家(255个)]
    ↑                  ↑
  总是激活         选择8个激活
    ↓                  ↓
   每个token激活9个专家(1+8) 

共享专家能接触到所有数据，学习通用模式，而普通专家则专注于特定类型的输入，两者结合提高了模型的整体能力和效率。共享专家相当于是一个"通用底层处理器"，确保即使路由决策不理想，每个token也能得到基本处理。

3. 推理过程的分解：理解预填充和解码阶段

特征	预填充阶段	解码阶段
计算强度	高	中等
并行化程度	高	低
内存需求	高内存带宽	中等（KV 缓存访问）
关键指标	吞吐量	延迟
典型硬件优化	多 GPU，高计算能力	快速内存访问，低延迟互连

预填充阶段在计算上受限且受内存带宽限制，特别是对于长输入序列 。它需要大量的并行处理能力和内存带宽来处理整个输入。解码阶段通常受内存限制，因为它主要涉及访问 KV 缓存并一次执行单个 token 的计算 。延迟是此阶段的关键问题。在预填充期间，模型一次性处理整个输入序列。这允许跨输入的不同部分以及跨模型的不同层进行并行计算。在分布式环境中，不同的节点可以并行处理输入的不同片段或不同的层，从而可能显着提高速度。

解码阶段以自回归方式逐个生成输出 token [用户查询。每个新 token 的预测都基于先前生成的 token 和来自预填充阶段的 KV 缓存 。由于 token 生成的顺序性质，此阶段通常比预填充阶段慢且并行化程度较低 。解码阶段的顺序性质给并行化带来了挑战。

通过分布专家，仍然可以通过减少每个节点在每个 token 生成步骤中的计算负载来提高效率。与预填充不同，解码是按顺序发生的。每个生成的 token 都依赖于前一个 token。这使得跨序列长度进行并行化变得更加困难。然而，在每个 token 生成步骤中，激活专家的计算仍然可以分布在多个节点上，从而降低每个步骤的延迟。

token在transformer层中传递的流程

1. 在每一层中，token首先通过自注意力机制
2. 然后该层的门控网络会独立评估这个token
3. 门控网络动态选择8个最相关的路由专家
4. token同时也会通过1个共享专家处理
5. 9个专家(8个路由+1个共享)的输出被加权合并
6. 合并后的结果传递到下一层
7. 在下一层，这个过程完全重复，重新选择专家

关键点是：

• 所有层共享同一个专家池(257个专家)
• 每层都有独立的门控网络做出独立的专家选择
• 专家选择是动态的，完全基于token在当前层的表示
• 不同层可能选择完全不同的专家组合

 

 4、DeepSeek R1 的分布式部署策略

通过将 256 个专家分布在不同的节点上，每个节点仅存储一部分专家的参数 。在推理期间，当一个 token 被路由到一组特定的 8 个专家时，只有托管这些专家的节点才需要执行涉及其参数的大量计算。这避免了每个节点都需要访问整个 6710 亿个参数，从而显着减少了需要本地获取和处理的数据量。这种有针对性的参数访问降低了内存带宽需求以及传输到每个节点的数据量。

 通过将计算负载分布到多个节点上，可以并行处理更多的 token 和请求，从而实现更高的吞吐量 。专家并行通过启用更大的批处理大小，进一步提高了 GPU 矩阵计算效率并提升了吞吐量 。DeepSeek 报告每个 H800 节点在预填充期间的平均输入 token 吞吐量约为 73.7k/s，在解码期间的平均输出 token 吞吐量约为 14.8k/s 。处理更大的批次和并行化计算的能力直接转化为在给定时间内服务更多用户或处理更多数据。当工作负载分布化时，系统的总处理能力会增加。

DeepSeek R1 推理并行策略

策略	描述	DeepSeek R1 的优势	DeepSeek R1 中的应用
专家并行 (EP)	将模型专家分布在节点上，允许每个节点处理模型参数的一个子集。	扩展批处理大小，减少每个节点的内存访问，降低延迟。	跨节点的 EP 用于预填充和解码，具有不同的配置。
数据并行 (DP)	将输入数据分布在多个设备上，每个设备都持有模型的副本（或在某些情况下是分区）。	通过避免注意力层中的 KV 缓存重复来提高内存效率（在 MLA 的上下文中）。	DP 与 EP 结合使用，例如预填充期间的 MLA/共享专家 DP32。

 5、单机部署deepseek r1的局限性

主要性能影响排序

1. 吞吐量严重受限（最主要影响）
   • 并发请求处理能力达到硬性上限，无法超越8卡能力
   • 无法通过增加节点横向扩展处理更多并发请求
   • 在高负载场景下，请求队列迅速增长
2. 高负载下延迟不稳定
   • 随着并发请求增加，热门专家争抢造成性能波动
   • 无法通过分布式部署分散负载压力
   • 专家访问不均衡导致部分GPU成为系统瓶颈
3. 上下文长度与批量处理互斥
   • 长上下文需要占用大量显存存储KV缓存
   • 在固定显存条件下，上下文越长，能处理的批次越少
   • 这种权衡限制了同时支持长上下文和高吞吐量的能力
4. 资源利用率不均衡
   • 热门专家所在GPU可能负载过重
   • 冷门专家所在GPU可能相对闲置
   • 无法通过动态调整优化全局资源利用

单机部署的资源利用情况

• 总显存: 8×141GB = 1128GB
• FP8模型参数: ~671GB
• 剩余显存在KV缓存与批处理空间之间权衡
• 关键规律: 上下文长度增加→可处理批次减少→吞吐量下降

专家在H20 8卡上的实际分布

在H20 8卡(每卡141GB)部署时，专家分布如下：

1. 专家分配策略：
   • 256个路由专家均匀分布在8个GPU上
   • 每张GPU分配32个路由专家
   • 共享专家可能放在其中一张GPU上或复制到多个GPU
2. 显存占用计算：
   • 模型总参数：671B
   • 单个专家估算参数量：~2.62B (FP8精度下约2.62GB)
   • 每张GPU存储32个专家：~84GB
   • 基础模型部分(张量并行切分)：~10-20GB
   • 总计每卡显存占用：~94-104GB
   • 剩余显存(~37-47GB)：用于KV缓存、激活值等 

vLLM/SGLang加载流程

推理引擎加载过程：

1. 解析模型结构：识别出总共257个专家
2. 专家分配：将256个路由专家均匀分配到8张GPU
3. 张量并行：基础层(注意力机制等)通过张量并行分布
4. 专家并行：专家通过专家并行分布
5. 建立路由表：创建专家ID到GPU位置的映射

推理过程中的专家调用

推理时：

1. 门控决策：门控网络为每个token选择8个最相关专家
2. 跨GPU通信：若选中的专家分布在不同GPU上，需要跨GPU通信
3. 共享专家处理：所有token都通过共享专家
4. 结果合并：9个专家(8个路由+1个共享)的结果合并形成输出

 适合的应用场景

单机部署适合以下场景:

1. 稳定低并发环境
   • 用户数量少且稳定可预测
   • 无需处理流量高峰
2. 对单次请求延迟敏感
   • 需要稳定的响应时间
   • 单机内部通信可能优于跨机通信
3. 开发测试环境
   • 降低部署复杂度
   • 简化系统调试
4. 中等上下文长度应用
   • 不要求极长的上下文窗口
   • 显存可以合理分配
5. 预算有限场景
   • 避免多机集群的高成本
   • 减少网络设备投入

不适合的应用场景

单机部署不适合以下场景:

1. 高并发生产环境
   • 需要同时服务大量用户
   • 需要高吞吐量处理能力
2. 流量波动大的服务
   • 需要弹性扩展能力
   • 高峰期需要动态增加资源
3. 极长上下文应用
   • 需要处理数万token的输入
   • 同时要求保持较高吞吐量
4. 需要高可用性服务
   • 不能容忍单点故障
   • 需要冗余部署保障服务连续性
5. 大规模批处理
   • 需要处理海量并行请求
   • 要求高计算吞吐能力

结论

H20单机8卡部署DeepSeek R1的最主要性能影响是吞吐量受限，而非长上下文处理能力。显存总量(1128GB)理论上足以支持较长的上下文，但会以牺牲吞吐量为代价。

该部署方式适合对延迟敏感、并发量可预测且不太高的场景，不适合需要大规模并发处理、高可用性或极长上下文同时保持高吞吐量的生产环境。在选择部署方案时，应根据实际应用特点和性能需求权衡单机与分布式方案。