Tarifs et limites de l’API DeepSeek Search (guide 2026)

À 0,75 $ les 1 000 requêtes réussies, l’API DeepSeek Search est peu coûteuse. Mais son intérêt ne se résume pas à ce prix : Search comme Fetch sont plafonnés à 5 requêtes par seconde et par compte. C’est une option séduisante pour des agents économiques, à condition de maîtriser les fetchs en double, les tentatives de reprise, la couverture des sources et les tokens consommés par le modèle.

Quel point de départ selon votre besoin ?

Ce que propose réellement l’API brute

DeepSeek documente deux endpoints JSON en lecture seule. L’authentification est identique pour les deux : envoyez Authorization: Bearer <DeepSeek API Key> et Content-Type: application/json à api.deepseek.com.

L’API brute est distincte du produit de chat hébergé. Disposer d’une clé API DeepSeek ne permet pas à une requête Chat Completions classique de parcourir automatiquement le Web. Votre application doit appeler Search ou Fetch, ou passer par une intégration cliente documentée qui fournit la couche d’outils.

Search et Fetch : deux usages distincts

Search accepte un champ obligatoire query de 1 à 128 caractères Unicode. Parmi les champs facultatifs figurent count, de 1 à 50, ori_question, une valeur localization basée sur l’IP et need_content. La valeur par défaut de count est 10, tandis que need_content est défini sur false.

Avec need_content: true, Search peut inclure le texte de la page dans le champ content de chaque résultat. Lorsqu’il est présent, ce contenu peut éviter un appel Fetch séparé. Rien n’est toutefois garanti : les pages indisponibles ou bloquées peuvent toujours renvoyer un champ de contenu vide.

Fetch sert à récupérer une URL que vous avez déjà sélectionnée. Il renvoie du Markdown, à raison d’une URL par requête. DeepSeek précise que le fetch dépend de la disponibilité de la cible et de ses politiques d’accès : un résultat Search valide ne garantit donc pas que Fetch aboutira.

Les résultats Search exposent un rerank_score de 0 à 3 et un niveau d’authority de -1 à 4. La documentation présente les scores d’au moins 1,5 et les valeurs d’autorité d’au moins 3 comme des signaux de haute qualité. Il s’agit de métadonnées du service, non de benchmarks indépendants sur la qualité de recherche.

La syntaxe de requête prend en charge des filtres pratiques tels que site:, -site:, les expressions entre guillemets, lang:, after: et before:. Exemple :

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

Une tarification qui influence l’architecture

DeepSeek facture Search et Fetch 0,75 $ pour 1 000 requêtes réussies, soit 0,00075 $ par requête facturable. La facturation est calculée par requête, et non par token ni selon le nombre de résultats retournés. Consultez la page tarifaire officielle.

Le coût de l’endpoint ne couvre pas à lui seul une tâche de recherche IA : les tokens d’entrée et de sortie du modèle, ainsi que les tours d’agent supplémentaires autour de la récupération, sont facturés séparément.

Une formule de coût réaliste

Pour un workflow simple, la part récupération s’écrit ainsi :

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

Un lot de 10 000 recherches coûte 7,50 $ si chaque requête Search produit des résultats. Si l’application récupère une page pour chaque résultat, 10 000 appels Fetch réussis supplémentaires ajoutent 7,50 $, hors tokens du modèle. Demander 50 résultats à Search ne multiplie pas le coût de la requête, mais peut accroître le volume de texte à traiter par votre modèle.

C’est pourquoi need_content mérite une politique explicite. Utilisez-le pour de petits ensembles de pages ; préférez une recherche limitée aux métadonnées suivie de Fetch sélectifs lorsque vous devez d’abord filtrer par score, domaine, date ou autorité.

@haolv511482 indique : « Check the content field before adding a fetch loop. Search can return page text with need_content=true ... Otherwise your agent may pay to read the same page twice. » Source

Limites et échecs à prévoir dès la conception

Le guide officiel fixe un maximum de 50 résultats par requête Search, ainsi que des quotas distincts de 5 requêtes par seconde et par compte pour Search et Fetch. Un déploiement avec plusieurs workers a donc toujours besoin de limiteurs propres à chaque endpoint.

Fetch est particulièrement sensible au comportement des sites. La documentation officielle limite sa garantie à la disponibilité du site cible et à ses politiques d’accès ; elle ne promet ni exécution JavaScript, ni session de navigateur, ni sélection de user-agent, ni captures d’écran, ni conservation du HTML brut. Lors d’un test précoce, @jiangkoumo_ a signalé que des sites fortement rendus en JavaScript pouvaient renvoyer 404, alors qu’une page publique classique était convertie en Markdown. Source

Ces premiers essais ont également mis en lumière un compromis important sur la couverture. @bei351009016 a rapporté seulement 2,1 % de chevauchement avec Exa sur 29 requêtes et 12 plateformes, décrivant DeepSeek comme rapide et récent pour les sources chinoises, mais faible sur WeChat et YouTube. Source

Considérez ce test précoce comme un indicateur, puis validez les types de sources dont vous avez besoin.

Un schéma d’implémentation minimal

Cet exemple sépare la récupération de la génération de réponse, évite un appel Fetch lorsque Search a déjà renvoyé le contenu et espace les appels à 5 par seconde pour ce processus. Un déploiement multi-worker nécessite néanmoins un limiteur partagé unique.

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))

Quand DeepSeek ne doit pas être votre unique fournisseur

DeepSeek est un choix solide pour la découverte à bas coût, particulièrement si votre corpus inclut des sources chinoises et que votre application peut s’accommoder d’une limite de 5 QPS par compte. Il est moins adapté comme fournisseur unique lorsque votre charge de travail dépend de YouTube, WeChat, de pages fortement rendues côté client ou du classement d’un moteur de recherche particulier.

Une architecture hybride est plus défendable :

1. Envoyez les requêtes de découverte larges et peu coûteuses à DeepSeek.
2. Filtrez par domaine, date, autorité et score de reranking.
3. Utilisez un second fournisseur pour les catégories de sources que DeepSeek ne couvre pas.
4. Ne récupérez que les URL sélectionnées.
5. Vérifiez l’appui documentaire des réponses à partir des textes sources stockés.

La gestion des données est un autre choix de déploiement. Consultez les conditions actuelles de DeepSeek et vos obligations de conformité avant d’envoyer des requêtes sensibles ; les préoccupations de la communauté ne prouvent pas l’existence d’une politique de conservation précise. Source

Checklist opérationnelle avant la production

1. Journalisez séparément les appels Search et Fetch afin de pouvoir rapprocher la facture.
2. Vérifiez content avant de récupérer une URL renvoyée par Search.
3. Imposez un limiteur partagé à 5 QPS sur tous les workers et sous-agents.
4. Ne réessayez que les réponses 408, 429 et les erreurs 5xx transitoires.
5. Stockez l’URL, le titre, la date, l’autorité, le score de reranking et l’heure de récupération.
6. Rejetez les schémas non pris en charge et les URL de réseaux privés dans tout chemin Fetch contrôlé par l’utilisateur.
7. Traitez le texte des pages comme des données non fiables, et non comme des instructions pour vos outils.
8. Exécutez un jeu de tests incluant des pages officielles en anglais, des sources chinoises, des forums, des pages vidéo et des sites riches en JavaScript.
9. Mesurez le coût total de la tâche, tokens du modèle et tentatives de reprise inclus, plutôt que d’indiquer uniquement le prix de Search.

FAQ : DeepSeek Search API

L’API est-elle automatiquement disponible via des appels compatibles OpenAI ?

L’endpoint Search brut est une route distincte : POST /v1/tools/search. Une requête de modèle classique ne navigue pas sur le Web simplement parce que le client emploie une URL de base compatible OpenAI. Ajoutez vous-même les appels Search/Fetch ou utilisez une intégration cliente documentée par DeepSeek.

DeepSeek Search est-il le meilleur remplacement pour tous les fournisseurs de recherche ?

Non. C’est une option de récupération convaincante et peu coûteuse, mais les premiers tests utilisateurs ont relevé une couverture différente d’Exa ainsi que des lacunes autour de YouTube et WeChat. Testez un petit échantillon représentatif de votre charge de travail avant d’en faire votre fournisseur unique.