La latence dans les systèmes d'IA se décompose en plusieurs composantes distinctes, et comprendre chacune aide à diagnostiquer ce qui est réellement lent. D'abord, il y a la latence réseau — le temps aller-retour pour que votre requête atteigne le serveur du fournisseur et que les premiers octets de la réponse reviennent. C'est typiquement de 20 à 100 ms selon votre distance géographique du centre de données. Ensuite, il y a le temps d'attente en file — combien de temps votre requête attend avant qu'un GPU soit disponible pour la traiter. Pendant les heures de pointe ou pour les modèles populaires, cela peut aller de zéro à plusieurs secondes. Puis vient le temps de prefill — le modèle traite votre prompt d'entrée complet. Pour un prompt de 1 000 tokens sur un grand modèle, cela pourrait prendre de 200 à 500 ms. Enfin, le décodage commence et vous obtenez votre premier token. Le total de toutes ces étapes est votre TTFT (Time to First Token).
Après l'arrivée du premier token, il y a une deuxième métrique de latence tout aussi importante : la latence inter-token, ou la rapidité avec laquelle les tokens suivants arrivent en streaming. Cela se mesure typiquement en tokens par seconde. GPT-4o pourrait diffuser à 80-100 tokens/seconde, tandis que Claude diffuse à des vitesses similaires pour la plupart des requêtes. Pour un chatbot, tout ce qui dépasse environ 30 tokens/seconde semble « instantané » pour un lecteur humain — plus rapide que ce qu'on peut lire. En dessous de 15 tokens/seconde, le streaming commence à paraître saccadé. C'est pourquoi les fournisseurs citent parfois à la fois le TTFT et les tokens/seconde — ils mesurent des goulots d'étranglement différents de l'expérience utilisateur. Une réponse pourrait commencer rapidement mais diffuser lentement, ou prendre un moment à démarrer mais ensuite filer.
La longueur du prompt a un impact plus important sur la latence que la plupart des développeurs ne l'anticipent. La phase de prefill évolue de manière grossièrement quadratique avec la longueur de l'entrée pour les modèles Transformer standards (à cause de l'auto-attention), donc un prompt de 10 000 tokens ne prend pas simplement 10 fois plus longtemps qu'un prompt de 1 000 tokens — cela peut prendre significativement plus. C'est pourquoi les fournisseurs comme Anthropic facturent différemment les tokens d'entrée et de sortie, et pourquoi injecter toute votre base de code dans une fenêtre de contexte a de réelles conséquences sur la performance. Des techniques comme la mise en cache de prompt aident énormément ici : la fonctionnalité de mise en cache de prompt d'Anthropic permet de marquer une portion de votre prompt comme cacheable, de sorte que si vous envoyez le même prompt système à chaque requête (ce que font la plupart des applications), le prefill de cette portion est essentiellement gratuit après le premier appel.
L'erreur la plus courante des développeurs avec la latence est de tester avec des prompts courts pendant le développement et d'être ensuite surpris par la performance en production. Un prompt de test de 50 tokens répond en 300 ms ; le vrai prompt de production avec un message système, des exemples few-shot et un historique de conversation totalisant 4 000 tokens répond en 2 secondes. L'autre piège est le routage géographique — si votre serveur est en Europe mais que vous appelez un endpoint API basé aux États-Unis, vous ajoutez 100-150 ms de latence réseau à chaque requête. Certains fournisseurs offrent des endpoints régionaux, et les services de proxy d'inférence plus intelligents routeront votre trafic vers le centre de données le plus proche automatiquement. Pour les applications en temps réel comme les assistants vocaux, où la latence totale de bout en bout doit rester sous 500 ms, chacune de ces composantes compte et on finit par les optimiser toutes simultanément.