单集群每天要处理约 155 万亿个 Token。这个数字来自 DeepSeek 最新开源的推理引擎 DeepInfer ——不是新模型，而是 DeepSeek-V4.1-Flash 背后的那套推理系统。

流量大到这个量级，GPU 在每轮计算里浪费一点资源，累积起来都相当可观。DeepInfer 放出的代码里，能看到 DeepSeek 怎么安排大规模推理中的计算、通信和请求调度。

GPU 等 CPU 的那段空档

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

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

传统推理引擎的 Decode 按固定顺序运行：CPU 选择请求、组织 Batch 和 KV Cache 元数据，GPU 执行 Forward 与 Sampling，随后 CPU 读取结果、更新生成长度和请求状态，再启动下一轮。随着 DeepGEMM、FlashMLA 等底层 Kernel 持续优化，GPU 单轮计算时间不断缩短，CPU 调度与结果处理的耗时占比反而更明显。

调整后的顺序是：GPU 处理第 N 轮 Forward 和 Sampling 时，CPU 已经开始准备第 N+1 轮 Batch，并利用设备计算期间的空档处理更早一轮的采样结果。部分工作可提前提交到 GPU 执行队列，依赖关系由 CUDA Stream 和 Event 维护。

实现中，WorkerStepState 用来保存跨轮次执行状态，包括 SequenceMetadata、SchedulerOutputs、SamplerOutput 以及 Forward 和 Sampling 对应的 CUDA Event。上一轮结果可以暂时保留，CPU 无须等其全部完成后处理，便能继续推进后续调度。

提前排程带来的状态难题

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

普通自回归解码通常只推进一个 Token，开启推测解码后，一条请求可能连续接受多个候选，不同序列的实际推进长度也会出现差异。假设一条请求已缓存 1000 个 Token，当前轮可能接受 3 个候选，CPU 准备下一轮时并不清楚最终会通过几个。直接使用旧长度组织计算，Query Length、Key Length 和 RoPE 位置就可能偏移。

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

容量预留之后，还要解决连续两轮 Batch 中请求位置不一致的问题。请求可能结束、加入或被抢占，同一条序列在不同 Batch 中的排列位置也可能改变。DeepInfer 通过 Remap 映射，将当前轮的请求对应到上一轮保存的执行状态，新加入的请求使用特殊标记。GPU 利用映射找到上一轮的实际采样结果，再通过设备侧 Kernel 修正 Query Length、Key Length 等参数。

内存生命周期是另一处复杂性。同步执行时，请求完成后 CPU 通常可以直接释放相关元数据和缓存引用；异步流水线中，某条请求虽已完成 CPU 后处理，GPU 上可能仍有未结束的操作引用其内存。DeepInfer 使用 DeferredRelease 延迟回收 SequenceMetadata、RequestOutput 以及相关缓存块的固定引用，待释放资源先进入队列，再在后续的 pre_sampler_sync 阶段统一处理。

宽专家并行下的组内协调

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

对于同时承担 Prefill 和 Decode 的 NORMAL Engine，如果部分 Rank 进入 Prefill，其他 Rank 却继续 Decode，就可能发生集合通信不匹配。DeepInfer 在 Scheduler 中加入组内投票机制：ALL 模式要求相关 Rank 满足执行 Prefill 的条件，减少无任务设备陪跑；ANY 模式允许部分 Rank 的待处理请求触发组级 Prefill，避免小规模请求长时间排队。

等待队列存在请求，不代表这一轮能够成功排出 Prefill。某个 Rank 可能因为 KV Cache 容量不足或序列槽位受限，最终没有可执行任务。DeepInfer 在初步决定切换 Prefill 后，还会执行第二轮确认：各 Rank 完成实际排程，再检查组内是否存在有效 Prefill。如果没有就返回 Decode；如果部分 Rank 成功排出任务，其他 Rank 则执行空 Prefill Step，维持一致的通信顺序。

MoE 的专家负载也会影响整轮执行时间。Router 可能将较多 Token 分配给少数热点专家，导致对应 GPU 的工作量高于其他设备。DeepInfer 通过 Expert-Parallel Load Balancing 分散这类负载，在 GPU 上保留部分冗余专家副本，并根据运行统计重新安排专家分布。官方 Decode 配置使用 1000 步统计窗口，每 10000 步调整一次专家分配，测得的慢速 Rank 与平均负载之比约为 1.090。

Zero-Overhead Batch Scheduler 借鉴了 SGLang、NanoFlow 等已有异步调度实践，工程特点集中在跨轮次状态修正、在途 Token 记账、KV Cache 生命周期管理，以及与宽专家并行的协同实现。官方尚未单独公布这套调度机制相对同步方案的完整端到端加速数据，DeepInfer 的整体性能结果还包含底层 Kernel、模型并行和其他执行优化的共同作用。当前公开版本主要面向 DeepSeek-V4.1-Flash，完整线上服务所需的部分基础设施仍未开放。