DeepSeek开源DeepInfer：省钱绝活给了，调度没给

DeepSeek开源了生产环境推理引擎DeepInfer，采用Apache 2.0协议，还罕见公布了官方运行数据：单集群一天处理155万亿Token。按官方口径折算，一张卡一小时营收38美元，而B200市场租金大约8美元——四倍多的差距。需要先泼一盆冷水：这是营收对租金，不是利润，电费、折旧、存储都没扣。

但这份开源真正值得琢磨的，不是那个四倍数字，而是"开了什么、没开什么"的分界线。

开源框架不等于开源调度

很多人把开源权重和开源框架混为一谈。开源权重是给你菜谱，照着能做；开源推理框架是把灶台、流水线、半成品加工都给你。但DeepInfer这次开放的，是"怎么做这道菜"的工艺，而不是"怎么同时服务10万人"的调度系统。

官方给出的理由是：KV缓存管理、跨副本负载均衡这些模块和内部基础设施耦合太深，没法剥离。所以总调度室还锁着。这解释了他为什么能把成本压下来，但别人复刻不出同样的账。

三个省钱绝活：工艺层全给了

DeepInfer公开的三项优化，是这套成本结构的核心。

PD分离：备菜和出餐分班组

Pre-fill（处理输入）消耗算力，Decode（生成输出）消耗显存带宽，两者放在同一张卡上会互相抢资源。DeepSeek^广告把这两个阶段拆开：8卡服务器负责Pre-fill，64到128卡超节点负责Decode，GPU配比大约1比1。类比就是备菜和出餐分成两个班组，各干各的。

Prefill 与 Decode 的资源特性差异

理解 PD 分离的关键，在于这两个阶段的瓶颈完全不在同一个硬件维度上。Prefill 阶段要对整个输入序列做注意力计算，计算量随输入长度线性甚至平方增长，属于典型的**算力密集型（compute-bound）任务，GPU 的 Tensor Core 利用率高。Decode 阶段每步只生成一个 Token，但需要反复读取整个 KV 缓存和模型权重，数据搬运量远大于计算量，属于显存带宽密集型（memory-bound）**任务。

如果两者混布在同一张卡上，Prefill 的长计算会阻塞 Decode 的迭代节奏，导致生成阶段出现明显抖动；反过来 Decode 持续占用带宽也会拖慢 Prefill 的批处理效率。拆开之后，两类硬件可以各自按最优 batch size 和并行策略配置，这也是为什么 DeepSeek 给 Prefill 配 8 卡、给 Decode 配 64 到 128 卡超节点——后者需要更大规模的高带宽互联来承载 KV 缓存的跨卡搬运。

KV缓存：SSD集群的命中率生意

聊天场景缓存存7天，Agent场景存3天，平均每个请求7.7万Token输入，96%命中缓存。价格上，命中2分钱每百万Token，没命中1块钱，差50倍。

这里有个容易被忽略的点：命中不是不要钱。存储、带宽、垃圾回收都是成本，只是被摊薄了。

KV 缓存与前缀缓存（Prefix Caching）

大模型推理时，每生成一个 Token 都要对之前所有 Token 做注意力计算。为了不重复计算，系统会把每一层注意力中的 Key 和 Value 矩阵缓存下来，这就是 KV 缓存。它的体积随上下文长度和并发数线性膨胀，长上下文场景下可占数十 GB，是显存的主要消耗方。

所谓“命中缓存”，指的是前缀缓存机制：当新请求的开头部分与历史请求完全一致时，可以直接复用已算好的 KV，跳过这部分 Prefill 计算。Agent、多轮对话、固定系统提示词这类场景天然共享大量前缀，因此命中率可以很高。命中率每提升一点，省下的是实打实的 Prefill 算力，这也是 DeepSeek 能把未命中价格定到命中价格 50 倍的根本原因——两者的边际成本结构完全不同。

投机解码Dspark：猜得准才省得快

草稿模型一次猜5个Token，自信度头判断哪些值得验证，每步验证的草稿Token从5个降到3.2到4.4个，省30%。再配上滑动窗口注意力，模型只往回看一小段：本来精确重建要把最后2560个Token拖过20层，现在只重算128个，Pre-fill计算量接近砍半。

这套Dspark让单用户速度提升60%到85%，线上实测230到300 Token每秒，写代码能到300字，首字延迟0.4秒。但落到高并发吞吐，增益只有4%到7%。单用户体感和集群吞吐，从来不是一回事。

投机解码（Speculative Decoding）原理

标准自回归生成每步只出一个 Token，且必须等前一个 Token 算完才能算下一个，GPU 并行能力被严重浪费。投机解码的思路是：用一个更小更快的草稿模型一次性猜出多个候选 Token，再让大模型并行验证这一串候选。验证是并行的，一次前向就能判断每个位置是否接受，因此只要猜得够准，就能用一次大模型前向产出多个 Token。

关键在于验证必须保证输出分布与大模型单独采样一致，否则会损害质量——这通过接受-拒绝采样实现。草稿越准，接受率越高，加速越明显；草稿不准则验证开销白费。Dspark 用“自信度头”动态裁剪每步验证的草稿数量，本质是在接受率和验证成本之间做自适应权衡。这也解释了为什么单用户延迟改善显著、而高并发吞吐增益有限：高并发下 GPU 本就处于饱和状态，投机解码省下的串行步数无法直接转化为吞吐。

7.7万Token输入透露了什么

平均7.7万Token的输入长度，和Agent场景高度吻合——Agent每次调工具都要重发全量上下文。但官方没有给出Agent占比，长上下文也可能来自代码库和文档，别把话说死。

今年7月，OpenRouter上美国企业通过中国模型处理的Token一度占到58%，但只贡献了约一到三成的支出。DeepSeek单家6月约16%。这说明中国模型卖得便宜，不等于成本低；收入份额低是价格问题，不是成本优势的证明。拿这个推成本地板，逻辑上还差一步。

没开的部分，才是真正的护城河

KV缓存管理、PD分离的完整在线编排、跨副本负载均衡，这三块没开。开源版目前是离线推理，想搭在线服务得自己补缓存和路由。

翻译一下：让一台机器快的部分给你，让一万台机器便宜的部分留着。官方说是耦合太深，不是故意留一手，但结果就是最值钱的集群调度还在它手里。

这不是DeepSeek一家的问题，而是所有把生产系统开源的公司都要面对的边界：工艺可以共享，规模化的运营know-how很难共享。对使用者来说，DeepInfer的价值在于提供了一个经过生产验证的推理优化参考架构；对DeepSeek来说，开源放大了生态影响力，却没交出真正的成本壁垒。

至于这是大方还是留一手——答案取决于你站在哪一边。

推理服务的调度层为何难以开源

在线推理系统的调度层要解决的是多副本、多请求、多租户下的资源分配问题：请求该路由到哪个副本、KV 缓存放在哪层存储、副本过载时如何迁移、长尾请求如何避免拖累整体延迟。这些决策依赖实时监控数据、集群拓扑、硬件异构情况和业务优先级策略，往往与公司的监控体系、发布系统、容量规划工具深度绑定。

把它剥离成通用开源组件，需要抽象出一套与内部设施解耦的接口，成本和维护负担都很高。这也是业界常态：vLLM、SGLang 等开源框架提供了调度骨架，但真正生产级的全局路由、弹性扩缩和故障转移，各家基本自建。因此 DeepInfer 开放的工艺层对复现单机优化很有价值，但要达到官方公布的集群级成本，仍需要使用者自己补齐调度这一环。