DeepSeek Search API 定价与限制（2026 指南）

DeepSeek Search API 每 1,000 次成功请求收费 $0.75，价格确实很低，但真正决定它是否适合你的并不只是单价。Search 和 Fetch 两个接口的账户配额均为每秒 5 次请求。对于追求低成本的 Agent 来说，它很有吸引力；前提是你得管住重复 Fetch、重试策略、信源覆盖范围，以及模型 Token 的消耗。

先看结论：不同需求该怎么选

原始 API 提供了什么能力

DeepSeek 文档定义了两个只读 JSON 接口，认证方式完全一致：向 api.deepseek.com 发送请求时，带上 Authorization: Bearer <DeepSeek API Key> 和 Content-Type: application/json。

这套原始 API 与托管式聊天产品是分开的。有 DeepSeek API Key，并不代表普通的 Chat Completions 请求会自动联网浏览。你的应用必须自行调用 Search 或 Fetch，或者使用 DeepSeek 已文档化、并提供工具层的客户端集成方案。

Search 和 Fetch 怎么分工

Search 的必填参数是 query，长度为 1 到 128 个 Unicode 字符。可选字段包括取值为 1 到 50 的 count、ori_question、基于 IP 的 localization 值，以及 need_content。其中 count 默认是 10，need_content 默认是 false。

启用 need_content: true 后，Search 可能会在每条结果的 content 字段中直接返回页面正文。对于已经带回内容的页面，这可以省掉后续单独调用 Fetch 的步骤。不过这不是保证：页面不可访问或被拦截时，content 仍可能为空。

Fetch 用于读取你已经选定的 URL。它会返回 Markdown，但每次请求只能提交一个 URL。DeepSeek 说明，Fetch 是否成功取决于目标网站的可用性和访问策略，因此 Search 能搜到某个结果，并不意味着 Fetch 一定能成功读取。

Search 结果会包含 0 到 3 的 rerank_score，以及 -1 到 4 的 authority 等级。文档将不低于 1.5 的分数和不低于 3 的权威度视为高质量信号。它们属于服务提供的元数据，并不是独立的搜索质量评测指标。

查询语法支持不少实用过滤条件，包括 site:、-site:、精确短语、lang:、after: 和 before:。例如：

"DeepSeek Search API" site:api-docs.deepseek.com lang:en after:2026-10-01

这个定价会怎样影响系统设计

DeepSeek 对 Search 和 Fetch 的标价都是每 1,000 次成功请求 $0.75，即每次可计费请求 $0.00075。计费按请求次数计算，不按 Token，也不取决于返回了多少条结果。具体可查看官方定价页面。

接口费用并不是一次 AI 研究任务的全部成本：模型输入/输出 Token，以及围绕检索增加的 Agent 轮次，都需要单独计费。

更接近实际的成本计算方式

对于一个简单工作流，检索部分的成本可以写成：

successful Search calls * $0.00075
+ successful Fetch calls * $0.00075
+ model input and output token charges

如果 10,000 次 Search 请求全部返回结果，成本就是 $7.50。假如应用再为每个结果各 Fetch 一个页面，额外 10,000 次成功 Fetch 又会增加 $7.50，模型 Token 费用另算。让 Search 返回 50 条结果不会让单次请求费用翻倍，但会提高模型需要处理的文本量。

因此，need_content 应当有明确的使用策略。需要处理少量页面时可以启用它；如果你想先按分数、域名、日期或权威度筛选，则更适合先做仅返回元数据的 Search，再有选择地调用 Fetch。

@haolv511482 提醒：“在加入 fetch 循环前，先检查 content 字段。启用 need_content=true 后，Search 可以直接返回页面文本……否则你的 Agent 可能会为读取同一页面付两次钱。” 来源

生产环境要重点防范的限制与失败场景

官方指南规定，单次 Search 最多返回 50 条结果；同一账户下，Search 和 Fetch 分别拥有每秒 5 次请求的独立配额。即使部署了多个 Worker，也仍然需要针对不同端点设置限流器。

Fetch 对网站自身行为尤其敏感。官方文档仅保证服务会受到目标站点可用性和访问策略的约束，并未承诺支持 JavaScript 执行、浏览器会话、User-Agent 选择、截图或保留原始 HTML。早期测试中，@jiangkoumo_ 发现重度依赖 JavaScript 渲染的网站可能返回 404，而普通公开页面则可以正常转换为 Markdown。来源

同一批早期测试还揭示了一个重要的覆盖范围取舍。@bei351009016 报告称，在 29 个查询和 12 个平台中，DeepSeek 与 Exa 的结果重合率仅为 2.1%；其评价是 DeepSeek 对中文信源速度快、内容新，但对微信和 YouTube 的覆盖较弱。来源

这些早期测试只能作为方向性参考，真正部署前仍应针对你需要的信源类型自行验证。

一个够用的最小实现模式

下面的示例将检索与答案生成分开处理；当 Search 已经返回正文时，不再额外调用 Fetch；同时在当前进程内将调用间隔控制为每秒 5 次。若有多个 Worker，仍然需要一个全局共享的限流器。

import os
import threading
import time
import requests

BASE = "https://api.deepseek.com"
HEADERS = {
    "Authorization": f"Bearer {os.environ['DEEPSEEK_API_KEY']}",
    "Content-Type": "application/json",
}
RATE_LOCK = threading.Lock()
LAST_CALL = 0.0


def post_json(path, payload, attempts=3):
    global LAST_CALL
    for attempt in range(attempts):
        with RATE_LOCK:
            wait = 0.2 - (time.monotonic() - LAST_CALL)
            if wait > 0:
                time.sleep(wait)
            LAST_CALL = time.monotonic()
        response = requests.post(
            BASE + path, headers=HEADERS, json=payload, timeout=30
        )
        if response.status_code in {408, 429, 500, 502, 503, 504}:
            if attempt == attempts - 1:
                response.raise_for_status()
            time.sleep(2 ** attempt)
            continue
        response.raise_for_status()
        return response.json()


search = post_json(
    "/v1/tools/search",
    {
        "query": 'DeepSeek Search API pricing site:api-docs.deepseek.com',
        "count": 10,
        "need_content": True,
    },
)

usable = [
    result for result in search.get("results", [])
    if result.get("rerank_score", 0) >= 1.5
]

for result in usable:
    content = result.get("content") or ""
    if not content:
        fetched = post_json("/v1/tools/fetch", {"url": result["url"]})
        content = fetched.get("content", "")
    # Store title, URL, date, authority, score, and content before summarizing.
    print(result["title"], result["url"], len(content))

哪些情况下不该只用 DeepSeek

如果你追求低成本的信息发现，尤其语料中包含中文信源，并且应用可以接受每个账户 5 QPS 的限制，DeepSeek 是一个很强的选择。但如果工作负载依赖 YouTube、微信、重度客户端渲染页面，或特定搜索引擎的排序结果，那么它并不适合作为唯一服务商。

更稳妥的做法是采用混合架构：

1. 先将范围广、成本敏感的发现型查询发给 DeepSeek。
2. 按域名、日期、权威度和 rerank 分数筛选。
3. 对于 DeepSeek 容易遗漏的信源类别，调用第二家服务商。
4. 只 Fetch 经过筛选的 URL。
5. 将答案与已存储的源文本进行交叉核对。

数据处理也是部署时必须做出的决策。向服务发送敏感查询前，应审阅 DeepSeek 当前的条款以及你的合规要求；社区层面的担忧并不能证明存在某种具体的数据保留政策。来源

上线前的运维检查清单

1. 分别记录 Search 和 Fetch 调用，方便对账。
2. Fetch Search 返回的 URL 前，先检查 content。
3. 在所有 Worker 和子 Agent 间执行共享的 5 QPS 限流。
4. 只对 408、429 和临时性 5xx 响应进行重试。
5. 保存 URL、标题、日期、权威度、rerank 分数和检索时间。
6. 在任何由用户控制的 Fetch 路径中，拒绝不受支持的协议和私有网络 URL。
7. 将页面文本视为不可信数据，而不是工具指令。
8. 准备包含英文官方页面、中文信源、论坛、视频页面和重度 JavaScript 网站的测试集。
9. 衡量包含模型 Token 和重试在内的总任务成本，而不是只报告 Search 的价格。

DeepSeek Search API 常见问题

通过 OpenAI 兼容调用会自动获得 API 搜索能力吗？

不会。原始 Search 接口是独立的 POST /v1/tools/search 路由。即使客户端使用了 OpenAI 兼容的 base URL，普通模型请求也不会自动联网。你需要自行接入 Search/Fetch 调用，或使用 DeepSeek 已文档化的客户端集成方案。

DeepSeek Search 能替代所有搜索服务商吗？

不能。它是很有竞争力的低成本检索方案，但早期用户测试发现它与 Exa 的覆盖范围不同，并且在 YouTube 和微信方面存在缺口。在将它作为唯一服务商之前，先用贴近自身业务的少量工作负载进行测试。