千次搜索 0.75 美元：DeepSeek 开放全套 App 能力，开发者账单怎么算

先说结论：

DeepSeek 在 2026 年 11 月 13 日把之前聊天 App 独占的完整工具链开放给了 API 开发者。大家以为这次改动只是给大模型加了一个简单的联网开关，实际上 DeepSeek 把文档解析、多步推理搜索、网页抓取、语音听写和文本朗读做成了开箱即用的服务器端服务。

费用计算采用 token 加上单次工具调用的双轨账单。搜索与网页抓取每 1000 次成功请求各收 0.75 美元，OCR 图像识别每 1000 页收 0.225 美元，只有成功调用才扣费，搜索落空不计费。

目前这批内置高级工具绑定在 deepseek-flash 模型上，据报道 deepseek-v4-pro 暂不支持内置联网搜索和文件输入。对于需要直接在接口里处理复杂网页或长文档的业务，现在不需要再自己费力维护爬虫代理和解析工具包了。

这次开放到底给了什么？

11 月 5 日 pricememo 曾报道过 DeepSeek 独立搜索接口开始收费，当时按千次调用 5 元人民币计费。这次更新的范围更广，官方把整个聊天客户端背后的全套支撑系统一次性端了出来。

整套开放能力划分成两类形态：

第一类是直接内置在 Messages、Responses、Chat Completions 这三个接口里的集成工具。开发者发请求时直接在参数里传布尔值开启。这些内置能力包含：

1. 联网搜索：由服务端去抓取最新互联网信息，并给回答附带原始引用出处。
2. 深度思考搜索：通过多步推理持续读取多个页面，用来处理复杂问题。
3. 文件输入：支持把 PDF、Office 系列办公文档以及图片直接扔给模型解析。
4. URL 读取：在消息里写下网址链接，服务端会自动去抓取页面内容。
5. 安全检查：服务端前置拦截不合规内容。
6. 自动生成标题：聊天完成后由服务端为本次会话生成摘要标题。

这些操作全部在 DeepSeek 自己的服务端集群运行。以往写 Agent 应用，大家以为只要大模型够聪明就行，实际上大部分工程时间都花在写 Python 脚本解析 PDF、配置无头浏览器绕过反爬机制、购买搜索引擎 API 配额上。现在这类脏活累活全被收束到了服务端。

第二类能力是五个独立单功能 API，方便不需要完整对话流的场景调用：

1. Search：独立的纯网络检索接口。
2. Fetch：输入单个网页网址，服务端直接下载并转换成排版整洁的 Markdown 格式。
3. OCR：单纯的图片与文档页面文字识别接口。
4. ASR：语音识别转文字。
5. TTS：文字转语音合成。

承载内置能力的模型代号为 deepseek-flash，底层实际运行的是 DeepSeek-V4.1-Flash-1017。值得注意的是，DeepSeek 聊天 App 里的 V4 Pro 模型虽然面向普通用户免费使用，但在 API 侧，据报道内置联网工具和文件输入并不支持 deepseek-v4-pro。

账单怎么算：官方定价与扣费规则

以前调用大模型只有 token 一张账单，现在要算两笔钱：基础 token 消耗费加上工具调用附加费。

工具调用的计费标准经过 DeepSeek 官方定价页面公布和多家报道交叉确认，基础资费如下：

仔细看这套价格规则，里面有几个直接关乎成本的细节：

工具只针对“成功请求”收钱。如果检索关键词没有返回任何结果，或者抓取链接由于目标服务器报错而失败，官方不会产生这笔工具扣费。

图片搜索存在渠道限制。独立 Search API 里暂时不提供图片检索能力，如果你的业务需要让模型参考图片搜索结果，必须通过 Chat Completions 里的内置联网工具来发起。

时间线上也有继承关系。10 月 17 日 DeepSeek 就先上线了独立的 Search 与 Fetch 接口；10 月 31 日 16:00 UTC 开始，在 DeepSeek Harness、Claude Code、Codex 这类代码工具里的服务端工具调用，已经全部按这个新标准同步计费。

代码怎么写：Chat Completions 调用示例

要把这套内置工具跑起来，调用方式依旧贴近标准 OpenAI 规范。开发者只要在请求体里指明 deepseek-flash 模型，并通过 tools 或内置字段告知服务端开启 web_search 即可。

先看一个容易写错的版本：

{
  "model": "deepseek-flash",
  "messages": [
    {
      "role": "user",
      "content": "帮我查一下今天科技领域有什么最新动态，并附上引用来源。"
    }
  ],
  "tools": [
    {
      "type": "builtin",
      "builtin": {
        "name": "web_search"
      }
    }
  ],
  "stream": false
}

当你把这段 payload 发送给 DeepSeek 服务端后，服务器会自动分析用户提问，如果判定需要最新信息，就会在后台直接调度搜索模块去查资料。不过先纠正一点：前面那段把工具包进 builtin 对象的写法是错的，照抄会调不通。

按照官方最新的规范，工具直接平铺在 tools 数组里声明，名字固定为 deepseek_web_search 和 deepseek_read_url。你不需要也无法通过 tool_choice 强行指定模型去调这两个工具，调用权力完全交给模型自己权衡。它觉得你的问题需要看最新动态，就会在后台自己调起检索；如果只是打个招呼或者问基础代码语法，它就直接回复，一分钱搜索费也不会多扣。

具体是走普通搜索还是深度推理，开关放在了 thinking 字段上。把 thinking 关掉，模型走的就是普通联网搜索，抓几个摘要就回答；把 thinking 设为 {"type": "enabled"}，模型就会切换到深度思考搜索模式。如果你只想让它帮着扒用户给的具体链接，不需要满网乱搜，把 deepseek_web_search 从列表里删掉、只留 deepseek_read_url 即可。

下面是经过核实的可运行脚本：

# 开启深度思考搜索与网页读取的调用示例
curl https://api.deepseek.com/anthropic/v1/messages \
  -H "Content-Type: application/json" \
  -H "x-api-key: ${DEEPSEEK_API_KEY}" \
  -d '{
    "model": "deepseek-flash",
    "thinking": {"type": "enabled"},
    "tools": [
      {"type": "deepseek_web_search", "name": "deepseek_web_search"},
      {"type": "deepseek_read_url", "name": "deepseek_read_url"}
    ],
    "messages": [{"role": "user", "content": "DeepSeek V4.1 有什么新变化？"}],
    "stream": true
  }'

上面这个调用走的是兼容接口。发完请求后，在流式返回的数据包里，你能清楚看到模型自己吐出来的调用参数与引用的网页标题。

两种搜索模式与工程调用限制

把搜索塞给大模型，很多人的第一反应就是去必应或者谷歌查几条摘要，再把那几段百来字的简介拼到提示词里。普通搜索模式干的差不多就是这件事，动作快，延迟低，搜一次拿回几个相关网页切片，组织语言就给答案。

深度思考搜索的运作逻辑完全变了。只要你把 thinking 跑起来，它会像一个坐在电脑前查资料的研究员。在单轮对话里，服务端最多允许它进行大概 20 次工具调用。这 20 次调用里，模型会自己拆解任务：先搜一个大词，发现结果不够精准，马上换关联词二次检索；看到靠谱的网页链接，它会主动通过后台工具把整页抓下来，通篇翻看里面的小标题；如果页面文字太长，它还会在网页内部继续搜特定字词，摘出真正有用的数据片段。整个多轮搜寻、翻页、对照验证的过程全在服务端一次性跑完，最后端出来的是带有完整佐证的综合报告。

用好这套工具，还得摸清它的物理边界。

针对 deepseek_read_url 读链接的功能，官方做了很严格的范围限定。它只认对话历史里“最后一条用户消息”里的 URL。如果用户在三轮对话之前发过一个链接，后面再追问“那个网页里说了什么”，模型并不会回过头重新去爬那条老消息，必须确保当前这一轮的 user 消息正文带着目标网址。同时，单次请求能解析的链接数量上限是 10 个，不同域名算不同链接，即便你在提问里一口气贴了 15 个参考网站，服务端也只挑前 10 个处理，多出来的会被直接丢弃。

如果你不用内置的聊天接口，走的是独立的 Search 和 Fetch 接口，那就要看账号级别的速率限制了。独立 Search 接口给的标准配额是每秒 100 次请求（100 QPS），拿来做常规站内检索聚合绰绰有余；Fetch 接口需要把目标网页拉回并转成规范的 Markdown 排版，服务端消耗资源多得多，限流直接压到了每秒 25 次请求（25 QPS）。这两个阈值全按主账号合并计算，如果你在同一个账号下挂了好几个并发业务，得在自己的网关层提前做好令牌桶限流，省得直接撞上 429 报错。

两笔账

很多人看到千次搜索 0.75 美元，第一反应是这价格真便宜，也有人担心把搜索和 OCR 接进生产环境会不会把钱包烧穿。我们不妨摆脱抽象的单价，带入两个常见的业务假设实际推演一下。

先看一个典型的联网问答助手场景。按这个假设：你的产品每天接待 100 次带有联网搜索的对话。每一次对话，模型都只触发 1 次网络搜索。单次交互里，用户输入加上之前带上来的上下文总共算 2000 个 token，模型最终整理生成的回复按 1000 个 token 来算。

在这个假设前提下，我们把调用全部按工作日的高峰期资费来算：

搜索费这块很简单，每天 100 次搜索，一个月按 30 天算就是 3000 次。千次单价 0.75 美元，月度搜索账单就是：

100 × 30 ÷ 1000 × 0.75 = 2.25 美元。

然后再算模型消耗的 token 费。

输入部分：每天 100 次 × 2000 token = 20 万 token。高峰期输入单价是每百万 token 收 0.30 美元，每天输入成本 200,000 × 0.30 ÷ 1,000,000 = 0.06 美元。

输出部分：每天 100 次 × 1000 token = 10 万 token。高峰期输出单价是每百万 token 收 1.20 美元，每天输出成本 100,000 × 1.20 ÷ 1,000,000 = 0.12 美元。

两者相加，每天的 token 支出是 0.18 美元。一个月 30 天跑下来，token 总费用是 5.40 美元。

把两笔钱拼在一块，在全天高峰期的假设下，这个月度搜索助手的总账单大约是 7.65 美元（2.25 美元搜索费加上 5.40 美元 token 费）。如果你的业务大部分访问发生在夜间或非高峰时段，官方给出了 token 费五折优惠，输入每百万 0.15 美元，输出每百万 0.60 美元，那么当月的 token 账单就会降到 2.70 美元，加上固定不变的 2.25 美元搜索费，整月开销大约只要 4.95 美元。

再看另一个常见的企业知识库处理场景，假设你有一份 200 页的行业研报 PDF 扫描件需要走独立的 OCR 接口。

按照千页 0.225 美元的定价计算：

200 ÷ 1000 × 0.225 = 0.045 美元。

整本 200 页厚书识别提取下来，官方只收 4.5 美分。

从上面这两笔账不难看出，搜索和抓取本身的价格其实低得惊人，千次调用几块钱在常规业务里几乎可以忽略不计，整个调用链路里真正的支出大头依然是模型吞吐的 token。

但账面上的这几美分还不是全部。很多技术团队以前为了给大模型配个像样的联网和读文件功能，得专门雇工程师写一堆爬虫服务，买一堆住宅代理 IP 防封禁，还得在服务器上挂一堆无头浏览器集群随时待命，遇到反爬机制天天通宵排错；解析 PDF 时又得在后台折腾各种复杂的开源 OCR 环境。现在 DeepSeek 把这些脏活累活全接了过去，按成功次数扣几美分，省下来的服务器开销和人力排错时间，才是小团队最划算的地方。

把 App 端成熟的信息检索与文件处理流水线以低廉单价对外输出，让开发者用标准接口就能甩掉爬虫和文档解析的基建包袱。

来源：

• https://ainewsway.com/news/deepseek-opens-its-app-tools-to-api-users
• https://techprolonged.com/2026/11/deepseek-opens-its-apps-search-file-reading-and-voice-as-apis/
• https://api-docs.deepseek.com/guides/search
• https://api-docs.deepseek.com/guides/web_tools
• https://aicost.tools/llm-cost/deepseek/