DeepInfer vs vLLM 差在哪：DeepSeek 开源了自家推理引擎，但它不是来取代 vLLM 的

先给判断：DeepInfer 不是 vLLM 的竞品，而是 vLLM 的一个「单模型特化分支」——它把 DeepSeek 自己的模型、自己的负载、自己的硬件，用一套为这三件事量身定做的引擎跑到了极致。 对绝大多数人，它今天的价值是「读」，不是「换」。下面只拆架构和依据，不复述新闻稿。

为什么是这个时间点

2025 年 4 月，DeepSeek 曾公开表示自家服务引擎与内部系统耦合太深、没法开源（据 technology.org 对当时表态的回溯）。一年半后，2026 年 10 月 20 日，它把 DeepInfer 以 Apache 2.0 放上了 GitHub，README 第一句就是：这是「驱动 DeepSeek 大规模生产服务的推理框架」。

这个时间点补的是哪块拼图？DeepSeek 过去两年陆续开源了 FlashMLA、DeepGEMM、DeepEP、TileLang 这些「零件」，但零件之间怎么组装成一台日吞吐以万亿 token 计的机器，外界只能猜。DeepInfer 把组装图交出来了：配套的《V4.1 Flash 推理部署 Q&A》（仓库 doc/inference_deployment_qa.md）写明，单个集群目前每天服务 155 万亿（155T）token、谷时电价口径下每 GPU 小时收入 38 美元。注意口径：这两个数字来自 DeepSeek 自家的生产系统（含未开源部分），不是这个仓库单独跑出来的成绩，后文会拆开讲。

还有一个信号不在代码里：支持硬件清单上，NVIDIA SM100 和华为 Ascend 950 并列出现，且 Ascend 侧有独立的内核与构建路径（CANN 9.2）。在主流开源推理框架里，把昇腾当一等公民的，DeepInfer 是第一个。

DeepInfer 是什么：以官方文档为准

只列仓库 README 与部署 Q&A 能证实的点：

• 只支持一个模型：DeepSeek-V4.1-Flash，默认权重 deepseek-ai/DeepSeek-V4.1-Flash-1017。未来模型的推理代码会继续放进这个仓库（Q&A 原话），但今天就是单模型。
• 只有离线推理：入口是 examples/offline_inference.py，README 明说这次发布的是 offline inference。在线服务必需的三件套不在发布内：KV cache 系统、VE/Prefill/Decode 分离（引擎侧功能大部分已实现）、跨 DP 副本的负载均衡，要自己补。Q&A 也承认 KV cache 管理与负载均衡组件与内部基础设施耦合太深、尚未完全开源——设计细节写在它的知乎长文里，代码没给。
• 内核栈是 DeepSeek 全家桶：FlashMLA、DeepGEMM、DeepEP、TileKernels、DeepSelect 加 TileLang 定制内核（README 列明）。Q&A 还透露了一个诚实的细节：开源版 FlashMLA 少了一处手工调优的 SASS 优化，解码内核比内部版慢约 5%–10%，端到端差距在 5% 以内。
• 并行策略围绕 MoE 与超大解码集群：Attention DP / balanced CP、MoE EP + EPLB。生产部署形态是分离式 E/P/D 架构：Prefill 用 EP2–8 的普通 8 卡机，Decode 用 EP64–128 的「Wide-EP」超节点；最小可部署 1P+1D，但官方口径里最小高效单元是 64 卡 Prefill + 64 卡 Decode。
• DSpark 投机解码：用 Confidence Head 预测每个草稿 token 的接受概率，按边际收益分配验证算力，而不是固定验证 5 个。Q&A 给了实测口径：动态长度验证把每步验证的草稿数从 5.00 降到 3.2–4.4，平均接受长度基本不变，在生产工作点（约 60 并发/ rank）换来 +4–7% 吞吐；但低并发（16 并发）时是 −1.5%，这不是免费午餐。
• SWA 有界重播（bounded replay）：滑动窗口注意力的 KV 命中后只需重算最近 128 个 token，重算成本与上下文长度无关；decoder 侧只重播尾部，使 prefill 计算量近乎减半（Q&A 原话）。
• 异步调度：CPU 在 GPU 执行第 N 步时并行做第 N+1 步的调度，消掉调度空泡，README 称之为 zero-overhead batch scheduler，实现思路注明参考了 SGLang、NanoFlow。
• 确定性：batch-invariant inference（结果不随 batch 组成变化）与 deterministic sampling（同输入同参数必同输出）——但仅限 NVIDIA 平台，昇腾侧未提供。
• 结构化输出：regex / JSON schema / EBNF 三种约束，编译与推理解耦，编译在专用机器上异步完成。
• 生产 KV cache 的设计（未开源，仅设计披露）：块 KV 放在独立的 3FS 存储集群（约 100 PiB SSD），TTL 按流量类型 3–7 天，目标是 KV 保留 72 小时以上；官方生产口径的输入缓存命中率 96%、平均 TTFT 约 400ms、生成速度 230 tokens/s（代码场景最高 300）——再次提醒：这是完整生产系统的数字，其中缓存层正是没开源的那部分，你下载这个仓库复现不出来。

血统上没什么可猜的：README 的 Acknowledgments 明说 DeepInfer「originally built primarily on vLLM」，另借鉴了 SGLang 与 TensorRT-LLM。所以这篇文章的对比，本质是「原版通用引擎 vs 它长出来的特化后代」。

对比表：每一格都要有依据

vLLM 基线以其官方文档（docs.vllm.ai）当前版本为准：核心是 PagedAttention（KV cache 分块、像操作系统虚拟内存一样按需分配）+ continuous batching（迭代级调度，请求随到随进、随完随出），外加 chunked prefill、prefix caching、投机解码等；支持 200+ 模型架构，硬件覆盖 NVIDIA / AMD / 多种 CPU 及 TPU、Gaudi、Ascend 等插件；提供 OpenAI 兼容 API server、Anthropic Messages API 与 gRPC。

有两格我特意不写数字：双方都没有在同一硬件、同一负载下由官方给出的 head-to-head 对比，任何「快 X%」的格子都是编造。

差在哪：3 点核心判断

第一，它优化的不是「推理」，是「一种负载」。 vLLM 的假设是：你有很多种模型、很多种请求形状，要在有限显存里把并发塞满。DeepInfer 的假设完全不同：只有一个 MoE 模型、平均提示长度以万 token 计（生产口径平均 prompt 约 77K，见第三方对部署报告的转述）、缓存命中率能做到 96%、解码集群 64–128 卡起步。DSpark、SWA 有界重播、72 小时 KV 保留、按上下文长度分档的 prefill 负载均衡——每一个机制都是对着「长上下文 + 超高缓存复用 + 超大规模 MoE 解码」这一副牌打的。你的负载不是这副牌，这些机制对你就大多不成立。

▲ 两种负载形状：左列数字出自 DeepSeek 官方部署 Q&A 的生产口径（含未开源组件，本仓库不可复现）；平均 prompt 约 77K 为第三方转述官方部署报告的口径；右列为定性对比

第二，它和 DeepSeek 自家模型是共生关系，不是上下游关系。 引擎只服务 V4.1-Flash 一个模型，SWA 有界重播直接依赖 V4.1 的层结构（前 20 层存状态、YOCO 式投影），低精度格式（MXFP4 权重、per-16 e4m3 KV）也是按自家权重量身定的。换句话说，DeepInfer 是 DeepSeek 模型发布的配套基础设施：模型开源解决「你能拿到权重」，DeepInfer 解决「你能像官方一样跑」——顺带把昇腾生态、正版 API 行为（deepseek-recipe 与官方 API 编解码逻辑对齐）一起铺了。这盘棋下的是部署侧的话语权，不是引擎市场的份额。

第三，对 vLLM 生态的实际影响是「抬表」而不是「换表」。 发布几小时后 vLLM 官方就在 X 上宣称：用 Wide-EP + EPLB，vLLM 的解码性能与 DeepInfer 相差 6% 以内、每 GPU 小时收入约 39 美元（按 DeepSeek 谷时价折算，与官方 38 美元口径几乎贴脸）——这是 vLLM 维护者自测口径、非独立验证，但它说明一件事：DeepInfer 的关键招式（Wide-EP、EPLB）vLLM 本来就有或很快能补。真正的增量在那些还没进 vLLM 的机制：置信度调度验证、SWA 有界重播、确定性采样。接下来半年值得看的是 vLLM/SGLang 会吸收哪几个，而不是谁宣布「胜出」。

局限与待观察

• 第三方实测刚出现，且互相打架。 warmctl 在 8×B300 上测得 vLLM 在 decode 与 prefill 上全面领先（其口径为随机 token 负载，作者自己也指出随机 token 让 EPLB 的专家重分配无从发挥）；GPUStack 在 8×B200、100 个请求的小样本里测得 DeepInfer 改造版吞吐高约 25%、但 TTFT 约为 vLLM 的 2.09 倍。两份都是单方小样本、配置不可比，现阶段只能得出一个结论：离开 DeepSeek 的生产负载形状，DeepInfer 的优势不自动成立。HN 讨论热度（两千多分）证明的是关注度，不是性能验证。 ▲ 两份第三方实测并排：均为单方小样本，硬件（B300 / B200）与负载口径不可比，不可直接对比输赢

• 官方性能图的读法有个坑：第三方拆解（zyvop、explainx.ai）指出其 examples 文档中 decode 吞吐按「全接受」口径计账（每步按 1+草稿数 记满），已发布曲线用没用这个口径、用了哪档接受率缩放，仓库里没有写明。对比任何引擎前先对齐这个设置。

• 未披露/未开源清单：KV cache 系统代码、负载均衡组件代码、生产环境完整的调度参数、Ascend 侧的性能数据（官方基准全在 SM100 上）、除 V4.1-Flash 外任何模型的支持时间表。把「未披露」本身当结论：这次开源给的是引擎与部署学，不是可复制的整套生产系统。

• 上手成本不低：源码构建、GCC 13 + Python 3.12 + CUDA 13/CANN 9.2 的版本矩阵、只支持两款数据中心加速器；没有 Release、没有镜像、提交历史只有 4 次。今天 clone 下来，大概率先卡在构建。

对国内开发者的实际启示

• 正在用 vLLM 跑 Qwen/Llama/GLM 等多模型服务的：什么都不用动。 DeepInfer 不支持你的模型，vLLM 官方已表态关键机制在射程内，你的升级路径还是跟着 vLLM 版本走。
• 计划自部署 DeepSeek V4.1-Flash、且手里有 SM100 或 Ascend 950 的：值得进试点名单，但试点目标设成「用它自带的 sweep 脚本在你的真实 prompt 分布上复测」，不要拿官方 Pareto 图当采购依据；同时预算里留出自研/自备 KV cache 与负载均衡的人力，这部分才是它生产性能的大头。
• 在昇腾生态做交付的：这是今年最重要的信号之一。 一线模型厂把自家生产引擎对 Ascend 950 做了同等支持，还给了 CANN 版本口径。哪怕暂时不用，也值得把 Q&A 里 Ascend 相关的部署约束先摸清。
• 做技术选型/售前方案的：把部署 Q&A 当教材读，155T 那个数字先放一边——按上下文长度给 prefill 分档配额、用时间预算反解 chunk 大小、KV 按 3 天/7 天 TTL 分层、解码集群的优雅下线与 KV 迁移，这些是花钱也买不到的一线生产经验，且与引擎选型无关，抄的是思想不是代码。

一句话收束：vLLM 解决「把模型跑起来」，DeepInfer 展示「把一个模型跑到极致」；前者是工具，后者是样板间——样板间值得参观，但你家装修照抄之前，先量量自己的户型（负载）对不对。

参考与依据（2026-10-24 查阅）：

• DeepInfer 仓库 README 与 doc/inference_deployment_qa.md：https://github.com/deepseek-ai/DeepInfer
• vLLM 官方文档首页（特性与支持范围）：https://docs.vllm.ai/en/latest/
• 第三方实测：warmctl《DeepSeek-V4.1-Flash on 8×B300: vLLM vs DeepInfer》；GPUStack（Medium）《DeepInfer vs. vLLM on 8× B200》——均为单方小样本，引用时已注明口径
• vLLM 官方「相差 6% 以内」表态与生产数字口径辨析：explainx.ai、latent.space 的发布复盘（转述，已注明非独立验证）