Que sont les limites de débit de l'API LLM ?

Qu'est-ce qu'une limite de débit sur cette API

Une limite de débit est ici un plafond par "bucket" à l'intérieur d'une fenêtre fixe. Le limiteur compte une requête dans le processus de l'API, laisse passer les premières et refuse la suivante avec HTTP 429. Il n'y a pas de "token bucket", pas de "leaky bucket" et pas de compteur partagé à travers un cluster : un "bucket" est un nom, une limite et une fenêtre, et chaque nombre sur la page des limites est rendu à partir du même objet que le limiteur lit, plutôt que d'être tapé dans un document.

Les "buckets", avec leurs nombres

Les "buckets" d'inférence sont les deux que la plupart des appelants rencontrent. key_chat autorise 600 appels d'inférence par clé API dans une fenêtre d'une minute ; org_chat autorise 1800 appels d'inférence pour l'ensemble d'une organisation dans la même minute. Les deux doivent être respectés pour qu'un appel puisse se poursuivre, et c'est délibéré plutôt que redondant : une clé bruyante ne peut pas consommer tout le budget de l'organisation, et une organisation occupée ne peut pas être affamée par une seule clé ne comptant que pour elle-même.

L'API de la plateforme est comptée séparément. platform autorise 300 appels par clé par minute pour les lectures et écritures organisationnelles — clés, utilisation, traces, politiques. Les surfaces publiques ont leurs propres "buckets" basés sur l'IP : public_chat autorise 20 appels anonymes de "playground" par adresse IP par heure, public_card_request autorise 5 requêtes de fiches de modèle depuis le formulaire public par IP par heure, et auth autorise 20 tentatives de connexion, d'inscription, de récupération et de réinitialisation de mot de passe par IP dans une fenêtre de quinze minutes.

Une ligne de ce tableau est un avertissement plutôt qu'un contrôle. public_page est définie avec une limite de 300 requêtes par heure par IP, et aucun chemin de requête sur ce déploiement ne la vérifie. Elle est imprimée avec un marqueur "non-appliqué", car un nombre dans la documentation que rien n'applique n'est pas une limite, et cacher l'écart rendrait tous les autres nombres de la page moins crédibles.

Ce que contient réellement un refus

Une requête refusée est HTTP 429 avec le type rate_limit_error et le code rate_limit_exceeded. Ce déploiement ne définit aucun en-tête "retry-after" et aucun en-tête "x-ratelimit", donc le corps de la réponse est la seule horloge que vous obtenez. Lorsque le limiteur sait quand sa fenêtre se termine, le message se termine par cet instant en ISO 8601, par exemple un horodatage "Retry after". Pour la limite par organisation, le message ne nomme aucun temps, donc la "backoff" exponentielle est la seule stratégie honnête. Réessayer plus tôt ne peut pas réussir : le compteur ne bouge que lorsque la fenêtre se réinitialise.

La concurrence est également limitée

Au maximum 8 requêtes peuvent être en cours sur une clé API à la fois. Le compte est conservé par clé et non par organisation, il est augmenté lorsqu'un appel entre dans le gestionnaire de chat et diminué lorsqu'il se termine, et une requête dépassant la limite est refusée immédiatement avec le même 429. Il n'y a pas de file d'attente derrière, ce que les gens oublient : une requête concurrente dépassant la limite n'est pas ralentie, elle est rejetée.

Pourquoi les fenêtres sont par processus

Les fenêtres résident dans la mémoire du processus API. Elles sont réécrites dans la table rate_limits toutes les 15 secondes et à l'arrêt, et restaurées au démarrage du processus, de sorte qu'un redémarrage continue une fenêtre au lieu de distribuer un nouveau budget. La conséquence est énoncée plutôt que découverte : le compteur est par nœud API, donc deux nœuds API doublent chaque limite effective. La version partagée nécessiterait un stockage que rien ne lit encore — REDIS_URL est réservé à cet effet et inutilisé, donc le conseil pratique est d'exécuter un seul nœud API ou d'accepter sciemment les limites par nœud.

Ce qui n'est pas une limite de débit

Trois refus ressemblent à une limitation de débit et n'en sont pas. Un plafond de dépenses quotidien sur l'organisation répond 402 budget_exceeded avant qu'un point de terminaison ne soit évalué ; c'est de l'argent, pas un débit. Un plafond de prix par million de jetons supprime un point de terminaison de l'ensemble des candidats pendant le routage au lieu de rejeter la requête, de sorte que l'appel réussit toujours sur un point de terminaison moins cher. Et 409 no_endpoint_for_policy est le filtre de résidence qui refuse de se relâcher ; le réessayer ne change rien, car la même requête échoue de la même manière. Seul le 429 vaut la peine d'être réessayé avec une "backoff".

Les corps de requête sont plafonnés à 1 Mo et validés avant que quoi que ce soit d'autre ne se produise, ce qui est une limite de taille plutôt qu'une limite de débit, et les traces de pile sont enregistrées plutôt que renvoyées à un appelant.

Comment planifier en fonction des limites

Comptez ce que votre intégration envoie réellement par clé par minute, et rappelez-vous qu'une complétion en streaming occupe un emplacement en cours de traitement pendant toute sa durée. Si plusieurs services partagent une clé, ils partagent ses 600 appels et ses 8 emplacements concurrents ; des clés séparées sous une même organisation respectent toujours ensemble le plafond de 1800 appels de l'organisation. Lisez la page des limites avant de régler, car elle est rendue à partir de la table d'application, et traitez les noms de "bucket" comme le vocabulaire sur lequel votre gestion des erreurs doit se baser : clé, organisation, IP et plateforme échouent chacun différemment et seuls certains d'entre eux vous disent quand revenir.

Si votre charge de travail ne peut pas s'intégrer dans ces chiffres, la conclusion honnête est que ce déploiement n'est pas encore dimensionné pour elle. Le tableau est public, il indique quelles lignes sont appliquées, et une limite que vous pouvez lire à l'avance vaut plus que celle que vous découvrez en production.