LLM Benchmark de latence par cas d'usage
Nous avons benchmarké 11 des meilleurs grands modèles de langage avec un total de 1 320 requêtes, en séparant les modèles de raisonnement et de non-raisonnement, et mesuré la latence du premier token, la latence par token et le temps de réponse global.
LLM benchmark de latence
Vous trouverez 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 les modèles de raisonnement et de non-raisonnement séparément. 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 aux modèles de non-raisonnement en termes de latence. Certains modèles changent également de comportement selon la tâche : GPT-5.2 répond aux questions-réponses sans raisonnement, mais raisonne sur les prompts de codage.
Cas de réponse courte (questions-réponses)
Dans le cas court, ce qui compte est la rapidité à 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 de non-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 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 les questions courtes, l'étape de réflexion est principalement un 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 la vitesse de diffusion en continu et le temps de réponse total prennent le dessus. claude-haiku-4-5 a mené sur les deux, diffusant à environ 180 tokens par seconde et terminant en environ 5.5 secondes. Les autres modèles de non-raisonnement ont terminé en à peu près 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 lancés (hy3-preview tourne à environ 200 tokens par seconde), mais la réflexion préalable maintient le total élevé.
La longueur de 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 cours de réflexion.
Réponses courtes contre réponses longues
Le contraste entre les deux cas est le principal point à retenir :
- Dans le cas court, les modèles plus rapides ont répondu en moins d'une seconde et l'écart était faible.
- Dans le cas long, les modèles de non-raisonnement sont restés près de la tête (Haiku le plus rapide à environ 5.5 secondes), tandis que les modèles de raisonnement sont tombés loin derrière à 18 à 35 secondes.
- L'ordre au sein du groupe de non-raisonnement change également : Haiku faisait partie de plusieurs modèles démarrant en moins d'une seconde sur les prompts courts, mais se détache nettement sur les sorties longues en raison de sa vitesse de diffusion.
Latence au 90 centile
Le principal motif 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 la réflexion, et la durée de la 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 ressortent :
- MiMo est l'exception parmi les modèles de raisonnement. Il raisonne sur chaque requête mais réfléchit brièvement, de sorte que son p90 est resté proche de 3.7 secondes. Le raisonnement en soi ne rend pas un modèle imprévisible ; c'est la quantité de réflexion qui le fait.
- GPT-5.2 montre une queue uniquement là où il raisonne. En questions-réponses, son p90 était sous 2 secondes, mais en codage, où il active le raisonnement, son p90 est monté à environ 11 secondes.
- Les modèles de non-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 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 cacher 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 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 modèles 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, d'environ une seconde pour les modèles de non-raisonnement à plusieurs secondes ou plus.
La capacité de raisonnement d'un modèle 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 pour lesquelles chaque modèle a raisonné :
GPT-5.2 le montre directement : il a répondu aux prompts courts de questions-réponses sans raisonnement, mais a raisonné sur la plupart des prompts de codage. Pour un modèle hybride comme celui-ci, le « raisonnement » n’est pas une étiquette fixe ; le modèle 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 en questions-réponses, mais recule en 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, 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 modèles Claude (Opus 4.7, Sonnet 5, Haiku 4.5).
Les autres ont raisonné sur presque toutes les requêtes, c’est pourquoi ils paraissent plus lents à la première réponse. Ainsi, « 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 de lui-même, en activant le raisonnement pour les prompts de codage plus difficiles tout en le laissant désactivé pour les questions-réponses.
Effet du point de terminaison sur la latence pour les LLM
La latence d’un modèle hébergé n’est pas seulement celle du modèle. Elle englobe également la pile de diffusion du fournisseur, la mise en file d’attente, le chemin réseau et la géographie. Notre liste montre cela à l’intérieur d’une même ligne de modèle. Claude Opus 4.8, servi via Google Vertex en Europe, a renvoyé son premier token en environ 0.75 seconde, tandis que Claude Opus 4.7, servi via Anthropic propre API, a pris environ 2 secondes.
Ce sont des versions différentes, de sorte que l'écart n'est pas uniquement dû au point de terminaison, mais le motif 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 s'exécutait en Europe, de sorte que le point de terminaison 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 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 de sortie maximale fixe afin qu'aucun modèle 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 proviennent la plupart des échecs :
- Les modèles de raisonnement passent une partie du budget à réfléchir 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 frappé MiniMax le plus durement en codage, où le premier passage a terminé moins de la moitié de ses requêtes.
Le point à retenir est que la limite maximale de tokens est un paramètre à surveiller : la fixer trop bas et un modèle de raisonnement peut tout dépenser en réflexion et ne jamais aboutir à une réponse. Nous avons augmenté le budget pour les modèles de raisonnement, accordé une marge de réflexion en plus de la longueur de réponse, et réessayé les requêtes ayant échoué. La plupart des lacunes ont été comblées, bien que quelques-unes aient encore échoué lorsque la réflexion du 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, en mesurant la rapidité avec laquelle chaque modèle répond.
Modèles
Nous avons pris les cinq modèles plus utilisés sur OpenRouter et y avons ajouté six autres modèles actuels :
- Non-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'usage et exemples de prompts
Nous avons utilisé deux cas d'usage avec des longueurs d'entrée et de sortie fixes, de sorte que les résultats reflètent la vitesse et non la longueur imprévue du prompt ou de la réponse :
- Réponse courte (questions-réponses) : entrée courte (environ 256 tokens), sortie courte (plafonnée à 128 tokens). Exemple : « Quel est le but 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 : « Construire un téléchargeur d'URL multi-thread en Python qui prend une liste d'URL d'images et les télécharge en parallèle. »
Chaque cas d'usage a utilisé 20 prompts, et chaque prompt a été envoyé 3 fois par modèle, ce qui donne 60 mesures par modèle par cas d'usage. Nous rapportons la médiane (p50) et le p90.
Ce que nous avons mesuré
Nous avons diffusé chaque réponse en continu 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 là, 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 compteur de tokens de raisonnement. Nous avons lu cela pour chaque requête et marqué la requête comme raisonnement lorsque le compteur était supérieur à zéro, et non-raisonnement lorsqu'il était nul, au lieu de nous fier à l'étiquette du modèle. C'est ainsi que nous avons constaté que GPT-5.2 raisonne en codage mais pas en questions-réponses.
Comment nous avons choisi les fournisseurs
Le même modèle est servi par différents fournisseurs à des vitesses différentes, nous avons donc fixé chaque modèle à un fournisseur au lieu de laisser les requêtes s'acheminer 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 ayant une disponibilité inférieure à environ 98 pour cent, puis nous avons choisi le plus rapide parmi les autres selon la latence et le débit. Nous avons fixé ce fournisseur pour chaque requête et consigné le fournisseur qui a effectivement servi chaque réponse pour confirmer que la fixation a tenu. Quelques-uns des fournisseurs les plus rapides n'étaient pas joignables 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 fixé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 de client.
- 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 en plus de cette limite.
- Chaque prompt commençait par un bloc de texte unique pour contrer 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 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'usage}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/llm-latency-benchmark}},
note = {AIMultiple. Consulté le 12 Août 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.
Les travaux de Cem ont été cités par des publications internationales de premier plan telles que Business Insider, Forbes, Washington Post, des entreprises mondiales comme Deloitte, HPE et des ONG comme le Forum économique mondial et des organisations supranationales comme la Commission européenne.
Tout au long de sa carrière, Cem a exercé en tant que consultant tech, acheteur tech et entrepreneur tech. Il a conseillé des entreprises sur leurs décisions technologiques chez McKinsey & Company et Altman Solon pendant plus d'une décennie. Il a également publié un rapport McKinsey sur la numérisation.
Il a dirigé la stratégie technologique et les achats d'un opérateur télécom tout en rendant compte au PDG. Il a également mené la croissance commerciale de l'entreprise deep tech Hypatos qui a atteint un chiffre d'affaires récurrent annuel à 7 chiffres et une valorisation à 9 chiffres à partir de 0 en 2 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 la Bogazici University en tant qu'ingénieur informatique et détient 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.