J’ai fait tourner DiffusionGemma (le dLLM de Google DeepMind) en local : l’effet “imprimerie” à 700 t/s, ça change tout

Salut, Je viens de passer une bonne partie de mon week-end à poncer DiffusionGemma, le modèle expérimental en “open-weights” que Google DeepMind a sorti en juin 2026.

Franchement, au début, j’étais assez sceptique. On nous promet des paradigmes de rupture tous les quatre matins, mais là, on touche à quelque chose de fondamentalement différent.

On oublie complètement le mode d’affichage “machine à écrire” (autorégressif) où le modèle crache ses mots un par un. DiffusionGemma fonctionne comme une imprimerie, ou plutôt comme un négatif photo qui se révèle d’un coup dans un bac d’acide en chambre noire.

Et le plus fou ? Sur ma bécane, ça bombarde à des vitesses hallucinantes. Je vous fais un retour d’expérience complet sous le capot.

Le shift mathématique : Adieu le masque causal

Pour comprendre pourquoi ça va si vite, il faut regarder la théorie. Les LLM traditionnels (Gemma 4, Llama, GPT-4, etc.) découpent la probabilité d’une séquence de texte de manière purement séquentielle :

$$P(W)=\prod {t=1}^{T}P(w{t}\mid w_{1},w_{2},…,w_{t-1})$$

Chaque token dépend uniquement de ce qui est écrit avant. C’est ce qui crée ce goulot d’étranglement infernal sur la bande passante mémoire de nos GPU : à chaque mot généré, la carte doit recharger l’intégralité des poids du modèle. Les cœurs Tensor passent leur temps à attendre les transferts de mémoire.

DiffusionGemma utilise la diffusion de tokens discrets via une chaîne de Markov sur un bloc ou “canevas” de $L = 256$ tokens :

$$P(W)=\int P(W_{0}\mid W_{1})P(W_{1}\mid W_{2})\dots P(W_{N-1}\mid W_{N})dW$$

Au lieu de deviner le mot suivant, le modèle part d’un canevas de 256 emplacements remplis de bruit (des tokens de masquage aléatoires). Grâce à un masque d’attention bidirectionnel, chaque token peut regarder à gauche et à droite en même temps.

Pendant les étapes de débruitage (généralement 20 à 25 étapes), le modèle utilise un mécanisme d’acceptation par limite d’entropie :

1. Il calcule l’entropie de Shannon $H = -\sum P(x) \log P(x)$ pour chaque slot du canevas.
2. Lors des premières passes, seuls les tokens à faible entropie (ceux où le modèle est ultra-confiant, comme les verbes principaux, les noms ou la ponctuation structurelle) sont gelés. Ce sont les “jetons ancres”.
3. Ces ancres réduisent instantanément l’incertitude sur les slots adjacents lors de la passe suivante. Les probabilités s’affinent, et tout le bloc de 256 tokens se fige d’un coup en haute définition.
4. Pour les longs textes, une fois qu’un bloc de 256 tokens est stabilisé, il est verrouillé comme contexte causal (traité par un encodeur autoregressif), et le bloc de 256 tokens suivant commence son processus de débruitage parallèle.

En déplaçant le goulot d’étranglement de la bande passante mémoire vers la puissance de calcul brute (compute-bound), DiffusionGemma sature enfin nos cœurs Tensor qui s’ennuyaient ferme en mono-utilisateur.

Les specs du monstre

• Architecture de base : Conçu sur la plateforme Google Gemma 4.
• Type de modèle : Mixture of Experts (MoE) Transformer.
• Paramètres : 25,2 milliards de paramètres au total, mais seulement 3,8 milliards de paramètres actifs par passage de jeton d’inférence (merci l’architecture MoE).
• Fenêtre de contexte : 256 000 tokens (idéal pour y injecter de gros documents).
• Licence : Apache 2.0. On peut l’intégrer dans des projets commerciaux ou locaux sans aucune contrainte.

Benchmarks en local : Ça donne quoi en pratique ?

J’ai testé le modèle sur deux configurations très différentes pour voir ce qu’il a dans le ventre.

1. Sur ma config principale (NVIDIA RTX 5090) :
   En lançant le serveur vLLM local avec le modèle brut, j’atteins une moyenne impressionnante de 710 à 730 tokens par seconde sur des requêtes de code. En comparaison, un H100 dans le cloud frise les 1100 t/s dans des conditions optimales. Voir une telle réactivité à la maison, c’est presque déstabilisant. Pas de streaming progressif : vous cliquez sur “générer”, vous attendez une fraction de seconde, et un bloc complet de code Rust optimisé apparaît d’un coup sous vos yeux.
2. Sur un Mac mini de test (Apple Silicon – 16 Go de RAM) :
   J’ai chargé la version quantifiée en 4 bits (google/diffusiongemma-26b-a4b-it-4bit) qui se cale confortablement dans environ 18 Go de mémoire virtuelle/VRAM. Évidemment, on n’a pas les accélérateurs d’une grosse carte Nvidia, mais j’ai quand même sorti un solide 130 t/s. C’est parfait pour un serveur d’arrière-plan discret à la maison.

Comment le faire tourner chez vous ?

Pour obtenir ces performances, pas le choix, il faut utiliser des runtimes modernes capables de gérer le décodage parallèle par blocs de tokens.

Le plus simple est de passer par vLLM en local. Voici comment j’ai configuré mon environnement de test :

# Installation propre du gestionnaire uv et de vLLM
pip install uv
uv venv diffusion-gemma-env
source diffusion-gemma-env/bin/activate
uv pip install -U vllm --torch-backend=auto

# Lancement du serveur vLLM compatible OpenAI
export HF_TOKEN="votre_token_hugging_face"
python3 -m vllm.entrypoints.openai.api_server \
    --model google/diffusiongemma-26b-a4b-it \
    --port 8000 \
    --max-model-len 8192

Ensuite, pour interroger l’API, j’ai écrit un petit script Python. Attention : le streaming n’est pas supporté à cause de la génération par blocs. Il faut ajuster le paramètre clé num_inference_steps dans le payload :

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="local-token")

response = client.chat.completions.create(
    model="google/diffusiongemma-26b-a4b-it",
    messages=[
        {"role": "user", "content": "Écris une implémentation ultra optimisée de quicksort en Rust."}
    ],
    temperature=0.0, # Recommandé pour la cohérence structurelle
    extra_body={
        "num_inference_steps": 20 # Le sweet spot entre vitesse et qualité
    }
)

print(response.choices[0].message.content)

(Note rapide : si vous voulez tester directement dans un pipeline Python sans lancer de serveur vLLM, la bibliothèque transformers classique fonctionne très bien à condition d’avoir la version 5.10.1 ou supérieure, en appelant le pipeline avec la tâche any-to-any.)

Multimodalité et “Thinking Mode”

J’ai aussi joué avec les entrées d’images et de vidéos. Le modèle traite nativement les images (jusqu’à 1120 tokens visuels pour garder les détails des graphiques ou des factures en OCR) et les vidéos (jusqu’à 60 secondes max à 1 fps, encodées sous forme de frames). L’audio n’est pas du tout supporté, par contre.

Pour le traitement d’images via vLLM, n’oubliez pas d’activer le runner de modèle V2 avec export VLLM_USE_V2_MODEL_RUNNER=1 pour que l’encodeur bidirectionnel soit bien pris en compte.

Ce qui m’a le plus bluffé, c’est l’activation du Thinking Mode. En forçant des paramètres comme thinking_tokens: 1024 dans la requête vLLM, le modèle s’octroie des cycles internes dans des canaux de raisonnement dédiés. Il produit un cheminement logique complet entre des balises <thinking>...</thinking> avant de générer sa réponse finale. Pour auditer du code ou analyser des schémas d’architecture complexes, c’est d’une aide précieuse.

Pour mesurer tout ça proprement, je me suis codé un petit dashboard Gradio en utilisant time.perf_counter(). Pouvoir mesurer en direct la latence et voir la jauge afficher fièrement plus de 700 tokens par seconde sur des prompts complexes, c’est super gratifiant.

Mes cas d’usage préférés (et ses limites)

Après quelques jours d’utilisation, voici là où il brille et là où il montre ses limites :

• Le top du top : L’infogérance de code (le text infilling bénéficie énormément de l’attention bidirectionnelle), la génération de JSON hautement structuré, et l’analyse OCR de documents denses. C’est ultra-rapide et très fiable sur la structure.
• Les limites : Si vous cherchez un modèle d’encyclopédie capable de vous réciter des faits historiques pointus ou de faire de la création littéraire très nuancée, ce n’est pas son fort. Le modèle est optimisé pour la vitesse locale et l’agilité structurelle, pas pour la mémorisation brute de connaissances massives.

Bref, si vous avez une carte graphique décente ou même un Mac récent avec un peu de RAM, je vous conseille vivement d’aller faire un tour sur la collection officielle DiffusionGemma sur Hugging Face. Les intégrations pour vLLM, Unsloth et NVIDIA NIM sont déjà prêtes.

Ceux qui ont déjà pu jouer avec, vous obtenez quels scores de votre côté en tokens par seconde ?