神了，DeepSeek 这回，连自家大模型背后的推理引擎都掏出来了！？
刚刚，DeepSeek 宣布，将其内部推理框架 DeepInfer「开源」。
这套框架已经在 DeepSeek V4.1 Flash 的大规模推理服务中投入使用，主打高吞吐、低延迟。
而且，其还兼容英伟达 GPU 和华为昇腾 NPU 两大硬件平台：
简单来说，它负责把不同格式的 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，恢复后续推理所需的近似缓存状态。
这样一来，就能避免每次都在完整上下文上重复进行相关计算。
在线上服务中，模型平均首字延迟仅 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。
除了 DeepInfer，DeepSeek 此次还同步开源了 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
一键三连「点赞」「转发」「小心心」
欢迎在评论区留下你的想法！
— 完 —
点亮星标
科技前沿进展每日见
