Le 19 octobre 2026, Inception a présenté Mercury 3 avec une promesse spectaculaire : 1 068 tokens générés par seconde sur GPU NVIDIA. Son secret tient à une architecture à diffusion, capable de retravailler plusieurs fragments de texte en parallèle. La technologie est bien réelle, et le modèle est accessible par API.
Mais cette cadence ne correspond ni au temps d’attente garanti pour chaque requête, ni à la vitesse d’un agent qui consulte des outils. Les essais externes dessinent un portrait plus contrasté : Mercury 3 excelle dans certaines tâches courtes, tout en rencontrant des difficultés sur des séquences complexes. Alors, nouvelle voie pour l’IA ou chiffre marketing savamment choisi ?
Trois points clés
- 1 068 tokens/s est une mesure revendiquée par Inception, pas une vitesse contractuelle pour tous les appels API.
- La diffusion textuelle accélère la production de blocs de tokens, sans supprimer la lecture du contexte ni les appels d’outils.
- La valeur réelle dépend du taux de réussite, du temps de bout en bout et du coût par tâche achevée.
1 068 tokens par seconde, mais dans quelles conditions ?
Dans son annonce du 19 octobre, Inception avance 1 068 tokens/s sur des GPU NVIDIA, soit une vitesse quatre à huit fois supérieure à celle de modèles rapides pris comme références, notamment GPT-6 Luna et Claude Haiku 5.5. Ces deux comparaisons, comme le rappelle RoboActu, viennent du fournisseur lui-même. La configuration matérielle et les paramètres précis ne sont pas assez documentés pour reproduire cette mesure. Un token n’est pas forcément un mot entier. Ce débit n’équivaut pas à mille mots par seconde.
Autre distinction : la cadence de sortie commence après la préparation de la requête. Il faut d’abord acheminer le message, traiter le contexte, produire le premier élément et éventuellement attendre les appels d’outils. Pour une réponse brève, le délai avant le premier token peut peser davantage que le débit maximal. La durée totale devient déterminante pour les agents qui enchaînent les opérations. Ces indicateurs ne sont pas interchangeables.
Sur la fiche OpenRouter de Mercury 3, le relevé consulté le 29 octobre affiche 243 tokens/s de débit médian et 0,80 seconde de latence médiane, pour le fournisseur présenté. Ce sont des statistiques de service, susceptibles d’évoluer selon la période, les requêtes et la charge. Elles ne réfutent pas une mesure de pointe obtenue ailleurs ; elles rappellent surtout pourquoi 1 068 tokens/s ne doit jamais être présenté comme une performance universelle.
Ce que la diffusion change vraiment dans la génération de texte
La plupart des grands modèles conversationnels fonctionnent de façon autorégressive : ils ajoutent les tokens successivement, chacun dépendant des précédents. Mercury 3 utilise une autre méthode. Il part de positions textuelles provisoires, puis raffine plusieurs tokens en parallèle, au fil de passes de correction. Les explications pédagogiques d’Alessandro Ecclesie Agazzi et de MindStudio décrivent bien cette différence. L’analogie avec les images est utile, sans être littérale. Affirmer que la réponse entière apparaît instantanément serait aussi trompeur : la génération s’organise par blocs et étapes de raffinement.
Cette architecture exploite mieux certaines opérations parallèles du GPU, sans rendre le calcul gratuit. Les passes supplémentaires et le contexte peuvent réduire cet avantage. Inception revendique aussi un million de tokens de contexte, contre 260 000 pour Mercury 2.5, et un modèle plus de quarante fois plus grand que Mercury 1. Son nombre total de paramètres reste inconnu. La fenêtre annoncée indique une capacité d’entrée, non une compréhension parfaite d’un million de tokens. L’intérêt scientifique dépasse Mercury : DiffusionGemma, développé par Google, explore également cette famille de modèles. La percée concerne la méthode de génération, pas la disparition de toutes les limites des LLM.
Les benchmarks confirment une avancée, pas une supériorité générale
Inception présente Mercury 3 comme compétitif face à GPT-6 Luna et Claude Haiku 5.5 sur plusieurs évaluations, avec huit meilleurs résultats sur douze dans la comparaison rapportée par NeoTeo. Mais le même tableau comporte des épreuves où les concurrents arrivent devant, notamment sur le code et la recherche dans des textes longs. Il compare des modèles optimisés pour la vitesse, pas les systèmes les plus puissants. Les réglages comptent : le palmarès doit être confronté au terrain.
Bito a réalisé un benchmark distinct sur la programmation. Mercury 3 obtient 76 % sur ses demandes courtes, contre 79 % pour Claude Haiku 5.5. Sur huit sessions de code longues, son score tombe à 65 %, contre 87 % pour Claude Opus 5.5. Bito observe pourtant une session moyenne terminée en 5,8 minutes, contre 17,2 pour Opus, et 198 tokens/s de débit médian par requête. Terminer vite et terminer correctement ne sont pas synonymes. L’échantillon est limité et les notes reposent en partie sur un juge automatique.
Le test pratique de MindStudio apporte une nuance complémentaire, mais pas un classement statistique. Mercury 3 y corrige correctement un problème de logique dans une application, puis peine davantage sur une demande créative et interactive comportant plusieurs étapes. Cet essai ne mesure pas une performance moyenne. En somme, Mercury 3 convainc davantage sur les tâches ciblées que sur les missions longues, et le jugement dépend du critère retenu.
Les applications où ce gain peut devenir perceptible
Le meilleur terrain de Mercury 3 n’est pas nécessairement la rédaction d’un long rapport. C’est plutôt la boucle courte : un assistant qui répond à une question, un tuteur qui corrige un exercice, ou un agent web qui doit décider rapidement de son prochain clic. Inception cite des partenaires en navigation, enseignement et support. TinyFish AI rapporte 25 réussites sur 50 tâches Mind2Web dans son propre dispositif. Octen AI annonce, pour une recherche utilisée sur lunettes connectées, une génération médiane de 0,9 seconde et un temps de réponse complet de 2,2 secondes. Les conditions et les applications diffèrent ; il serait abusif de comparer ces chiffres à ceux d’OpenRouter comme s’il s’agissait du même test.
Ces témoignages proviennent de partenaires mis en avant par Inception, pas d’un audit indépendant. Ils sont néanmoins parlants : lorsqu’un agent multiplie les sollicitations au modèle, une seconde gagnée à chaque étape peut s’additionner. À l’inverse, un appel réseau lent, une mauvaise décision ou une seconde tentative peuvent effacer tout le bénéfice. Dans les usages vocaux, un modèle textuel ne remplace pas à lui seul la reconnaissance et la synthèse de la parole ; Inception propose d’ailleurs un produit distinct, Mercury Voice. Il faut distinguer : débit de génération, délai de réponse et temps de tâche réussie.
Prix attractifs, mais la facture ne se résume pas aux tokens
Mercury 3 est disponible par API chez Inception et via OpenRouter, Baseten ou Vercel. La compatibilité annoncée avec l’API OpenAI facilite les essais, sans garantir qu’une application complexe basculera sans adaptation. Le modèle accepte les appels d’outils et les sorties structurées, mais ses poids ne sont pas publiés librement. Hébergement et conservation des données restent à examiner avant tout déploiement sensible. La taille du contexte ne garantit pas une analyse fiable.
Le prix catalogue annoncé est de 0,20 dollar par million de tokens en entrée et 0,70 dollar en sortie. Inception affiche au lancement une remise de 50 %, soit 0,10 et 0,35 dollar. The Deep View souligne que la période promotionnelle n’avait pas de date de fin publique et que le véritable argument de Mercury 3 est d’abord sa vitesse. Comparer son prix remisé au tarif permanent d’un concurrent reviendrait donc à tirer une conclusion fragile. Une génération plus rapide ne prouve pas davantage une sobriété énergétique supérieure.
Un détail du test Bito résume mieux l’économie réelle : une longue session Mercury 3 y coûte 0,48 dollar, contre 0,14 dollar pour DeepSeek V4.1 Flash 1017, pourtant plus lent dans ce protocole. Le rapport pointe notamment des résultats de mise en cache décevants sur le contexte répété. Le tarif au million de tokens n’est qu’un point de départ : c’est le coût d’une tâche correcte, sans reprise, qui tranche.
Comment départager la prouesse technique de l’effet d’annonce
La bonne méthode consiste à tester Mercury 3 sur les requêtes qui comptent vraiment : quelques réponses courtes, une synthèse documentaire, une correction de code et un agent qui consulte plusieurs outils. Face à un modèle concurrent, gardez les mêmes documents, objectifs et critères de réussite. Notez le fournisseur, les réglages, la taille du contexte, la part de cache et le nombre d’essais. Mesurez le premier token, la durée totale, le coût facturé et la réussite finale. En programmation, exécutez les tests du projet ; pour les agents, comptabilisez les reprises et les interventions humaines. Examinez aussi les échecs et les cas lents.
Ce protocole rejoint l’objectif des benchmarks centrés sur les performances réelles. Si Mercury 3 rend dix étapes sensiblement plus rapides sans dégrader la qualité, son architecture apporte un avantage concret. Si les corrections et les appels ratés s’accumulent, l’exploit au compteur perd une partie de son intérêt. La diffusion textuelle est bien une avancée technique crédible : elle montre qu’un autre chemin existe pour accélérer les LLM. Mais prétendre que Mercury 3 est déjà supérieur partout serait aller plus vite que les preuves. Le véritable verdict dépendra alors de la rapidité avec laquelle il termine correctement une tâche, pas du seul chiffre de 1 068 tokens/s.
- Partager l'article :
