DeepSeek Search API 定價與限制（2026 指南）

端點費用並不是 AI 研究任務的完整成本。模型輸入／輸出 Token，以及檢索前後額外的 Agent 回合，仍會另外計費。

比較貼近實務的成本公式

以簡單工作流程來看，檢索成本可寫成：

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

若每次 Search 都有結果，進行 10,000 次搜尋的費用是 $7.50。若應用程式再為每個結果各 Fetch 一個頁面，額外 10,000 次成功 Fetch 會再增加 $7.50，尚未計入模型 Token。要求 Search 回傳 50 筆結果不會讓單次請求費用倍增，但可能提高模型需要處理的文字量。

這也是為什麼 need_content 應該有明確策略。頁面集合較小時可直接啟用；如果你想先依分數、網域、日期或權威度篩選，則適合先做純中繼資料的 Search，再針對選中的結果 Fetch。

@haolv511482 表示：「在加入 fetch 迴圈前，先檢查 content 欄位。Search 可以透過 need_content=true 回傳頁面文字……否則你的 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？

DeepSeek 很適合低成本的來源探索，特別是你的資料語料涵蓋中文來源，而且應用可以接受每帳號 5 QPS 的限制時。但若工作負載高度依賴 YouTube、微信、重度客戶端渲染頁面，或特定搜尋引擎的排序結果，它就不是理想的單一供應商選擇。

更穩妥的是採用混合式架構：

1. 先將廣泛且成本敏感的探索查詢送到 DeepSeek。
2. 依網域、日期、權威度與 rerank score 篩選。
3. 針對 DeepSeek 容易漏掉的來源類別，使用第二家供應商。
4. 只 Fetch 篩選後的 URL。
5. 將答案依據與已儲存的來源文字比對。

資料處理也是部署時必須評估的面向。在送出敏感查詢前，請先檢閱 DeepSeek 現行條款與自身的合規要求；社群疑慮並不能證明某種特定的資料保留政策。來源

上線前的營運檢查清單

1. 分開記錄 Search 與 Fetch 呼叫，才能核對帳單。
2. 在 Fetch Search 回傳的 URL 前，先檢查 content。
3. 為所有 worker 與 subagent 設置共享的 5 QPS 限流器。
4. 只重試 408、429 與暫時性的 5xx 回應。
5. 儲存 URL、標題、日期、權威度、rerank score 與擷取時間。
6. 在任何由使用者控制的 Fetch 路徑中，拒絕不支援的 scheme 與私有網路 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 與微信方面存在缺口。在將它作為唯一供應商前，請先以符合自身工作負載的小型測試集驗證。