DeepSeek开源推理引擎DeepInfer：把省钱的门道全摊开了

DeepSeek 这次没有发新模型，也没有刷榜，而是把支撑线上服务的推理框架 DeepInfer 连同编解码组件 Recipe 一起开源了。如果说模型权重是菜谱，推理框架就是后厨——同一本菜谱，不同的后厨一小时能接多少单、客人要等多久，差别可能非常大。开源引擎比开源权重罕见得多，因为引擎里藏着真正的工程 know-how。

推理框架为什么比权重更值得开源

很多人以为模型开源就是下载权重，但权重只是一堆数字，它不会回答问题。中间隔着一整套工程：接单、排队、把请求送进芯片、取回结果。技术博主宝玉用菜谱和后厨打比方——菜谱人人可得，后厨的排班、火候、动线才是核心竞争力。

DeepSeek^广告 曾在 2025 年 4 月解释过为什么不开源内部引擎：内部版本做了大量定制，很难搬到外部环境，团队也没有精力维护大型项目。到了 10 月，这个说法被自己推翻了。除了 DeepInfer 和 Recipe，同期上线的还有给模型用的搜索与抓取服务 Search 和 Fetch——Search 和 Fetch 负责找料，DeepInfer 是后厨，Recipe 是多语种菜单，三样东西串成一条线。

Search 和 Fetch 背后是一笔平时没人算过的成本：搜索引擎是给人看的，一页结果里有广告、推荐、导航栏和弹窗，人扫一眼就能跳过；但模型不行，每一个多余的字都要占上下文，都是 token，都要花钱。这两个接口返回原始 JSON，Search 额外给相关性评分和来源权威度，Fetch 给一个网址返回清洗过的 Markdown。定价每 1000 次成功请求 5 元，2026 年 11 月 1 日零点前不计费，也不绑定模型。

DeepInfer 的核心设计：PD 分离与三级缓存

DeepInfer 采用 Apache 2.0 协议，支持英伟达 SM100 和华为昇腾 950，环境是 Linux + Python 3.12 + GCC 13 以上。当前支持的模型是 DeepSeek V4.1 Flash。

一个请求进来先过 Recipe 变成 token，然后分两个阶段：预填充阶段模型把系统提示词、历史对话、文件、问题一口气读完，每个 token 在每一层算出一组中间结果，这就是 KV 缓存；解码阶段一个 token 一个 token 往外吐答案，每吐一个都要用到前面所有的 KV 缓存。两个阶段吃的资源完全不一样——预填充拼算力，解码大部分时间花在从显存读参数和缓存。

所以 DeepSeek 把它们拆到不同的机器上，这就是常说的 PD 分离。系统设计之初定了三个目标：兼容不同厂商芯片、围绕常见硬件组织预填充和解码、让 KV 缓存至少保留 72 小时。落到部署上，预填充用常见 8 卡服务器，解码用 64 到 128 卡超节点，视觉编码器单独拉出来，首 token 延迟和 token 间延迟分开优化。官方文档里还有一句挺有意思的话：视觉编码器一般单卡就行，建议用可用范围内最便宜的卡。

最省钱的一环是缓存。Agent 场景下每调用一次工具，客户端都要把完整历史重新发一遍——系统提示词、工具说明、之前每一轮回复和工具结果，一个都不能少。而这些绝大部分上一轮已经算过了。DeepSeek 的做法是把算过的 KV 缓存存下来，下一轮只算新增部分，前提是前缀完全一致、必须从第一个 token 开始对齐。

效果有多夸张？同一张卡跑一天，不计缓存命中每秒约 6 万个 token，命中缓存后是 150 万个，差了 25 倍。DeepSeek 线上平均每个请求输入 77K，首 token 延迟平均 400 毫秒，P99 是 1000 毫秒，命中缓存的输入售价只有未命中的 50 分之一。

这些缓存没放在计算节点自己的内存里，而是进了独立存储集群，用的是 DeepSeek 之前开源的分布式文件系统 3FS，容量约 100PB。KV 缓存以 128 个 token 为一块写入，Agent 流量保留 3 天，聊天流量保留 7 天——聊天流量有长尾命中特征，少量缓存被反复读取，丢掉对整体命中率影响更大，只留 3 天的话聊天命中率会掉 0.5% 到 1%。放到行业里看，Anthropic、OpenAI 和谷歌的缓存大概只留 5 分钟到 24 小时，3 天和 7 天算是很长的。

KV 缓存是 Transformer 推理中一种复用中间计算结果的技术。自回归生成时，每生成一个新 token，模型都需要对之前所有 token 的 Key 和 Value 向量做注意力计算。如果每次都从头算，计算量会随上下文长度平方增长。KV 缓存把这些已经算过的 Key/Value 存下来，下一步直接复用，只需计算新 token 的部分。代价是显存占用随上下文线性增长——上下文越长、并发越高，缓存越吃显存。这也是为什么缓存命中率对推理成本影响巨大：命中意味着跳过预填充阶段的大量矩阵运算，直接进入解码。

SWA 有界重放：把重算成本变成常数

缓存总有没命中的时候，这部分最能看出 V4.1 的改动。V4.1 有一部分层用的是滑动窗口注意力（SWA），每个 token 只看离自己最近的 128 个 token。运行中的 Block KV 缓存和 State KV 缓存放在推理卡显存里，持久部分写进 3FS；SWA 单独维护前 20 层，每层一个环形缓冲窗口 128 个 token，另外留 6 个给投机回退。这部分不进 3FS，只在产生它的那台机器内存里放一份，约 3 分钟后清掉，命中率在 98% 以上，跨机器命中就走 400G VLAN 拉数据。

对于没命中的 2%，V4 的做法是精确重算、逐层恢复窗口状态，要重算的 token 数等于层数乘以窗口长度。为减少这种情况，V4 把这部分缓存也写进硬盘，结果吃到了硬盘缓存接近一半的容量——问题是它只在对话进行的几分钟内有用，用能存好几天的硬盘去装显然性价比极低。

V4.1 换了思路，叫 SWA 有界重放：只重新计算最后 128 个 token，算的时候注意力也只在这 128 个 token 之内，得到一份近似的窗口缓存。重算成本变成常数，跟上下文多长、模型多少层没有关系。同样的办法也用在 Decoder 的那 20 层上，改完之后原本要处理最后 2560 个 token，现在只需处理 128 个，预填充总计算量少了接近一半。

滑动窗口注意力（Sliding Window Attention, SWA） 是一种稀疏注意力变体：每个 token 只关注距离自己最近的固定数量（如 128 个）的 token，而不是全部历史。这让注意力的计算和缓存开销从随上下文长度线性增长变为有界常数，显著降低长上下文推理成本。代价是模型无法直接看到窗口之外的信息，通常需要与全局注意力层交替使用来弥补。SWA 的缓存维护也因此更复杂：窗口是环形的，新 token 进入时旧 token 被挤出，缓存状态需要精确跟踪，一旦丢失就得重算窗口内容。

投机解码与零开销批调度

缓存解决读得快，解码解决吐得快。投机解码的思路是先让轻量草稿模块连续猜 5 个，再交给大模型一次性验证，猜对的部分直接采用。但核对本身也要算力，5 个草稿全拿去验，很多算力浪费在被拒绝的猜测上。DeepSeek 自研的方案先估计每个猜测被接受的概率，把验证预算往更有希望的地方倾斜，动态核对让每步检查数量减少约 30%，平均接受长度基本不变，线上吞吐提升 6%。序列数从 16 加到 96，收益从负 1.5% 一路涨到 11%——这个数字是有条件的，不是所有负载都快。

另一笔开销藏在 CPU 和 GPU 之间。GPU 算完当前步要停下来等 CPU 更新上一轮状态，对连续生成几千个 token 的请求，这种等待反复发生。DeepInfer 的零开销批调度把 CPU 的工作藏进 GPU 计算时间里：GPU 处理第 N 步前向和采样时，CPU 已在准备第 N+1 步的批次，同时处理更早一轮的采样结果。开了投机解码之后，一条请求可能连续接受多个候选，CPU 还不知道最后能过几个，直接拿旧长度去组织计算，查询长度、键长度、旋转位置编码位置就全歪了。DeepInfer 维护一个在途计数，分配资源时提前预留缓存空间，再由设备侧内核修正长度。

V4.1 部署规模是预填充 EP2 到 EP8、解码 EP64 到 EP128，这么宽的专家并行，同一个通信域的卡必须步调一致。DeepInfer 在调度器里加了组内投票，两种模式：一种要求所有卡满足条件才能切，另一种允许部分卡触发，避免小请求久等。投票之后还有第二轮确认，因为队列里有请求不代表这一轮真排得出来。

投机解码（Speculative Decoding） 是一种加速自回归生成的技术。它先用一个轻量“草稿”模型（或模块）快速生成多个候选 token，再让目标大模型一次性并行验证这些候选：如果草稿猜对了前缀，就一次性接受多个 token，从而减少大模型的前向次数。关键在于验证是并行的，成本远低于逐个生成。草稿质量越高、接受长度越长，加速越明显；反之如果大量候选被拒，验证算力就浪费了。因此如何分配验证预算、动态决定验几个候选，是工程优化的核心。

算账：38 美元是收入，不是利润

DeepSeek 罕见地公开了单位经济：一个一天 155 万亿 token 的机群，按波峰价折算平均每卡每小时挣 38 美元，乘以 24 再乘以 30，一张卡一个月约 2.7 万美元。梁文锋曾在投资人闭门会上说过，API 定价是合理利润，大约买一批设备回来 10 个月收回成本，只赚合理利润，不追求利润最大化。

外面还有人在算另一笔账：有博主按 GB200 NVL72 的极限压榨能力推算，一季算力一年能跑出 1000 亿到 1490 亿美元的 token 收入，比机构预测高出近 10 倍；还有人按 B300 每小时 7 美元租金、利用率足够高，算出毛利率 82%。这些数字听着很爽，但都得打折看——前两个建立在乐观假设上，第三个只扣了 GPU 租金，没算存储、网络、运维和研发成本，而且高度依赖缓存命中率和流量结构。把它们当成 DeepSeek 的利润率或回本周期都不成立，38 美元指的是收入。

单位经济（Unit Economics） 指按单个可计量单位（如每张 GPU 卡、每百万 token、每个请求）核算收入与成本的分析方法。在 AI 推理服务中，常用“每卡每小时收入”衡量硬件变现效率，但它只反映流水，不等于利润。要得到真实利润，还需扣除 GPU 折旧或租金、存储与网络带宽、电力与散热、运维人力、研发摊销以及闲置率带来的浪费。因此同一组数字在不同假设下可以得出截然不同的毛利率，这也是外界对 DeepSeek 成本数据解读分歧巨大的原因。

开源的是引擎，不是底盘

官方 ReadMe 写得很清楚：构建完整推理服务还需要独立的 KV 缓存系统、视觉编码器与解码之间的解耦设施、数据并行副本之间的负载均衡。部署问答也承认，生产环境的缓存管理和负载均衡跟内部基础设施耦合太深，暂时没有完整开源。外部团队拿到代码能看到请求怎么穿过调度器、缓存、通信和采样，也能拆某一项优化搬回自己家，但想复刻一套同样又快又省的线上服务，还是得自己对接存储、网络、服务管理和故障切换。

硬件也是硬门槛：当前支持列表只有英伟达 SM100 和华为昇腾 950，H100、H800、A100 和消费级显卡都不在列。官方推荐 64 卡预填充加 64 卡解码，这是跑出效率的起步规模，不是能跑起来的下限。昇腾这部分值得单独说：9 月底 DeepSeek 已公开面向昇腾平台的编程工具、计算库和通信库，华为团队参与研发；彭博社报道过 DeepSeek 计划在内蒙古新数据中心部署至少 16 万张昇腾 950DT 芯片，但这是报道中的计划，不能算成已投入使用的规模。Recipe 的性能测试只在英伟达 SM100 上做过，两种芯片同时进入支持列表不等于跑出了相同的性能和成本。

这件事真正值得看的地方

过去几年外界看到的都是散件：Flash MLA 负责注意力，DeepGEMM 负责矩阵运算，DeepEP 负责专家通信，EPLB 负责专家摆放。每个零件都有论文和基准，但一个请求怎么穿过它们、中间的数据契约长什么样，一直是黑盒。DeepInfer 把这些放进了同一个公开工程，虽然没给全生产控制面，装配图已经能看到了。

这也说明模型结构正在决定运行时结构。MLA 吸收、滑动窗口、消费式生产者分层、超连接 MOE、多 token 预测，这些不是通用引擎能自动推断的配置项，它们直接改变缓存排布、调度器状态机、计算图形状和回滚逻辑。所以 DeepSeek 得自己写一套引擎，而不是在通用框架上打补丁。

开源本身既没有理想主义那么天真，也没有阴谋论说的那么黑。Recipe 把官方处理逻辑做成公共库，第三方照着实现，行为自然对齐——对开发者是好事，换了服务商也不容易出问题；对 DeepSeek 更是好事，提示词格式、工具调用格式、流式输出规则会随着越来越多第三方服务器采用，变成事实上的通用写法。Search 和 Fetch 抢的是入口，Agent 每次查资料都得调搜索工具，谁是默认的那个，谁就占住了位置。配方公开换来的东西，比配方本身值钱得多。

当推理引擎和接口格式都被做成公共品，模型厂商之间真正能拉开差距的还剩下什么？是数据，是场景，还是像可口可乐那样把冰柜摆进每一家店的能力。