Limitation de débit et quotas pour les API LLM

La limitation de débit tenant compte des jetons est essentielle pour garantir la fiabilité, la stabilité et le contrôle des coûts dans les déploiements d'API LLM. Le trafic LLM est inégal. Un utilisateur envoie une invite contenant 200 jetons, un autre en envoie 20 000. Si vous ne faites que limiter demandes par minute, quelques instructions lourdes peuvent geler tout le monde et faire exploser votre budget. Les limites tenant compte des jetons protègent la latence et les coûts sans pénaliser une utilisation normale.

Essayez Compute dès aujourd'hui: placez votre modèle derrière un support dédié VllM point de terminaison activé Calculer. Limitez les plafonds, diffusez des jetons et appliquez des limites tenant compte des jetons au niveau de la passerelle. Placez-le à proximité des utilisateurs pour éviter toute latence évitable.

Pourquoi les limites de demandes simples échouent pour les LLM

• Le travail varie en fonction de la demande. Une courte invite avec un petit plafond coûte quelques centimes ; une longue invite avec un plafond énorme coûte de nombreux jetons et beaucoup de temps.
• Le streaming masque le travail. Un seul long flux peut occuper des emplacements de décodage pendant des dizaines de secondes.
• L'équité en souffre. Quelques gros travaux font perdre beaucoup de petites tâches si vous n'emballez qu'en fonction du nombre de demandes.

La limitation de débit tenant compte des jetons pour les LLM a pour but de garantir une gestion équitable et efficace des ressources sur les plateformes d'IA multi-locataires, de prévenir la pénurie de ressources et de promouvoir un fonctionnement stable du système.

Des modèles qui fonctionnent grâce à la prise en compte des jetons

Utilisez des limites qui reflètent le coût réel :

• Limites de jetons rapides par minute (protégez le préremplissage et la mémoire).
• Limites des jetons de sortie par minute (protéger le débit de décodage).
• Limites totales de jetons par minute/heure/jour (simple à raisonner).
• Plafonds de simultanéité par clé/utilisateur (nombre maximum de flux actifs à la fois).
• Capuchons rigides par demande (max_tokens, longueur du contexte) au coût dans le pire des cas.

Combinez par touche limites (protection de la plateforme) avec par itinéraire limites (protéger l'expérience utilisateur pour des fonctionnalités spécifiques).

Suivez les meilleures pratiques pour mettre en œuvre et gérer des modèles de limitation de débit tenant compte des jetons, telles que l'établissement de règles claires, la surveillance de l'utilisation et la révision régulière des configurations pour garantir une utilisation équitable et une efficacité opérationnelle.

Choix de votre unité : demandes ou jetons

• Demandes par minute : facile à mettre en œuvre ; injuste sous des charges mixtes.
• Jetons/minute (TPM) : le meilleur équilibre entre coût et équité.
• TPM rapide par rapport au TPM de sortie : des boutons séparés si les entrées longues ou les sorties longues dominent dans votre magasin.
• Simultanéité : backstop nécessaire pour les interfaces utilisateur de streaming.

Lors de la sélection de l'unité appropriée pour la limitation de débit dans les API LLM, les principaux facteurs à prendre en compte incluent le contrôle des demandes, la stabilité du système, l'évolutivité et les modèles d'utilisation spécifiques de votre application.

Hiérarchies : par clé, par utilisateur, par application

Définissez des limites sur plusieurs couches :

• Clé → Utilisateur → Application → Organisation → Global. La limite applicable la plus stricte l'emporte. Les limites au niveau de l'organisation contribuent à garantir une utilisation équitable entre plusieurs équipes ou départements, empêchant ainsi une seule organisation de monopoliser les ressources.
• Explosion ou maintien. Donnez une petite marge de rafale, puis revenez à la cadence soutenue.
• Niveaux de priorité. Les clés premium bénéficient d'un TPM plus élevé et d'une plus grande simultanéité.

Plafonds de concurrence et équité

• Slots de décodage actifs par touche. Exemple : concurrency=2—4 pour les applications standard, 8+ pour les applications internes fiables.
• Une file d'attente équitable. Admettez un mélange d'instructions courtes et longues à chaque étape ; évitez de mourir de faim.
• Plafonds par demande. Gardez max_tokens serré pour éviter de longues générations bloquantes.
• Annulation rapide. Le cache KV gratuit se bloque immédiatement à l'arrêt de l'utilisateur.

Des plafonds de simultanéité efficaces sont essentiels pour favoriser l'évolutivité, garantir les performances du système et la rentabilité des déploiements LLM à grande échelle.

Défis courants liés à la limitation du débit des API LLM

La définition de limites de débit pour les API LLM présente des défis que vous ne rencontrerez pas avec les API classiques. L'utilisation équitable est importante : vous avez besoin de limites qui protègent votre système contre les abus tout en garantissant l'équité pour tous. Les charges de travail LLM évoluent considérablement en fonction de la taille des entrées, de la complexité du modèle et de la quantité de sortie générée. Cela rend les approches de limitation de débit standard insuffisantes.

L'application en temps réel constitue un autre obstacle. Votre API LLM doit détecter et arrêter instantanément toute utilisation excessive. Les pics de trafic peuvent affecter les performances ou faire planter votre système si vous n'êtes pas prêt. Vous avez besoin d'un équilibrage de charge intelligent et de contrôles d'accès qui s'adaptent à l'évolution des habitudes d'utilisation. Suivez les demandes et les réponses au fur et à mesure qu'elles se présentent afin de détecter les abus potentiels et de vous assurer que vos limites sont respectées.

Une communication claire est également utile. Les développeurs ont besoin de politiques de limitation de débit prévisibles pour éviter les erreurs surprises ou les problèmes de service. Fixez des limites trop strictes ou expliquez-les mal, et vous frustrerez les clients qui ne peuvent pas utiliser tout le potentiel de votre API. Si vous êtes trop lâche, vous incitez à des abus qui feront grimper vos coûts.

Une bonne limitation de débit pour les API LLM signifie trouver le juste équilibre entre les besoins des clients et la réalité de l'exploitation de grands modèles. Vous devrez surveiller en permanence, ajuster les paramètres et communiquer les modifications afin de maintenir des limites équitables, efficaces et conformes à vos objectifs commerciaux et à vos limites techniques.

Algorithmes à implémenter

• Seau à jetons pour le TPM : chaque clé a un solde qui se recharge à un rythme régulier ; dépensez en jetons d'invite et de sortie au fur et à mesure de leur traitement.
• Seau qui fuit pour le lissage : la file d'attente autorise les rafales mais se vide à un débit fixe.
• Fenêtre coulissante pour les quotas : suivez les totaux du dernier jour, de la dernière semaine ou du dernier mois sans réinitialisation précise.
• Coûts pondérés: facturez plus cher pour les longues fenêtres contextuelles ou l'utilisation d'outils si elles sollicitent les ressources.

Concevoir le 429 et réessayer après

• Retourner HTTP 429 lorsqu'une clé est hors budget ou en cas de simultanéité.
• Inclure Réessayer-Après avec une attente réaliste en quelques secondes.
• Renvoie un corps d'erreur structuré :

{
« erreur » : {
« type » : « limite_limite dépassée »,
« message » : « La clé a dépassé les 60 000 jetons/minute. «,
« retry_after » : 8,
« identifiant de la demande » : «... »
}
}


• Lorsque les limites de débit sont dépassées, assurez-vous que la réponse de l'API communique clairement l'erreur et, si possible, mettez en œuvre des stratégies de repli pour acheminer la réponse ou proposer une autre gestion afin de préserver la stabilité de l'application.
• Dans Docs, afficher retrait du client exemples de SDK que vous prenez en charge.
• Pour le streaming, envoyez un message de fin de diffusion clair lorsqu'un quota souple est atteint en cours de demande ; préférez des plafonds stricts par demande pour éviter cela.

Quotas par jour/semaine/mois

• Quotas mensuels facturation adaptée. Réinitialisez un jour calendaire ou une fenêtre continue de 30 jours.
• Quotas quotidiens protégez les abus soudains causés par de nouvelles clés.
• Exposer points de terminaison d'utilisation afin que les clients puissent voir le budget restant et éviter les surprises.
• soutien avertissements souples (en-tête HTTP 200 +) à 80 % et 95 % du quota.
• Les mécanismes de gouvernance, tels que les politiques de quotas, contribuent à garantir une utilisation équitable et stable des API LLM en gérant l'allocation des ressources et en alignant l'utilisation sur les politiques organisationnelles.

Esquisse de référence Gateway

• Façade le tout avec une passerelle légère (Nginx/Envoy/Traefik) + une petite service de limitation de taux avec Redis. Cette architecture de référence est conçue pour prendre en charge une variété d'applications, garantissant ainsi la prise en charge des différents cas d'utilisation et fonctionnalités. L'architecture permet un fonctionnement fiable et sécurisé des API LLM dans les environnements de production en fournissant des communications de service cohérentes et de haute qualité et des fonctionnalités de sécurité robustes. L'architecture de la passerelle définit des politiques de limitation du débit, d'autorisation et de protection contre les abus, contribuant ainsi à protéger les API contre les menaces malveillantes et à garantir la conformité aux exigences organisationnelles. L'exploitation efficace de la passerelle est essentielle pour maintenir les performances et la sécurité à grande échelle.
• Clés :
• tpm_prompt, tpm_output, tpm_total
• concurrence
• rpm fallback pour les itinéraires autres que le streaming
• jetons_quotidiens, jetons_mensuels
• Pour SSE, désactivez la mise en mémoire tampon du proxy et définissez judicieusement les délais de maintien en vie.
• Émettre des métriques pour permet, nie, réessayer_après, et % d'utilisation.

Essayez Compute dès aujourd'hui: Exécutez un VllM point de terminaison activé Calculer et placez votre passerelle devant. Respectez les limites en tenant compte des jetons, diffusez par défaut et placez le nœud dans la région pour réduire la latence.

Outils et technologies pour la limitation du débit

Vous disposez de nombreux outils pour aider votre organisation à mettre en place une limite de débit solide pour les API LLM. La passerelle API est au cœur de la plupart des configurations modernes. C'est votre point de contrôle central. Ici, vous gérez les demandes d'API, appliquez des limites de débit et bénéficiez de fonctionnalités essentielles telles que l'équilibrage de charge et le contrôle d'accès. Vous pouvez configurer des passerelles pour appliquer des quotas et des limites en fonction de différents critères, par client, par service ou par point de terminaison. Cela protège vos services principaux contre le trafic excessif et les abus potentiels.

Au-delà des passerelles API, vous constaterez que les algorithmes de limitation de débit tels que Token Bucket et Leaky Bucket fonctionnent bien pour atténuer les pics de trafic. Ils maintiennent des performances constantes. Ces algorithmes garantissent le traitement efficace de vos demandes d'API. Ils empêchent les pics soudains de surcharger votre système. De nombreux fournisseurs d'API LLM proposent également des fonctionnalités intégrées de limitation de débit. Vous pouvez définir des quotas ou des limites quant au nombre de demandes ou de jetons consommés au cours d'une période donnée.

Vous pouvez gérer et configurer ces limites via des API, des outils de ligne de commande ou des tableaux de bord Web. Cela vous donne, à vous et à vos administrateurs, la flexibilité nécessaire pour ajuster les paramètres selon vos besoins. Par exemple, vous pouvez utiliser une passerelle d'API pour appliquer un quota sur les appels d'API. Cela permet à votre service backend de rester réactif même en cas de pic de demande.

Lorsque vous utilisez ces outils et technologies ensemble, vous créez des systèmes efficaces et évolutifs. Ils garantissent une utilisation équitable et protègent contre les abus. Une limitation de débit efficace ne garantit pas seulement les performances et la fiabilité des API LLM. Il vous aide également à gérer les coûts et à offrir une meilleure expérience à tous les utilisateurs.

Surveillance et réglage

Montre :

• TTFT p95 et TPS p50/p95 avec longueur de file d'attente.
• Refuse pour motif (tpm_prompt, tpm_output, simultanéité).
• Principales touches en fonction de l'utilisation de jetons et éclat.
• Réessayer‑Après précision (Les clients ont-ils réussi lors de la tentative suivante ?)
• Budget d'erreur pour 429 ans : gardez-les rares pour les clients qui se comportent bien.

Mélodie :

• Le suivi de ces indicateurs permet de déterminer quand ajuster les limites de taux ou les plafonds de simultanéité.
• Augmenter TPM lorsque les files d'attente sont courtes et que l'espace libre est suffisant.
• Plus bas concurrence lorsque de longues sorties provoquent la famine.
• Ajuster plafonds par trajet pour protéger les chemins sensibles à la latence.

Implémentez des limites tenant compte des jetons sans nuire à l'expérience utilisateur

Protégez la plateforme avec jetons par minute, pas seulement demandes par minute. Gardez plafonds par demande serré, concurrence raisonnable, et Réessayer‑Après honnête. Placez une passerelle simple et un compteur Redis au premier plan, diffusez par défaut et mesurez le TTFT/TPS pour voir l'effet. Ces habitudes permettent de contrôler les dépenses et de rendre les performances prévisibles. La mise en œuvre de ces pratiques de limitation de débit permet également d'économiser des ressources et d'éviter des interruptions de service coûteuses.

FAQ

Qu'est-ce qu'une limite par défaut équitable pour les nouvelles clés d'API ?

Commencez avec 30 à 60 000 jetons/min, 2 à 4 flux simultanés et des limites strictes par demande. Augmentez les limites une fois que vous constatez un comportement stable.

Demandes/minute ou jetons/minute, que devons-nous choisir ?

Jetons/minute. Il permet de suivre les coûts réels et de protéger l'équité. Utilisez RPM comme filet de sécurité sur les itinéraires hors diffusion.

Comment limiter le débit des réponses au streaming ?

Chargez les jetons au fur et à mesure qu'ils sont générés et arrêtez lorsque le budget est épuisé, mais préférez des plafonds stricts par demande pour que les streams se terminent correctement.

Comment éviter 429 tempêtes ?

Utilisez un backoff instable chez les clients, répartissez les réinitialisations à l'aide de fenêtres coulissantes et réservez une petite capacité de mémoire tampon pour les nouvelles tentatives.

Pouvons-nous partager les limites entre plusieurs régions ?

Oui : répliquez les compteurs (par exemple, REDIS/CRDT) ou les partitions par base d'utilisateurs. Veillez à ce que les clients restent attachés à une région pour réduire la latence.

Que devons-nous enregistrer pour les audits ?

ID de clé, itinéraire, nombre de jetons d'invite et de sortie, décision d'autorisation/de refus, retry_after seconds, request_id. Évitez d'enregistrer du texte brut.

Les limites tenant compte des jetons ralentissent-elles le système ?

Les comptoirs sont bon marché. La plus grande victoire est d'empêcher que quelques gros emplois ne nuisent à tout le monde.

Quels sont les cas d'utilisation courants de la limitation de débit dans les API LLM ?

Les cas d'utilisation courants incluent la protection des services backend contre les surcharges, la gestion des coûts opérationnels et la garantie d'un accès équitable pour plusieurs clients. La limitation du débit peut également soutenir les stratégies de déploiement telles que les déploiements Canary et Blue-Green en contrôlant le trafic et en permettant des déploiements sécurisés.

‍