突发，DeepSeek重磅开源核心推理引擎 - 竞彩比分查询

源神归位！

就在不久之前，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个相比，线上吞吐量提升了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氪经授权发布。