Latence en IA : Comprendre et Optimiser le Temps de Réponse des API
Qu’est-ce que la latence exactement ?
La latence, dans le contexte des API d’IA, est le délai entre le moment où vous envoyez votre requête et celui où vous recevez une réponse exploitable. C’est l’équivalent du temps de réflexion du modèle, auquel s’ajoutent les délais réseau et de traitement.
Il faut distinguer deux métriques de latence essentielles :
Le TTFT (Time to First Token) mesure le temps entre l’envoi de la requête et la réception du premier token de la réponse. C’est la métrique la plus importante pour l’expérience utilisateur en mode streaming, car elle détermine le temps d’attente avant que la réponse commence à apparaître.
La latence totale (end-to-end) mesure le temps entre l’envoi et la réception complète de la réponse. Elle dépend directement de la longueur de la réponse et de la vitesse de génération (tokens par seconde).
Les composantes de la latence
La latence totale d’une requête API se décompose en plusieurs phases :
Latence réseau
Le temps de transit aller-retour entre votre serveur et celui du fournisseur. Typiquement 10-100ms selon votre localisation géographique et la région du datacenter. Les fournisseurs utilisent des CDN et des points de présence régionaux pour minimiser cette composante. Depuis la France, la latence réseau vers les API américaines (OpenAI, Anthropic) est de l’ordre de 50-100ms.
Temps de « prefill » (traitement de l’input)
Le modèle doit d’abord traiter tout votre prompt (input) avant de commencer à générer la réponse. Ce temps est proportionnel à la longueur de votre prompt. Pour un prompt de 100K tokens, le prefill peut prendre plusieurs secondes, même sur les modèles les plus rapides. C’est la composante dominante du TTFT pour les longs contextes.
Temps de génération (décodage)
Une fois le prefill terminé, le modèle génère la réponse token par token. La vitesse de génération varie de 20 à 200+ tokens par seconde selon le modèle. Pour une réponse de 1000 tokens à 50 tokens/s, c’est 20 secondes de génération. En mode streaming, les tokens arrivent au fil de l’eau, ce qui améliore l’expérience perçue.
Temps de raisonnement (thinking)
Les modèles en mode « thinking » (GPT-5.4 Thinking, Claude Opus 4.6 avec adaptive thinking) ajoutent une phase de raisonnement interne avant de commencer à générer la réponse visible. Cette phase peut durer de quelques secondes à plusieurs minutes sur des problèmes complexes. C’est un compromis : plus de temps de réflexion produit des réponses de meilleure qualité, au prix d’une latence accrue.
Latence des principaux modèles (mars 2026)
Les valeurs ci-dessous sont des ordres de grandeur pour des requêtes typiques (prompt ~1000 tokens, réponse ~500 tokens, sans mode thinking). La latence réelle varie selon la charge serveur, la région et la longueur du prompt.
| Modèle | TTFT typique | Vitesse génération | Commentaire |
|---|---|---|---|
| GPT-5.4 | 0,5-2s | ~50-80 tok/s | Rapide sur requêtes courtes |
| Claude Opus 4.6 | 1-3s | ~40-60 tok/s | Fast Mode : ~2,5x plus rapide (6x le prix) |
| Claude Sonnet 4.6 | 0,5-1,5s | ~60-100 tok/s | Meilleur compromis latence/qualité |
| Claude Haiku 4.5 | 0,2-0,5s | ~100-150 tok/s | Le plus rapide chez Anthropic |
| Gemini 3.1 Pro | 0,5-2s | ~50-80 tok/s | Variable selon la charge Google |
| Gemini 3 Flash | 0,2-0,8s | ~80-120 tok/s | Conçu pour la vitesse |
| Mistral Large 3 | 0,5-1,5s | ~60-90 tok/s | MoE : rapide malgré 675B params |
| DeepSeek V3.2 | 0,5-2s | ~40-70 tok/s | Variable, serveurs parfois saturés |
Note sur Claude Opus 4.6 Fast Mode : Anthropic propose un mode accéléré (research preview) qui multiplie la vitesse d’output par ~2,5x, facturé à 6x le prix standard ($30 input / $150 output par 1M tokens). C’est une option intéressante pour les applications temps réel où la latence d’Opus est un frein mais où la qualité de Sonnet est insuffisante.
Facteurs qui influencent la latence
La taille du prompt (input)
C’est le facteur le plus important pour le TTFT. Un prompt de 1000 tokens aura un TTFT bien inférieur à un prompt de 500K tokens, car la phase de prefill est proportionnelle à la taille de l’input. Avec la fenêtre de contexte de 1M tokens disponible sur Claude Opus 4.6 et Gemini 3.1 Pro, les prompts très longs peuvent engendrer des TTFT de 10-30 secondes ou plus.
La taille de la réponse (output)
La latence totale est directement proportionnelle au nombre de tokens générés. Claude Opus 4.6 peut générer jusqu’à ~128K tokens en sortie, ce qui à 50 tok/s prendrait plus de 40 minutes. En pratique, limitez le max_tokens à ce dont vous avez réellement besoin.
La charge serveur
La latence augmente significativement pendant les heures de pointe. Les serveurs DeepSeek sont particulièrement sujets à la congestion en raison de leur popularité et de leur infrastructure plus limitée. Les fournisseurs majeurs (OpenAI, Anthropic, Google) disposent d’infrastructures plus élastiques mais ne sont pas immunisés contre les pics.
La localisation géographique
La proximité entre votre serveur et le datacenter du fournisseur impacte la latence réseau. Depuis l’Europe, les API hébergées aux États-Unis ajoutent 50-100ms de latence réseau pure. Google et Anthropic proposent des régions européennes (via Google Cloud et AWS), ce qui réduit ce delta.
Comment réduire la latence
Utilisez le streaming
Le streaming envoie les tokens au fur et à mesure de leur génération au lieu d’attendre la réponse complète. L’utilisateur voit la réponse apparaître progressivement, ce qui améliore l’expérience perçue même si la latence totale reste identique. Toutes les API majeures supportent le streaming via SSE (Server-Sent Events).
Exploitez le prompt caching
Si vos requêtes partagent un préfixe commun (instructions système, contexte), utilisez le prompt caching d’Anthropic ou OpenAI. Le prefill du préfixe caché est quasi-instantané au lieu de devoir être recalculé à chaque requête. Chez Anthropic, le cache read coûte ~0,1x le prix standard. C’est le levier d’optimisation le plus sous-estimé.
Choisissez le bon modèle
Utilisez le modèle le plus léger qui répond à vos exigences de qualité. Pour un chatbot de support client, Claude Haiku 4.5 ou Gemini 3 Flash suffisent souvent et sont 3-5x plus rapides que les modèles flagship. Réservez Claude Opus 4.6 ou GPT-5.4 aux tâches complexes qui nécessitent un raisonnement approfondi.
Parallélisez les requêtes
Si votre application traite plusieurs requêtes indépendantes, envoyez-les en parallèle plutôt que séquentiellement. 10 requêtes en parallèle avec 2s de latence chacune prennent 2s au total, contre 20s en séquentiel. Attention toutefois aux rate limits.
Réduisez la taille du prompt
Chaque token supplémentaire dans le prompt augmente le TTFT. Techniques efficaces : compactez les instructions système, supprimez les informations redondantes, utilisez des exemples concis plutôt que volumineux, et implémentez le RAG pour ne fournir au modèle que les documents pertinents plutôt que tout un corpus.
Latence vs throughput : quelle différence ?
La latence et le throughput sont deux métriques complémentaires mais distinctes. La latence mesure le temps d’une requête individuelle. Le throughput mesure le nombre de requêtes traitées par unité de temps.
Une analogie : la latence est le temps que met une voiture pour faire le trajet Paris-Lyon. Le throughput est le nombre de voitures qui arrivent à Lyon par heure. Une autoroute à 4 voies a un throughput supérieur à une nationale, même si la vitesse de chaque voiture est identique.
En production, vous devez optimiser les deux. Un TTFT de 200ms ne sert à rien si votre rate limit vous restreint à 50 requêtes par minute. Inversement, 10 000 RPM ne compensent pas un TTFT de 15 secondes pour un chatbot temps réel.
Comment mesurer la latence
Pour mesurer et monitorer la latence de vos appels API, instrumentez votre code avec des métriques sur chaque composante : latence réseau (temps de connexion TCP), TTFT (premier byte de la réponse), vitesse de génération (tokens par seconde), et latence totale (dernier byte). Des outils comme Prometheus, Datadog ou LangSmith permettent de collecter et visualiser ces métriques en production.
Mesurez la latence sur des percentiles, pas sur des moyennes. La latence P50 (médiane) est souvent correcte, mais la P99 (99e percentile) peut être 5-10x supérieure. Ce sont les P95 et P99 qui déterminent l’expérience de vos utilisateurs les moins chanceux.
Questions fréquentes sur la latence en IA
Qu’est-ce que le TTFT (Time to First Token) ?
Le TTFT est le temps entre l’envoi de votre requête et la réception du premier token de la réponse. C’est la métrique de latence la plus importante pour l’expérience utilisateur, car elle détermine combien de temps l’utilisateur attend avant de voir la réponse commencer à apparaître. En mode streaming, un bon TTFT (inférieur à 1 seconde) masque efficacement le temps de génération total.
Quel est le modèle IA le plus rapide en 2026 ?
Parmi les modèles de pointe, Claude Haiku 4.5 et Gemini 3 Flash offrent les meilleures latences avec des TTFT inférieurs à 500ms et des vitesses de génération dépassant 100 tokens/seconde. Pour un modèle frontier complet, Claude Sonnet 4.6 offre le meilleur compromis entre qualité et vitesse. Le Fast Mode de Claude Opus 4.6 accélère la génération de ~2,5x mais à un coût 6x supérieur.
Pourquoi la latence augmente-t-elle avec un prompt long ?
Le modèle doit traiter (encoder) tout votre prompt avant de commencer à générer la réponse. Cette phase de « prefill » est proportionnelle au nombre de tokens en entrée. Un prompt de 500K tokens prend beaucoup plus de temps à traiter qu’un prompt de 1000 tokens. Le prompt caching réduit drastiquement cette composante pour les requêtes partageant un préfixe commun.
Comment le streaming réduit-il la latence perçue ?
Le streaming n’accélère pas réellement la génération : la réponse complète arrive au même moment. Mais au lieu d’attendre la fin de la génération pour afficher quoi que ce soit, le streaming affiche chaque token dès qu’il est produit. L’utilisateur voit la réponse se construire en temps réel, ce qui transforme une attente passive de 10 secondes en une lecture progressive de 10 secondes.
La latence est-elle différente entre l’API et l’interface chat ?
Oui. L’interface chat (ChatGPT, Claude.ai, Gemini) ajoute une couche applicative (serveur web, WebSocket, rendu) qui augmente la latence perçue de quelques centaines de millisecondes. L’API offre généralement de meilleures latences brutes car vous contrôlez le pipeline de bout en bout. Pour les applications temps réel, l’API est toujours préférable.