Google DeepMind a sorti DiffusionGemma cette semaine, un modèle ouvert expérimental qui fait quelque chose que la plupart des modèles de langage ne font pas : il génère du texte comme un modèle d'image génère une image. Là où un LLM autorégressif normal écrit un token à la fois, de gauche à droite, comme une machine à écrire, DiffusionGemma part d'un bloc de tokens placeholders aléatoires et débruite le bloc entier d'un coup, jusqu'à 256 tokens par forward pass, en faisant plusieurs passes de raffinement jusqu'à ce que le texte converge. Parce que le bloc entier est présent dès le départ, l'attention est bi-directionnelle, chaque token peut attendre à chaque autre, et le modèle peut réviser un token antérieur après en avoir vu des plus tardifs, une sorte d'autocorrection en continu que le paradigme gauche-à-droite peut pas faire. C'est un Mixture of Experts de 26 milliards de paramètres qui en active 3,8 milliards par étape, bâti sur la famille Gemma 4 avec de la recherche en diffusion reportée de Gemini Diffusion, sorti sous Apache 2.0 avec les poids sur Hugging Face et une empreinte quantifiée qui tient dans 18Go.
La vitesse est le chiffre vedette et elle est réelle : environ 4x plus rapide qu'un modèle autorégressif équivalent en génération single-user, que DeepMind chronomètre à plus de 1000 tokens par seconde sur un seul NVIDIA H100 et plus de 700 sur un RTX 5090 grand public. Le caveat honnête est énoncé par Google lui-même, pas enterré : la qualité d'output globale de DiffusionGemma est plus basse que le Gemma 4 standard, et pour du travail critique en qualité la recommandation, c'est d'utiliser le Gemma 4 standard à la place. Donc c'est pas un upgrade gratuit. C'est un échange vitesse-contre-qualité, shippé comme une expérience que tu peux vraiment rouler, et la bonne façon de le lire, c'est comme un artefact de recherche avec des poids utilisables plutôt qu'un remplacement de Gemma 4.
La partie qui mérite toute l'attention d'un builder, c'est pourquoi c'est rapide, parce que ça inverse la règle habituelle. Le décodage autorégressif est limité par la bande passante mémoire : chaque token requiert de lire le modèle entier, donc t'es limité par la vitesse à laquelle les poids bougent, pas par la vitesse à laquelle la puce calcule. Générer un bloc de 256 tokens en parallèle renverse ça, le bottleneck passe de la bande passante mémoire au compute, exploitant la haute intensité arithmétique que les accélérateurs modernes sont affamés d'utiliser. La conséquence pratique est contre-intuitive : DiffusionGemma gagne sur du hardware local à basse concurrence, un seul user sur un GPU, et est pas bâti pour du serving cloud à haut QPS où le batching garde déjà les accélérateurs occupés. DeepMind note même que les machines limitées en bande passante mémoire comme les Mac Apple Silicon pourraient pas voir le même gain. Ça roule sur Hugging Face Transformers, vLLM, MLX et NVIDIA NeMo, avec le support llama.cpp qui s'en vient.
Pour l'arc de vélocité Gemma qu'on track, ça ajoute un nouvel axe. L'histoire jusqu'ici, c'était le même modèle qui devient plus petit et plus vite-quantifié, local-laptop puis local-téléphone. DiffusionGemma est un move différent : pas un Gemma plus petit, un généré différemment, la première fois que le paradigme de diffusion qui fait rouler la génération d'images et de vidéos ship comme un modèle de texte ouvert utilisable que tu peux fine-tuner et rouler. Sa maison naturelle, c'est l'ensemble des tâches où les tokens dépendent de tokens qui viennent plus tard, le code infilling, le texte structuré ou non-linéaire, même le cas jouet que DeepMind montre d'un fine-tune qui résout un Sudoku, où gauche-à-droite est exactement la mauvaise forme. C'est expérimental et plus basse qualité aujourd'hui. Mais un paradigme de génération qui renverse le bottleneck de décodage de la mémoire vers le compute, c'est le genre de chose qui compte de plus en plus à mesure que l'inférence locale devient l'endroit où les builders veulent vraiment rouler, et c'est la lane vers laquelle ça vise direct.
