LLM Benchmark de latence par cas d'utilisation
We benchmarked 11 top large language models with a total of 1,320 requests, splitting reasoning and non-reasoning models, and measured first-token latency, per-token latency, and overall response time.
Vous trouverez ici des détails sur la façon dont nous avons mesuré la latence.
Temps de réponse de bout en bout par model
LLM résultats du benchmark de latence
Nous présentons séparément les models de raisonnement et les models sans raisonnement. Les models de raisonnement passent plusieurs secondes à réfléchir avant la première réponse visible, il serait donc trompeur de les comparer directement aux models sans raisonnement sur la latence. Certains models changent aussi de comportement selon la tâche : GPT-5.2 répond aux Q&R sans raisonnement, mais raisonne sur les prompts de codage.
Cas de réponse courte (Q&R)
Dans le cas court, ce qui compte est la rapidité à laquelle le premier token de réponse apparaît, car la réponse complète ne fait qu'une phrase ou deux. Les models sans raisonnement se regroupent dans la zone de faible latence :
- claude-opus-4-8: 0,75 secondes
- gpt-5-2: 0,8 secondes
- claude-haiku-4-5: 0,96 secondes
- claude-sonnet-5: 1,5 secondes
- claude-opus-4-7: 2 secondes
Les models de raisonnement étaient plus lents à atteindre le premier mot de réponse même ici, car ils réfléchissent d'abord :
- mimo-v2-5: 1,2 secondes
- minimax-m3: 2,4 secondes
- deepseek-v4-flash: 3,6 secondes
- gemini-3-1-pro-preview: 9 secondes
- hy3-preview: 14,6 secondes
Sur les questions courtes, l'étape de réflexion est surtout du surcoût, car la réponse elle-même est courte.
Cas de réponse longue (génération de code)
Dans le cas long, le délai du premier token importe moins, et le streaming spDans le cas long, le délai du premier token importe moins, et la vitesse de streaming et le temps de réponse total prennent le dessus. claude-haiku-4-5 a dominé les deux, avec un streaming d'environ 180 tokens par seconde et une fin en environ 5,5 secondes. Les autres models sans raisonnement ont terminé en environ 10 à 13 secondes : claude-sonnet-5 à 10 secondes, claude-opus-4-8 à 10.8 et claude-opus-4-7 à 12.7.
Les models de raisonnement ont produit des temps totaux plus longs, car la réflexion et la sortie longue s'additionnent :
- gemini-3-1-pro-preview: 18,5 secondes
- hy3-preview: 23,1 secondes
- deepseek-v4-flash: 24,3 secondes
- minimax-m3: 28,1 secondes
- mimo-v2-5: 35 secondes
Certains diffusent rapidement une fois lancés (hy3-preview tourne à environ 200 tokens par seconde), mais la réflexion initiale maintient un total élevé.
La longueur de sortie a été plafonnée plutôt que laissée ouverte, de sorte que les models ne sont pas comparés sur la verbosité : environ 128 tokens pour les réponses courtes et 1 024 pour les réponses longues. Les models de raisonnement ont reçu un budget supplémentaire au-delà de cette limite pour contenir leurs tokens de réflexion, de sorte que leurs temps de bout en bout reflètent la réflexion plus la réponse, et non une réponse coupée en pleine réflexion.
Réponses courtes par rapport aux réponses longues
Le contraste entre les deux cas est le principal enseignement :
- Dans le cas court, les models les plus rapides ont répondu en moins d'une seconde et l'écart était étroit.
- Dans le cas long, les models sans raisonnement sont restés près de la tête (Haiku le plus rapide à environ 5,5 secondes), tandis que les models de raisonnement ont nettement reculé à 18 à 35 secondes.
- L'ordre au sein du groupe sans raisonnement change également : Haiku était l'un des plusieurs démarreurs en moins d'une seconde sur les prompts courts, mais prend clairement l'avantage sur les longues sorties grâce à sa vitesse de streaming.
Latence au 90 centile
Le schéma principal est que la traîne se multiplie pour les models de raisonnement plutôt que de simplement se décaler. Sur la tâche de codage, MiniMax est passé d'environ 13 secondes à la médiane à 42 secondes au p90, et Hunyuan d'environ 16 à 46 secondes. Le temps supplémentaire est de la réflexion, et la durée de réflexion varie d'une requête à l'autre, de sorte que ces models sont non seulement plus lents mais aussi moins prévisibles.
Quelques points ressortent :
- MiMo est l'exception parmi les models de raisonnement. Il raisonne à chaque requête mais réfléchit brièvement, de sorte que son p90 est resté près de 3,7 secondes. Le raisonnement en soi ne rend pas un model imprévisible ; c'est la quantité de réflexion qui le fait.
- GPT-5.2 ne montre une traîne que là où il raisonne. Sur la Q&R, son p90 était inférieur à 2 secondes, mais sur le codage, où il active le raisonnement, son p90 est monté à environ 11 secondes.
- Les models sans raisonnement sont restés serrés. Haiku 4.5 et Opus 4.8 ont maintenu le p90 dans une fourchette d'environ 2 à 2,5 secondes. Même Sonnet 5, qui s'est élargi sur les longues sorties (environ 4 secondes à la médiane contre 8 au p90), est resté bien en dessous du groupe de raisonnement.
Le point pratique est que la médiane peut le masquer. La médiane de MiniMax sur le codage, environ 13 secondes, n'est pas la pire du groupe, mais son p90 d'environ 42 secondes correspond à Hunyuan, de sorte que sur une mauvaise requête, il est aussi lent que tout ce qui a été mesuré.
LLM raisonnement et son effet sur la vitesse
Les models de raisonnement mettent plus de temps à produire leur premier token de réponse car ils génèrent des tokens de chaîne de pensée internes avant la réponse visible. Cette étape de réflexion est ce qui augmente leur temps jusqu'à la première réponse, passant d'environ une seconde pour les models sans raisonnement à plusieurs secondes ou plus.
Le fait qu'un model raisonne n'est pas toujours fixe. Nous avons détecté le raisonnement par requête à partir du nombre de tokens de raisonnement renvoyés par chaque réponse, puis nous avons regroupé les résultats par tâche. La part des requêtes sur lesquelles chaque model a raisonné :
GPT-5.2 le montre directement : il a répondu aux prompts courts de Q&R sans raisonnement, mais a raisonné sur la plupart des prompts de codage. Pour un model hybride comme celui-ci, « raisonnement » n'est pas une étiquette fixe ; le model décide en fonction de la tâche, et sa latence évolue avec cette décision. C'est pourquoi GPT-5.2 se trouve dans le groupe rapide sur la Q&R mais recule sur le codage.
Nous avons mesuré chaque model dans son état par défaut. Plusieurs sont des hybrides qui peuvent raisonner à la demande, mais sont livrés avec la réflexion désactivée : Claude Opus 4.8, par exemple, prend en charge la réflexion étendue, mais elle est désactivée par défaut, de sorte qu'il n'a jamais produit de tokens de raisonnement lors de nos exécutions et est resté rapide, tout comme les autres models Claude (Opus 4.7, Sonnet 5, Haiku 4.5).
Les autres ont raisonné sur presque chaque requête, ce qui explique pourquoi ils semblent plus lents à la première réponse. Ainsi, « ne raisonne jamais » signifie ici pas par défaut, et non que la capacité est absente. GPT-5.2 se distingue car il a fait ce choix de lui-même, en activant le raisonnement pour les prompts de codage plus difficiles tout en le laissant désactivé pour la Q&R.
Effet de l'endpoint sur la latence pour les LLMs
La latence d'un model hébergé n'est pas seulement le model. Elle inclut également la pile de service du fournisseur, la file d'attente, le chemin réseau et la géographie. Notre liste le montre au sein d'une même ligne de model. Claude Opus 4.8, servi via Google Vertex en Europe, a renvoyé son premier token en environ 0,75 secondes, tandis que Claude Opus 4.7, servi via la propre API de Anthropic, a pris environ 2 secondes.
Il s'agit de versions différentes, donc l'écart n'est pas purement lié à l'endpoint, mais le schéma correspond à un effet bien connu : les mêmes poids peuvent être plusieurs fois plus rapides ou plus lents selon l'endroit et la manière dont ils sont servis. Notre client de mesure s'exécutait en Europe, de sorte que l'endpoint Vertex européen avait un chemin réseau plus court, ce qui explique en partie pourquoi il est arrivé en tête.
Pour voir comment nous avons choisi le fournisseur de chaque model, consultez notre méthodologie de benchmark.
Limite maximale de tokens et models de raisonnement
Pour mesurer la latence équitablement, nous avons fixé une longueur de sortie maximale fixe afin qu'aucun model ne soit récompensé ou pénalisé pour avoir écrit davantage. Ce plafond est le budget de tokens pour l'ensemble de la réponse, et c'est de là que venaient la plupart des échecs :
- Les models de raisonnement consacrent une partie du budget à la réflexion avant que la réponse ne commence.
- Sur les prompts de codage difficiles, certains réfléchissent beaucoup, et de manière imprévisible (MiniMax a utilisé environ 2 500 à 3 700 tokens de réflexion sur un seul prompt).
- Lorsque la réflexion remplit tout le budget, il ne reste plus de tokens pour la réponse et la réponse revient vide.
- Cela a le plus touché MiniMax sur le codage, où la première passe a complété moins de la moitié de ses requêtes.
Le point à retenir est que la limite maximale de tokens est un paramètre à surveiller : fixez-la trop bas et un model de raisonnement peut tout dépenser en réflexion et ne jamais atteindre une réponse. Nous avons augmenté le budget des models de raisonnement, accordé de la marge de réflexion en plus de la longueur de réponse, et réessayé les requêtes échouées. La plupart des lacunes se sont comblées, même si quelques-unes ont encore échoué lorsque la réflexion d'un model a dépassé même le budget plus important.
Ajouter comme source préféréeLLM méthodologie de benchmark de latence
Nous avons évalué 11 models de langage avec 1 320 requêtes, en mesurant la rapidité avec laquelle chaque model répond.
Models
Nous avons pris les cinq models les plus utilisés sur OpenRouter et avons ajouté six autres models actuels par-dessus :
- Sans raisonnement par défaut : Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5, Claude Haiku 4.5, GPT-5.2
- Raisonnement par défaut : DeepSeek V4 Flash, Xiaomi MiMo v2.5, MiniMax M3, Gemini 3.1 Pro, Tencent Hunyuan HY3, Claude Fable 5
Cas d'utilisation et prompts d'exemple
Nous avons utilisé deux cas d'utilisation avec des longueurs d'entrée et de sortie fixes, de sorte que les résultats reflètent la vitesse et non la longueur d'un prompt ou d'une réponse.
- Réponse courte (Q&R) : entrée courte (environ 256 tokens), sortie courte (plafonnée à 128 tokens). Exemple : « Quel est le rôle d'une clé primaire dans une base de données ? »
- Réponse longue (génération de code) : entrée courte (environ 512 tokens), sortie longue (plafonnée à 1 024 tokens). Exemple : « Construisez un téléchargeur d'URL multithread en Python qui prend une liste d'URL d'images et les télécharge simultanément. »
Chaque cas d'utilisation a utilisé 20 prompts, et chaque prompt a été envoyé 3 fois par model, ce qui donne 60 mesures par model et par cas d'utilisation. Nous rapportons la médiane (p50) et le p90.
Ce que nous avons mesuré
Nous avons diffusé chaque réponse et enregistré quand la requête a été envoyée, quand le premier token est arrivé, quand le premier token de réponse est arrivé (après toute réflexion), et quand le dernier token est arrivé. À partir de ces données, nous avons dérivé le temps jusqu'au premier token, le temps jusqu'au premier token de réponse, la latence par token et la vitesse de sortie, ainsi que le temps de bout en bout.
Raisonnement vs non-raisonnement
Chaque réponse renvoie un résumé d'utilisation qui inclut un compte de tokens de raisonnement. Nous avons lu ce compte pour chaque requête et marqué la requête comme raisonnante lorsque le compte était supérieur à zéro et non raisonnante lorsqu'il était nul, au lieu de nous fier à l'étiquette du model. C'est ainsi que nous avons constaté que GPT-5.2 raisonne sur le codage mais pas sur la Q&R.
Comment nous avons choisi les fournisseurs
Le même model est servi par différents fournisseurs à des vitesses différentes, nous avons donc épinglé chaque model à un seul fournisseur au lieu de laisser les requêtes se router librement. OpenRouter répertorie la disponibilité, la latence et le débit de chaque fournisseur, et nous avons utilisé ces chiffres pour choisir. Nous avons écarté tout fournisseur en dessous d'environ 98 pour cent de disponibilité, puis nous avons choisi le plus rapide parmi les autres selon la latence et le débit. Nous avons épinglé ce fournisseur pour chaque requête et journalisé le fournisseur qui a réellement servi chaque réponse pour confirmer que l'épinglage a tenu. Quelques-uns des fournisseurs les plus rapides n'étaient pas accessibles avec notre compte et renvoyaient des erreurs de limite de débit, nous avons donc utilisé le fournisseur le plus rapide qui servait de manière fiable.
Les fournisseurs épinglés étaient Claude Opus 4.8 sur Google Vertex (Europe), Claude Opus 4.7 sur Anthropic, Claude Sonnet 5 et GPT-5.2 sur Azure, Claude Fable 5 et Claude Haiku 4.5 sur Amazon Bedrock, DeepSeek V4 Flash sur Novita, MiMo v2.5 sur DeepInfra, MiniMax M3 sur Together, Gemini 3.1 Pro sur Google Vertex, et Hunyuan HY3 sur GMICloud.
Contrôles
- Toutes les requêtes ont été exécutées depuis une seule région cliente.
- La longueur de sortie a été plafonnée (128 pour le court, 1 024 pour le long) afin que la verbosité ne fausse pas la latence. Les models de raisonnement ont reçu un budget supplémentaire pour la réflexion en plus de cette limite.
- Chaque prompt commençait par un bloc de texte unique pour déjouer la mise en cache des prompts, et nous avons vérifié qu'aucun token d'entrée ne provenait du cache.
- Tous les comptages de tokens utilisent un seul tokenizer afin que la vitesse soit comparable entre les models.
Citez ce benchmark
Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Şipi, Nazlı},
title = {{LLM Benchmark de latence par cas d'utilisation}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/llm-latency-benchmark}},
note = {AIMultiple. Consulté le 6 août 2026}
}Résultats et horodatages de 1.4 mille points de données. Téléchargez les données de synthèse présentées dans les graphiques et les tableaux de cet article sous forme de fichier ZIP contenant 6 fichiers CSV et un README.
Vous voulez les données détaillées derrière ? Rejoindre Premium
Journal des modifications
5 mises à jourRemplacement des plages de latence approximatives par des valeurs de temps précises par modèle dans le benchmark de latence.
La liste des modèles comparés a été remplacée par 11 modèles actuels, raisonneurs et non raisonneurs.
A été étendue la section « Résultats de l'analyse comparative de la latence des LLM » avec des résultats détaillés sur la latence du premier jeton et la latence par jeton.
Le travail de Cem chez AIMultiple a été cité par des publications mondiales de premier plan, notamment Business Insider, Forbes, Morning Brew et Washington Post, par des entreprises mondiales comme Deloitte et HPE, par des ONG comme World Economic Forum et par des organisations supranationales comme European Commission. [1], [2], [3], [4], [5]
Tout au long de sa carrière, Cem a été consultant en technologies, acheteur de technologies et entrepreneur technologique. Il a conseillé des entreprises sur leurs décisions technologiques chez McKinsey & Company et Altman Solon pendant plus de dix ans. Il a également publié un rapport McKinsey sur la digitalisation.
Il a dirigé la stratégie technologique et les achats d'un opérateur télécom, sous la responsabilité du PDG. Il a également dirigé la croissance commerciale de l'entreprise de technologie profonde Hypatos, qui a atteint un revenu récurrent annuel à 7 chiffres et une valorisation à 9 chiffres, passant de 0 à ce résultat en deux ans. Le travail de Cem chez Hypatos a été couvert par des publications technologiques de premier plan comme TechCrunch et Business Insider.
Cem intervient régulièrement lors de conférences technologiques internationales. Il est diplômé de Bogazici University en tant qu'ingénieur informatique et titulaire d'un MBA de la Columbia Business School.
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.