前言
众所周知，四大天王一般有五个人。所以开源周五连发有第六天也很正常。贴上了开源周活动的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-indexhttps://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，成本和理论收入逐渐恢复到初始水平，表明需求再次回升。