Mercury 2

Qu’est-ce que Mercury 2 ?

Mercury 2 est un grand modèle de langage (LLM) axé sur le raisonnement, lancé par Inception. Son objectif principal est d’offrir des performances de raisonnement rapides pour les charges de travail IA en production — en particulier là où la latence s’accumule dans des « boucles » itératives comme les étapes d’agents, les pipelines de récupération et les tâches d’extraction.

Contrairement aux modèles autorégressifs qui génèrent un token à la fois de gauche à droite, Mercury 2 utilise une approche basée sur la diffusion pour un raisonnement en temps réel. Le modèle produit des sorties par raffinement parallèle, générant plusieurs tokens simultanément et convergeant en un petit nombre d’étapes.

Fonctionnalités clés

• Génération par raffinement parallèle basé sur la diffusion : Produit plusieurs tokens en même temps plutôt que par décodage séquentiel, pour une latence bout en bout réduite dans les systèmes interactifs.
• Optimisé pour la vitesse en production : Annoncé à 1 009 tokens/sec sur GPU NVIDIA Blackwell, conçu pour réduire les temps d’attente perçus sous charge.
• Raisonnement ajustable : Permet de configurer le comportement de raisonnement tout en maintenant l’équilibre vitesse–qualité.
• Contexte 128K : Prend en charge les entrées longues via une fenêtre de contexte de 128K.
• Utilisation native d’outils : Inclut une capacité intégrée pour invoquer des outils dans les workflows de raisonnement.
• Sortie JSON alignée sur un schéma : Peut retourner des sorties structurées alignées sur un schéma, utiles pour l’automatisation en aval.

Comment utiliser Mercury 2

1. Intégrez Mercury 2 dans votre pipeline LLM là où la latence compte (ex. : boucles d’agents, workflows augmentés par récupération, ou tâches d’extraction).
2. Choisissez un réglage de raisonnement adapté à vos besoins en qualité et en temps de réponse (le modèle prend en charge un raisonnement ajustable).
3. Fournissez des entrées dans la fenêtre de contexte 128K et, si nécessaire, demandez une sortie JSON alignée sur un schéma pour un parsing fiable.
4. Utilisez des appels d’outils pour les workflows nécessitant des actions externes (ex. : recherche, requêtes base de données, ou étapes assistées par outils), particulièrement dans les scénarios d’agents multi-étapes.

Cas d’usage

• Workflows de codage et d’édition : Autocomplétion, suggestions de prochaines éditions, refactorisations et agents de code interactifs où les pauses peuvent perturber le flux du développeur.
• Tâches en boucles agentiques : Systèmes qui enchaînent de nombreux appels d’inférence par job (ex. : prise de décision multi-étapes), où réduire la latence par appel permet plus d’étapes.
• Voix en temps réel et interactions : Interfaces vocales et scénarios HCI interactifs avec budgets de latence serrés, où un raisonnement plus rapide maintient une interaction fluide comme la parole.
• Pipelines de recherche et RAG : Workflows de récupération multi-sauts et de synthèse où le raisonnement s’ajoute à la boucle de recherche sans dépasser les contraintes de latence.
• Nettoyage de transcripts et autres tâches de transformation itératives : Applications nécessitant des transformations et raffinements rapides et cohérents sur des interfaces utilisateur.

FAQ

En quoi Mercury 2 diffère-t-il du décodage LLM typique ?
Mercury 2 est décrit comme basé sur la diffusion et générant des réponses par raffinement parallèle plutôt que par décodage autorégressif séquentiel, token par token.

Quelles caractéristiques de performance sont indiquées pour Mercury 2 ?
La page rapporte une génération >5x plus rapide et 1 009 tokens/sec sur GPU NVIDIA Blackwell, avec des conseils pour optimiser la réactivité perçue par l’utilisateur (y compris latence p95 sous forte concurrence).

Quelle longueur de contexte Mercury 2 supporte-t-il ?
Il est indiqué 128K de contexte.

Mercury 2 peut-il produire des sorties structurées ?
Oui. Il est décrit comme supportant une sortie JSON alignée sur un schéma pour des réponses structurées.

Mercury 2 supporte-t-il l’utilisation d’outils ?
La page indique qu’il dispose d’une utilisation native d’outils, destinée à intégrer des outils dans les workflows de raisonnement.

Alternatives

• LLM de raisonnement autorégressifs : Les LLM traditionnels token par token sont plus simples à intégrer mais génèrent généralement de manière séquentielle, augmentant la latence dans les boucles multi-étapes.
• Autres approches de génération par diffusion ou non autorégressive : Architectures de modèles alternatives visant une génération parallèle avec des objectifs de latence similaires, bien que les détails d’implémentation et le comportement de sortie puissent différer.
• Petits LLM optimisés pour la vitesse en usage interactif : Modèles axés sur faible latence qui sacrifient souvent la profondeur de raisonnement ou la contrôlabilité par rapport à une configuration comme Mercury 2.
• Stratégies d’orchestration agent/RAG minimisant les appels : Au lieu de changer l’architecture du modèle, les équipes peuvent réduire la latence en restructurant les workflows (ex. : moins d’étapes de récupération, mise en cache ou batching), bien que cela puisse limiter le raisonnement par tâche.