源神归位！

就在刚刚，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起的标题是「走向真正普惠的未来」。