Tous les 'Trucs IA Rapide' Étaient des Contournements. DiffusionGemma Est le Premier Modèle Que Vous Pouvez Vraiment Faire Tourner

12 min read

Prédire 1 token à la fois. Voilà ce qui limitait les modèles depuis le début, y compris les modèles locaux.

Cette contrainte n'avait rien à voir avec un matériel insuffisant ou des modèles trop petits. Elle était architecturale, intégrée dès le départ.

Pour générer chaque token, votre GPU charge tous les poids du modèle depuis la mémoire, produit 1 token, puis recommence. Ce goulot d'étranglement de bande passante mémoire explique pourquoi l'inférence locale restait frustrante même sur du matériel décent. Et c'est pourquoi 5 ans d'optimisations (flash attention, quantification, décodage spéculatif) ont toutes contourné le même plafond structurel sans jamais le déplacer.

TLDR : DiffusionGemma génère 256 tokens en parallèle par passe de débruitage, déplaçant le goulot d'étranglement de la bande passante mémoire vers le calcul brut. Sur le papier : 4x plus rapide que Gemma 4 AR, 700+ tokens/sec sur RTX 5090, fonctionne sur RTX 4090. Mais ce n'est pas la vitesse qui rend cela intéressant.

Il y a quelque chose qui se passe quand on réalise qu'on a optimisé la bonne métrique sur la mauvaise couche. Flash attention était une véritable percée, la quantification INT4 était une véritable percée, et le H100 à 40 000$ la carte était une véritable percée pour ceux qui pouvaient se l'offrir. Et rien de tout cela n'a déplacé la contrainte fondamentale. Les poids devaient toujours se charger pour chaque token individuel. Les tensor cores du GPU, conçus pour des opérations matricielles parallèles massives, restaient largement inactifs pendant l'inférence, attendant simplement le prochain cycle mémoire. Chaque ingénieur qui faisait de l'inférence locale sur un GPU grand public haut de gamme ressentait cela comme une frustration sourde : les chiffres devraient fonctionner, mais ils ne fonctionnent pas tout à fait.

Employé de bureau fatigué entouré de papiers d'optimisation versus développeur confiant avec un modèle IA rapide fonctionnant efficacement sur un laptop
Enfin, une optimisation IA qui ne nécessite pas un doctorat et 47 contournements.

La Course que Personne ne Remettait en Question

Flash attention est sorti en 2022. Véritablement brillant : réécrire le calcul d'attention pour qu'il soit conscient des E/S, gardant les valeurs intermédiaires en SRAM au lieu d'écrire constamment vers la HBM. De vraies accélérations, mesurables, déployées partout en 18 mois. L'article a obtenu 15 000 citations en environ 2 ans.

Puis le domaine a continué à ajouter des couches sur la même fondation. Quantification INT4, GGUF, décodage spéculatif, le LPU de Groq construit from scratch autour de l'inférence AR, les H100 à 40 000$ la carte, puis les H200, puis les GB200. Des entreprises entières valorisées à des milliards sur la prémisse que rendre l'AR plus rapide était le problème qui valait la peine d'être résolu. Groq a construit du silicium personnalisé from scratch autour de l'inférence AR, et l'industrie a appelé cela visionnaire. Personne dans la salle n'a suggéré que peut-être l'architecture elle-même était la question.

Toute l'industrie s'est organisée autour d'un seul goulot d'étranglement. Personne n'a remis en question si le goulot d'étranglement était architectural.

Pour être honnête : pourquoi l'auraient-ils fait ? Les modèles étaient livrés, les produits fonctionnaient. La pile d'entraînement, l'infrastructure de service d'inférence, l'écosystème de noyaux CUDA, chaque pattern de déploiement de vLLM à TGI à Ollama, tout cela construit autour de la prédiction autorégressive du prochain token. Remettre en question l'architecture depuis l'intérieur de cet écosystème, c'est comme remettre en question si les voitures devraient avoir des roues pendant qu'on est en train de concevoir un pneu plus rapide. Le coût de changement n'était pas seulement technique. C'était le coût irrécupérable accumulé de l'industrie : chaque noyau CUDA, chaque optimisation de service, chaque achat de matériel justifié par rapport aux chiffres de débit AR.

Inception Labs a été le premier à vraiment livrer quelque chose de différent. Mercury est sorti début 2025, Mercury 2 début 2026, 1 000+ tokens par seconde. Des chiffres vraiment impressionnants. Complètement inaccessible : API commerciale, poids fermés, impossible de le faire tourner soi-même. Utile comme signal de marché, pas actionnable pour quiconque construisant sur son propre matériel.

DiffusionGemma est sorti le 10 juin 2026, poids ouverts sous Apache 2.0, support vLLM dès le jour 0, fonctionnant sur RTX 4090.

Pour la communauté des développeurs, "première version ouverte d'un labo de premier plan" signifie support vLLM jour 0, une fiche de modèle HuggingFace, intégration Unsloth, et une communauté qui aura des fine-tunes intéressants en quelques jours. L'écart entre un article de recherche et quelque chose sur lequel on peut vraiment construire s'est refermé environ 18 mois plus vite que quiconque ne s'y attendait quand Gemini Diffusion a été annoncé comme expérience à I/O 2025.

C'est la différence entre "quelqu'un a prouvé que ça marche en théorie" et "tu peux télécharger les poids ce soir."

5 ans de contournements. Le vrai correctif tournait sur ton GPU hier.

Ce que DiffusionGemma Change Vraiment (et ce qu'il ne Change Pas)

TITLE "AR vs Diffusion: Where the Bottleneck Lives" + subtitle "Memory-bound vs compute-bound inference on the same GPU". Metaphor: two factory assembly lines side by side: left line labeled AUTOREGRESSIVE has a giant VRAM warehouse door that opens and closes for every single item on the belt, workers labeled TENSOR CORES sit idle waiting; right line labeled DIFFUSION loads once at start then all workers process 256 items simultaneously. Style: engineer blueprint, thick pen technical drawing, cross-section view, grid paper background. Palette: deep navy #1a2744, electric blue #3b82f6, amber #f59e0b, white #ffffff, light gray #e5e7eb. Content: left side station labels LOAD WEIGHTS x256 TIMES, PRODUCE 1 TOKEN, REPEAT 256x; right side labels LOAD WEIGHTS ONCE PER PASS, GENERATE 256 TOKENS IN PARALLEL, REFINE VIA DENOISING. Highlight: amber oversized bottleneck arrow on left labeled THE REAL CEILING in bold annotation box; right tensor cores block highlighted electric blue labeled NOW THE CEILING SHIFTS. Footer: copyright rentierdigital.xyz. NOT flat corporate infographic, NOT minimalist startup aesthetic.
Comparaison des Goulots d'Étranglement GPU AR vs Diffusion

La boucle d'inférence AR est limitée par la mémoire. Pour générer 256 tokens, votre GPU charge la matrice de poids complète depuis la mémoire 256 fois, 1 chargement par token. Les tensor cores, conçus pour des multiplications matricielles parallèles à grande échelle, exécutent leur calcul réel en environ 1% du temps total. Les autres 99% consistent à attendre que les données arrivent de la VRAM. Imaginez doter une cuisine de chefs étoilés Michelin et faire passer chaque plat par un entrepôt à 300 mètres entre les services. C'est votre H100 sur l'inférence AR. C'est pourquoi faire évoluer les FLOPS théoriques d'un GPU se traduisait rarement linéairement en vitesse d'inférence : vous n'étiez pas limité par le calcul, vous étiez limité par la mémoire, et acheter une carte avec plus de tensor cores aidait moins qu'acheter une avec une bande passante mémoire plus élevée. Chaque optimisation depuis flash attention travaillait à raccourcir cette attente de 99%, pas à l'éliminer. Le plafond était toujours le même plafond, juste approché sous un angle légèrement différent.

DiffusionGemma charge les poids une fois par passe de débruitage et génère 256 tokens en parallèle. Le goulot d'étranglement se déplace. Les tensor cores sont maintenant le vrai plafond, exécutant une attention bidirectionnelle sur le bloc complet de 256 tokens à chaque passe avant. C'est pour cela que ces puces ont été conçues. Le mur de bande passante mémoire ne disparaît pas, il cesse d'être ce qui vous limite.

Chiffres de Google et NVIDIA : 700+ tokens/sec sur RTX 5090, 1 000+ sur H100, 4x plus rapide que Gemma 4 AR sur matériel équivalent. Le modèle fait 26B paramètres en Mixture of Experts, 3,8B actifs pendant l'inférence, fonctionne en 18GB VRAM quand quantifié.

Les limitations sont réelles et méritent d'être énoncées clairement.

DiffusionGemma traîne derrière Gemma 4 AR sur les benchmarks de raisonnement par une marge significative. AIME 2026 : 69,1% vs 88,3%. LiveCodeBench v6 : 69,1% vs 77,1%. GPQA Diamond : 73,2% vs 82,3%. Ce sont des écarts de 15-20 points sur des tâches de raisonnement difficiles, pas des erreurs d'arrondi.

La fenêtre de contexte est de 8 192 tokens. La plupart des modèles AR actuels fonctionnent à 128K+. Pour tout ce qui est agentique ou à long contexte, c'est un vrai mur. Un fichier TypeScript modérément complexe mange 3 000 tokens. 3 fichiers et vous êtes déjà au plafond.

Google lui-même l'appelle "expérimental". Les recettes de fine-tuning étaient encore en cours de publication au lancement. Le support MLX pour Apple Silicon était incomplet au jour 0. Pour le service cloud à haut volume, les modèles AR se regroupent encore plus efficacement à grande échelle.

La performance est réelle, et le plafond aussi. La question est de savoir si le plafond importe pour votre cas d'usage.

La Preuve au-delà de la Vitesse

Une grille de Sudoku a 81 cases. Chacune est contrainte par sa ligne, sa colonne, et son carré 3x3 simultanément. Pour la résoudre correctement, vous devez garder toutes ces contraintes en vue en même temps.

Un modèle autorégressif génère 1 case à la fois, de gauche à droite, de haut en bas. Quand il remplit la case 72, il ne peut pas revenir et corriger la case 3. Il ne se conditionne que sur ce qu'il a déjà généré. Ce n'est pas un échec d'échelle ou un problème de données d'entraînement. C'est une propriété structurelle de la génération séquentielle. Vous pouvez rendre un modèle AR plus gros, plus rapide, meilleur en reconnaissance de motifs, et il remplira toujours les cases sans résolution de contraintes globales, parce qu'il ne peut structurellement pas regarder vers l'avant.

Google a fait un test direct là-dessus. Modèle de base DiffusionGemma sur des puzzles Sudoku : 0% de taux de réussite. Fine-tuning SFT standard avec une recette JAX sur un dataset Sudoku : 80% de taux de réussite, avec 4x moins d'étapes d'inférence que la baseline.

L'amélioration venait de l'attention bidirectionnelle, pas de la vitesse brute. Chaque token dans le bloc de 256 tokens fait attention à tous les autres tokens pendant la génération. Le modèle voit toute la grille d'un coup. Il propage les contraintes à travers le bloc complet à chaque passe de débruitage et s'auto-corrige avant que la sortie soit finalisée.

Je pense que c'est là que la signification à long terme des LLM de diffusion est sous-estimée, même dans la couverture de lancement. Les chiffres de vitesse font les gros titres. La bidirectionnalité est la propriété la plus intéressante.

Votre codebase est plus difficile qu'une grille de Sudoku. Chaque fonction est contrainte par les types qu'elle retourne, les API qu'elle appelle, les contrats qu'elle assume implicitement à travers les fichiers. Le code infilling (remplir un corps de fonction étant donné ce qui vient avant et après) est structurellement exactement ce problème. Les modèles AR gèrent l'infilling à travers un objectif d'entraînement spécial fill-in-the-middle, qui est un contournement pour la contrainte directionnelle. DiffusionGemma le gère architecturalement. Même classe de problème, couche différente du correctif. Le même pattern apparaît dans les migrations de schéma SQL, la génération de fichiers de config, tout ce où vous remplissez une structure avec des contraintes dures des deux côtés. Une migration ajoutant une colonne doit être cohérente avec le schéma existant et les requêtes en aval qui la référencent. L'AR génère de gauche à droite sans reconsidérer les choix antérieurs basés sur les contraintes ultérieures. Vous pouvez contourner cela avec un prompting soigneux et une génération multi-passes. Des contournements, tous autant qu'ils sont.

J'ai passé 3 mois à chasser des signatures de types subtilement incohérentes à travers les fichiers dans les sessions Claude Code. La fenêtre de contexte divisait les contrats pertinents entre 2 sessions. L'attention bidirectionnelle dans un bloc de génération ne résout pas complètement la cohérence inter-fichiers, mais elle déplace l'origine de l'incohérence. Problème différent, correctif différent.

Quand Changer, Quand Rester

L'arbitrage pour un builder utilisant Claude Code quotidiennement ressemble à ceci.

DiffusionGemma a du sens pour les tâches où le goulot d'étranglement est le débit sur des sorties courtes à moyennes avec des contraintes structurelles : génération de boilerplate en lot, code infilling où le contexte environnant est disponible, remplissage de templates structurés (schémas API, fichiers de config, stubs de migration), cycles d'itération rapides où vous régénérez 10-20 variantes sous 4 000 tokens. Le modèle est sorti maintenant, poids ouverts sous Apache 2.0, prêt vLLM, déployable sur RTX 4090. Le coût API variable sur ces tâches tombe à zéro. L'économie change d'une manière spécifique et réelle pour les workflows locaux à haute répétition.

Restez sur Claude pour les chaînes de raisonnement multi-étapes, le débogage qui nécessite de tracer la logique à travers de nombreuses étapes, les décisions d'architecture qui ont besoin d'un grand contexte cohérent, toute tâche de production où vous avez besoin de plus de 8K tokens en une seule passe, tout ce qui est dans le niveau lourd en raisonnement où ce delta de 15-20 points est la différence entre une sortie utile et une réponse plausible mais fausse.

La contrainte de fenêtre de contexte est le vrai limiteur pratique. 8 192 tokens semble beaucoup jusqu'à ce qu'un seul fichier modérément complexe en prenne 3 000. Ce n'est pas un problème de fine-tuning. C'est intégré dans la taille de bloc de génération actuelle. Les versions futures pousseront cela vers le haut. Pour l'instant, cela fait de DiffusionGemma un outil spécifique à une tâche, pas un remplacement général drop-in.

Karen de la Comptabilité demanderait si cela justifie d'acheter un second GPU. La réponse honnête : si vous faites déjà tourner une pile de modèles locaux sur RTX 4090, c'est une situation pull-and-test, pas une décision matérielle. Si vous partez de rien, le point mort sur du matériel dédié vs des crédits API nécessite des chiffres de débit réels de votre workflow réel, pas de l'enthousiasme sur le benchmark 😅. La recette de fine-tuning JAX dans le guide développeur est suffisamment documentée qu'une expérience SFT de 500 échantillons sur un domaine spécifique est un projet de weekend (plus réalisable que "je vais réécrire ça en Rust ce weekend" en tout cas).

Côté infra : si vous routez déjà des tâches à travers différents backends de modèles, le pattern derrière construire des agents natifs CLI pour des workloads sensibles au débit devient plus pertinent avec un backend de diffusion local dans le mix. DiffusionGemma s'intègre proprement dans cette architecture.

L'Hypothèse que Vous n'avez Jamais Remise en Question

J'ai une intégration WooCommerce dans ma pipeline qui parse des flux CSV de distributeurs dans un format qui n'a pas changé depuis 2019. J'ai reconstruit l'infrastructure environnante 3 fois. Le parser CSV est toujours la même fonction, même ordre de colonnes, même contournement regex pour un cas limite que j'ai trouvé en 2021. Personne n'y touche parce que ça marche. La question "est-ce que ça devrait encore être un parser CSV en 2026" n'a jamais été posée. À un moment donné, ça a cessé d'être une décision et c'est devenu du mobilier.

Chaque pile a du mobilier.

Le pattern apparaît chaque fois qu'une contrainte technique reste stable assez longtemps pour devenir invisible. En 2023, l'inférence locale signifiait charger un modèle 7B et regarder les tokens arriver à 3 par seconde. La latence rendait cela inutile pour tout ce qui était interactif. Les développeurs l'ont essayé, l'ont trouvé impraticable, sont passés aux appels API, et la décision s'est solidifiée : l'inférence locale c'est pour les hobbyistes, le vrai travail passe par l'API. Ce que personne n'a encodé dans cette décision, c'était la date d'expiration. "L'inférence locale est lente" sonne comme un fait sur la physique. "L'inférence locale sur du matériel 2023 avec des modèles 2023 était trop lente pour ce cas d'usage" est une affirmation sur un contexte spécifique, et les contextes spécifiques changent.

L'AR n'a pas été choisi par rapport à la diffusion parce que quelqu'un a fait une comparaison et conclu que c'était mieux. Il a été choisi parce que la génération de texte par diffusion n'était pas viable. L'hypothèse "on utilise AR" était une contrainte pragmatique qui est devenue invisible au moment où elle a cessé d'être contestée.

Si vous réfléchissez à quels défauts dans votre pile valent la peine d'être revisités, comment j'ai rendu les décisions de routage intentionnelles avec les contrats de prompt est par où j'ai commencé. Ou si la pile elle-même est un territoire plus nouveau, Vibe Coding, For Real couvre la construction sur des principes explicites dès le départ, disponible gratuitement sur Kindle Unlimited.

Pour les builders : si votre workflow a une couche de génération répétitive avec des contraintes structurelles, commencez par la recette de fine-tuning Sudoku dans le guide développeur. Lancez-la, regardez ce qui change entre 0% et 80% de précision, et demandez-vous ce que cela implique pour vos propres tâches lourdes en contraintes.

La décision de routage est maintenant une vraie décision d'architecture : pas quelle API est moins chère ce mois-ci, mais quelle contrainte structurelle ce modèle peut résoudre que l'autre ne peut architecturalement pas.

Sources

Cet article peut contenir des liens d'affiliation. Si vous cliquez dessus, je pourrais gagner une petite commission (ça ne vous coûte rien, et ça m'aide à continuer à livrer des articles de qualité chaque jour pour votre plaisir de lecture).