突发，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搭建，