DeepSeek开源推理引擎DeepInfer：单集群日服务155万亿Token的部署实践

源神归位，DeepSeek 又放大招了。这次开源的不是模型，而是藏在模型身后的推理引擎 DeepInfer——正是它撑起了 DeepSeek V4.1 Flash 高吞吐、低延迟的大规模推理，一个集群单日能服务 155 万亿 Token。

开源地址：https://github.com/deepseek-ai/DeepInfer

deepseek-recipe 开源地址：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 生成答案，每生成一个，都要用上前面所有的 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 存储集群里，容量约 100 PiB，清一色固态硬盘。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 张卡配约 400 Gbps 的互联带宽就够，但可能牺牲可靠性，因为「跨机房的光纤容易被挖断」。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 开源推理框架：走向真正普惠的未来