Scaler les AI Gateways : Comment regrouper des clés API et survivre aux rate limits

Quand on intègre pour la première fois des Large Language Models (LLMs) dans son produit, tout fonctionne. On envoie un prompt, on reçoit une réponse. Mais au fur et à mesure que la base d'utilisateurs grandit, on heurte un mur dur : les rate limits du provider.

Qu'il s'agisse des limites strictes de Tokens Par Minute (TPM) d'OpenAI ou des contraintes de Requêtes Par Minute (RPM) d'Anthropic, une seule clé d'API devient rapidement un goulot d'étranglement. La solution intuitive est de regrouper plusieurs clés API pour exactement le même modèle afin d'augmenter artificiellement la capacité totale de rate limit.

Cependant, gérer un pool de clés API de provider introduit un changement architectural. Explorons pourquoi les reverse proxies simples ne suffisent pas, comment implémenter réellement le pooling de clés API, et l'architecture générique requise pour le faire en toute sécurité.

Le catalyseur : Heurter le mur des rate limits

La plupart des grands providers LLM imposent des rate limits doubles :

• RPM (Requêtes Par Minute) : Plafonne le volume pur des connexions concurrentes.
• TPM (Tokens Par Minute) : Plafonne le throughput réel de calcul (souvent un mélange de tokens d'entrée et de sortie).

Si vous avez une application IA à croissance rapide, atteindre une limite de 1M TPM est facile. Quelques utilisateurs intensifs traitant de gros documents peuvent épuiser votre quota en quelques secondes, laissant le reste de vos utilisateurs fixer des erreurs 429 Too Many Requests.

L'étape logique pour surmonter cela est de provisionner plusieurs clés API (ou plusieurs déploiements cloud, comme plusieurs endpoints Azure OpenAI) et de répartir le trafic entre eux. Si une clé vous donne 1M TPM, cinq clés vous donnent 5M TPM.

L'approche naïve : Pourquoi les load balancers simples échouent

Votre premier instinct pourrait être de placer Nginx, HAProxy ou un ALB AWS basique devant vos requêtes et de configurer une stratégie de routing round-robin simple à travers votre pool de clés API.

Cela échoue en production.

iWarning+

Les reverse proxies standards suivent les requêtes, pas les tokens.

Contrairement au trafic web traditionnel où les requêtes ont des coûts de ressources relativement uniformes, les requêtes LLM varient. La Requête A peut poser une simple question consommant 50 tokens. La Requête B peut transmettre un PDF massif consommant 100 000 tokens.

Si un load balancer round-robin naïf distribue ces requêtes uniformément par compte, il épuisera les quotas de tokens de vos clés sous-jacentes de façon inégale. Une clé API peut atteindre sa limite TPM instantanément tandis qu'une autre reste complètement inactive. Pour router le trafic correctement, le load balancer doit comprendre la taille du payload, estimer les comptes de tokens et maintenir l'état de la capacité restante sur chaque clé de provider.

Le comment : L'architecture IA à 3 couches

Pour construire ça réellement, il faut abandonner l'idée d'un seul « proxy intelligent ». L'infrastructure LLM de production répartit les responsabilités à travers trois couches distinctes.

1. Le Control Plane (Source de vérité)

Cette couche possède l'état global. Elle stocke vos Virtual Keys (identités d'utilisateurs), les budgets utilisateur, les clés API de provider et les compteurs RPM/TPM en direct. Elle est généralement soutenue par Postgres (pour le billing/clés durables) et Redis (pour les token buckets rapides).

2. Le Moteur de Routing (Décideur)

Cette couche décide où la requête doit aller. Elle vérifie le Control Plane pour voir quelles clés de provider ont une capacité restante, évalue la logique de fallback et sélectionne le provider amont optimal (par ex., choisir la Clé OpenAI n°3 parce qu'elle a le plus de TPM disponible).

3. Le Gateway (Couche d'exécution)

C'est le plan de données « bête ». Il reçoit le payload, attache la clé API physique choisie par le router, transfère la requête au LLM, diffuse les Server-Sent Events (SSE) au client et émet des logs d'usage vers le Control Plane.

Implémenter des rate limits distribués

Comment empêcher réellement les requêtes qui se chevauchent de dépasser vos limites quand vous exécutez plusieurs nœuds de gateway ? Il faut externaliser la vérification de quota en utilisant du verrouillage pessimiste via Redis.

Quand une requête arrive, le Control Plane l'intercepte, estime le coût en tokens et déduit ce coût d'un compteur Redis global avant de transférer la requête au Gateway. Si le compteur Redis atteint zéro, la requête est bloquée immédiatement.

Comme Redis traite les commandes atomiquement, peu importe que vous ayez 1 ou 100 nœuds de gateway traitant des requêtes simultanément. Deux requêtes concurrentes ne peuvent pas vider le même budget de 1,00 $. Le Control Plane garantit que le quota n'est jamais enfreint.

Prochaines étapes : Choisir votre implémentation

Vous pouvez construire ce système à 3 couches entièrement à partir de zéro, mais la plupart des équipes adoptent des AI gateways open-source qui implémentent des parties (ou la totalité) de ce schéma.

Cependant, tous les gateways ne gèrent pas l'état global de la même façon. Dans de futurs posts, nous verrons comment cette exigence architecturale impacte vos choix :

• LiteLLM : Regroupe le Control Plane (via Redis) et le Router/Gateway ensemble, ce qui le rend très capable de rate limiting distribué open-source out-of-the-box.
• Bifrost : Agit comme un Router/Gateway rapide, mais suit l'état par nœud. Pour le scaler en toute sécurité sans payer pour le clustering Enterprise, vous devez construire et attacher votre propre Control Plane externe.

Pour une plongée plus profonde dans la théorie derrière les limites côté demande par rapport aux limites côté offre, explorez notre plan pour architecturer les budgets d'AI gateway.