- Modèle de langage utilisant une approche de génération parallèle basée sur un modèle de diffusion (diffusion) pour dépasser les limites de vitesse des LLM à décodage séquentiel
- Grâce à une architecture de raffinement parallèle (parallel refinement) qui génère et corrige plusieurs tokens à la fois, il atteint une vitesse de réponse plus de 5 fois supérieure
- Avec un débit de 1 009 tokens/s, un contexte de 128K, la sortie JSON et la prise en charge des outils, il est optimisé pour les applications en temps réel
- Son efficacité est démontrée dans des environnements sensibles à la latence, comme l’assistance au code, les boucles d’agents, les interfaces vocales et les pipelines de recherche·RAG
- Entièrement compatible avec l’API OpenAI, il peut être intégré immédiatement sans modification de l’infrastructure existante
Présentation de Mercury 2
- Mercury 2 est le modèle de langage d’inférence le plus rapide au monde
- Son objectif est d’offrir une réactivité instantanée dans les environnements IA de production
- Le principal goulot d’étranglement des LLM existants vient de leur architecture de décodage séquentiel autorégressif (one token at a time)
- Cela entraîne une accumulation de latence dans les workflows IA de type boucle itérative
Architecture d’inférence en temps réel basée sur la diffusion
- Mercury 2 adopte une approche de raffinement parallèle (parallel refinement) au lieu du décodage séquentiel
- Il génère plusieurs tokens simultanément et converge en un petit nombre d’étapes
- Son fonctionnement s’apparente davantage à celui d’un « éditeur » qui révise l’ensemble d’un brouillon de façon itérative qu’à celui d’une « machine à écrire »
- Cela permet au final une vitesse de génération plus de 5 fois supérieure et une nouvelle courbe de vitesse
- L’inférence basée sur la diffusion permet une inférence de haute qualité tout en minimisant la latence et les coûts
Performances et spécifications
- Vitesse : 1 009 tokens/s sur GPU NVIDIA Blackwell
- Prix : 0,25 $ par million de tokens en entrée, 0,75 $ par million de tokens en sortie
- Qualité : un niveau compétitif face aux principaux modèles optimisés pour la vitesse
- Fonctionnalités : raisonnement ajustable (tunable reasoning), contexte de 128K, utilisation d’outils, sortie alignée sur un schéma JSON
- Optimisation de la latence : latence p95, réactivité constante dans les environnements à forte concurrence, maintien d’un débit stable
- Un responsable de NVIDIA a indiqué que Mercury 2, combiné à l’infrastructure IA de NVIDIA, dépasse les 1 000 tokens/s
Cas d’usage en production
1. Code et édition
- Il fournit des réponses immédiates dans les boucles de travail des développeurs pour l’autocomplétion, le refactoring et les agents de code
- Max Brunsfeld, cofondateur de Zed, a souligné une « vitesse de suggestion aussi rapide qu’une partie de la pensée »
2. Boucles d’agents
- Il réduit la latence des appels dans les workflows d’agents nécessitant des appels de raisonnement en plusieurs étapes
- Viant utilise Mercury 2 pour l’optimisation de campagnes en temps réel et le renforcement de systèmes publicitaires autonomes
- Wispr Flow évalue la vitesse de Mercury 2 pour les conversations en temps réel et le raffinement de transcriptions
- Skyvern indique qu’il est « au moins deux fois plus rapide que GPT-5.2 »
3. Voix et interactions en temps réel
- Les interfaces vocales ont les contraintes de latence les plus strictes
- Happyverse AI met en œuvre avec Mercury 2 des avatars conversationnels naturels en temps réel
- OpenCall évoque la possibilité de construire des agents vocaux plus réactifs grâce à une faible latence et une haute qualité
4. Recherche et pipelines RAG
- Il réduit la latence cumulée des processus de recherche multiple, reranking et résumé, rendant l’inférence en temps réel possible
- En collaboration avec Mercury 2, SearchBlox a mis en œuvre une IA de recherche en temps réel,
fournissant une intelligence en quelques secondes dans divers domaines comme le support client, le risque et l’e-commerce
Déploiement et intégration
- Mercury 2 est disponible immédiatement et entièrement compatible avec l’API OpenAI
- Il peut être intégré aux systèmes existants sans modification du code
- Pour les évaluations en entreprise, un accompagnement est proposé sur l’adéquation des workloads, la validation des performances et la conception des évaluations
- Formule officielle : « Mercury 2 is live. Welcome to diffusion. »
1 commentaires
Avis Hacker News
Le concept d’intelligence (metric) par seconde est intéressant
Par exemple, mesurer l’intelligence par token et la considérer avec le nombre de tokens par seconde
Personnellement, si Sonnet 4.6 est 5 fois plus rapide qu’Opus 4.6, j’utiliserais surtout Sonnet
Dans la génération précédente, la famille Sonnet n’était pas assez bonne, mais maintenant l’avantage d’itération apporté par la vitesse change la donne
Avant, j’utilisais OpenAI Deep Research, mais o3-thinking + recherche web était bien plus rapide tout en étant suffisamment intelligent
Développer une API sur du matériel comme Cerebras ou Groq place la vitesse d’itération et les coûts à un tout autre niveau
Dans une note de recherche écrite récemment, on montre aussi qu’en séparant la planification en modèle AR et la génération en modèle de diffusion, les performances s’améliorent nettement
Par exemple, si 5 tonnes de charbon suffisent mais qu’on en utilise 30 pour gagner 0,0000000001 %, ce n’est pas un vrai progrès
Les modèles Composer ou les versions Flash en sont des exemples, et Mercury 2 se positionne aussi comme un modèle solide dans cette catégorie
Les modèles rapides permettent d’itérer vite, tandis que les gros modèles sont plus précis dès la première tentative
Pour l’instant, j’aime bien Opus 4.6, mais j’aimerais voir avec des données l’écart d’efficacité avec Sonnet
C’est exactement pour ça que j’aimais Gemini 3 Flash — suffisamment intelligent tout en étant incroyablement rapide
J’ai fait un test simple : en demandant les accomplissements de Maradona, Mercury 2 a fait la faute de frappe « Dieadona »
Même un modèle local 3B répondrait parfaitement à cette question, mais Mercury 2 est lent et bourré d’erreurs
Mercury 2 génère ses réponses via un mécanisme de raffinement parallèle (parallel refinement)
Il produit plusieurs tokens simultanément pour converger en quelques étapes, donc au lieu d’un fonctionnement type machine à écrire, il retouche un brouillon complet comme un éditeur
Des recherches sont en cours pour unifier DDPM et SGM via les SDE, et je me demande si chaque couche d’un transformer pourrait être vue comme une étape de diffusion
Si les L couches d’un transformer correspondent aux L étapes de raffinement d’une diffusion, il serait peut-être possible d’avoir un ajustement mutuel (fitting) entre les deux modèles
En tant que cofondateur et Chief Scientist d’Inception, je réponds volontiers aux questions techniques sur Mercury 2 ou les LM de diffusion
Peut-il réduire la latence ou les coûts, suit-il une courbe similaire à celle du cache autoregressif, ou bien n’est-il pas applicable du tout ?
Il serait aussi intéressant de savoir si on peut appliquer une longueur de bloc dynamique
Dans la plupart des systèmes vocaux, le plus important n’est pas la latence totale de réponse mais le TTFT (time-to-first-token)
J’aimerais savoir dans quelle mesure le TTFT de Mercury 2 s’améliore par rapport aux autres modèles de reasoning
Voir ce lien d’exemple
Je suis curieux de connaître la cause de ce phénomène
Le plus intéressant, c’est de voir apparaître des modèles qui génèrent des milliers de tokens par seconde
Dans ce cas, même avec du multi-shot prompting ou du nudging, l’utilisateur ne le percevra pas, ce qui peut réduire les hallucinations et les réponses non déterministes
Mercury 2 permet une itération rapide sur des tâches agentiques
Une tentative isolée peut être moins précise, mais le temps d’exécution très court permet d’améliorer bien plus vite
Par exemple, GPT-OSS 20B atteint environ 2k tok/s avec bs=64 sur une seule 3090
Je ne suis toujours pas convaincu par les modèles de diffusion
Google et d’autres ont essayé aussi, mais dans la plupart des cas ils sont restés en retrait sur la frontière de Pareto
Voir ce lien de comparaison prix/performance
À qualité égale, Mercury est plus de 5 fois plus rapide que des modèles AR comparables
Son intelligence absolue reste inférieure à celle d’Opus ou de Gemini Pro, mais il garde un gros avantage en vitesse d’inférence
C’est un domaine beaucoup moins exploré que les transformers autoregressifs, donc il y a beaucoup de headroom technique
S’il existait une version « Mercury Edit » comme Fast Apply de Morph, j’aimerais vraiment l’essayer
L’approche basée sur la diffusion est très intéressante
Les transformers traditionnels génèrent les tokens de façon séquentielle, alors que la diffusion peut raffiner l’ensemble de la sortie de manière itérative
Si le problème de latence a réellement été résolu, cela pourrait ouvrir de nouvelles possibilités pour les tâches de reasoning complexes
Je me demande s’il existe un LLM de diffusion à poids ouverts pouvant tourner sur du matériel local
J’aimerais voir directement la différence de performance sur un GPU grand public
Mercury 2 a échoué au Car Wash Test
Il vaudrait sans doute mieux se concentrer sur un usage spécifique (par ex. un agent de code) plutôt que sur le reasoning généraliste, et le comparer aux modèles SOTA du domaine comme Qwen3-Coder-Next
Même pour de longues sessions, l’exactitude compte plus
Si ce modèle était déployé sur une puce Talaas, je me demande s’il pourrait générer plus de 50 000 tokens par seconde