Architecturer les budgets d'AI Gateway : Virtual Keys, Provider Keys et quotas distribués

Comme nous l'avons établi en parlant des défis du pooling de clés API, quand on construit un AI Gateway comme interface principale entre vos utilisateurs et les LLM en amont, router les requêtes n'est que la moitié du travail. Le défi le plus difficile est de concevoir un système de budgétisation au niveau produit.

Si vous ne concevez pas votre système de quotas correctement, un pic soudain de requêtes concurrentes peut contourner vos limites, ruiner vos comptes d'API en amont et causer des pannes généralisées de 429 Too Many Requests pour tous vos clients.

Dans ce dernier post, nous parcourons un plan pour architecter un moteur de quotas IA distribué.

La séparation architecturale : exécution vs. vérité

L'erreur la plus courante en construisant un AI Gateway est de traiter le proxy lui-même comme source de vérité.

Une architecture de production doit séparer l'exécution des requêtes de la vérité du budget. Le gateway peut parser les headers, gérer le streaming Server-Sent Events (SSE) et gérer les timeouts. Mais un module de budget dédié (ou microservice) doit posséder la vue autoritaire des budgets utilisateurs, des compteurs et des dépenses.

Limites côté demande vs. côté offre

Un AI Gateway en production fonctionne comme un marché à deux côtés. Une requête n'est valide que si elle passe les vérifications des deux côtés de l'équation.

1. Limites côté demande (l'utilisateur)

Ce sont les contraintes placées sur l'entité qui fait la requête.

• Identité : Qui est-ce ? (Mappé via une Virtual Key)
• Modèles autorisés : Peuvent-ils utiliser gpt-4o ou seulement gpt-3.5-turbo ?
• Dépense max : Cette équipe a-t-elle dépassé sa limite mensuelle de 500 $ ?
• Rate limits : Dépassent-ils leurs 50 Requests Per Minute (RPM) assignées ?

2. Limites côté offre (le provider)

Ce sont les contraintes de votre infrastructure amont réelle.

• Provider Keys : Quelles clés OpenAI/Anthropic sont disponibles ?
• Capacité : sk-key-1 a-t-il assez de Tokens Per Minute (TPM) restants pour traiter ce prompt ?
• Cooldowns : Cette clé spécifique est-elle actuellement verrouillée par un 429 du provider ?

Les Virtual Keys sont la frontière du budget

Une Virtual Key n'est pas simplement un jeton d'authentification ; c'est la frontière fondamentale du budget.

Dans un système multi-tenant, la Virtual Key représente l'identité, l'accès aux modèles et l'attribution des dépenses en même temps. Cela montre exactement pourquoi les architectures qui ne synchronisent pas l'état des Virtual Keys entre plusieurs nœuds (comme les déploiements open-source de Bifrost que nous avons analysés précédemment) sont cassées. Si l'état des Virtual Keys n'est pas globalement cohérent, votre frontière de budget n'existe tout simplement pas sous charge.

Le flux de requêtes d'un module de budget

Pour orchestrer ces contraintes en toute sécurité, votre module de budget doit exécuter une séquence spécifique d'opérations :

1. Résoudre la Virtual Key : Identifier l'utilisateur, l'équipe ou la politique client.
2. Vérifier l'accès au modèle : S'assurer que le modèle demandé est autorisé pour cette Virtual Key.
3. Vérifier le quota côté demande : Interroger Redis/Postgres pour s'assurer que l'utilisateur a suffisamment de RPM/TPM et de budget monétaire.
4. Sélection des candidats : Demander au layer de routing les Provider Keys disponibles.
5. Vérifier le quota côté offre : S'assurer que la Provider Key sélectionnée a de la capacité.
6. Réserver le quota : Atomiquement réserver le coût estimé avant de transférer la requête.
7. Exécuter : Proxyer la requête au provider LLM.
8. Régler : Calculer les tokens réellement utilisés à partir des headers de réponse du provider et mettre à jour le coût final.
9. Persister : Écrire le grand livre durable des dépenses dans Postgres.

Pourquoi la réservation compte sous concurrence

L'étape 6 (Réservation) est la pièce maîtresse de tout le système.

Imaginez que l'Utilisateur X a 1,00 $ restants dans son budget. Il lance un script qui tire 100 requêtes concurrentes sur le gateway.

Si votre gateway utilise une vérification de budget en "lecture seule", les 100 requêtes interrogeront la base de données à la même milliseconde. Les 100 requêtes verront "1,00 $ restants" et laisseront la requête continuer. Quelques secondes plus tard, le LLM répond, les coûts sont réglés, et l'Utilisateur X a consommé 10,00 $ de compute, dépassant son hard limit de 10x.

iWarning+

Pour éviter cela, le système a besoin de réservation atomique. Quand une requête arrive, le gateway doit immédiatement déduire le coût estimé de la requête (par ex. input_tokens + max_tokens) du compteur chaud dans Redis.

Si la réservation pousse le budget sous zéro, la requête est bloquée. Une fois la requête terminée, le gateway rembourse les tokens inutilisés au compteur Redis. En exécutant la vérification du budget et la déduction atomiquement dans Redis, vous éliminez complètement la race condition.

Hard limits, soft caps et règlement

Faire respecter ces limites nécessite des stratégies distinctes selon la métrique :

• Hard RPM (Requests Per Minute) : C'est direct. Vous incrémentez atomiquement un compteur Redis avant le route. S'il dépasse la limite, bloquez-le.
• Hard-ish TPM (Tokens Per Minute) : Vous devez réserver les tokens estimés avant le routing. Comme les tokens de sortie du LLM sont imprévisibles, vous utilisez le paramètre max_tokens comme réservation du pire cas.
• Soft budgets (dépense totale) : La documentation de l'AI Gateway de Vercel décrit les budgets de clés API explicitement comme des soft caps vérifiés au début d'une requête. Vous laissez la "requête qui franchit" (celle qui pousse un utilisateur de 49,95 $ à 50,10 $) terminer, mais vous bloquez immédiatement toutes les requêtes futures pendant la phase de règlement.

Le rôle de Redis et Postgres

Un module de budgétisation robuste répartit les responsabilités entre des datastores éphémères et durables.

Redis possède le hot path :

• Token buckets RPM/TPM en direct.
• Réservations atomiques pour les requêtes en vol.
• Compteurs de requêtes parallèles max.
• Locks de cooldown de provider de courte durée.

Postgres possède le path durable :

• La liste autoritaire des Virtual Keys, utilisateurs et équipes.
• Définitions de budget et politiques de facturation.
• Le grand livre immuable des dépenses et les enregistrements de rapprochement.

Thèse finale

Un AI Gateway en production est, à la base, un moteur de quotas distribué à deux côtés. Les Virtual Keys représentent votre identité et exécution de budget côté demande, tandis que les Provider Keys représentent votre capacité amont.

En utilisant des outils qui séparent l'état durable et éphémère, comme LiteLLM, pour coordonner les réservations en direct via Redis et enregistrer les dépenses durables via Postgres, vous pouvez faire évoluer votre infrastructure IA pour gérer une forte concurrence sans ruiner vos comptes d'API. Toute architecture de gateway qui ne peut pas synchroniser cet état entre ses nœuds, comme nous l'avons vu dans notre comparaison LiteLLM vs. Bifrost, n'est pas sûre pour la production.