DeepSeek 又一开源重器！深挖 DeepInfer 究竟藏着多少技术狠活？

单集群日处理约 155 万亿 Token，推理优化争夺毫秒。

作者丨郑佳美

编辑丨岑 峰

昨天，DeepSeek 又在 GitHub 上开源了一个大项目，叫 DeepInfer。

这次没有发布新模型，放出来的是 DeepSeek-V4.1-Flash 背后的推理引擎，包含 MoE 专家并行、异步 Batch 调度、定制 Kernel 和推测解码等核心技术。

DeepSeek 还披露了一组数据：单个集群每天需要处理约 155 万亿个 Token。如此庞大的流量，GPU 哪怕在每轮计算中浪费一点资源，累积起来也相当可观。

目前 DeepInfer 开放的是离线推理能力，线上 KV Cache 存储和跨副本负载均衡等组件尚未完整公开。不过，从已经放出的代码中，可以看到 DeepSeek 如何安排大规模推理中的计算、通信和请求调度。

其中有一套叫 Zero-Overhead Batch Scheduler 的异步调度机制。它解决的问题很具体：GPU 明明已经完成计算，却要停下来等 CPU 整理上一轮生成结果、更新请求状态，再安排下一轮工作。

对于需要连续生成几千个 Token 的请求，这种短暂等待会反复发生，GPU 的实际利用率也会受到影响。DeepInfer 让 CPU 提前一轮安排计算，把原本串行执行的调度和模型前向重叠起来。

但提前排程意味着下一轮计算启动时，上一轮的 Token 可能还没完成 CPU 后处理，序列长度、KV Cache 状态和请求生命周期便会出现时间差。整个机制的技术难点，就藏在这种跨轮次的状态管理里。

01

重新安排 Decode 时序

传统推理引擎的 Decode 通常按照固定顺序运行：CPU 选择请求、组织 Batch 和 KV Cache 元数据，GPU 执行 Forward 与 Sampling，随后 CPU 读取结果、更新生成长度和请求状态，再启动下一轮计算。

随着 DeepGEMM、FlashMLA 等底层 Kernel 持续优化，GPU 的单轮计算时间不断缩短，CPU 调度与结果处理的耗时开始占据更明显的比例。尤其在 Decode 阶段，模型每轮处理的 Token 数量有限，CPU 和 GPU 之间频繁切换执行权，会产生持续累积的空档。

Zero-Overhead Batch Scheduler 调整了这套执行顺序。按照公开的实现，当 GPU 处理第 N 轮 Forward 和 Sampling 时，CPU 已经开始准备第 N+1 轮 Batch，并利用设备计算期间的空档处理更早一轮的采样结果。部分工作可以提前提交到 GPU 执行队列，依赖关系则由 CUDA Stream 和 Event 维护。

实现中，WorkerStepState 用来保存跨轮次执行状态，包括 SequenceMetadata、SchedulerOutputs、SamplerOutput 以及 Forward 和 Sampling 对应的 CUDA Event。

这样，上一轮的结果可以暂时保留，CPU 无须等其全部完成后处理，便能继续推进后续调度。

LLMEngine 通过 Worker 回调衔接这些操作，将原本集中在相邻 Decode Step 之间的 CPU 工作分散到 GPU 计算期间。对于持续生成的请求，流水线进入稳定状态后，CPU 与 GPU 可以分别处理不同轮次，减少设备因调度工作产生的等待。

当然，流水线的启动和收尾仍然需要特殊处理。刚开始执行时没有更早的结果可供消费，请求全部完成后也可能留下尚未提交的采样输出。DeepInfer 通过 Flush 机制处理这些在途结果，确保最后一批计算完成后，请求状态能够正常收尾。

这套方法的收益取决于 CPU 工作与 GPU 计算能够重叠多少。当 CPU 处理时间超过设备计算能够覆盖的窗口时，仍然会出现等待，因此 Zero-Overhead 更接近一种执行调度目标。

02

DeepInfer 如何修正状态错位

CPU 提前安排下一轮时，上一轮的采样结果可能尚未确定。普通自回归解码通常只推进一个 Token，开启推测解码后，一条请求可能连续接受多个候选，不同序列的实际推进长度也会出现差异。

假设一条请求已经缓存了 1000 个 Token，当前轮可能接受 3 个候选。CPU 准备下一轮时，尚不清楚这些候选最终会通过几个，如果直接使用旧长度组织计算，Query Length、Key Length 和 RoPE 位置就可能出现偏移。

DeepInfer 为此维护 total_inflight_tokens，记录已经下发、但尚未完成结果提交的 Token。调度器分配计算资源时，会把这部分在途计算纳入序列长度与 KV Cache 容量检查，并提前预留可能需要的缓存空间，避免后续 GPU 执行时出现容量不足。

容量预留之后，还要解决连续两轮 Batch 中请求位置不一致的问题。

请求可能结束、加入或被抢占，同一条序列在不同 Batch 中的排列位置也可能改变。DeepInfer 因此通过 Remap 映射，将当前轮的请求对应到上一轮保存的执行状态，新加入的请求则使用特殊标记。

GPU 利用映射找到上一轮的实际采样结果，再通过设备侧 Kernel 修正 Query Length、Key Length 等参数，使当前轮注意力计算能够访问正确的上下文范围。对于变长推测验证，还会根据实际接受结果更新需要处理的 Token 数量。

由于 CUDA Graph 通常按照提前捕获的执行规格运行，系统还需要区分计算图预留容量与实际有效序列长度。设备侧状态修正减少了 CPU 与 GPU 之间频繁传输少量长度数据的需要，也让动态请求能够适配固定规格的执行图。

另一处复杂性来自内存生命周期。同步执行时，请求完成后，CPU 通常可以直接释放相关元数据和缓存引用。但在异步流水线中，某条请求虽然已经完成 CPU 后处理，GPU 上可能仍有尚未结束的操作引用其内存。

DeepInfer 使用 DeferredRelease 延迟回收 SequenceMetadata、RequestOutput 以及相关缓存块的固定引用。待释放资源先进入队列，再在后续的 pre_sampler_sync 阶段统一处理。

对于涉及 GPU 状态复制的资源，系统利用 CUDA Event 确认操作完成后再解除引用，避免缓存提前被其他请求占用。

请求抢占也要遵循相同的状态边界。如果某条序列已经离开运行集合，先前提交的计算结果返回时，就不能继续按照原状态更新 Token 计数或缓存位置，否则可能影响重新排程后的序列。

这些处理让提前调度能够跨越多个尚未完成的 Step，避免序列位置、缓存分配和资源回收之间发生冲突。

03

保证多卡执行步调一致

DeepSeek-V4.1-Flash 的部署规模进一步增加了调度难度。官方方案中，Prefill 通常采用 EP2 至 EP8，Decode 则使用 EP64 至 EP128 的宽专家并行。扩大专家并行规模可以分散 MoE 权重读取压力，但参与同一个通信域的 GPU 必须采用一致的执行步型。

对于同时承担 Prefill 和 Decode 的 NORMAL Engine，如果部分 Rank 进入 Prefill，其他 Rank 却继续 Decode，就可能发生集合通信不匹配。

DeepInfer 在 Scheduler 中加入组内投票机制，协调不同 Rank 的执行模式。ALL 模式要求相关 Rank 满足执行 Prefill 的条件，减少无任务设备陪跑。

ANY 模式允许部分 Rank 的待处理请求触发组级 Prefill，避免小规模请求长时间排队。两种模式受到各自触发间隔的控制，减少频繁切换带来的额外开销。

代码里还有一个细节：等待队列存在请求，不代表这一轮能够成功排出 Prefill。某个 Rank 可能因为 KV Cache 容量不足或序列槽位受限，最终没有可执行任务。

为此，DeepInfer 在初步决定切换 Prefill 后，还会执行第二轮确认。各 Rank 完成实际排程，再检查组内是否存在有效 Prefill。如果没有，就返回 Decode；如果部分 Rank 成功排出任务，其他 Rank 则执行空 Prefill Step，维持一致的通信顺序。

启用 Zero-Overhead Scheduling 时，部分组内调度协调还可以通过 CPU 侧 Data Parallel 通信组执行，减少控制通信对 GPU 计算的干扰。

多卡同步之外，MoE 的专家负载也会影响整轮执行时间。Router 可能将较多 Token 分配给少数热点专家，导致对应 GPU 的工作量高于其他设备，即使 CPU 调度已经完成，计算仍需等待较慢的 Rank。

DeepInfer 通过 Expert-Parallel Load Balancing 分散这类负载，在 GPU 上保留部分冗余专家副本，并根据运行统计重新安排专家分布。官方 Decode 配置使用 1000 步统计窗口，每 10000 步调整一次专家分配，测得的慢速 Rank 与平均负载之比约为 1.090。

这样，组内步型协调负责处理跨设备的执行一致性，专家负载均衡则缓解部分设备长期拖慢整轮计算的问题。两者配合异步调度，让 DeepInfer 能够在大规模 MoE 部署中维持较连续的 Decode 执行。

04

推理优化开始深入执行时序

DeepInfer 的 Zero-Overhead Batch Scheduler 借鉴了 SGLang、NanoFlow 等已有异步调度实践。它的工程特点集中在跨轮次状态修正、在途 Token 记账、KV Cache 生命周期管理，以及与宽专家并行的协同实现。

目前官方尚未单独公布这套调度机制相对同步方案的完整端到端加速数据，DeepInfer 的整体性能结果还包含底层 Kernel、模型并行和其他执行优化的共同作用。当前公开版本也主要面向 DeepSeek-V4.1-Flash，完整线上服务所需的部分基础设施仍未开放。

随着 Coding Agent 和长链路推理任务不断增加，Decode 需要执行的轮次持续增长。DeepInfer 展示了一条明确的工程路线：通过跨轮次执行重叠减少调度空档，再利用状态修正与资源生命周期管理维护正确性，让更多 GPU 时间用于实际模型计算。

参考链接： https://github.com/deepseek-ai/DeepInfer/blob/main/README.md

上车，带你看遍全球 AI 顶会精华

可独家畅览：

专家演讲PPT

大会报告全文

热门论文解读

学术新星访谈

未经「AI科技评论」授权，严禁以任何方式在网页、论坛、社区进行转载！

公众号转载请先在「AI科技评论」后台留言取得授权，转载时需标注来源并插入本公众号名片。