刚刚，DeepSeek开源最新推理框架：单集群日吞吐155万亿Token，KVCache可保存7天

作者 | 褚杏娟

10 月 20 日，DeepSeek 宣布正式开源大规模云服务推理框架 DeepInfer。该框架已经用于 DeepSeek V4.1 Flash 的大规模线上推理服务。

据介绍，DeepInfer 集成了高性能算子和深度优化的推理引擎，支持分布式推理、推测解码、SWA Bounded Replay、结构化输出等能力，并能够运行在 NVIDIA 与华为昇腾平台上。按照 DeepSeek 公布的数据，目前基于这套系统运行的单一集群服务吞吐已经达到每天 155 万亿 Token，按谷价计算，整体收入达到每卡每小时 38 美元。

DeepSeek 同时开源了生产级 Token 编解码组件 deepseek-recipe，用于在主流大模型 API 协议和模型 Token 之间进行高效、准确转换，其处理逻辑与 DeepSeek 官方 API 完整对齐，从而使第三方部署能够尽可能获得与官方服务一致的 API 体验。

开源仓库：

DeepInfer：https://github.com/deepseek-ai/DeepInfer

deepseek-recipe：https://github.com/deepseek-ai/deepseek-recipe

不过，这并不是 DeepSeek 全部线上推理基础设施的完整开放版本。DeepSeek 明确表示，KVCache 管理与负载均衡组件因为与内部基础设施耦合较深，相关代码目前尚未完整开源。此次披露的重点，是 V4.1 Flash 推理系统的整体架构和关键实现方式，以及这些组件在真实大规模在线服务中的设计逻辑。

DeepSeek-V4.1-Flash 线上系统的实际统计数据

普通8卡机器做Prefill，64-128卡超节点做Decode

DeepSeek 介绍，V4.1 Flash 推理系统在设计之初确定了三个核心目标：兼容不同厂商计算芯片；围绕常见硬件组织 Prefill 与 Decode；以及让 KVCache 能够保留 72 小时以上，从而减少重复计算。

在具体部署中，DeepSeek 使用常见的 8 卡服务器承担 Prefill，并使用 64-128 卡超节点承担 Decode。两者不再被视为同一种计算负载，而是分别按照不同特点设计计算、通信和调度策略。

这一架构延续了 DeepSeek-V3、R1 时代的部分设计，但进一步将视觉编码器、Prefill 与 Decode 分离部署，使三个阶段能够独立分配资源，并分别优化首 Token 延迟（TTFT）和 Token 间延迟（TBT）。在混合专家模型（MoE）部分，Prefill 通常采用 2-8 路专家并行和数据并行，而 Decode 则扩大至 64-128 路 Wide-EP，以通过更大的批处理规模提高 GPU 矩阵计算效率。

其中一个非常明显的变化，是推理系统优化越来越多地围绕整个集群如何减少空转进行。

PD 分离后，两类资源需求比例会随着线上流量实时变化。如果提前设定固定比例，就会在部分时段产生排队，而另一类机器则出现空转。因此，DeepSeek 在集群层加入自动扩缩容机制：Prefill 侧根据未命中 Token 数判断需要多少实例，Decode 侧根据当前实际计算请求数估算需求，扩缩容过程设有上下界和调整速率限制。

对于大 EP 部署中长尾请求导致的资源浪费，Decode 实例收到下线通知以后不会立刻退出，而是进入 1 分钟宽限期。宽限期结束后，如果仍然存在尚未完成的请求，系统会把对应请求和它们的 KVCache 一次性转发给其他实例继续进行 Decode。部署时还会额外保留冗余配额。一部分机器处于 Ready 状态但暂未分配，用作突发扩容库存；与此同时，在线实例数量始终会比理论需求更多。当配额占用率高于 0.8 时，系统直接禁止缩容。

容错方面，DeepSeek 并没有试图把实例重启时间压到极短。实际错误重启仍然是分钟量级，整体容错依赖“冗余配额 + 请求级重新路由”的组合。

大规模 EP 部署下，一个实例中的所有 GPU 构成一个通信域，只要其中任何一张卡发生故障，整个实例都可能无法继续工作。重新启动时，为了继续利用其他健康 GPU，平台会重新统计可用卡数量，并按照实际获得的健康 GPU 数重新确定 EP Size。

数据并行、专家并行、Prefill、Decode 和视觉编码都需要不同的负载均衡器，DeepSeek 因此分别开发了 Prefill Load Balancer、Decode Load Balancer、Vision Encoder Load Balancer 和 Expert-Parallel Load Balancer。

例如，Prefill 会根据输入长度分成小于 16K、16K-64K、64K-256K 以及超过 256K 四档，并根据实际计算负载动态分配引擎数量；Decode 则同时观察请求数量和 KVCache 总长度，将长短请求分配至不同卡上，以降低部分设备等待造成的吞吐损失。

专家并行同样采用动态调整。每张卡除常驻专家外，还会部署额外冗余专家作为热门专家副本，并根据最近一段时间内不同专家的实际负载重新分配。DeepSeek 公布的线上数据显示，Prefill 场景下不同计算卡之间的负载差距已经被压缩至较低水平。

100 PiB SSD专门存KVCache，最长保留7天

DeepInfer 中另一个占据大量篇幅的部分，是 KVCache。

随着上下文越来越长，同时 Agent 持续携带历史信息和工具调用记录，重复 Prefill 的成本开始快速上升。为此，DeepSeek 把 KVCache 从普通显存缓存进一步做成了集群级共享数据层。

DeepSeek 将 KVCache 存储划分为 Block KVCache 和 State KVCache。Block KVCache 以 128 个 Token 为一个 Block 分页管理，并将持久数据写入独立的 3FS 集群。与此同时，系统单独维护 SWA KVCache，前 20 层各有一个 134 Token 的 Ring，其中窗口长度 128 Token，另预留 6 Token 用于投机回退。运行中的 Block KVCache 和 State KVCache 位于推理卡显存，SWA KVCache 则保存在产生它的 Prefill/Decode 机器内存中，不进入 3FS 持久存储。

运行中的 Block KVCache 和 State KVCache 保存在推理卡显存中，由 Prefill/Decode 实例负责管理；SWA KVCache 保存在产生对应数据的 Prefill 或 Decode 机器内存中，不写入 3FS，只保留单副本，如果跨机器命中则通过 400G VLAN 拉取；分页 Block KVCache 则存放在独立 3FS 存储集群，由 3FS 自身负责数据冗余，kvcache-store 负责管理。

DeepSeek 没有采用常见的多级缓存，而是将持久 Block KVCache 直接放入独立存储集群。这样，所有 Prefill 机器都能够命中任何前缀，不必采用前缀亲和路由，也避免缓存路由和负载均衡之间发生冲突。同时，存储节点和计算节点能够分别扩缩容，计算节点故障也不会导致持久 KVCache 丢失。DeepSeek 提到，计算节点的故障率比存储节点高出数量级，因此将缓存独立出来也能够提升整体稳定性。

3FS 目前为 KVCache 提供约 100 PiB SSD 容量。Agent 流量对应 KVCache 的生存时间（Time-To-Live，TTL）达到 3 天，Chatbot 流量则达到 7 天。后者存在更加明显的长尾命中特征：少量 KVCache 可能会被非常频繁地反复读取，一旦过早删除，对整体命中率影响更大。按照 DeepSeek 经验，如果 Chatbot KVCache TTL 缩短到 3 天左右，整体命中率会下降 0.5%-1%。

带宽方面，3FS 针对约 112 KiB 粒度的 KVCache Block 随机读写进行了专门优化，峰值聚合读取带宽达到 10 TiB/s，峰值聚合写入带宽约 850 GiB/s。

DeepSeek 还进一步拆解了 KVCache 命中路径。

Block KVCache 由 Decode 实例负责落盘，因此无论数据来自 Prefill 还是 Decode，都可以继续被其他请求复用。整个命中流程分为 3 段，其中只有第一段真正位于请求关键路径上：

第一步是匹配。Entrypoint 会在本机 CHECK 角色的 kvcache-store 中通过哈希链进行前缀匹配。这一步只查元数据，但因为命中长度必须在路由之前获得，所以无法被其他计算掩盖；

第二步是取 KV。系统在独立进程中异步将 KVCache 从 3FS 搬入宿主机共享内存；

第三步是换入。Engine 进程中的线程再把数据从共享内存搬到 HBM。系统目标是让逐层 Host-to-Device（H2D）传输和前向计算重叠。由于 CUDA Copy Engine 对细粒度 KVCache Block 复制性能不理想，DeepSeek 改用 GDR，使 RDMA 网卡能够跑满 PCIe 带宽，同时不占用 SM。

在 KVCache 管理上，DeepSeek V4.1 Flash 还改变了 V4 时期的一项设计。

此前的系统会将滑动窗口注意力（SWA）对应的 KVCache 写入持久化存储，以便在需要时精确恢复。但实际运行后，DeepSeek 发现，这类缓存通常只会在单次活跃会话的几分钟内被反复使用，与能够跨数天重复命中的 Block KVCache 完全不同。如果仍用大量 SSD 长期保存这些分钟级数据，会占据接近一半的持久缓存容量，却无法获得对应的命中收益。

因此，V4.1 采用了 SWA Bounded Replay：不再将 SWA KVCache 长期写入 SSD，而是在缺失时仅重新计算最近 128 个 Token，并把重算范围限制在固定窗口中。这样，重算成本不再随完整上下文长度和模型层数持续增加，而变成近似固定开销。

DeepSeek 称，在 Decoder 部分采用这一方法后，每次 Prefill 只需要重新计算 Prompt 尾部 128 个 Token，相比此前逐层精确重建大量状态，总 Prefill 计算量接近减半。

推测解码继续提速：不再固定验证5个Token

DeepInfer 同时集成了 DeepSeek 的推测解码框架 DSpark。

传统推测解码通常一次生成固定数量的候选 Token，再统一交给主模型验证。但问题在于，不同位置上的候选 Token 被接受的概率并不相同，如果固定验证 5 个 Token，就可能把大量算力浪费在本来很难被接受的位置上。

DSpark 加入置信度预测，根据每个候选 Token 的预计接受率动态决定需要验证多少个 Token。在实际线上部署中，系统仍然一次生成 5 个候选 Token，但会根据硬件吞吐曲线和预计接受率，选择预期收益最高的一部分进行验证。

DeepSeek 给出的结果显示，相比固定验证 5 个 Token，变长验证在真实线上部署中的吞吐提高了 6%。

此外，Decode 调度也采用 GPU 与 CPU 异步流水。传统流程中，CPU 进行下一轮调度时 GPU 可能处于等待状态；DeepInfer 则让 GPU 执行当前轮前向计算和采样时，CPU 提前完成下一轮调度，使计算和调度尽可能重叠，减少 GPU 空转。

把API到Token这一层也开源

除了核心推理引擎，DeepSeek 此次还开源了一个此前较少受到关注的生产级组件 deepseek-recipe。

它负责在主流大模型 API 协议与 DeepSeek 模型实际使用的 Token 序列之间进行转换，目前支持 Chat Completions API、Responses API 和 Messages API，并将不同协议统一转换为内部对话格式，再根据模型版本生成对应 Prompt 和 Token 序列。请求转换、Prompt 编码和输出解析主要使用 Rust 实现，同时提供 Python 绑定。

DeepSeek 特别处理了特殊 Token 注入问题。例如用户输入中即使包含 <｜User｜>、<｜image｜> 或类似工具调用标签，也不会直接被解释成拥有特殊语义的控制 Token，而会被当作普通文本编码，以避免用户输入中的特殊 Token 字符串被赋予控制语义，从而影响模型推理行为。

在长上下文场景中，DeepSeek 还利用特殊 Token 已知边界，将不同普通文本片段并行 Tokenize，再重新组合，以降低超长输入对 CPU 和首 Token 延迟的影响。

对于流式输出，DeepInfer 则维护了一套跨 Chunk 流式解析状态机。即使一个 UTF-8 字符、工具调用参数或结构标签被拆成多个数据块，也能等待数据完整后再解析，同时尽可能提前返回已经确认的部分，减少工具调用和长参数生成过程中的额外延迟。

更多详细细节，可以查看官方文档：

https://zhuanlan.zhihu.com/p/2095560295930508953

声明：本文为 InfoQ 整理，不代表平台观点，也不构成投资建议，未经许可禁止转载。

会议推荐

QCon 全球软件开发大会·2026（上海站）将于 10 月 22 日—24 日举办。本届大会聚焦 Harness AI 时代的工程实践，从「构建 AI」到「驾驭 AI」，围绕 AI Native 架构、Agent Runtime、AI Infra、Agent 安全与可观测、Loop Engineering、具身智能与世界模型 等热门技术方向，邀请全球技术社区与产业一线实践者，共同分享 AI Native 时代最具价值的工程经验。查看更多详情可扫码或联系票务经理 18514549229 进行咨询。