DeepSeek 又一开源重器！深挖 DeepInfer 究竟藏着多少技术狠活？|deepseek|scheduler|token|元数据|基础设施组件|序列|开源重器|时序

单集群日处理约 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 状态和请求生命周期便会出现时间差。整个机制的技术难点，就藏在这种跨轮次的状态管理里。

重新安排 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 更接近一种执行调度目标。

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，避免序列位置、缓存分配和资源回收之间发生冲突。

保证多卡执行步调一致

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 执行。