L’expression « tokens par seconde » nécessite une attention particulière. Elle désigne une unité, et non une métrique complète. Il faut encore savoir quels tokens ont été comptés et quel intervalle de temps a été utilisé.
Ce que mesure chaque métrique
Latence d’inférence
La latence d’inférence correspond au temps écoulé pour une requête. Pour une réponse générée, la « latence de bout en bout » s’étend normalement de l’envoi ou de la réception de la requête à la réception de sa sortie finale.
Elle répond à la question : Combien de temps faut-il avant que cette requête soit terminée ?
Cette limite n’est pas universelle. Une mesure côté client peut inclure le routage, le transfert réseau, la mise en file d’attente et le traitement de la réponse. Un serveur d’inférence peut démarrer son chronomètre après certaines de ces étapes. Un benchmark qui mentionne uniquement la « latence » ne fournit pas suffisamment d’informations pour reproduire le résultat.
La latence dépend aussi directement de la longueur de la sortie. Une réponse concise et une réponse longue peuvent avoir le même TTFT et le même rythme de génération, mais la réponse longue demande davantage de temps avant d’être terminée.
Temps jusqu’au premier token
Le temps jusqu’au premier token, ou TTFT, s’étend de la limite définie pour la requête jusqu’au premier token de sortie non vide d’une réponse diffusée en continu.
Il répond à la question : Combien de temps faut-il avant que la réponse commence à apparaître ?
Le TTFT inclut généralement la mise en file d’attente, le traitement de l’entrée, le travail de préremplissage du modèle sur le prompt, la génération du premier token et le temps réseau compris dans la limite choisie. Il fait partie de la latence de bout en bout et ne constitue pas un autre nom pour celle-ci.
Un TTFT faible donne à une interface une impression de réactivité. Il ne permet pas à lui seul de savoir si le reste de la réponse arrivera de manière fluide ni quand la réponse sera terminée.
Tokens par seconde
Les tokens par seconde correspondent à un nombre de tokens de sortie divisé par un nombre de secondes écoulées. Dans les comparaisons de produits, cela désigne souvent la vitesse de génération d’une requête après l’arrivée du premier token.
Ils répondent à la question : À quelle vitesse le texte généré arrive-t-il une fois la génération lancée ?
Pour une réponse comportant (N) tokens de sortie, il existe (N-1) intervalles entre le premier et le dernier token. Si ces intervalles durent (G) secondes, le débit après le premier token est :
[\n\text{débit de génération par requête} = \frac{N-1}{G}\n]
Il s’agit de l’inverse du temps moyen par intervalle entre tokens de sortie lorsque chaque événement mesuré contient un token. Les API de streaming réelles peuvent transmettre des blocs contenant plusieurs tokens ; le client doit donc compter les tokens plutôt que supposer qu’un événement correspond à un seul token.
Certains outils divisent plutôt le nombre total de tokens de sortie par la latence de bout en bout de la requête. D’autres combinent les tokens de toutes les requêtes concurrentes. Ces choix produisent des nombres différents, même si tous peuvent être désignés par TPS ou tokens/s.
Débit d’inférence
Le débit d’inférence correspond à la quantité totale de travail accomplie par un système par unité de temps dans le cadre d’une charge donnée. Il peut être mesuré en tokens de sortie par seconde, en tokens totaux par seconde, en requêtes par seconde, en échantillons par seconde ou dans une autre unité adaptée à la charge de travail.
Il répond à la question : Quelle charge le système peut-il gérer ?
Le débit est une propriété agrégée. Il nécessite un intervalle de test et un profil de charge. La concurrence, le taux d’arrivée des requêtes, les longueurs des prompts et des réponses, le traitement par lots, le nombre de réplicas et la gestion des requêtes échouées peuvent tous le modifier.
Le débit de requêtes et le débit de tokens ne sont pas interchangeables. Un serveur peut traiter de nombreuses requêtes courtes ou moins de requêtes longues tout en produisant le même nombre de tokens de sortie par seconde.
La distinction réelle
| Metric | Clock stops at | Typical scope | Typical unit | The question it answers |
|---|---|---|---|---|
| Latency | Final response output | One request | ms or s/request | When is this request finished? |
| TTFT | First content token | One streamed request | ms or s/request | When does the answer begin? |
| Tokens per second | Depends on the stated formula | One request or the whole system | output tokens/s | How fast are tokens arriving, and for whom? |
| Throughput | End of a test interval | System or deployment | tokens/s, requests/s, or samples/s | How much work is completed under load? |
Trois questions permettent de lever l’ambiguïté dans presque tous les résultats rapportés :
- Que compte-t-on ? Les tokens de sortie, tous les tokens, les requêtes terminées ou les échantillons ?
- Quand le chronomètre démarre-t-il et s’arrête-t-il ? Lors de l’envoi par le client, de la réception par le serveur, du premier token, du dernier token ou selon des limites fixes du test ?
- Quelle est la portée ? Une requête, un utilisateur, un réplica ou le déploiement complet sous charge concurrente ?
Si un benchmark ne peut pas répondre aux trois questions, son résultat n’est pas prêt à être comparé.
Exemple détaillé
Imaginons une requête qui renvoie 81 tokens de sortie :
- La requête est envoyée à 0,0 seconde.
- Le premier token arrive à 0,8 seconde.
- Le dernier token arrive à 2,8 secondes.
Son TTFT est de 0,8 seconde. Sa latence de bout en bout est de 2,8 secondes. La génération après le premier token s’étend sur 2,0 secondes et comporte 80 intervalles entre tokens ; son débit après le premier token est donc de 40 tokens par seconde.
Si un outil compte les 81 tokens de sortie et les divise par la latence totale de 2,8 secondes, il indique environ 29 tokens par seconde. Il ne s’agit pas d’un désaccord mathématique, mais d’une limite temporelle et d’un numérateur différents.
Plaçons maintenant de nombreuses requêtes sur un même serveur. Pendant une fenêtre de test de 10 secondes, le serveur génère 3 000 tokens de sortie et termine 50 requêtes :
- Débit de tokens de sortie : (3 000 / 10 = 300) tokens par seconde
- Débit de requêtes : (50 / 10 = 5) requêtes par seconde
Les 300 tokens par seconde du serveur correspondent à la sortie combinée des requêtes actives. Un utilisateur individuel peut malgré tout recevoir des tokens à 40 tokens par seconde, ou moins si la charge supplémentaire augmente l’attente en file et les délais de décodage.
Quand chaque métrique est importante
Pour une interface de chat, un assistant de programmation ou toute autre interaction diffusée en continu, le TTFT décrit la pause initiale. Le débit de génération par requête, ou son inverse — le temps par token de sortie — décrit le rythme après cette pause. La latence de bout en bout est importante lorsque l’utilisateur ou un autre programme doit attendre la réponse complète avant de poursuivre.
Pour un traitement par lots, le débit est généralement plus important que le TTFT. Le traitement s’intéresse au taux d’achèvement total, à condition que les échecs et la qualité des sorties restent acceptables.
Pour planifier la capacité, utilisez le débit conjointement avec un objectif de latence. Augmenter la concurrence améliore souvent d’abord le débit global, car le matériel effectue davantage de travail en parallèle. Cette même concurrence peut accroître l’attente en file et ralentir chaque utilisateur. Après saturation, le débit peut plafonner ou diminuer tandis que la latence continue d’augmenter.
Pour une API sans streaming, le TTFT peut ne pas être observable côté client, car la réponse n’est transmise qu’une fois terminée. Le serveur peut toujours mesurer les étapes internes, mais la performance visible par le client est la latence de bout en bout.
Ce que les gens confondent, et pourquoi
Un TTFT faible ne garantit pas une faible latence
Une réponse peut commencer rapidement, puis être générée lentement. Le TTFT ne mesure que la première étape importante. La latence totale inclut également le temps de génération restant.
Avec une définition explicite du temps après le premier token, la relation est la suivante :
[\n\text{latence de bout en bout} = \text{TTFT} + (N-1)\times\text{temps moyen par intervalle entre tokens de sortie}\n]
Les implémentations utilisent des conventions de comptage différentes ; vérifiez donc la formule du benchmark avant de reconstituer une métrique à partir d’une autre.
Les tokens par seconde peuvent correspondre au débit
« Tokens par seconde » désigne parfois le rythme de génération pour un utilisateur. Il peut également s’agir de l’unité du débit agrégé de tokens de sortie. Le libellé seul ne permet pas de les distinguer.
Recherchez des qualificatifs tels que par requête, par utilisateur, par flux, agrégé ou système. Si aucun n’apparaît, examinez la formule et la configuration du test.
Un débit élevé ne garantit pas des requêtes rapides
Un serveur peut traiter de nombreuses requêtes par lots afin de produire davantage de tokens au total chaque seconde, tandis que chaque requête attend plus longtemps ou reçoit les tokens moins fréquemment. C’est pourquoi les tests sérieux de service indiquent le débit avec les percentiles de latence, ou calculent le goodput : le travail accompli tout en respectant un objectif de service défini.
Des charges différentes produisent des résultats différents
Le TTFT varie selon la longueur du prompt et l’attente en file. La latence de bout en bout varie selon la longueur de la réponse. Le débit varie selon la concurrence, le profil d’arrivée, le traitement par lots et l’allocation matérielle. Les débits de tokens dépendent également du tokenizer utilisé pour compter les sorties.
Ne comparez les systèmes qu’avec le même comportement du modèle, les mêmes distributions de prompts et de sorties, le même profil de charge, le même mode de streaming, les mêmes paramètres d’échantillonnage, le même tokenizer, la même limite de mesure et les mêmes critères de réussite. Une requête unique sur un système inactif teste autre chose qu’un serveur saturé.
Les moyennes masquent les requêtes dont les utilisateurs se souviennent
Une moyenne du TTFT ou de la latence peut sembler satisfaisante alors qu’une petite partie des requêtes attend beaucoup plus longtemps dans une file. Présentez une distribution, notamment les percentiles de queue pertinents, et indiquez le nombre d’observations. Pour le débit, indiquez les erreurs et les requêtes rejetées au lieu de compter uniquement le travail réussi sans le préciser.
Comment lire un benchmark d’inférence
Avant de faire confiance à un graphique ou à une affirmation d’une fiche de modèle, vérifiez qu’il précise :
- si les tokens par seconde sont mesurés par requête ou de manière agrégée ;
- s’il compte uniquement les tokens de sortie ou les tokens d’entrée et de sortie ;
- si le TTFT ou le premier token est inclus dans le calcul du débit de tokens ;
- si la latence est mesurée côté client, côté serveur ou uniquement au niveau du modèle ;
- les distributions de longueur des prompts et des sorties ;
- la concurrence et le profil d’arrivée des requêtes ;
- la phase d’échauffement, la durée du test et la gestion des limites de début et de fin ;
- la latence moyenne et de queue, et pas seulement une moyenne unique ;
- les critères concernant les requêtes réussies et les erreurs ;
- le modèle, la précision, le matériel, le moteur et le nombre de réplicas.
La meilleure métrique n’est pas l’une de ces quatre métriques prise isolément. C’est celle qui correspond à l’objectif visible pour l’utilisateur ou à l’objectif opérationnel, mesurée sous une charge réaliste avec toutes les limites clairement indiquées.
Pour aller plus loin
Lisez Qu’est-ce que la latence d’inférence ? pour les limites temporelles d’une requête, Qu’est-ce que le temps jusqu’au premier token ? pour le délai initial d’une réponse diffusée en continu, Que sont les tokens par seconde ? pour les formules de débit de tokens, et Qu’est-ce que le débit d’inférence ? pour la capacité du système sous charge.