DiffusionGemma : génération de texte 4 fois plus rapide

• DiffusionGemma est un modèle ouvert expérimental 26B MoE sous licence Apache 2.0 qui génère des blocs de texte entiers simultanément via une approche de diffusion textuelle
• Au lieu de la génération séquentielle de tokens des LLM autorégressifs classiques, il utilise une génération parallèle de 256 tokens pour offrir jusqu’à 4 fois plus de vitesse sur les GPU dédiés
• Lors de l’inférence, seuls 3,8B paramètres sur les 26B totaux sont activés, et avec la quantification, il peut fonctionner dans la limite de 18 Go de VRAM sur des GPU dédiés grand public haut de gamme
• Grâce à l’attention bidirectionnelle et à l’auto-correction itérative, il présente des avantages pour les tâches avec structures non linéaires comme l’édition inline, le remplissage de code, les séquences d’acides aminés et les graphes mathématiques
• Comme il s’agit d’un modèle expérimental privilégiant la vitesse et la génération parallèle de mises en page, la qualité globale de sortie reste inférieure à celle de Gemma 4 standard, et le déploiement de Gemma 4 standard est recommandé pour les applications exigeant la meilleure qualité

---

Une nouvelle proposition de valeur pour les développeurs

• DiffusionGemma est un modèle ouvert expérimental qui explore la diffusion textuelle et génère des blocs de texte entiers simultanément, au-delà du traitement séquentiel token par token des LLM autorégressifs classiques
• Ce modèle est un modèle 26B Mixture of Experts (MoE) proposé sous licence Apache 2.0, avec une génération de texte jusqu’à 4 fois plus rapide sur GPU
• Il s’appuie sur l’intelligence par paramètre de la famille Gemma 4 et sur la recherche Gemini Diffusion, en intégrant une nouvelle tête de diffusion conçue pour maximiser la vitesse de génération
• Les modèles Gemma 4 autorégressifs restent la référence pour des sorties de production de haute qualité, tandis que DiffusionGemma est conçu pour les chercheurs et développeurs qui explorent des workflows locaux interactifs où la vitesse est cruciale

• Compromis clés

  • L’inférence rapide déplace le goulet d’étranglement du décodage de la bande passante mémoire vers le calcul, offrant jusqu’à 4 fois plus de tokens par seconde sur les GPU dédiés
  • Il génère plus de 1 000 tokens par seconde sur une NVIDIA H100 seule, et plus de 700 tokens par seconde sur une NVIDIA GeForce RTX 5090
  • L’accessibilité matérielle vient d’une architecture où seuls 3,8B paramètres sont activés à l’inférence sur les 26B du MoE
  • Avec la quantification, il tient dans la limite de 18 Go de VRAM des GPU dédiés grand public haut de gamme
  • L’attention bidirectionnelle génère 256 tokens en parallèle à chaque passe avant, permettant à tous les tokens de se référencer mutuellement
  • Cela apporte des avantages dans des domaines non linéaires comme l’édition inline, le remplissage de code, les séquences d’acides aminés et les graphes mathématiques
  • L’auto-correction affine itérativement la sortie, le modèle évaluant un bloc de texte entier à la fois pour corriger ses erreurs en temps réel
  • Son statut expérimental et les recommandations de production sont explicites : comme il privilégie la vitesse et la génération parallèle de mises en page, la qualité globale de sortie reste inférieure à celle de Gemma 4 standard

• Exemple de fine-tuning

  • Les performances sur des tâches spécifiques peuvent être améliorées par fine-tuning
  • Unsloth a effectué un fine-tuning de DiffusionGemma pour résoudre des Sudoku, une tâche difficile pour les modèles autorégressifs car chaque token dépend de tokens futurs
  • L’attention bidirectionnelle de DiffusionGemma rend des tâches comme le Sudoku bien plus faciles

Pourquoi utiliser la diffusion pour le texte

• La communauté de recherche en IA explore depuis des années la génération de texte par diffusion, mais son application à des modèles de grande taille restait un défi
• DiffusionGemma aborde ce problème en modifiant la manière dont le modèle utilise le matériel

• Compromis par rapport aux modèles existants

  • La plupart des modèles de langage génèrent un token à la fois, de gauche à droite, comme une machine à écrire
  • Dans le cloud, cette approche est efficace car les serveurs peuvent traiter par lots les requêtes de milliers d’utilisateurs et mutualiser la charge matérielle
  • Lorsqu’un seul utilisateur exécute le modèle en local, cette génération mot par mot n’exploite pas pleinement les GPU ou TPU dédiés, et le matériel passe beaucoup de temps à attendre la prochaine « frappe »
  • DiffusionGemma rédige en une fois l’ébauche d’un paragraphe entier de 256 tokens, donnant ainsi au processeur une charge de travail plus importante d’un seul coup
  • Cette architecture transforme l’inférence du modèle : on passe d’une machine à écrire séquentielle à une grande presse qui imprime des blocs de texte entiers en une seule fois

• Gains de vitesse adaptés à l’inférence locale et à faible concurrence

  • Le gain de vitesse de DiffusionGemma est conçu pour l’inférence locale et les scénarios de faible concurrence
  • Dans le cloud à QPS élevé, les modèles autorégressifs peuvent eux aussi être déployés de façon à saturer efficacement les ressources de calcul
  • Dans les environnements à QPS élevé, l’avantage du décodage parallèle de DiffusionGemma diminue, et le coût de service peut être plus élevé
  • L’avantage en débit est le plus marqué sur un seul accélérateur, avec des tailles de batch faibles à intermédiaires

Comment fonctionne la diffusion textuelle

• La diffusion textuelle applique au texte un processus similaire à la génération d’images par IA, qui part d’un bruit visuel et l’améliore itérativement jusqu’à obtenir une image nette
• À l’étape initiale du canevas, le modèle démarre à partir d’un canevas composé de tokens placeholders aléatoires
• Pendant l’étape d’amélioration itérative, le modèle effectue plusieurs passes, fixe les bons tokens, puis les utilise comme indices de contexte pour affiner le reste
• À l’étape finale d’affinage, le texte converge vers une sortie de haute qualité
• Comme le modèle peut traiter un paragraphe entier pendant la génération, cela permet des comportements tels que la fermeture correcte d’un formatage Markdown complexe ou la génération et le rendu de code quasiment en temps réel

Comment démarrer

• Les poids du modèle expérimental sont proposés sous une licence Apache 2.0 permissive et sont accessibles sur Hugging Face
• Le guide développeur DiffusionGemma explique comment l’intégrer, et A Visual Guide to DiffusionGemma permet d’examiner plus en profondeur ses mécanismes internes
• Le serving du modèle peut être assuré avec MLX, vLLM, Hugging Face Transformers
• L’intégration vLLM bénéficie du support de Red Hat
• Pour des expérimentations rapides, un tutoriel de fine-tuning basé sur Hackable Diffusion, une boîte à outils JAX modulaire conçue pour la composabilité, est disponible
• Le fine-tuning peut aussi être exploré avec Unsloth et NVIDIA NeMo
• Le support officiel de llama.cpp arrivera bientôt

Optimisations et environnement d’exécution

• En collaboration avec NVIDIA, des optimisations ont été réalisées sur toute la pile matérielle afin d’offrir compatibilité et performances à la fois dans les environnements grand public et les systèmes d’entreprise
• Les environnements grand public prennent en charge la quantification pour les GPU GeForce RTX 5090 et 4090
• Les environnements d’entreprise offrent de hautes performances sur Hopper et Blackwell avec des kernels NVFP4 avancés
• NVIDIA DGX Spark, DGX Station pour les déploiements locaux de type desktop side, ainsi que les RTX PRO pour les spécialistes de l’IA, font aussi partie des cibles
• Le support natif NVFP4 en virgule flottante 4 bits accélère le débit de calcul, permettant au modèle de fonctionner plus vite avec une précision presque sans perte
• Il est possible de l’exécuter sur un GPU desktop dédié, via Gemini Enterprise Agent Platform Model Garden, ou via NVIDIA NIM

[GN⁺]

Avis Hacker News

• Je suis passé récemment à OpenCode et j’ai beaucoup testé des modèles qui ne viennent pas des grands laboratoires américains de recherche de pointe, et contre toute attente, celui que j’ai préféré a été Mercury
  Ce n’est pas parce qu’il était « intelligent », mais parce qu’il était incroyablement rapide. C’était plus proche du pair programming que de l’expérience agentique moderne où l’on envoie un prompt puis on attend. J’y retrouvais les avantages de l’IA tout en récupérant un peu de la sensation de coder d’avant l’IA, ce qui rendait le tout plus amusant. Ce n’était pas comme une machine à sous où l’on lance un prompt en espérant que ça parte dans la bonne direction, et je me suis aussi mis à utiliser plus souvent de petits modèles comme Gemini Flash Lite ou GPT Mini/Nano. Je suis impatient de voir arriver un modèle à poids ouverts et je vais le tester tout de suite

  • Si on peut lancer des tests vite et à faible coût, et construire rapidement des indicateurs peu coûteux pour repérer du mauvais code ou du code bricolé, alors quand le temps compte, un modèle rapide mais un peu moins bon peut être préférable à un modèle plus lent mais nettement meilleur
    J’ai obtenu de très bons résultats avec les LLM en utilisant une métrique qui mesure la complexité réelle plutôt que la complexité cyclomatique, puis en automatisant les retours en arrière jusqu’à ce que la complexité ajoutée reste dans une plage raisonnable par rapport à la fonctionnalité
  • Mercury-2 est excellent. Je l’utilise souvent comme arbitre dans llm-consortium
    Sa fenêtre de contexte est relativement petite, donc pour des consortiums plus larges on peut construire quelque chose comme un méta-consortium récursif :
    llm consortium save cns-glm -m glm-5.2 -n 5 --arbiter mercury-2 --judging-method rank
llm consortium save cns-kimi -m k2.6 -n 5 --arbiter mercury-2 --judging-method rank
llm consortium save cns-meta-glm-kimi -m cns-glm -m cns-kimi --arbiter mercury-2 --judging-method synthesis
    Ensuite, si on envoie un prompt à cns-meta-glm-kimi, il choisit le meilleur parmi 5 résultats de kimi et de glm respectivement, puis synthétise les deux réponses gagnantes
  • Je me demande quel impact cela aura sur les modèles locaux pour le code. Si on utilise un modèle de diffusion plusieurs fois plus rapide que Qwen ou Gemma 4, je devrai davantage préparer les choses moi-même, comme avant l’IA, mais ce n’est peut-être pas un mal, et on pourrait travailler en local avec des modèles très rapides et très peu coûteux
    Si on n’effectue pas de longs calculs lourds, il me semble aussi que le coût d’exécution sur du matériel local pourrait être plus faible
  • Je vois exactement ce que tu veux dire. Claude était tellement lent sur des projets perso que ça me frustrait, alors je suis passé à Google Antigravity et aux modèles Flash, et la différence de vitesse est énorme
    Je garde mieux le rythme et je reste plus concentré sur le travail. Je ne pensais pas que la vitesse ferait une telle différence. Claude vaut le compromis entre temps de réponse lent et complexité de tâche sur de très gros codebases très complexes, mais Antigravity ou d’autres modèles rapides conviennent bien mieux quand on veut itérer rapidement sur de petits développements, exécution et débogage
  • Oui, la vitesse est le point clé. J’adore générer des POJO boilerplate ou des data classes à la vitesse délirante de plus de 300 tok/s, et dans ce genre de cas Flash-Lite est plus utile que GPT-5.5
    Si c’est trop lent, on se retrouve coincé dans cette fichue boucle d’attente asynchrone

• Google continue de montrer sa puissance. Il est surprenant que Gemini ne soit pas plus compétitif que Claude ou les modèles d’OpenAI pour le code ou les usages agentiques, mais il est clair que Google dispose toujours de talents IA parmi les meilleurs du secteur
  Cela dit, Google semble davantage se concentrer sur les cas d’usage tournant sur téléphone ou quasi temps réel que sur les gros LLM orientés raisonnement. Ce type de gains d’efficacité a de fortes chances de devenir très important pour l’IA à l’avenir. L’époque où l’on subventionnait les tokens à bas prix pour enfermer les gens dans un écosystème touche à sa fin, et le moment arrive où il faudra payer le vrai coût. L’entreprise qui trouvera comment faire tourner des modèles vraiment intelligents de manière rentable gagnera. DeepSeek coûte plus d’un ordre de grandeur de moins que GPT 5.5 ou Opus 4.8, et même s’il est moins bon que les deux, il n’est pas catastrophiquement moins bon. Si le meilleur modèle de code me fait vraiment gagner assez de temps humain, je paierai volontiers 10 fois plus, mais quand l’écart atteint 100 fois, comme dans de récents benchmarks où GPT 5.5 Pro coûtait plus de 200 fois plus cher que DeepSeek et environ 30 fois plus cher qu’Opus 4.8, cela devient difficile à accepter

  • Fable coûte deux fois plus qu’Opus et semble assez compétitif face à GPT-Pro, donc si les garde-fous de sécurité excessifs ne posent pas trop de problème, cela peut être une option correcte
    Google a aussi sa propre option de « Deep Research » dans ce domaine, et cela semble bien fonctionner. Le grand avantage de DeepSeek, c’est qu’on peut le faire tourner sur du matériel local sans coût d’API. Si c’est important pour vous, être un peu moins bon qu’Opus ou GPT n’est pas un gros problème
  • Au final, je pense que Google va gagner. Ils se concentrent sur des aspects cruciaux : les performances par watt et par dollar
    Ils développent leur propre matériel d’inférence et vont vers l’edge computing pour réduire la latence et la surcharge de calcul. Les gros LLM ne sont toujours pas rentables, et Google laisse ses concurrents brûler leurs capitaux pour « vendre » aux consommateurs en dessous du coût réel. Même après l’éclatement de la bulle de l’IA, une entreprise comme Google s’en sortira très bien, et cette bulle semble surtout destinée à décoller le vernis de certains géants déjà établis

• Certaines réactions passent à côté des avantages de la diffusion. Cela peut avoir un impact important sur les appareils en périphérie comme les smartphones ou les GPU de PC.
  Le décodeur d’un LLM doit prendre en compte tous les tokens précédents, donc il calcule les tokens un par un. Les décodeurs LLM classiques passent bien à l’échelle si la charge est suffisante pour regrouper plusieurs inférences en batch, et dans cet environnement l’avantage de la diffusion est limité. En edge, le problème est différent. Les accélérateurs d’inférence sont affamés parce qu’ils déplacent sans cesse des poids de plusieurs Go depuis la RAM. La RAM grand public comme la LPDDRx/GDDRx offre une bande passante inférieure à celle de la HBM, et comme les requêtes sont sérialisées il est impossible de mutualiser en batch les calculs sur les poids partagés. La diffusion peut calculer les tokens en parallèle, ce qui atténue le goulot d’étranglement de bande passante mémoire

  • Les appareils edge ne manquent pas seulement de bande passante mémoire, leurs performances de calcul sont aussi très limitées. En pratique, même sans gros batchs, on sature vite la capacité de calcul disponible et on se heurte à des limites nettes de chaleur et de consommation électrique.
    Et dire qu’en inférence edge « les requêtes sont intrinsèquement sérialisées » n’est pas vraiment exact non plus. Il y a plusieurs requêtes en même temps, donc plusieurs chats en cours, et si la capacité mémoire suffit pour stocker le cache KV, le traitement par batch peut s’appliquer. Si un modèle de diffusion produit une qualité inférieure avec plus de calculs, et que l’économie de bande passante mémoire reste ambiguë, je vois mal en quoi cela aide
  • C’est globalement vrai, mais cela mélange l’attention avec la structure autorégressive/causale. Le vrai problème qui empêche d’utiliser davantage de calcul, c’est la structure autorégressive/causale.
    On peut aussi utiliser l’attention dans la diffusion, et ce modèle utilise effectivement l’attention

• NVIDIA propose un endpoint gratuit pour ce modèle. Plus de détails ici : https://build.nvidia.com/google/diffusiongemma-26b-a4b-it ; il faut créer un compte et probablement aussi valider son numéro de téléphone.
  Je lui ai aussi fait dessiner un pélican : https://tools.simonwillison.net/markdown-svg-renderer#url=ht...

  • Avec un modèle vraiment rapide, on pourrait peut-être demander des frames d’animation. Par exemple, frame 1 : pied droit à 12 h, pied gauche à 6 h ; frame 2 : pied droit à 3 h, pied gauche à 9 h.
    Dans ce cas, il faudrait évidemment mesurer non pas en tokens par seconde, mais en frames de pélican par seconde
  • Je me suis inscrit il y a quelques semaines, et malgré la procédure suivie mon compte n’a toujours pas été validé. Tant que le compte n’est pas validé, on ne peut pas utiliser l’API

• Bonne explication visuelle de la façon dont fonctionnent les modèles de diffusion de texte comme DiffusionGemma : https://newsletter.maartengrootendorst.com/p/a-visual-guide-...

• Il y a encore quelques jours, je pensais que Google ne disait plus rien du tout sur les modèles de génération de texte par diffusion après la démo faite à l’I/O il y a un an.
  Il y avait des rumeurs disant que c’était trop coûteux à faire tourner, mais si l’on compare DiffusionGemma et Gemma classique sur le même matériel 1x H100, comme dans les graphiques fournis, cela ne semble pas être le cas. En dehors du fait qu’il soit légèrement moins bon que Gemma, je me demande quel est l’inconvénient de cette vitesse

  • Je pense que la réponse à « je me demande quel est l’inconvénient de cette vitesse » est dans ce passage :
    « Le gain de vitesse de DiffusionGemma a été conçu pour l’inférence locale et à faible concurrence. Dans un service cloud à QPS élevé, les modèles autorégressifs peuvent être batchés efficacement pour saturer le calcul ; l’avantage du décodage parallèle de DiffusionGemma diminue alors, et le coût de service peut être plus élevé »
  • Avec un modèle autorégressif standard, s’il y a 256 utilisateurs on peut par exemple générer 256 tokens d’un coup. Cette approche, elle, peut générer 256 tokens pour un seul utilisateur, mais elle demande plusieurs étapes de propagation avant.
    Donc le processus de diffusion consomme plus de GFLOPs, et si l’on a suffisamment d’utilisateurs on peut déjà équilibrer mémoire et calcul

• « DiffusionGemma inverse cette inefficacité. Au lieu de prédire les mots séquentiellement, il produit en même temps un brouillon de tout un paragraphe de 256 tokens. En donnant au processeur de l’ordinateur des blocs de travail plus gros d’un seul coup, il exploite au maximum le matériel. Il fait passer l’inférence de modèle d’une machine à écrire tapant caractère par caractère à une énorme presse d’imprimerie produisant des blocs entiers de texte d’un seul coup. »
  « Il fonctionne comme un modèle mixture of experts (MoE) de 26B paramètres au total, dont seulement 3,8B paramètres sont activés pendant l’inférence, et une fois quantifié il tient confortablement dans la limite de 18 Go de VRAM des GPU dédiés grand public haut de gamme. »
  Donc Gemma 4 26B est un modèle MoE qui tourne très vite sur mon GPU 24 Go avec ollama. Cela ressemble à du speculative decoding, mais je pensais que cela ne marchait pas avec les modèles MoE. Pour quelqu’un dont ce n’est pas le métier de suivre tout ça, il y a tellement de changements qu’il devient difficile de suivre

  • C’est un autre modèle dont le nombre de paramètres est presque le même, ce qui prête à confusion avec le gemma4 MoE existant. En parcourant rapidement la doc, on ne voit pas clairement si l’un a été entraîné à partir de l’autre d’une façon ou d’une autre.
    Le mécanisme n’est pas le même que le speculative decoding. Le speculative decoding reste séquentiel, généralement quelques tokens à la fois. La diffusion ne fonctionne pas ainsi et traite un bloc de texte d’un seul coup. Je n’ai pas encore lu la documentation, mais j’imagine qu’ils ont entraîné le modèle pour que certains experts restent stables sur l’ensemble du bloc de diffusion

• Sur ma 3090 Ti, je n’atteins même pas les vitesses annoncées, mais c’est amusant de voir la réponse se « remplir ».
  J’ai essayé le test du « pélican SVG à vélo » de Simon et le résultat est assez minimaliste, mais il respecte bien la demande : https://gist.github.com/peterc/7672e74ec1437945e5fca5ce2c1c9... -- obtenu avec une quantification Q4 sur un llama.cpp patché. Je me demande aussi à quel point le résultat de Simon est différent

• À quoi pourrait ressembler un modèle de raisonnement par diffusion ? Est-ce qu’il ferait diffuser longtemps un bloc [thinking] de longueur prédéfinie, puis utiliserait le contenu de ce bloc thinking comme une partie de l’entrée pour le bloc de sortie final ?
  Et au fond, comment un modèle de diffusion détermine-t-il la longueur de sortie ? Est-ce un paramètre fixé à l’avance, ou bien diffuse-t-il un token [end] à un moment intermédiaire ?

  • En lisant le reste des commentaires, j’ai au moins obtenu une réponse. Il est logique que le processus de diffusion lui-même soit par essence un processus proche du raisonnement : https://www.inceptionlabs.ai/blog/introducing-mercury-2

• C’est impressionnant, mais même si les modèles locaux sont déjà corrects, en pratique ils restent clairement en dessous de l’API la moins chère, donc j’ai du mal à me dire que je sacrifierais ne serait-ce qu’un peu de qualité pour gagner en vitesse
  Il y aura sans doute des cas d’usage où cela a de la valeur, mais je suis curieux de voir des exemples concrets de déploiement en production

  • Ça peut convenir pour écrire des tests unitaires ou pour du bootstrap
    Même sans être au niveau d’Opus, c’est faisable, et aussi plus simple à itérer