LLM Benchmark de latence par cas d'utilisation
Nous avons benchmarké 11 grands modèles de langage avec un total de 1,320 requêtes, en séparant les modèles de raisonnement des modèles sans raisonnement, et nous avons mesuré la latence du premier token, la latence par token, et le temps de réponse global.
LLM benchmark de latence
Vous pouvez trouver des détails sur la façon dont nous avons mesuré la latence ici.
Temps de réponse de bout en bout par modèle
LLM résultats du benchmark de latence
Nous présentons séparément les modèles de raisonnement et les modèles sans raisonnement. Les modèles de raisonnement passent plusieurs secondes à réfléchir avant la première réponse visible, il serait donc trompeur de les comparer directement sur la latence aux modèles sans raisonnement. Certains modèles changent également de comportement selon la tâche : GPT-5.2 répond aux Q&A sans raisonnement mais raisonne sur les prompts de codage.
Cas de réponse courte (Q&A)
Dans le cas court, ce qui compte est la rapidité avec laquelle le premier token de réponse apparaît, car la réponse entière ne fait qu'une ou deux phrases. Les modèles sans raisonnement se regroupent dans la région 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 modèles de raisonnement ont mis plus de temps à 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 des questions courtes, l'étape de réflexion est principalement du surcoût, puisque 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 spIn le délai du premier token dans le cas long importe moins, et la vitesse de streaming et le temps de réponse total prennent le dessus. claude-haiku-4-5 a mené les deux, diffusant à environ 180 tokens par seconde et terminant en environ 5.5 secondes. Les autres modèles 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 modèles 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 qu'ils commencent (hy3-preview s'exécute à environ 200 tokens par seconde), mais la réflexion initiale maintient le total élevé.
La longueur de la sortie a été plafonnée plutôt que laissée ouverte, de sorte que les modèles 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 modèles 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 plutôt qu'une réponse coupée en pleine réflexion.
Réponses courtes versus réponses longues
Le contraste entre les deux cas est le principal enseignement :
- Dans le cas court, les modèles plus rapides ont répondu en moins d'une seconde et l'écart était étroit.
- Dans le cas long, les modèles sans raisonnement sont restés en tête (Haiku le plus rapide à environ 5.5 secondes), tandis que les modèles de raisonnement ont été bien derrière à 18 à 35 secondes.
- L'ordre au sein du groupe sans raisonnement change également : Haiku était l'un des plusieurs démarreurs en dessous d'une seconde sur les prompts courts, mais se détache nettement sur les sorties longues en raison de sa vitesse de streaming.
Latence au 90th percentile
Le schéma principal est que la queue se multiplie pour les modèles 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 dû à la réflexion, et la durée de réflexion varie d'une requête à l'autre, de sorte que ces modèles sont non seulement plus lents mais aussi moins prévisibles.
Quelques points se démarquent :
- MiMo est l'exception parmi les modèles de raisonnement. Il raisonne à chaque requête mais réfléchit brièvement, donc son p90 est resté proche de 3.7 secondes. Le raisonnement en lui-même ne rend pas un modèle imprévisible ; c'est la quantité de réflexion qui le fait.
- GPT-5.2 ne montre une queue que là où il raisonne. Sur Q&A, son p90 était inférieur à 2 secondes, mais sur le codage, où il active le raisonnement, son p90 est monté à environ 11 secondes.
- Les modèles sans raisonnement sont restés serrés. Haiku 4.5 et Opus 4.8 ont maintenu le p90 dans environ 2 à 2.5 secondes. Même Sonnet 5, qui s'est élargi sur les sorties longues (environ 4 secondes à la médiane à 8 au p90), est resté bien en dessous du groupe de raisonnement.
Le point pratique est que la médiane peut masquer cela. La médiane de MiniMax en codage, environ 13 secondes, n'est pas la pire du groupe, mais son p90 d'environ 42 secondes rejoint Hunyuan, donc 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 modèles de raisonnement mettent plus de temps à produire leur premier token de réponse car ils génèrent des tokens internes de chaîne de pensée avant la réponse visible. C'est cette étape de réflexion qui augmente leur temps jusqu'à la première réponse, d'environ une seconde pour les modèles sans raisonnement à plusieurs secondes ou plus.
Le fait qu'un modèle raisonne n'est pas toujours fixe. Nous avons détecté le raisonnement par requête à partir du nombre de tokens de raisonnement retournés par chaque réponse, puis regroupé les résultats par tâche. La part des requêtes sur lesquelles chaque modèle a raisonné :
GPT-5.2 le montre directement : il a répondu aux prompts courts de Q&A sans raisonnement, mais a raisonné sur la plupart des prompts de codage. Pour un modèle hybride comme celui-ci, « raisonnement » n'est pas une étiquette fixe ; le modèle décide en fonction de la tâche, et sa latence change avec cette décision. C'est pourquoi GPT-5.2 se trouve dans le groupe rapide sur Q&A mais recule sur le codage.
Nous avons mesuré chaque modèle 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, donc il n'a jamais produit de tokens de raisonnement lors de nos exécutions et est resté rapide, tout comme les autres modèles Claude (Opus 4.7, Sonnet 5, Haiku 4.5).
Les autres ont raisonné sur presque toutes les requêtes, ce qui explique pourquoi ils semblent plus lents à la première réponse. Donc « ne raisonne jamais » signifie ici pas par défaut, non pas que la capacité est absente. GPT-5.2 se distingue car il a fait ce choix par lui-même, activant le raisonnement pour les prompts de codage plus difficiles tout en le laissant désactivé pour Q&A.
Effet de l'endpoint sur la latence pour les LLMs
La latence d'un modèle hébergé ne dépend pas seulement du modèle. Elle inclut également la pile de service du fournisseur, la mise en file d'attente, le chemin réseau et la géographie. Notre liste le montre au sein d'une même ligne de modèle. Claude Opus 4.8, servi via Google Vertex en Europe, a retourné son premier token en environ 0.75 secondes, tandis que Claude Opus 4.7, servi via l'API propre d'Anthropic, a pris environ 2 secondes.
Il s'agit de versions différentes, donc l'écart n'est pas purement dû à 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 où et comment ils sont servis. Notre client de mesure tournait en Europe, donc l'endpoint Vertex européen avait un chemin réseau plus court, ce qui explique en partie pourquoi il est sorti en tête.
Pour savoir comment nous avons choisi le fournisseur pour chaque modèle, lisez notre méthodologie de benchmark.
Limite maximale de tokens et modèles de raisonnement
Pour mesurer la latence de manière équitable, nous avons défini une longueur maximale de sortie fixe afin qu'aucun modèle ne soit récompensé ou pénalisé pour avoir écrit plus. Ce plafond est le budget de tokens pour la réponse entière, et c'est de là que proviennent la plupart des échecs :
- Les modèles de raisonnement dépensent une partie du budget en réflexion avant que la réponse ne commence.
- Sur des 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ù le premier passage a terminé moins de la moitié de ses requêtes.
L'enseignement est que la limite maximale de tokens est un paramètre à surveiller : si on la fixe trop bas, un modèle de raisonnement peut dépenser tout en réflexion et ne jamais atteindre une réponse. Nous avons augmenté le budget pour les modèles de raisonnement, donné de la marge pour la réflexion en plus de la longueur de réponse, et réessayé les requêtes échouées. La plupart des lacunes ont été comblées, bien que quelques-unes aient encore échoué lorsque la réflexion d'un modèle dépassait même le budget plus important.
Ajouter comme source préféréeLLM méthodologie du benchmark de latence
Nous avons benchmarké 11 modèles de langage avec 1,320 requêtes, mesurant la rapidité de réponse de chaque modèle.
Modèles
Nous avons pris les cinq modèles plus utilisés sur OpenRouter et y avons ajouté six modèles récents supplémentaires :
- Sans raisonnement par défaut : Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5, Claude Haiku 4.5, GPT-5.2
- Avec 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 exemples de prompts
Nous avons utilisé deux cas d'utilisation avec des longueurs d'entrée et de sortie fixes, afin que les résultats reflètent la vitesse et non la longueur d'un prompt ou d'une réponse :
- Réponse courte (Q&A) : entrée courte (environ 256 tokens), sortie courte (plafonnée à 128 tokens). Exemple : « Quel est l'objectif 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 modèle, donnant 60 mesures par modèle 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é. De là, nous avons déduit le temps jusqu'au premier token, le temps jusqu'au premier token de réponse, la latence par token et la vitesse de sortie, et le temps de bout en bout.
Raisonnement vs sans raisonnement
Chaque réponse renvoie un résumé d'utilisation qui inclut un nombre de tokens de raisonnement. Nous avons lu cela pour chaque requête et avons marqué la requête comme raisonnement lorsque le compte était supérieur à zéro et sans raisonnement lorsqu'il était nul, au lieu de se fier à l'étiquette du modèle. C'est ainsi que nous avons constaté que GPT-5.2 raisonne sur le codage mais pas sur Q&A.
Comment nous avons choisi les fournisseurs
Le même modèle est servi par différents fournisseurs à des vitesses différentes, nous avons donc épinglé chaque modèle à un fournisseur au lieu de laisser les requêtes 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 éliminé tout fournisseur en dessous d'environ 98 pourcent de disponibilité, puis choisi le plus rapide parmi les autres en termes de latence et de débit. Nous avons épinglé ce fournisseur pour chaque requête et enregistré le fournisseur qui a effectivement servi chaque réponse pour confirmer que l'épinglage tenait. Quelques-uns des fournisseurs les plus rapides n'étaient pas accessibles avec notre compte et ont renvoyé 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 les courtes, 1,024 pour les longues) afin que la verbosité ne fausse pas la latence. Les modèles de raisonnement ont reçu un budget supplémentaire pour la réflexion au-delà de cette limite.
- Chaque prompt commençait par un bloc de texte unique pour empêcher 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 tokeniseur afin que la vitesse soit comparable entre les modèles.
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 = jul,
howpublished = {\url{https://aimultiple.com/llm-latency-benchmark}},
note = {AIMultiple. Consulté le 8 Juillet 2026}
}Résultats et horodatages de 1.3 mille points de données. Téléchargez les données utilisées dans cet article sous forme de fichier ZIP contenant un fichier CSV et un README.
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.