Pendant l’inférence, un modèle peut renvoyer un résultat unique, comme un score de fraude, ou diffuser un résultat progressivement, comme du texte généré. Une prédiction unique possède généralement un point d’achèvement évident. Ce n’est pas le cas d’une réponse diffusée en continu : la première sortie visible et la réponse terminée arrivent à des moments différents.
Comment mesure-t-on la latence d’inférence ?
Commencez par définir la limite de mesure.
La latence du modèle
La latence du service
La latence de bout en bout
Ces appellations ne sont pas parfaitement standardisées. La « latence du modèle » d’une plateforme peut inclure des opérations qu’une autre plateforme comptabilise comme des frais généraux. Les horodatages font donc partie de la définition. « De l’envoi par le client à la réception de la réponse finale » est comparable ; « la latence était de 800 ms » ne l’est pas.
Pour un modèle de langage qui diffuse du texte, le chronomètre peut également s’arrêter à différents événements de sortie :
- Temps jusqu’au premier token (TTFT) se termine lorsque le premier token de sortie est reçu. Il indique à quelle vitesse une réponse commence à apparaître.
- La latence de bout en bout de la requête, parfois appelée temps jusqu’au dernier token, se termine lorsque la réponse complète est reçue.
- La latence inter-tokens (ITL) mesure les intervalles entre des tokens de sortie successifs après le début de la génération. Certains outils l’appellent le temps moyen par token de sortie.
Selon une convention courante :
latence de bout en bout = TTFT + temps de génération
Si une réponse contient n tokens de sortie, sa latence inter-tokens moyenne après le premier token est la suivante :
(latence de bout en bout - TTFT) / (n - 1)
Le dénominateur est n - 1 parce que n tokens comportent autant d’intervalles après le premier token. Vérifiez la définition utilisée par l’outil avant de comparer les résultats. Certains outils incluent l’attente du premier token dans une moyenne par token, tandis que d’autres l’excluent.
Exemple détaillé
Supposons qu’un client enregistre les horodatages suivants pour une réponse diffusée en continu hypothétique :
- Requête envoyée :
0 ms - Premier token de sortie reçu :
450 ms - Dernier token de sortie reçu :
1 400 ms - Longueur de la sortie :
20 tokens
Le TTFT observé par le client est de 450 ms. La latence de bout en bout est de 1 400 ms. La génération après le premier token prend 950 ms, réparties sur 19 intervalles entre tokens :
950 ms / 19 = 50 ms
La même requête présente donc une latence de 450 ms jusqu’au premier token, une latence inter-tokens moyenne de 50 ms et une latence d’achèvement de 1,40 s. Aucun de ces chiffres ne remplace les autres.
Supposons maintenant que le serveur de modèle signale 720 ms de traitement dans le conteneur du modèle. Cela ne prouve pas que les 680 ms restantes correspondent à la latence réseau. Les chronomètres du client et du serveur peuvent couvrir des étapes qui se chevauchent ou dont les définitions diffèrent. Pour expliquer l’écart, il faut des horodatages alignés concernant la mise en file d’attente, le prétraitement, l’exécution du modèle, le post-traitement et le transfert réseau.
Ce qui modifie la latence d’inférence
La latence est le résultat d’un test complet, et non une propriété permanente d’un modèle. Elle varie selon les facteurs suivants :
- La forme et la taille de l’entrée. Une entrée plus volumineuse peut nécessiter davantage de prétraitement et de calculs du modèle.
- La forme et la taille de la sortie. Une réponse générée plus longue nécessite davantage d’étapes de génération séquentielles.
- Le trafic et la concurrence. Les requêtes peuvent attendre que des ressources se libèrent lorsque d’autres opérations utilisent les mêmes ressources de service.
- Le traitement par lots et la planification. Regrouper les requêtes peut améliorer l’efficacité globale du système tout en faisant attendre une requête individuelle.
- Le matériel et les logiciels de service. Les accélérateurs, la précision numérique, les transferts en mémoire, les kernels et les moteurs d’inférence influent sur le temps d’exécution.
- L’état chaud ou froid. Une requête peut être plus lente si le code, les données du modèle ou les caches ne sont pas prêts.
- Les étapes applicatives. La recherche documentaire, les contrôles de sécurité, les outils et le post-traitement peuvent ajouter un délai perceptible par l’utilisateur en dehors du modèle.
- Le réseau et l’emplacement du client. Une évaluation côté serveur n’inclut pas chaque saut observé par un utilisateur distant.
Pour le texte généré, la longueur de l’entrée tend à influer sur l’attente avant le début de la sortie, tandis que la longueur de la sortie influe fortement sur le moment où la réponse se termine. La diffusion en continu peut rendre l’interface plus réactive en affichant plus tôt une sortie partielle, mais elle ne garantit pas à elle seule une latence d’achèvement plus faible.
Pourquoi la moyenne ne suffit pas
Un service en production traite des requêtes de tailles différentes, sous une charge variable. Une seule moyenne résume cette distribution et peut masquer les requêtes dont l’attente est la plus longue.
La latence est souvent présentée sous forme de percentiles. Une latence d’achèvement p95 est la valeur en dessous de laquelle ou à laquelle 95 % des requêtes mesurées se sont terminées. Les 5 % restantes ont pris plus de temps. Le p50 décrit la requête médiane, tandis que le p95 ou le p99 révèle davantage la longue traîne des requêtes lentes.
Chaque percentile communiqué nécessite néanmoins un contexte. Au minimum, indiquez les éléments suivants :
- Limite : du client au premier token, du client au résultat final ou intervalle côté serveur nommé.
- Charge de travail : modèle, distribution des entrées, distribution des sorties et paramètres des requêtes.
- Niveau de charge : concurrence ou mode d’arrivée des requêtes.
- Statistique : p50, p95, p99, moyenne ou valeur par requête.
Par exemple, « latence p95 du client au résultat final pour cette charge de travail avec 20 requêtes simultanées » constitue une mesure exploitable. Une valeur plus faible obtenue avec un autre mélange d’invites ou avec une seule requête simultanée ne prouve pas que le système de production est plus rapide.
Pourquoi la latence d’inférence est importante
La latence détermine le temps d’attente d’une requête. Le point d’arrêt pertinent dépend du produit.
Une interface interactive peut surtout s’intéresser à la première sortie visible. Un classificateur exécuté en arrière-plan s’intéresse à la prédiction terminée. Un système en plusieurs étapes ne peut commencer l’étape dépendante suivante tant que le résultat précédent n’est pas terminé ; la latence d’achèvement peut donc s’accumuler au fil de la séquence.
La latence interagit également avec le débit, qui mesure la quantité de travail qu’un système termine au cours d’une période donnée. Augmenter la taille des lots ou la concurrence peut accroître le débit total tout en augmentant l’attente de chaque requête. Un système peut donc traiter davantage de tokens par seconde au total et sembler malgré tout plus lent pour un utilisateur individuel.
Idées reçues courantes
« La latence d’inférence » désigne toujours le temps d’exécution du modèle. Ce n’est pas le cas. Le terme est également utilisé pour désigner des mesures au niveau du service et des mesures observées par le client. Recherchez la limite de mesure.
Le temps jusqu’au premier token correspond à la latence de réponse. Il s’agit d’une étape de la réponse. Un premier token rapide peut être suivi d’une longue génération.
La diffusion en continu accélère la fin de l’inférence. La diffusion en continu modifie le moment où les résultats partiels sont transmis. Elle peut améliorer la réactivité perçue même si le résultat final arrive au même moment.
Un modèle possède une seule valeur de latence. Le résultat dépend des entrées, des sorties, de la charge, du matériel, des logiciels et de la statistique communiquée.
Un débit total de tokens par seconde plus élevé signifie une latence plus faible. Le débit agrégé et le temps d’attente par requête peuvent évoluer en sens opposés.
Pour aller plus loin
Utilisez le temps jusqu’au premier token lorsque le début d’une réponse diffusée en continu est important. Utilisez tokens par seconde pour décrire le rythme de génération, et le débit d’inférence pour décrire la capacité totale de service. Pour une distinction côte à côte, consultez latence vs. TTFT vs. tokens par seconde vs. débit.