Цены и лимиты DeepSeek Search API: гид на 2026 год

У DeepSeek Search API очень привлекательная цена — $0.75 за 1 000 успешных запросов. Но при выборе сервиса важнее не только тариф: и для Search, и для Fetch действует отдельный лимит в 5 запросов в секунду на аккаунт. Для недорогих агентных систем это хороший вариант, если заранее продумать защиту от повторных Fetch-запросов, ретраи, охват источников и расход токенов модели.

Какой вариант выбрать: кратко

Что доступно в нативном API

DeepSeek документирует два JSON-endpoint'а только для чтения. Аутентификация у них одинаковая: передавайте Authorization: Bearer <DeepSeek API Key> и Content-Type: application/json при обращении к api.deepseek.com.

Нативный API существует отдельно от размещённого чат-продукта. Наличие ключа DeepSeek API не означает, что обычный запрос Chat Completions автоматически получит доступ к веб-поиску. Приложение должно самостоятельно вызывать Search или Fetch либо использовать документированную интеграцию клиента, которая добавляет слой инструментов.

Чем отличаются Search и Fetch

Search принимает обязательный параметр query длиной от 1 до 128 символов Unicode. Среди необязательных полей — count от 1 до 50, ori_question, значение localization на основе IP и need_content. По умолчанию count равен 10, а need_content отключён.

Если указать need_content: true, Search может вернуть текст страницы в поле content каждого результата. Когда контент доступен, отдельный вызов Fetch не понадобится. Однако это не гарантируется: для недоступных или заблокированных страниц поле content может остаться пустым.

Fetch нужен для URL, который вы уже отобрали. Он возвращает Markdown, но в одном запросе передаётся только один URL. DeepSeek предупреждает, что получение страницы зависит от её доступности и правил доступа на целевом сайте. Поэтому успешный результат Search ещё не гарантирует успешный Fetch.

В результатах Search есть rerank_score от 0 до 3 и уровень authority от -1 до 4. В документации значения score от 1.5 и authority от 3 названы сигналами высокого качества. Это служебные метаданные сервиса, а не независимые бенчмарки качества поиска.

Синтаксис запросов поддерживает полезные фильтры: site:, -site:, фразы в кавычках, lang:, after: и before:. Например:

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

Цена, которая влияет на архитектуру

DeepSeek указывает для Search и Fetch единую цену: $0.75 за 1 000 успешных запросов, то есть $0.00075 за оплачиваемый запрос. Тарификация идёт по числу запросов, а не по токенам и не по количеству результатов в выдаче. Подробнее — на официальной странице с ценами.

Стоимость endpoint'ов — не вся цена задачи с ИИ-исследованием: отдельно оплачиваются входные и выходные токены модели, а также дополнительные шаги агента вокруг поиска и извлечения данных.

Практичная формула расчёта

Для простого сценария расходы на поиск и получение контента считаются так:

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

Пакет из 10 000 поисковых запросов обойдётся в $7.50, если каждый запрос Search вернёт результаты. Если затем приложение получает по одной странице на каждый результат, ещё 10 000 успешных вызовов Fetch добавят $7.50 — без учёта токенов модели. Запрос 50 результатов через Search не увеличивает цену самого запроса, но может заметно нарастить объём текста, который должна обработать модель.

Поэтому для need_content стоит задать явную политику. Используйте его для небольших наборов страниц; если нужно сначала отфильтровать результаты по оценке, домену, дате или авторитетности, выбирайте Search только с метаданными, а затем точечный Fetch.

@haolv511482 советует: «Проверяйте поле content перед запуском цикла fetch. Search может вернуть текст страницы при need_content=true ... Иначе агент может дважды заплатить за чтение одной и той же страницы». Источник

Лимиты и сбои, которые нужно учесть в архитектуре

В официальном руководстве указан максимум в 50 результатов на один запрос Search, а также отдельные лимиты в 5 запросов в секунду на аккаунт для Search и Fetch. Даже при развёртывании с несколькими воркерами нужны отдельные лимитеры для каждого endpoint'а.

Fetch особенно чувствителен к поведению сайтов. Официальная документация ограничивает гарантии доступностью целевого сайта и его политиками доступа; она не обещает выполнение JavaScript, браузерную сессию, выбор User-Agent, скриншоты или сохранение исходного HTML. В раннем тесте @jiangkoumo_ сообщил, что сайты с интенсивным JavaScript-рендерингом могли возвращать 404, тогда как обычная публичная страница успешно преобразовывалась в Markdown. Источник

Те же ранние тесты выявили важный компромисс в охвате. @bei351009016 сообщил лишь о 2.1% пересечении с Exa в 29 запросах по 12 платформам: DeepSeek был быстрым и актуальным для китайских источников, но слабее справлялся с WeChat и YouTube. Источник

Считайте этот ранний тест ориентиром, а не окончательным выводом, и проверяйте те типы источников, которые важны именно вам.

Минимальный шаблон интеграции

Этот пример разделяет поиск контента и генерацию ответа, не вызывает Fetch, если Search уже вернул текст, и выдерживает для данного процесса частоту в 5 запросов в секунду. При нескольких воркерах всё равно необходим единый общий лимитер.

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, WeChat, страницы с тяжёлым клиентским рендерингом или ранжирование конкретной поисковой системы.

Более надёжна гибридная схема:

1. Отправляйте широкие и недорогие поисковые запросы в DeepSeek.
2. Фильтруйте результаты по домену, дате, authority и rerank score.
3. Подключайте второго провайдера для классов источников, которые DeepSeek пропускает.
4. Получайте через Fetch только отобранные URL.
5. Сопоставляйте поддержку ответа с сохранённым текстом источников.

Отдельного решения требует и обработка данных. Перед отправкой чувствительных запросов изучите актуальные условия DeepSeek и собственные требования к соответствию нормам; опасения сообщества сами по себе не доказывают конкретную политику хранения данных. Источник

Чек-лист перед выходом в production

1. Логируйте вызовы Search и Fetch раздельно, чтобы можно было сверять счета.
2. Проверяйте content, прежде чем запрашивать Fetch для URL из Search.
3. Применяйте общий лимитер в 5 QPS ко всем воркерам и субагентам.
4. Повторяйте только запросы с ответами 408, 429 и временными ошибками 5xx.
5. Сохраняйте URL, заголовок, дату, authority, rerank score и время получения данных.
6. В любом пользовательском пути Fetch отклоняйте неподдерживаемые схемы и URL из частных сетей.
7. Считайте текст страницы недоверенными данными, а не инструкциями для инструментов.
8. Соберите тестовый набор из официальных англоязычных страниц, китайских источников, форумов, видеостраниц и сайтов с интенсивным JavaScript.
9. Измеряйте полную стоимость задачи, включая токены модели и ретраи, а не только цену Search.

FAQ по DeepSeek Search API

Доступен ли API автоматически через OpenAI-совместимые вызовы?

Нативный endpoint Search — это отдельный маршрут POST /v1/tools/search. Обычный запрос к модели не получает веб-поиск лишь потому, что клиент использует OpenAI-совместимый base URL. Добавьте вызовы Search/Fetch самостоятельно или используйте документированную DeepSeek интеграцию клиента.

Может ли DeepSeek Search заменить любой поисковый сервис?

Нет. Это привлекательный вариант для недорогого извлечения данных, однако ранние пользовательские тесты показали отличия в покрытии относительно Exa и пробелы вокруг YouTube и WeChat. Прежде чем делать DeepSeek единственным провайдером, проведите небольшой тест на своей рабочей нагрузке.