Mercury 3 débarque à 1 068 tokens par seconde — et sans un seul chiffre de benchmark

Inception Labs a publié Mercury 3 le 19 octobre 2026, et l’annonce commence par trois chiffres : 1 068 jetons par seconde sur GPU NVIDIA, une fenêtre de contexte de 1 M de jetons et 0,10 $ par million de jetons d’entrée tant que la remise de lancement dure. Ce qu’elle ne contient pas, c’est le moindre score de benchmark. L’affirmation de qualité est comparative — Mercury 3 « surpasse GPT-6 Luna et Claude Haiku 5.5 » — et chaque affirmation quantitative du billet porte sur la vitesse, la taille ou le prix. Ce n’est pas tant une critique que la forme des éléments dont vous disposez si vous décidez de migrer une charge de travail vers cette solution cette semaine. Cet article passe en revue ce qu’Inception a réellement livré, ce que signifient les affirmations non chiffrées et où un développeur devrait tracer la ligne entre l’essayer et en dépendre. Les défaillances documentées de l’IA et les incidents d’agents derrière des versions comme celle-ci sont recensés dans l’OrcaRouter AI Incident Archive où chaque entrée comporte ses propres sources, un niveau de gravité, une note de confiance et un indicateur de contestation.

Ce qu’Inception a mis sur la table le 19 octobre

Mercury 3 est un modèle de langage à diffusion — le terme employé par Inception est dLLM — et l’entreprise le qualifie de modèle à diffusion le plus capable publié à ce jour. L’architecture génère des tokens en parallèle plutôt qu’un à la fois, ce qui explique l’affirmation concernant le débit. Inception indique que le modèle est plus de 40 fois plus grand que Mercury 1 en nombre total de paramètres, sans publier de nombre absolu de paramètres, et que l’intelligence mesurée sur sa suite de benchmarks a environ triplé entre Mercury 1 (mini) et Mercury 3.

• Contexte — 1 M de tokens, contre 260 K sur Mercury 2.5, avec une sortie maximale de 131 072 tokens.

• Prix — 0,20 $ par million de tokens d’entrée et 0,70 $ par million de tokens de sortie au tarif catalogue ; 0,10 $ et 0,35 $ pendant la durée de la remise de lancement.

• Entrée mise en cache — 0,02 $ par million au tarif catalogue, réduit de moitié à 0,01 $ pendant la fenêtre de lancement, ce qui correspond à la remise habituelle de 90 % sur le tarif d'entrée.

• Effort de raisonnement — quatre réglages : instantané, faible, moyen et élevé. Mercury 3 utilise par défaut le réglage faible lorsque le paramètre est omis, tandis que Mercury 2.5 et Mercury 2 utilisent par défaut le réglage moyen.

• Modalités — texte en entrée, texte en sortie. L’appel d’outils et les sorties structurées sont pris en charge sur le point de terminaison des complétions de chat.

• Forme de l’API — complétions de chat compatibles OpenAI, avec une température réglable entre 0,5 et 1,0.

• Disponibilité — la propre plateforme API d'Inception, où les nouveaux comptes reçoivent 100 millions de tokens gratuits, ainsi que plusieurs plateformes d'inférence tierces. Les déploiements Enterprise ajoutent une capacité dédiée, l'autoscaling et une rétention des données configurable.

Le réglage d’effort par défaut est le détail le plus susceptible d’être négligé et le plus susceptible d’avoir de l’importance. Un modèle qui répond avec un effort « faible » par défaut semblera plus rapide et obtiendra un score inférieur au même modèle avec un effort « élevé », et les propres affirmations comparatives d’Inception ne précisent pas quel réglage les a produites. Si vous évaluez Mercury 3 vous-même, fixez explicitement le niveau d’effort, sinon vos chiffres ne seront comparables à ceux de personne d’autre.

L'allégation de qualité est comparative, et non quantitative

Relisez la phrase : Mercury 3 « surpasse GPT-6 Luna et Claude Haiku 5.5 ». Tous deux sont des modèles optimisés pour la vitesse, et non des fleurons de pointe, et la comparaison est la bonne pour un modèle dont tout l'argumentaire repose sur la latence. Mais l'annonce ne donne aucune marge, aucun nom de benchmark et aucun résultat par tâche, si bien que l'affirmation ne peut être vérifiée sur un harnais public sans l'exécuter soi-même.

Le seul résultat de qualité qui repose sur une structure quelconque est un test d’agent. Inception a exécuté Mercury 3 dans son propre harnais d’agent web de production, face à des modèles de pointe, sur 50 tâches de navigation Mind2Web en conditions réelles, et rapporte qu’il en a terminé 50 %, « nettement plus que GPT-6.1-Sol », en utilisant le même volume de tokens et le même nombre d’étapes d’agent, et donc une fraction du coût par token. Cinquante tâches constituent un petit échantillon, le harnais est celui d’Inception, et le modèle de comparaison est nommé sans score. C’est un signal réel — l’achèvement de tâches sur des sites en conditions réelles est plus difficile à manipuler qu’une suite à choix multiples — mais c’est un signal, pas une mesure que l’on peut mettre dans un document d’achat.

Inception affirme aussi que Mercury 3 est « au niveau, voire meilleur, que les modèles frontière optimisés pour la vitesse », et non au niveau des modèles de raisonnement frontière. Cette distinction joue un rôle considérable dans l’article, et il vaut la peine de la prendre au pied de la lettre : il s’agit d’un modèle positionné face au segment rapide, pas face à Claude Opus 5.5 ou Gemini 4 Argon.

Le numéro de vitesse, inscrit en regard du dernier Mercury

Ce n'est pas seulement le débit qui a changé. Le [[[5000]]] et le [[[Latent Consistency Model]]] ont transformé la manière dont nous pensions la latence des pipelines de diffusion — et rendu possible un type de service tout à fait différent pour plusieurs utilisateurs simultanés. Dans cet article, nous montrons comment nous avons obtenu un gain de débit de 70 % par rapport à une implémentation déjà optimisée, en supprimant un inefficacité subtile, pilotée par SDK, sur le chemin critique de la génération d'images. Ce que nous détaillons ci-dessous est directement applicable à tout serveur de diffusion en production, pas seulement à notre plateforme gérée. ## Pourquoi la latence de diffusion se comporte différemment de la latence LLM Lorsque les équipes abordent pour la première fois la latence de diffusion, elles importent souvent des techniques du monde des LLM. La logique est intuitive : un LLM et un modèle de diffusion génèrent tous deux des sorties token par token, donc les optimisations devraient se transférer. Elles ne se transfèrent pas. Du moins, pas directement. Un LLM génère des tokens séquentiellement, un après l'autre, et chaque token dépend du précédent. C'est le décodage autorégressif, et il est essentiellement lié au calcul : vous ne pouvez pas paralléliser la génération d'un seul ensemble de tokens à travers plusieurs GPU sans complexité significative. La diffusion fonctionne différemment. Un modèle de diffusion commence par du bruit pur et le raffine progressivement sur un nombre fixe d'étapes de débruitage. Chaque étape traite l'image entière, pas un seul token. Les étapes dépendent les unes des autres, mais le travail au sein d'une étape peut être distribué. La conséquence pratique : le temps de génération d'image pour une seule requête est limité par le nombre d'étapes de débruitage et par le coût de chaque étape. Réduire le nombre d'étapes est l'optimisation la plus importante. C'est ce que fait LCM : il réduit considérablement le nombre d'étapes nécessaires tout en produisant des images de qualité acceptable. C'est pourquoi il a changé la donne pour la latence. Mais le débit n'est pas la latence. Une fois que chaque requête est assez rapide, la question devient : combien de requêtes le système peut-il traiter simultanément sans dégrader la latence par requête ? ## Où le SDK entre en jeu Notre pipeline de génération dispose de deux chemins distincts : asynchrone et synchrone. Les requêtes asynchrones sont mises en file d'attente et traitées par des workers qui pilotent le pipeline dans son ensemble. Ces workers gèrent le batching, la planification et le suivi d'état sans aucune intervention d'un SDK côté client. Le SDK soumet la demande et interroge les résultats. Ce chemin est optimisé pour le débit. Les requêtes synchrones sont différentes. Lorsque nous avons introduit pour la première fois le SDK Python, l'appel asynchrone du SDK interrogeait une file d'attente. Le SDK vérifiait périodiquement si un résultat était prêt, avec un délai d'attente. Pour une seule requête, c'était correct. Sous charge concurrente, cela ajoutait une latence perceptible à chaque requête — non pas parce que la génération était lente, mais parce que le mécanisme d'interrogation introduisait un décalage entre le moment où le résultat était prêt côté serveur et celui où le SDK le remarquait. ## La correction, étape par étape L'inefficacité venait du chemin synchrone. Chaque appel synchrone traversait la couche d'interrogation du SDK avant d'atteindre le serveur, ajoutant une attente qui n'avait rien à voir avec le calcul de génération. ### 1. Raccourcir l'attente d'interrogation La première correction fut de réduire la durée d'attente entre les interrogations et d'ajuster l'algorithme de backoff pour qu'il réagisse plus rapidement sur les premières étapes, lorsque la plupart des résultats arrivent. ### 2. Éliminer le décalage d'arrondi par lots Pour les requêtes mises en lot, le résultat d'une requête dans un lot se bloque jusqu'à ce que le lot entier soit terminé. Le SDK attendait une petite marge au-delà de la durée prévue pour le lot, ce qui ajoutait une latence inutile à chaque requête. Nous avons aligné les attentes sur les lots réels. ### 3. Retarder la connexion Le SDK établissait les connexions tôt, avant que le serveur ne soit réellement prêt. Ces connexions inactives consommaient des ressources et ajoutaient de la latence. Nous avons rendu l'établissement des connexions paresseux. ### 4. Exposer le dernier délai Chaque appel SDK portait un délai par défaut qui ne correspondait pas au pool de travailleurs, provoquant des échecs de connexion sans rapport avec la charge réelle. Nous avons supprimé le délai par défaut et révélé le vrai délai du dernier moment. ## Les résultats Après ces correctifs, nous avons observé une amélioration du débit de 70 % par rapport à la version précédente, mesurée en requêtes par seconde sur le même matériel. L'amélioration s'est maintenue à mesure que la concurrence augmentait. ## Ce que cela signifie pour vous Si vous exploitez un serveur de diffusion, la leçon n'est pas « utilisez le SDK ». Elle est de comprendre que la latence est un système. Le calcul peut être rapide, mais si la couche d'appel côté client ajoute une attente à chaque requête, vous ne verrez jamais ce gain. Mesurez les composants de la latence, pas seulement le total. Séparez le temps de génération du temps d'attente. Ensuite, corrigez la partie qui n'est pas le calcul. La publication sur la théorie des files d'attente de huit ans est disponible dans l'article associé, et nous recommandons de la lire si vous concevez un système sous charge concurrente.

La mesure indépendante disponible concerne la génération précédente. Artificial Analysis mesure Mercury 2.5 à environ 706 tokens par seconde et Mercury 2 dans les 680, les deux selon son propre banc d’essai. Ce sont des chiffres de tiers réels et reproductibles, et ils sont inférieurs aux chiffres du fournisseur qui accompagnaient ces lancements. Cet écart est la décote normale entre chiffres fournisseur et mesures indépendantes dans cette catégorie, et non une preuve de mauvaise foi — mais c’est la décote que vous devez appliquer mentalement à 1,068 jusqu’à ce que quelqu’un le reproduise.

Au 20 octobre 2026, Artificial Analysis n’a pas de page Mercury 3 : son index des modèles liste encore Mercury 2.5 et Mercury 2, et l’URL de Mercury 3 ne renvoie rien. L’affirmation sur la vitesse n’a donc pas encore de vérification indépendante, un jour après le lancement. Cela changera ; ce qu’il est utile de surveiller n’est pas de savoir si le chiffre atterrit près de 1 068, mais si l’écart avec Mercury 2.5 reste aussi large dans un cadre d’évaluation neutre que le laisse entendre la présentation d’Inception.

Ce que vaut la remise de lancement, et ce qu’elle ne vaut pas

La réduction de 50 % est annoncée comme temporaire — « au lancement » — sans date de fin. Cela en fait un tarif promotionnel plutôt qu'une grille tarifaire, et tout modèle de coûts fondé sur 0,10 $/0,35 $ comporte une date d'expiration que vous ne pouvez pas voir. Le prix catalogue est la référence sur laquelle bâtir vos prévisions.

Une comparaison concrète rend l’échelle évidente. Prenons une charge de travail de support ou de recherche de 10 millions de tokens d’entrée et de 40 millions de tokens de sortie par jour. Au prix catalogue, Mercury 3 coûte 2 $ pour l’entrée et 28 $ pour la sortie, soit 30 $ par jour. Au tarif de lancement, le même trafic coûte 1 $ et 14 $, soit 15 $ par jour. Sur un mois, cela représente environ 900 $ contre 450 $ — la promotion vaut à peu près autant que l’avantage total du modèle sur le prix catalogue par rapport à un modèle autorégressif de milieu de gamme. Utile, mais pas une raison pour concevoir son architecture autour de cela.

La ligne d’entrée mise en cache est celle qui change véritablement l’économie réelle des charges de travail agent, car les agents renvoient le même invite système et les mêmes définitions d’outils à chaque étape. À 0,02 $ par million de tokens mis en cache, un préambule de 20 000 tokens coûte 0,0004 $ par appel au lieu de 0,004 $. Sur une exécution d’agent de cinquante étapes, cela représente deux cents de préambule plutôt que vingt, ce qui fait la différence entre un prix par tâche viable et un prix marginal.

Inception ne vend pas de chatbot

Le lancement est présenté autour d’un portefeuille plutôt que d’un modèle unique, et ce cadrage indique à qui le produit s’adresse. Mercury Voice est optimisé pour le délai jusqu’au premier token de réponse dans les agents vocaux ; Mercury Decide est un modèle de classification et de notation sur un point de terminaison distinct, facturé 0,02 $ par million de tokens d’entrée et rien par token de sortie. Les citations de clients d’Inception concernent toutes des systèmes de production sensibles à la latence : un harnais d’agent web chez TinyFish, les retours de tutorat chez RevisionDojo, la génération de recherche chez Octen, le support chez Lorikeet.

Ce sont des charges de travail où une réponse en deux secondes constitue l’exigence produit et où une réponse en cinq secondes est un bug. Ce sont aussi des charges de travail où se tromper est récupérable — une mauvaise suggestion, une mauvaise réponse de recherche, un échange de support escaladé — ce qui correspond exactement au profil de risque sur lequel un modèle sans scores de benchmark publiés peut être essayé en toute sécurité.

Où cela laisse un constructeur cette semaine

Mercury 3 ne figure pas au catalogue d’OrcaRouter. Notre API de modèles ne renvoie actuellement rien pour aucun modèle Inception, et la page du modèle Mercury 3 n’existe pas sur notre site ; toute personne souhaitant l’appeler se tourne donc vers la plateforme propre à Inception ou vers l’un des hébergeurs tiers répertoriés par Inception. Nous préférons le dire clairement plutôt que de laisser entendre une route que nous n’avons pas.

Ce pour quoi notre couche de routage est utile dans cette situation, c'est la partie autour du nouveau modèle plutôt que le modèle lui-même. Le schéma qui fonctionne avec une version non éprouvée et inhabituellement rapide est une voie à deux modèles : envoyer le niveau critique en latence vers Mercury 3 via la clé d'Inception, et garder le repli et les cas difficiles sur des modèles que nous proposons réellement — plus de 200 d'entre eux derrière un seul point de terminaison compatible OpenAI, au prix catalogue du fournisseur avec 0 % de marge, avec bascule automatique en cas de dégradation d'un fournisseur. Vous obtenez la vitesse là où elle est payante et un second avis là où cela compte, sans une deuxième intégration pour le repli.

Trois choses méritent d’être suivies au cours des prochaines semaines. Premièrement, une mesure indépendante de Mercury 3, qui tranchera d’un coup à la fois sur le chiffre de débit et sur la position en termes de qualité. Deuxièmement, de savoir si Inception publie le niveau d’effort et le matériel derrière ses propres chiffres, car un benchmark sans ces éléments n’est pas reproductible. Troisièmement, de savoir si la remise de lancement aura une date de fin — le prix catalogue est 33 % inférieur au tarif de sortie de Mercury 2.5 et environ un cinquième de celui de Claude Haiku 5.5, et une entreprise qui vient de passer un modèle à l’échelle 40 fois a des raisons de vouloir que ce soit le chiffre promotionnel dont les gens se souviennent.

D’ici là, le résumé honnête est le suivant : Mercury 3 est une véritable version avec un récit architectural défendable, un prix réellement agressif et une affirmation de qualité que personne en dehors d’Inception n’a encore testée. Pour une charge de travail contrainte par la latence avec un humain ou un chemin d’escalade dans la boucle, cela suffit à justifier une semaine d’évaluation. Pour tout cas où une mauvaise réponse est coûteuse et non surveillée, cela ne suffit pas encore à justifier une migration.