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： /ai-market-guide/ deepseek-recipe： /ai-market-guide/ 不过，这并不是 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 注入问题。
例如用户输入中即使包含 、 或类似工具调用标签，也不会直接被解释成拥有特殊语义的控制 Token，而会被当作普通文本编码，以避免用户输入中的特殊 Token 字符串被赋予控制语义，从而影响模型推理行为。在长上下文场景中，DeepSeek 还利用特殊 Token 已知边界，将不同普通文本片段并行 Tokenize，再重新组合，以降低超长输入对 CPU 和首 Token 延迟的影响。
对于流式输出，DeepInfer 则维护了一套跨 Chunk 流式解析状态机。即使一个 UTF-8 字符、工具调用参数或结构标签被拆成多个数据块，也能等待数据完整后再解析，同时尽可能提前返回已经确认的部分，减少工具调用和长参数生成过程中的额外延迟。
更多详细细节，可以查看官方文档： /ai-market-guide/