DeepInfer 开源：155 万亿 Token 集群与 38 美元每 GPU 小时

一句话结论：DeepInfer 是 DeepSeek 把支撑 DeepSeek-V4.1-Flash 线上服务的整套推理框架搬上了 GitHub，一个单集群每天消化约 155 万亿 Token、闲时每 GPU 小时创收 38 美元的生产级调度系统，第一次以 Apache 2.0 协议完整公开。

2026 年 10 月 16 日，一个名为 deepseek-ai/DeepInfer 的仓库出现在 GitHub 上。10 月 20 日的首次提交里摆出了完整代码库。仓库描述只有一句：DeepSeek 大规模生产服务所用的推理框架。十几天后，它已经积累了两万四千多星标、近三千次 fork，以及两百多条 open issue。

这件事的分量不在于又一家中国厂商开源了一个模型。模型权重开源已经不算新闻，推理引擎开源才是。权重决定模型能做什么，引擎决定这份能力跑得多快、多贵、少占多少卡。DeepSeek 这次连同单位经济账一起摆了出来。

仓库里到底放了什么

DeepInfer 目前只支持一个模型，DeepSeek-V4.1-Flash，也就是 DeepSeek 官网 9 月 10 日发布的那款 552B 参数 MoE 模型，输入激活 8B、输出激活 16B 的非对称结构。

代码主体建立在 vLLM 之上，同时吸收了 SGLang 与 TensorRT-LLM 的思路。仓库自带的能力清单不长，但每一项都指向真实生产环境里的具体痛点：优化过的 kernel 与模型运行时、注意力数据并行与均衡上下文并行、MoE 专家并行加专家负载均衡、名为 DSpark 的推测解码、SWA 有界重放、默认开启的异步调度、批不变推理、确定性采样，以及结构化输出约束。

与之配套开源的还有 deepseek-recipe，一个用 Rust 写的令牌编解码组件，负责把 Chat Completions、Responses、Messages 三种 API 协议与模型令牌序列互相转换。官方明确它的处理逻辑与 DeepSeek 官方 API 完全对齐，第三方自部署得到的 API 行为与官方一致。

硬件支持是一处值得单独指出的细节。DeepInfer 同时支持英伟达 SM100 与华为昇腾 950 NPU，两条生态线平等列出。官方给出的构建依赖是 Linux、GCC 13 以上、Python 3.12、CUDA 13 或 CANN 9.2。

155 万亿 Token 与 38 美元每 GPU 小时

官方 Q&A 文档给出了一个很少见的数字组合：DeepInfer 支撑的单个集群目前每天服务约 155 万亿个 Token，在闲时价格下每 GPU 小时整体收入 38 美元。

这两句话合起来是一种罕见的价格公开。结合 DeepSeek 官方 API 定价页面上 deepseek-flash 的费率，可以反推这套系统的成本结构。

高峰时段为 UTC 时间周一至周五的 01:00 至 04:00 与 06:00 至 10:00，其余时段全部按闲时价计算，中国法定节假日同样整段计入闲时。缓存命中价与未命中价之间 50 倍的差距，是这套系统真正在优化的东西。

把 38 美元每 GPU 小时这个收入数字与硬件成本放在一起看，有第三方研究者推算出 84.2% 至 96.1% 的硬件毛利率区间。这部分属于外部估算，官方没有背书，但量级上说明了同一个事实：在 Flash 这个价位上，毛利空间是被底层调度撑出来的，而不是被参数规模堆出来的。

零开销批调度解决的那段 GPU 空转

DeepInfer 里最具体的一套机制叫 Zero-Overhead Batch Scheduler，用来消掉解码阶段 GPU 等待 CPU 的那段空档。

传统解码循环是 schedule(N) 到 forward(N) 到 sample(N) 再到 post-process(N) 的串行链条。schedule 与 post-process 都是纯 CPU 逻辑，而 post-process(N) 之前必须等 sample(N) 的结果，需要一次 GPU 与 CPU 的同步。GPU 算完了却停在那里等 CPU 整理上一轮生成结果、更新请求状态、再安排下一轮。对于要连续产出几千个 Token 的请求，这种等待会反复发生。

异步调度的做法是把链条错开一格。GPU 跑 forward(N) 与 sample(N) 的同时，CPU 并行执行 schedule(N+1)、launch_forward(N+1)、post-process(N-1) 与 launch_sample(N+1)，整个流水线里 GPU 没有等待窗口。这套重叠方式参考了 SGLang 与 NanoFlow 已有的实现。

错开一格带来的代价是状态错位。下一轮计算启动时，上一轮的采样结果可能还没完成 CPU 后处理，序列长度、KV Cache 状态与请求生命周期之间会出现时间差。DeepInfer 用 total_inflight_tokens 记录已下发但尚未提交结果的 Token，调度器分配资源时把这部分在途计算计入序列长度与 KV Cache 容量检查，并提前预留空间。跨轮次的执行状态由 WorkerStepState 保存，位置变化通过 Remap 映射处理，内存回收则延后到 DeferredRelease 机制里执行。

投机解码这条路线上的另一套工作，站内此前的 FlashMap 拆解过用投机解码把 Qwen3-8B 加速 6.14 倍的做法。DeepInfer 的 DSpark 走的是同一条路，但把调度策略换了个维度。

DSpark：按置信度分配验证算力

常规推测解码用一个草稿模型一次生成若干候选 Token，再由主模型逐个验证，接受率高的位置就多赚一个 Token。但不同请求、不同位置的接受概率差别很大，固定长度的验证会在低概率位置上白白花掉验证算力。

DSpark 用一个 Confidence Head 预测每个草稿 Token 的接受概率，调度时把验证算力优先分配给边际收益最高的那些 Token。生产环境里草稿模型一次生成 5 个 Token，框架依据实测的硬件吞吐曲线与逐请求的接受率排序，挑出能让有效吞吐最大的那个前缀子集去做验证。

效果相当直接。动态长度验证把每步需要验证的草稿 Token 数从 5.00 压到 3.2 至 4.4 之间，减少约 30%，而平均接受长度几乎不变，3.29 对 3.20。在生产工作点，也就是每 rank 约 60 条并发序列时，吞吐提升落在 4% 到 7% 区间。

单位是每 rank 每秒 Token 数，数据来自 EP64 与 DP64 的基准测试。并发越低，动态验证反而略微吃亏，原因是可挑选的候选集合太小；并发越过 48 之后收益开始稳定放大。

SWA 有界重放与三层 KV Cache

长上下文场景下，重算的成本决定了缓存能不能真正省钱。DeepInfer 用 SWA Bounded Replay 把这部分成本压成了一个常数。

做法是从位置 s 开始重放时，位置 i 的 query 只对 max(s, i−127) 到 i 区间的 key 做计算，得到近似的 SWA KV Cache。解码器侧，prefill 只在编码器层里做，CED 架构下解码层的块 KV Cache 由最后一层编码器的隐状态投影而来，精确重建需要把最后 2560 个 Token 过一遍 20 层解码器。DeepInfer 改成每层只重算最后 128 个 Token，结果只用于解码、从不进入前缀缓存，prefill 总计算量近乎减半。

缓存则分成三层，各有各的存放位置。

存储层的细节很具体。3FS 分布式文件系统提供约 100 PiB 的 SSD 空间给 KV Cache 使用，采用 10+2 纠删码，每个纠删组能容忍两个存储节点同时故障。一次读取会同时向组内 11 个存储节点发请求，任意 10 个响应就足以解码返回。TTL 方面，智能体流量为 3 天，对话机器人流量为 7 天，官方给的理由是对话流量的命中长尾更重，少量 KV 被反复读取的次数极多。实测把对话流量的 TTL 压到 3 天左右，代价是 0.5% 到 1% 的命中率损失。

容量配比上，官方给出的经验值是每 GPU 约 14.4 TB 逻辑容量，物理需求还要更大。标准存储服务器配置是 20 块 30.73 TB SSD，单台至少提供 40 GB/s 读与 5 GB/s 写。单机内存里每条序列落到存储层的只有 20 层乘 134 Token 乘 528 字节，合 1415040 字节，采用 MXFP8 的 SWA KV 格式。

缓存命中长度还有个硬约束。命中长度由块 KV Cache 决定，SWA KV Cache 决定最后一块要不要重算。在 YOCO 截断要求下，长度 L 的输入最大命中长度不超过 L 减 134，这个 134 来自 128 的 SWA 窗口加上 6 个 Token 的投机回退。

缓存层的收益在别处也有印证，站内关于 AKV 缓存工程开源 与 EdgeRock-4B 固定 KV 方案 的拆解，都在讲同一件事：智能体场景下缓存命中率直接决定账单。

专家并行负载均衡与最小部署单元

MoE 模型部署的难点是专家负载不均。DeepInfer 的 EPLB 机制让每张 GPU 除了负责的专家之外，还冗余托管若干热点专家副本。系统收集专家在过去 N 步的负载，每 M 步按统计重新分配专家，并通过 NVLink 的 symm_mem 在组内打乱专家权重。

预填充侧从每 GPU 4 个冗余专家起步，100 步统计窗口，1000 步重分配一次；解码侧从每 GPU 1 个冗余专家起步，在 EP64 下取整后是每 GPU 7 个专家（不含共享专家），1000 步统计窗口，10000 步重排一次。实测的 moe_lb 指标也就是最慢 rank 与平均负载之比，预填充在 EP4DP4 下是 1.074，EP2DP2 下是 1.045，解码在 EP64 下是 1.090。整体负载均衡效果大约是完美均衡离线基准的 80%。

预填充的请求按上下文长度分四档，低于 16K、16K 到 64K、64K 到 256K、256K 以上，各档按上一轮算力配额需求占比动态调整引擎数量，每档单独设算力配额上限。单步的 chunk 大小不由固定值决定，而是用拟合的二次成本模型 cost(q, c) 反解，q 是序列 Token 数，c 是已算好的前缀长度，求解在 32768 Token 预算内取最大可行 q，正好用完剩余时间预算。

部署形态上，预填充跑普通 8 卡机，解码跑 64 到 128 卡超节点。1P 加 1D 可以跑起来，但官方认为最小的高效部署单元是 64 张预填充卡加 64 张解码卡。跨数据中心拆分 P 与 D 技术上可行，成本是可靠性，每 8 张 GPU 约需 400 Gbps 的互连带宽。

多卡规模化的能力指标与挑战并存，站内关于 vLLM d3-ultra 的分析可以对照阅读，同一套社区生态里，引擎与模型分两条线在往前推。

谁能用起来，还差什么

官方对 DeepInfer 的定位很诚实。这是离线推理框架，不是可以直接替换 API 服务的成品。README 明确列出三样未包含的东西：KV Cache 系统、VE 与 Prefill 与 Decode 的分离编排、以及数据并行副本之间的负载均衡。前者与内部基础设施耦合紧密，后两者的引擎主体功能其实已经实现。

上手路径本身不复杂。准备一个空的 Python 3.12 环境，导出 DEEPINFER_ACCELERATOR 为 nvidia 或 ascend，执行 ./build.sh 从源码构建。权重默认首次运行自动从 Hugging Face 拉取 deepseek-ai/DeepSeek-V4.1-Flash-1017，也可以用 DEEPINFER_HF_MODEL_DIR 指向本地副本。然后跑 python examples/offline_inference.py，官方给的示例参数组合有 –ep 8、–ep 2 –dp 8、–ep 2 –cp 8 三种。

基准测试的硬件门槛能说明它面向谁：预填充用 4 张 SM100，解码用 64 张，各自都在一个 scale-up 域内。一张消费级显卡跑不了，Hopper 也不在支持列表里。

评测框架随仓库一起发布，走离线批量接口。AIME 2026 用 30 道题每题 32 样本，HLE 包含 2158 道文本题与 342 道图片题共 2500 题，GPQA Diamond 是 198 题每题 8 样本，指标统一为 Pass@1。生成与打分被拆成两个阶段，打分可以换判定器重跑而无需重新生成。

还有一个细节能看出工程投入的偏向：批不变推理与确定性采样目前只在英伟达平台可用，昇腾 950 尚不支持。这两项决定了第三方部署能否复现官方输出，属于可复现性的地基。

常见问题

DeepInfer 和 vLLM、SGLang 是什么关系？

DeepInfer 主要构建在 vLLM 之上，同时借鉴了 SGLang 与 TensorRT-LLM 的实现思路，仓库致谢里写明了这一点。它是 DeepSeek 自己生产环境所用框架的公开版本，目前只支持 DeepSeek-V4.1-Flash 一个模型，且只开放离线推理能力。

普通开发者能跑起来吗？

能编译能运行，但门槛不低。需要 Linux、GCC 13 以上、Python 3.12、CUDA 13 或 CANN 9.2，硬件必须是英伟达 SM100 或昇腾 950。官方基准用了 4 张 SM100 做预填充、64 张做解码，个人机器与常规创业公司集群都不在支持范围内。

155 万亿 Token 一天意味着什么？

意味着这个引擎每天要处理相当于数千亿次推理请求的量级。在这种规模下，GPU 每轮计算里浪费一点点资源，累积起来都非常可观。也正因为如此，异步调度、专家负载均衡、缓存复用这些看起来只是工程细节的东西，才真正决定了这套系统的单位成本。

相关阅读

• GPT-6.1 Terra 发布：50.3 分终端基准，API 砍到 1 美元
• OpenRouter 全球模型榜前五全是中国模型：周调用 188 万亿 Token
• Cloudflare GLM-5.3 泄露拆解：155 个响应混入他人 KV Cache