Limites de requêtes de l’API DeepSeek : fonctionnement et gestion des erreurs 429

Réponse directe — informations vérifiées le 10 juillet 2026. DeepSeek publie actuellement des limites de requêtes simultanées, et non un quota universel chiffré en requêtes par minute. Le plafond standard annoncé est de 500 connexions concurrentes pour deepseek-v4-pro et de 2 500 pour deepseek-v4-flash. Il s’applique au niveau du compte, toutes les clés API de ce compte étant regroupées. Une requête occupe un emplacement depuis son envoi jusqu’à la fin de la réponse ; dépasser le plafond entraîne une erreur HTTP 429.

Note importante : les limites, les modèles disponibles et les prix de l’API peuvent évoluer. Avant tout déploiement en production, vérifiez toujours la documentation officielle DeepSeek et la configuration réelle de votre compte.

Limites officielles de l’API DeepSeek

Modèle	Limite de concurrence publiée	Portée	Durée de comptabilisation	En cas de dépassement
deepseek-v4-pro	500 requêtes simultanées	Compte DeepSeek	De l’envoi de la requête à la fin de la réponse	HTTP 429
deepseek-v4-flash	2 500 requêtes simultanées	Compte DeepSeek	De l’envoi de la requête à la fin de la réponse	HTTP 429

Ces valeurs correspondent aux limites publiques standard au 10 juillet 2026. Un compte ayant obtenu une augmentation de capacité peut disposer d’un plafond total différent. DeepSeek indique que cette augmentation est attribuée selon les besoins réels de l’entreprise et qu’elle n’entraîne pas de frais supplémentaires spécifiques ; la consommation de l’API reste néanmoins facturée selon les tokens utilisés.

Plusieurs clés API n’augmentent pas le plafond

Les limites sont calculées au niveau du compte, indépendamment de la clé utilisée. Créer ou faire tourner plusieurs clés API rattachées au même compte ne multiplie donc pas la capacité disponible.

Cette règle a une conséquence importante pour les architectures distribuées : deux microservices utilisant des clés différentes peuvent se concurrencer sans le savoir s’ils appartiennent au même compte. La régulation doit alors être globale, et non limitée à chaque clé ou à chaque instance applicative.

Les anciens noms de modèles doivent être remplacés

Les alias deepseek-chat et deepseek-reasoner sont encore utilisables à la date de vérification de cet article, mais leur retrait est prévu le 24 juillet 2026 à 15 h 59 UTC :

• deepseek-chat correspond actuellement au mode sans raisonnement de deepseek-v4-flash ;
• deepseek-reasoner correspond actuellement au mode raisonnement de deepseek-v4-flash.

Une intégration destinée à rester en production doit utiliser dès maintenant deepseek-v4-flash ou deepseek-v4-pro.

Concurrence, RPM, TPM et contexte : quatre limites différentes

La principale source de confusion vient du terme rate limit, souvent traduit par « limite de débit ». Selon le fournisseur, il peut désigner plusieurs mécanismes distincts.

Type de limite	Ce qu’elle mesure	Exemple
Concurrence	Nombre de requêtes encore en cours au même instant	100 appels dont la réponse n’est pas terminée
RPM	Requêtes démarrées pendant une minute	600 requêtes par minute
TPM	Tokens envoyés ou générés pendant une minute	2 millions de tokens par minute
Fenêtre de contexte	Quantité maximale de tokens dans un appel	Prompt, historique et sortie d’une requête

DeepSeek publie des valeurs numériques pour la concurrence. Sa page chinoise consacrée aux codes d’erreur indique par ailleurs qu’une erreur 429 peut correspondre à un plafond de RPM ou de TPM, mais elle ne donne pas de seuil numérique public. La version anglaise se contente d’indiquer que les requêtes sont envoyées trop rapidement. Il serait donc incorrect d’inventer un quota tel que « 20 requêtes par seconde » ou de présenter une estimation comme une limite officielle.

Peut-on convertir une limite de concurrence en RPM ?

Il n’existe pas de conversion fixe. Le débit dépend du temps pendant lequel chaque requête reste active.

Une approximation utile en régime stable est :

Débit estimé en requêtes/minute
≈ concurrence réellement utilisée × 60 ÷ durée moyenne d’une requête en secondes

Avec 40 appels simultanés :

• une durée moyenne de 12 secondes donne environ 200 requêtes par minute ;
• une durée moyenne de 60 secondes donne environ 40 requêtes par minute.

Il s’agit d’une estimation de capacité, pas d’un quota DeepSeek. En production, il est préférable d’utiliser la latence au 95e ou au 99e percentile et de conserver une marge, car les réponses longues, le raisonnement, les appels d’outils et les ralentissements temporaires augmentent la durée d’occupation.

La fenêtre de contexte n’est pas une limite de débit

Les modèles V4 disposent actuellement d’une fenêtre de contexte annoncée à un million de tokens et d’une sortie maximale pouvant atteindre 384 000 tokens. Ces valeurs décrivent la taille possible d’une requête, pas le nombre d’appels autorisés.

Une requête très longue peut néanmoins affecter indirectement le débit : plus sa génération dure, plus elle conserve son emplacement de concurrence.

Le streaming ne libère pas plus tôt l’emplacement

Le streaming améliore le temps perçu avant l’apparition des premiers tokens, mais la requête reste comptabilisée jusqu’à la fin complète de la réponse. Il ne permet donc pas, à lui seul, d’éviter une erreur 429.

DeepSeek documente un mécanisme de keep-alive pendant l’attente de planification :

• pour une requête non streamée, le serveur peut envoyer des lignes vides ;
• pour une requête streamée, il peut envoyer des commentaires SSE : keep-alive ;
• si l’inférence n’a pas commencé après dix minutes, le serveur ferme la connexion.

Un parseur HTTP personnalisé doit ignorer correctement ces lignes ou commentaires. Il ne faut pas les interpréter comme une réponse vide, un JSON invalide ou la fin prématurée du flux.

Pourquoi l’API DeepSeek renvoie-t-elle une erreur 429 ?

Une réponse 429 Rate Limit Reached signifie que l’appel est refusé par un mécanisme de limitation. Le dépassement de la concurrence publiée constitue une cause officiellement documentée, mais l’analyse doit porter sur l’ensemble du trafic associé au compte.

Les causes les plus fréquentes sont les suivantes.

Trop de requêtes actives sur le même compte

Le compteur ne se limite pas au processus qui observe l’erreur. Il peut inclure les appels provenant :

• d’autres instances de la même application ;
• d’un environnement de préproduction utilisant le compte de production ;
• de tâches planifiées ou de traitements par lots ;
• de plusieurs produits partageant les mêmes identifiants ;
• de clés API différentes rattachées au même compte.

Un sémaphore local dans chaque conteneur ne suffit pas lorsque dix conteneurs démarrent chacun 100 requêtes.

Une rafale de trafic sans file d’attente

Même si le débit moyen semble faible, un pic bref peut remplir tous les emplacements disponibles. C’est fréquent après :

• le redémarrage simultané de plusieurs workers ;
• la reprise d’une file de tâches ;
• l’arrivée d’une campagne ou d’une notification ;
• l’exécution d’un traitement massif ;
• la reconnexion de nombreux clients.

La solution consiste à lisser les admissions avant l’envoi à DeepSeek, pas seulement à ralentir après les premiers 429.

Des requêtes qui restent actives trop longtemps

La concurrence augmente lorsque la durée des appels augmente. Parmi les facteurs possibles :

• réponses très longues ;
• prompts ou historiques volumineux ;
• mode raisonnement utilisé pour des tâches simples ;
• workflows comportant plusieurs appels d’outils ;
• latence élevée du service ;
• attente avant le début de l’inférence ;
• consommateurs trop lents sur un flux streamé.

Le mode raisonnement des modèles V4 est actuellement activé par défaut. Le désactiver pour des tâches simples peut réduire la durée et le coût, mais seulement après avoir vérifié que la qualité reste suffisante. Définir un max_tokens raisonnable évite également des générations inutilement longues.

Une tempête de nouvelles tentatives

Une boucle qui relance immédiatement chaque appel refusé transforme un incident limité en surcharge durable :

1. les premières requêtes reçoivent un 429 ;
2. tous les workers réessaient au même moment ;
3. la nouvelle vague est plus importante que la précédente ;
4. le plafond reste saturé.

Un backoff exponentiel sans jitter peut produire un problème similaire, car tous les clients se réveillent après le même délai.

Un workflow agentique qui multiplie les appels

Une seule demande utilisateur peut déclencher plusieurs requêtes : planification, recherche, appels d’outils, validation, synthèse et nouvelles tentatives. Il faut mesurer les appels réels à l’API, pas seulement les requêtes reçues par l’application.

Une page recevant 50 utilisateurs simultanés peut ainsi générer plusieurs centaines d’appels en vol si chaque interaction lance un agent parallèle.

Le 429 provient d’un intermédiaire

Lorsque DeepSeek est utilisé via OpenRouter, une passerelle LLM, un proxy d’entreprise ou une plateforme d’automatisation, l’erreur peut être émise par cet intermédiaire.

Vérifiez en priorité :

• l’URL de base réellement appelée ;
• l’hôte figurant dans les traces réseau ;
• le corps de l’erreur ;
• les en-têtes de réponse ;
• le tableau de bord du fournisseur ;
• la clé utilisée par l’application.

L’endpoint officiel au format OpenAI est https://api.deepseek.com. Un appel dirigé vers un autre domaine obéit potentiellement à des quotas différents.

Différence entre 429, 500, 503 et un timeout

Signal	Signification documentée ou probable	Réaction adaptée
429 Rate Limit Reached	Requêtes envoyées trop rapidement ou plafond de capacité atteint	Réduire les admissions, mettre en file, appliquer un retry limité avec jitter
500 Server Error	Erreur interne côté DeepSeek	Réessayer brièvement, puis arrêter et transmettre les éléments de diagnostic si elle persiste
503 Server Overloaded	Surcharge générale du service	Temporiser, vérifier le statut officiel, activer éventuellement un circuit breaker ou un fallback
Timeout ou erreur réseau	Réponse perdue, connexion interrompue, proxy ou délai client dépassé	Réessayer avec prudence et un budget limité
400, 401, 402 ou 422	Format, authentification, solde ou paramètres incorrects	Corriger la requête ; ne pas répéter à l’identique

DeepSeek distingue explicitement le 429 du 503 : le premier correspond à une limitation du rythme d’envoi, tandis que le second signale une surcharge du serveur. Les traiter avec une même boucle de retries immédiats masque le diagnostic et augmente la pression.

Un timeout est plus ambigu : le serveur peut avoir commencé ou terminé le travail sans que le client ait reçu la réponse. Une nouvelle tentative peut alors dupliquer la génération et la consommation facturée. La documentation publique consultée ne décrit pas de clé d’idempotence pour les chat completions ; les retries sur timeout doivent donc être plafonnés et associés à une déduplication applicative lorsque le résultat déclenche d’autres actions.

Diagnostiquer une erreur 429 étape par étape

1. Identifier le fournisseur réel

Commencez par enregistrer le domaine cible et le nom du modèle. Une configuration compatible OpenAI peut facilement masquer le fournisseur derrière un SDK, un proxy ou une variable d’environnement.

L’objectif est de savoir si le 429 vient :

• de l’API officielle DeepSeek ;
• d’un fournisseur tiers ;
• d’une passerelle interne ;
• d’un reverse proxy ;
• de votre propre couche de limitation.

2. Mesurer les requêtes en vol à l’échelle du compte

Le compteur pertinent est le nombre total de requêtes envoyées mais pas encore terminées pour le compte. Ne vous limitez pas :

• au nombre de threads ;
• au nombre de requêtes de l’instance courante ;
• au débit moyen par minute ;
• aux statistiques d’une seule clé.

Ajoutez un identifiant de corrélation local et suivez chaque transition :

en attente dans la file
→ admission autorisée
→ requête envoyée
→ première donnée reçue
→ réponse terminée
→ emplacement libéré

3. Ventiler les métriques par modèle et par service

Les limites publiées diffèrent entre deepseek-v4-pro et deepseek-v4-flash. Les tableaux de bord doivent donc afficher au minimum :

• modèle appelé ;
• service ou worker à l’origine de l’appel ;
• nombre de requêtes en cours ;
• durée de l’appel ;
• statut HTTP ;
• numéro de tentative ;
• fournisseur et URL de base.

4. Examiner le corps et les en-têtes du 429

La norme HTTP autorise une réponse 429 à inclure un en-tête Retry-After, mais ne l’impose pas. La documentation DeepSeek consultée ne garantit pas que cet en-tête sera toujours présent.

Le client doit donc :

1. respecter Retry-After lorsqu’il est valide ;
2. utiliser son propre backoff avec jitter lorsqu’il est absent ;
3. imposer un nombre maximal de tentatives ;
4. abandonner lorsque le délai total autorisé est dépassé.

Cette sémantique de Retry-After est définie par le standard HTTP 429.

5. Comparer la latence avant et pendant l’incident

Une hausse de la latence précède souvent l’augmentation de la concurrence : les requêtes restent actives plus longtemps, ce qui réduit mécaniquement le débit soutenable.

Comparez :

• latence médiane ;
• p95 et p99 ;
• temps d’attente dans votre file ;
• temps avant le premier token ;
• durée totale de génération ;
• taux de 429 ;
• profondeur de la file.

6. Vérifier l’état officiel du service

Si les erreurs s’accompagnent de 500, de 503 ou d’une dégradation générale de la latence, consultez la page officielle de statut DeepSeek. Un incident fournisseur ne se résout pas en augmentant agressivement le nombre de retries.

Prévenir les erreurs 429 en production

Placer la file d’attente avant l’appel HTTP

Une requête DeepSeek est comptabilisée dès son envoi. Il est donc préférable de conserver les travaux excédentaires dans votre propre file plutôt que d’ouvrir immédiatement toutes les connexions.

Une architecture robuste suit généralement ce parcours :

Requête métier
    ↓
Contrôle d’admission
    ↓
File d’attente bornée
    ↓
Pool de workers par modèle
    ↓
Sémaphore de concurrence
    ↓
API DeepSeek

La file doit être bornée. Lorsqu’elle est pleine, l’application doit appliquer une stratégie explicite : refuser temporairement la demande, réduire la qualité de service, reporter un traitement asynchrone ou utiliser un fournisseur de secours.

Une file infinie ne supprime pas la surcharge ; elle la transforme en latence et en consommation de mémoire.

Coordonner toutes les instances

Dans une application déployée sur plusieurs machines, un sémaphore en mémoire ne contrôle que l’instance locale. Utilisez plutôt, selon l’architecture :

• une file de messages centralisée ;
• un pool partagé de workers ;
• un sémaphore distribué ;
• un compteur atomique dans Redis ;
• un ordonnanceur unique par compte et par modèle.

La capacité interne choisie ne doit pas être automatiquement égale au plafond officiel. Elle doit tenir compte des autres services, des variations de latence et de la marge nécessaire aux tâches prioritaires.

Appliquer un backoff exponentiel avec jitter

Une stratégie de retry correcte comporte quatre protections :

1. Backoff exponentiel : le plafond d’attente augmente après chaque échec.
2. Jitter aléatoire : les clients ne réessaient pas tous au même moment.
3. Nombre maximal de tentatives : aucun appel n’est relancé indéfiniment.
4. Budget total : l’ensemble des attentes et tentatives ne dépasse pas la durée acceptable pour l’utilisateur ou la tâche.

Une variante dite full jitter choisit le délai aléatoirement entre zéro et un plafond exponentiel :

plafond(n) = min(plafond_max, délai_initial × 2ⁿ)
attente(n) = valeur aléatoire entre 0 et plafond(n)

Les valeurs concrètes dépendent de la latence du produit, du type de traitement et de la criticité de la demande. Elles ne constituent pas des paramètres officiels DeepSeek.

Réduire la durée des requêtes

Pour libérer plus rapidement les emplacements :

• imposez une sortie maximale adaptée au besoin ;
• ne transmettez pas un historique inutile ;
• résumez les conversations très longues ;
• désactivez le mode raisonnement pour les tâches simples après validation qualitative ;
• annulez les traitements devenus inutiles lorsque le client abandonne ;
• évitez de lancer simultanément plusieurs variantes dont une seule sera utilisée ;
• mettez en cache les réponses déterministes ou réutilisables ;
• dédupliquez les travaux identiques arrivant au même moment.

Le streaming peut améliorer l’expérience utilisateur, mais il ne réduit pas automatiquement la durée totale de la connexion.

Séparer les traitements interactifs et les traitements par lots

Un batch massif ne doit pas consommer toute la capacité réservée au trafic utilisateur. Utilisez des files et des limites distinctes, par exemple :

• une file prioritaire pour les requêtes interactives ;
• une file à faible priorité pour les exports et enrichissements ;
• un quota interne par produit ou par tenant ;
• une capacité de réserve pour les opérations critiques.

Il s’agit de quotas applicatifs : ils ne remplacent pas le plafond du compte DeepSeek.

Exemple Python : concurrence bornée et retries contrôlés

L’exemple suivant utilise directement l’endpoint compatible OpenAI afin de rendre visibles les statuts et les en-têtes HTTP. Il nécessite httpx :

pip install httpx

La valeur 20 utilisée pour MAX_CONCURRENCY est un point de départ applicatif illustratif, pas une limite officielle.

from __future__ import annotations

import asyncio
import email.utils
import os
import random
import time
from datetime import datetime, timezone
from typing import Any

import httpx


API_URL = "https://api.deepseek.com/chat/completions"
MODEL = os.getenv("DEEPSEEK_MODEL", "deepseek-v4-flash")

# Valeur interne à adapter après des tests de charge.
MAX_CONCURRENCY = int(
    os.getenv("DEEPSEEK_MAX_CONCURRENCY", "20")
)

MAX_ATTEMPTS = 5
RETRY_BUDGET_SECONDS = 60.0
BASE_DELAY_SECONDS = 0.75
MAX_DELAY_SECONDS = 20.0
RETRYABLE_STATUS = {429, 500, 503}


class TemporaryDeepSeekError(RuntimeError):
    pass


def parse_retry_after(value: str | None) -> float | None:
    """Analyse Retry-After en secondes ou sous forme de date HTTP."""
    if not value:
        return None

    try:
        return max(0.0, float(value))
    except ValueError:
        pass

    try:
        retry_at = email.utils.parsedate_to_datetime(value)
        if retry_at.tzinfo is None:
            retry_at = retry_at.replace(tzinfo=timezone.utc)

        return max(
            0.0,
            (retry_at - datetime.now(timezone.utc)).total_seconds(),
        )
    except (TypeError, ValueError, OverflowError):
        return None


async def create_completion(
    client: httpx.AsyncClient,
    gate: asyncio.Semaphore,
    prompt: str,
    *,
    user_id: str | None = None,
) -> str:
    payload: dict[str, Any] = {
        "model": MODEL,
        "messages": [
            {"role": "user", "content": prompt},
        ],
        # Désactivé ici pour raccourcir cette tâche d'exemple.
        # Activez-le si la qualité attendue l'exige.
        "thinking": {"type": "disabled"},
        "max_tokens": 500,
        "stream": False,
    }

    if user_id is not None:
        payload["user_id"] = user_id

    deadline = time.monotonic() + RETRY_BUDGET_SECONDS
    last_reason = "cause inconnue"

    for attempt in range(1, MAX_ATTEMPTS + 1):
        retry_after: float | None = None

        try:
            # Le sémaphore n'est occupé que pendant l'appel HTTP.
            async with gate:
                response = await client.post(
                    API_URL,
                    json=payload,
                )
        except httpx.TransportError as exc:
            last_reason = type(exc).__name__
        else:
            if response.is_success:
                body = response.json()
                return body["choices"][0]["message"]["content"]

            if response.status_code not in RETRYABLE_STATUS:
                # Pas de retry à l'identique pour 400, 401,
                # 402, 422 ou une autre erreur permanente.
                response.raise_for_status()

            last_reason = f"HTTP {response.status_code}"
            retry_after = parse_retry_after(
                response.headers.get("Retry-After")
            )

        if attempt == MAX_ATTEMPTS:
            break

        exponential_cap = min(
            MAX_DELAY_SECONDS,
            BASE_DELAY_SECONDS * (2 ** (attempt - 1)),
        )

        if retry_after is None:
            # Full jitter.
            delay = random.uniform(0.0, exponential_cap)
        else:
            # Respecte le délai demandé et ajoute un petit jitter.
            delay = retry_after + random.uniform(
                0.0,
                min(1.0, exponential_cap),
            )

        remaining = deadline - time.monotonic()
        if remaining <= 0 or delay > remaining:
            break

        await asyncio.sleep(delay)

    raise TemporaryDeepSeekError(
        "Appel DeepSeek abandonné après épuisement "
        f"des tentatives ou du budget de retry ({last_reason})."
    )


async def run_batch(prompts: list[str]) -> list[object]:
    api_key = os.getenv("DEEPSEEK_API_KEY")
    if not api_key:
        raise RuntimeError(
            "La variable DEEPSEEK_API_KEY est absente."
        )

    gate = asyncio.Semaphore(MAX_CONCURRENCY)

    limits = httpx.Limits(
        max_connections=MAX_CONCURRENCY,
        max_keepalive_connections=MAX_CONCURRENCY,
    )

    timeout = httpx.Timeout(
        connect=10.0,
        read=180.0,
        write=30.0,
        pool=30.0,
    )

    async with httpx.AsyncClient(
        headers={
            "Authorization": f"Bearer {api_key}",
            "Content-Type": "application/json",
        },
        limits=limits,
        timeout=timeout,
    ) as client:
        return await asyncio.gather(
            *(
                create_completion(client, gate, prompt)
                for prompt in prompts
            ),
            return_exceptions=True,
        )


if __name__ == "__main__":
    results = asyncio.run(
        run_batch(
            [
                "Résume ce texte en trois points.",
                "Propose un titre technique précis.",
                "Classe ces événements par priorité.",
            ]
        )
    )

    for result in results:
        if isinstance(result, Exception):
            print(f"Échec contrôlé : {result}")
        else:
            print(result)

Ce client apporte plusieurs garanties :

• la concurrence réelle est bornée avant l’envoi ;
• les tâches excédentaires attendent côté application ;
• les statuts permanents ne sont pas relancés à l’identique ;
• 429, 500 et 503 disposent de retries limités ;
• Retry-After est respecté lorsqu’il est fourni ;
• le jitter évite une reprise simultanée des workers ;
• un budget total empêche les attentes indéfinies ;
• la clé API reste dans une variable d’environnement.

Dans un déploiement multi-instance, remplacez ou complétez le sémaphore local par une coordination distribuée. Sinon, cinq instances configurées à 20 appels chacune peuvent produire 100 requêtes simultanées.

Utiliser user_id sans le confondre avec un quota

DeepSeek accepte un paramètre user_id pour l’isolation liée à la sécurité du contenu, au KV cache et à la planification.

Pour les comptes standard, tous les user_id sont regroupés dans le calcul de la concurrence. Ajouter plusieurs identifiants ne multiplie donc pas la capacité.

Pour un compte ayant obtenu une augmentation de concurrence, DeepSeek applique à la fois :

• une limite totale au niveau du compte ;
• une limite par user_id ;
• 500 requêtes simultanées par user_id pour deepseek-v4-pro ;
• 2 500 par user_id pour deepseek-v4-flash.

L’identifiant doit respecter l’expression [a-zA-Z0-9\-_]+, ne pas dépasser 512 caractères et ne contenir aucune information privée. Avec le SDK OpenAI, DeepSeek demande de le transmettre dans extra_body.

Exemple :

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[
        {"role": "user", "content": "Analyse ce document."}
    ],
    extra_body={
        "user_id": "tenant_8f3a2",
    },
)

Utilisez un identifiant opaque interne, et non une adresse e-mail, un numéro de téléphone, un nom ou toute autre donnée directement identifiable.

Circuit breaker et fournisseur de secours

Un fallback ne doit pas remplacer le contrôle de concurrence. Il devient utile lorsque :

• une série de 503 indique une surcharge générale ;
• le taux de 429 reste élevé malgré une admission correctement régulée ;
• la latence dépasse le délai maximal du produit ;
• un incident est visible sur la page de statut ;
• une tâche critique doit continuer malgré l’indisponibilité du fournisseur principal.

Un circuit breaker peut temporairement interrompre les nouveaux appels après un nombre d’échecs défini, puis autoriser quelques requêtes de test avant de rétablir le trafic.

Le fournisseur de secours doit être validé à l’avance sur :

• le format des messages ;
• les outils et sorties structurées ;
• les différences de modèles ;
• la qualité obtenue ;
• le coût ;
• la latence ;
• la confidentialité et le lieu de traitement des données.

Basculer aveuglément vers une API « compatible OpenAI » ne garantit pas un comportement identique.

Métriques indispensables pour surveiller les 429

Métrique	Utilité
Requêtes en vol par modèle	Comparer la charge au plafond interne et détecter la saturation
Profondeur de la file	Voir si la demande dépasse durablement la capacité
Temps d’attente dans la file	Mesurer la latence créée avant l’appel
Réponses par statut HTTP	Distinguer 429, 500, 503 et erreurs permanentes
Nombre de retries	Détecter les tempêtes de nouvelles tentatives
Succès après retry	Vérifier si la stratégie de reprise est réellement utile
Latence p50, p95 et p99	Repérer une augmentation de la durée d’occupation
Temps avant le premier token	Diagnostiquer les attentes sur les flux streamés
Tokens d’entrée et de sortie	Suivre la taille des appels et leur coût
Erreurs par service et fournisseur	Identifier le composant à l’origine du problème

Les alertes doivent combiner plusieurs signaux. Un 429 isolé n’a pas la même signification qu’une file en croissance, un p95 qui double et un taux de retries qui augmente simultanément.

Ne journalisez jamais :

• la clé API ;
• le contenu intégral de prompts sensibles ;
• des données personnelles non nécessaires ;
• un user_id contenant des informations identifiables ;
• les réponses complètes lorsque leur contenu est confidentiel.

Utilisez plutôt des identifiants de corrélation, des empreintes non réversibles si nécessaire et des métadonnées techniques minimales.

Tester la capacité sans perturber la production

Un test de charge utile ne consiste pas à envoyer immédiatement 500 ou 2 500 appels parallèles.

Procédez progressivement :

1. Utilisez un environnement contrôlé et une charge représentative.
2. Fixez le modèle, le mode raisonnement, la taille des prompts et la sortie maximale.
3. Commencez avec une faible concurrence.
4. Augmentez-la par paliers.
5. Maintenez chaque palier assez longtemps pour observer la stabilité.
6. Mesurez la latence, le taux de 429, les erreurs 5xx et la profondeur de file.
7. Testez séparément le streaming, les requêtes non streamées et les workflows agentiques.
8. Identifiez le point où la latence ou les erreurs commencent à se dégrader.
9. Définissez une limite interne inférieure à ce point.
10. Recommencez après un changement de modèle, de prompt ou d’architecture.

Le plafond officiel est une limite maximale publiée, pas un objectif d’exploitation. Une application stable doit conserver une marge pour les pics, les ralentissements et les autres services partageant le compte.

Quand demander une augmentation de capacité

Une demande d’extension devient pertinente lorsque :

• la demande soutenue dépasse votre capacité après optimisation ;
• la file d’attente augmente malgré un dimensionnement correct ;
• les appels inutiles ont déjà été supprimés ;
• la concurrence est coordonnée à l’échelle du compte ;
• le retry n’est plus utilisé pour masquer une insuffisance permanente ;
• la croissance prévue justifie une capacité supérieure.

DeepSeek permet actuellement de transmettre une demande depuis sa page officielle sur les limites. L’entreprise indique attribuer une concurrence adaptée aux besoins réels sans coût supplémentaire propre à l’extension.

Préparez des données concrètes :

• modèle concerné ;
• concurrence actuelle et souhaitée ;
• latence p50, p95 et p99 ;
• taux de 429 ;
• volume moyen et volume de pointe ;
• durée moyenne des réponses ;
• profil des rafales ;
• croissance prévue ;
• description du cas d’usage ;
• mesures de régulation déjà déployées.

Si les 429 persistent alors que le nombre de requêtes en vol paraît largement inférieur au plafond publié, fournissez au support des horodatages précis, le modèle, les statuts, le domaine appelé et des identifiants de corrélation. Ne transmettez jamais une clé API dans un ticket ou une capture.

Questions fréquentes sur les limites DeepSeek

Combien de requêtes par minute peut-on envoyer à DeepSeek ?

DeepSeek ne publie pas, au 10 juillet 2026, de valeur numérique universelle en RPM sur sa page de limites. Le débit soutenable dépend notamment de la concurrence, de la durée des requêtes et des éventuelles conditions propres au compte.

DeepSeek applique-t-il des TPM ou des RPM ?

La version chinoise de la documentation des erreurs mentionne des plafonds TPM ou RPM comme cause possible d’un 429, mais leurs valeurs ne sont pas publiées. Les seuls chiffres publics actuellement présentés sur la page des limites concernent les requêtes simultanées.

Plusieurs clés API permettent-elles d’éviter les 429 ?

Non lorsqu’elles appartiennent au même compte. La concurrence est calculée au niveau du compte, indépendamment de la clé API.

Le streaming augmente-t-il la capacité disponible ?

Non. Il réduit le délai avant l’affichage des premiers tokens, mais la connexion reste comptabilisée jusqu’à la fin de la réponse.

Ajouter une pause fixe d’une seconde suffit-il ?

Pas nécessairement. Une pause fixe ne tient compte ni du nombre de workers, ni de la durée des appels, ni des rafales. Une file d’attente, une concurrence bornée et un backoff avec jitter sont plus robustes.

user_id augmente-t-il la limite du compte ?

Non. Pour les comptes standard, tous les identifiants sont regroupés. Pour les comptes ayant obtenu une extension, user_id ajoute une isolation de planification et un plafond par identifiant, mais ne remplace pas la limite totale du compte.

Pourquoi un 429 apparaît-il avec OpenRouter alors que DeepSeek annonce une capacité supérieure ?

Parce que l’erreur peut provenir d’OpenRouter ou d’un autre fournisseur intermédiaire. Ses quotas, sa capacité partagée et ses politiques de retry ne sont pas ceux du compte officiel DeepSeek.

Faut-il toujours relancer une requête après un 429 ?

Non. Le client doit d’abord réduire la pression, puis effectuer un nombre limité de tentatives avec jitter. Une tâche ayant dépassé son délai utile doit être abandonnée ou replacée dans une file différée.