5分钟看懂Deepseek开源周之六：Deepseek-V3/R1推理体系设计----揭开深度求 ...

前言

        众所周知，四大天王一般有五个人。以是开源周五连发有第六天也很正常。贴上了开源周运动的github主贴，各人可以不上推特就能了解详情。
deepseek-ai/open-infra-index: Production-tested AI infrastructure tools for efficient AGI development and community-driven innovation

https://github.com/deepseek-ai/open-infra-index/tree/main?tab=readme-ov-file

---

开源第六天：Deepseek-V3/R1推理体系设计

 open-infra-index/202502OpenSourceWeek/day_6_one_more_thing_deepseekV3R1_inference_system_overview.md at main · deepseek-ai/open-infra-index

https://github.com/deepseek-ai/open-infra-index/blob/main/202502OpenSourceWeek/day_6_one_more_thing_deepseekV3R1_inference_system_overview.md
中文版：DeepSeek-V3 / R1 推理体系概览 - 知乎
体系设计原则

DeepSeek-V3/R1模型的推理优化目标在于：实现更高的吞吐量和更低的延长。
        为告竣这两个目标，我们采用了跨节点的专家并行（Expert Parallelism, EP）办理方案。该方案通过两个核心机制实现优化：
   专家并行（Expert Parallelism, EP）是一种专为混合专家模型（Mixture of Experts, MoE）设计的分布式训练/推理战略。其核心思想是通过将模型中的不同“专家”（Expert）分配到不同的计算节点或设备上，实现模型计算和资源的解耦优化。
  

• 专家分布式部署
  MoE模型中包含多个独立专家（如128个），EP将这些专家分配到不同GPU或节点上。例如：
  
  
  
  • 如有8个GPU，每个GPU存放16个专家。
    
  • 输入数据（Token）根据门控（Gating）网络动态路由到对应专家所在的设备。
    
  
  
• 计算与通讯解耦
  
  
  
  • 前向传播: 数据按路由效果分发到对应设备，各设备独立计算分配的专家输出。
    
  • 效果聚合: 计算完成后，各设备将效果传回主节点举行聚合（All-to-All通讯）。
    
  
  

          起首，专家并行显著扩展了批量处置惩罚规模，通过提升GPU矩阵运算效率实现吞吐量跃升。其次，该架构将专家模型分布式部署于多GPU环境，每个GPU仅需处置惩罚专家子集（大幅降低内存访问需求），从而有效控制延长。但该方案也带来了体系复杂度的提升，重要体现在两个方面：

• 跨节点通讯机制：为最大化吞吐量，需设计精细化的计算流程实现通讯与计算的流水线重叠2
  
• 多节点协同架构：体系本质要求数据并行（Data Parallelism, DP）的支撑，并需确保不同DP实例间的负载均衡
  

本文将重点阐述我们攻克这些挑战的技术路径，包罗：

• 基于EP架构的批量扩展技术
  
• 通讯时延的算力遮蔽战略
  
• 分布式体系的动态负载均衡方案
  

---

大规模跨节点的专家并行（Expert Parallelism, EP）办理方案

        由于DeepSeek-V3/R1模型中专家数量巨大（每层包含256个专家，但仅激活其中8个），模型的高稀疏性要求极大规模的团体批量处置惩罚（Batch Size），以确保每个专家分配到富足的子批量（Sub-batch），从而实现高吞吐与低延长。为此，跨节点的大规模专家并行（EP）成为必需。
        基于我们采用的预添补-解码解耦架构（prefill-decode disaggregation），模型在预添补阶段息争码阶段分别采用了不同粒度的并行战略：

• 预添补阶段
  [路由专家 EP32，MLA/共享专家 DP32]
  每个部署单元（Deployment Unit）跨4个节点，包含32路冗余路由专家。
  每个GPU处置惩罚：9个路由专家 + 1个共享专家。
  
• 解码阶段
  [路由专家 EP144，MLA/共享专家 DP144]
  每个部署单元跨18个节点，包含32路冗余路由专家。
  每个GPU处置惩罚：2个路由专家 + 1个共享专家。
  

   
  关键设计解读

  

• 动态冗余路由专家
  
  
  
  • 通过冗余部署路由专家（如32路冗余），既包管高可用性，又能在稀疏激活（8/256）时维持每个专家的有效负载。
    
  
  
• 阶段化并行战略
  
  
  
  • 预添补阶段：偏重高吞吐，采用粗粒度EP（EP32），通过扩大节点规模（4节点）分摊路由专家计算压力。
    
  • 解码阶段：偏重低延长，采用细粒度EP（EP144），通过更多节点（18节点）分散计算，减少单GPU负载。
    
  
  
• 混合并行架构
  
  
  
  • 同时集成专家并行（EP）与数据并行（DP）：
    
    
    
    • EP负责专家计算的横向扩展，DP（如DP32/DP144）处置惩罚同构任务的分片执行。
      
    • MLA（Multi-Level Attention）与共享专家（Shared Expert）通过DP实现跨节点协同。
      
    
    
  
  

  

---

 计算-通讯重叠优化

        大规模跨节点专家并行（EP）会引入显著的通讯开销。为此，我们在预添补阶段采用双微批次重叠战略，通过将请求批次拆分为两个微批次（microbatches），将通讯成本隐藏在计算过程中，从而提升团体吞吐量：

 示意图：预添补阶段通讯与计算流水线重叠

   1.计算阶段（Computation）：
  

• 包含108个SMs（流式多处置惩罚器），分为多个步调。
  
• 重要步调包罗：ATTN（注意力层）、SHARED（共享专家层）、MLP（多层感知器）。
  

  
  2. 通讯阶段（Communication）：
  

• 包含24个SMs，重要用于COMBINE（合并）和DISPATCH（分发）操纵。
  

  
  3. 微批次（Micro-batches）：
  

• 微批次0（黄色）和微批次1（绿色）交替执行。
  
• 在预添补阶段（Prefilling Phase），两个微批次交替执行，一个微批次的通讯成本被另一个微批次的计算所隐藏。
  

  
        由于不同计算阶段的执行时长不均衡，我们将注意力层拆分为两步计算，并设计五级流水线（5-stage pipeline），实现通讯与计算的无缝重叠。

   1计算阶段（Computation）：
  

• 包含132个SMs（流式多处置惩罚器），分为多个步调。
  
• 重要步调包罗：SHARED（共享专家层）、ATTN-0（注意力层0）、MLP（多层感知器）、ATTN-1（注意力层1）。
  

  
  2通讯阶段（Communication）：
  

• 包含0个SMs，重要用于DISPATCH（分发）和COMBINE（合并）操纵。
  

  
  3微批次（Micro-batches）：
  

• 微批次0（黄色）和微批次1（绿色）交替执行。
  
• 在预添补阶段（Prefilling Phase），两个微批次交替执行，一个微批次的通讯成本被另一个微批次的计算所隐藏。
  

          深度求索公开了从训练和推理框架中获取的性能剖析数据，以帮助社区更好地明白通讯-计算重叠战略和底层实现细节。该性能剖析数据通过 PyTorch Profiler 捕捉，下载后可直接通过 Chrome浏览器（地点栏输入 chrome://tracing）或 Edge浏览器（输入 edge://tracing）加载并可视化。请注意，我们在性能剖析中模拟了绝对均衡的MoE路由战略。详情从以下链接获取：
deepseek-ai/profile-data: Analyze computation-communication overlap in V3/R1.

https://github.com/deepseek-ai/profile-data

---

实现最优负载均衡

        大规模并行（包罗DP和EP）引入了一个关键挑战：假如单个GPU因计算或通讯过载，它将成为性能瓶颈，导致整个体系减速，而其他GPU则处于空闲状态。为了最大化资源利用率，我们致力于在全部GPU间平衡计算和通讯负载。
1.预添补负载均衡器
关键问题：不同DP实例间的请求数量和序列长度差异导致核心注意力计算和分发发送负载不均衡。
优化目标：

• 跨GPU平衡核心注意力计算（核心注意力计算负载均衡）。
  
• 均衡每个GPU的输入token数量（发送负载均衡），避免特定GPU处置惩罚耗时过长。
  

2.解码负载均衡器
关键问题：不同DP实例间的请求数量和序列长度差异导致核心注意力计算（与KVCache使用相关）和分发发送负载不均衡。
优化目标：

• 跨GPU平衡KVCache使用量（核心注意力计算负载均衡）。
  
• 均衡每个GPU的请求数量（分发发送负载均衡）。
  

3.专家并行负载均衡器
关键问题：对于给定的MoE模型，存在固有高负载专家，导致不同GPU间的专家计算负载不均衡。
优化目标：

• 平衡每个GPU上的专家计算（即最小化全部GPU间的最大分发接收负载）。
  

---

深度求索的在线推理体系框架

框架概述

该框架重要分为两个阶段：预添补（Prefill）阶段息争码（Decode）阶段，而且每个阶段都有负载均衡器和服务。
组件详解

• API Server
  
  
  
  • 功能：接收外部请求并将其转发到相应的服务。
    
  • 作用：作为整个体系的入口点，负责路由和调度请求。
    
  
  
• Prefill Load Balancer
  
  
  
  • 功能：负责将预添补阶段的请求分发到多个预添补服务实例。
    
  • 作用：确保请求均匀分布，进步体系吞吐量和相应速度。
    
  
  
• Expert-Parallel Load Balancer (Prefill)
  
  
  
  • 功能：在预添补阶段进一步细化负载均衡，确保专家层的并行处置惩罚。
    
  • 作用：优化预添补阶段的计算资源分配。
    
  
  
• Prefill Service
  
  
  
  • 功能：执行预添补任务，包罗初始化模型参数和其他预处置惩罚操纵。
    
  • 作用：为后续的解码阶段准备数据。
    
  
  
• Decode Load Balancer
  
  
  
  • 功能：负责将解码阶段的请求分发到多个解码服务实例。
    
  • 作用：确保请求均匀分布，进步体系吞吐量和相应速度。
    
  
  
• Expert-Parallel Load Balancer (Decode)
  
  
  
  • 功能：在解码阶段进一步细化负载均衡，确保专家层的并行处置惩罚。
    
  • 作用：优化解码阶段的计算资源分配。
    
  
  
• Decode Service
  
  
  
  • 功能：执行解码任务，包罗生成最终输出效果。
    
  • 作用：根据预添补阶段的数据生成最终的推理效果。
    
  
  
• External KVCache Storage (Optional)
  
  
  
  • 功能：可选的外部键值缓存存储，用于存储中心效果或常用数据。
    
  • 作用：减少重复计算，进步体系性能。
    
  
  

工作流程

• API Server 接收外部请求。
  
• 请求被转发到 Prefill Load Balancer。
  
• Prefill Load Balancer 将请求分发到多个 Prefill Service 实例。
  
• Prefill Service 执行预添补任务，并将效果通报给 Decode Load Balancer。
  
• Decode Load Balancer 将请求分发到多个 Decode Service 实例。
  
• Decode Service 执行解码任务，并生成最终效果。
  
• 效果返回给 API Server，并通过 API 返回给客户端。
  

---

DeepSeek在线服务统计

有DeepSeek-V3/R1推理服务均运行在H800 GPU上，其计算精度与训练阶段保持同等。具体设置如下：

• 矩阵乘法与分发传输采用与训练对齐的FP8格式
  
• 核心MLA计算与合并传输使用BF16格式
  以此确保服务性能最优。
  

此外，由于日间服务负载高、夜间负载低，我们实现了动态资源调度机制：

• 日间高峰时段：推理服务全节点部署
  
• 夜间低负载时段：减少推理节点，释放资源用于研究与训练任务
  

在过去24小时内（UTC+8 2025年2月27日12:00至2025年2月28日12:00）：

• V3与R1推理服务的合计峰值节点占用数达278个
  
• 平均节点占用数为226.75个（每个节点含8块H800 GPU）
  按单块H800 GPU租赁成本2美元/小时计算，每日总成本为87,072美元。
  

H800节点推理服务的成本

   图表信息
标题：H800 Node Count For Inference Service
X轴：时间（Time），从12:00到次日12:00，以小时为单元。
Y轴：H800节点数量（Node Count），范围从0到300。
数据分析
初始阶段（12:00 - 24:00）：
在12:00时，H800节点的数量稳固在约275个。
直到约莫23:00左右，节点数量保持稳固。
下降阶段（24:00 - 06:00）：
从24:00开始，节点数量逐渐减少。
到06:00时，节点数量降至最低点，约为75个。
上升阶段（06:00 - 12:00）：
从06:00开始，节点数量逐渐增长。
到12:00时，节点数量规复到约275个。
总结
高峰期：从12:00到24:00，节点数量保持较高水平，表明这段时间内推理服务的需求较高。
低谷期：从24:00到06:00，节点数量显著减少，表明这段时间内推理服务的需求较低。
规复期：从06:00到12:00，节点数量逐渐规复到初始水平，表明需求再次回升。
   
  1. H800 服务器的背景与界说

  H800​ 是英伟达（NVIDIA）针对特定市场（如中国市场）推出的高性能计算（HPC）及人工智能（AI）加速 GPU，属于 ​Hopper 架构​ 的衍生型号。它的推出重要是为了顺应美国出口管制政策，在保持核心功能的条件下，对部分性能参数举行调整（如显存带宽或算力限制），以满意合规要求。H800 可以看作是 ​H100 GPU 的定制版本，类似于此前 A100 与 A800 的关系。
  

---

  ​2. H800 服务器的核心设置

  一台典范的 ​H800 服务器​ 通常包含以下组件：
  

• ​多块 H800 GPU：单台服务器可能搭载 4-8 块 H800 GPU，提供强大的并行计算本领。
  
• ​CPU 与内存：配备多路高性能 CPU（如 AMD EPYC 或 Intel Xeon），搭配大容量内存（通常 1TB 以上）。
  
• ​高速互联：支持 GPU 间的高速互联技术（如 NVLink 或 PCIe 5.0），以及节点间通讯的 InfiniBand 或以太网。
  
• ​存储与散热：集成高速存储（如 NVMe SSD）和高效散热体系（液冷/风冷）。
  

  

---

  ​3. H800 节点的概念

  H800 节点​ 是指在一个分布式计算集群中，由 ​单台或多台 H800 服务器​ 构成的独立计算单元。节点的核心特性包罗：
  

• ​硬件独立性：每个节点拥有独立的 CPU、GPU、内存和存储资源。
  
• ​任务分配单元：在分布式训练或 HPC 任务中，单个节点负责处置惩罚分配给它的子任务（例如模型的一部分计算或数据分片）。
  
• ​网络互联：节点之间通过高速网络（如 InfiniBand）连接，实现数据交换和同步。
  

  DeepSeek在线服务统计（UTC+8 2025年2月27日12:00至2025年2月28日12:00）
V3与R1服务数据概览

• 总输入token数：608B（其中342B token命中磁盘KV缓存，占比56.3%）
  
• 总输出token数：168B
  
• 平均输出速度：20–22 token/秒
  
• 每个输出token的平均kvcache长度：4,989 token
  
• 单H800节点吞吐量：
  
  
  
  • 预添补阶段（含缓存命中）约73.7k token/秒输入
    
  • 解码阶段约14.8k token/秒输出
    
  
  

计费与成本分析

• 统计范围：覆盖网页端、APP及API全量用户请求
  
• 若按DeepSeek-R1定价尺度计算(*)：
  
  
  
  • 日总收入：562,027美元
    
  • 成本利润率：545%
    
  
  
• 现实收入显著低于理论值的原因：
  
  
  
  • DeepSeek-V3定价显著低于R1
    
  • 仅部分服务收费（网页端与APP访问仍免费）
    
  • 夜间低峰时段自动启用折扣费率
    
  
  

定价说明 (*)

• 输入token：
  
  
  
  • 缓存命中：0.14美元/百万token
    
  • 缓存未命中：0.55美元/百万token
    
  
  
• 输出token：2.19美元/百万token
  

 

   
  图表信息

  

• 标题：Cost and Theoretical Income
  
• X轴：时间（Time），从12:00到次日12:00，以小时为单元。
  
• Y轴：金额（USD），范围从0到35K美元。
  
• 颜色说明：
  
  
  
  • 黄色柱状图：表现成本（Cost）。
    
  • 蓝色柱状图：表现理论收入（Theoretical Income*）。
    
  
  

  数据分析

  

• 初始阶段（12:00 - 24:00）：
  
  
  
  • 在12:00时，成本约为4K美元，理论收入约为27K美元。
    
  • 直到约莫23:00左右，成本保持在约4K美元，理论收入逐渐增长到约30K美元。
    
  
  
• 下降阶段（24:00 - 06:00）：
  
  
  
  • 从24:00开始，成本和理论收入均逐渐减少。
    
  • 到06:00时，成本降至最低点，约为1K美元，理论收入降至最低点，约为7K美元。
    
  
  
• 上升阶段（06:00 - 12:00）：
  
  
  
  • 从06:00开始，成本和理论收入逐渐增长。
    
  • 到12:00时，成本规复到约4K美元，理论收入规复到约30K美元。
    
  
  

  总结

  

• 高峰期：从12:00到24:00，成本保持较低水平，理论收入较高，表明这段时间内推理服务的需求较高且收入可观。
  
• 低谷期：从24:00到06:00，成本和理论收入均显著减少，表明这段时间内推理服务的需求较低且收入较少。
  
• 规复期：从06:00到12:00，成本和理论收入逐渐规复到初始水平，表明需求再次回升。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。