DeepSeek 全面开源推理框架 DeepInfer：单集群日吞吐 155 万亿 Token，英伟达与昇腾双平台可用

2026 年 10 月 20 日——DeepSeek 于 10 月 20 日宣布将内部推理框架 DeepInfer 全面开源，同步开放生产级 Token 编解码组件 deepseek-recipe；官方披露，基于 DeepInfer 的单一集群日均服务吞吐为 155 万亿 tokens，按谷价计算平均每卡每小时收入 38 美元，框架可运行在英伟达与华为昇腾两类加速卡上。

官方给出的动机是分享内部部署经验：帮助开发者与企业优化大规模推理的吞吐与延迟，高效构建私有化及公有云部署，从而降低算力成本、减少能源消耗。此次发布发生在 DeepSeek 连续开放模型权重、TileLang 编译工具与推理算子库之后，软件栈由此从训练侧延伸到服务侧。

2026-10-20 · DeepSeek · 推理框架 · 开源

一、概览

在 DeepSeek 的官方表述里，大模型的能力边界由模型本身划定，但能否以合理成本提供超大规模的模型服务，取决于一个长期未被公众了解的中间层：推理框架。训练让模型学有所成，推理让模型为人所用；面对海量调用，推理框架负责统筹调度庞大算力集群，其效率直接决定 AI 服务的算力成本与电力消耗。

本次开源由两个仓库组成。框架本体 deepseek-ai/DeepInfer 采用 Apache-2.0 协议，仓库创建于 2026 年 10 月 16 日，截至发稿（10 月 20 日 18 时）已获得 3615 个星标、262 次 fork；协议层组件 deepseek-ai/deepseek-recipe 采用 MIT 协议，星标 869 个。DeepSeek 另在知乎发布了配套技术报告，仓库内 README 则以英文说明功能开关与构建方式。

从时间线看，这次开源不是孤立动作。2025 年 2 月的开源周，DeepSeek 放出了 FlashMLA、DeepEP、DeepGEMM 等面向英伟达平台的训练算子与通信库；2026 年 9 月 30 日，同一套组件以「同构双后端」的方式补齐华为昇腾版本，DeepGEMM-Ascend 在昇腾 950DT 上的 Dense GEMM 利用率最高达硬件极限的 99.8%；10 月 17 日，DeepSeek-V4.1-Flash-1017 权重以 MIT 协议在 Hugging Face 与 ModelScope 开放。模型、算子、编译器、框架四层至此连成一条完整链路。

二、核心信息

2.1 DeepInfer与deepseek-recipe组件

deepseek-recipe 是这次容易被忽略的一半。它是一个 Rust 库加 Python 绑定（pip install deepseek-recipe），负责协议与模型之间的翻译：思考模式、推理强度、temperature、top_p、输出长度上限、工具调用、图像预处理、JSON Schema 与正则约束、流式响应解析都在这一层完成。官方称其处理逻辑与 DeepSeek API 完整对齐，因此第三方部署可以拿到与官方服务一致的行为，而不只是「跑得起来」。

2.2 三大设计目标与请求链路

据技术报告，V4.1 Flash 推理系统在设计之初定了三条约束：芯片不挑，要同时跑满英伟达与昇腾各自的性能；用常见硬件组集群，8 卡机器做 Prefill、64 至 128 卡超节点做 Decode，围绕两个阶段各自的负载特征分别设计计算、通信与调度；KVCache 至少保留 72 小时，为上下文复用留出更长的时间窗口，并把长期保存的容量与管理开销计入系统设计。

请求的流转路径可以概括为：协议层进来，经入口分发，三条支路各自处理，缓存在独立存储集群统一落盘。

值得注意的是缓存的位置：它不属于 Prefill 或 Decode 任何一侧，而是独立存储集群，两侧都能读写。这一选择决定了后面所有数字——若缓存只是单机上的优化项，96% 的命中率无从谈起。

2.3 线上实测：96% 缓存命中与接近 1:1 的阶段配比

技术报告披露的线上指标如下（口径为官方实测，未说明统计窗口）：

这组数字里最刺眼的是 1.5M 与 60K 之间 25 倍的差距：同一张卡，加上缓存命中后处理的输入量提升一个半数量级。原因很直接——平均输入长度 77K，命中缓存时省掉整段 Prefill 计算，只剩调度与拼接开销。也就是说，在 DeepSeek 的实际负载里，「省掉重复计算」带来的收益，已经超过「把计算做得更快」带来的收益。

第二个反直觉的数据是 Prefill 与 Decode 的机器数接近 1:1。行业里更常见的配比是 Decode 侧占多数，因为逐字生成更耗资源；这里能压到 1:1，前提是 96% 的命中率把 Prefill 的有效负载大幅摊薄，而 Decode 侧又有 230 tps 的单用户速度与 14K tps 的单卡吞吐支撑。

2.4 四大机制

SWA Bounded Replay。 滑动窗口注意力只让每个 token 关注窗口内的邻近上下文，窗口外的历史在标准实现里需要重算。DeepInfer 的做法是只重放一段有界后缀：配置项 DEEPINFER_YOCO_PREFILL_TRUNCATION_MODE=compact 与 DEEPINFER_YOCO_PREFILL_KEEP_TOKENS=140（V4.1 默认值），保留的尾部需覆盖 SWA 窗口加最大回退长度。效果是把重算代价从「随上下文长度增长」变成「与上下文长度无关的常数」。在 77K 平均输入的场景下，这一条直接决定了 Prefill 的成本曲线形状。

DSpark 与置信度调度验证。 这是 DeepInfer 中最接近研究前沿的部分，也是 DeepSeek 此前已单独开源的工作。并行草稿器能一次提出长 token 序列，但缺少 token 间依赖，接受率会快速衰减；不加区分地验证整块草稿，又会在高并发下把珍贵批容量浪费在大概率被拒绝的 token 上。DSpark 用「并行骨干 + 轻量串行模块」的半自回归结构补上块内依赖，再按每个请求的预期前缀存活概率与引擎吞吐曲线动态决定验证长度。据其论文（arXiv:2607.05147），在 DeepSeek-V4 生产系统上，相同吞吐下每用户生成速度较 MTP-1 基线提升 60% 至 85%；官方技术解读则称，该机制为线上整体吞吐带来 6% 的提升。两个数字口径不同：前者是同等吞吐下的单用户速度，后者是全集群吞吐。

异步调度。 README 称其为「零开销批调度器」，默认开启，把 CPU 侧的批次编排与设备侧的执行重叠起来。这类优化在论文里通常只占一段，在真实服务里却常常是 GPU 空转的主要原因。

确定性与批不变性。 DEEPINFER_BATCH_INVARIANT=1 让模型结果在不同批次组成下保持一致，配合 DEEPINFER_ENABLE_MTP_VARLEN=0 与固定 seq_seed 可实现相同输入、相同采样参数下的完全确定性输出（两项均标注仅英伟达平台支持）。对做回归测试、效果对齐、计费审计的团队来说，这一条的价值不低于任何加速手段；它把「同样的请求为什么这次答得不一样」从不可解释变成可复现。

此外，结构化输出支持正则、JSON Schema 与 EBNF 文法三种约束，通过 so_args 传入采样参数，属于约束解码的标准做法。

2.5 开源的边界：三类组件没有开放

在「全面开源」的表述之外，README 用一段小字界定了范围：本次发布提供的是离线推理，以及规模化服务所需的核心功能。一个完整推理服务还需要三样东西，本次不包含：KVCache 系统、VE/Prefill/Decode 分离部署（引擎侧大部分功能已实现）、Prefill 与 Decode 数据并行副本之间的负载均衡。

官方解读给出的理由是，KVCache 管理与负载均衡组件与内部基础设施耦合过深，代码暂未放出，设计写在技术报告里。这一取舍可以理解，但也决定了这次开源的现实定位：它是一个可以读、可以学、可以在单机或小集群上跑通并复现性能曲线的框架，而不是一套拿来即用的线上服务栈。用 vLLM 替换成本的一句话概括——省掉的是「怎么调」，没省掉的是「怎么运维」。

三、数据与规格

四、成本：每卡每小时 38 美元

「每卡每小时 38 美元」是这次传播中被引用最多的数字，也最容易被误读。它是按谷价把所有 token 按标价售出算出的收入，官方没有同步披露成本，因此不能反推利润率。可以用官方定价与实测吞吐做一次交叉验算，看这个口径是否自洽。

DeepSeek 当前对 deepseek-flash（即 V4.1-Flash-1017）的谷价定价为：输入缓存命中 0.02 元/百万 tokens，输入缓存未命中 1 元/百万 tokens，输出 4 元/百万 tokens。按每卡吞吐与 1:1 的机器配比，单卡每小时的收入约为：

估算值 36.7 美元与官方 38 美元相差约 3%，落在假设误差范围内（汇率取 7.1，未计缓存写入、结构化输出等额外开销）。这说明 38 美元是一个由定价与吞吐直接推导出的理论收入指标，与 DeepSeek 2025 年 3 月披露 V3/R1 推理系统时使用的口径一致——当时官方给出每日成本 87072 美元、理论日收入 562027 美元、成本利润率 545%，并注明实际收入显著低于理论值。因此这次的两个数字应当读作「这套系统的产能与理论变现能力」，而不是「这套系统有多赚钱」。

真正值得企业关注的是另一个数：缓存命中率。输入命中与否的价格差是 50 倍（0.02 元对 1 元），命中率每下降一点，输入单价就上升一截。

也就是说，同样是「用 DeepInfer 部署 V4.1-Flash」，一个 Agent 类长会话负载（前缀高度复用，命中率可能超过 90%）与一个每次都是全新长文档的负载（命中率接近 0），单位 token 成本可以差一个数量级。框架给出的 96% 属于 DeepSeek 自家负载的实测，能否复现取决于业务形态，而不是部署动作本身。

对「能否帮企业降低部署与运行成本」，比较准确的回答是：能降低单位算力的服务成本上限，但不自动降低总拥有成本。三条前提缺一不可——模型必须是 V4.1-Flash；硬件必须是 SM100 或昇腾 950 这一代；缓存、P/D 分离与负载均衡需要企业自己补齐。三条都满足时，官方给出的 60K/1.5M tps 与 400ms 首字时延是可以对标的起点；只要有一条不满足，收益就要重新估算。

五、行业观察

门槛降的是认知，不是工程。 过去关于超大规模推理的知识，大多以「某公司分享了几个数字」的形式流传，读者知道结论，不知道取舍过程。DeepInfer 把取舍写成了代码和配置项：为什么缓存要独立成集群、为什么尾部只保留 140 个 token、为什么高并发下要按置信度裁剪验证长度、为什么确定性要单独做一个开关。这些是可以直接迁移的判断依据。但生产门槛由硬件代际与工程人手决定——只支持单模型、只支持最新一代加速卡、缺三个关键组件，任何一条都会把多数团队挡在「照着重现」之外。

开源姿态从「给权重」转向「给方法」。 模型权重开源解决的是「能不能用」，算子与框架开源解决的是「用得起多少」。DeepSeek 这一年的路径很清晰：先开放训练侧的算子与通信库，再开放模型权重，最后开放服务侧的框架与协议层。越往后，开放的东西越贴近工程 know-how，也越难被简单复制——权重下载即得，把 96% 缓存命中率做出来需要长期积累。这既是「推动普惠」的官方叙事，也是一种竞争策略：当权重不再是稀缺品，标准与工程能力就成为新的护城河。

与上游社区的关系是叠加而非替代。 README 明确写到，DeepInfer 最初主要基于 vLLM 构建，并参考了 SGLang 与 TensorRT-LLM。这意味着它是「模型厂在通用框架之上做的深度定制」，而不是另起一套生态。Apache-2.0 允许商用与回馈，理想情况下，其中的调度与验证策略会回流到上游；现实中，专用框架与通用框架的分层可能长期并存——上游负责广度与硬件覆盖，模型厂负责把自家模型的性能压到极限。

国产算力的闭环又补了一环。 DeepInfer 同时支持 SM100 与昇腾 950，与 9 月 30 日开源的昇腾版算子库、以及华为在 10 月中旬开放的商用 HDK（Atlas 850E）形成时间上的衔接。此前开源的是「训练算子在昇腾上有高性能实现」，这次延伸到了「推理框架能在昇腾上跑」。对国产算力生态而言，这比单个算子库的意义更实在：一套经过最大规模生产验证的服务栈，第一次以双后端同构的方式对两种芯片开放。当然，验证范围仍集中在昇腾 950 系列与 CANN 9.2，更早代际尚未被覆盖。

对 Token 价格的边际影响有限。 开源会压低行业的边际服务成本，方向上利空价格；但 DeepSeek 自身定价已在 0.02 元至 8 元的区间内，业内普遍认为接近成本线，进一步下探的空间来自缓存命中率与能源效率，而非框架是否开源。真正的变量在需求侧：当单位成本下降，长上下文与 Agent 类负载会先吃掉这部分红利。

六、待观察的三个问题

其一，数字的可复现性。155 万亿 tokens/天与每卡 38 美元都出自官方技术报告，外部无法独立验证：完整服务栈未开源，统计窗口、输入输出拆分、是否含缓存命中均未披露。用单机跑通 examples/offline_inference.py 能验证功能，验证不了这两个数字。

其二，「全面开源」的边界会否收敛。KVCache 系统、P/D 分离、副本负载均衡三项缺失，恰好是自建服务最难的部分。官方称耦合过深，后续是否以简化版或参考实现的形式补齐，决定了这个项目最终是「研究级框架」还是「可替代 vLLM 的生产框架」。

其三，硬件与模型的绑定会否放开。当前只支持 V4.1-Flash 与 SM100、昇腾 950。若长期维持这一范围，受益者主要是持有最新硬件的云厂商与大型企业；若要覆盖 A100、H800 等存量集群，需要额外的算子与内核适配工作，官方尚未给出路线图。