Il s’agit d’une mesure de la capacité du système. Elle ne vous indique pas à quelle vitesse une requête commence ou se termine.
Fonctionnement du débit d’inférence
Le calcul de base est le suivant :
débit = travail terminé ÷ temps écoulé
Le terme « travail » est important. Pour un classificateur d’images, il peut désigner les images traitées. Pour un modèle de langage, il peut désigner les requêtes terminées ou les jetons traités. Un résultat de « 2 000 par seconde » n’a aucun sens tant que vous ne savez pas ce qui a été compté.
Le débit de jetons nécessite une précision supplémentaire. Le débit de jetons d’entrée mesure le traitement des invites. Le débit de jetons de sortie mesure les jetons générés. Le débit total de jetons combine les deux. Ces taux décrivent des travaux différents et ne doivent pas être comparés comme s’il s’agissait de la même métrique.
La limite de mesure est également importante. Un résultat peut couvrir un seul accélérateur, un seul serveur ou un déploiement complet comportant plusieurs répliques. Diviser un résultat à l’échelle du déploiement par le nombre d’accélérateurs peut aider à comparer la capacité par accélérateur, mais uniquement lorsque le modèle et la charge de travail sont par ailleurs équivalents.
Le débit augmente généralement à mesure que davantage de requêtes s’exécutent simultanément. Le système de service peut regrouper les tâches par lots, en utilisant davantage le matériel à chaque étape de traitement. Pour les modèles de langage, le traitement continu par lots peut remplacer une séquence terminée par une séquence en attente, au lieu de conserver l’ensemble du lot jusqu’à la fin de la séquence la plus longue.
Cette amélioration a toutefois une limite. Lorsque le calcul, la mémoire ou une autre ressource partagée est saturé, les requêtes supplémentaires attendent dans une file. Le taux d’arrivée peut continuer d’augmenter, mais le taux d’achèvement cesse de progresser au même rythme. La latence se dégrade alors, même si le débit brut varie peu.
C’est pourquoi un résultat de capacité utile est souvent un « débit soutenable sous une contrainte de latence ». Le benchmark augmente la charge, mesure le travail terminé et vérifie que les limites de temps de réponse sont toujours respectées. La dernière charge conforme est plus utile pour planifier un service en ligne qu’un pic maximal sans contrainte.
Exemple détaillé
Supposons qu’un benchmark envoie le même ensemble d’invites à un serveur exécutant un modèle pendant 60 secondes. Le serveur termine 1 200 requêtes et génère 180 000 jetons de sortie.
- Débit de requêtes :
1 200 ÷ 60 = 20 requêtes par seconde - Débit de jetons de sortie :
180 000 ÷ 60 = 3 000 jetons de sortie par seconde
Il s’agit de deux façons d’observer la même exécution. Le taux de requêtes aide à estimer le nombre d’interactions que le serveur peut terminer. Le taux de jetons tient compte des différences de longueur des réponses que le simple décompte des requêtes ne révèle pas.
Augmentons maintenant la charge proposée à 30 requêtes par seconde. Le serveur en termine 22 par seconde, mais huit requêtes supplémentaires entrent chaque seconde dans la file et l’objectif de latence n’est pas respecté. La charge proposée est de 30 requêtes par seconde. Le débit d’achèvement observé est de 22 requêtes par seconde. Aucun de ces chiffres ne prouve que le service peut gérer durablement 30 requêtes par seconde.
Si 20 requêtes par seconde était la charge testée la plus élevée qui maintenait une file stable tout en respectant l’objectif de latence, alors 20 est la mesure de capacité défendable pour cette charge de travail et cet objectif.
Pourquoi le débit d’inférence est important
Le débit indique à un opérateur quelle quantité de matériel est nécessaire pour répondre à la demande prévue. Il permet également de calculer des mesures de coût telles que le nombre de requêtes terminées par dollar ou le nombre de jetons de sortie par heure-accélérateur.
Pour les traitements hors ligne, un débit plus élevé peut réduire la durée totale de traitement. Pour un service en ligne, un débit suffisant empêche les requêtes entrantes de s’accumuler plus vite que le système ne peut les terminer.
L’objectif dépend du produit. Un pipeline de traitement par lots peut accepter de longues attentes afin de maximiser le travail total. Une application interactive a besoin d’un débit suffisant tout en conservant des temps de réponse individuels réactifs. Une métrique plus stricte, appelée « goodput » ou débit utile, ne compte que le travail qui respecte également les objectifs de latence du service.
Idées reçues courantes
Un débit plus élevé signifie que chaque réponse est plus rapide
Pas nécessairement. Le traitement par lots d’un plus grand nombre de requêtes peut augmenter la production totale du serveur, tandis que chaque requête attend plus longtemps ou reçoit les jetons plus lentement. Le débit décrit l’ensemble du système ; la latence décrit le temps d’attente d’une requête individuelle.
Les jetons par seconde correspondent toujours au débit
« Jetons par seconde » peut désigner soit le débit global de jetons, soit le taux de génération observé par un seul utilisateur. Demandez-vous si le nombre concerne une seule requête ou l’ensemble des requêtes simultanées, et s’il compte les jetons d’entrée, de sortie ou les deux.
Le taux de requêtes est le débit
Le taux de requêtes correspond à ce qui arrive. Le débit correspond à ce qui est terminé. Les deux sont proches uniquement lorsque le système suit le rythme. Si les arrivées dépassent les achèvements, la file s’allonge jusqu’à ce que les requêtes soient retardées, refusées ou abandonnées.
Un seul chiffre de débit suffit pour comparer les systèmes
Le débit dépend du modèle, de la taille des entrées et des sorties, du schéma de traitement par lots ou de concurrence, de l’étendue du matériel, de la fenêtre de mesure et des limites de latence. Si la charge de travail change, le chiffre peut changer même lorsque le système reste identique.
Pour aller plus loin
Lisez « Qu’est-ce que l’inférence en IA ? » pour découvrir le processus dont le débit mesure la capacité. Comparez-le à la « latence d’inférence », qui mesure le temps d’attente, et aux « jetons par seconde », qui désignent souvent la vitesse de génération. Pour une distinction complète, consultez « Latence vs TTFT vs jetons par seconde vs débit ».