Métriques de latence AI API : TTFT, première réponse et vitesse

La latence d’une AI API n’est pas un chiffre unique. Pour une requête streaming, il faut distinguer l’arrivée des headers upstream, le premier SSE event non vide, le premier contenu ou Action utile, le premier texte visible et la fin de la réponse. Ces étapes répondent à des questions différentes et ne doivent pas toutes s’appeler « TTFT ».

Dans un chat textuel, Time to First Visible Text représente généralement l’expérience utilisateur. Dans un workflow de reasoning ou de Tools, des Function Arguments peuvent constituer une sortie effective plus tôt. La vitesse de génération se mesure après le début de la sortie.

Construire une timeline avant de nommer la métrique

Utilisez une horloge monotone et un seul point d’origine :

t0  le gateway reçoit la requête
t1  il démarre la requête upstream
t2  les headers upstream arrivent
t3  premier SSE event non vide
t4  premier contenu ou Action effectif
t5  premier Text Delta visible
t6  le body upstream se termine ou se ferme
t7  le handler gateway se termine

Tous les jalons n’existent pas pour chaque requête. Une valeur absente doit rester absente, pas devenir zéro.

Champ	Mesure	Limite importante
auth_ms	Authentification	Phase locale
distribution_ms	Sélection de route	Phase locale
body_read_ms	Lecture du request body	Révèle un upload lent
upstream_headers_ms	Début upstream à headers	Origine différente du receipt gateway
first_sse_event_ms	Receipt à premier event	Peut ne contenir que metadata
first_response_ms	Receipt à contenu ou Action utile	Texte, reasoning, Function Arguments
first_text_delta_ms	Receipt à texte visible	Peut être absent
upstream_done_ms	Receipt à fermeture upstream	Une fermeture n’est pas toujours un succès
total_handler_ms	Receipt à fin du relay	Approximation E2E gateway
visible_output_tps	Tokens / fenêtre visible	Diagnostic utilisateur, pas TPS système

Ne soustrayez pas des durées qui n’ont pas la même origine.

TTFT possède plusieurs sens pratiques

Le guide NVIDIA NIM inclut généralement réseau, queue et prompt prefill dans TTFT et exclut les réponses initiales vides. Un stream moderne peut émettre avant le texte : metadata, reasoning, Function Arguments, Tool Input ou heartbeat.

Nom	Définition recommandée	Usage
Time to Headers	Début à headers upstream	Réseau et admission
Time to First Event	Début à premier SSE non vide	Transport uniquement
Time to First Effective Response	Début à contenu ou Action utile	Agents et reasoning
Time to First Visible Text	Début à texte affichable	Expérience chat

Un graphique « TTFT » doit documenter la définition choisie.

Séparer réactivité et vitesse de génération

end_to_end_latency = final_response_time - request_start_time
visible_generation_window = final_response_time - first_visible_text_time
visible_output_tps = output_tokens / visible_generation_window_seconds

Inter-token Latency exclut TTFT et divise généralement le temps restant par output_tokens - 1. Ne comptez pas les SSE events comme des tokens : un event peut en contenir zéro ou plusieurs.

Un texte rapide avec peu de TPS démarre bien puis ralentit ; un texte tardif avec beaucoup de TPS semble bloqué puis finit vite. TPS par utilisateur et throughput agrégé sont également différents.

Reasoning et Tools peuvent précéder le texte

En texte pur, first_response_ms et first_text_delta_ms sont proches. Des Function Arguments à 1,8 s et du texte à 6,4 s indiquent une Action utile précoce mais aucune prose visible avant 6,4 s.

• un terminal agent peut mesurer First Effective Action ;
• une UI textuelle doit mesurer First Visible Text ;
• une Tool API peut ne jamais produire de texte ;
• un SSE envelope précoce prouve la connexion, pas un progrès utile.

Le guide AI API Streaming couvre parsing, Cancellation et Idle Timeout. Les métriques doivent suivre les limites du parser.

Diagnostiquer les étapes dans un ordre fixe

Symptôme	Métrique	Vérifier
Lent avant headers	upstream_headers_ms	Réseau, admission, queue, route, région
Headers rapides, sortie tardive	first_response_ms	Queue modèle, prefill, reasoning, inflight
Event rapide, sortie tardive	Gap SSE→Response	Metadata, heartbeat, démarrage reasoning
Action rapide, texte tardif	Gap Response→Text	Tool/reasoning, composition
Texte rapide, génération lente	visible_output_tps	Decode, contention, long contexte
Upstream normal	Champs locaux	Auth, policy, upload client

Aucune métrique ne prouve seule la cause. Route, région, fournisseur et charge doivent être combinés.

Lire trois traces synthétiques

Trace A : attente des headers

Métrique	Valeur
upstream_headers_ms	6 100 ms
first_response_ms	6 350 ms
first_text_delta_ms	6 400 ms
total_handler_ms	9 200 ms
visible_output_tps	42

La majorité de l’attente précède les headers. Examinez route, admission, réseau, région et charge avant l’interface.

Trace B : Action avant texte visible

Métrique	Valeur
upstream_headers_ms	240 ms
first_response_ms	2 900 ms
first_text_delta_ms	8 700 ms
total_handler_ms	10 200 ms
visible_output_tps	55

Une Action existe à 2,9 s mais le texte attend encore 5,8 s. Inspectez reasoning ou Tools ; allonger le header timeout ne corrige rien.

Trace C : début rapide, génération lente

Métrique	Valeur
upstream_headers_ms	260 ms
first_response_ms	420 ms
first_text_delta_ms	430 ms
total_handler_ms	20 430 ms
visible_output_tps	9,8

Le texte arrive vite mais la génération dure près de 20 s. Comparez longueur, contexte, channel, inflight et fournisseur. Un first-output timeout ne détecte pas ce cas.

Comparer uniquement dans des conditions contrôlées

Enregistrez modèle et route, distributions de tokens, streaming, reasoning effort, Tools, région, Network Path, concurrency, sampling, Max Output, warmup, retry policy, échantillon et méthode de percentile.

Comparez p50, p95 et p99, pas une moyenne isolée. Gardez timeouts et erreurs visibles. Des prompts, longueurs ou concurrences différentes ne forment pas un classement de vitesse de modèles.

Conserver la metadata, pas le contenu

Request ID, timestamp, model, group, channel reference, status, token counts, timing fields, event counts, inflight, région approximative et classificateur comme upstream_headers_slow suffisent souvent.

Prompts, réponses, API Keys et identités en clair ne sont pas nécessaires. Appliquez rétention et Access Control à la metadata.

Commencez par la timeline, utilisez Reliable AI API Routing pour comparer les Attempts et AI API Error Troubleshooting pour relier le statut final. On sépare ainsi admission, model startup, reasoning/Tools, génération visible et overhead local.