神了，DeepSeek这回，连自家大模型背后的推理引擎都掏出来了！？
刚刚，DeepSeek宣布，将其内部推理框架DeepInfer「开源」。
这套框架已经在DeepSeek V4.1 Flash的大规模推理服务中投入使用，主打高吞吐、低延迟。
而且，其还兼容英伟达GPU和华为昇腾NPU两大硬件平台：
值得一提的是除了DeepInfer，DeepSeek还同步开源了生产级Token编解码组件deepseek-recipe。
简单来说，它负责把不同格式的API请求转换成模型能理解的输入，再将生成结果转换为对应的API响应。
这样一来，我们在部署DeepSeek模型，也能在请求处理、工具调用、思考模式等环节，尽可能与官方API保持一致。
一个负责让模型跑得更快、更省算力，一个负责让模型接得上API、用得更顺手。
DeepSeek，你这是把整套模型推理技术都给我们公开了啊。。。
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协议适配～
不过我说DeepSeek，你咋每次搞大事儿，都这么突然啊。。。
参考链接：
[1]https://zhuanlan.zhihu.com/p/2095560295930508953
[2]https://github.com/deepseek-ai/DeepInfer
[3]https://github.com/deepseek-ai/deepseek-recipe
一键三连「点赞」「转发」「小心心」
欢迎在评论区留下你的想法！
— 完 —
🌟 点亮星标 🌟
科技前沿进展每日见
