DiffusionGemma: Google gør lokal tekstgenerering fire gange hurtigere

Google har sendt DiffusionGemma ud som eksperimentel open model, og den interessante del er ikke endnu et Gemma-navn. Det interessante er, at Google forsøger at bryde en af de mest sejlivede begrænsninger i lokale sprogmodeller: token-for-token-generering, hvor modellen skriver som en gammel skrivemaskine og GPU’en står halvt ubrugt imens.

DiffusionGemma er en 26B Mixture of Experts-model, hvor kun 3,8 milliarder parametre er aktive under inferens. Google beskriver den som en tekst-diffusionsmodel, der genererer og forfiner blokke på 256 tokens i parallel i stedet for at producere tekst lineært fra venstre mod højre. Ifølge Google giver det op til fire gange hurtigere tekstgenerering på dedikerede GPU’er, blandt andet over 1.000 tokens i sekundet på en NVIDIA H100 og over 700 tokens i sekundet på en RTX 5090.

Det lyder som benchmark-konfetti, men der er en reel arkitekturpointe her. Hvis du bygger lokale copilots, inline-redigering, kodeudfyldning eller agentværktøjer, er første token og løbende responsivitet ofte forskellen mellem et værktøj der føles levende, og et værktøj brugeren lukker efter tre forsøg. DiffusionGemma peger på en anden inferensprofil end de klassiske autoregressive LLM’er.

DiffusionGemma flytter flaskehalsen fra hukommelse til beregning

Traditionelle sprogmodeller er autoregressive. De forudsiger næste token, føjer den til konteksten, og gentager. I store cloudmiljøer kan man skjule meget af ineffektiviteten ved at batch’e mange brugere sammen. På en lokal workstation, hvor én bruger sidder med én prompt, bliver GPU’en derimod ofte ikke udnyttet særligt effektivt.

Googles påstand med DiffusionGemma er, at diffusionstilgangen flytter flaskehalsen. I stedet for at hente vægte igen og igen for hvert token giver modellen GPU’en en større parallel opgave. Den starter med et lærred af tilfældige placeholder-tokens og raffinerer hele blokken i flere passager. Det minder om billeddiffusion, bare på tekst.

Det giver især mening for lokale workloads med lav eller mellem batch-størrelse. Google er selv ret tydelige om begrænsningen: Ved høj QPS i cloud kan almindelige autoregressive modeller stadig mætte hardware effektivt, og DiffusionGemmas fordel kan blive mindre eller dyrere. Det er en vigtig indrømmelse. Det her er ikke nødvendigvis en ny standard for alle chatbots. Det er et bud på hurtigere interaktive lokale workflows.

Hvad udviklere faktisk kan bruge det til

Den mest oplagte anvendelse er ikke lange essays. Det er korte, hurtige, strukturerede interaktioner hvor modellen skal reagere næsten øjeblikkeligt: inline code completion, redigering af tekst, infilling, små agentbeslutninger, markdown, SVG, matematiske strukturer eller andre opgaver hvor tokens længere fremme i teksten betyder noget for tokens tidligere i teksten.

Googles developer guide fremhæver bidirektionel opmærksomhed som en kernefordel. Fordi hele blokken evalueres samlet, kan modellen i princippet rette fejl undervejs i stedet for at sidde fast i en dårlig venstre-mod-højre-sekvens. Deres Sudoku-eksempel er næsten for pædagogisk, men pointen er god: Nogle problemer er ikke naturligt sekventielle. Hvis alle felter i et gitter påvirker hinanden, er en model der kan se hele lærredet på én gang et mere naturligt værktøj.

For danske udviklere og IT-arkitekter er den praktiske konklusion: DiffusionGemma bør testes som en inferenskomponent, ikke vurderes som en generel GPT-erstatning. Hvis produktet kræver maksimal tekstkvalitet, er standard Gemma 4 ifølge Google stadig anbefalingen. Hvis produktet kræver lokal hastighed, lav latenstid og korte iterative outputs, er DiffusionGemma langt mere interessant.

Open model er ikke det samme som lav risiko

DiffusionGemma udgives under Apache 2.0, hvilket gør den nemmere at eksperimentere med end mange lukkede modeller. Det betyder dog ikke, at man bare skal smide den ind i produktion. Google kalder modellen eksperimentel, og det bør man tage alvorligt. Kvalitet, hallucinationer, evalueringsmetoder, sikkerhedspolitikker og driftsegenskaber skal måles i den konkrete applikation.

Der er også en leverandørpolitisk vinkel. Selvom modellen er åben, er økosystemet rundt om den tungt præget af Google, NVIDIA, Hugging Face, vLLM, MLX og specialiserede GPU-stacks. NVIDIA skriver selv om Day 0-understøttelse og høje hastigheder på deres platforme. Det er godt for udviklere, men det betyder også, at den reelle portabilitet afhænger af tooling, quantization, drivere og serving-lag. Open weights alene gør ikke en model nem at drifte.

Det er samme type tradeoff, som i de seneste indlæg om Gemini 3.5 Pro og lange kontekstvinduer og Gemma 4 12B: Modelnyheder bliver først interessante, når man oversætter dem til arkitekturvalg. Hvad koster latenstid? Hvad kan køre lokalt? Hvad kræver cloud? Hvilke opgaver taber kvalitet, når man jager hastighed?

Min vurdering

DiffusionGemma er en relevant nyhed, fordi den angriber et konkret problem: lokal inferens føles for ofte langsom og sekventiel. Men den skal ikke læses som “nu er autoregressive modeller døde”. Det er for tidligt og for upræcist. Den rigtige læsning er mere jordnær: Vi får flere inferensarkitekturer, og valg af model kommer til at afhænge mere af workload end af én samlet leaderboard-score.

Hvis du bygger interne AI-værktøjer i 2026, bør DiffusionGemma ind på testlisten sammen med de almindelige Gemma-modeller og andre lokale LLM’er. Ikke fordi den nødvendigvis skriver bedst, men fordi den kan ændre brugeroplevelsen i de dele af systemet, hvor hastighed betyder mere end litterær kvalitet. Det er en mere nyttig nyhed end endnu en marginal scoreforbedring på et benchmark.