大家好，这里是最佳拍档，我是大飞。10月20日，DeepSeek开源了支撑线上服务的推理框架 DeepInfer 以及配套的编解码组件 deepseek-recipe。这次DeepSeek没有发布新模型，也没有刷新榜单，而是交出来了模型背后那台发动机的图纸。今天我们就来聊聊这个框架。要想理解DeepInfer，我们得先说清楚推理框架是什么。很多人以为模型开源就是把权重下载下来，事情就结束了。可权重只是一大堆数字，它不会说话，更不会回答问题。中间还隔着一整套工程：负责接单、排队、把请求送进芯片、取回结果。

技术博主宝玉曾经用菜谱和后厨打过比方：如果说模型文件是菜谱，推理框架就是后厨。同一本菜谱，交给不同的后厨，一小时能接多少单以及客人要等多久，差别可能会很大。所以开源引擎其实比开源权重罕见得多。权重开源已经是常规操作了，而引擎开源等于把后厨怎么排班、火开多大一起摊开给大家看。2025年4月，DeepSeek解释过为什么不开源内部引擎，大意是内部版本做了大量定制，很难搬到外部环境，团队也没精力维护大型项目。

不过到了今年10月，这个说法被他们自己推翻了。这次放出来的不止一个仓库：除了DeepInfer之外，还有 deepseek-recipe。再往前几天，DeepSeek上线了给模型用的搜索与抓取服务 Search 和 Fetch。三样东西看着很分散，其实是一条线：Search 和 Fetch去外面找料，DeepIner是后厨，recipe是多语种菜谱。这样一来，即使不同格式的客人点单，都能翻译成同一个厨房听得懂的话。我们先简单说一下Search 和 Fetch，它背后是一个平时没人算的成本。

我们都知道，搜索引擎是给人看的：一页结果里有广告、推荐、导航栏和弹窗，人扫一眼就能跳过。但是模型不行：每一个多余的字都要占上下文，都是 Token，都要花钱。这两个接口返回的是最原始的 JSON：Search 除了会给出标题、网址、摘要、正文和发布时间，还会额外给相关性评分和来源权威度两个分数。Fetch 就更简单了：给一个网址，返回清洗过的 Markdown。这两个API定价每1000次成功请求5元，用户可以在 DeepSeek Harness、Claude Code、Codex 里通过服务端工具调用使用。

北京时间2026年11月1日零点之前不计费，它也不需要绑定模型：只要有 DeepSeek 的 API，调别家的模型也行。当然，真正的主角还是 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。关于具体技术细节，我们后面还会细说。

然后是deepseek-recipe：它解决的是格式问题。眼下主流的 API 有三种：OpenAI 的 Chat Completions和Responses，还有 Anthropic 的 Messages。说到底都是问模型、拿答案，可格式不同：所以同一段对话没法直接搬过去。如果你想在自己的服务器上跑 DeepSeek，客户端却照着 OpenAI 那套写，那就会导致模型听不懂。所以中间得有人翻译：recipe 做的就是这层翻译。它的核心是用 Rust 写的，另外提供 Python 绑定。它把三种请求统一转成了内部的对话格式：按照模型版本拼成提示词，再用自带的分词器编码成 Token。

模型输出之后，它再把 Token 还原成对应协议的回复，流式吐回去。它还维护了一套跨数据块的解析状态机：因为一个汉字在 UTF-8 里占3个字节，很可能被拆到相邻两块里；工具参数也会被拆开。所以它会等数据齐了再进行解析，这样用户就看不到半个字了。它顺手还堵了一个安全口子：DeepSeek 的模型是靠一批特殊的 Token 来标记对话结构的，比如用户发言从哪里开始或者什么时候调用工具。如果有人在输入里手动敲出一模一样的用户标记或者图片标记，就可以冒充系统发号施令。

recipe 的处理方式是：只有构建提示词时显式插入的标记，才会映射成特殊 Token；用户敲的同样字符串会被当成普通文字。另外，不开启思考模式时输出的上限默认是8192个 Token；而开了思考模式后是65536，将推理力度拉满的话则可以达到131072。现在我们先来看个实例，看一下一个请求是怎么走完全程的：首先请求进门要先过 recipe 这一关变成 Token，然后分成两个阶段。第一个阶段叫预填充：模型把系统提示、历史对话、文件、问题一口气读完，每个 Token 在每一层都会算出一组中间结果。

这就是 KV缓存：第二个阶段叫解码，模型一个 Token 一个 Token地往外吐答案。每吐一个都要用到前面所有的 KV缓存：这两个阶段吃的资源完全不一样——预填充一次要处理几万个 Token，拼的是算力；解码一次只生成一个 Token，大部分时间花在从显存里读参数和缓存。所以 DeepSeek 把它们拆到不同的机器上，就是常说的 PD分离：这套系统设计之初定了三个目标。分别是兼容不同厂商的芯片、围绕常见硬件组织预填充和解码，还有让 KV缓存至少保留72小时。

落到部署上：预填充用常见的8卡服务器，解码用64到128卡的超节点。视觉编码器也被单独拉了出来：三个阶段各分各的资源，首 Token 延迟和 Token 间延迟分开进行优化。官方文档里还有一句话挺有意思：说视觉编码器一般单卡就行，建议用可用范围内最便宜的卡。实际部署里两边的卡数比例接近1比1：最小一组预填充加一组解码就能跑起来。但是想要跑出效率，还得按官方给的起步规模来配置。

接下来是整个系统里最省钱的一环：缓存 Agent 场景下，每调用一次工具客户端都要把完整的历史重新发一遍。系统提示、工具说明以及之前每一轮的回复和工具结果，一个都不能少：而这些绝大部分在上一轮已经算过了。DeepSeek 的做法是把算过的KV缓存存下来，下一轮只算新增的那一截。前提是前缀完全一致才能命中：所以必须从第一个 Token 开始对齐，中间开始的重复内容复用不了。缓存效果有多夸张呢？同一张卡跑预填充：不计缓存命中每秒可以处理6万个 Token，计入命中是150万个，差了25倍。

而DeepSeek线上平均每个请求输入77K：首字延迟平均400毫秒，P99是1000毫秒。命中缓存的输入售价只有未命中的五十分之一：命中率每提高一点，账单就薄一层。这些缓存没有放在计算机器自己的内存里而是进了独立的存储集群：用的是 DeepSeek 之前开源的分布式文件系统3FS，容量大约100 PB，清一色的固态硬盘。KV缓存以128个 Token 为一块写入：Agent 流量的缓存保留3天，聊天流量保留7天。

聊天流量留得更久是因为它有长尾命中的特征：少量缓存会被反复读很多次，丢掉对整体命中率影响更大。按照DeepSeek 的经验估算：只留3天的话聊天流量的命中率会掉0.5%到1%。放到行业里看：Anthropic、OpenAI 和 Google 的缓存大多只留5分钟到24小时，3天和7天算很长的。放在独立存储集群里还有两个好处：任何一台预填充机器都能读到任意一段的缓存，用户不用再绑死在上次的机器上了；计算机器的故障率也比存储高几个数量级以上：所以即使机器坏了缓存还在。

不过，读缓存也不能拖慢首字延迟：DeepSeek把命中分成三段。第一段在入口服务，用哈希链去本机的 kvcache-store 做前缀匹配：只查元数据，可命中长度必须在路由之前拿到。第二段取数据，通过独立进程异步把缓存从 3FS 搬进宿主机共享内存。第三段换入：引擎线程再从共享内存搬到显存，逐层传输和前向计算重叠。这里本来可以用 CUDA 的拷贝引擎：但是细粒度块的复制性能不理想，于是DeepSeek改用 GDR让 RDMA 网卡可以跑满 PCIe的带宽还不占计算单元。

底层存储也针对大约112 KB 的块随机读写做过优化：聚合读取峰值可以达到每秒10 TB。缓存总有没命中的时候，这部分最能看出 V4.1 的改动：V4.1 有一部分层用的是滑动窗口注意力，也就是 SWA。每个 Token 只看离自己最近的128个 Token：运行中的 Block KV缓存和 State KV缓存放在推理卡显存里了。Block 按128个 Token分页：持久的那部分写进3FS，SWA单独维护。前20层每层一个环形缓冲：窗口128个 Token，另外留了6个给投机回退。

它不进3FS：只会在产生它的那台机器内存里放一份，大约3分钟后清掉，命中率在98%以上。跨机器命中的话就会走400G的VLAN去拉数据：那对于没命中的2%该怎么办呢？V4 的做法是精确重算，逐层恢复窗口状态：要重算的 Token数等于层数乘以窗口长度。为了减少这种情况，V4 把这部分缓存也写进了硬盘：结果吃掉了硬盘缓存接近一半的容量。问题是它只在对话进行中的几分钟内有用，所以用能存好几天的硬盘去装显然性价比极低。

所以V4.1换了个思路：叫 SWA Bounded Replay（有界重放）。它只重新计算最后128个 Token：而且算的时候注意力也只在这128个Token之内，这样就能得到一份近似的窗口缓存。这样一来：重算成本变成了常数，跟上下文多长、模型有多少层就都没什么关系了。同样的办法也用在了 Decoder 的那20层上：这20层的窗口缓存每次预填充都要重建。改完之后原本要处理最后2560个 Token：现在只处理128个。预填充的总计算量因此少了接近一半。

不过：缓存解决读得快，解码解决也吐得快。模型每算一步本来只能生成一个 Token：投机解码的思路是先让轻量的草稿模块连续猜5个，再交给大模型一次性验证。猜对的部分直接采用：而在第一个猜错的位置由大模型给出正确答案。这样一步计算能拿到不止一个 Token，但是核对本身也要算力：5个草稿全拿去验的话很多算力就会被浪费在被拒绝的猜测上。DeepSeek 自研的这套叫 DSpark：先估计每个猜测被接受的概率，把验证预算往更有希望的地方倾斜。

相比每步固定要核对5个：动态核对让每步检查的数量减少了大约30%，平均被接受的长度反而基本不变。落到吞吐上：线上实测提升了6%。还有一组数据更细：序列数从16加到96，收益从负1.5%一路涨到11%，所以这个数字是有条件的：不是所有负载都快。还有一笔开销藏在 CPU 和 GPU之间：GPU算完当前这一步本来要停下来等CPU更新上一轮的状态，然后安排下一步。对要连续生成几千个 Token的请求：这种等待会反复发生。

而DeepInfer 的做法叫零开销批调度：名字听着像调度不要钱似的，其实是把 CPU的工作藏进了 GPU计算的时间。GPU在处理第 N步的前向和采样时，CPU已经在准备第N+1步的批次了：同时处理更早一轮的采样结果。所以部分工作可以提前提交到 GPU执行队列，依赖关系交给 CUDA Stream 和 Event维护。提前排程也会带来新的麻烦：CPU安排下一轮时上一轮的结果可能还不确定。普通自回归解码一次只推进一个 Token：而开了投机解码之后一条请求可能会连续接受多个候选。

假设它已经缓存了1000个 Token：当前轮可能接受3个，CPU还不知道最后能过几个。这样一来直接拿旧长度去组织计算：查询长度、键长度、旋转位置编码的位置就全歪了。DeepInfer 维护了一个计数：表示记录已经下发、但是结果还没提交的 Token；分配资源的时候他把在途计算也算进去了，提前预留了缓存空间。请求在相邻两轮批次里的位置也会改变：有的结束、有的新加入、有的被抢占。所以它还有一层映射把当前轮的请求对到上一轮的执行状态上：再由设备侧的内核来修正长度。

内存回收也被推后了：同步执行的时候请求一完成CPU就能释放引用，但是这在异步流水线里不行。某条请求虽然做完了：CPU后处理GPU上可能还有操作在用它。所以 DeepInfer 把要回收的元数据、输出对象和缓存块先放进队列：等后面的同步点统一处理。涉及 GPU状态复制的资源还要用 CUDA Event来确认完成。多卡之间也有同步问题存在：V4.1 的部署规模是预填充用 EP2到EP8，解码用 EP64到EP128。

这么宽的专家并行：同一个通信域的卡必须步调一致，否则一部分在跑预填充另一部分还在跑解码：集合通信就会对不上。DeepInfer 在调度器里加了组内投票：有两种模式，一种模式要求所有卡都满足条件才切；另一种允许部分卡触发避免小请求久等。投票之后还有第二轮确认：因为队列里有请求不代表这一轮真排得出来，实际中会遇到可能某张卡的缓存容量或者序列槽位不够的情况。确认完如果只有部分卡被排出任务：其余卡执行一个空的预填充步骤即可。

专家负载是另一个拖慢整轮计算的因素：V4.1 是典型的 MoE模型，路由专家一共384个。每个 Token只用到了其中6个：另外还有1个共享专家。解码阶段开到 EP64，这些专家就会被摊到64张卡上：每张卡放6个再加1个热门专家的副本。这7个都不含共享专家：每张卡上的专家越少每一步要从显存读的参数就越少，同样数量的卡就能接住更多的请求。热门专家的副本也不是固定的：要每1000步统计一次负载，每10000步重新分配。

线上实测的结果是：最忙的那张卡只比平均水平高9%。所以虽然残余的不均衡还在，但是已经压得比较低了：请求本身也要分匀。预填充按输入长度分成四档：分别是16K以下、16K到64K、64K到256K、256K以上。每一档要分配多少台机器是根据上一轮的需求动态调整的：解码同时看每卡的请求数和缓存总长度。短请求分给请求少、缓存长的卡：长请求分给缓存短的卡。这一套调度下来系统能跑到离线测试里完全均衡状态的80%左右：负载均衡器也分了四种，包括预填充、解码、视觉编码和专家并行各一个。

扩缩容放在集群层来做：预填充看未命中缓存的 Token数，解码看正在算的请求数。扩缩容都设了上下界和速率限制：大专家并行部署下最怕的是长尾请求被浪费。所以解码实例收到下线通知后并不会马上退出：而是先给1分钟宽限期。期限过了还没做完的连请求带KV缓存一次性转给别的实例接着来算：另外DeepSeek还常备了一批已准备好但是还没有分配的机器当做突发库存。配额占用率超过0.8的时候就会禁止缩容：故障这一块 DeepSeek 没去追求极短的重启时间，实际还是分钟级的。

靠冗余配额和请求级重新路由这两条兜住：一个实例里所有 GPU在同一个通信域，坏一张卡整个实例就都干不了活了。所以重启时可以重新数一遍健康的卡：按实际可用数量重新来确定EP的大小。关于跨机房这件事：官方说技术上可行，V4.1 大幅压缩了 KV缓存。每8张卡大约需要400Gbps的互联带宽：但是会牺牲可靠性，因为跨机房的光纤很容易被挖断。这也是为什么DeepSeek他们自己的推理节点都要放在不同但相邻的机房里：技术方面讲完了，我们差不多该算算账了。

DeepSeek 这次罕见地把单位经济公开了：它有一个一天155万亿 Token的集群。按照波谷价折算平均每卡每小时能挣38美元：乘以24再乘以30，一张卡一个月大约2.7万美元。这个数字是同行很少公开过的：梁文锋曾经在之前的投资人闭门会上说过，他们的 API定价是一个合理的利润。大概是买一批设备回来10个月收回成本：他还说过只赚合理的利润，不追求利润最大化。当然：DeepSeek 明确是要有商业化的，最终还是要能活下去。本质上还是一个公司只是在考虑赚哪些钱、什么时候赚钱、靠什么赚钱以及如何取舍。

如果我们把这些话和可口可乐的故事放在一起：很多事好像就对上了。2011年可口可乐配方泄露，结果几乎什么都没发生：公司说那只是早期手稿。量产版本早就改过好几轮了。

于是股价没变，销量反而涨了。因为可乐的护城河从来不是糖浆配方，而是灌装分销网络、是品牌心智、是成本纪律。DeepSeek 这次的做法很像可口可乐，把配方全公开了，但是赚钱的根本不是配方。那它图的究竟是什么呢？答案在入口和格式上。

现在各家旗舰模型的差距在收窄，单靠参数和榜单很难拉开身位，竞争重心正从谁的模型更强，转向谁掌握入口、数据流和格式。Search 和 Fetch 抢的就是入口：Agent 每次查资料都得调一个搜索工具，谁是默认的那个，谁就占住了位置。而且什么模型都能走这个入口，每一次查询、抓取、引用选择，都可能变成训练信号。

形成“入口、数据、模型”以及更强入口的飞轮；Recipe 抢的是格式。它把官方的处理逻辑做成公共库，第三方照着用就行了，行为会自然对齐。这对开发者来说当然是一件好事：对于针对官方行为调好的 Agent，换其他服务商也不容易出问题；对 DeepSeek 那就更是好事了。

提示词格式、工具调用格式、流式输出的规则，都会随着越来越多第三方服务器采用，变成事实上的通用写法。社区的反应也很直接：vLLM 官方账号发文致谢，感谢 DeepSeek 把最初基于 vLLM 打造的 DeepInfer 用 Apache 2.0 协议回馈给社区。

DeepSeek 研究员 Deli Chen 在 X 上说：“这是开源与闭源的对决，对方想打多久就打多久。”DeepSeek Harness 负责人崔添翼说得更实在：“开源就是希望全世界的公司都能部署 DeepSeek 模型，靠它实打实地赚到钱。”

外面还有人在算另一笔账。有博主按 GB200 NVL72 的极限压榨能力推算，1GW 算力一年能跑出 1000亿到 1490亿美元的 Token 收入，比之前机构预测的要高出接近十倍。还有人按 B300 每小时 7美元的租金、假设 API 使用率足够高，算出毛利率为 82%。

如果按 3到6美元租金来测算，租金只占收入的 6%到12%。这些数字虽然听着很爽，但实际上都是得打折看的：前两个都建立在乐观假设上；第三个只扣了 GPU 租金，没算存储、网络、运维和研发的成本。

而且高度依赖缓存命中率和流量结构，所以把它们当成 DeepSeek 的利润率或回本周期都不成立。38美元是收入，不是利润；也不是 DeepInfer 一个项目单独创造的收益。

还有一个更根本的限制：这次开源的是引擎，并不是底盘。DeepSeek 的 DeepInfer 在官方 README 里写得很清楚：构建完整的推理服务还需要三样东西，分别是独立的 KV 缓存系统、视觉编码器、预填充与解码之间的解耦设施，以及数据并行副本之间的负载均衡。

部署问答中也承认：生产环境的缓存管理和负载均衡跟内部基础设施耦合太深，暂时也没有完整开源。所以外部团队拿到代码，虽然能看到请求是怎么穿过调度器、缓存、通信和采样的，也能拆出某一项优化搬回自己家用。

但是想要复刻一套同样又快又省的线上服务，还是得自己对接存储、网络、服务管理和故障切换。不过如果可以跑通离线推理，估计离生产系统就不远了。

当然，硬件也是一个硬门槛。当前支持列表中只有英伟达 SM100 和华为昇腾950；H100、H800、A100 以及普通消费级显卡都不在里面。官方推荐 64卡预填充加 64卡解码，这是跑出效率的起步规模，不是能跑起来的下限。

可是对大多数团队来说，这套东西暂时还不是下载完就能开张的工具。昇腾这部分我们单独拿出来说两句：9月底 DeepSeek 已经公开了面向昇腾平台的编程工具、计算库和通信库，华为团队参与了研发支持。

同月，彭博社报道过 DeepSeek 计划在内蒙古的新数据中心部署至少 16万张昇腾950DT 芯片。这是报道中的计划，不能算成已经投入使用的规模；另外 README 里的性能测试只在英伟达 SM100 上做过。

两种芯片同时进入支持列表，不等于已经跑出了相同的性能和成本。那这件事到底该怎么评价呢？我觉得，这件事真正值得看的地方其实是 DeepSeek 少见地把零件装到了一起。

过去几年外界看到的都是散件：FlashMLA 负责注意力，DeepGEMM 负责矩阵运算，DeepEP 负责专家通信，EPLB 负责专家摆放。每个零件都有论文和基准，但是一个请求怎么穿过它们、中间的数据契约大约该长什么样，一直还是黑盒。

DeepInfer 把这些放进了同一个公开工程里：虽然没有完全给全生产控制面，但是整体的装配图已经能看到了。这也说明模型结构正在决定运行时结构：MLA、稀疏索引、滑动窗口、YOCO 式的生产者消费者分层、超连接、MoE、多 Token 预测。

这些不是通用引擎能自动推断的配置项，它们会直接改变缓存的排布、调度器的状态机、计算图的形状和回滚逻辑。所以 DeepSeek 得自己写一套引擎，而不是在通用框架上打补丁。

至于开源本身，我倒觉得既没有理想主义那么天真，也没阴谋论说得那么黑。《尹文子·大道上》有言：“为善与众行之，为巧与众能之。”意思是做善事要带着大家一起做，有本事要让众人都能掌握。

当然，商业上的算盘也是真的：这两件事并不冲突。配方公开的话，能换来的是入口、格式、数据流和规模；这些其实比配方本身值钱得多。最后剩下的问题是：如果当推理引擎和接口格式都被做成公共品，模型厂商之间真正能拉开差距的会剩下什么呢？

是数据、是场景；还是像可口可乐那样，把冰柜摆进每一家店的能力呢？感谢收看，我们下期再见。