DeepSeek 开源的 DeepInfer，不是给你省 API 钱的

结论先放这：它是 DeepSeek 内部生产推理框架的「离线推理」开源版，目标客户是有 GPU 集群的团队，不是想省几块钱 API 费的开发者。把它当成「自建 DeepSeek API 的捷径」，是从第一行 README 就误读了。

一、今天发生了什么

10 月 20 日，DeepSeek 把内部的大规模推理框架 DeepInfer 全面开源，Apache-2.0。仓库是 deepseek-ai/DeepInfer，10 月 16 日建仓，今天正式对外。

官方给的数据很硬：

· 支撑 DeepSeek-V4.1-Flash 的高吞吐、低延迟大规模推理服务

· 单一集群 155 万亿 tokens/天

· 每卡每小时收入 38 美金（官方说法是「按谷价」）

同时开源的还有 deepseek-recipe：一套 Rust 库 + Python 绑定，负责把不同格式的 API 请求统一转成 Conversation、渲染成 DeepSeek 的 prompt、用官方 tokenizer 编码成 token IDs、再把模型输出转回对应格式。MIT 协议。

注意这两个东西是一对：DeepInfer 管算，deepseek-recipe 管格式和分词。官方原文说得很清楚，recipe 的转换逻辑与官方 API「完整对齐」。

二、先把事实钉死：它给了什么、没给什么

README 很短，但信息密度很高。支持范围：

模型：只有 DeepSeek-V4.1-Flash（就是这段时间的 -1017 检查点）。

硬件：NVIDIA SM100（Blackwell）、华为昇腾 950。就这两类，没有 A100/H100，没有消费卡，没有 Mac。

形态：offline inference（离线推理）。官方明确写了，一个完整推理服务还缺三样，本仓库不含：

1. KV cache 系统

2. Prefill/Decode 分离（PD 分离）

3. Data-parallel 副本之间的负载均衡

环境：Linux、GCC ≥ 13、Python 3.12、CUDA 13（N 卡）或 CANN 9.2（昇腾）。

跑分：prefill 用 4 张 SM100，decode 用 64 张。

把这几行连起来读，答案就很清楚了：这是一份给「已经有 SM100/昇腾 950 集群、且有推理工程团队」的人用的东西。它把最难的那部分（算子、并行、投机解码、调度）开源了，但把「怎么把它跑成一个能对外服务的 API」留给了你自己。

所以第一层误读要排除：下载 DeepInfer ≠ 拥有一个 DeepSeek API。

三、技术上有意思的六件事

抛开「能不能白嫖」，这份代码里真正值得看的是几个工程选择。

1）算子全部自研或已开源。 FlashMLA、DeepGEMM、DeepEP、TileKernels、TileLang 内核。MLA 的 attention、MoE 的 all-to-all、GEMM 的 tile 调度，这三块是推理性能的命门，DeepSeek 之前就陆续开源过，这次是在框架层把它们串起来。

2）并行策略：Attention DP/CP + MoE EP + EPLB。 简单说，attention 层按 DP/CP 切，MoE 层按专家并行切，EPLB 负责专家负载均衡。MoE 推理最怕的就是专家热点——某些专家被路由爆了，其它卡在等。EPLB 就是解这个的。

3）DSpark + 置信度调度验证。 投机解码（speculative decoding）不新鲜，新鲜的是「用置信度估计来调度验证」。draft token 不是无条件全验证，而是按置信度决定验证多少，这直接影响吞吐和延迟的平衡点。默认 draft 长度 5，环境变量可调。

4）SWA bounded replay。 对 decoder 的 prefill 做「只回放一个有界后缀」，把 prefill 的计算量砍下来。V4.1 的默认配置是保留 140 个 token——这个后缀必须覆盖 SWA 窗口加上最大回溯长度，官方特意提醒了，配错就会破坏语义。

5）batch-invariant + 确定性采样。 这两条是给「要可复现」的场景准备的：同一个输入、同样的采样参数，输出必须一致。batch-invariant 保证结果不随 batch 组成变化；确定性采样再加固定 seq_seed。NVIDIA only。

6）结构化输出。 支持 regex、JSON schema、EBNF 语法约束生成。这个对做业务集成的人最实用——法律、金融、政务这类场景，输出必须是严格 JSON，不能靠 prompt 求模型自觉。

四、那它到底对谁有用

我不觉得它的价值在「省钱」。算笔粗账：decode 要 64 张 SM100 才能压出那个吞吐，这不是个人或小团队能玩的硬件；而且官方缺的那三块（KV cache、PD 分离、负载均衡）恰恰是把离线跑分变成在线服务最难的部分。

它的价值在三个「非成本」的方向：

第一，数据不出内网的选项。 律所、政企、医院这类客户，模型能力再强，只要数据要出内网就直接否掉。以前这类客户想用 DeepSeek 只有两条路：接受官方 API（数据出网），或者自己拿别的开源模型凑合（能力差一档）。现在多了第三条：有算力的客户自建 V4.1-Flash。对我们做 B 端产品的人来说，这是把「不能卖」变成「可以谈」的那一步。

第二，国产算力的对齐。 官方同时支持昇腾 950，这件事对信创采购的意义比技术本身大。NVIDIA 高端卡在国内的供给不确定性是长期变量，一个官方维护、原生支持昇腾的 DeepSeek 推理栈，等于给「国产化替代」这条路补上了软件侧的最后一块。

第三，可复现和结构化。 这两条在消费级对话里没人在意，但在合同审查、文书生成、合规判定这类场景里是硬需求：同样的输入必须出同样的结果（否则没法验收），输出必须是严格结构（否则没法入库）。官方 API 给不了 batch-invariant 和 deterministic sampling 的承诺，自建可以。

五、做客户端和插件的人，能立刻用上什么

我自己是做桌面客户端和插件这条线的，说三个我看到的、成本很低的使用点。

1）本地精确算 token 和费用。 deepseek-recipe 的 tokenizer 和官方 API 对齐，这意味着可以在本地把 prompt 编码成 token IDs，精确算出这次请求要花多少 token、多少钱，不用等响应里的 usage 字段。对做用量面板、预算控制、离线计费预估的产品，这是直接可用的零件。

2）协议桥。 客户端现在走的是 Anthropic Messages 协议到 api.deepseek.com/anthropic。deepseek-recipe 支持 Messages / Chat Completions / Responses 三种格式互转。将来如果要接自建模型、或者换任何一个后端，只需要在中间加一层格式转换，客户端内核一行不用改。这个「解耦」的价值，等真需要换的时候才知道有多省事。

3）给 B 端客户的私有化退路。 不是现在去做，而是等第一个客户问「能不能私有化部署」的时候，我们能拿出一条能验证的路径：客户有 SM100 或昇腾 950 → 用 DeepInfer 跑模型 → 用 recipe 做格式桥 → 客户端指向自建端点。到时候缺的是 KV cache 和 serving 层，得客户自己补或者我们一起补——这一点必须提前跟客户讲清楚，不能拿离线跑分当在线服务卖。

六、一个判断

这波开源真正改变的不是「成本」，是「选择权」。

以前用 DeepSeek 只有一条路：官方 API。它的价格、可用性、故障恢复时间，全在别人手里。10 月中旬那次接近 5 小时的服务中断，很多人都还记得。现在官方把生产框架的一部分放出来了，意味着对有能力自建的客户，「不押注单一供应商」这件事第一次变得可执行。

对绝大多数人来说，继续用官方 API 仍然是最优解——便宜、稳定、零运维。但对那些「数据不能出网」「结果必须可复现」「算力必须国产化」的场景，今天之前是没有答案的，今天之后有了一个起点。

我的判断是：DeepInfer 短期不会改变 API 市场格局，但它会让「私有化部署」这个选项从 PPT 变成可以报价的东西。 对做 B 端的人来说，这就够了。

---

本文部分内容由 AI 辅助整理，技术细节以 DeepInfer 官方仓库 与 TechWeb 报道 为准。

本文属于《技术观察》系列：既拆推理基础设施，也拆「工具自己会不会骗人」。