Dernière mise à jour : 2026-06-22

La planification des limites de débit d'un LLM expliquée

La planification des limites de débit d'un grand modèle de langage est la démarche consistant à déterminer le débit de requêtes soutenable, et la concurrence en vol qu'il implique, que les limites d'API d'un fournisseur autorisent pour une charge donnée. Les API d'inférence hébergées plafonnent le débit sur deux axes indépendants : les jetons par minute (JPM), le nombre de jetons — entrée plus sortie — que le compte peut traiter chaque minute, et les requêtes par minute (RPM), le nombre d'appels d'API autorisés chaque minute, quelle que soit leur taille. Le plafond atteint en premier fixe la limite.

Quelle limite est déterminante

Une charge dont le coût moyen en jetons par appel est connu traduit le plafond JPM en un plafond de requêtes équivalent. Diviser le budget de jetons par minute par les jetons consommés par requête donne les requêtes par minute que la limite de jetons autorise à elle seule :

où $L_t$ est la limite JPM et $n$ les jetons par requête. Le débit soutenable est le plus petit de ce plafond dérivé des jetons et du plafond RPM explicite $L_r$ :

Si $R_t < L_r$, la limite de jetons est déterminante ; si $R_t \ge L_r$, c'est la limite de requêtes. Les travaux riches en jetons (contexte long, grandes réponses) tendent à être limités par les jetons ; les petits appels à haute fréquence tendent à être limités par les requêtes.

La concurrence par la loi de Little

Le débit soutenable par seconde est $R_s = R / 60$. La loi de Little, un résultat de la théorie des files d'attente établissant que le nombre moyen d'éléments dans un système égale le débit d'arrivée multiplié par le temps moyen que chacun y passe, convertit ce débit et la latence moyenne par requête $t_L$ en la concurrence $C$ qui doit s'exécuter en parallèle pour garder le tuyau plein :

Exemple chiffré

Soit une limite JPM de $L_t = 2\,000\,000$, une limite RPM de $L_r = 10\,000$, et une moyenne de n = 2,000 jetons par requête. Le plafond dérivé des jetons est

Comme 1,000 < 10,000, la limite de jetons est déterminante : le débit est plafonné à 1 000 requêtes par minute, et non aux 10 000 affichées. À une latence moyenne de $t_L = 20$ secondes, le débit par seconde est $R_s = 1\,000 / 60 \approx 16.7$, de sorte que la concurrence requise est

Soutenir ce débit signifie donc garder à peu près 333 requêtes en vol à la fois. Comme la charge est limitée par les jetons, relever le plafond RPM n'aiderait pas ; réduire les jetons par requête — par des invites plus courtes, des réponses plus brèves ou le Calculateur d'économies du cache d'invite — ou demander une allocation JPM plus élevée le ferait.

Variantes et application

Quand les requêtes sont plutôt limitées par les requêtes, regrouper plusieurs éléments par appel accroît le débit effectif là où réduire les jetons n'aide pas. La latence n'intervient que par la loi de Little : doubler $t_L$ double la concurrence qu'exige un débit fixe, de sorte que des modèles plus rapides détendent le dimensionnement des pools de connexions et des files d'attente. Le chiffre de concurrence alimente la configuration du client — nombre de travailleurs, limites de sémaphores, pools de connexions — et le débit soutenable alimente les projections de coût via le Calculateur de coût mensuel d'un LLM. Comme le nombre de jetons varie d'une requête à l'autre et que les fournisseurs peuvent mettre en file d'attente ou autoriser des rafales, les chiffres en régime permanent sont une base de planification à valider face au trafic réel.