Calculateur de débit d'inférence par lots
Données
| Taille du lot | 32 |
|---|---|
| Jetons de sortie par requête | 256 |
| Temps de complétion du lot | 5 s |
Calculateur de débit d'inférence par lots
Convertit un temps de complétion de lot mesuré en débit agrégé de jetons par seconde, vitesse par requête et requêtes par seconde — le compromis débit-latence du service LLM par lots.
Données
Lot
Résultats
Saisissez une valeur pour afficher les résultats.
Détails
Le débit d'inférence par lots
L'inférence par lots est la manière dont les serveurs de modèles de langage en production atteignent une utilisation élevée : au lieu de décoder une requête à la fois, ils en traitent plusieurs ensemble. Comme les poids du modèle sont lus une fois et réutilisés pour tout le groupe, la production totale du serveur grimpe fortement avec la taille du lot — mais chaque requête individuelle attend la fin du lot. Ce calculateur sépare ces deux points de vue en convertissant un temps de complétion de lot mesuré en débit agrégé, vitesse par requête et taux de requêtes.
Le compromis du traitement par lots
Le décodage autorégressif est limité par la mémoire : chaque étape lit tous les poids pour produire un jeton. Lorsqu'une seule requête est en cours, la quasi-totalité de ce trafic mémoire ne sert qu'un seul utilisateur. Regroupez plusieurs requêtes en un lot et la même lecture de poids produit un jeton pour chaque requête à la fois, de sorte que le débit agrégé de jetons augmente avec la taille du lot alors que le coût en bande passante change à peine. Le revers est la latence : une requête ne peut sortir avant l'achèvement de l'étape de lot qui la contient, donc la vitesse par requête ne s'améliore pas et peut même décliner légèrement à mesure que les lots grandissent.
Les formules
À partir de la taille du lot , des jetons de sortie par requête et du temps de complétion du lot mesuré :
vaggvreqR=tbB×Nout=tbNout=tbBoù est le débit agrégé, le débit par requête et le nombre de requêtes achevées par seconde. L'agrégat est simplement la vitesse par requête multipliée par la taille du lot.
Exemple chiffré
Un serveur décode un lot de 32 requêtes, produisant chacune 256 jetons, et le lot s'achève en 5 secondes :
vaggvreqR=532×256=1638.4 tokens/s=5256=51.2 tokens/s=532=6.4 requests/sL'exploitant voit plus de 1 600 jetons par seconde sortir du serveur, mais chaque utilisateur lit à environ 51 jetons par seconde. Doubler le lot à 64 — si la mémoire le permet et que le temps de complétion reste proche de 5 secondes — doublerait à peu près l'agrégat tout en laissant le chiffre par requête inchangé.
Choisir une taille de lot
Le débit agrégé continue d'augmenter avec la taille du lot uniquement tant que le travail reste limité par la mémoire. Dès que le lot sature le calcul ou que le cache clé-valeur épuise la mémoire de l'appareil, le temps de complétion croît plus vite que le lot et la latence par requête se dégrade. La cible pratique est le plus grand lot qui maintient une latence par requête acceptable tout en tenant en mémoire, trouvé en mesurant le temps de complétion pour plusieurs tailles de lot. Les serveurs réels utilisent par ailleurs un traitement par lots continu, où les requêtes rejoignent le lot et le quittent à chaque étape plutôt qu'en groupe fixe, ce qui relève encore le débit soutenu. Pour le plafond du flux unique qui fixe , voir le Calculateur de débit d'inférence ; pour la capacité à l'échelle d'une flotte répartie sur de nombreuses répliques, voir le Calculateur de jetons effectifs par seconde.
Questions fréquentes (FAQ)
Pourquoi le débit agrégé est-il bien supérieur au débit par requête ?
Le débit agrégé comptabilise tous les jetons que le serveur émet sur l'ensemble des requêtes du lot, alors que le débit par requête correspond à ce qu'un seul utilisateur perçoit. Le traitement par lots lit chaque poids du modèle une fois et le réutilise pour tout le groupe, de sorte que le total de jetons servis augmente à peu près proportionnellement à la taille du lot.
La requête individuelle, en revanche, doit toujours attendre la fin du lot : sa vitesse perçue ne s'améliore pas — et peut même légèrement diminuer à mesure que le lot grandit. C'est le compromis central du service par lots : le débit pour l'exploitant face à la latence pour l'utilisateur.
Un lot plus grand est-il toujours préférable ?
Seulement jusqu'à un certain point. Le débit agrégé augmente avec la taille du lot tant que le travail reste limité par la mémoire, mais dès que le lot sature le calcul ou que le cache clé-valeur épuise la mémoire, le temps de complétion croît plus vite que le lot et la latence par requête se dégrade.
Le bon compromis est le plus grand lot qui maintient la latence par requête dans la cible tout en tenant en mémoire, ce que l'on trouve en mesurant le temps de complétion pour plusieurs tailles de lot.
Comment le traitement par lots continu change-t-il la donne ?
Ce calculateur modélise un lot fixe qui démarre et s'achève ensemble. Les serveurs modernes utilisent un traitement par lots continu (en vol), où de nouvelles requêtes rejoignent le lot et les requêtes terminées le quittent à chaque étape, gardant l'accélérateur plein même lorsque les longueurs de séquence diffèrent.
Cela relève le débit agrégé soutenu au-dessus de l'estimation à lot fixe, mais le même compromis demeure : le total de jetons par seconde s'améliore tandis que chaque requête individuelle reste bornée par la vitesse de décodage.
Mentions légales
Les estimations supposent que toutes les requêtes du lot génèrent le même nombre de jetons et démarrent ensemble. Les charges réelles mélangent des longueurs de séquence et utilisent un traitement par lots continu, de sorte que le débit agrégé mesuré différera. Mesurez les performances pour plusieurs tailles de lot sur le matériel cible avant de dimensionner la capacité.
Recommandations
Calculateur de débit d'inférence
Estime la limite de vitesse de décodage d'un LLM imposée par la bande passante mémoire, à partir de la taille du modèle, de la précision des poids et de la bande passante mémoire de l'accélérateur — le plafond en jetons par seconde pour un flux unique.