
北京时间 10 月 20 日 17:30,DeepSeek 在 X 上发了一条 4 连推:把自家线上推理框架 DeepInfer 完整开源,协议 Apache-2.0。官方的说法是,它就是现在支撑 DeepSeek-V4.1-Flash 大规模线上服务、做到高吞吐低延迟的那套代码。
GitHub 仓库
https://github.com/deepseek-ai/DeepInfer
DeepSeek 官宣推文(1/4),@deepseek_ai,2026-10-20 17:30(北京时间)
🚀 隆重推出 DeepInfer——我们的自研推理框架,现已完全开源!
它以高吞吐、低延迟支撑着 DeepSeek-V4.1-Flash 的大规模服务。我们把自己的生产技术栈分享出来,帮助社区降低算力成本、减少能耗,让 AI 更实惠。
🚀 Introducing DeepInfer, our in-house inference framework, now fully open source!
Powering DeepSeek-V4.1-Flash at scale with high throughput and low latency. We’re sharing our production stack to help the community lower compute costs, reduce energy use, and make AI more affordable.
1/4
模型开源大家见得多了,把线上服务用的推理引擎也拿出来,就少见多了。我们把仓库 clone 下来,从调度器读到专家负载均衡,下面用大白话讲讲里面到底有什么。
先认识一下 DeepSeek
DeepSeek(深度求索)是杭州的大模型公司,V3、R1 到 V4 系列都是开源权重,以性价比著称。过去他们已经陆续开源了 FlashMLA、DeepGEMM、DeepEP 等一批算子库,这次轮到把这些零件「组装起来」的整机。
推理框架是干什么的?打个比方
把大模型想成一位厨艺很好的大厨,推理框架就是整个后厨的调度系统:订单(用户请求)怎么排队、几口锅(GPU)怎么分工、备好的半成品(KV 缓存)放哪儿、哪道菜先出——都归它管。
同一位大厨,后厨乱,一小时出几十道;后厨顺,一小时出几百道。对 DeepSeek 这种体量来说,后厨效率就是真金白银的成本。
官方 4 条推文说了什么

推文 2/4:DeepInfer 的主要能力。来源:X @deepseek_ai
• 高性能算子 + 深度优化的推理引擎
• 分布式推理、推测解码
• SWA Bounded Replay、结构化输出
• 以后 DeepSeek 新模型的推理代码和后续优化,也会放进这个仓库
第 3 条推文还顺带开源了 deepseek-recipe:生产环境用的 token 编解码组件,处理逻辑和官方 API 对齐,让第三方部署也能拿到和官方一致的 API 行为。第 4 条则是一句口号:Open models. Open kernels. Open inference.

推文 3/4:同时开源 deepseek-recipe。来源:X @deepseek_ai
仓库里有什么:整体架构
仓库 README 写明:DeepInfer 最初主要基于 vLLM 构建,也借鉴了 SGLang 和 TensorRT-LLM。目前只支持一个模型——DeepSeek-V4.1-Flash;硬件支持英伟达 SM100(Blackwell)GPU 和华为昇腾 950 NPU。
读下来,代码大致分四层:
• C++ 调度核心(csrc/engine):调度器、KV 块管理、推测解码长度规划都在这里,光 scheduler.hpp 就有 1300 多行,注释几乎全是中文
• Python 引擎层(deepinfer/engine、worker):驱动每一步的前向、采样、CUDA Graph、KV 缓存分配
• 模型层(model_executor/models/v4_modules):V4 的注意力、MoE、压缩 KV、YOCO 等模块
• 算子层:调用 FlashMLA、DeepGEMM、DeepEP 等自家算子库,另有用 TileLang 写的算子,分 cuda 和 asc(昇腾)两套
还要说清楚:这次开源的是离线推理部分。README 列明,完整线上服务还需要的 KV 缓存存储系统、视觉编码/Prefill/Decode 分离部署、多副本负载均衡没有包含在内(其中分离部署所需的引擎功能「大部分已实现」)。
看点一:多张卡一起「投票」决定这一步干什么
大模型推理分两种活:Prefill 是读题(一次性消化你发的长提示),Decode 是答题(一个字一个字往外吐)。DeepInfer 的注意力部分用数据并行,几十张卡各管一批请求,但它们必须同一步干同一种活,否则通信会卡死。

调度器里的「两轮投票」:用 allreduce 让所有卡统一步调。来源:DeepInfer 源码
代码里的做法很像开会举手:每隔固定步数设一个「ALL 点」,全员都有读题任务才一起读题,免得一张卡干活、其他卡陪跑;再设一个「ANY 点」,只要有一张卡憋着任务就一起做,保证孤立的请求最多等这么多步。第二轮投票再确认是不是真排出了活,注释里写得很直白:不这样做,「running 满 + waiting 非空就死循环了」。
看点二:显存不够时,谁先让位

Decode 调度:按已输出长度排序,KV 块不够就抢占队列另一端的请求。来源:DeepInfer 源码
KV 缓存是模型的「草稿纸」,按块分配。Decode 时,调度器先把正在跑的请求按已输出长度排好序,从一头开始逐个分配新块;块不够了,就从另一头挑请求「请出去」(抢占),释放草稿纸,之后再重算。像餐厅满座时,先安排翻台。
块管理器(block_manager.hpp)是一个带引用计数的空闲链表:同一前缀 fork 出来的请求可以共享同一块,引用数归零才回收。
看点三:推测解码,但每个请求「猜几个」按把握分配
推测解码好比让徒弟先猜后面几个字,大厨一次性检查,猜对的直接用。DeepInfer 里这套叫 DSpark,默认最多猜 5 个(DEEPINFER_USE_NEXTN_DECODE),并配了「置信度调度验证」。

按实测耗时曲线和接受率,挑出单位时间期望产出最高的总验证长度。来源:DeepInfer 源码
源码的思路是:先用一条实测的「批大小→耗时」曲线,加上运行时滚动修正的斜率和采样耗时,估算这一步要花多久;再把每个草稿 token 按「被接受的把握」从高到低排队,一个个往批里加,算每毫秒期望能产出多少 token,取最高点。多出来的验证名额,优先给最有把握的请求。说白了:猜得准的多猜几个,没把握的少猜,算力不浪费在大概率被否决的草稿上。
看点四:MoE 专家的「排班表」
V4.1-Flash 是 MoE 模型,每层有几百个「专家」小网络,分散在不同卡上(专家并行 EP)。问题是专家冷热不均,热门专家所在的卡会被挤爆,其他卡干等。

EPLB 贪心排布:让各历史步上「最忙那张卡」的负载之和尽量小。来源:DeepInfer 源码
DeepInfer 的 EPLB 像排班:给热门专家多配几个「替身」(冗余副本),再按历史负载从重到轻,一个个塞到「放进去后最不容易成为最忙的那张卡」上。仓库附带的部署 Q&A 文档给了实测值:Prefill 每卡起步 4 个冗余专家、每 1000 步重排,最慢卡/平均负载为 1.074(EP4DP4)和 1.045(EP2DP2);Decode 每卡起步 1 个冗余专家、每 10000 步重排,该值为 1.090。
看点五:SWA Bounded Replay,只重算最后一小段
V4 用到了滑动窗口注意力(SWA),只看最近一段 token。缓存命中时,如果这一小段窗口的缓存丢了,传统做法要大段重算。Q&A 文档解释:DeepInfer 只重算最近 128 个 token,把重算成本变成一个和上下文长度、层数都无关的常数;用在 decoder 层时,「总 prefill 计算量近乎减半」。README 给的 V4.1 默认保留长度是 140 个 token(要覆盖 SWA 窗口加推测解码最大回退)。仓库里还专门有脚本验证两种实现方式输出等价。
其他实用能力
• 异步调度:CPU 排下一批和 GPU 算这一批重叠进行,默认开启
• 批次无关推理 / 确定性采样:同样输入,不管和谁拼批,结果都一致(目前仅英伟达)
• 结构化输出:可按正则、JSON Schema、EBNF 语法约束生成
• 测试与评测:tests/ 里有批次无关性、EPLB 策略、采样器等测试,PPL 基线逐样本精确比对;eval/ 提供 AIME 2026、HLE、GPQA Diamond 的离线评测脚本
性能:官方给了哪些数

Prefill:每卡每秒处理的未缓存输入 token 数 vs. 单步延迟(EP4DP4)。来源:DeepInfer README

Decode:每卡每秒输出 token 数 vs. 单用户速度(EP64DP64)。来源:DeepInfer README
README 注明:Prefill 在 4 张 SM100 上测、Decode 在 64 张上测,都在同一个 scale-up 域内,可以用 examples/sweep/run_sweep.sh 复现。从图上看,Prefill 吞吐随批增大逐渐逼近每卡每秒 9 万 token;Decode 在每卡 256 个请求时每卡每秒约 2.6 万 token,单用户速度约每秒 100 token,请求越少单用户越快。
仓库里的部署 Q&A 文档还写了两个线上数字:单一集群服务吞吐 155 万亿 tokens/天,整体收入约每卡每小时 38 美元(按谷价计)。
怎么跑起来
准备 Linux、GCC 13+、Python 3.12,英伟达需要 CUDA 13,昇腾需要 CANN 9.2。设置 DEEPINFER_ACCELERATOR=nvidia(或 ascend)后执行 ./build.sh,再运行 python examples/offline_inference.py --ep 8,首次运行会自动从 Hugging Face 下载 V4.1-Flash 权重。
门槛要有心理准备:这是为数据中心级集群写的框架,Decode 推荐 64 卡以上的大专家并行,不是给单卡玩家准备的。
我们怎么看
这次开源的价值,不只是又多了一个推理框架,而是 DeepSeek 把「自家模型在自家集群上怎么跑到最省」的经验,连同大量中文注释和踩坑说明一起放了出来。对要私有化部署 V4.1-Flash 的企业和云厂商,这几乎是一份官方参考答案。
同时支持英伟达 Blackwell 和华为昇腾 950,也值得留意。缺的 KV 缓存存储和负载均衡部分,官方说和内部基础设施耦合较深,暂未完整开源,后面会不会补上,值得继续关注。
相关链接
DeepInfer GitHub 仓库
https://github.com/deepseek-ai/DeepInfer
deepseek-recipe GitHub 仓库
https://github.com/deepseek-ai/deepseek-recipe
DeepSeek 官宣推文
https://x.com/deepseek_ai/status/2112476496283775135
DeepSeek-V4.1-Flash-1017 模型权重
https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash-1017