10 月 20 日DeepSeek 把自家线上服务用的推理框架 DeepInfer 开源了Apache 2.0 协议可以商用。同步放出来的还有 deepseek-recipe一个 MIT 协议的 token 编解码组件官方说它的处理逻辑和 DeepSeek API 对得上。这条消息在知乎和 Reddit 的 r/LocalLLaMA 上都挂了几天讨论集中在两件事显存占用、部署成本以及“跟 vLLM、SGLang 比到底谁快”。先把冷水泼在前面这个框架普通开发者基本用不起来。它只支持 DeepSeek-V4.1-Flash 一个模型只支持离线推理硬件只认 NVIDIA SM100Blackwell和华为昇腾 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 的思路。它是站在这些项目肩膀上做极致优化的产物不是替代品。二、真正的技术增量在哪我把官方 QA 和技术解读看了一遍值得记的有三块。第一块Wide-EP 的工程结论。Attention 层用数据并行MoE 层用专家并行加一个专家负载均衡器EPLB。decode 阶段在超节点内跑 EP64 到 EP128prefill 阶段用显存够用的最小 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 是自报的架构选择是自己的。你怎么看评论区聊聊。