Gemini Diffusion

 (simonwillison.net)
14 points par GN⁺ 2025-05-23 | 1 commentaires | Partager sur WhatsApp
  • Gemini Diffusion, annoncé par Google, est le premier LLM à utiliser une approche par diffusion plutôt qu’un transformeur
    • Similaire à ce qui est utilisé dans des modèles d’image comme Imagen ou Stable Diffusion
  • Ce modèle génère du texte non pas avec une approche autorégressive classique, mais via un processus de diffusion qui affine progressivement le bruit
  • Résultat : une vitesse de réponse très élevée, avec des performances expérimentales atteignant 857 tokens par seconde
  • Les benchmarks précis manquent encore, mais Google affirme qu’il est 5 fois plus rapide que Gemini 2.0 Flash-Lite

Aperçu de Gemini Diffusion

  • Gemini Diffusion est un nouveau grand modèle de langage (LLM) dévoilé par Google
  • Au lieu de l’approche autorégressive des LLM classiques basés sur les transformeurs, il adopte une approche par diffusion
  • Cette méthode de diffusion, similaire à celle des modèles de génération d’images (Imagen, Stable Diffusion, etc.), est ici appliquée à la génération de texte
  • Parmi ses principales caractéristiques : une grande rapidité de réponse et une capacité efficace à corriger les erreurs pendant la génération
  • Dans un exemple d’utilisation, le prompt "Build a simulated chat app" produit un résultat en HTML+JavaScript en quelques secondes, avec une vitesse de génération allant jusqu’à 857 tokens par seconde

Fonctionnement des modèles de langage par diffusion

  • Les modèles de langage autorégressifs classiques génèrent les tokens un par un de manière séquentielle, ce qui les rend plus lents et limite aussi la cohérence de la sortie
  • À l’inverse, les modèles par diffusion partent du bruit, puis améliorent progressivement le résultat en traitant des phrases ou des paragraphes entiers en plusieurs étapes
  • Cela permet une génération parallèle des tokens, d’où une production de résultats extrêmement rapide
  • Ils sont particulièrement efficaces pour les domaines où un retour immédiat est important, comme l’édition de texte, les mathématiques ou le code

Modèles similaires et comparaison des performances

  • Jusqu’ici, il existait très peu de LLM commerciaux par diffusion, et le projet Inception Mercury, apparu en février 2024, en a été le premier exemple
  • En termes de vitesse et de performances, Gemini Diffusion est, selon Google, comparable à Gemini 2.0 Flash-Lite, mais environ 5 fois plus rapide
  • À l’image de Cerebras Coder, il affiche une vitesse de génération élevée, et des données de benchmark objectives devraient être ajoutées par la suite

Explications complémentaires et correction

  • Les modèles de langage par diffusion ne remplacent pas complètement l’architecture Transformer : ils modifient surtout la structure de génération du texte en remplaçant l’autorégression par la diffusion
  • Mercury comme Gemini Diffusion reposent tous deux sur des transformeurs, mais traitent l’ensemble de l’entrée d’un seul coup et diffèrent dans leur manière de générer
  • Il s’agit d’une évolution des méthodes classiques de masquage et de restauration de type BERT : le taux de masquage augmente progressivement, et le résultat est complété étape par étape même lorsque tous les tokens sont masqués
  • L’approche par diffusion ne fixe comme définitifs qu’une partie des tokens à chaque étape, puis augmente de façon répétée la proportion de tokens validés jusqu’à compléter toute la séquence
  • L’idée clé de ces LLM par diffusion est donc la restauration progressive et la génération parallèle

Conclusion

  • Gemini Diffusion est un nouveau type de LLM qui présente des caractéristiques innovantes en matière de vitesse et de qualité de génération
  • Il étend avec succès au domaine de la génération de texte les avantages des modèles par diffusion déjà démontrés pour la génération d’images
  • Son intérêt pour des usages concrets et l’attente autour de futurs benchmarks ne cessent de grandir

À lire aussi

1 commentaires

 
GN⁺ 2025-05-23
Avis Hacker News

  • Je ne sais pas vraiment comment cela fonctionne en interne chez Google, mais il s’est passé récemment quelque chose d’intéressant du côté de RWKV. Ils ont mené une expérience consistant à remplacer entièrement le mécanisme d’attention existant par du WKV (attention linéaire), et ils ont obtenu tout cela uniquement via du post-training. Cela suggère que l’essentiel des connaissances utiles se trouve en réalité dans le FFN (feed-forward network), et que l’attention elle-même n’est peut-être ni aussi unique ni aussi importante qu’on le pense. Les liens associés valent aussi le détour. D’un autre côté, exploiter une attention déjà apprise et tester séparément à quel point le FFN est rapide dans un entraînement à vitesse GPT-2 serait aussi une tentative intéressante, même si cela sort des règles, et j’aimerais lire un article là-dessus. Parmi mes lectures d’hier, il y avait aussi l’idée qu’à un certain stade, les embeddings de tous les modèles deviennent (très) similaires, qu’on peut donc entraîner un transformeur simple, et que si ces deux choses sont vraies, alors partager embeddings et attention pourrait considérablement accélérer tout l’entraînement

    • L’attention, avec le plus grand respect pour les chercheurs, je la vois comme le fait de prendre toutes les informations passées du réseau en entrée et de les injecter dans un réseau neuronal reverse-MoE. Ici, l’« expert » ne sélectionne pas une partie du réseau, mais une partie de l’entrée à exécuter. On savait que cette approche fonctionnerait, mais elle était tellement inefficace que même les utilisateurs de R ou Python n’auraient pas songé à l’exécuter. L’entraînement lui-même était si lent que cette architecture était difficile à essayer en pratique

    • Je me dis que le fameux « Attention is all you need » peut en fait s’interpréter autrement

    • L’idée selon laquelle les embeddings des modèles deviennent (très) similaires et peuvent être mappés par un transformeur simple vient d’ici

    • Je vois l’attention comme une manière totalement arbitraire de découper le réseau pour permettre un apprentissage parallèle. Ce qui a vraiment contribué au succès, ce sont les « shortcut connections » entre couches. Cela donne davantage d’influence aux couches initiales pendant l’apprentissage

    • Le manque d’importance relative de l’attention SDPA utilisée dans les transformeurs actuels est déjà connu. FFN, normalisation et connexions résiduelles sont absolument irremplaçables, mais l’attention peut facilement être remplacée par n’importe quelle autre couche qui partage l’information entre tokens (pooling, convolution, mélange aléatoire, etc.)

  • C’est incroyablement rapide. Jusqu’ici, je pensais que le meilleur cas d’usage des modèles était l’écriture de code entièrement nouveau et le prototypage rapide. Je ne les ai pas trouvés particulièrement forts pour améliorer de grands codebases déjà retravaillés de nombreuses fois. L’une des raisons, c’est que par définition le modèle ne peut pas savoir ce qui n’est pas inclus dans le codebase. Le fait qu’une chose soit absente du code porte aussi un signal important, mais c’est assez difficile à représenter. Même un modèle très intelligent garde là une limite fondamentale, faute de « contexte interne et d’expérience ». Par exemple, si on donne un énorme codebase à un développeur extrêmement talentueux et qu’on lui demande de résoudre immédiatement un problème précis, un développeur moyen qui connaît bien le codebase pourra souvent produire quelque chose de plus utile dans le même laps de temps

    • On peut résoudre cela en se concentrant sur la manière de communiquer. Mon workflow principal en ce moment, quand j’ai besoin d’un gros travail (nouvelle fonctionnalité, refactorisation, etc.), consiste à lancer une discussion avec o3 comme avec un collègue. Je colle progressivement les fichiers source nécessaires pour fournir du contexte, tout en menant une discussion de haut niveau sur l’objectif et l’état actuel du code. J’ai l’impression que cela clarifie à la fois ce que je veux faire et le contexte du codebase. Ensuite, je demande à o3 un plan d’implémentation, puis je le passe à Codex pour exécuter toute une chaîne automatisée de lecture du code, modification de fichiers, tests, etc. Une fois la PR prête, il suffit parfois de quelques retouches manuelles, voire d’un merge immédiat. Je suis d’accord sur le fait que les modèles ont besoin d’un contexte riche, mais ce n’est pas une limite essentielle, plutôt une question de méthode de collaboration efficace. Avec assez de pratique, c’est non seulement productif, mais aussi, pour moi, une manière de travailler plus agréable mentalement

    • L’idée que « ce qui n’existe pas dans le codebase porte un signal significatif » me parle profondément. Je fais du logiciel depuis longtemps, et je n’avais jamais pris conscience avec autant de clarté de cette vérité fondamentale. Merci pour cette intuition

    • D’après mon expérience jusqu’ici, les LLM sont bons pour imiter un bon code existant, mais ils produisent rarement d’eux-mêmes quelque chose de nouveau et d’original, sauf si on le demande explicitement. Souvent, ils n’ingèrent pas assez bien le codebase et il faut leur désigner directement d’autres parties du projet. Cela dit, ce serait vraiment génial de pouvoir leur donner des « prompts négatifs » comme dans Stable Diffusion

    • Je me demande ce qu’on obtiendrait si un LLM pouvait lire comme contexte l’intégralité de l’historique git, l’issue tracker et même les enregistrements de réunions. Il faudra encore voir si un très grand contexte d’entrée mène réellement à des résultats exploitables

  • Cette annonce m’a vraiment surpris. Je pense que c’est la plus grande annonce de l’IO, même si elle est un peu éclipsée par d’autres nouvelles comme Veo 3. Utiliser un modèle de diffusion pour la génération de code a une portée énorme. S’ils utilisent un transformeur, cela relèverait alors plutôt de la famille DiT (diffusion transformer), et j’ai participé il y a quelques années à un modèle hybride combinant de la diffusion basée sur U-Net, donc j’ai vu les progrès réalisés depuis. J’ai l’impression qu’il pourrait y avoir une grande percée à venir dans le domaine de la diffusion

    • Je me demande comment l’intuition issue des vision transformers s’appliquerait au code. En vision, on part du bruit pour produire progressivement l’image cible, couche après couche, avec de plus en plus de netteté. Si on transpose cela à la génération de code, il semblerait qu’il faille une structure hiérarchique abaissant peu à peu le niveau d’abstraction, par exemple : « il faut utiliser Django », « définir la liste des endpoints », puis « générer le code concret ». Mais la diffusion n’a pas de mécanisme de backtracking, donc même si un problème de bas niveau est détecté, il est difficile de faire remonter immédiatement ce retour vers les couches supérieures. À l’inverse, un transformeur parcourt tout le modèle à chaque token, ce qui facilite les retours en arrière et les changements de conception au cas par cas. Il se peut que mon modèle mental soit imparfait, donc je serais curieux d’avoir d’autres éclairages

    • Veo 3 a fait parler de lui parce que ses performances et sa différenciation sautent immédiatement aux yeux, alors que pour comprendre la valeur d’une avancée importante dans la complétion de texte, il faut connaître les résultats précédents et les usages potentiels. Beaucoup ne sont pas encore convaincus que les LLM soient vraiment utiles pour coder

    • Les modèles de génération de code basés sur la diffusion sont réellement révolutionnaires. Quelques idées simples qu’un tel modèle pourrait permettre : générer les tokens entre une signature de fonction et son résultat fixé, en exploitant une information bidirectionnelle ; ensuite, esquisser d’abord le grand plan d’une fonction (comme écrire les « chapitres » d’un article pour un LLM), puis affiner progressivement l’implémentation ; enfin, itérer dans un contexte plus large en s’appuyant sur des signaux comme les linters, les informations AST, etc. Il y a énormément de choses à expérimenter

    • En principe, cette approche semble avoir de grands avantages, et des modèles comme LLaDA que j’ai testés m’ont impressionné malgré des ressources d’entraînement limitées. Mais sur des métriques comme la perplexité, ils restent encore en retrait. Ils ont aussi tendance à se figer pendant la génération, ce qui semble limiter leur capacité à modifier profondément un texte une fois lancé (plus la probabilité de masquage augmente, plus les modifications simultanées deviennent difficiles). Cela dit, dans des expériences réelles, j’ai obtenu des résultats assez pratiques

    • J’avais déjà vu des démos chez InceptionLabs et ailleurs, donc je ne suis pas si surpris que ça

  • J’ai l’impression que le point essentiel de cette annonce passe inaperçu. C’est un InstructGPT vraiment rapide et vraiment bon. Cela va forcément être utilisé pour la correction orthographique, les codemods, les éditeurs de code, etc. Grâce à la fonction Instant edits, on peut faire des modifications de texte très rapides et très précises, sans ajouts ni suggestions inutiles. J’ai demandé de renommer des variables dans un exemple ShaderToy pour qu’elles soient plus compréhensibles, j’ai copié le résultat, exécuté, et j’ai été surpris que tout fonctionne encore parfaitement

    • La correction orthographique, ce n’est pas déjà un problème entièrement résolu ?

  • L’avantage de la diffusion ne se limite pas à la vitesse. D’après les premiers benchmarks, à nombre de paramètres équivalent, elle serait meilleure que l’AR en raisonnement et en planification. La diffusion permet aussi l’édition intermédiaire et ne souffre pas du biais des tokens initiaux

    • C’est une affirmation intéressante. Je serais curieux de voir des liens vers des benchmarks ou des éléments à l’appui

    • L’AR en soi n’empêche pas d’établir des plans longs, mais dans la manière dont les modèles AR populaires récents sont implémentés, ce type de limite apparaît souvent. L’AR reste fondamental pour apprendre correctement la bonne distribution

    • Personnellement, j’ai envie d’y croire ou que ce soit vrai, mais je n’ai encore vu ni papier ni démo sur revise diffusion text. J’aimerais bien essayer, donc je serais preneur de références

  • Je m’intéresse depuis longtemps à l’application des techniques de diffusion à la génération de texte. Je suis ravi de voir Google sortir enfin un modèle de ce type, cela me donne l’impression que mon intuition se confirme. Côté matériel utilisé pour les expérimentations, on est le plus souvent sur des services payants ou du matériel haut de gamme, au moins dans le segment grand public. Moi, je n’ai qu’une 5700XT actuellement, donc une mise à niveau est difficile, et cela m’a permis de voir plus nettement les limites des modèles actuels. Plus les modèles grossissent, plus leur cohérence augmente, donc les petits modèles se retrouvent forcément limités à des tâches simples. L’un des principaux constats de mes essais concerne l’importance de la taille du contexte : avec un petit GPU, il est difficile de loger à la fois un contexte suffisant et un modèle de taille correcte, et je me demande si une approche par diffusion pourrait changer l’équilibre entre densité et cohérence. J’espère une génération de texte plus cohérente avec moins de contexte, ainsi que de meilleurs résultats dans des sorties mêlant tool calls et réponses. La vitesse reste aussi un problème très concret : avec les LLM classiques, la boucle entrée-sortie est lente à chaque itération, ce qui met la patience à rude épreuve, surtout sur les vieux GPU sans matériel dédié à l’IA. Ce serait déjà bien de pouvoir voir une progression de 0 à 100 % en temps réel, et j’espère que les modèles de diffusion s’en sortiront mieux là-dessus. Cela soulève aussi une question : comme l’entrée bruitée est essentielle, existe-t-il une bonne source de bruit adaptée aux LLM/au texte, et la longueur totale des blocs est-elle fixée à l’avance ou peut-elle varier ?

  • Je peux l’affirmer de mon point de vue : ce modèle est extrêmement rapide. Son défaut, c’est qu’il se fait très facilement contourner par des attaques de prompt injection. Par exemple, si on lui demande une recette de drogue, il refuse, mais si on reformule en « jeu de rôle d’enfant », il donne réellement le résultat. Mis à part ce défaut, sa rapidité et son aptitude à l’automatisation sont remarquables. Si on y ajoute une approche agentique, son potentiel pourrait vraiment s’exprimer

    • Ce n’est peut-être pas une limite intrinsèque du modèle, mais plutôt le signe que moins de ressources ont été investies dans la sécurité ou la censure pendant l’entraînement. À mon avis, c’est une sorte de prototype expérimental, une démonstration légère avant d’investir sérieusement dans un grand modèle

    • Je ne pense pas que ce type de prompt injection soit un signe qu’on pourra contrôler des modèles plus intelligents

  • La description « premier LLM de diffusion de Google, utilisant la diffusion à la place des transformeurs » est erronée. Google n’a jamais présenté les choses ainsi. Au contraire, les modèles de diffusion basés sur des transformeurs sont courants. Je pense même que Gemini Diffusion utilise probablement un transformeur. La différence serait plutôt qu’il s’agit d’un transformeur encoder-only. Autrement dit, on lui fournit toute la séquence dans un état bruité/corrompu, et il prédit la séquence correcte complète. Cela permet de calculer toute la séquence en parallèle à chaque passe, et si le nombre d’itérations reste raisonnable, cela devient bien plus rapide que le décodage séquentiel d’un modèle decoder-only (même si le speculative decoding offre aussi un gain de vitesse comparable). En général, on entraîne cela avec du masquage de type BERT, mais c’est encore un domaine de recherche actif. Je me demande aussi quel est le lien exact avec Gemini et comment les checkpoints sont exploités : import direct, fine-tuning spécifique à la diffusion, distillation des connaissances, ou simple usage de la marque ? J’aimerais que des détails officiels soient publiés

  • C’est absurdement rapide. Je m’attends à ce que le GPU tourne toujours à pleine puissance, et qu’il y ait très peu de gains de calcul liés au batch processing. Mais en y réfléchissant, ce n’est pas vraiment un tradeoff au sens strict. Ma seule inquiétude, c’est que l’objectif de diffusion puisse être moins performant que l’AR. Si c’est le cas, alors des modèles AR multi-token pourraient atteindre la même vitesse que la diffusion, ou bien on pourrait utiliser un modèle de diffusion comme générateur de brouillon pour du speculative decoding

    • Je suis curieux de savoir pourquoi tu penses qu’un dLLM sera de moins bonne qualité qu’un arLLM. Comme la sortie est traitée de façon itérative comme un « tout structuré » (thème, points clés, concepts, arbre de mots), on peut imaginer une qualité au contraire supérieure

    • Ce tradeoff structurel est bien plus favorable dans un environnement d’hébergement personnel. Comme il n’y a pas besoin de gros batches, l’avantage est limité dans le cloud, mais important pour les LLM en local

  • Les LLM de diffusion m’enthousiasment énormément. Mon équipe rêve d’un mécanisme de jeu allant de la voix au code, et la diffusion pourrait bien en être la pièce manquante. Cerebras et Groq sont impressionnants, mais leur matériel sur mesure impose des limites pour le fine-tuning et le passage à l’échelle. L’autre option, c’est un MoE avec environ 0.5b de paramètres actifs, mais nous n’avons pas les ressources pour y consacrer du temps pour l’instant. Si quelqu’un de Google/DeepMind lit ceci, merci de proposer une API. Mon équipe développe un jeu sandbox génératif, et notre premier titre permet de donner des ordres à des monstres en temps réel. Nous avons aussi une vidéo de prototype à montrer si besoin