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

　　参考资料：

　　https://github.com/deepseek-ai/DeepInfer

　　https://github.com/deepseek-ai/deepseek-recipe

　　DeepSeek 开源推理框架：走向真正普惠的未来

　　编辑：摩西桃子