拆解 DeepSeek 最新开源推理框架 DeepInfer：万亿级大模型的高效落地实战

近期，DeepSeek 开源了其大规模推理框架 DeepInfer。根据同期发布的官方技术报告，基于 DeepInfer V4.1 Flash 的单一集群服务，其吞吐量达到了惊人的每日 155 万亿个 Token，折算下来整体收入约为每卡每小时 38 美元。

本次开源的核心内容主要包含三部分：DeepInfer 推理框架 、处理 API 请求与 Token 编解码的 DeepSeek Recipe，以及详细阐述 V4.1 Flash 大规模线上部署的技术报告。

本文将从系统架构与线上实测 、开源范围与硬件支持 、以及核心技术深度拆解三个维度，把这套高吞吐、低延迟的生产级推理系统彻底讲清楚。

一、整体推理系统长什么样？

DeepSeek 团队在系统设计之初就确立了三大核心目标：

兼容多家厂商的芯片。
硬件分层部署：使用常见的、高性价比的机器做 Prefill（预填充），使用 64 ~ 128 卡超节点集群做 Decode（解码）。
KV Cache 持久化：实现 KV Cache 能够保留 72 小时以上。

1. 架构设计与流量走向

入口层 ：用户的 API 请求先经过 DeepSeek Recipe 转化为 Token 列表，进入 Entry Point，再由三个负载均衡器（Load Balancers）分发到 Vision Encoder、Prefill 和 Decode 三类服务。
计算分离：Vision Encoder、Prefill 和 Decode 三段独立部署、各自按需分配资源。
- Prefill 负责首个 Token 的延迟（TTFT），追求极致的并行计算效率。
- Decode 负责每个 Token 之间的生成间隔（TBT），两者可以针对性地优化并行方式。
并行策略 ：延续了 V3 的推理系统架构，MoE（混合专家模型）部分采用专家并行（EP） ，Attention 部分采用数据并行（DP） 。通过令 $DP=EPDP = EP$ DP=EP 的设计，将发往同一个专家的 Token 聚到一张卡上，使得 Batch 变大后矩阵乘法的效率大大提升。
集群规模：
- Prefill：单节点一般配 1 P (Pool) 到 8 卡，在显存足够的前提下规模越小越好。
- Decode：单节点配置 1 P 64 到 128 卡（即大 EP 架构），在显存允许的前提下规模越大越好。
- Vision Encoder：一般单卡部署，使用可用范围内最具性价比的硬件。

2. 线上实测数据表现

Prefill 端 ：单卡吞吐（不算缓存命中）为每秒 60K Token；算上缓存命中则高达每11.5M Token。平均输入缓存命中率高达 96% ，平均输入长度达到 77K Token，首 Token 延迟平均 400ms，P99 约为 1 秒。
Decode 端：单卡吞吐为每秒 14K Token，单个用户的生成速度为每秒 230 个 Token（长文本代码场景可达 300 Token/s）。
KV Cache 策略：不活跃后依然能保存 72 小时以上。线上预留了充足的冗余以应对流量剧烈波动。

二、这次开源了什么？没开源什么？

1. 开源范围

根据 DeepInfer 的 Readme，目前首批支持的模型为 DeepSeek-V4.1-Flash ，硬件层支持英伟达 SM100 GPU 以及华为昇腾 950 MPU。

这次开源的是离线推理加上大规模服务所需的核心功能清单，共计 8 大核心模块：

优化过的 Kernel 模型及 Sampler。
Attention、DP、Balance、CP、MoE、EP、EPLB（专家动态负载均衡）。
D-Spark 与暗指信度调度的变长验证机制。
SWA Bounded Replay（滑动窗口注意力的有界重放）。
异步调度机制。
Batch Invariant（推理确定性采样保证）。
结构化输出支持。

2. 未开源与解耦部分

KV Cache 分布式存储系统：与内部基础设施深度耦合。
Vision Encoder、Prefill 与 Decode 的分离部署封装。
DP 副本之间的全局负载均衡调度代码。

3. 代码结构与依赖

框架主体大约由 5.5 万行 Python 和 5,900 行 C++ 组成。核心数据结构（如 Sequence Block Manager）写在 C++ 中并通过 Python 绑定调用。底层依赖了 DeepSeek 此前开源的众多明星项目：

FlashMLA：用于稀疏 MLA Attention 加速。
DeepGEMM / MegaMoE：用于高性能 GEMM 算子与 MoE 计算。
DeepEP：用于专家并行的高效通信。
DeepSelect / TIKernels：用于各种融合小算子。

昇腾版本单独维护了 DeepEP 和 DeepGEMM 的分支，底层通信通过 NCCL 或 HCCL 实现。

三、核心技术深度拆解

1. SWA Bounded Replay（滑动窗口有界重放）

在 V4 架构中，KV Cache 分为两类：

Block KV Cache：按 128 个 Token 一页管理，存储前 4 层的 Main KV 和 Indexer K，可长期落盘。
SWA KV Cache：滑动窗口 Attention 的窗口状态。

痛点：SWA 占掉了持久化 KV Cache 近一半的容量，却只在活跃会话里被分钟级复用，而 Block KV Cache 的 Prefix 能在几天里被反复命中，用昂贵的存储去存只活几分钟的数据极不划算。

解决方案（V4.1 SWA Bounded Replay） ：

缺了 SWA KV Cache 时，只重新计算最近的 128 个 Token，并把注意力窗口截断在回放段里面。
计算代价变成了一个常数，与上下文长度和层数完全无关。
应用场景 1（Encoder 侧 Prefix 命中） ：优先查找 Block KV Cache，如果 SWA 不在了，就把命中 Prefix 的最后 128 个 Token 和没命中的 Suffix 一起做前向回放，重新生成 SWA KV Cache，而 Block KV Cache 原样复用。
应用场景 2（Decoder 侧 CED 架构） ：V4.1 论文将 40 层划分为两半（下 20 层 Castle Encoder，上 20 层 Decoder）。Decoder 层的全局 KV 不由本层计算，而是由 Encoder 最后一层的 Hidden State 投影得到，大大降低了计算量。

2. D-Spark 与变长验证异步调度

D-Spark 投机解码：沿用 D-Flash 的并行结构，通过一个 Confidence Head 预测每个 Draft Token 在前面都被接受的条件下，自身也被接受的概率。
变长验证（Variable-length Verification） ：不同请求、不同位置的 Draft Token 接受概率不同。系统会把所有请求的 Draft 按置信度连乘后的全局概率进行全局排序，动态决定每个请求验证几个 Token，避免固定验证带来的算力浪费。
异步调度流水线：
- 在 Decode 第 N 步中，CPU 先发射当前步的 Forward，接着处理上一步留下的状态，再发射 Sample。
- 后处理不当场执行，而是存起来留给下一步。这样 GPU 队列里永远有活干，CPU 的开销被完全隐藏在 GPU 的计算时间里。

3. 确定性推理与结构化输出

Batch Invariant 推理：确保同一个请求无论和哪些请求拼在同一个 Batch 里，其输出结果完全一致。底层通过禁用多路归约、在英伟达/昇腾上启用确定性算子来实现。
确定性采样：通过将随机种子与 Token 在序列中的绝对位置进行哈希生成均匀随机数，在 FP64 的累积分布上查表采样，彻底摆脱 Batch 大小和执行顺序对生成结果的影响。
结构化输出（XGrammar） ：支持 JSON Schema、正则表达式与 EBNF 语法。在后台线程异步编译语法状态机，运行时每一步在 CPU 上推进状态，并在另一条 Stream 上与 GPU 计算并行，保障格式严格规范。

4. 负载均衡与分布式 3FS 存储

四层负载均衡策略：
1. 按输入总长分桶 （16K 以下、16K~~64K、64K~~256K、256K 以上），动态调整各桶的引擎实例数。
2. DP 组间调度：按剩余计算配额拉取请求，不强求 Prefix 亲和路由（得益于 3FS 的强大支持）。
3. 组内调度：新请求发给当前负载最低的 DP 进程。
4. 单卡内 Chunk 动态调整：基于纳秒级时间预算和代价模型反解出最优的 Batch Size。
3FS 分布式存储集群：
- 拥有约 100 PiB 的 SSD 存储空间，Chat Bot 的 KV Cache TTL 设为 7 天。
- 采用纠删码（10+2）保障高可靠性，通过 RDMA 结合 GPU Direct Storage（GDS）将 PCIe 带宽直接打满，实现毫秒级的跨节点 KV 恢复。

总结

DeepInfer 的开源不仅让我们得以窥见 DeepSeek 在大模型万卡集群上的工程巅峰，更提供了一套从编解码（DeepSeek Recipe）、离线推理、投机解码、到长文本有界重放（SWA Bounded Replay）的完整工业级解决方案。对于广大开发者和企业而言，这无疑是迈向高吞吐、低成本 AI 应用部署的一座重要里程碑。