DeepSeek-V3/R1 推理系统官方详解：理论利润率高达 545%

DeepSeek 官方于今日在知乎平台发布了题为《DeepSeek-V3 / R1 推理系统概览》的文章，详细阐述了如何运用大规模跨节点专家并行（Expert Parallelism / EP）技术来扩大 batch size，同时探讨了如何优化传输耗时以及实现负载均衡。

DeepSeek 官方明确指出，DeepSeek-V3 / R1 推理系统的核心优化目标在于实现更高的吞吐量和更低的延迟。

以下是 AI 工具库整理的 DeepSeek 提出的相关方案：

大规模跨节点专家并行（Expert Parallelism / EP）

鉴于 DeepSeek-V3 / R1 拥有庞大的专家数量，且每层 256 个专家中仅激活 8 个，这种高度稀疏性使得 DeepSeek 必须采用极大的 overall batch size，以确保每个专家获得足够的 expert batch size，进而实现更高的吞吐量和更低的延迟。为此，大规模跨节点专家并行（Expert Parallelism / EP）成为必然选择。

DeepSeek 采用多机多卡间的专家并行策略，旨在实现以下目标：

Prefill 阶段：采用路由专家 EP32、MLA 和共享专家 DP32 策略，一个部署单元包含 4 个节点，配置 32 个冗余路由专家，每张卡分配 9 个路由专家和 1 个共享专家。
Decode 阶段：采用路由专家 EP144、MLA 和共享专家 DP144 策略，一个部署单元包含 18 个节点，配置 32 个冗余路由专家，每张卡分配 2 个路由专家和 1 个共享专家。

计算通信重叠

多机多卡专家并行策略不可避免地会带来较大的通信开销。为了降低通信开销对整体性能的影响，DeepSeek 采用了双 batch 重叠技术，以提高整体吞吐量。

在 prefill 阶段，两个 batch 的计算和通信过程交错进行，从而在一个 batch 进行计算时，可以有效掩盖另一个 batch 的通信开销。

Prefill 阶段的双 batch 重叠

对于 decode 阶段，考虑到不同阶段执行时间的差异，DeepSeek 将 attention 部分拆分为两个 stage，形成共计 5 个 stage 的流水线，从而实现计算和通信的重叠。

Decode 阶段的双 batch 重叠

如需了解更多关于双 batch 重叠的细节，请参考 profiling 数据 GitHub 仓库：https://github.com/deepseek-ai/profile-data。

尽可能地负载均衡

由于系统采用了大规模并行策略（包括数据并行和专家并行），任何一个 GPU 的计算或通信负载过重都可能成为性能瓶颈，进而拖慢整个系统。同时，其他 GPU 会因等待而处于空转状态，导致整体利用率下降。因此，必须尽可能为每个 GPU 分配均衡的计算负载和通信负载。

Prefill Load Balancer

核心问题：不同数据并行（DP）实例上的请求数量和长度存在差异，导致 core-attention 计算量和 dispatch 发送量也随之不同。
优化目标：确保各 GPU 的计算量尽可能相同（core-attention 计算负载均衡），且输入的 token 数量也尽可能相同（dispatch 发送量负载均衡），从而避免部分 GPU 处理时间过长。

Decode Load Balancer

核心问题：不同数据并行（DP）实例上的请求数量和长度存在差异，导致 core-attention 计算量（与 KVCache 占用量相关）和 dispatch 发送量不同。
优化目标：确保各 GPU 的 KVCache 占用量尽可能相同（core-attention 计算负载均衡），且请求数量尽可能相同（dispatch 发送量负载均衡）。

Expert-Parallel Load Balancer

核心问题：对于给定的 MoE 模型，存在一些天然的高负载专家（expert），导致不同 GPU 的专家计算负载不均衡。
优化目标：实现每个 GPU 上的专家计算量均衡（即最小化所有 GPU 的 dispatch 接收量的最大值）。

参考架构图

线上系统的实际统计数据

DeepSeek V3 和 R1 的所有服务均采用 H800 GPU，并使用与训练过程一致的精度设置，即矩阵计算和 dispatch 传输采用与训练一致的 FP8 格式，core-attention 计算和 combine 传输采用与训练一致的 BF16 格式，以最大程度地保证服务效果。此外，考虑到白天服务负荷高，晚上服务负荷低的特点，DeepSeek 实施了一套动态调整机制：

白天负荷高峰期，使用所有节点部署推理服务。
晚上负荷低谷期，减少推理节点，以便用于研究和训练任务。

在最近 24 小时内（北京时间 2025/02/27 12:00 至 2025/02/28 12:00），DeepSeek V3 和 R1 推理服务占用的节点总数，峰值达到 278 个节点，平均占用 226.75 个节点（每个节点包含 8 个 H800 GPU）。若假定 GPU 租赁成本为 2 美金/小时，则总成本为 $87,072/天。

在 24 小时统计时段内，DeepSeek V3 和 R1 的运行数据如下：

输入 token 总数为 608B，其中 342B tokens（56.3%）命中 KVCache 硬盘缓存。
输出 token 总数为 168B，平均输出速率为 20~22 tps，平均每输出一个 token 的 KVCache 长度为 4989。
平均每台 H800 的吞吐量为：对于 prefill 任务，输入吞吐量约为 73.7k tokens/s（含缓存命中）；对于 decode 任务，输出吞吐量约为 14.8k tokens/s。以上统计数据涵盖了网页、APP 和 API 的所有负载。
Token（缓存未命中）0.55 美元/百万，输出 Token 2.19 美元/百万。