11 月 1 日起，AI 工具调用要单独计费了

📋 目录

• 一、被刷屏盖掉的那条公告
• 二、这笔钱到底有多大
• 三、同期还有几件事：一手涨价，一手融资
• 四、自建还是调 API：把判断写成清单
• 五、几个流传的说法，需要核对
• 六、对领码 SPARK 融合平台的映射
• 七、结语

一、被刷屏盖掉的那条公告

10 月 18 日 17:58，DeepSeek 发了一则《DeepSeek API 搜索服务定价通知》。原文不长，但每一句都带着成本：

DeepSeek API 现已支持网页搜索与抓取，按请求次数计费，单价为每 1000 次成功请求 5 元，请到价格页面查看详情。

请注意，当前用户在 DeepSeek Harness/Claude Code/Codex 中使用 DeepSeek API 时，已经会通过 Server 端工具调用访问到 Search/Fetch 接口，这部分 Search/Fetch 接口调用目前未计费，并将于北京时间 2026 年 11 月 1 日 00:00 起按次收取调用费用。

如您在计费调整后继续选择使用我们的服务，则代表您已同意调整后的计费方式；如不同意接受则可选择退出使用并申请退费。

公告里还有一句多数人没读到的细节：只有返回 HTTP 200 且产生结果的请求才会计费——搜索的结果必须非空，抓取必须返回网页正文。请求失败、搜索无结果或超时不计费。

这条公告发布的时间点很不巧。三天后（10 月 20 日），DeepSeek 开源了推理框架 DeepInfer，HN 讨论两千多条，全网都在谈"全球首个生产级推理引擎开源"。一条真正会改变企业账单的通知，就在这场刷屏的下面躺了三天。

而它的实际影响面可能比推理框架更大——因为它影响的不是"要不要自建"这种年度级决策，而是下个月就开始的每一笔调用。

二、这笔钱到底有多大

先把单价换算成能直接用的形态。

Search 和 Fetch 各是每 1000 次成功请求 5 元人民币（官方美元页面的对应值是每 1000 次成功请求 $0.75）。分开算：

单次 5 厘钱。按绝对金额看，这笔钱小到大多数团队根本不会注意。

那为什么值得单开一篇？因为真正的问题不是这 5 厘钱，而是它暴露的一类账。

一个典型的 Agent 任务长这样：读一段长文档、调两三次搜索、可能抓几个网页、跑几轮工具调用。如果一次用户请求平均触发 3 次 Search/Fetch，那么这个 Agent 每服务一个用户，就额外产生 1.5 分钱的搜索费。

假设一个客服 Agent 每天处理 20 万次请求：搜索费是每天 300 元，一年约 11 万元。这个数字本身不吓人。

**但真正需要关注的是它和 token 成本的关系。**用前面那笔账的框架看：V4.1-Flash 缓存命中输入是每百万 token 0.003 美元（约 0.02 元），输出是 0.6 美元（约 4 元）。一次 Agent 任务的输出 token 假设 500 个，输出成本约 0.002 元。

也就是说，一次 3 次搜索的 Agent 调用，搜索费（0.015 元）大约是输出 token 费的 7 倍。

这个比例关系才是要点。它意味着在 Agent 场景里，"工具调用次数"这个变量可能比"token 用量"这个变量更值得优化——而过去两年整个行业的成本优化注意力，几乎全在 token 上。

把三种典型 Agent 的成本结构摆出来对比（按一次用户请求计）：

工具费用在 Agent 场景里占到八成左右，而且这个比例相当稳定——因为它是按次计费，而 token 是按量计费，前者不随任务复杂度自动摊薄。

这个结论有一个直接的行动含义：**在 Agent 场景做成本优化，第一刀应该砍在"检索轮次"上，而不是"模型选型"上。**换更便宜的模型能省下那八分钱的 token 部分，省不掉那四毛钱的工具调用部分。

还有个容易被忽略的机制：失败不计费，但重试要计费。"只有返回 HTTP 200 且产生结果才计费"这条规则看起来对用户有利，实际上创造了一个反直觉的行为激励——搜索无结果不计费，所以"搜不到"不花钱；但一旦搜到了、抓到了正文，就花钱。

而对 Agent 来说，**最常见的模式恰恰是"搜一次、发现信息不够、再搜一次、抓一次、再抓一次"。**多轮检索会线性放大这个费用。

顺带算一个更实用的指标。如果一次用户请求平均触发 3 次 Search/Fetch，单次 0.005 元，那么每 1000 次用户请求的工具费是 15 元，每 10 万次用户请求是 1500 元，每 100 万次是 1.5 万元。

这个阶梯可以直接搬进预算表。相比之下，很多团队对"月调用量"的直觉偏差极大——把"用户请求数"当成"调用数"，直接低估三倍以上。Agent 场景里，一次用户请求对应多少次模型调用和工具调用，这个乘数必须先量出来。

三、同期还有几件事：一手涨价，一手融资

把 10 月中下旬这几件事排在一起看，能看到一条更清晰的线。

华夏时报的标题起得挺准：《从新增收费项目到二轮融资："不差钱"的 DeepSeek，开始认真谈钱了》。

有一个行业人士的观察值得展开。顺福资本创始人李明顺说，DeepSeek 的联网搜索 API 能力相当于一种"AI 引擎/基础设施"式的平台服务——开发者做 Agent 本地化、模型本地化，都需要实时搜索能力，这项服务可以吸引更多开发者融入生态。

这句话点出了 Search/Fetch 的真正定位：它不是一个小收费项，是一条新的入口。

看这个链条：DeepSeek 的开源模型吸引开发者 → 开发者用 DeepSeek API 跑 Agent → Agent 需要实时搜索 → 搜索走 DeepSeek 自研的 Search/Fetch → 这是平台级的、不可替换的调用。

**开源模型的公司，通过 API 把生态锁在自己的服务上。**这就是所谓"用工程文档换分发"的另一面——不只框架是入口，搜索也是。

有分析师把这解读为"对做开源模型的公司来说，这项业务非常有价值，未来大量企业客户用它的开源模型，同时调用它的 API，这会形成一个比较成熟的商业闭环"。

所以 11 月 1 日这个日期，真正的看点不是收费本身，而是DeepSeek 第一次把模型层之外的、纯服务型的调用变成了明确的收入项。

四、自建还是调 API：把判断写成清单

现在到了最实际的部分。这次开源给了一个新变量——推理框架开源了——所以"自建"这个选项第一次变得具体了。但要把这个选择做对，得先算三笔账。

第一笔：规模账

DeepInfer 官方口径的最小高效部署单元是 64 卡 prefill 加 64 卡 decode，共 128 张 SM100 或昇腾 950。

模型本身是 763,205,315,794 参数，48 个 safetensors 分片约 510 GB，社区 GGUF 量化最小到 246 GiB，1-bit 量化仍需超过 128 GB 系统内存。

**这一笔账的关键不是绝对金额，是"你的负载形态能不能被优化路径覆盖"。**DeepInfer 官方跑分是 96% 前缀缓存命中下的结果——如果你的业务是大量不重复的长 prompt，这个引擎的核心优势对你基本失效。

第二笔：功能账

功能对照这张表，直接决定某些负载能不能迁过去：

**有一个功能差异值得单独说：Search/Fetch。**自建 DeepInfer 意味着你要自己接搜索——而 DeepSeek 自研的 Search/Fetch 用的是自己的搜索引擎，返回结构化搜索结果和 Markdown 正文，与官方 API 对齐。自建不是"更便宜"，是"要自己解决一整条链路"。

第三笔：迁移成本账

这一笔最容易被漏算，因为它不在技术文档里。

DeepInfer 自己就源自 vLLM 深度魔改，而且 README 明确说 vLLM 会继续改进自己的 V4.1-Flash 支持、把 DeepInfer 的思路吸收进去。反过来说，DeepSeek 与 vLLM 的优化方向会持续分叉——今天你 patch 的是 DeepInfer 的某个调度逻辑，明天 vLLM 那边可能已经用另一种方式解决了同一个问题。

对一个要长期维护的平台来说，分叉维护的成本会随时间上升。这是所有"基于 X 的厂商分支"都在同一条线上挣扎的问题，区别只是 DeepSeek 选择了公开分叉。

还有一条容易被忽略的：deepseek-recipe 解决的正是"自托管时提示词渲染与官方 API 不一致"这个老问题。它是 MIT 许可、Rust 核心加 Python 绑定，0.2.0 版本。这东西单独用价值就很高——哪怕你完全不碰 DeepInfer，只是用官方 API，把它装上能让你的请求渲染和官方完全对齐，省掉一批难查的边界问题。

这张图的最后一行值得强调：**自建是一个大决策，deepseek-recipe 是一个小决策，但后者可能解决你八成的对齐问题。**先把小决策做了，大决策的信息也顺便攒够了。

五、几个流传的说法，需要核对

有一条值得单独提醒：**计费调整后继续使用即视为同意，不同意可退出并申请退费。**这条写在公告末尾，是给存量用户的一个明确选择权。有 Agent 应用在 11 月 1 日前批量跑一遍回归测试，是负责任的做法——因为服务端工具调用的行为变化，会直接影响输出结果。

11 月 1 日之前，这四件事可以做完

时间点很近，所以这四条要具体到能当天执行：

**第一，数一次真实的工具调用次数。**翻最近一周的调用日志，统计"每次用户请求平均触发几次 Search/Fetch"。这个数如果算错了，后面所有预算都错。它也是最容易被高估的——日志里通常只记了用户请求，没记 Agent 内部的工具循环。

**第二，标出那个"搜索最凶"的 Agent。**按 Agent 维度把工具调用次数排个序。排在第一位的那个，多半不是业务必需，而是检索策略没收敛——比如每次都重新发起同样的检索、或者失败后无限重试。

**第三，跑一遍回归。**11 月 1 日之后服务端工具调用的计费与行为可能有细微变化，输出结果也可能随之变化。在 10 月 31 日之前用固定语料跑一轮，把关键 Agent 的输出存档，11 月 1 日之后再跑一遍做对比。

**第四，查一下 query 里带了什么。**这是最容易被忽略、但风险最高的一条。**如果 Agent 把用户的原始输入直接拼进搜索 query，那么用户在提问里提到的内部信息（客户名、项目代号、未公开的数字），就被发到外部搜索服务了。**这件事平时没人查，因为不收费的时候它不产生账单；11 月 1 日之后它仍然不产生额外账单，但它产生的是合规问题。

第四条是这四件事里唯一一条与计费无关、但时间点相同的检查项。把它和计费准备放在一起做，是因为它们指向同一批代码路径。

这四件事里，E 那件最要紧。钱的事可以慢慢优化，数据出去的事不能等。

六、对领码 SPARK 融合平台的映射

这一节要说的不是"怎么省钱"，而是这三笔账里有一笔平台根本不该让企业自己算。

**其一，成本归因要能穿透到 Agent 的每一次工具调用。**过去企业看 token 账单，看到的是"这次对话花了多少钱"。但 Agent 场景下，一个用户请求可能触发几十次模型调用、几次搜索、若干次抓取。如果平台只能看到 token 总量，就永远发现不了"某个 Agent 的检索策略有问题，导致重复搜索"。

治理中心要能提供的一层能力是：把成本归因从"按模型"细化到"按 Agent、按工具、按调用链"。看到一个 Agent 的搜索次数是另一个的三倍，问题往往就在检索策略，而不在模型。

其二，工具调用是新的授权边界。这条比推理框架那篇更硬。Search/Fetch 意味着模型可以主动把 query 发到外部、把外部网页正文拉回内部。这两个方向的数据流，都穿过了原有的系统边界。

• 向外：query 里可能带用户输入、上下文片段，甚至内部术语——这些会不会被送到外部搜索服务？
• 向内：抓回的网页正文进入模型的上下文，然后可能影响最终输出，进而写回某个业务系统。

全域守卫要解决的就是这个：**"谁在什么域能看什么"这张表，必须能表达"外部工具调用"这个动作类型。**不是只管数据入库时的权限，也要管数据出库和外部内容回库这两个方向。

**其三，数据的进出要留下可追溯的链路，而不只是授权判断。**一个 Agent 搜了什么、抓了什么、这些内容进了哪次模型调用、影响了哪个最终输出——这条链路要能回溯。理由很实际：一旦模型输出出了合规问题，你需要能回答"它依据的是哪段外部内容"。

顺带说清与 Dify 一类编排层的分工：**编排层负责编排调用链，平台负责这一次调用链上数据的授权与追溯。**这次 Search/Fetch 计费公告恰好说明，编排层会持续加新的工具类型，每一次新增都会带来新的数据出入口——这个清单应该由平台的治理能力来兜底，而不是每次由业务方自己想起来。

一句话：工具调用越普及，"数据往哪流"这个问题就越不能靠人记。

七、结语

这条公告最值得注意的地方，是它和"开源推理框架"这两件事在同一天前后发生，却指向完全不同的方向。

开源框架是把能力给出去，换生态占位；Search/Fetch 收费是把服务卖出来，换现金流。一家公司同时做这两件事，说明它想清楚了哪部分该开源、哪部分该收费。

对企业的实际含义，可以收成三句：

**第一，11 月 1 日之前，先把 Agent 的工具调用链路跑一遍回归。**服务端工具调用开始计费后，行为变化会直接影响输出。这是最近的一个明确的时间点。

**第二，从这个月开始，把注意力从 token 成本挪一点到"工具调用次数"上。**在 Agent 场景里，一次任务 3 次搜索的费用大约是它输出 token 费用的 7 倍。这个比例决定了优化方向，而过去两年大家都在优化另一个方向。

**第三，自建推理是个大决策，但 deepseek-recipe 是个小决策。**先把这个装上，把请求渲染对齐的问题解决了；自建那件事，等调用量和复用率的数据攒够了再评估。

你团队里的 Agent，现在每次用户请求平均会触发几次搜索或抓取？你知道这个数吗？如果不知道，这大概是下个月账单里最该先搞清的一项。评论区说说你的场景，我按形态给一组排查顺序。