Fonctionnement du TTFT

La mesure du TTFT nécessite deux horodatages :

TTFT = heure de la première sortie − heure de début de la requête

La formule est simple. Le choix des horodatages ne l’est pas.

Un TTFT observé par le client commence lorsque celui-ci envoie la requête et s’arrête lorsqu’il reçoit le premier token contenant du contenu ou le premier fragment diffusé. Cet intervalle peut inclure :

  1. L’envoi de la requête au service.
  2. L’authentification, le routage et la mise en file d’attente.
  3. La conversion du prompt en tokens.
  4. Le traitement du prompt complet, une étape appelée préremplissage.
  5. La sélection du premier token de sortie.
  6. La conversion et le renvoi de cette sortie au client.

Pendant le préremplissage, le modèle traite l’entrée et prépare les informations d’attention stockées qu’il réutilisera lors de la génération des tokens suivants. Les prompts plus longs nécessitent généralement davantage de travail de préremplissage. Un service très sollicité peut ajouter une attente en file avant le début de ce travail.

Un TTFT mesuré au niveau du moteur peut utiliser des limites plus restreintes. Par exemple, la métrique serveur de vLLM commence à l’arrivée dans le frontend, actuellement au début de la tokenisation. Elle n’inclut donc pas le trajet réseau du client ni le travail effectué par une application en amont.

C’est pourquoi le TTFT ne constitue pas une valeur universellement comparable. La documentation de référence de NVIDIA le définit entre la soumission de la requête et la réception du premier token. Le glossaire de Google Cloud le décrit entre le moment où le modèle reçoit le prompt et celui où il produit le premier token. Ces deux conventions sont utiles, mais elles mesurent des portions différentes de la requête.

Exemple détaillé

Supposons qu’une requête diffusée suive cette chronologie :

  • 0 ms : le client envoie le prompt et démarre son chronomètre.
  • 40 ms : le service reçoit la requête.
  • 110 ms : la mise en file se termine et le traitement commence.
  • 350 ms : le traitement du prompt se termine et le premier token est généré.
  • 390 ms : le client reçoit le premier fragment contenant du contenu.

Le TTFT observé par le client est de 390 ms.

Une mesure serveur qui commence à l’arrivée de la requête et s’arrête lorsque le token est généré est de 310 ms : 350 ms moins 40 ms.

La différence de 80 ms vient du périmètre de mesure. Elle ne signifie pas que l’un ou l’autre chronomètre est inexact.

Le même exemple montre également pourquoi il ne faut pas considérer le TTFT comme la latence totale. La génération se poursuit après 390 ms. Les intervalles entre les tokens suivants et le délai jusqu’au dernier token sont des mesures distinctes.

Quand et pourquoi le TTFT est important

Le TTFT est particulièrement important lorsque la sortie peut être utilisée dès qu’elle commence à arriver. Les interfaces de chat, les assistants de programmation et les systèmes de génération de texte en temps réel peuvent afficher une progression dès la réception du premier contenu. Un TTFT plus court réduit la pause silencieuse avant ce retour.

Il est moins important en lui-même lorsque l’application doit attendre la réponse complète. Une tâche de synthèse par lots, par exemple, peut davantage s’intéresser au temps total d’exécution ou au débit global.

Utilisez le TTFT pour analyser le début d’une requête. Une valeur élevée peut indiquer un prompt long, une occasion manquée d’utiliser le cache de prompts, une mise en file sous forte charge, un worker froid, une surcharge du frontend ou une distance réseau importante. Le TTFT seul ne permet pas de déterminer quelle étape est responsable. Associez-le à des traces ou à des mesures distinctes de la mise en file, du préremplissage et du réseau.

Pour comparer des systèmes, gardez la charge de travail constante. Utilisez la même distribution de longueur des prompts, le même état du cache, le même niveau de concurrence, le même comportement de diffusion, le même emplacement du client et les mêmes événements de début et de fin. Présentez une distribution, par exemple la médiane et les percentiles de queue, plutôt qu’une seule requête exceptionnellement rapide. La méthodologie de référence de MLCommons utilise pour cette raison des scénarios définis et traite séparément le TTFT de la phase de prompt et le temps de la phase de génération.

Idées reçues courantes

Un TTFT faible ne signifie pas que la réponse complète est rapide. Un système peut démarrer rapidement puis générer lentement. Un autre peut démarrer lentement et produire rapidement le reste de la sortie.

La diffusion ne réduit pas automatiquement le temps de calcul du modèle. Elle permet au client d’observer une sortie partielle avant la fin de la réponse. La mise en tampon dans un serveur, un proxy ou un client peut allonger le TTFT observé même lorsque le modèle génère son premier token au même moment.

Le premier fragment ne correspond pas toujours à un seul token. Les protocoles de diffusion peuvent regrouper plusieurs tokens dans un même événement. Les événements vides ou les métadonnées ne doivent pas arrêter le chronomètre si l’objectif est de mesurer le moment où une sortie utilisable apparaît.

Il n’existe pas de TTFT « bon » indépendamment du contexte. La longueur du prompt, la charge, le matériel, la mise en cache, le trajet réseau et les limites de mesure modifient tous le résultat. Une cible doit préciser la charge de travail et le percentile auquel elle s’applique.

Pour aller plus loin

Lisez Qu’est-ce que la latence d’inférence ? pour situer le TTFT dans la chronologie complète d’une requête. Lisez Que sont les tokens par seconde ? pour connaître le débit de génération après l’arrivée du premier token. Pour comparer l’attente initiale, la vitesse de génération et la capacité du système, consultez Latence vs. TTFT vs. tokens par seconde vs. débit.