源神回归！
就在不久之前，DeepSeek再次推出重大举措，完全开放了其自主研发的推理框架DeepInfer。
一个计算集群每天可处理155万亿Token，DeepSeek V4.1 Flash实现的高吞吐、低延迟大规模推理，正是依托于这一框架。
开源链接：https://github.com/deepseek-ai/DeepInfer 以及 https://github.com/deepseek-ai/deepseek-recipe
一同发布的，还有面向生产环境的Token编解码组件deepseek-recipe。
英伟达SM100 GPU与华为昇腾950 NPU，均被列入支持范围。
DeepSeek还在知乎上发布了技术详解，并在GitHub上提供了一份部署问答，详细介绍了该系统的架构设计与部署细节。
根据官方公布的线上数据，平均每个请求输入77K Token，首个字的输出平均仅需400毫秒。生成阶段每秒可输出230个Token，在编写代码时更可达到300个。
平均96%的输入能够直接命中缓存，无需重新计算。
按谷价计算，每张显卡每小时的平均收入为38美元。
如今，全球用户都可以了解到DeepSeek如何让大模型高效地执行任务。
DeepSeek研究员Deli Chen更是发表了一段强硬的声明。
开源与闭源。光明与黑暗。这是两种未来、人类两种命运之间的对决。他们想持续多久，我们就持续多久。直至取得完全的胜利。
评论区中，充满了开发者们的热烈反响。
正如网友所说，模型开源已是“常规操作”，如今连推理引擎也开放源代码，格局瞬间被拉满。
此前，DeepSeek已经开源了一系列大模型、用于开发高性能算子的TileLang以及多个推理算子库。
这一次，从请求进入系统到产生结果，每一步如何节省算力，DeepSeek都进行了全面公开。
一个请求，分为两条路径
模型处理一个请求分为两个阶段。第一阶段称为Prefill，模型会一次性读取系统提示、聊天记录、文件和问题，每个Token在每一层都会计算出一组中间结果，这就是KV缓存。
第二阶段称为Decode，模型开始逐个Token生成答案，每生成一个Token，都需要利用之前所有的KV缓存。
这两个阶段对资源的需求截然不同。Prefill一次需要处理数万个Token，对算力要求极高。
Decode一次只生成一个Token，大部分时间用于从显存中读取参数和缓存。
因此，DeepSeek将这两个阶段分配到不同的机器上。Prefill使用常见的8卡机器，而Decode则使用64至128卡的超节点。
如果请求中包含图片，会先交由独立的图像编码服务处理。
在实践中，两个阶段所需的显卡数量大致为1比1。根据官方建议，要达到高效率，最小部署单元为64卡Prefill加上64卡Decode。
官方API的那套逻辑，也开放了源代码
请求进入系统后，首先经过deepseek-recipe这一环节。
目前主流的API格式有三种：OpenAI的Chat Completions和Responses，以及Anthropic的Messages。
deepseek-recipe将它们统一转换为同一种对话格式，然后根据模型版本拼接prompt并进行Token编码。模型输出的Token，也由它转换回各自的格式，并通过流式方式返回。
它还顺便堵住了一个漏洞。DeepSeek的模型依靠一批特殊Token来标记对话结构，例如用户发言的起始、思考的结束以及工具调用的时刻。
96%的输入，无需再次计算
Agent每次调用工具时，都需要将系统提示、工具说明，以及之前每一轮的回复和工具结果，整个重新发送给模型。
这其中绝大部分内容，在上一轮中已经计算过。
DeepSeek的做法是，将计算过的KV缓存保存下来，下一轮只计算新增的部分。前提是前缀必须从第一个Token开始完全一致，中间重复的内容无法复用。
效果有多显著呢？在同一张显卡上运行Prefill，如果不考虑缓存命中，每秒可处理6万个Token。
如果考虑缓存命中，每秒可达150万个，相差整整25倍。
这些缓存全部存放在DeepSeek自家的3FS存储集群中，容量约为100PiB，全部采用固态硬盘。Agent流量的缓存保留3天，聊天流量保留7天。
聊天流量保留更长时间，是因为少数缓存会被频繁读取多次，一旦丢失，整体命中率会大幅下降。根据DeepSeek的经验，如果聊天流量只保留3天，命中率会下降0.5%到1%。
将缓存单独放入存储集群后，任何一台Prefill机器都可以读取任意一段缓存，用户无需被绑定在上次使用的机器上。而且，计算设备的故障率比存储设备高出至少一个数量级，即使设备损坏，缓存仍然存在。
未命中？仅需补算128个Token
V4.1 Flash的部分层使用了滑动窗口注意力机制（SWA），每个Token只关注距离最近的128个Token。
注意力计算也仅限于这128个Token，从而得到一份近似的窗口缓存。重算成本因此成为一个常数，无论上下文长度或模型层数如何，都不受影响。
同样的方法也应用于模型的另外20层。这20层每次Prefill都需要重建窗口缓存，原本需要计算最后的2560个Token，现在只计算128个，Prefill的总计算量因此减少了近一半。
一步输出多个Token
进入Decode阶段后，模型每计算一步，原本只能生成一个Token。
DeepSeek自研的DSpark在此基础上更进一步。它首先估计每个猜测被接受的概率，对概率较低的猜测直接放弃验证，将验证算力分配给其他请求。
与固定验证5个Token的方法相比，线上吞吐量提升了6%。
在两个计算步骤之间，CPU需要排列下一步的请求并处理上一步的结果，GPU原本只能等待。DeepInfer使两者能够同时工作，当GPU计算第N步时，CPU已经在排列第N+1步。
通过这一系列组合，线上Decode阶段每张显卡每秒可生成1.4万个Token。
384个专家，分配到64张显卡上
V4.1 Flash是一个MoE模型，内部包含多组“专家”参数，每个Token只会用到其中几组，仅路由专家就有384个。
在Decode阶段，DeepSeek将这些专家分配到64张显卡上，每张显卡放置6个专家，并额外放置1个热门专家的副本，共计7个。每张显卡上的专家越少，每一步需要从显存中读取的参数就越少，同等数量的显卡就能处理更多请求。
官方离线测试显示，64卡一组运行Decode，每张显卡每秒最多可输出超过2.6万个Token。
热门专家的副本也会动态调整，每1000步统计一次负载，每10000步重新分配。线上实测显示，负载最高的显卡仅比平均水平高出9%。
请求也需要均匀分配。Prefill根据输入长度分为4个档次，每个档次分配多少机器，会根据上一轮的需求动态调整。
Decode阶段则同时考虑每张显卡上的请求数和缓存总长度，短请求分配给请求少、缓存长的显卡，长请求分配给缓存短的显卡。
通过这一套调度机制，系统整体性能可达到离线测试中完全均衡状态的80%左右。
即使是跨机房部署，DeepSeek也在问答中给出了答案。V4.1 Flash大幅压缩了KV缓存，跨机房在技术上可行，每8张显卡配备约400Gbps的互联带宽即可，但可能会牺牲可靠性，因为“跨机房的光纤容易被挖断”。
DeepSeek自己的推理节点，就放置在相邻但不同的机房中。
降低智能的成本
此次开源的DeepInfer采用Apache 2.0协议，deepseek-recipe采用MIT协议。DeepInfer目前支持V4.1 Flash，最初主要基于vLLM构建，并参考了SGLang和TensorRT-LLM。
开源版本目前仅提供离线推理。KV缓存管理和负载均衡由于与内部基础设施绑定较深，代码尚未完整开源，但其设计细节已包含在长文和问答中。
DeepSeek此次分享的内部部署经验，主要目的是降低算力成本、减少能源消耗，让更广泛的人群能够负担得起智能服务。
接下来，DeepSeek新模型的推理代码和性能优化，都将在DeepInfer中持续开源。
从模型、TileLang、算子库，到推理框架和API编解码，DeepSeek的开源范围，已经从模型本身扩展到了每天处理155万亿Token的在线服务。
此次官方公告，DeepSeek使用的标题是“走向真正普惠的未来”。
本文来自微信公众号“新智元”，作者：ASI启示录，36氪经授权发布。