DeepSeek 开源推理引擎，把省钱的门道摊开了​ | DeepInfer | 推理框架开源 | 推理引擎 | V4.1 Flash |KV缓存 | 集群调度 | 3FS | PD分离 | 投机解码

开源引擎：从“菜谱”到“后厨图纸”的范式转移

2024年10月20日，DeepSeek开源了支撑其线上服务的推理框架 DeepInfer 以及配套的编解码组件 deepseek-recipe。这一举动标志着其战略重心的转移：这次DeepSeek没有发布新模型，也没有刷新榜单，而是交出来了模型背后那台发动机的图纸。在此之前，业界普遍认为开源权重已是常规操作，但引擎的开放意味着将“后厨”的排班、火候控制等核心工程细节完全摊开。正如技术博主宝玉所比喻，模型文件是菜谱，而推理框架则是后厨。同一本菜谱交给不同的后厨，接单效率和等待时间可能天差地别。因此，开源引擎比开源权重罕见得多，它直接暴露了系统如何接单、排队、调度芯片并返回结果的完整工程链路。

DeepSeek此前曾解释不开源内部引擎的原因是“定制过多、难以迁移且维护成本高”，但此次开源行为推翻了这一说法。这次发布的并非单一仓库，而是包含 DeepInfer、deepseek-recipe 以及此前上线的搜索抓取服务 Search/Fetch 的一整套体系。这三者构成了一条完整的数据与服务流水线：Search和Fetch负责去外部获取原始数据，DeepIner作为“后厨”进行推理处理，而recipe则充当多语种菜谱的翻译器。这种组合拳旨在解决不同格式客户端请求的统一接入问题，确保即使输入格式各异，也能被转化为厨房（模型）能听懂的标准语言。

“权重只是一大堆数字，它不会说话，更不会回答问题。中间还隔着一整套工程。”

数据入口与格式标准化：Search、Fetch与Recipe的协同机制

在深入推理引擎之前，必须理解其上游的数据入口组件。Search和Fetch接口背后隐藏着一个常被忽视的成本：模型处理上下文的Token费用。搜索引擎返回的结果包含广告、导航栏等人类可忽略的信息，但对模型而言，每一个多余字符都占用Token并产生费用。DeepSeek提供的Search接口返回原始JSON格式数据，包含标题、网址、摘要、正文及相关性评分和来源权威度两个分数；Fetch接口则更简单，输入网址返回清洗后的Markdown文本。这两个API定价为 每1000次成功请求5元，且在2026年11月1日零点前不计费。它们不绑定特定模型，只要有DeepSeek API即可调用其他模型的接口。

deepseek-recipe 的核心任务是解决API格式兼容性问题。目前主流API包括OpenAI的Chat Completions/Responses和Anthropic的Messages，虽然本质都是问答，但格式差异导致客户端代码无法直接复用。Recipe用 Rust 编写并提供Python绑定，将三种请求统一转换为内部对话格式。它通过模型版本拼接提示词，使用自带分词器编码为Token，并在输出后将Token还原为对应协议的流式回复。Recipe维护了一套跨数据块的解析状态机，因为UTF-8编码的一个汉字可能跨越两个数据包，工具参数也可能被拆分。它等待数据完整后再解析，避免用户看到半个字的情况。

此外，Recipe还修复了一个关键的安全漏洞。DeepSeek模型使用特殊Token标记对话结构（如用户发言开始、工具调用等）。如果用户在输入中手动敲入相同的标记，可能冒充系统指令。Recipe的处理方式是：只有构建提示词时显式插入的标记才会映射成特殊Token，用户敲入的相同字符串被视为普通文字。在输出限制上，不开启思考模式时上限为 8192个Token，开启后提升至 65536个Token，推理力度拉满时可达 131072个Token。这种格式标准化的意义在于，它让第三方开发者能轻松适配DeepSeek的行为规范，从而形成事实上的通用写法标准。

“Search和Fetch去外面找料，DeepInfer是后厨，recipe是多语种菜谱……即使不同格式的客人点单都能翻译成同一个厨房听得懂的话。”

架构设计：PD分离与硬件适配策略

DeepInfer 采用 Apache 2.0协议，支持英伟达SM100和华为昇腾950芯片。运行环境要求Linux、Python 3.12及GCC 13以上，英伟达侧需CUDA 13，昇腾侧需CANN 9.2。当前仅支持 DeepSeek-V4.1-Flash模型，默认权重代号为 DeepSeek-V4.1-Flash-1017。理解其架构需先区分推理的两个阶段：预填充（Prefill）和解码（Decoding）。

在预填充阶段，模型一次性读取系统提示、历史对话、文件和问题等所有输入Token。每个Token在每一层计算出一组中间结果，即 KV缓存。此阶段拼的是算力，需处理数万个Token。在解码阶段，模型逐个生成输出Token，每生成一个都依赖之前所有的KV缓存。此阶段大部分时间花在从显存读取参数和缓存，算力需求相对较低。DeepSeek将这两个资源消耗截然不同的阶段拆分到不同机器上，即业界常说的 PD分离（Prefill-Decode Separation）。

系统设计之初确立了三个目标：兼容不同厂商芯片、围绕常见硬件组织预填充和解码、让KV缓存至少保留72小时。在部署上，预填充使用常见的8卡服务器，解码使用64到128卡的超节点。视觉编码器被单独剥离，建议用可用范围内最便宜的卡。实际部署中，预填充与解码的卡数比例接近 1:1。最小配置为一组预填充加一组解码，但为了跑出效率需按官方起步规模配置。

“预填充一次要处理几万个Token拼的是算力，解码一次只生成一个Token大部分时间花在从显存里读参数和缓存。”

核心省钱机制：长时KV缓存与3FS存储集群

KV缓存（Key-Value Cache） 是DeepInfer中最具经济效益的组件，尤其在Agent场景下。在工具调用场景中，客户端每次请求都需发送完整的历史记录（系统提示、工具说明及过往回复）。由于这些内容在上一轮已计算过，DeepSeek的做法是 将算过的KV缓存存储下来，下一轮仅计算新增部分。前提是前缀完全一致才能命中，因此必须从第一个Token开始对齐。

缓存带来的性能提升极为显著。在同一张卡上，不计缓存命中时每秒处理6万个Token，计入命中后达到150万个Token，性能提升25倍。DeepSeek线上平均每个请求输入 77K Token，首字延迟平均 400毫秒（P99为1000毫秒）。命中缓存的输入售价仅为未命中的 五十分之一。这意味着命中率每提高一点，账单就薄一层。

这些缓存并未存放在计算节点本地内存中，而是进入了独立的分布式存储集群 3FS（DeepSeek此前开源的文件系统）。该集群容量约 100 PB，全为固态硬盘。缓存以 128个Token为一块写入。Agent流量的缓存保留3天，聊天流量保留7天。选择长周期是因为聊天流量具有长尾命中特征，少量缓存会被反复读取，丢弃会对整体命中率产生较大影响。DeepSeek估算，若聊天流量仅保留3天，命中率会下降 0.5%到1%。相比之下，Anthropic、OpenAI和Google的缓存大多仅保留 5分钟到24小时。

独立存储集群带来两大优势：一是任何预填充机器均可读取任意缓存，用户无需绑定特定机器；二是存储故障率远低于计算节点，即使机器损坏数据仍在。然而，读取缓存不能拖慢首字延迟。DeepSeek将命中过程分为三段： 1. 入口服务：用哈希链在本机KV Cache Store做前缀匹配，仅查元数据。 2. 取数据：通过独立进程异步将缓存从3FS搬入宿主机共享内存。 3. 换入：引擎线程从共享内存搬至显存，与前向计算重叠。

为优化细粒度块复制性能，DeepSeek未使用CUDA拷贝引擎（因PCIe带宽受限），而是改用 GDR，让RDMA网卡跑满PCIe带宽且不占计算单元。底层存储针对约 112 KB 的块随机读写优化，聚合读取峰值可达每秒 10 TB。

“命中率每提高一点，账单就薄一层。聊天流量留得更久是因为它有长尾命中的特征。”

滑动窗口注意力优化与投机解码策略

对于未命中缓存的2%请求，V4.1模型采用了 滑动窗口注意力（SWA） 机制。每个Token仅关注最近 128个Token。运行中的Block KV缓存和State KV缓存位于推理卡显存中，Block按128个Token分页。持久部分写入3FS，SWA单独维护。前20层每层一个环形缓冲（窗口128个Token），另留6个给投机回退。这部分SWA缓存不进3FS，仅存于产生它的机器内存中约 3分钟后清除，命中率在 98%以上。跨机器命中则通过400G VLAN拉取数据。

针对未命中的情况，V4采用精确重算（逐层恢复窗口状态），导致重算Token数等于 层数乘以窗口长度。为减少此开销，V4曾尝试将SWA缓存写入硬盘，但这占用了近一半的硬盘容量且仅在对话几分钟内有效，性价比极低。V4.1引入了SWA Bounded Replay（有界重放）机制：仅重新计算最后 128个Token，且注意力范围限制在这128个Token内。这样重算成本变为常数，与上下文长度和层数无关。

同样应用于Decoder的20层窗口缓存重建。改进前需处理最后 2560个Token，改进后仅处理128个，预填充总计算量减少近 一半。此外，DeepSeek还实现了自研的投机解码框架 DSpark。

传统投机解码让轻量草稿模块连续猜测5个Token，大模型一次性验证。DSpark则 动态估计每个猜测被接受的概率，将验证预算倾斜给更有希望的猜测。相比固定核对5个，动态核对使每步检查数量减少约 30%，平均接受长度基本不变。线上实测吞吐提升 6%。细粒度数据显示，序列数从16增加到96时，收益从 -1.5% 涨至 11%。这表明投机解码的收益是有条件的，并非在所有负载下都显著。

“V4.1换了个思路叫SWA Bounded Replay……重算成本变成了常数，跟上下文多长、模型有多少层就都没什么关系了。”

零开销批调度与负载均衡机制

GPU计算完成后需等待CPU更新状态并安排下一步，这种同步在连续生成数千Token时造成大量浪费。DeepInfer采用 零开销批调度（Zero-Overhead Batch Scheduling），将CPU工作隐藏进GPU计算时间。当GPU处理第N步前向和采样时，CPU已在准备第N+1步批次及更早一轮的采样结果。依赖关系由 CUDA Stream和Event 维护，部分工作提前提交至GPU执行队列。

异步流水线带来长度不确定性问题。投机解码可能导致一条请求连续接受多个候选，CPU难以预判最终长度，导致查询长度、键长度及旋转位置编码错位。DeepInfer维护一个计数记录 已下发但未提交的Token，在分配资源时将“在途计算”计入并预留缓存空间。请求在相邻两轮批次中的位置会动态变化，系统通过映射层将当前轮请求对应到上一轮执行状态，由设备侧内核修正长度。内存回收也被推迟至同步点统一处理，涉及GPU状态复制的资源需等待CUDA Event确认完成。

在多卡部署中，V4.1预填充采用 EP2到EP8（专家并行），解码采用 EP64到EP128。为防止集合通信不同步，调度器加入组内投票机制：一种模式要求所有卡满足条件才切换，另一种允许部分触发以避免小请求久等。投票后还有第二轮确认，若仅部分卡有任务，其余执行空预填充步骤。

针对MoE模型 384个专家（每Token用6个+1共享）的负载不均问题，解码阶段EP64下每张卡放置 6个专家加1个热门副本。每 1000步统计负载，每 10000步重新分配。线上实测最忙卡仅比平均高 9%，残余不均衡被有效压制。

请求调度按输入长度分四档（16K以下、16-64K、64-256K、256K以上），动态调整机器分配。解码时短请求分给缓存长卡，长请求分给缓存短卡。整套调度使系统达到离线均衡状态的 80% 左右。负载均衡器分为预填充、解码、视觉编码和专家并行四类。扩缩容基于未命中Token数（预填充）或正在计算请求数（解码），并设上下界及速率限制。实例下线前给予 1分钟宽限期，未完成请求连同KV缓存迁移至其他实例。集群常备未分配机器作为突发库存，配额占用率超 0.8 时禁止缩容。故障处理依靠冗余配额和请求级重路由，重启时按健康卡数重新确定EP大小。

“零开销批调度……把CPU的工作藏进了GPU计算的时间，部分工作可以提前提交到GPU执行队列。”

商业逻辑与开源战略：入口、格式与护城河

DeepSeek罕见地公开了单位经济数据。其拥有 一天155万亿Token 的集群，按波谷价折算，平均每卡每小时收入 38美元。折合每月每卡约 2.7万美元（按30天计算）。梁文锋曾在闭门会表示，API定价保证 10个月收回设备成本，只赚合理利润而非最大化。这与可口可乐策略相似：公开配方（权重/引擎），但护城河在于灌装分销网络、品牌心智和成本纪律。

DeepSeek的盈利核心不在于模型本身，而在于 入口、数据流和格式。 1. Search/Fetch抢占入口：Agent调用搜索工具时，默认接口占据关键位置。无论使用何种模型，查询、抓取和引用选择都可能转化为训练信号，形成“入口-数据-模型”飞轮。 2. Recipe抢占格式：将官方处理逻辑开源为公共库，使第三方行为自然对齐。这不仅方便开发者适配DeepSeek，也增加了用户迁移至其他服务商的难度（因提示词、工具调用格式已成事实标准）。

社区反应积极，vLLM致谢DeepSeek回馈Apache 2.0代码。研究员Deli Chen称这是“开源与闭源的对决”，DeepSeek Harness负责人崔添翼表示希望全球公司部署并获利。外界虽有乐观估算（如1GW算力年收千亿美元、毛利率82%等），但这些数据基于乐观假设或未扣除存储运维成本，且38美元仅为收入非利润。更重要的是，DeepIner并非完整底盘。官方README指出，构建生产服务还需独立的KV缓存系统、视觉编码器解耦设施及数据并行负载均衡。这些与内部基础设施深度耦合，暂未开源。

硬件方面，当前仅支持 英伟达SM100 和 华为昇腾950。H100/H800/A100及消费级显卡不在支持列表。官方推荐起步规模为 64卡预填充加64卡解码，这是效率门槛而非运行下限。昇腾950虽已列入支持列表且华为参与研发，但性能测试仅在SM100上完成，两者性能和成本差异尚不明确。DeepSeek计划在内蒙古部署至少 16万张昇腾950DT 芯片，但这属计划规模。

“配方公开的话，能换来的是入口、格式、数据流和规模。这些其实比配方本身值钱得多。”

结论

DeepSeek开源DeepInfer及其配套组件，本质上是将模型运行时的工程细节从黑盒变为白盒。通过 PD分离架构、基于3FS的 长时KV缓存（Agent 3天/聊天7天）以及针对V4.1滑动窗口的 有界重放优化，DeepSeek实现了极高的吞吐效率和极低的边际成本。其商业战略不再单纯依赖模型权重的稀缺性，而是通过 Search/Fetch抢占数据入口 和 Recipe标准化API格式，构建起类似可口可乐分销网络的护城河。尽管开源代码未包含完整的生产级存储与负载均衡控制面，且硬件支持目前局限于高端芯片（SM100/昇腾950），但这一举动确立了DeepSeek在推理框架领域的标准制定者地位。未来模型厂商的竞争焦点，将从参数规模转向 数据获取能力、场景落地深度以及基础设施的成本控制力。