Qu’est-ce que la latence ?
La latence est le délai entre l’envoi d’une requête et la réception du premier élément de réponse. Dans le contexte des LLM, on parle de TTFT (Time to First Token) : le temps avant que le premier token de la réponse soit généré.
La latence est un facteur clé d’expérience utilisateur. En dessous de 500 ms, l’interaction semble fluide. Au-delà de 2 secondes, l’utilisateur perçoit un temps d’attente.
Les composantes de la latence
Le temps total entre la requête et la réponse complète se décompose en plusieurs phases :
1. Latence réseau
Le temps de transit entre le client et le serveur. Il dépend de la distance géographique et de la qualité de la connexion. Un serveur en Europe répond plus vite à un utilisateur européen qu’un serveur aux États-Unis.
Ordre de grandeur : 10-100 ms.
2. Latence de traitement (prefill)
Le temps nécessaire au modèle pour traiter le prompt en entrée avant de commencer à générer. Plus le prompt est long, plus cette phase est longue.
Ordre de grandeur : 100-2 000 ms selon la taille du prompt et du modèle.
3. Temps de génération (decode)
Le temps de génération token par token de la réponse. Chaque token nécessite un passage dans le réseau de neurones. Cette phase détermine le débit (tokens par seconde).
Ordre de grandeur : 20-100 ms par token selon le modèle.
Latence par modèle
| Modèle | TTFT typique | Débit (tokens/s) | Usage recommandé |
|---|---|---|---|
| Claude Haiku 4.5 | 300-500 ms | 100-150 | Chatbot temps réel, classification |
| Claude Sonnet 4.6 | 400-800 ms | 70-100 | Usage polyvalent |
| Claude Opus 4.6 | 800-2 000 ms | 30-50 | Raisonnement complexe |
| GPT-4o mini | 200-400 ms | 100-150 | Tâches légères, haut volume |
| GPT-4o | 400-1 000 ms | 60-80 | Usage polyvalent |
Les valeurs varient selon la charge des serveurs, la taille du prompt et la région.
Latence dans les workflows d’automatisation
Dans un workflow, la latence s’accumule à chaque module :
- Un workflow de 5 modules avec 200 ms de latence chacun = 1 seconde minimum
- Un workflow qui appelle un LLM (1 seconde) + une API externe (300 ms) + un webhook (100 ms) = 1,4 seconde minimum
Pour les workflows déclenchés par un webhook avec réponse attendue (chatbot, formulaire), la latence totale détermine le temps de réponse perçu par l’utilisateur.
Stratégies d’optimisation dans les workflows
- Paralléliser les appels indépendants : si deux modules n’ont pas de dépendance entre eux, les exécuter en parallèle plutôt qu’en séquence
- Répondre d’abord, traiter ensuite : envoyer un accusé de réception immédiat à l’utilisateur, puis effectuer le traitement en arrière-plan
- Mettre en cache les réponses fréquentes : stocker les résultats des requêtes récurrentes pour éviter de rappeler le LLM
Streaming et latence perçue
Le streaming est la technique la plus efficace pour réduire la latence perçue. Au lieu d’attendre la fin de la génération pour afficher la réponse complète, chaque token est envoyé au client dès qu’il est généré.
L’utilisateur voit la réponse se construire en temps réel, ce qui transforme une attente de 5 secondes en une expérience interactive. Le temps total reste identique, mais la perception change radicalement.
Les API d’Anthropic et d’OpenAI supportent nativement le streaming via les Server-Sent Events (SSE). Dans n8n, le nœud AI Agent supporte le streaming pour les chatbots connectés.
Bonnes pratiques
- Mesurer régulièrement : monitorer le TTFT et le temps total en production. Une dégradation soudaine peut indiquer un problème de serveur ou une augmentation de la charge
- Choisir le modèle adapté : ne pas utiliser Opus pour une simple classification quand Haiku fait le travail en 4 fois moins de temps
- Optimiser le prompt : un prompt de 500 tokens sera traité plus vite qu’un prompt de 5 000 tokens. Supprimer le contexte inutile réduit directement le TTFT
- Tester depuis la bonne région : si les utilisateurs sont en Europe, déployer l’infrastructure en Europe pour minimiser la latence réseau
Termes associés
Questions fréquentes
C'est quoi la latence d'une API ?
La latence est le temps écoulé entre l'envoi d'une requête et la réception de la réponse. Pour une API de LLM, c'est le délai avant que le modèle commence à générer sa réponse. Une latence de 200 ms signifie que l'utilisateur attend 0,2 seconde avant de voir le premier token apparaître. Plus la latence est faible, plus l'expérience est fluide.
Quelle est la différence entre latence et temps de réponse total ?
La latence (Time to First Token ou TTFT) mesure le délai avant le premier élément de réponse. Le temps de réponse total inclut la latence plus le temps de génération de l'intégralité de la réponse. Un LLM peut avoir une latence de 500 ms mais un temps total de 10 secondes pour une longue réponse, car chaque token est généré séquentiellement.
Quel modèle LLM a la latence la plus faible ?
Les modèles plus petits ont généralement une latence plus faible. Claude Haiku (300-500 ms TTFT), GPT-4o mini (200-400 ms), et Gemini Flash (200-400 ms) sont parmi les plus rapides. Les modèles premium comme Claude Opus ou GPT-4o sont plus lents (500-2 000 ms TTFT) en raison de leur taille supérieure.
Comment réduire la latence d'un LLM ?
Quatre leviers principaux : utiliser un modèle plus petit quand la tâche le permet (Haiku au lieu d'Opus), réduire la taille du prompt en entrée (moins de tokens à traiter), utiliser le streaming pour afficher les tokens dès leur génération sans attendre la réponse complète, et choisir une région de serveur proche géographiquement.