DeepInfer 开源不等于能部署：5 项能力与 3 道门槛
2026 年 10 月 26 日：为什么现在值得看
2026 年 10 月 26 日抓取到的 DeepInfer 一手仓库显示，DeepSeek 已公开面向 DeepSeek-V4.1-Flash 的高性能、大规模推理框架。README 明确把它描述为支撑 DeepSeek 大规模生产服务的框架，本次发布提供的是带核心能力的大规模离线推理。现在值得看，是因为推理底座本身可以读源码；但“框架开源”与“普通用户能拼出同等生产服务”不是一回事。以下按仓库口径拆成 5 项能力、3 道门槛，并复算两组公开吞吐数字。
中文社区视角的 36Kr 报道转述了更贴近线上服务的数字：平均请求输入 77K Token、首字平均 400 毫秒、生成阶段每秒输出 230 Token、平均 96% 的输入命中缓存。它们属于媒体转述的官方统计，不应当作源码仓库给出的本机复现实验；能确认的是，DeepInfer 面向持续服务，而不只是跑一次样例。
5 项能力：加速、并行与可控输出
为方便普通用户，我把 README 的功能按工作位置归成 5 组；这是我的归类，不是官方列出的“五项”。
| 能力组 | README 明确提供的内容 | 便于普通用户的理解（我的翻译） |
|---|---|---|
| 专用算子 | FlashMLA、DeepGEMM、DeepEP、TileKernels、DeepSelect 与自定义 TileLang kernel | 提供面向特定计算路径的专用实现 |
| 并行执行 | Attention DP / balanced CP，MoE EP + EPLB | 让多张卡分担模型工作，具体方式取决于模型和并行策略 |
| 异步调度 | CPU 批调度与设备执行重叠，默认启用 | 一侧准备下一批请求时，另一侧仍可继续计算 |
| 验证与回放 | DSpark 置信度调度验证、draft tokens；SWA bounded replay | 用草稿 token 和有限后缀减少解码或 prefill 工作 |
| 输出控制 | batch-invariant、deterministic sampling，以及 regex、JSON schema、EBNF 结构化输出 | 分别约束批大小变化、重复请求和输出格式 |
最容易被误读的是“确定性”。DEEPINFER_BATCH_INVARIANT=1 用于批次不变推理；确定性采样还要求 DEEPINFER_ENABLE_MTP_VARLEN=0，并向 SamplingParams 传入固定 seq_seed，官方注明这两项仅支持 NVIDIA。前者管“换批是否变”，后者管“相同输入和采样参数能否重复”。
DSpark 由 DEEPINFER_ENABLE_MTP_VARLEN=1 开启，DEEPINFER_USE_NEXTN_DECODE 控制最大 draft length，默认是 5。SWA 默认使用 DEEPINFER_YOCO_PREFILL_TRUNCATION_MODE=compact 和 DEEPINFER_YOCO_PREFILL_KEEP_TOKENS=140，但保留后缀必须覆盖 SWA 窗口与最大回退长度。
3 道门槛：源码、离线推理与生产服务
真正的门槛来自部署链条，我把它归成 3 道：
| 部署环节 | 仓库明确写明的边界 | 对使用者的直接影响 |
|---|---|---|
| 硬件 | 只列出 NVIDIA SM100 GPU 与华为 Ascend 950 NPU | 其他 GPU 不在官方支持名单，不能直接套用相关性能结论 |
| 软件与模型 | Linux、GCC >= 13.0、Python 3.12；NVIDIA 侧需要 CUDA 13，Ascend 侧需要 CANN 9.2；支持模型为 DeepSeek-V4.1-Flash | 环境不符时首先要解决兼容性，而不是先调性能参数 |
| 服务完整性 | 完整服务还需要 KV cache、VE/Prefill/Decode 分离，以及 Prefill 与 Decode 数据并行副本间的负载均衡；这些未包含在本次发布中 | 克隆仓库不等于获得一套完整 API 网关 |
官方还要求先创建并激活空的 Python 3.12 环境。默认检查点首次运行会下载到 Hugging Face 缓存，也可用 DEEPINFER_HF_MODEL_DIR 指向本地目录。能按 README 跑通的是离线推理；完整服务所需的缓存、阶段分离和副本负载均衡仍要自己补齐。
# 二选一：NVIDIA 使用 nvidia，Ascend 使用 ascend
export DEEPINFER_ACCELERATOR=nvidia
./build.sh仓库本身给了三个可核对的信息
看一个开源推理框架，除了看功能清单，更该看三件能直接核对的事：许可、出身和基准口径。
许可是 Apache License 2.0（仓库 LICENSE 文件），对要在企业环境里改代码、嵌进自研服务的人说，这是能不能用的第一道门槛，比性能数字更早决定方向。
出身写在 README 的致谢里：DeepInfer 主要基于 vLLM 构建，另外参考了 SGLang 和 TensorRT-LLM。这条信息很有用 —— 它的算子与调度设计不是凭空冒出来的，读 vLLM 的读者可以直接对上概念，也知道遇到问题时该去翻哪边的实现。
基准口径最容易被人跳过。README 写明性能数字的测量条件是 prefill 用 4 张 SM100、decode 用 64 张，且各自都在单个 scale-up 域内，并给了 run_sweep.sh 作为复现入口。这条细节决定了后面那些吞吐数字该怎么读：官方给的是分阶段的、分域的测量，而不是”一套配置打天下”。社区文章里那些 4 卡、64 卡的数字，恰恰要挂到这条口径上才有意义。
顺带一个抓取时点的快照：仓库页显示 24.7k star、3.0k fork，main 分支只有 5 次提交（这三个数随时会变）。
复算吞吐：数字能对上，但不是性能保证
阿里云开发者社区的 中文社区实测文章转述了一组上游口径：64 张卡、每卡 256 条请求、131,072 Token 上下文、nextn=3、75% 接受率；对应每用户约 103 Token/s、每卡约 2.63 万 Token/s、整集群约 168 万 Token/s。先不比较性能，只检查这组数是否自洽：
# 以下是我的算术复算，不是运行程序后的新实测
64 × 256 = 16,384 个并发请求
16,384 × 103 = 1,687,552 Token/s
1,680,000 ÷ 64 = 26,250 Token/s/卡结果与文章给出的整集群约 168 万、每卡约 2.63 万在算术上基本对齐，说明这组数字的并发乘法没有明显矛盾；算式本身不能验证真实速度。我的边界推导是：103 Token/s 带有上下文长度、投机解码接受率、调度和网络等前提，只适合解释该组配置，不应改写成面向所有用户的 API 速度承诺。
社区降门槛：4 卡结果不能冒充上游基线
同一篇文章把方案改成 EP4，并用 PCIe 共享内存读取主机内存中的 Engram 表，从而去掉 GPUDirect RDMA 依赖。作者称，在 4 张 B200、128k 上下文、1,024 个并发请求下，总吞吐约 6.2 万 Token/s、每请求约 61 Token/s；把并发降到 256 时，每请求约 110 Token/s。
| 指标 | 64 卡上游口径（社区文章转述） | 4 卡改法（社区实测） |
|---|---|---|
| 并发请求数 | 16,384，来自我的复算 | 1,024 |
| 总吞吐 | 约 168 万 Token/s | 约 6.2 万 Token/s |
| 每请求速度 | 约 103 Token/s | 1,024 并发时约 61；256 并发时约 110 |
| 数据路径 | 上游路径依赖 GPUDirect RDMA | PCIe 共享内存，不要求 RDMA |
社区数字也能做一次算术检查：62,000 ÷ 1,024 ≈ 60.5 Token/s/请求，与报告的每请求约 61 吻合。但这不是同机同卡对照，不能拿两个总吞吐直接计算缩比。把官方仓库与社区实测并置后，可以得到一个额外判断：硬件卡数不是唯一变量，网络数据路径和并发数也会改变每个用户拿到的速度；这是跨源对比，不是官方结论。
谁该现在试：看目标，不看峰值
按我的经验判断，不是官方说法：如果你有 SM100 或 Ascend 950，想研究 DeepSeek-V4.1-Flash 的算子、并行策略与离线推理，这个仓库值得进入测试；如果目标是在普通 GPU 或普通云主机上直接获得同等服务，README 的支持名单和缺失组件都提示暂时不合适。
实际试用可以按固定顺序进行：先核对硬件和软件版本，再构建并准备模型；随后用固定输入和采样参数核对输出；最后再逐步增加并发，同时记录首字延迟、总吞吐、单请求吞吐、缓存命中率与投机解码接受率。若业务要求跨批次一致，应把 batch-invariant 与确定性采样单独测试，不要和性能基线混在一起。开源的价值在这里很具体：它让这些变量终于有机会被逐项拆开检查，而不是只看一个集群峰值。
评论区
登录后可评论。