DeepSeek开源推理框架DeepInfer

刚刚，DeepSeek开源自家推理框架！

DeepSeek宣布，将其内部推理框架DeepInfer「开源」。这套框架已经在DeepSeek V4.1 Flash的大规模推理服务中投入使用，主打高吞吐、低延迟。而且，其还兼容英伟达GPU和华为昇腾NPU两大硬件平台：

值得一提的是除了DeepInfer，DeepSeek还同步开源了生产级Token编解码组件deepseek-recipe。简单来说，它负责把不同格式的API请求转换成模型能理解的输入，再将生成结果转换为对应的API响应。这样一来，我们在部署DeepSeek模型，也能在请求处理、工具调用、思考模式等环节，尽可能与官方API保持一致。一个负责让模型跑得更快、更省算力，一个负责让模型接得上API、用得更顺手。

DeepSeek把推理引擎开源了 根据DeepSeek官方GitHub介绍，DeepInfer是一套服务于大规模生产环境的高性能推理框架。目前公开版本支持DeepSeek V4.1 Flash。其最核心的任务，就是让训练完成的大模型，在庞大的计算集群上尽可能高效地运行。值得一提的是，这套系统已经支撑起单集群每天155万亿Token的服务吞吐量。

这里先要解释一个概念，大模型的推理通常分为两个主要阶段——Prefill和Decode，前者负责处理用户输入的上下文，后者负责逐个生成回答Token。当用户只问一句简单问题时，这个过程相对容易处理。但如果同时涌入大量复杂任务，有人提交几十万Token的长文档，有人让Agent连续执行数十轮工具调用，推理系统面临的压力便会迅速增加。大量请求需要排队，模型计算要在不同设备之间分配，历史Token产生的KV Cache还会持续占用存储资源。而DeepInfer，恰好就是专门这解决这抓马之事儿的～

第一项，是分布式推 理和负载均衡。DeepInfer支持注意力数据并行、上下文并行，以及MoE专家并行与专家负载均衡。这对DeepSeek的MoE模型尤其重要，因为MoE模型由多个专家组成，处理不同Token时会选择性激活部分专家。如果不同专家之间的请求分配不均，有些GPU忙得不可开交，另一些却闲着，整个集群的算力利用率就会下降。DeepInfer提供专家并行和负载均衡机制，目的就是减少这类资源分配问题，让更多计算设备能够被有效利用。具体到V4.1 Flash的部署，DeepSeek采用了两套不同的并行策略——Prefill阶段使用2—8路专家并行，Decode阶段则扩大至64—128路专家并行。

第二项，是通过推测解码提高生成效率。DeepInfer集成了DSpark，以及基于置信度的验证调度机制。让模型先快速预测接下来可能出现的多个Token，再交给目标模型批量验证，预测正确时，模型便有机会一次推进多个Token，减少逐Token生成带来的串行等待。而置信度调度则根据预测结果动态安排验证长度，尽量避免做无用功。具体来说，DSpark会先预测5个Token，再通过Confidence Head估计各个Token被接受的概率，把有限的验证算力优先分配给更有希望通过验证的候选Token。据DeepSeek此次技术报告披露，在实际线上部署中，相较于固定验证5个Token的方案，动态验证长度还能让吞吐量进一步提升6%。

第三项，是减少长上下文场景中的重复计算。DeepInfer支持SWA Bounded Replay技术，其中SWA指滑动窗口注意力。其解决的问题很实际，模型在处理长上下文时，需要保存大量KV Cache，但部分滑动窗口缓存的有效复用时间只有几分钟，长期存储在SSD中并不划算。因此，DeepSeek在V4.1中采用了新的处理方式——SWA KV Cache不再持久化存储，一旦缓存缺失，就只重新计算最近128个Token，恢复后续推理所需的近似缓存状态。这样一来，就能避免每次都在完整上下文上重复进行相关计算。

值得一提的是，DeepSeek还公布了V4.1 Flash的实际运行数据。在线上服务中，模型平均首字延迟仅400毫秒，生成速度达到230 tokens/s，代码场景下更达到300 tokens/s。与此同时，平均输入缓存命中率高达96%，包含缓存命中的每卡吞吐量达到150万 tokens/s。离线测试同样亮眼。Prefill阶段，单GPU吞吐量最高约8.6万 tokens/s。Decode阶段，当单用户生成速度约为100 tokens/s时，单GPU总吞吐量约2.6万 tokens/s。

deepseek-recipe：把官方API的处理逻辑也开源了 除了DeepInfer，DeepSeek此次还同步开源了deepseek-recipe。 如果说DeepInfer解决的是模型如何高效运行，那么deepseek-recipe负责的——就是模型如何准确理解来自不同API的请求，以及怎样把生成结果返回给开发者。 根据官方仓库介绍，deepseek-recipe是一套生产级Token编解码组件，主要负责将外部API请求转换成DeepSeek模型能够理解的输入，并将模型输出转换为对应的API响应。

具体来说，它主要涉及三个步骤。 首先，是统一不同API的输入格式。 无论开发者使用Chat Completions、Responses还是Messages接口，组件都可以将请求转换为统一的内部会话表示。 这样一来，开发者就不必为每种接口单独维护一套完整的Prompt处理逻辑～其次，将会话内容转换为模型需要的Token序列。 这里不仅涉及普通文本，还包括消息角色、思考模式、工具调用，以及图像等多模态内容的组织方式，这些细节会直接影响模型如何理解输入，以及怎样生成符合预期的结果。 最后，是对生成结果进行解析和格式转换。

比如，模型返回了一段工具调用内容，组件需要将其解析为对应API要求的结构。 如果模型同时生成思考内容和最终回答，也需要按照接口协议进行区分。 这样一来，开发者才能获得与官方API处理逻辑尽可能一致的响应～所以我们可以理解为这两套开源项目实际上是一个互补关系——DeepInfer负责推理计算、算力调度和性能优化，deepseek-recipe负责请求编码、输出解析与API协议适配～