DeepInfer 是什么？DeepSeek 的推理引擎，以及它未发布的部分

DeepInfer 是 DeepSeek 于 2026 年 10 月 16 日以 Apache-2.0 许可证发布的推理框架，它仅服务一个模型：DeepSeek-V4.1-Flash，并将 DeepSeek-V4.1-Flash-1017 作为默认检查点。这种单模型定位是首先要理解的一点，因为它几乎解释了该仓库的其他所有方面。这不是一个恰好包含 DeepSeek 配置的通用服务框架。它是 DeepSeek 在生产环境中运行的代码路径，被裁剪到可通用化的部分，并且对裁剪之处很坦诚：README 自己列出了完整推理服务需要什么，以及本次发布不包含什么，其中点名了 KV 缓存系统、VE/Prefill/Decode 分离，以及跨数据并行副本的负载均衡。你得到的是计算路径——内核、并行、推测解码、调度、结构化输出。你没有得到的是存储与路由层，而正是它让计算路径能够在大规模下以低成本运行。DeepSeek 说明了原因：这些组件与内部基础设施紧密耦合，因此设计在已发布的技术文章中描述，而代码仍留在内部。

仓库里实际有什么？

已发布的功能列表读起来就像一次对服务大型混合专家模型时各项瓶颈的巡览。其中有 DeepSeek 此前发布的核函数库——用于注意力的 FlashMLA、用于矩阵乘法的 DeepGEMM、用于专家并行通信的 DeepEP，以及 TileKernels 和 DeepSelect。还有并行方案：注意力部分以数据并行运行，并配合均衡的上下文并行；MoE 部分以专家并行运行，并配有专家并行负载均衡器。还有 DSpark 这一推测解码栈，其验证长度是调度出来的，而非固定的。还有 SWA 有界重放，这一机制可避免滑动窗口注意力缓存因每次缓存未命中而被迫进行完整重算。还有异步批调度、具有确定性采样的批不变推理，以及受正则表达式、JSON schema 或 EBNF 约束的结构化输出。

入口点刻意保持很小。在将 DEEPINFER_ACCELERATOR 设置为 nvidia或 Ascend 对应项并运行 build.sh 后，仓库附带 examples/offline_inference.py，它会端到端运行默认检查点。DEEPINFER_HF_MODEL_DIR 可将其指向不同的权重目录。已发布的基准是在四块 SM100 GPU 上测 prefill、在 64 块 SM100 GPU 上测 decode 得到的，这正是该引擎所面向的部署形态，而不是笔记本规模的演示。

README 还说明了代码的来源，这一点在阅读之前值得了解。该引擎最初主要基于 vLLM 构建，设计灵感来自 SGLang 和 TensorRT-LLM。这种渊源体现在结构上——调度器、分页注意力接口和采样路径，读过上述项目的人都会感到熟悉——这也解释了为什么此次发布的是一个服务栈的分支，而不是从零编写的架构。DeepSeek 添加的部分是其自身模型所特有的：分离式部署、带负载均衡器的宽专家并行、滑动窗口重放以及 DSpark。

它不包含什么，以及为什么这更重要

这三个缺失的部分并非小遗漏。每一个都是引擎投入生产流量服务之前就必须存在的系统，而且每一个的昂贵之处各不相同。

• KV 缓存系统。前缀复用是聊天工作负载中大部分成本节省所在，因为一次缓存命中会替代一次预填充。没有缓存存储时，每个请求都会重新计算其提示词。DeepSeek 自己的文章描述了其使用的存储：一个专用的 3FS 集群，而非本地主机内存，正是为了让任何预填充机器都能命中任何前缀，并且缓存容量可以独立于计算进行扩展。

• VE/Prefill/Decode 解耦。README 指出，大部分引擎侧功能已在发布版本中存在；缺少的是部署。将视觉编码器、prefill 和 decode 解耦，可以让每个阶段针对自身瓶颈进行容量规划，并将首 token 时间与 token 间时间分开控制。这是基础设施决策，而不是一个开关。

• 跨数据并行副本的负载均衡。DeepSeek 运行四个负载均衡器——预填充、解码、视觉编码器和专家并行——并在技术说明中描述了全部四个。这些路由逻辑均未随附发布。缺少它，副本集群的表现就只能取决于你置于其前的路由器，而简单的轮询路由器会破坏该存储本要保护的缓存命中率。

结合起来看，这一省略便告诉你这是哪一类制品。DeepInfer 是计算路径的参考实现，发布它是为了让内核与调度方面的工作可供检查和复用，而不是一个供你安装并将流量导向它的发行版。

硬件门控才是真正的筛选器

DeepInfer 面向 NVIDIA SM100 和华为昇腾 950。它没有 Ampere 路径，也没有 Hopper 路径，这就把当今大多数集群中的大多数 GPU 排除在外。工具链的其余部分同样特定：仅支持 Linux，需要 GCC 13 或更新版本、Python 3.12，NVIDIA 平台使用 CUDA 13，昇腾平台使用 CANN 9.2。而且根本没有任何发布版本——在 2026 年 10 月 21 日读取该仓库时，其已发布版本数为零，因此既没有可下载的内容，也没有可锁定版本。你只能克隆它，并针对自己的工具链进行构建。

这种组合对于一次备受关注的开源发布来说并不常见，最好将其理解为对范围的准确说明，而不是疏忽。仓库中的内核是为特定指令集和特定互连编写的；README 中的数字来自那套硬件。将计算路径下移一代，正是社区能迅速完成、而工程组织无法承诺的那类工作。发布后几天内，GitHub 上就出现了一个面向较旧 NVIDIA 部件的第三方移植版本，这对需求是一个有用信号，但对已公布的吞吐量数据能否在移植后保持不变则完全不是信号。

DeepSeek 实际运行的部署形态

架构文档正是让仓库中的假设变得清晰可读的地方。系统被解耦为视觉编码器、预填充和解码，以及专用存储节点。预填充使用 2 到 8 的专家并行，并搭配与之匹配的数据并行，选择 HBM 允许的最小配置。解码则相反：专家并行和数据并行均为 64 到 128，DeepSeek 称之为 Wide-EP，并使用可用 GPU 允许的最大配置。张量并行和上下文并行完全不用。视觉编码器每个实例运行在一个 GPU 上，建议使用更便宜的 GPU，因为编码器并不是花钱的大头。

合理的最小部署可以从这些数字推出来。会运行一个预填充 GPU 和一个解码 GPU，而实际上这两个资源池之间的比例大致是一比一。但由于解码需要 64 块或更多 GPU 才能获得专家并行带来的收益，所以最小的高效单元就是 64 块预填充 GPU 加 64 块解码 GPU。在阅读任何关于 DeepInfer 效率的说法时，要记住的就是这个数字：这些数据描述的是一个 128 块 GPU 的部署，而其中一半就是一个阶段。

将预填充和解码拆分到不同数据中心在技术上是可行的，因为 DeepSeek-V4.1-Flash 大幅压缩了 KV 缓存，而且 DeepSeek 自己的部署也确实将推理节点放在不同但相邻的数据中心。预算大约是每八块 GPU 对应 400 Gbps 的互连带宽，文章也坦率地指出了可靠性代价——楼宇之间的光纤很容易被切断。

为什么解码分布得这么广

宽专家并行是设计中唯一最关键的选择，而它很容易被误读为一种扩展技巧。在混合专家层中，每个 token 只接触少量专家，因此解码一步的成本主要取决于搬运专家权重和激活，而不是算术强度。将专家分散到 64 或 128 块 GPU 上，会减少每块 GPU 在每一步中贡献的内存流量；如果——而这就是条件——各专家之间的负载保持均衡，这就会提高每秒 token 数。这正是专家并行负载均衡器的用途。

DeepSeek 的设置足够具体，可以直接照搬。对于预填充，每块 GPU 除了自己拥有的专家之外，还持有四个冗余专家；统计信息在 100 步窗口内收集；每 1,000 步重新分配一次专家，并通过 NVLink 共享内存在同一组内打乱权重。实测不均衡度——最慢的 rank 除以均值——在 EP4/DP4 配置下为 1.074，在 EP2/DP2 配置下为 1.045。对于解码，这些设置则拉长了：每块 GPU 一个冗余专家、1,000 步的统计窗口、每 10,000 步重新分配一次，实测不均衡度为 1.090。两者之间的差异正是关键所在。预填充面对的是突发性、异构的工作负载，需要快速再平衡；解码面对的是稳定流入的负载，可以承受长窗口，因此它很少再平衡，为此付出的代价几乎为零。

路由侧也有同样的特点。预填充请求按总上下文长度分入四个层级——低于 16K、16 至 64K、64 至 256K，以及 256K 及以上——并且引擎会根据上一轮各层级在计算需求中所占的份额被分配到相应层级。在单个 GPU 内，每个预填充步骤的块大小并非固定：一个拟合的二次成本模型会根据序列 token 数量和已计算的前缀预测一步需要多长时间，调度器则求解在剩余时间内符合 32,768 个 token 预算的最大块。解码均衡器同时平衡两个维度：请求数量和总 KV cache 长度，将短请求发送到并发度低且缓存长的 GPU，将长请求发送到缓存小的 GPU。DeepSeek 自己对这一切带来多少收益的总结：大约相当于完全均衡的离线基准的 80%。

缓存，以及那个三天之问

KV 缓存驻留在专用的 3FS 集群上，而不是本地主机内存中，这一决定决定了其余存储设计。数据以 10+2 纠删码方式存储，因此每个编码组可承受两个节点同时故障；一次读取会向组内全部 11 个节点发出请求，任意 10 个响应就足以解码。每个存储节点上都运行一个垃圾回收工作进程，并在超过水位线后按 LRU 淘汰数据。推荐的服务器配备 20 块 30.73 TB 的固态硬盘，至少可持续提供 40 GB/s 的读取和 5 GB/s 的写入，其容量按每台服务器保留约 24 小时数据来配置。实际上，该集群按每个在线 GPU 约 14.4 TB 逻辑缓存运行，物理容量大于该值。

驻留策略让这一权衡变得清晰可见。缓存侧没有过期逻辑；TTL 设置在存储侧，对 agent 流量为三天，对聊天机器人流量为七天，依托一个容量约 100 PB 的固态存储集群。之所以这样拆分，是因为聊天机器人流量有着重得多的长尾命中——少量缓存被反复读取多次，因此丢失它对整体命中率的代价比其体量所暗示的更大。DeepSeek 实测将聊天机器人留存期缩短到三天，会使缓存命中率下降 0.5% 到 1%。这个数字很小，却恰好代表大量被重新计算的前缀填充（prefill）。

滑动窗口注意力使用单独的缓存，并遵循不同的规则。SWA 缓存不会进入分页块；每个序列在主存中占用一个固定大小的槽位，对于 DeepSeek-V4.1-Flash，存储的层是前 20 层。只有该区域会持久化——20 层 × 134 个 token × 528 字节，采用 MXFP8 格式，每个序列为 1,415,040 字节。没有任何内容会发往存储集群；它会保留在生成它的机器的内存中，并由一个内存中的目录记录哪台机器持有什么内容，跨机器命中会通过 400 Gbps VLAN 将其拉回。

产生这些头条数字的两种机制

两种方案中，有界重放更有意思，因为它把一项无界开销变成了恒定开销。通常，滑动窗口缓存未命中意味着要从头重新计算窗口，而开销会随上下文长度和层数增长。DeepSeek 则只重新计算最近的 128 个 token，并将注意力窗口截断到该片段，从而以固定代价生成近似 SWA 缓存。在编码器侧，这使前缀缓存命中长度与 SWA 缓存完全解耦：如果 SWA 缓存缺失，就重放命中前缀的最后 128 个 token，同时块缓存原样复用。

节省主要来自解码器侧。在这种架构中，解码器各层的块缓存由最后一层编码器的隐藏状态投影而来，因此每层只需计算解码器的 SWA 缓存——而要精确重建它，就意味着每次预填充都要让最后 2,560 个 token 经过 20 个解码器层。改为重放 128 个 token，并且只将结果用于解码，而不让它进入前缀缓存，这几乎将总预填充计算量减半。这一项改动比大多数内核优化更有价值，而且这是只有拥有模型架构的团队才能做到的事情。

DSpark 的贡献较小，也更常规。草稿 token 的接受概率会因请求和位置而异，因此每步固定验证五个草稿会在最终被拒绝的 token 上浪费算力。一个置信度头会预测每个草稿 token 的接受率，调度器则按预期回报对草稿排序，并只验证能最大化吞吐量的前缀。在生产环境中，草稿模型仍然每步生成五个 token；验证数量从 5.00 降到 3.2 到 4.4 之间，减少约 30%，而接受长度几乎不变——3.29 对 3.20。根据 EP64/DP64 基准数据，在每 rank 约 60 个并发序列时，这相当于吞吐量提升 4% 到 7%。恰好为 60 时，每 rank 吞吐量从每秒 13,730 个 token 升至 14,466 个 token。低于约 16 个并发序列时，该技术是小幅净亏损，在将其用于低流量部署前值得了解。

155万亿这个数字意味着什么

与本次发布相关的最常被引用的数字是：单个集群每天处理 155 万亿个 token，按低谷定价计算，整体收入为每 GPU 小时 38 美元。这两部分都来自厂商报告，而且都不是你可以复现的基准测试；但这并不意味着它们没有意思——每 GPU 小时的收入数字与吞吐量数字是真正不同类型的说法，因为它把利用率、定价和缓存命中率合并到了一行里。它也是最有可能被脱离限定条件引用的数字，因此这些限定条件值得写下来：单个集群、低谷定价、收入而非成本，以及跨预填充、解码和视觉编码器的汇总。

两个较小的披露更为直接有用。公开仓库中的 FlashMLA 解码内核缺少内部版本所拥有的一项手工调优的汇编优化，这使得它在单独运行时慢 5% 到 10%；DeepSeek 表示端到端性能最多相差 5%。此外，用于推测解码的内部草稿模型比已发布的版本更新，性能差异被描述为很小。这两项陈述都为第三方通过复制代码能在多大程度上达到已发布的性能设定了预期，答案是：大部分，前提是硬件匹配。

目前的代码库，就现状而言

上述截图拍摄于 2026 年 10 月 21 日，显示页面上的星标数为 16.3k。同一天查询 GitHub API，返回的是 16,590 个星标、1,649 个复刻和 176 个未关闭 issue，同时 issue 已被禁用，讨论被引导至 GitHub Discussions。此后星标数持续攀升，因此请把这里的每个数字都视为一个时间戳，而不是代码本身的属性。不到一周内出现如此规模的流量，更能说明人们对 DeepSeek 服务栈的兴趣，而非代码的成熟度；而发布数量为零这一点则说明了其余问题。

如果你正在考虑自己运行它

坦率地总结：DeepInfer 值得仔细研读，却难以实际运营。四个问题就能告诉你它是否适合你。

• 你是否有 SM100 或昇腾 950？工具链中其余的一切都取决于这一个问题。没有合适的加速器，公布的数据就无法迁移，而社区移植版本在生产规模下尚未经过验证。

• 你能在一个通信域中运行 64 个解码 GPU 吗？宽专家并行不是可以跳过的优化；它是解码路径所围绕设计的配置。低于该规模时，你运行的是一个名称相同但实质不同的系统。

• 你是否已经拥有前缀缓存？ 如果没有，你就是在将 DeepInfer 的计算路径与自带前缀缓存的竞争技术栈进行比较，这种比较结果会比该设计本身应得的更差。

• 你承担得起编写路由层吗？ 预填充分桶、解码均衡和专家重分配都描述得足够清楚，可以照着重新实现，而重新实现它们是数周的工作量，仓库并不会替你完成。

如果您不想拥有上述任何一项

对大多数团队来说，实际问题不是如何部署 DeepSeek-V4.1-Flash，而是在哪里调用它。该模型可通过兼容的 API 使用，无需搭建 128 块 GPU 的集群，也无需重新实现负载均衡器；而且这正是本文一直在描述其架构的同一个模型——相同的上下文处理方式、相同的结构化输出行为，且无需进行解耦工作。

要做的比较并不是抽象地看哪个引擎更快，因为已发布的数字是厂商报告的测量结果，基于大多数读者并不拥有的硬件。而是要判断工作负载是否属于那种 3 天缓存 TTL 和 64-GPU 解码池会改变价格的情况，还是属于每几秒通过 API 发一个请求，就比上述任何操作都更便宜的情况。对于第二种情况——也就是大多数情况——该使用的 DeepInfer 数量是零，而该阅读的量是全部。请从DeepSeek V4.1 Flash 模型页面开始，如果你想了解该端点；如果你想了解该端点在做什么，请从仓库的 README 开始。