首页 / 资讯详情
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 与 GP