AI惊叹号 - 推理引擎全知道：DeepInfer 开源了，但只开了半套

DeepInfer 交出来的，是一套完整引擎还是半套？

先看它是什么。10 月 20 日，DeepSeek 在 GitHub 放出 DeepInfer，Apache 2.0 协议，定位写得很清楚：offline inference，离线推理。跑的是自家大规模生产服务那一套。

支持的模型只有一行：DeepSeek-V4.1-Flash。不是「DeepSeek 全家」，就这一个。

评论区有人问，为什么不支持 V3。答案在 README 的结构里——它把融合算子和这个模型的结构绑死了。

再看它给了什么。我按 README 的清单数了一遍：FlashMLA、DeepGEMM、DeepEP、TileKernels、DeepSelect 五套算子，加一套 TileLang 写的自定义 kernel；并行上支持 Attention DP、平衡 CP、MoE EP 加 EPLB；解码上有一套叫 DSpark 的投机解码，默认草稿长度 5；此外还有 SWA 有界重放、异步调度、批不变推理、确定性采样、结构化输出。

这个清单不短。但往后翻几屏，有一段用词很克制的话：

三行，三样。KV Cache 系统、PD 分离、跨数据并行副本的负载均衡。

这三样不是边角料。KV Cache 决定你能同时服务多少人；PD 分离决定长请求会不会把短请求拖死；跨副本负载均衡决定你加了十台机器之后，是不是真的一起在干活。

换句话说，DeepSeek 公开的是一台机器怎么跑到极限，没公开的是一百台机器怎么排班。

还有一处细节值得留意。README 末尾的致谢写：DeepInfer 最初主要构建在 vLLM 之上，另外参考了 SGLang 和 TensorRT-LLM。这句话很实在，也解释了为什么它能在一个开源项目里直接给出生产级配置——它站在别人的骨架上，换了自己的肌肉。

同一个 V4.1 Flash，换引擎凭什么快三倍？

要回答这个问题，得先把推理拆成两段。这两段的瓶颈完全不是一回事。

Prefill 是算力活。用户把几千个 token 一起丢进来，模型要一次性算完这些 token 的注意力。矩阵乘一个接一个，张量核心跑满，这时候卡在算力上。

Decode 是搬运活。每生成一个 token，都要把模型权重从头读一遍，再把这个 token 和前面所有 token 做一次注意力。权重几百 GB，一次只算出一个字。这时候卡在显存带宽上，算力单元大半在等数据。

搞清这两段，很多「玄学加速」就变得很朴素了。

Prefill 端最常见的浪费，是长短请求混在一起。一个 20 万 token 的文档总结排在最前面，后面三十个短问答全得等它。引擎的做法是分块 prefill：把长请求切成小块，和短请求交替着算。GPU 不空转，短请求也不用等到天荒地老。

Decode 端的浪费更隐蔽。单条请求解码时，权重读一遍只产出一个 token，带宽几乎全浪费。解法是批处理：把几十上百条请求拼成一批，权重只读一次，产出几十上百个 token。批越大，摊得越薄。

DeepInfer 官方给的压测配置，恰好把这件事说透了：prefill 用 4 张 SM100，decode 用 64 张 SM100。同一个模型，解码侧要十六倍的卡。这不是浪费，是解码本来就该用堆机器的方式去摊薄权重读取。

所以「换个引擎快三倍」这件事，绝大部分不来自某个神奇 kernel。它来自三件很土的事：长请求别再堵路、解码尽量拼大批、前缀别重复算。

vLLM 当年靠 PagedAttention 把 KV Cache 切页管理，解决的就是「显存碎片导致批大不了」。SGLang 用 RadixAttention 做前缀树复用，解决的是「多轮对话每轮都把系统提示词重算一遍」。DeepInfer 在这两条路上都继承了，再叠加自己的算子。

你把这三件事任何一件做对，都能看到肉眼可见的提升；三件都做对，才有资格谈倍数。

长文本读到一百万 token，时间到底花在哪？

先算一笔显存账。这笔账很多人没算过，算完就明白长上下文为什么贵。

KV Cache 的大小，跟 token 数成正比。假设一个 60 层的模型，用 8 个 KV 头，每个头 128 维，FP8 存一个字节。那么每个 token 的 KV 占用大约是：

一个 token 120 KB。十万 token 是 12 GB，一百万 token 是 120 GB。

120 GB 是什么概念？一张 80 GB 的卡装不下。这还没算模型权重本身。

更麻烦的是解码阶段。每生成一个新 token，都要把前面所有 token 的 KV 读一遍。序列越长，每一步要搬的数据越多，而算力还是只算一个 token。这就是为什么长上下文对话到了后面，吐字会肉眼可见地变慢。

DeepInfer 里有一个参数专门对付这件事：DEEPINFER_YOCO_PREFILL_KEEP_TOKENS=140。开启 compact 模式后，解码前的 prefill 只重放一段有界的后缀，默认保留 140 个 token。

140 这个数字不是拍脑袋。README 补了一句：保留的后缀必须覆盖 SWA 窗口，再加上最大回溯长度。也就是说，模型在滑动窗口注意力下真正会回头看的范围有多大，这段就得留多长。留短了，结果会错；留长了，白算。

这也是推理引擎里最常见的取舍：不是「能不能算」，是「能不能少算一点还不算错」。

所以长文本场景的瓶颈，早就不是 FLOPS 了。它卡在三件事上：KV 装不装得下、每步搬得动搬不动、有没有一段可以安全跳过的历史。

装不下就上分页和分层存储；搬不动就上 GQA、MLA 这类压缩注意力的结构；跳得过的部分，就靠 SWA 窗口加回溯边界去截。三条路，每条都在赌一件事——赌模型不需要看那么远。

MoE 并行省下的时间，被哪一段通信吃掉了？

MoE 模型的卖点是「参数多、激活少」。总参数几百 B，一次只激活几十 B。听着很省，但省下来的算力，很容易被通信吃回去。

原因是专家被切到了不同的卡上。一个 token 进来，路由说它该去 2 号卡的第 7 个专家和 5 号卡的第 3 个专家，那这个 token 的隐藏状态就得先发过去，算完再发回来。这叫 all-to-all，是 MoE 并行里最贵的一步。

DeepInfer 的策略写在并行那一行：Attention 用 DP 加平衡 CP，MoE 用 EP 加 EPLB。

前一半好理解，注意力部分按数据并行切开，序列太长时再用上下文并行摊。关键是「平衡」两个字——切上下文的时候，各张卡分到的计算量得差不多，不然一张卡算完了在等另一张。

后一半是 EPLB，专家并行负载均衡。这是 MoE 推理里最容易被忽略的一环。

训练好的 MoE，专家热度天然不均。有的专家被 30% 的 token 选中，有的只有 0.5%。如果按平均分，热门专家所在的那张卡就会变成整批的瓶颈——其它卡都算完了，等它一个。

EPLB 干的事，是把热门专家复制几份放到不同的卡上，再把冷门专家挪走。代价是显存，收益是整批不再被一张卡拖住。

这件事在单机八卡上不明显，在几十卡的集群上会突然变得要命。因为 all-to-all 的延迟随规模上升，负载不均的放大效应也随规模上升。

所以「MoE 省算力」这句话只对了一半。它省的是乘加，付出的是通信和调度。引擎的价值，就在于把这份通信压在计算后面，让它别浮出水面。

投机解码的快，落到你的业务上还剩多少？

投机解码的思路很简单：先用一个小模型（或者模型自己的一个轻量头）猜出后面 5 个 token，再用大模型一次性验证这 5 个。猜对了就白赚，猜错了就退回去重算。

DeepInfer 里这套叫 DSpark，默认草稿长度 5，环境变量是 DEEPINFER_ENABLE_MTP_VARLEN=1，上限由 DEEPINFER_USE_NEXTN_DECODE 控制。

真正的关键是「置信度调度验证」这几个字。它不是在猜完之后无脑验证，而是先用置信度估一下这串草稿值不值得验。

为什么要在意这个？因为验证不是免费的。草稿越长，验证一次要算的位置越多。如果接受率只有三成，你花在草稿和验证上的算力，可能比老老实实解码还多。

这就是为什么同一套投机解码，在代码补全上效果惊人，在开放写作上却很一般。代码的下一个 token 高度确定，接受率高；自由写作下一个词有无数种写法，草稿基本靠猜。

所以看到「投机解码提速 2 倍」这类说法，先问三个问题：什么任务、草稿多长、接受率多少。这三个数不报，倍数就没有意义。

DeepInfer 里还有两个容易被跳过的开关，值得单独说。

DEEPINFER_BATCH_INVARIANT=1 打开批不变推理：同一个请求，不管跟谁拼在一批里，输出都一样。再配上 DEEPINFER_ENABLE_MTP_VARLEN=0 和固定 seq_seed，可以做到确定性采样——同样的输入和参数，每次输出完全一致。

这两个开关在聊天场景里没什么用，但在对账、审计、金融回测里是硬需求。很多团队上线之后才发现，模型输出会因为批次不同而漂移，日志对不上，排查一周。

代价写在 README 里：这两项只在 NVIDIA 上支持。

三家都说快了三倍，它们量的其实是三件事

这周有三个「快」的数字同时在传。

DeepInfer 开源当天，HN 首页 2043 分、800 条评论，全站第一。这是热度，不是性能，但它决定了有多少人会去读那份 README。

是石科技的 TokenFleet 集群调度框架，报的是首 token 延迟降低 32.4%。注意，是首 token，也就是 prefill 那一段的等待时间。

九章云极的 Alaya-DFlash2，报的是让 GLM-5.3 的长文本解码提速 3.41 倍。注意，是解码，而且是长文本这个特定负载。

还有一条容易被漏掉：Google 同期开源了 TorchTPU，给 PyTorch 加 TPU 原生后端，HN 197 分。它不报倍数，报的是「多了一条硬件路」。

四个数字放在一起，你会发现它们根本不在一个坐标系里。一个量等待，一个量吞吐，一个量社区注意力，一个量硬件选择权。

这就是「快 N 倍」最容易骗人的地方。倍数是一个比值，分子分母换个定义，结果能从 1.2 变到 5。

看这类数字，我一般按三步走。

第一步，问负载。是 128 token 的短问答，还是 20 万 token 的长文档？两者的瓶颈一个在调度，一个在带宽，优化手段完全不同。

第二步，问基线。对比的是原版 vLLM，还是某个没调过的内部版本？很多「提升 3 倍」，基线是一个连连续批处理都没开的服务。

第三步，问复现。有没有给压测脚本、硬件型号、batch 大小？DeepInfer 这点做得不错，README 直接写了 4 卡 prefill、64 卡 decode，还给了复现脚本的路径。给了这些，数字才有讨论的基础。

昇腾那一栏，为什么只挂了一个模型？

DeepInfer 的支持硬件写了两行：NVIDIA SM100 GPU，华为昇腾 950 NPU。

在国内的开源推理框架里，这个组合不常见。大多数项目要么只做 CUDA，要么把国产卡放在一个单独的 branch 里，隔几个月同步一次。DeepInfer 把它写进了主 README。

但紧接着就有一个细节：支持的模型仍然只有 V4.1 Flash 一个。

这不是偷懒。前面说过，它的融合算子跟模型结构是绑定的——FlashMLA 对应 MLA 注意力，DeepGEMM 对应特定的矩阵形状，DeepEP 对应 MoE 的专家切分。换一个模型，这些 kernel 就得重写。

所以「支持昇腾」这四个字，准确的含义是：这一个模型，在这一套算子上，能在昇腾 950 上跑起来。不是「DeepSeek 全家都能跑」，也不是「你的模型改两行就能跑」。

构建环境也能看出门槛：Linux、GCC 13 以上、Python 3.12，NVIDIA 侧要 CUDA 13，昇腾侧要 CANN 9.2。两套工具链，两条编译路径。

对国内团队来说，这件事的意义在另一个层面。训练侧被卡得最紧，推理侧反而是国产卡最有机会的地方——因为推理对精度的容忍度高，对生态的依赖浅，而且需求量大、负载稳定。

但「能跑」和「跑得划算」之间，还隔着一整套调优。同样的模型，在昇腾上要重新找 batch 大小、重新调并行切分、重新验证数值一致性。这些工作不会因为 README 写了支持就自动完成。

所以这一栏更像一个路线图信号：DeepSeek 在生产里真的用了昇腾，而且愿意把这条路径公开。至于你的业务能不能直接用，得看你的模型是不是那一个。

vLLM、SGLang、TensorRT-LLM、DeepInfer，你的场景该选哪个？

这四个不是同一层的东西，但经常被放在一张表里比。先把它们的定位分清楚，选型就没那么纠结了。

如果只想要一句话建议：

先上 vLLM。它的模型覆盖能让你在两周内把所有候选模型跑一遍，这个阶段谈极致性能没意义。

前缀复用占比高，再看 SGLang。如果你的请求里系统提示词占了七成长度，RadixAttention 省下来的不是一点。

模型和硬件都定死了，再考虑 TensorRT-LLM。它的收益是真的，但工程成本也是真的，量不够就是亏。

DeepInfer 适合「抄作业」。你如果正在跑 V4.1 Flash，可以照着它的算子选择、并行配置、140 token 的重放参数去改自己的服务。但别指望它替你做 KV Cache 和跨副本调度——README 已经写明了没给。

还有一个常被忽略的选型维度：你的团队能不能读懂它的代码。推理引擎出问题时，报错往往是一行 CUDA 或者一段通信超时。选一个社区大、issue 多的项目，至少有人踩过同样的坑。

开源的是算子，没开源的是账

回到最初那个问题：DeepInfer 到底开源了什么。

它开源了一套把单机吞吐压到极限的做法。哪些算子该融合、注意力怎么切、MoE 怎么摆、草稿多长、SWA 留多少 token，这些都是一线调出来的参数，平时只存在于内部文档里。

它没开源的是另一套东西：一百万 token 的 KV 放在哪、prefill 和 decode 怎么拆到两组机器上、一百个副本怎么分流量。这些不写在 kernel 里，写在调度器和存储层里。

这也解释了为什么它敢开源。算子是可复制的，账本不是。你把代码拉下来，能跑出一个漂亮的离线吞吐；但要把它变成能收钱的服务，还得自己补上那三行「not included」。

对读者来说，这份 README 最大的价值不是「又多了一个引擎可选」，而是它把推理优化的优先级摊开了：先解决长请求堵路，再解决解码批太小，然后才是投机解码和算子融合。

顺序反了，投入产出比会很难看。

至于「快几倍」这件事，下次看到，先问负载、基线、复现。三个都答得上来，再信那个数字。