DeepSeek 开源了推理引擎 DeepInfer，但 KV 存储与负载均衡没有跟着开源

DeepSeek 在 2026-10-20 把自家生产推理框架 DeepInfer 以 Apache-2.0 开源，同时放出了协议编解码仓库 deepseek-recipe。但这次发布只提供 offline inference：官方 README 明确列出「构成一个完整推理服务所必需、本次不含」的三项，分别是 KV cache 系统、VE/Prefill/Decode 分离编排、以及 prefill 与 decode 两侧 DP 副本间的负载均衡。因此真正值得回答的不是「DeepSeek 也开源了一个推理框架」，而是它交出了什么、把什么留在了手里，以及「护城河从权重移到 serving 层」这句话在什么条件下才成立。DeepInfer

全篇不做跑分，也不做框架排行。所有生产与性能数字都是 DeepSeek 自报口径，本文逐处标注。

DeepInfer 开源的是引擎和算子，服务层三件套明确不在这次发布里

DeepInfer 是一个离线推理引擎加算子库，不是一个拿来就能对外提供服务的完整服务。它恰好缺了 KV 存储系统、PD 编排与 DP 副本间负载均衡这三件服务层组件，而这个缺失本身就是全篇要解释的事情。

把边界钉在最前面，后面所有关于 KV、编排、负载均衡的「为什么没开源」才有落点。官方 README 的两栏口径可以整理成下面这张对照。

这不是措辞上的谨慎，有代码级旁证。deepinfer/engine/llm_engine.py 里 LLMEngine 的 docstring 原文写着：The 'LLM' class wraps this class for offline batched inference. This release does not include an online-serving wrapper. 递归文件树中也不存在任何 api_server / serving / openai / fastapi 命名模块。随发布一并开源的 deepseek-recipe 补的是协议适配层，它负责把不同格式的 API 请求统一转成对话格式与 token IDs，但明确要求调用方自己提供模型推理、工具执行与 HTTP 传输，正好是 online-serving wrapper 缺失在协议层上的对偶。

支撑矩阵同样是专用的证据：README 只声明支持 DeepSeek-V4.1-Flash 与 NVIDIA SM100、昇腾 950 两类硬件。以上结论均以截至 2026-10-22 的官方 README 口径为准，官方既没有承诺补齐这三件套，也没有给时间表。

官方那些规模数字不是「引擎有多快」的证明，而是一套硬件组织方式的产物

官方给出的线上吞吐与成本数字，背后假设了一整套具体的硬件组织方式：8 卡机器做 prefill、64 到 128 卡超节点做 decode、P:D 接近 1:1，再加一个专用的 3FS KV 存储集群。这套组织方式本身并没有随 DeepInfer 开源。

系统整体是 E/P/D 分离加专用存储节点。Vision Encoder、Prefill、Decode 三段各自解耦，以便分别优化 TTFT 与 TBT；注意力沿用 V3/R1 的做法用数据并行，因此需要四个负载均衡器，分别是 Prefill、Decode、Vision Encoder 与 Expert-Parallel。

图注：用户请求经 DeepSeek Recipe 进入 Entrypoint，再分流到 Vision Encoder、Prefill、Decode 三个 Service，每个 Service 前各有一个对应的 Load Balancer，Prefill 与 Decode 内部还各含一个 Expert-Parallel Load Balancer；右侧是独立的 External KVCache Storage (3FS)。黑色箭头是请求流，蓝色箭头是 KVCache 流，两条通道的分离正是 P/D 分离之后 KV 传输变成独立问题的图形来源。DeepInfer Q&A

P/D 分离并不是 DeepInfer 的新发明，它自带一份代价清单。DistServe 在 2024 年就把共置的两层代价讲清楚了：往一个 decode 批次里塞进 prefill 会同时拖慢两者，而共置还强迫两个阶段共享同一套并行配置，尽管 prefill 偏计算密集、decode 偏访存受限，最优形态本就不同。更关键的是它把分离后的 KV 传输量化了：OPT-66B 上一条 512-token 请求的 KV cache 约 1.13GB，要让传输开销隐形需要约 90Gbps 的集群带宽，此外还有负载不均衡敏感与故障传播风险。这解释了 DeepInfer 为什么必须配一个专用 KV 存储集群，而不是随便挂一个普通分布式存储。DistServe

图注：2024 年 P/D 分离的原始运行时形态，顶部 Controller 接收请求后分发给独立的 Prefill 实例组与 Decoding 实例组，两组之间是一条显式的 KV Cache Transfer 通道。图中没有 Vision Encoder 阶段，也不能读出任何并行配置或性能数字。DistServe

线上到底跑成什么样，官方给了一张自报统计表：prefill 每卡吞吐 60K tps（不含缓存命中）与 1.5M tps（含命中）、平均输入缓存命中率 96%、TTFT 平均 400ms 与 P99 1000ms、平均输入 77K tokens、decode 每卡吞吐 14K tps、吐字速度 230 tps（编码场景 300 tps）、KV 不活跃后保留 72 小时、整体收入约每卡每小时 38 美金（谷价）。这些数字必须带一句限定：DeepSeek 自报、无第三方复现，官方未披露统计窗口与硬件口径，图里也没有任何竞品对比，不能当横向性能比较。DeepSeek 博客

图注：官方博客给出的线上统计表原图，列出 prefill 与 decode 两阶段的每卡吞吐、缓存命中率、首字时延与平均输入长度，以及 kvcache 的保留时长。这是 DeepSeek 自报口径的原图，图中没有竞品数据，不能用作横向对比。DeepSeek 博客

每一步的算力都该被当成预算花：批调度反解 chunk size，投机解码分配验证长度

DeepInfer 的调度不是「把 batch 开大」，而是把每一步的算力当成一份要在固定时间预算内花完的配额：批调度用二次代价模型反解 chunk size，投机解码用前缀存活概率把验证算力分给边际收益最高的 token，两者是同一思路在两种资源上的两次应用。

先说批调度。prefill 是非命中的输入吞吐随 batch 增大很快趋平的阶段，所以正确的做法不是继续开大 batch，而是算清楚这一步的钱该怎么花。

图注：Prefill 非命中输入吞吐随每步时延变化的离线 sweep，五个点对应 prefill_batch_size 从 4,096 到 65,536，吞吐上升后迅速饱和。图中条件是 EP4DP4、context 131,072、Decoder Bounded Replay 140 tokens，横轴是每 prefill step 的延迟而非端到端 TTFT，不可当作生产吞吐。DeepInfer Q&A

官方给出的 Prefill Load Balancer 是四层的。第一层按总上下文长度分四档，不足 16K、16 到 64K、64 到 256K、256K 以上，每档有各自的每批 compute-quota 上限，档间按上一轮该档的 quota 需求动态重分实例；第二层在 DP 组间按剩余 quota 拉活，官方特意说明因为任何 engine 都能命中任何前缀，所以不做前缀亲和路由；第三层在 DP 组内把请求分给 quota 负载最低的 rank；第四层在单卡内 FIFO 出队。最关键的第四层机制是：每个 prefill step 有一份纳秒级时间预算，调度器用拟合出的二次代价模型 cost(q, c) 预测耗时，对二次方程反解出 q，取在 32,768 token 预算内且恰好耗尽时间预算的最大 chunk size，这个预算本身还要再经 DP 组内 all-reduce 取 MIN 收紧。

调度与执行的重叠则消除了 GPU 空转。同步式流程里 post-process(N) 需要一次 GPU 到 CPU 的同步才能拿到 sample(N) 的结果，GPU 在 post-process(N) 与 schedule(N+1) 期间就空着。

异步调度让 GPU 跑 forward(N) → sample(N) 的同时，CPU 并发跑 schedule(N+1) → launch_forward(N+1) → post-process(N-1)。官方文档在这里写得很直白，异步调度是「参考已有实现」，点名了 SGLang 与 NanoFlow，技术血缘停留在设计思路层面。SGLang 在 2023 年提出的 RadixAttention 把 KV cache 保留在一棵 radix tree 里做前缀复用，淘汰策略是 LRU 但先删叶子，这与 DeepInfer 的调度是相邻而非相同的东西。SGLang

投机解码是这条预算思路的第二个落点。每 token 延迟可以写成 $L = (T_{draft} + T_{verify})/\tau$，加速因此归约为三个杠杆：草稿更快、接受长度 τ 更高、有效验证开销更低。DSpark 用两个部件分别治后两个杠杆，半自回归结构补回 token 间依赖来治接受率衰减，置信度调度验证则把目标模型的验证算力按前缀存活概率分配给边际收益最高的 token。

图注：一轮解码里发生的五件事：目标模型先生成 anchor，并行 backbone 加轻量串行头出草稿 token 与置信度，调度器按置信度把该行切成保留与丢弃两段，目标模型并行验证保留的前缀，被拒的 token 由纠正 token 补上并进入下一轮。图中没有吞吐或加速数字，四个草稿位只是示意。DSpark

落到系统侧，DeepInfer 线上一次生成 5 个草稿 token，按接受率排序取有效吞吐最大的前缀子集做验证，逐请求的验证长度由 GPU 上的 TileLang kernel 重算。变长验证把每步验证的草稿 token 数从 5.00 降到 3.2 到 4.4，平均接受长度基本不变（3.29 对 3.20），在生产工作点约每 rank 60 条并发序列下折算成 +4% 到 +7% 的吞吐。DeepInfer Q&A 要强调的是这里有两套口径：算法侧论文给的是每用户 token/s 的提升，系统侧给的是验证 token 数与吞吐折算，两者不可互相比较或相乘。DSpark

模型侧把 KV 账本压到极致之后，serving 侧的问题才变成怎么存、怎么复用、怎么搬

DeepInfer 的 KV 设计必须被读成两条互不相同的账本线：模型侧的压缩决定账本有多大，serving 侧的管理决定账本怎么存、怎么复用、缺了怎么补。把这两件事混为一谈，是理解这套系统时最容易犯的错。

图注：V4.1-Flash 的层结构示意，40 层被分成 20 层 causal encoder 与 20 层 decoder，decoder 的首个注意力块直接从编码器输出取 KV，另有 CSA2 的若干静态模式与 Engram 条件记忆。这张图只用于确立「模型侧已经把 KV 账本压到极致」这个前提，不能从中取任何 KV 字节数或吞吐数字。V4.1 技术报告

模型侧这一半的账，DeepSeek 用三招同时压算力、存储与带宽。CED 让 decoder 层的全局 KV 不再来自本层 hidden state，而是直接从第 L/2 层投影得到，于是 prefill 只需计算前一半层，整体 prefill 计算量近乎减半；CSA2 让相邻层复用同一份 main KV 与 indexer K，并可复用已算好的 Top-K 索引，把「省存储」与「省 indexer 计算」两条收益路径解耦；FP4 main KV 再把每条 KV entry 的字节数砍半。结果是全局 KV 被压到 890 bytes/token，约为 V4-Flash 的四分之一，持久 KV 约为 V4-Flash 的八分之一。V4.1 技术报告

账本被压小之后，serving 侧的账目才显出形状。

serving 侧把 KV 分成两类、三种介质。Block KV 以 128 token 为一个 block 分页管理，落在独立的 3FS 存储集群上，不使用本机内存；官方给的三条理由是，所有 prefill 机器都能命中任何前缀从而避免前缀亲和与负载均衡路由冲突，存储与计算节点解耦因而扩缩容不影响 KV，以及 KV 不受计算节点故障影响。3FS 为 KV 提供约 100 PiB 的 SSD 容量、峰值聚合读 10 TiB/s、写约 850 GiB/s，数据以 10+2 纠删码存放，读取时同时向组内 11 个节点发请求，任意 10 个响应即可解码返回，回收交给按 LRU 的 GC，agent 流量 TTL 3 天、chatbot 流量 7 天。SWA KV 则只留在产出它的那台机器内存里，单副本、不落 3FS，TTL 约 180 秒，命中率 98% 以上，跨机命中走 400G VLAN 拉回。DeepSeek 博客

命中策略把两类 KV 的职责分得很干净：命中长度由 Block KV 决定，最后一块是否需要重算由 SWA KV 决定。先查 Block KV 得到 L1，再查 SWA KV 是否落在 L1 减 128 到 L1 的区间，落在则命中长度为 L1，否则退一块重算；在 YOCO 截断要求下，长度 L 的输入最大命中长度为 L 减 134。命中路径分三段，官方自己承认只有第一段不可掩盖：匹配由 Entrypoint 在本机 kvcache-store 上做仅元数据的哈希链前缀匹配，但命中长度必须在路由前算出，所以它落在关键路径上；取 KV 在独立进程里异步把 KV 从 3FS 搬进宿主机共享内存；换入在 engine 进程的线程里把共享内存换进 HBM，逐层与前向重叠，因为 CUDA copy engine 对细粒度 KV block 拷贝性能不佳，改用 GDR 让 RDMA 网卡打满 PCIe 带宽且不占 SM。

这套机制不是推翻分页，而是在同一分页范式上换存储层级。2023 年的 PagedAttention 早已把 KV 组织成固定大小的 block，逻辑块到物理块的映射由 block table 维护，物理显存不必连续，并量化出既有系统只有 20.4% 到 38.2% 的 KV cache 显存真正用于存放 token 状态。PagedAttention

图注：逻辑上连续的 key/value 在物理上以固定大小的块分散存放，attention kernel 逐块抓取，图中占用块里填的是示例文本。图中未标块大小，三个块的上下位置只是示意，也不代表 DeepInfer 采用了 PagedAttention。PagedAttention

社区在前缀复用上还有另一条路线：SGLang 把 KV 保留在前缀树里、用先删叶子的 LRU 淘汰，DeepInfer 选择的是块级路线加更远的存储层级。

最后是这套账本里最贵的一次方案迁移。V4 的做法是 SWA KV 落盘加未命中时精确重算，必须用足够大的 SSD 把未命中率压到极低，结果 SWA KV 占去持久 KVCache 近一半容量却不带来对应命中收益，因为 Block KV 是数天级长尾复用，SWA KV 只在活跃会话内被分钟级复用。V4 技术报告提出的 Zero SWA Caching 完全不落盘，又因生产代价过高未被采用。V4.1 最终改用 SWA Bounded Replay，只重算最近 128 个 token 并把注意力窗口截断在重算段内，重算代价因此与上下文长度和层数无关；decoder 侧精确重建本需跑 20 层乘 2,560 token，改成只重算 prompt 末尾 128 token 后总 prefill 计算量近乎减半，结果只用于 decode、不进前缀缓存。这条链说明的是同一件事：以数天留存的容量承载分钟级生命期的数据不划算。

prefill 取最小、decode 取最大：MoE 下 EP 说了算，DeepInfer 干脆不用 TP 与 CP

并行度不是越大越好，DeepInfer 的选择是 prefill 用 HBM 装得下的最小 EP 与 DP、decode 用 GPU 允许的最大 EP 与 DP，并完全不用 TP 与 CP。官方给出的理由是 Wide-EP 压低了 MoE 专家部分的每步访存，而弃用 TP 与 CP 目前只有官方自陈，缺独立论证。

判断框架先要一把尺子：端到端推理延迟可以拆成计算、卡间通信与流水线气泡三项，提高并行度往往只是把瓶颈从计算侧迁移到通信侧，所以最优并行度取决于工作负载而非模型大小。

图注：张量并行把层内权重与计算切开，每层在 attention 与 FFN 之后各插入一次 AllReduce 集合通信，这是「通信代价从哪来」的物理图像。图中没有 EP、DP、PD 分离或任何数值，不能据图推出延迟、吞吐或并行度建议。ParallelTaxonomy

两阶段的异质性正是分离配置的理由。prefill 中序列长、GEMM 主导，属计算受限，流水线并行的点对点通信只发生在 stage 边界且能被长序列摊薄，因此更利于 TTFT；decode 中每请求每轮只产出一个 token，可用工作单元数约等于活跃 batch，流水线欠占用会让气泡主导 ITL，把流水线并行度降到 1 就彻底消除气泡，因此张量并行更利于 ITL。这套解析模型只覆盖 TP、PP 与混合并行，不含 EP、DP 与专家偏斜，因此它只能用来解释「prefill 与 decode 不该共用一套固定并行配置」，不能替 DeepInfer 的 EP-only 选择做背书或反驳。

DeepInfer 的具体档位如下。

DeepInfer Q&A

Wide-EP 的收益是把吞吐与每用户速度的前沿整体外推，而不是「快 X 倍」。

图注：Decode 输出吞吐与每用户速度的帕累托前沿，EP64DP64 的曲线整体高于 EP8DP8，说明同一每用户速度下 Wide-EP 的吞吐上限更高。条件是 context 131,072、nextn=3、per-token 接受率 75%，且这是离线 benchmark，不等于生产工作点。DeepInfer Q&A

MoE 的另一个麻烦是路由偏斜。热门专家负载集中到少数卡上，过载卡决定整层时延，其余卡空转；复制热门专家能把工作挪到欠载卡，但要付出两笔账：副本必须先收到专家权重才能执行，训练时副本产生的部分权重梯度还必须在专家属主处归约。

图注：上游是固定放置、下游是运行时重分配，左右分别是前向与反向，展示副本权重传输与副本梯度归约如何被重叠进已有的执行路径。原文已注明这是示意图，不能当实测时序，也不能据此断言 DeepInfer 采用了该机制。MegaFlux

DeepInfer 的 EPLB 用的不是 MegaFlux 那种每次前向都重算的运行时复制，而是静态冗余加统计窗加定期重排：Prefill 起步每卡 4 个冗余专家、统计窗 100 步、每 1,000 步重排；Decode 起步每卡 1 个冗余专家（EP64 取整后每卡 7 个）、统计窗 1,000 步、每 10,000 步重排，专家权重经 NVLink 在组内 shuffle。这两者机制可类比，但不可等同。还要说明一处官方口径本身的差异：moe_lb 这个最慢 rank 与均值之比，博客给 prefill 1.0320 与 1.0618，仓库 Q&A 给 1.045 与 1.074，decode 的 1.090 两处一致。两处都是官方一手材料，本文如实并列，不择一断言。MegaFlux

护城河不在引擎代码里：它建基于 vLLM，而服务层至今没有开源

这次开源改变的是「引擎开不开源」，没有改变「服务层不开源」。DeepInfer 是单模型、单硬件矩阵、只做 offline 的专用栈，与通用框架是分工而非替代；自建、复用还是混用，取决于自己的模型与规模是否超出了通用框架的工作点。

先给一套统一词汇表。通用 serving 方法可以分为算法创新与系统优化两大类，DeepInfer 公开的三处取舍恰好对应系统优化里的 Request Scheduling、Memory Management 与 Parallel Computation 三格，vLLM 的分页 KV、SGLang 的 RadixAttention、TensorRT-LLM 的 kernel 路线也可以放进同一套类目。

图注：一套把 serving 优化方法分层归类的词汇表，用来把 DeepInfer 与各通用框架放到同一坐标系里比较。该分类学转引自 Miao et al. (2025)，图中没有任何数据，不是采用率或排名图，也不含 DeepInfer。ServingWild

生态里「热」和「被用」是两回事。截至 2026-08 的一份实证研究统计了各框架的采用仓库数，vLLM 1,821 个、SGLang 54 个、FlashInfer 52 个、LMDeploy 45 个、TensorRT-LLM 15 个，论文明确说这些是 usage patterns 而不是性能证据，且各框架分母差异巨大，百分比只在各自分母内有意义。这份研究的视野只到 2026 年 8 月，DeepInfer 落在它之外。ServingWild

看清楚重叠区，需要 vLLM 一侧的能力基线。

图注：社区默认引擎的骨架，集中式 Scheduler 配单一 KV Cache Manager 与块表，下方是 CPU 与 GPU 两个块分配器，右侧每个 worker 各含 Cache Engine 与一个 Model Shard。用它说明重叠区在哪：DeepInfer 的调度与 KV 管理落在同一类机制上，差别在取舍。PagedAttention

两者不是同一类产品。

护城河命题的正面证据与反例都来自 DeepSeek 自己。2025-04-14 官方公告写明当时不开源整个内部引擎，三条理由是引擎基于一年多前的 vLLM 早期 fork 且已重度定制、与内部基础设施紧耦合、研究团队没有带宽维护大型开源项目，结论是改为向社区贡献可复用的独立组件。一年半之后 DeepInfer 开源，其 README 的 Acknowledgments 自陈「originally built primarily on vLLM, with additional inspiration from SGLang and TensorRT-LLM」，源码头也写着 # Derived from vLLM; modified by DeepSeek.。这说明引擎本身不构成不可逆的壁垒，它可以被逆向。EnginePath

但反转有边界。把两个时点并排看，变化只发生在一侧。

服务层三件套缺失与 2025 年给出的两条理由完全吻合，官方博客也再次确认 KV 管理与负载均衡组件因与内部基础设施耦合较深尚未完整开源。所以判断标准很清楚：能被逆向的引擎代码不是护城河，至今没有开源、只能读到设计描述的服务层才是。DeepSeek 博客

落到选型上，三种情况对应三种做法。模型与规模落在通用框架的工作点之内、需要快速上线，直接复用通用框架；模型与硬件矩阵都超出通用框架的覆盖（例如自研 MoE 架构配特定加速卡），或者规模大到调度与 KV 搬运本身成为主要成本，才值得自建；更常见的是混用，即用通用框架做服务与编排，只把少数瓶颈环节换成自研组件，这与那份实证研究观察到的「FlashInfer 常被当成更大 serving 栈里的组件」是同一模式。

参考文献

本专题引用的核心资料如下，建议深入学习时阅读原文：

1. DeepInfer: High-performance, large-scale inference framework for DeepSeek models（官方 GitHub 仓库） — https://github.com/deepseek-ai/DeepInfer
2. DeepSeek V4.1 Flash Inference Deployment Q&A（DeepInfer 仓库官方问答文档） — https://raw.githubusercontent.com/deepseek-ai/DeepInfer/main/doc/inference_deployment_qa.md
3. DeepSeek V4.1 Flash 大规模推理部署实践（官方知乎博客） — https://zhuanlan.zhihu.com/p/2095560295930508953
4. DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression — arXiv:2609.19969
5. DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation — arXiv:2607.05147
6. Efficient Memory Management for Large Language Model Serving with PagedAttention — arXiv:2309.06180
7. SGLang: Efficient Execution of Structured Language Model Programs — arXiv:2312.07104
8. DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving — arXiv:2401.09670
9. Characterizing Parallelism Strategies in LLM Inference: Fundamental Compute-Communication Trade-offs — arXiv:2610.05305
10. MegaFlux: Skew-Resilient MoE Megakernels via Pipelined Expert Replication — arXiv:2610.00671
11. LLM Serving in the Wild: An Empirical Study of Frameworks, Methods, and System Designs — arXiv:2608.03036
12. The Path to Open-Sourcing the DeepSeek Inference Engine（官方 open-infra-index README，2025-04-14） — https://github.com/deepseek-ai/open-infra-index/blob/main/OpenSourcing_DeepSeek_Inference_Engine/README.md