关于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

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

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

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

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

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

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

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

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

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

DeepSeek R1 推理并行策略

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

主要性能影响排序

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

单机部署的资源利用情况

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

适合的应用场景

单机部署适合以下场景:

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

不适合的应用场景

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

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

结论

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

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