10 月 20 日，DeepSeek 把自家线上服务用的推理框架 DeepInfer 开源了，Apache 2.0 协议，可以商用。同步放出来的还有 deepseek-recipe，一个 MIT 协议的 token 编解码组件，官方说它的处理逻辑和 DeepSeek API 对得上。

这条消息在知乎和 Reddit 的 r/LocalLLaMA 上都挂了几天，讨论集中在两件事：显存占用、部署成本，以及“跟 vLLM、SGLang 比到底谁快”。

先把冷水泼在前面：这个框架普通开发者基本用不起来。它只支持 DeepSeek-V4.1-Flash 一个模型，只支持离线推理，硬件只认 NVIDIA SM100（Blackwell）和华为昇腾 950，官方给出的最小高效生产单元是 64 张 prefill 卡加 64 张 decode 卡。没有一个个人开发者或者小团队会为跑一个模型去凑这个配置。

那为什么还值得看？因为它是一份罕见的、前沿实验室真实服务栈的完整剖面。这种东西平时只在论文的“实现细节”一节里出现三句话。

一、开源了什么，没开源什么

开源的部分：模型权重、TileLang 算子库、推理引擎本体、编解码组件。这条链路是完整的——从权重到算子到框架到 tokenizer 层，一家公司线上服务需要的东西基本都在。

没开源的部分，官方说得也挺直白：KV cache 存储系统、Prefill/Decode 分离（P/D disaggregation）、跨数据并行副本的负载均衡，这三块和内部基础设施耦合太深，没放出来。

这意味着什么？意味着你拿到的是一个能跑的引擎，不是一个能直接对外提供服务的服务。想做成 OpenAI 兼容的在线 API，还得自己补 KV cache 管理、请求调度和网关。这些活 vLLM 和 SGLang 已经替你干完了。

所以看到“DeepSeek 开源推理框架，vLLM 要完了”这类标题，可以直接跳过。README 里写得很清楚，它最初就是基于 vLLM 起步的，借鉴了 SGLang 和 TensorRT-LLM 的思路。它是站在这些项目肩膀上做极致优化的产物，不是替代品。

二、真正的技术增量在哪

我把官方 Q&A 和技术解读看了一遍，值得记的有三块。

第一块，Wide-EP 的工程结论。

Attention 层用数据并行，MoE 层用专家并行加一个专家负载均衡器（EPLB）。decode 阶段在超节点内跑 EP64 到 EP128，prefill 阶段用显存够用的最小 EP，通常是 EP2 到 EP8。

官方的性能曲线里有一张 EP8 对 EP64 的对比图，结论是 EP64 在每个 batch size 下都领先。这个结论对做 MoE 部署的人有参考价值：专家并行的宽度不是够用就行，宽了确实更快，代价是要有超节点。

第二块，DSpark，按置信度调度的投机解码。

常规投机解码是草稿模型每步猜 N 个 token，然后全部送去验证。DSpark 加了一个 Confidence Head，预测每个草稿 token 的接受概率，调度器只验证最有价值的那段前缀。

官方数据是验证的草稿 token 量减少约 30%（从 5.00 降到 3.2 到 4.4 之间浮动），而实际接受长度几乎没变，3.29 对 3.20。翻译成人话：同样的产出，少算了三成的验证量。这个思路不复杂，但把“验证预算”当成可调度资源来做，是个挺实用的角度。

第三块，SWA bounded replay。

滑动窗口注意力的状态在缓存命中时只需要重算最后 128 个 token，重算成本和上下文长度解耦。官方说在 decoder 层这能让 prefill 的总计算量接近减半。

长上下文场景里这是个硬收益。131072 上下文的 benchmark 里，prefill 在 4 张 SM100 上、每 rank 4096 token 时大约 6 万非缓存 token/s/GPU，到 65536 token 时接近 9 万，每步约 730 毫秒。

decode 侧的官方数字是：EP64DP64、每 rank 256 个请求时，单卡超过 25000 输出 token/s，单用户接近 100 token/s；请求数降到 8 时，单用户速度超过 300 token/s。单集群日处理 155 万亿 token。这些数字都是自报的，官方也标了是自报，看的时候心里打个折。

三、对普通开发者意味着什么

分三种人说实话。

个人开发者、小团队：继续用 vLLM 或 SGLang。不是 DeepInfer 不好，是它压根没打算服务你。一个模型、两种卡、离线推理，这三条里任何一条都够把你挡在外面。手上有一张 4090 想本地跑模型的，这篇新闻跟你无关，别被标题带着去折腾。

有昇腾集群的团队：这是这次最实际的价值。国产卡跑大模型的软件栈一直是短板，能同时支持 NVIDIA SM100 和昇腾 950 的生产级框架不多。虽然门槛高（构建要求 Linux、GCC 13 以上、Python 3.12、CUDA 13 或 CANN 9.2），但至少多了一个可评估的选项，而且是 DeepSeek 自己在线上跑过的。

做推理优化的工程师：值得把代码读一遍。三个点可以重点看：wide-EP 下的专家负载均衡怎么做的、投机解码的验证预算怎么调度、SWA 的 bounded replay 怎么把重算成本做成常数。这三个问题不分模型，换成别的 MoE 一样存在。官方还提了一句，开源版的 FlashMLA decode 算子比内部版慢 5% 到 10%，端到端差距在 5% 以内——这个差距本身也说明，框架层的优化空间和算子层的优化空间是两回事。

四、几个容易踩的坑

• 别指望它替代线上服务框架。缺 KV cache 系统和 P/D 分离，你补这部分的工作量可能超过自己写业务。
• • 别拿它和 vLLM 比通用性。一个支持 200+ 模型架构、一个支持 1 个，这个比较本身没有意义。要比就比同一个模型、同一批卡、同样的并发下的吞吐和延迟。
• • 注意“离线推理”这四个字。它是一批一批跑任务的形态，不是接在网关后面等用户请求的形态。想清楚你的场景再动手。
• • 硬件清单先对照。SM100 和昇腾 950，这两样都不是能随便租到的卡。

五、收尾

这次开源最有意思的地方不在性能数字，在于一个做模型的公司在往基础设施层延伸：权重开源了，算子开源了，现在连跑权重的引擎也开源了。对生态来说是好事，标准越透明，后来者踩的坑越少；对同行来说也是压力，以后“我们线上是这么跑的”会变成一个必须回答的问题。

至于普通打工人，看完这条新闻最该记住的可能是一句老话：benchmark 是自报的，架构选择是自己的。

你怎么看，评论区聊聊。