2026年10月20日，DeepSeek将其线上生产环境使用的推理引擎DeepInfer完全开源，许可证为Apache-2.0，代码托管于GitHub仓库。但README最显眼处列出两条硬性限定：模型仅支持DeepSeek-V4.1-Flash一款；硬件仅支持英伟达SM100和华为昇腾950两类。

一个开源项目，把准入条件写在了文档第一屏。

本文试图回答三个问题：引擎内部集成了哪些系统设计、单卡每小时38美元的单位经济数据是如何算出的、以及这一开源动作真正影响的决策者是谁。

开源内容有哪些：两项关键数字与五项系统设计

先看两个数字，它们决定了整个事件的分量。

DeepSeek单一集群日均处理155万亿tokens。按谷时电价计算，每卡每小时收入38美元。

换个角度理解：这份开源并非普通意义上的新闻通稿，而是一份附带了经济模型的工程交付物。DeepSeek首次将单位经济表现公之于众。

从技术构成看，引擎整合的算子库均为DeepSeek过去两年間陆续开源的项目：FlashMLA、DeepGEMM、DeepEP、TileKernels、DeepSelect，另有一批基于TileLang编写的自定义kernel。本次的新工作在于将这些组件装配为完整引擎，并在引擎层面新增五项系统设计。

第一项设计：并行策略根据推理阶段分为两套。

注意力计算采用数据并行，MoE层采用专家并行，并配备一个专家负载均衡器。核心要点不在于选择哪种并行方式，而在于Prefill与Decode两个阶段的并行度相差接近一个数量级：Prefill阶段使用2到8路并行，Decode阶段则扩展到64到128路。

为何两个阶段的并行度差异如此悬殊？原因在于两者工作性质截然不同。

Prefill阶段需要一次性完成整段输入的运算，瓶颈在算力资源；卡数量越多，单卡分摊的计算量越少，反而降低效率。Decode阶段每步仅生成一个token，然而每一步都必须从显存中完整读取被激活的参数，瓶颈在访存带宽。

因此DeepSeek将384个路由专家分布到64张卡上，每张卡仅承载6个专家，另加1个热门专家的副本。

Decode阶段扩大卡数并非为了加快计算，而是为了让每张卡少读一些数据。

第二项设计：DSpark推测解码与置信度调度相结合。

模型先对后续5个token做出猜测，再交由主模型批量验证。DeepSeek引入Confidence Head来估计每个猜测被接受的概率，从而将验证算力集中用于最有希望的前缀之上。

效果是：被验证的草稿token数量从5.00降至3.2至4.4，减少约三成；而最终接受长度基本未受影响，为3.29对3.20。

验证量减少三成，输出量并未缩减。

不过此处有一个坦诚的细节。官方部署问答指出，这套动态验证策略在每卡约60个并发序列时带来4%至7%的吞吐提升，但当并发序列降至16个时，反而比固定验证5个token的做法慢1.5%。这说明其优势并非无条件成立，仅在高并发场景下划算。此类「特定条件下性能会下降」的说明，通常企业不会写入文档。

第三项设计：SWA Bounded Replay。这一项最值得深入讨论。

V4.1-Flash的部分层采用滑动窗口注意力机制，每个token仅关注距离最近的128个token。这类缓存有个特征：有效复用时长仅为几分钟。

既然有效时间只有几分钟，就没有必要持久化到SSD中。DeepSeek的方案很直接——不持久化。缓存一旦缺失，仅重新计算最近128个token，以恢复一份近似的窗口状态。

由此，重算成本变为常数：无论上下文多长、模型多少层，均不影响。

在20层decoder上，原先每次Prefill都需要重建窗口缓存、需计算最后2560个token，现在仅需计算128个，Prefill的总计算量减少近一半。

引述官方数据时需注意：实际保留后缀为140个token而非128个。多出的12个token是回溯余量——保留的后缀必须同时覆盖滑动窗口本身与最大回溯长度。这类数值是经过计算得出的，而非随意设定。

第四项：在CPU排队下一步请求、处理上一步结果的同时，原本GPU只能空等。DeepInfer让双方并行工作：当GPU计算第N步时，CPU已在排布第N+1步。此功能默认开启。

第五项：批次不变性与确定性采样。对于同一批输入，无论怎样组合、怎样分批，输出结果完全一致。该特性仅在英伟达平台上支持。

五项设计叠加后的效果，官方离线测试数据为：64卡运行Decode、256请求每卡位时，每卡每秒输出超过2.5万个token，每个用户接近100 tokens/s；当请求数降至8个时，每用户速度超过300 tokens/s。

线上实测数据更为具体：平均首字延迟400毫秒，生成速度230 tokens/s，代码场景300 tokens/s，平均输入缓存命中率96%，含缓存命中的每卡吞吐150万 tokens/s。

那个96%的命中率后文还会再次出现。它能解释整套系统的经济性来源。

并未提供全套基础设施，但价值不在代码数量上

首先说明我不认同的一种观点。

网络上流传着「真正意义的OpenAI已经到来」的说法。我不同意这一判断。

若以「完整开源」的标准来衡量，DeepInfer欠缺的远不在少数。README本身列出三项未提供的组件：一套KV缓存系统；VE、Prefill、Decode分离部署能力；数据并行副本之间的负载均衡机制。

这三项恰好是大规模在线服务中最复杂、最繁重的部分——如何分层缓存、如何在机器之间迁移数据、机器故障时如何处置、请求如何在副本间均衡分配。算法再精巧，这三方面处理不当，线上系统就难以支撑。

更关键的约束是：仅支持一款模型、两种芯片。

代码已经给出，但用户仍需自行制造变速箱和底盘。

尽管如此，我依然认为这次开源具有重要意义，理由与代码行数无关。

需要区分两个层面：算法与基础设施。

所缺的三项功能属于基础设施层面。多机缓存、负载均衡、故障恢复，这些是工程量的活。云厂商自身具备建设能力，vLLM和SGLang生态中也有现成方案可以组合使用。这些工作重要，但不算稀缺。

已经提供的，是算法层面的成果。SWA如何重放、EPLB隔多少步重新计算一次、推测解码应当验证几个token、Prefill应使用几路并行——这些问题的答案，只有真正运营过超大规模生产服务的人才知道。而且这些答案与特定的模型架构紧密绑定。

举一个具体例子。EPLB每1000步统计一次专家负载，每10000步重新分配一次热门专家副本。线上实测显示，最繁忙那张卡的负载仅比平均水平高出9%。

一个集群部署数千张卡，负载偏差控制在9%以内。这个数字背后经历过多少次失败、多少次回滚，文档里没有记载。

整套调度运行下来，系统只能达到离线完全均衡状态的80%左右。剩余20%是现实世界的损耗：请求长度参差不齐、流量突发、机器状态波动。

这意味着，他们连「系统无法满载」的程度也如实告知。

取舍比代码更有价值。因为代码可以编写，取舍却难以复制。

还需要说明另一点：DeepInfer并非从零开始构建的框架。README的致谢部分坦白写明——最初主要基于vLLM构建，同时从SGLang和TensorRT-LLM中获得启发。

vLLM是当前开源推理领域的事实标准，几乎每家模型厂商的部署文档第一句话都是「使用vLLM启动服务」。那么问题在于：站在vLLM之上改进一版，开源的增量价值体现在何处？

我认为增量在于设计哲学方向相反。

vLLM的目标是「什么模型都能运行」，因此必须做通用抽象，必须为兼容性做出妥协。DeepInfer的目标是「在特定硬件上、将特定模型的成本压缩到最低」，因此可以为一个架构做极致特化：FP4 KV缓存、128 token滑动窗口、3层多token预测、384个专家的固定分布，全部固定不可更改。

这也解释了为何只支持一款模型。

并非不愿适配，而是这套优化脱离V4.1-Flash架构后便会全部失效。

「只支持一款模型」不是保守，而是这套优化方案的前提条件。

换作你也会做出同样选择。若你运营着一个每天处理155万亿token的服务，你不会去写一个什么模型都能运行的通用框架，而是会丢弃所有通用性，只保留一条最快的路径。通用框架解决的是「能否运行」，专用引擎解决的是「跑一次需要多少成本」。这两个目标指向的优化方向完全不同。

再提升一层来看。模型开源近年来已不新鲜，Llama、Qwen、Mistral，发布权重已成为常态。但将前沿实验室线上运行中的引擎源码公开，是另一回事——此前外界只能通过论文推测生产环境的样子。

因此我不喜欢「真正的OpenAI已经到来」这种说法。更准确的描述是：这是首次有人将中间层完整展示出来。

因此我不喜欢「真正的OpenAI已经到来」这种说法。更准确的描述是：

这是行业第一次将中间层公开展示。

比未开源的三个组件更关键的，是96%这个数字

前文提到的那个数字，现在需要详细解释。

平均输入缓存命中率96%。

这意味着，DeepSeek收到的输入token中，有96%是此前已经计算过的内容。多轮对话的上下文、系统提示词、代码库中未修改的文件，这些内容反复出现，全部命中缓存。

而缓存命中的输入，官方定价为每百万token 0.003美元。未命中时为0.15美元。输出为0.6美元。谷时与峰时价格相差一倍。

简单计算即可看出这一结构的价值：同样一亿个输入token，全部命中时费用为0.3美元，全部不命中时为15美元，相差50倍。

因此38美元这个数字有了答案。

38美元/卡时并非依靠「算法特别先进」堆叠出来，而是依靠「负载结构特别有利」实现的。

DeepSeek的主要场景是编程和多轮对话，这类负载天然产生大量重复上下文。若换成一次性问答，或每个请求上下文都完全不同的场景，命中率将下降，单位成本会立即改变。

代码可以复制，但那96%的命中率无法照搬。

代码可复制、算子库是开源的、框架采用Apache-2.0协议、硬件可以购买。但96%的命中率源于用户如何使用产品——那由产品形态决定，而非技术决定。

再深入一层，关于SWA那个选择。

缓存不持久化，缺失时仅重算128个token以恢复近似状态。注意「近似」这个词。

他们主动放弃一部分精确性，换取重算成本的常数化。这是一个非常清醒的交换：经过计算，96%的情况下缓存都存在，剩余4%情况下重算128个token的成本可以忽略；而为了这4%去搭建一套持久化存储系统，运维成本和延迟成本均远高于收益。

该决策的前提是96%的命中率。若命中率仅为60%，同一决策就会变成错误的，且是灾难性的错误。

架构选择、缓存策略、定价结构、负载特征，这四者在DeepSeek这里构成了一个紧密耦合的系统。

单独抽出任何一项来分析，都会得出错误结论。这也是为什么许多团队按照论文复现后，最终成本对不上——他们复现了架构，却没有复现负载。

顺便说明定价与技术的关系。今年6月DeepSeek启动了峰谷定价，峰时价格翻倍，峰时为工作日的上午和下午。表面上这是商业策略，实际上与这套框架配套：利用价格将负载从峰时引导至谷时，再凭借调度能力将谷时资源吃满。技术在为定价服务，定价在替技术平滑负载曲线。

那么，究竟是谁在向谁提供支持？

一个Apache-2.0框架的硬件白名单仅有SM100和昇腾950两项。云厂商若想用其部署DeepSeek模型、获得接近官方的成本与性能，就只能在两种芯片中做出选择。

开源的是软件，被选择的是硬件。

新框架的硬件白名单，实质上是一张采购清单。

这并非阴谋，而是自然的商业结果。技术上也有硬性约束：FP4 KV缓存、FP8计算路径，A100根本不具备这些能力，H100的FP4支持也不完整。因此「只认两种卡」既是商业考量，也是技术现实，两个方向指向同一结果。

谁从中受益？英伟达获得新框架的默认支持，华为昇腾获得国产替代叙事中最具说服力的一个技术背书。DeepSeek获得的是生态标准上的话语权，以及——如果行业部署成本确实下降——一个更大的调用基数。

至于普通开发者，短期内确实无法使用。有技术博主指出，该框架需运行在SM100或昇腾950上，官方性能测试使用了4至64张此类卡，个人电脑无法运行；模型也仅支持V4.1-Flash一款。

部署问答中还提到，这套框架的最小高效单元为128张卡。

128张Blackwell。这个数字比任何宣传语都更能说明此次开源的受众人群。

这件事与不同角色的关系

如果你是独立开发者：这套框架无法运行，不建议浪费时间编译。

但仓库值得阅读，重点不在代码，而在那些常量与注释。140这个数字是如何确定的、EPLB为什么设定为1000步和10000步、Prefill为什么只配置2到8路。每理解一处，你对「推理成本究竟高在哪里」的认知就深一层。这比看十篇KV缓存科普文章更有价值。

如果你在企业中进行技术选型：这次开源直接改变了那个一句话答案。

以往有人询问「能否私有化部署DeepSeek，成本接近官方」，标准答案是「你需要具备DeepSeek同等级别的调优团队」。

现在的答案是「你可以照搬它的调优方法，前提是你的硬件为SM100或昇腾950、规模达到128张卡、并且你的负载中包含大量重复上下文」。

前两个条件可以通过投入资金解决，第三个不能。

如果你仔细核算过自身业务，发现缓存命中率仅为三四成，那么这套方案对你而言并非降本工具。它会给出一个理想化的理论成本，而你在真实负载上无法达到该数值，最终可能怀疑自己调优有误。

如果你是行业观察者：判断锚点应当改变。

过去看模型跑分，现在看单位卡时收入。38美元/卡时是第一个公开的行业参照点。

但这个参照点存在一个问题，需要明确说明。

用官方定价乘以官方吞吐量，再除以官方卡时收入，反推得到的集群规模在一千多到四千多张之间，相差数倍。这说明38美元并非按标价成交的数字，其中包含折扣、免费额度，以及缓存命中结构带来的定价差异。

具体口径DeepSeek未披露，我只能标注为unknown，不替它补充。

因此看待此数字的正确方式是：认可其量级，不追求精度。

几个可自行跟踪的指标。

其一，GitHub上DeepInfer的提交频率，重点观察后续新模型的推理代码是否确实在此更新。官方承诺「后续新模型的推理代码及优化也将在该框架内持续更新」——这是检验承诺的唯一硬指标，比任何发布会都更具说服力。

其二，是否有云厂商公开宣布使用DeepInfer部署，并给出与官方API的对比数据。若有，说明这套方案确实可复制；若一年后仍只有DeepSeek自身在用，那它就只是一份技术文档。

其三，昇腾950的实际交付节奏。硬件白名单中包含一个国产选项，这件事的意义不在当下，而在明年。

其四，DeepSeek的API定价是否会进一步降低。如果框架确实压低了行业成本，价格会给出信号——这是最具可信度的指标。

这件事真正信息量并不在于又一家公司开源了某个东西。

而在于它揭示了一个长期被忽视的事实：模型的能力边界由模型架构定义，但模型的价值几何，取决于那个此前少有人详述的中间层。

训练决定模型能做什么，推理决定这件事要花费多少。而在商业上，后者的权重往往更大——因为训练是一次性投入，推理是每一天都在支付的账单。

DeepSeek此次将中间层与经济账本一并公开，是这个行业第一次出现此类做法。它不完美，三项基础设施未提供，硬件仅支持两种，个人开发者无法使用。但它确实把一个原本只能从论文中推测的对象，变成了可以逐行阅读的代码。

我会持续追踪这条线索。算力如何被消耗、API价格如何被重新计算、以及那些隐藏在数字背后的取舍——这些比模型又刷新了多少分数更有探索价值。

追溯来源与核实情况

DeepInfer开源公告与技术清单：来源为DeepSeek官方，发布日期2026-10-20；GitHub仓库 github.com/deepseek-ai/DeepInfer（Apache-2.0），README于2026-10-20发布，2026-10-21日有提交更新。核实状态：已阅读原仓库README。

155万亿tokens/天、38美元/卡时（谷价）：来源为DeepSeek部署问答/技术报告，经TechWeb、中新经纬、人民日报英文端等多家媒体同期报道，统计口径一致。核实状态：多源一致；集群规模未披露，文中反推数字为估算值，假设已在正文标注。

API定价（缓存命中0.003美元、未命中0.15美元、输出0.6美元，均为每百万token谷时价格；峰时翻倍；峰时为UTC 01:00-04:00及06:00-10:00工作日）：来源为DeepSeek官方API文档定价页。核实状态：已阅读官方页面。

96%缓存命中率、400ms首字延迟、230/300 tokens/s、每卡150万 tokens/s：来源为DeepSeek公布的V4.1-Flash线上运行数据，经凤凰网科技等报道。核实状态：媒体转述官方数据，未见独立第三方实测。

离线测试数据（4卡Prefill/64卡Decode、2.5万+ tokens/s/卡、EP2-8与EP64-128、DSpark 3.2-4.4、140 token后缀）：来源为仓库README与部署问答，另经AI In Context、SyncAI等英文技术媒体逐条解读。核实状态：官方自报，非第三方复测。

V4.1-Flash架构（763B总参数/16B激活、384个路由专家、1M上下文、CSA2、FP4 KV缓存、3层MTP）：来源为模型卡与技术报告《DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression》。核实状态：模型卡信息，参数细节引自第三方模型库整理，未逐项核对原论文。

最小高效单元128张卡：来源为部署问答，经英文技术媒体解读。核实状态：单一来源，建议以官方仓库为准。

致谢vLLM/SGLang/TensorRT-LLM：来源为仓库README原文。核实状态：已阅读原文。

小结：DeepSeek开源DeepInfer，实质是将算法层的工程取舍与单位经济模型公开。其单卡时38美元收入并非源于算法先进性，而由96%缓存命中率所对应的负载结构决定。对多数企业而言，若自身负载缺少重复上下文，便难以复制其成本优势。该框架的真正约束条件在硬件白名单与最小高效规模，不在代码是否可读。