DeepSeek搜索API定价拆解：按成功请求计费背后的隐藏成本

DeepSeek^广告 在 API 中上线了搜索与网页抓取功能，以每 1000 次成功请求 0.75 美元的价格迅速登上 Hacker News 首页。但"成功请求"这个计费单位里藏着不少值得推敲的细节——原文作者以读合同的方式逐条拆解了定价页，并在没有 API Key 的情况下探测了错误处理的边界。

计费规则的实际含义

两个端点都挂在常规的 DeepSeek base URL 下：/v1/tools/search 和 /v1/tools/fetch。官方文档写明，只有 HTTP 200 且返回了结果的请求才计费：搜索返回空结果数组不计费，抓取无内容不计费，失败和超时同样不计费。count 参数不影响价格。

这三条规则组合起来，产生了三个没有写在标题里的推论。

单条结果成本可相差 50 倍

一次请求固定花费 0.00075 美元，无论返回 1 条还是 50 条结果。count=50 时每条结果成本为 0.000015 美元，即每千条 1.5 美分；count=1 时同样的库存贵了 50 倍。这意味着默认值 10 并非成本最优解，具体怎么设置取决于你的 agent 实际需要多少条结果。

空结果免费，存在性检查零成本

"X 是否存在相关信息"这类查询，只有在答案存在时才产生费用。这个特性对构建探索型 agent 相当友好——探测性搜索不会因为查得多而烧钱。

探索型 agent（exploratory agent） 指那些在执行任务时频繁发起试探性查询、以“先查再决策”为主要工作模式的智能体，例如先确认某个实体或事实是否存在，再决定是否深入抓取或调用其他工具。这类 agent 的查询中有相当比例可能返回空结果，如果空结果也计费，探测行为就会变成持续烧钱的负担。DeepSeek 将“返回空结果数组”排除在计费之外，等于把存在性检查的边际成本降为零，使 agent 可以更积极地做覆盖式探测。不过要注意，免费只针对搜索端点返回空数组的情况；如果 agent 随后对命中结果发起抓取或把摘要注入上下文，仍然会产生抓取费或模型 token 费，因此“探测免费”不等于“探测无成本”。

真正的账单在上下文里

这是最容易被忽视的一点。50 条结果、每条 600–800 字符的摘要，合计 30000–40000 字符，还没算 snippet。DeepSeek 收你 0.00075 美元完成搜索，但你的模型读取这些内容的 token 费用另算。搜索费是零头，阅读费才是大头。

文档还规定了速率上限：搜索和抓取各 5 QPS，独立计算。满速跑一天最多 432000 次成功请求，单端点日花费上限 324 美元，双端点 648 美元。这个数字本身就是失控循环的支出天花板，对 agent 工具来说算是难得的可控性。另外，通过 DeepSeek Harness、Claude Code 或 Codex 作为服务端工具调用时目前免费，按请求计费从 2026 年 11 月 1 日（北京时间）开始——存在一个计费表已装好但尚未启用的窗口期。

QPS（Queries Per Second） 是衡量 API 端点每秒可接受请求数的常见指标，通常由服务端按时间窗口对每个账户或每个 Key 进行独立限流。文中“搜索和抓取各 5 QPS，独立计算”意味着两个端点的配额互不影响，并且限流一般以滑动窗口或令牌桶实现：短时突发可能被允许，但持续满载请求会触发 429 响应。对 agent 来说，QPS 与单次请求价格结合可以估算严格的支出上限：5 × 86400 × 0.00075 ≈ 324 美元/天/端点，双端点即 648 美元。这个上限不考虑重试和并发抖动，也未计入模型读取搜索结果的 token 成本，因此它只是搜索费的硬顶，而非整体 agent 运行成本的上限。

无 Key 探测：鉴权优先于一切

原文作者没有 DeepSeek Key，但这恰好足以测试错误面。文档说无效请求返回 400、无效 Key 返回 401，但没说判定顺序。于是作者构造了"双重错误"的请求——坏 Key 加坏 body——看哪个错误先触发。

八次测试，八次都是 401：

search, no key                          -> 401  1.11s
search, fake key                        -> 401  0.82s
search, fake key + count=999            -> 401  0.78s
search, fake key + empty query          -> 401  0.57s
fetch,  fake key                        -> 401  0.63s
fetch,  fake key + url="not-a-url"      -> 401  0.53s
search, fake key + malformed JSON body  -> 401  0.53s
fetch,  no key                          -> 401  0.55s

count=999（文档范围 1–50）、空 query、非 URL 的 URL、甚至不是 JSON 的 body，全部返回同一个 401。中间件把鉴权放在了最前面，这个顺序本身是对的——校验错误的形状是信息，没必要泄露给陌生人。但代价是文档里那些 400 示例，在你提供有效 Key 之前根本不可达。文档描述的是付费用户视角的 API；其他人看到的 API 只有一个重复的错误。

错误响应中的字段矛盾

那个 401 的响应体有个值得注意的瑕疵：type 字段是 authentication_error，code 字段却是 invalid_request_error。两个字段，一个错误，标签互相矛盾。如果你的客户端根据 code 做分支判断，鉴权失败会被归类为请求错误。文档确实提醒过 param 恒为 null，八次响应里它也确实都是 null——这部分合同履行得准确。

还有一个细节：错误消息会回显所发 Key 的掩码片段（如 ****-000，伪造 Key 的后三位）。对假 Key 无害，但如果日志管道捕获了真实 Key 的错误消息，掩码只保留尾部，而尾部恰恰是人们用来区分 Key 的部分。

401 与 400 的语义区别 在 HTTP 规范中有明确分工：401 Unauthorized 表示请求缺少有效的身份凭证，客户端应重新认证；400 Bad Request 表示请求本身格式或参数有误，与身份无关。当服务端把鉴权中间件放在参数校验之前时，任何未通过鉴权的请求——哪怕 body 不是合法 JSON、count 超出范围、url 不是 URL——都会先得到 401，而不会暴露参数校验的具体规则。这种设计在安全上是合理的，因为它避免向未认证方泄露内部校验逻辑和错误形状；代价是公开文档中描述的 400 示例只能被持有有效 Key 的付费用户复现。对客户端开发者而言，这意味着不能依赖 400 来调试无 Key 状态下的请求格式，必须先解决鉴权才能看到参数层面的反馈。

集成建议

定价模型本身是合理的：只为返回结果的 200 付费，失败和空结果免费，价格与 count 解耦，速率限制同时充当支出上限。在接入 agent 之前，需要建模的不是 0.75 美元，而是一次满配调用注入上下文的 30000–40000 字符摘要，以及在 11 月 1 日之前通过 harness 调用完全免费的窗口。集成时，错误判断请匹配 type 而非 code——原文作者验证过，code 在撒谎。