Latence en IA : quel temps mesure-t-on et pourquoi le jalon de réponse compte

Définition : un intervalle délimité par deux jalons

La latence est le temps écoulé entre un événement initial et un événement final définis à l’avance. Pour interpréter une mesure, il faut connaître ces deux jalons : par exemple, à quel moment une requête est considérée comme commencée et à quel moment une réponse est considérée comme reçue. Sans cette précision, deux chiffres appelés « latence » peuvent désigner des intervalles différents et ne pas être comparables.

Dans une application d’intelligence artificielle, le début pourrait correspondre à la réception d’une requête par un composant donné. La fin pourrait être la disponibilité d’une décision, l’envoi du premier fragment de réponse ou la réponse complète. Il ne faut pas supposer que l’une de ces options constitue toujours la bonne définition : tout dépend de la question posée et de la manière dont le système est instrumenté.

Dans sa définition générale, le portail Interopérable Europe de l’Union européenne décrit la latence comme le délai entre le lancement d’une requête et la réception d’une réponse. Cette définition aide à comprendre l’idée d’un intervalle, mais ne définit pas à elle seule une mesure spécifique pour l’inférence en IA, la génération en streaming ou la réponse perçue par l’utilisateur.

Dans cette fiche, le terme « latence » désigne de manière générale l’intervalle mesuré. Lorsque ses limites sont importantes, elles sont précisées, par exemple « de la réception au premier jeton » ou « de la fin de l’entrée vocale au début audible de la réponse ». Ces formulations sont des propositions pour définir des mesures ; elles ne signifient pas qu’il existe une convention universelle suivie par tous les systèmes.

Quel intervalle peut-on mesurer ?

Un système peut présenter plusieurs jalons utiles au cours d’un même parcours. Pour une requête qui produit du texte, on peut mesurer l’intervalle jusqu’à l’apparition du premier jeton, puis, séparément, celui qui s’écoule jusqu’à la fin de la réponse. Le premier indique quand une partie de la sortie devient disponible ; le second, quand le résultat complet est disponible selon le critère choisi. Ces deux chiffres ne sont pas interchangeables.

Le point de départ peut lui aussi être défini à différents endroits. Commencer le comptage lorsque l’interface reçoit l’action de l’utilisateur ne revient pas à le commencer lorsque le service reçoit la requête. La différence peut inclure des étapes qui ne sont pas prises en compte par une mesure interne au modèle. Une description rigoureuse précise donc le point d’entrée, au lieu de se contenter de parler de « temps de réponse ».

Le temps jusqu’au premier jeton, souvent abrégé en TTFT, peut être utile lorsque l’application affiche progressivement le texte. Le temps jusqu’à la réponse complète peut être plus pertinent si la tâche exige de disposer de tout le contenu avant d’agir. Il s’agit de distinctions opérationnelles utiles à la conception d’une mesure. Les sources disponibles pour cette fiche ne permettent pas d’affirmer qu’il existe une définition universelle du TTFT, ni de fixer une procédure commune à tous les fournisseurs.

Latence d’inférence et latence de bout en bout

La latence d’inférence désigne généralement le temps attribué à l’exécution d’un modèle pour produire une sortie à partir d’une entrée. Cependant, cette expression ne détermine pas à elle seule le point de départ du chronomètre ni les opérations incluses. Une étude peut définir ses limites d’une manière, une plateforme d’une autre. Si la documentation n’en précise pas la portée, le chiffre ne contient pas assez d’informations pour permettre une comparaison.

La latence de bout en bout, en revanche, est mesurée entre un point de départ du parcours de l’application et un résultat observé à un autre point. Selon les limites retenues, elle peut comprendre des étapes antérieures ou postérieures à l’exécution du modèle, comme le transport de la requête, le traitement de l’entrée ou la transmission de la sortie. Cette liste indique les éléments qu’il convient de vérifier ; elle ne signifie pas qu’ils sont tous présents dans chaque système.

La latence perçue par la personne qui utilise le produit ne doit pas non plus être automatiquement assimilée à la latence d’inférence. Pour se rapprocher de son expérience, il faut définir quel événement visible ou audible compte comme une réponse et à partir de quelle action la mesure commence. Si le système affiche le contenu par fragments, le premier signe de réponse et la fin de celle-ci peuvent influer différemment sur cette expérience.

Les recherches sur l’optimisation de la latence dans l’informatique en périphérie peuvent servir de contexte pour comprendre que l’exécution de plusieurs modèles dans ce type d’environnement fait l’objet d’études. Toutefois, l’extrait disponible ne suffit pas à déduire une définition générale de la latence d’inférence, ni à établir que ses limites correspondent à celles d’une application complète.

Trois exemples concrets : définir avant de mesurer

Les cas suivants montrent comment formuler une mesure ; ils ne présentent ni résultats empiriques ni valeurs attendues. Dans chaque cas, les jalons proposés permettent de poser une question précise. Une équipe peut choisir d’autres limites si son objectif diffère, à condition de les expliciter.

Dans une conversation vocale, si l’on veut savoir à quel moment le système commence à répondre, on peut démarrer la mesure à la fin de l’entrée vocale et l’arrêter au début audible de la réponse. Si l’on cherche plutôt à connaître le temps nécessaire pour qu’il ait fini de parler, il faut remplacer l’événement final par la fin de la sortie vocale. Ces deux mesures correspondent à des jalons différents. Pour les interpréter, il faut également préciser quel composant détecte la fin de l’entrée et quel signal marque le début ou la fin de la réponse audible.

Pour la classification de transactions, le début peut être la réception de l’événement par le système chargé de l’évaluer, et la fin, le moment où la décision devient disponible pour le composant qui en a besoin. Cette définition n’oblige pas à inclure toutes les étapes antérieures ou ultérieures : cela dépend de l’objectif, qu’il s’agisse de mesurer le classificateur, un service précis ou le parcours complet de l’application. Sans ces limites, un chiffre ne révèle pas à lui seul à laquelle de ces questions il répond.

Pour la génération de texte en streaming, on peut définir deux intervalles avec le même point de départ — par exemple, la réception de la requête par le service : l’un se termine lorsque le premier jeton est transmis, l’autre lorsque la réponse est terminée. Si un seul est indiqué, il faut préciser lequel. L’extrait disponible de la source consacrée à la latence en IA parle du traitement d’une unité de données ou de l’achèvement d’une tâche, mais ne confirme pas l’existence d’une mesure particulière du premier jeton. Cet exemple doit donc être compris comme une proposition d’instrumentation, et non comme une affirmation attribuée à cette source.

Latence, débit et autres confusions

La latence et le débit ne répondent pas à la même question. La première s’exprime comme la durée d’un intervalle associé à une requête, une tâche ou un événement défini. Le débit sert à décrire une quantité traitée pendant une période, mais les éléments fournis pour cette fiche ne contiennent aucune source qui en établisse les unités ou une définition technique propre aux systèmes d’IA. La distinction présentée ici est donc une orientation conceptuelle, et non la citation d’une norme universelle.

Un système peut traiter de nombreuses requêtes au fil du temps tout en mettant, pour une requête donnée, plus de temps que ce qu’un utilisateur juge acceptable. L’inverse est également possible : une réponse peut arriver rapidement lors d’un test, sans que cela démontre que le système conservera le même comportement sous une charge élevée. Ces scénarios illustrent pourquoi une mesure de durée et une mesure de traitement cumulé ne doivent pas être considérées comme des synonymes.

Le premier jeton n’équivaut pas non plus à la réponse complète. Dans une sortie progressive, ce premier jalon indique à quel moment du contenu commence à être disponible ; il ne précise ni le temps nécessaire pour achever la réponse, ni si son contenu final répond aux besoins de la tâche. De même, une mesure d’inférence ne démontre pas automatiquement le temps d’attente de la personne qui utilise l’application.

Enfin, la latence ne mesure pas la qualité de la réponse. Une sortie rapide peut être incorrecte ou incomplète, et une sortie plus lente n’est pas validée par le seul fait qu’elle a demandé davantage de temps. L’évaluation de la qualité exige d’autres critères ; les sources disponibles ici ne proposent pas de méthode pour l’effectuer.

Comment interpréter un chiffre et quelles sont ses limites

Un chiffre isolé ne caractérise pas le comportement du système pour toutes les tailles d’entrée et de sortie, toutes les conditions réseau, toutes les charges ou toutes les configurations. Il ne permet pas non plus de conclure que la même latence sera observée dans d’autres environnements. Pour en évaluer la portée, il faut d’abord examiner la définition de la mesure et les conditions dans lesquelles elle a été obtenue.

Vérifiez si la documentation précise le point de départ, l’événement final et les étapes incluses. Recherchez ensuite les informations disponibles sur la taille des entrées et des sorties, la charge concurrente, l’environnement d’exécution et toute autre condition déclarée par la source. Si ces détails ne figurent pas dans les documents consultés, ne les déduisez pas : signalez qu’ils ne sont pas précisés.

La manière dont l’observation est résumée compte également. Un enregistrement unique et une distribution fondée sur plusieurs observations ne fournissent pas le même type d’information. Cette fiche recommande de vérifier ce point avant toute comparaison, mais les sources fournies ne prescrivent aucun résumé statistique particulier et ne permettent pas de fixer des seuils d’acceptation.

La littérature citée sur l’optimisation de la latence traite d’un problème technique, mais l’extrait fourni ne détaille pas les conditions d’évaluation. De même, l’article de recherche sur l’exécution de plusieurs modèles en informatique en périphérie est un contexte de recherche pertinent, mais l’extrait ne suffit pas à reconstituer sa définition opérationnelle. Aucune valeur, aucun classement ni aucune règle générale n’est donc tiré de ces extraits.

Concepts associés et erreurs fréquentes

L’inférence est le processus qui consiste à obtenir une sortie du modèle à partir d’une entrée ; la latence d’inférence est le temps attribué à ce processus selon les limites fixées par la personne qui effectue la mesure. Ces termes ne sont pas synonymes : le nom du processus ne précise pas automatiquement l’intervalle chronologique ni les composants qu’il comprend.

Un jeton est une unité pouvant apparaître dans la représentation ou la génération de texte. Dans cette fiche, l’expression « temps jusqu’au premier jeton » désigne un jalon proposé pour mesurer une sortie progressive. Elle ne signifie pas que chaque réponse est transmise jeton par jeton, ni que ce jalon suffit à évaluer l’expérience dans son ensemble.

Le cache de contexte est un concept associé à la réutilisation d’informations contextuelles dans certains flux de traitement. Il ne faut pas le confondre avec une unité de latence : pour lui attribuer un effet sur une mesure précise, il faudrait disposer d’une documentation et de conditions comparables. Les sources fournies ne suffisent ni à quantifier cet effet ni à affirmer qu’il s’applique à tous les services.

L’évaluation de l’IA examine les propriétés d’une sortie ou d’un système au moyen de critères définis. La mesure de la latence peut en faire partie, mais elle ne remplace pas l’évaluation de l’exactitude, de l’utilité ou de la sécurité. Les sources présentées ici ne suffisent pas à établir comment évaluer ces propriétés.

Conseils pratiques pour décrire et comparer les latences

Pour décrire utilement une mesure, indiquez l’événement initial et l’événement final en termes observables, précisez quel composant enregistre chacun d’eux et déclarez les étapes incluses et exclues. Si le jalon est le premier jeton, dites-le ; s’il s’agit de la réponse complète, définissez comment on reconnaît qu’elle est terminée. Évitez l’étiquette générique « réponse » lorsqu’elle peut désigner plusieurs choses.

Ajoutez les conditions d’exécution fournies par la source, comme la charge concurrente ou la taille des entrées et des sorties, et signalez lorsqu’elles ne sont pas disponibles. Précisez si la donnée correspond à une observation ou à un résumé de plusieurs observations. Ne généralisez pas au-delà de la portée documentée.

Pour comparer deux chiffres, vérifiez d’abord qu’ils répondent à la même question et reposent sur des jalons et des conditions suffisamment proches. Si l’un mesure le temps jusqu’au premier jeton et l’autre le temps jusqu’à la fin d’une réponse, présentez-les comme des mesures différentes. Si l’un concerne un composant et l’autre le parcours complet, n’attribuez pas leur différence à un modèle sans éléments supplémentaires.

En résumé, la latence est impossible à interpréter correctement sans contexte : c’est le temps entre deux jalons définis. La pratique la plus sûre consiste à nommer ces jalons, à expliquer ce qui est compris dans l’intervalle et à considérer comme non vérifié tout détail que la documentation consultée ne permet pas d’établir.

Concepts associés