Introduction
Pendant des années, la latence d'inférence a été le talon d'Achille des assistants de code et des agents IA en production. Générer une réponse de qualité prenait plusieurs secondes — voire plusieurs dizaines de secondes pour les tâches de compaction ou de raisonnement complexe. Cette contrainte poussait les équipes à multiplier les compromis : réduire la taille du contexte, limiter la fréquence des appels ou accepter une expérience utilisateur dégradée.
La sortie de Mercury 2.5, le 8 septembre 2026, illustre à quel point les LLM par diffusion peuvent bousculer cet équilibre.
Une architecture radicalement différente
Contrairement à un modèle autorégressif classique — qui génère les tokens un à un, de gauche à droite —, un modèle de diffusion part d'une séquence entièrement masquée et raffine tous les tokens simultanément, en plusieurs passes. L'avantage opérationnel est considérable : à taille de modèle comparable, le débit peut être cinq à vingt fois supérieur à celui d'un modèle autorégressif équivalent.
Mercury 2.5, développé par InceptionLabs, pousse cette logique à 1 107 tokens par seconde sur GPU NVIDIA, avec une fenêtre de contexte de 260 000 tokens. InceptionLabs le positionne comme 40 % plus performant que Mercury 2 en termes de capacité, avec un niveau comparable aux modèles optimisés de la génération actuelle — Claude Haiku 4.5, Gemini 3.5 Flash-Lite.
Résultats mesurés en production
Les chiffres communiqués par deux clients en production méritent attention.
Chez Augment Code, un assistant de code intégré aux environnements de développement, l'adoption de Mercury 2.5 a réduit la latence de compaction de 82 % — la durée de traitement tombant de 150 secondes à 27 secondes. L'économie sur les coûts d'inférence atteint 90 %. Pour une équipe qui facture à l'usage ou optimise ses marges sur un produit SaaS, ce gain est structurant.
Du côté d'OpenCall, plateforme d'agents vocaux, le percentile 99 de latence est passé de plusieurs minutes à une seconde. La latence médiane se stabilise à 170 millisecondes. Pour des applications temps réel — voix, chat instantané, copilotes d'IDE — ce seuil ouvre des cas d'usage qui restaient inaccessibles avec des modèles autorégressifs standard.
Ce que les équipes techniques doivent en retenir
Mercury 2.5 supporte trois capacités critiques pour l'intégration dans des pipelines modernes : le raisonnement ajustable (contrôle du temps de réflexion selon la complexité de la tâche), l'exécution parallèle d'outils, et la génération JSON alignée sur un schéma. Ces fonctionnalités permettent une intégration directe dans des architectures d'agents ou des workflows CI/CD sans couche d'adaptation supplémentaire.
Le modèle est accessible via l'API Inception, Baseten et OpenRouter. Le tarif de lancement — 0,04 $ pour un million de tokens en entrée, 0,15 $ en sortie — représente une réduction de 80 % par rapport au prix catalogue. Les développeurs bénéficient de 100 millions de tokens offerts pour l'évaluation.
Quand privilégier un LLM par diffusion plutôt qu'un modèle autorégressif ?
La règle empirique qui se dégage de 2026 : préférez les LLM par diffusion pour les tâches à volume élevé et faible complexité — complétion de code, résumés courts, extraction d'entités, réponses structurées. Conservez un modèle autorégressif plus puissant pour le raisonnement long, la cohérence sur de très longs documents ou les instructions ambiguës. La combinaison des deux dans un routeur intelligent — Mercury Router est précisément annoncé à cet effet — devient une pratique d'architecture à part entière.
Pour les équipes qui arbitrent entre coût, vitesse et qualité sur leurs pipelines IA, ignorer la catégorie des modèles par diffusion en 2026 revient à renoncer à un levier d'optimisation majeur.