Mercury - Modèle de langage ultra-rapide basé sur la diffusion

 (arxiv.org)
10 points par GN⁺ 2025-07-08 | 1 commentaires | Partager sur WhatsApp
  • Mercury est un nouveau grand modèle de langage (LLM) commercial qui exploite une approche par diffusion (Diffusion)
  • Ce modèle se distingue par sa capacité à prédire plusieurs tokens en parallèle, sur la base d’une architecture Transformer
  • Mercury Coder constitue le premier ensemble de LLM à diffusion, développé pour l’écriture de code, et proposé en deux tailles : Mini et Small
  • Sur GPU NVIDIA H100, il enregistre un débit de 1109 tokens/s (Mini) et 737 tokens/s (Small), avec des performances jusqu’à 10 fois plus rapides que les modèles existants orientés vitesse à qualité équivalente
  • Lors de benchmarks en usage réel et d’évaluations développeurs comme Copilot Arena, il a obtenu la 2e place en qualité et la 1re place en vitesse, et propose aussi une API publique ainsi qu’un playground

Aperçu

  • Mercury est une nouvelle série de grands modèles de langage basée sur la diffusion et représente une nouvelle génération de LLM fonctionnant à l’échelle commerciale
  • Tous les modèles sont paramétrés avec une architecture Transformer et entraînés à prédire plusieurs tokens en parallèle
  • Ce rapport présente principalement la première gamme de Mercury Coder, conçue pour les applications de génération de code
  • Mercury Coder est actuellement disponible en deux tailles de modèle : Mini et Small

Contributions principales

  • Mercury Coder atteint un nouveau niveau state-of-the-art dans l’équilibre entre vitesse et qualité
  • Selon l’organisme d’évaluation externe Artificial Analysis :
    • Mercury Coder Mini : 1109 tokens par seconde
    • Mercury Coder Small : 737 tokens par seconde sur GPU NVIDIA H100
    • Jusqu’à 10 fois plus rapide en moyenne que les modèles frontier les plus rapides, avec une qualité comparable
  • Des résultats d’évaluation supplémentaires sont également fournis sur des benchmarks de code couvrant divers langages de programmation et cas d’usage
  • Dans un environnement développeur réel (Copilot Arena) également :
    • 2e place en qualité
    • 1re place absolue en vitesse
  • Prend en charge une API publique ( platform.inceptionlabs.ai ) et un chat playground gratuit ( chat.inceptionlabs.ai ) accessibles à tous

Structure de la table des matières

  • Introduction
    • Contributions principales
  • Inception Mercury Model Family (présentation de la famille de modèles)
    • Processus d’entraînement (Training)
    • Méthode d’inférence (Inference)
  • Capabilities (fonctionnalités du modèle)
    • Performances de référence (Baselines)
    • Capacités de génération de code (Coding Capabilities)
      • Benchmarks d’évaluation (Evaluation Benchmarks)

En résumé

  • Mercury combine une conception innovante de LLM basé sur la diffusion et une architecture de prédiction parallèle afin d’offrir une vitesse écrasante et une qualité élevée dans la génération de code
  • Avec plusieurs tailles de modèle, de solides benchmarks en conditions réelles et une grande facilité d’accès, il propose une option compétitive aussi bien pour les usages commerciaux que pour les environnements de développement

À lire aussi

1 commentaires

 
GN⁺ 2025-07-08
Avis Hacker News

  • Souligne que l’adoption d’agents LLM risque de transformer les performances de test en goulot d’étranglement CPU encore plus sévère, alors que toutes les équipes sont déjà limitées par la vitesse de leur CI
    Même si un agent écrit du code 100 fois plus vite qu’un humain, cela ne sert à rien si les tests prennent une heure
    Sur beaucoup de projets où j’ai travaillé, énormément de temps développeur était gaspillé à attendre que les changements soient pris en compte, et de nombreuses exécutions étaient limitées par les E/S ou par le manque de workers
    Si des agents de code transforment rapidement des tickets simples en PR puis réagissent aux échecs de test en corrigeant en temps réel, le goulot d’étranglement de la CI va empirer
    La plupart des environnements de test de projet ont une grande marge d’amélioration, mais dans les faits on a fini par considérer comme normale une CI lente et coûteuse, sans réel progrès depuis des années
    La CI est même devenue plus lente dans certains cas, par exemple quand on désactive le cache pour isoler complètement les builds, ou quand on passe de l’on-premise à des VM cloud plus lentes
    La vitesse de Mercury est complètement folle et, d’après quelques essais, la qualité du code était excellente et précise, mais le défi est désormais de faire suivre l’exécution des tests à cette cadence

    • J’ai du mal à croire que, sur la plupart des projets où j’ai travaillé, autant de temps développeur soit perdu à attendre l’approbation des PR
      Du point de vue de l’entreprise, le temps développeur coûte bien plus cher que le temps machine, donc si les développeurs se plaignent, il suffit de doubler le nombre de workers CI
      Chez Google, lors du débogage de tests instables, il arrivait de lancer 10 000 exécutions sur 10 000 machines pour trouver des échecs très rares
      Mon entreprise actuelle propose quelque chose de similaire : avec une seule commande, on exécute tous les tests en parallèle sur 1 000 workers afin d’obtenir un retour en moins de 5 minutes même sur un projet de 1M LOC
      Isoler complètement les builds et ne pas utiliser de cache sont deux sujets différents ; on peut isoler totalement les builds tout en exploitant au maximum tous les caches

    • Si la vitesse d’implémentation augmente, le goulot d’étranglement se déplacera vers les PM, ce qui pourrait réduire fortement les conflits à mesure que les changements seront davantage sérialisés
      On pourrait aussi assister à un retour des langages de spécification (comme TLA+), les agents pouvant les écrire et les vérifier rapidement, ce qui réduirait le nombre total de tests d’intégration
      Quand des agents d’arrière-plan nettoient du code dupliqué, ils peuvent aussi nettoyer les tests dupliqués
      L’IA semble susceptible de travailler plus efficacement que des équipes d’ingénieurs humains sur des architectures monolithiques, ce qui augmenterait la couverture de tests exécutables en local, réduirait les flaky tests et allégerait la charge CI
      Même si l’IA améliore l’efficacité, elle générera aussi plus de code, plus vite, avec de nouveaux problèmes en continu ; je suis convaincu que de nouveaux problèmes à résoudre par les ingénieurs humains continueront d’apparaître

    • Les LLM conviennent pour des corrections rapides de moins de 100 lignes ou pour servir de rubber duck, mais les injecter directement dans la pipeline CI d’un gros projet risque de faire perdre des centaines d’heures de productivité
      Si au lieu d’améliorer sa capacité à écrire du code on passe son temps à faire du prompt tuning et à ajuster le contexte, cela n’a aucun intérêt
      J’ai l’impression qu’il y a beaucoup trop de confiance dans le tooling LLM, qui selon moi s’applique mal aux systèmes complexes
      L’idée de lâcher un LLM sans supervision sur un dépôt critique me paraît impossible, « sauf sous la menace d’une arme »
      Au final, on finit par retravailler à moitié ce que produit le LLM, et dans ce cas autant le faire soi-même

    • Avant l’automobile, on dépensait très peu pour l’essence, l’huile ou l’entretien, mais à mesure que le système évolue, l’infrastructure annexe et les coûts qui vont avec suivent aussi
      Avec l’IA, soit on résout les goulots d’étranglement, soit on crée plus de fonctionnalités pour maximiser les revenus, puis on utilise ces revenus supplémentaires pour acheter plus de ressources CI : une boucle de renforcement
      L’IA ne change pas grand-chose au fait d’ajouter 10 développeurs de plus ; il est donc normal que les coûts de support augmentent
      Cela invite à se demander si l’on peut argumenter de manière rationnelle en faveur de plus de ressources CI grâce aux gains d’efficacité, ou proposer une direction d’optimisation
      Je me demande combien coûte une machine de ressource CI

    • J’ai nettement accéléré la CI d’une application Python grâce à la toolchain d’astral.sh et à l’installation de paquets via uv avec cache
      Je vais bientôt remplacer mypy par le type checker d’astral, ce qui devrait encore accélérer les choses
      Pour les applications avec frontend, les tests Playwright seront probablement la partie la plus lente, mais ce n’est pas le cas sur d’autres applications
      (P.S. : si Mike est bien la personne à laquelle je pense, c’est le SRE avec qui j’ai travaillé sur Google Maps au début des années 2000, donc son avis m’inspire confiance)

  • J’ai demandé un motif d’expression régulière dans le playground Mercury, et le modèle a commencé par élaborer son propre plan, écrire le motif, puis générer des tests
    Sauf qu’il a continué à ajouter des tests sans fin jusqu’à atteindre la limite de contexte, moment où la réponse s’est interrompue
    Vers une trentaine de tests, il a commencé à mal annoter les commentaires de résultat, et au-delà de 120, les entrées de test elles-mêmes sont devenues bizarres, remplies de caractères aléatoires
    Le motif lui-même n’était pas correct non plus, mais ce phénomène de « boucle infinie » était encore plus intéressant

    • Pour info, je me souviens que, jusqu’à récemment encore, des LLM généralistes produisaient eux aussi ce genre de sortie répétitive ressemblant à une « quasi-boucle infinie »
      Ils restaient coincés dans un schéma où seule une petite partie de la sortie changeait

    • Je pense que c’est une preuve typique qu’on ne peut pas produire du code correct uniquement par prédiction de tokens
      Les LLM n’ont de toute façon pas été conçus à l’origine pour raisonner sur le code

  • En lisant le rapport technique, j’ai constaté que Mercury est basé sur l’article Lou et al. 2023, SEDD
    J’ai été le premier (probablement) à réimplémenter SEDD from-scratch, avec le code en open source
    J’ai aussi implémenté moi-même la méthode de denoising complexe
    Je l’ai conçue pour qu’elle soit plus propre et plus lisible que le SEDD d’origine, et elle peut tourner en quelques heures sur un seul GPU avec un dataset jouet

  • À noter que DeepMind a également un modèle Gemini basé sur la diffusion (lien)
    Après l’avoir testé moi-même, j’ai trouvé la vitesse aussi folle que celle de Mercury, mais la qualité des réponses nettement inférieure à celle des autres Gemini

    • Après un essai rapide, je suis d’accord : la vitesse est impressionnante, mais le taux de bonnes réponses chute beaucoup

    • Je me demande si la démo Gemini Diffusion est gratuite
      Je suis sur liste d’attente depuis plusieurs jours et je regrette de ne pas avoir encore pu l’essayer

  • Personnellement, ce type de progrès m’enthousiasme énormément
    Lors d’une game jam récente, j’ai codé un petit jeu avec l’IA, et plus de la moitié du temps était passée à attendre les résultats
    Si au lieu de 1 à 2 minutes par prompt il ne faut attendre que 10 secondes, on peut faire cinq à dix expérimentations pendant le temps qu’il fallait auparavant pour un seul test
    Mercury n’est pas encore assez mature pour un usage vraiment pratique, mais Claude 3.0 était lui aussi insuffisant il y a un an, donc on peut s’attendre à de nets progrès
    La suite est vraiment prometteuse

  • Après avoir essayé le playground Mercury, la vitesse est vraiment remarquable
    La visualisation du mode diffusion est originale, mais en pratique elle semble surtout montrer un processus où un bruit de lignes visualisé est progressivement raffiné vers un état plus précis
    En réalité, j’y vois plutôt un processus de convergence, dans un espace vectoriel arbitraire, vers des tokens de plus en plus certains

    • Certains modèles de diffusion textuelle utilisent un espace latent continu, mais les performances ne sont pas très bonnes
      Ces derniers temps, la plupart se concentrent plutôt sur la prédiction de vrais tokens de sortie et corrigent l’état précédent étape par étape jusqu’au résultat final
      Je recommande cette explication du fonctionnement de la diffusion textuelle

    • Lien : https://chat.inceptionlabs.ai/

    • C’est vraiment absurdement rapide

  • Il reste énormément de marge d’optimisation dans la plupart du code proche du GPU
    Mais je me demande si le papier arXiv relève davantage du marketing que de la recherche proprement dite
    Je suis preneur d’autres avis

    • Ce n’est pas complètement faux, mais ce n’est pas non plus la première fois qu’on voit ce genre de cas sur arXiv

  • Tarification du modèle Mercury
    1 dollar par million de tokens en sortie, 0,25 dollar par million de tokens en entrée
    Voir la tarification détaillée ici

    • Le prix est un peu élevé
      Pour les usages sensibles aux performances, en comparant Mercury à Groq (Llama 3.1 8b, Llama 4 Scout), les performances étaient similaires mais les prix de Groq étaient bien plus avantageux
      J’attends avec intérêt l’arrivée de modèles de diffusion open source

  • Dans le code du playground et les réponses API, on voit gpt-3.5-turbo et "openai": true, ce qui fait se demander si, en réalité, ils n’appellent pas OpenAI au lieu de leur propre dLLM
    La fonction d’effet de diffusion en haut à droite ressemble à une simple animation

    • La vitesse est trop proche du temps réel pour qu’on puisse croire qu’ils utilisent vraiment un backend OpenAI

  • Tout cela a l’air formidable, mais
    si l’on soumet du contenu utilisateur au service, les conditions accordent à Inception une licence mondiale, non exclusive, perpétuelle, sans redevance, gratuite et entièrement cessible
    Autrement dit, ils peuvent utiliser le contenu des utilisateurs pour entraîner leurs modèles d’IA
    (Il existe toutefois une clause d’exception indiquant que ce qui transite via OpenRouter n’est pas utilisé pour l’entraînement)