Comment les APIs de LLM doivent-elles limiter les requêtes, les tokens et la concurrence ?
Traduction automatique
Cet article a été traduit automatiquement depuis la version originale en anglais.
Une API de LLM a besoin de limites distinctes pour le nombre de requêtes, le volume de tokens et le travail simultané. Le nombre de requêtes par minute ne suffit pas à protéger un service lorsque la longueur des prompts et des sorties générées varie. Ajoutez des plafonds d’entrée et de sortie par requête, puis testez les limites d’admission par rapport à l’objectif de latence.
Pourquoi le nombre de requêtes ne suffit pas
Un prompt de 10 tokens et un prompt de 100,000 tokens ont des longueurs d’entrée qui diffèrent d’un facteur 10,000. Leurs coûts totaux dépendent aussi de la longueur de sortie, du modèle et de la mise en cache. Une limite qui les traite de la même façon peut admettre plus de travail que le service ne peut en traiter.
Combinez plusieurs contrôles :
| Limite | Ce qu’elle contrôle |
|---|---|
| Requêtes par minute | Volume d’appels, y compris de nombreuses petites requêtes |
| Tokens d’entrée et de sortie | Volume de traitement et dépenses variables |
| Requêtes simultanées | Travail actif qui consomme de la capacité de décodage et de la mémoire KV |
| Tokens par requête | Prompts ou sorties individuels qui dépassent les limites testées |
Appliquez les limites par locataire avant une limite partagée à l’échelle du service, afin qu’un locataire ne puisse pas consommer toute la capacité disponible.
Comment fonctionne la réservation de tokens
Une politique possible de l’application réserve, à l’admission, le nombre estimé de tokens d’entrée plus la sortie maximale autorisée. Une requête avec 2,000 tokens d’entrée et un plafond de sortie de 1,000 réserve 3,000 tokens. Si elle produit 200 tokens de sortie, l’utilisation réelle est de 2,200 ; l’application restitue 800.
Distinguez cet exemple de la comptabilisation du fournisseur. OpenAI documente ses propres estimations de quotas de requêtes et de tokens. Anthropic documente des limites distinctes pour les tokens d’entrée et de sortie. Une réservation locale ne permet pas de prévoir quel quota du fournisseur une requête consomme. Réconciliez les requêtes interrompues lorsque les données d’utilisation deviennent disponibles, et plafonnez les réservations qui ne peuvent pas être réconciliées.
Que vérifier sous charge
Combinez prompts courts et longs, sorties courtes et longues et locataires actifs simultanément. Relevez le temps d’attente en file, les requêtes rejetées, TTFT, TPOT et l’utilisation du KV cache. Ne mettez les requêtes en attente que pour une durée limitée ; sinon, rejetez-les avec une politique claire de nouvelle tentative. Un budget de tokens par minute peut tout de même admettre un afflux soudain qui dépasse la capacité mémoire disponible pour les requêtes simultanées.
Pour une conception plus complète, lisez la limitation du débit de requêtes dans le guide d’ingénierie des LLM.