公告
🔥提供代码、复杂推理、多模态与智能体任务等领域的高质量原创任务数据，可添加：aiFreeCode 咨询
  1. 首页
  2. 精选文章
  3. DeepInfer 后，开源社区推理框架何去何从？

DeepInfer 后，开源社区推理框架何去何从？

  • 11 次阅读
  • 0 条评论

作者：刘景初
原文：https://zhuanlan.zhihu.com/p/2098528942038823244

10 月 20 日，DeepSeek 开源了线上服务用的推理框架 DeepInfer，它的技术设计我在《技术设计解读》里分析过。不出意料，其他开源推理框架快速跟进。之后一周，vLLM 和 SGLang 密集提了一批 PR，也各自发了博客，称已经追上 DeepInfer 的性能。追上性能之后，更大的问题是：这些开源框架何去何从？

1. DeepInfer 发布前的开源推理系统进展

9 月 10 日 V4.1 发布时，DeepSeek 开源的是模型权重和参考推理脚本。HuggingFace 权重仓库里带了一份 PyTorch 参考实现，覆盖 SWA 加压缩稀疏 attention、Engram、MoE、mHC 和 DSpark 的前向。

模型的部署说明里还提出了 SWA bounded replay 的思路，但没有给实现。同期也有一批 kernel 开源（如下）。但推理系统则是空白，给了 vLLM 和 SGLang 大显身手的空间。

组件 日期 内容
V4.1-Flash 权重 9-10 权重和 inference/ 参考实现；10-17 又发了 1017 版权重
FlashMLA 9-10 V4.1 的 SM100 稀疏 prefill / decode kernel，以及 Q-norm、RoPE、attention、输出 RoPE、FP8 转换融合在一起的 kernel（框架里叫 MegaAttention）；9-30 加了昇腾 950 版本，同时去掉了 Hopper 支持
DeepGEMM 9-10 Sparse Indexer、Mega Gate、Mega mHC；Mega MoE 是 4 月就开源的，9-30 加了 locality-aware 版本和昇腾版本
DeepSelect 9-10 新仓库，indexer 和采样用的 TopK kernel
DeepEP 9-29 V2.5：拆分 EP / Engram / PP buffer，加冗余专家权重预取原语。V2 是 4 月发的
deepseek-recipe 9-10 新仓库，API 请求格式转换、V4.1 prompt 渲染和输出解析；0.2.0 在 10-19 发布

站在 9 月 10 日这个时间点上，开源推理框架的系统层主要有这些工作需要补全：调度、P/D 分离、KV 传输、专家负载均衡、多机部署。两家各自动手补齐：

环节 vLLM SGLang
SWA bounded replay encoder 侧 #56227、decoder 侧 #58132，重放层分段进 CUDA graph #59532，再裁掉第 20 层多余计算 #59894。自报 prefill 计算时间降 30%～40% day-0 即支持两侧重放；10 月接进 breakable prefill graph #43736、DP attention #43812 和 P/D 两种角色 #45035。8×H200 上 prefill 吞吐 1.56 倍
P/D 分离与 KV 传输 NIXL 把 packed MLA 行注册为单一 region #61074；整行传输 #61121（open），每次传输的描述符从 11,118 个降到约 440 个；KV 已带窗口时跳过重放 #59197 DSpark 的 P/D #38949；decode 节点 DP attention #40177，prefill 节点 CP #40323；Mooncake 之外放行 NIXL #43734；prefill 完成后再分配 decode KV #40703
大 EP 与负载均衡 DeepEP V2 默认走 hybrid 模式 #57991；DSpark draft 模型支持 EPLB #57549；用对称内存迁移专家权重，并把副本映射融合进 MegaMoE #62009（open），DEP32 负载均衡度从 0.35 提到 0.94 DP attention 与 MegaMoE 打通 #43228；修复 MegaMoE 开 EPLB 后的精度问题 #44847，GSM8K 从 72.5% 回到 97.0%；共享专家融合进 MegaMoE #44837
调度与同步 DP 元数据同步改为低延迟 CPU all-reduce #61767，16 rank 时 p50 从 5.4 ms 降到 0.55 ms；限制每步新发起的异步 KV 加载数 #61725（open） HiCache 多级 KV 缓存；router 支持 V4.1 渲染和按缓存路由 #40532；prefill graph 支持任意长度，32 万 token 冷 prefill 从 6.6 s 降到 4.2 s #43733
硬件覆盖 recipe 覆盖 H200、GB200、GB300、MI350X；GB300 上 DEP4 prefill 加 DEP16 decode 的 P/D 配置（recipes#1137） day-0 覆盖 B200、B300、GB300、H200、MI350X；Hopper 专门优化 #41251，8×H200 每卡输出吞吐 2.1～2.3 倍

vLLM和sglang两家的工作重心有差别。

  • vLLM 在 9 月先把 bounded replay 和 W4A8 MoE 路径做完，10 月集中在多机：KV 传输、DP 同步、专家权重迁移，都是规模上去以后才出现的瓶颈。
  • SGLang 在 day-0 就带着 P/D、HiCache 和多种硬件，10 月的工作是把 bounded replay、MegaMoE、DP attention 和 P/D 互相接通，并在 Hopper 这类官方 kernel 不再覆盖的平台上自己补路径。

到 10 月 19 日，两家已经在 GB300 NVL72 上跑通了 P/D 分离加大 EP 的部署，并公开了一批测试结果。

框架 部署 每卡吞吐 @ 每用户 P90 来源与状态
vLLM GB300，7 个 DEP2 prefill + 1 个 DEP16 decode，NIXL，并发 4800 516K tok/s @ 153 tok/s #61725，open，开发树
SGLang GB300 单节点 DEP2，并发 128 284K tok/s @ 91 tok/s InferenceX #4033，10-16 合入
SGLang GB300 NVL72，2P5D（14 卡），Mooncake + HiCache，并发 240 104K tok/s @ 193 tok/s，缓存命中 96.7% InferenceX #3860，本地测试，未合入
SGLang GB300，6 个 DEP2 prefill + 1 个 DEP16 decode，8 节点，并发 2884 数值只在 InferenceX 看板上 InferenceX #4180，10-19 合入

注：负载都是 SemiAnalysis 的 AgentX 多轮 agentic trace，吞吐包含缓存命中的输入 token，所以每卡 tok/s 数值很大。

单看 decode，vLLM 在 GB300 NVL72 上用 DEP32、每 rank 128 个请求，加上 EPLB 后单个 decode 实例的输出达到 897K tok/s，MegaMoE 耗时从 14.65 ms 降到 7.63 ms（#62009，open）。

这些数字里规模最大的几组还在 PR 里，没有进稳定版，但部署形态已经齐了：官方 kernel 在下面支撑，P/D 分离、KV 传输、DP attention 加大 EP、专家负载均衡由框架自己实现，可以部署在整机柜上。DeepInfer 开源时，两家已经在部署优化上走了挺远。

2. 社区开源框架从 DeepInfer 吸收了什么？

DeepInfer 用到的 kernel 在 9 月已经开源，两家也早已接入，所以开源后能从它身上拿到的新东西集中在 kernel 以外：数据格式的定义、调度规则、部署运维的做法，以及少量算子融合的细节。

10 月 20 日到 27 日，两家在描述里明确引用 DeepInfer 源码或文档的 PR 和提案如下，除 SGLang #46163 外都还没有合入。

参照的 DeepInfer 部分 框架 PR 做了什么 自报效果
KV 格式定义 V41_FORMAT SGLang #45851（10-22） 在 SM120（RTX 50、RTX PRO、DGX Spark）上启用 V4.1 的 KV 格式 压缩 KV 每 token 584 B 降到 288 B；decode attention 单次 16.1 µs 降到 10.0 µs
prefill 调度器的上下文总长上限 vLLM #63035（10-22） 每个 prefill 步除了限制新 token 数，还限制这些 chunk 要读的上下文总长 针对 B200 DEP4 上单个 rank 的 prefill 步超过 10 s、其他 rank 空等的问题；未给吞吐数据
重放规则 clip_prefix vLLM #62817（10-21） 离 prompt 末尾较远的 prefill chunk 只重放 1 行 124K prompt 的单请求 TTFT 降 2.4%
部署文档里的 decode 缩容流程 vLLM #63702（10-26） 要下线的引擎把未完成的请求连同 KV 交给其他引擎继续解码 接手引擎的首 token 中位数 104～405 ms，不用整段重算
DSpark 运行时代价反馈 SGLang #45536（10-21） 用实测的步耗时在线修正投机验证的代价表 作者未声称加速，GSM8K 不变
跨层运行时 CrossLayerRuntime vLLM #63293（10-23） 同一个索引源层的稀疏索引只构建一次，后面的层复用 索引构建 kernel 快 3.6～4.5 倍；未给端到端数据
mHC 与 MoE 之间的 buffer 边界 SGLang #46163、#46056（10-23） mHC 直接把 FP8 激活写进 MegaMoE 的输入 buffer，省掉每层一次量化 decode 每步省 0.02～0.05 ms；prefill 提升 0.1%
DSpark 置信度头的融合 kernel vLLM #62840（10-21） 四次小 kernel 合成一个 TileLang kernel，权重保留 FP32 kernel 快 1.9 倍，TPOT 提升不到 0.05%
Engram 表放 host 加异步预取 SGLang #45777（10-22） 提案，跨层提前取 Engram 行，和计算重叠 尚无代码

按收益看，这些工作分成三类。

第一类是格式对齐。

V4.1 的 KV 格式在 checkpoint 自带的参考实现里就有，DeepInfer 的 V41_FORMAT 给了一份生产实现可以互相印证。SGLang 原来只在 SM100 上用这套格式，其他 Blackwell 卡一直走 V4 的旧格式。

改过来以后压缩 KV 体积减半，attention 快约 40%，误差也更小。这一类改动量小、收益直接，前提是有一份权威的格式定义可以对照。

第二类是调度和部署规则，也是开源后增加最多的一类。

按上下文总长限制 prefill 步、远离末尾的 chunk 少做重放、decode 缩容时把 KV 交给其他引擎、按实测耗时修正投机验证的代价，这些规则写在 DeepInfer 的调度器代码和部署文档 inference_deployment_qa.md 里，之前的 kernel 开源和论文都没有给出。

它们对应的问题只在大规模线上服务时才明显：单个 rank 卡住整个 DP 组、长尾请求占着整个 decode 实例不能下线、负载变化后离线代价表失准。现有 PR 的自报收益不大，有的还没测，但补的是框架以前没有参照的部分。

第三类是算子融合的细节，收益最小。

mHC 直写 MegaMoE buffer、置信度头融合，单个 kernel 能快一倍，摊到每步只有零点几个百分点，因为大头的融合在 DeepSeek 9 月开源的 Mega 系列 kernel 里已经做完了。

作者在 PR 里也说明，价值主要在减少 kernel 启动和 CUDA graph 节点数。

此外，SGLang 在 10 月 20 日到 24 日把 chat 模板、输出解析和原生端点都改成调用 DeepSeek 官方的 deepseek-recipe 0.2.0（#45315、#45907、#46219），删掉了自己维护的编码实现。这一项参照的是 DeepSeek 单独发布的库，不来自 DeepInfer，方向相同：模型相关的定义以官方实现为准，框架不再各自维护一份。

开源一周后，两家从 DeepInfer 里拿走的主要是格式定义和线上调度规则，kernel 层面没有新东西可拿。

3. 在一个模型厂具有顶尖部署工程能力的世界，社区部署框架的价值？

DeepInfer 的 README 把开源范围写得很清楚：支持的模型只有 DeepSeek-V4.1-Flash，硬件只有 NVIDIA SM100 和昇腾 950；完整服务还需要的 KV 缓存系统、VE/P/D 分离和跨 DP 副本的负载均衡，这次都没有包含。它是一台为一个模型、一种机柜级部署形态调好的引擎。vLLM 和 SGLang 的覆盖范围正好相反，下表按 README 列出的几项对照。

范围 DeepInfer 开源版 vLLM SGLang
模型 V4.1-Flash 覆盖主流开源模型，V4.1 是其中一个
硬件 SM100、昇腾 950 H200、GB200、GB300、MI350X；昇腾走 vllm-ascend B200、B300、GB300、H200、MI350X；SM120 在补（#45851）
KV 缓存系统 未包含 CPU 与文件系统 KV offload、Mooncake 连接器 HiCache 三级缓存，L3 接 Mooncake
P/D 分离 未包含（引擎侧功能大部分已实现） NIXL 传输，配合 Dynamo 编排 Mooncake、NIXL、MoRI 三种传输
跨副本负载均衡 未包含 交给 Dynamo、llm-d 等外部编排层 自带 router，按前缀缓存路由

开源后社区往 DeepInfer 仓库提的 PR，也集中在这张表的空白处。仓库开源 11 天收到 211 个 PR，207 个来自外部贡献者，到 10 月 27 日合入 2 个，一个是 DeepEP 版本更新，一个是环境变量校验。

还开着的 PR 里，有 Hopper 移植（#92、#148、#180）、AMD ROCm 后端（#201）、Trainium、MLX、RTX 5090、昇腾 910B，也有 Mooncake 的 KV 传输和 L3 缓存（#214、#216）、host 前缀缓存和跨机 P/D 服务。

社区在做的，是把 DeepInfer 往通用框架的方向补，补的内容 vLLM 和 SGLang 大多已经有了。编排层也在找接入点：llm-d 在开源当天开了 #2892，讨论把 DeepInfer 的 DSpark 和 bounded replay 与自己的路由编排结合。

这些空白里，硬件覆盖对开源框架的要求最高。DeepSeek 的 V4.1 kernel 主要针对 SM100，FlashMLA 在 9 月 30 日去掉了 Hopper 支持，其他平台要靠框架自己写。

SGLang 社区有人在 8×H20-3e 上对比了 SGLang 和 DeepInfer 的社区 Hopper 移植版（#46310）：8K、16K 输入时 SGLang 输出吞吐高 19% 和 6%，32K、64K 时低 16% 和 26%。

差距主要来自 indexer 打分：SGLang 的 SM90 路径对整个可见前缀打分，64K 时每轮 decode 耗时 9.4 ms，移植版只对候选块打分，耗时 1.0 ms。官方 kernel 覆盖不到的平台上，算子层的工作还要框架自己做，开源框架在这些平台上仍要继续投入 kernel。

4. 结论

回到开头的问题。DeepInfer 开源前一个多月，vLLM 和 SGLang 已经接入 DeepSeek 开源的 kernel，自己补齐了 bounded replay、P/D 分离、KV 传输和大 EP 负载均衡，在 GB300 NVL72 上跑到了和 DeepInfer 同一水平。所以开源后的性能对比里，两家能很快拿出追平的数字。

开源之后，两家的工作分成两个方向。

一是读 DeepInfer 的源码，吸收它在格式定义和线上调度规则上的做法：KV 格式对齐、prefill 步按上下文总长限流、decode 缩容时迁移 KV、投机验证的代价在线校正。这些经验在 kernel 开源和论文里都没有，只有生产系统的代码和部署文档才会写下来。

二是继续做 DeepInfer 不覆盖的部分：多模型、多硬件，以及 KV 缓存、P/D 编排、跨副本路由这一层服务系统。社区往 DeepInfer 仓库提的 PR，补的也是同一批空白。

开源框架的方向和开源前一致，多出来的是一份可以逐行对照的生产实现。以前要从论文和 kernel 倒推 DeepSeek 的系统怎么搭，现在可以直接对照源码，算子和调度层的差距会收敛得更快，框架之间的差别会更多落在硬件覆盖和服务层的完整度上。

对使用者来说，在 SM100 机柜上部署 V4.1-Flash，可以直接参考 DeepInfer；要同时服务多个模型、使用 Hopper 或 AMD 等其他硬件，或者需要缓存和 P/D 编排的，仍然以 vLLM 和 SGLang 为主。

DeepInfer 是一个模型、一种部署形态的参考实现，也是开源框架的催化剂；

多模型、多硬件，以及缓存、分离、路由这一层服务系统，是开源框架的主战场。

两者从不同角度，给开源生态提供着生命力。

5. 参考资料

DeepSeek 开源组件

vLLM

SGLang

测试与编排

阅读 -- 次

上一篇

RL 之外（2）！不靠训练样本，一文讲透扩散模型无监督训练的三条新路径

讨论

0 条评论

登录后即可参与讨论、向作者提问

目录
正在直播 B 站

进入 B 站直播间
视频号直播二维码

用微信扫一扫，在视频号观看直播