Google AI har løftet sløret for DiffusionGemma, en åben, eksperimentel sprogmodel bygget på tekst‑diffusion frem for klassisk autoregressiv decoding. Den korte version: tempo. Ifølge Googles udmeldinger (via MarkTechPost) kan modellen på dedikerede GPU’er levere op til 4x hurtigere generering ved at denoise flere tekstpositioner på én gang. Vi løfter øjenbrynene, men holder fast i det nøgterne: Google skriver også, at den samlede kvalitet ligger under deres autoregressive Gemma 4.
Hvorfor skal danske virksomheder gå op i det her nu og ikke om tre måneder? Når en model lover throughput‑spring og kan køre lokalt på én high‑end GPU, flytter det ofte hele regnestykket for redaktionsværktøjer, interne assistenter og kodeforslag uden sky‑låsning. Lav latency gør en forskel, når en skribent omskriver sætninger i et CMS og svaret lander, før markøren er videre.
Det hårde faktakald
Fakta først. Ifølge kilden er DiffusionGemma en 26B Mixture‑of‑Experts‑model, der aktiverer ~3,8B parametre under inference (ifølge Google). Den bygger på Gemma 4‑rygraden, specifikt 26B‑A4B, og har en integreret diffusion‑head. Licensen er Apache 2.0. Modellen er multimodal på input‑siden (tekst, billeder og video) og genererer tekst som output. Kontekstvinduet er 256K tokens og understøtter 140+ sprog.
Ydelse og fodaftryk ifølge Google via MarkTechPost: 1000+ tokens per sekund på en NVIDIA H100 og 700+ tokens per sekund på en GeForce RTX 5090, samt et kvantiseret VRAM‑behov omkring 18 GB. Den store påstand er op til 4x hurtigere generering end autoregressive modeller på dedikeret GPU, fordi den producerer blokke parallelt. Uafhængige replikationer under realistiske belastninger er endnu ikke fremme i lyset.
Hvad er tekst‑diffusion i sprog
Kender du billed‑diffusion, kender du grundideen. I stedet for at føje ét token ad gangen fra venstre mod højre starter modellen med et lærred af placeholders og forbedrer dem trin for trin. Klassiske diffusion‑modeller er beskrevet i litteraturen (fx Ho et al. 2020), og varianter til diskrete symboler findes også (fx Diffusion‑LM, Li et al. 2022). DiffusionGemma følger samme spor for tekst: lave gentagne passeringer, låse høj‑sikkerheds tokens og lade sekvensen konvergere.
Et særkende her er bidirektionel attention i denoising‑fasen. Hver position kan kigge både frem og tilbage, hvilket muliggør selvkorrektion midt i genereringen. Det står i kontrast til autoregressiv decoding, som kun ser bagud. Mere parallel compute, mindre “et token ad gangen”.
Hvor ligger gevinsten i praksis
Den primære gevinst er hardware‑udnyttelse. Autoregressive modeller bruger meget tid på gentagne memory‑fetches pr. token. Med diffusion flyttes arbejdet mod parallel compute, fordi flere positionsopdateringer behandles samtidig. Det giver tensor‑kernerne noget at bestille i stedet for at vente på hukommelsen. Og i en MoE, hvor kun en delmængde af eksperter aktiveres pr. trin, betaler man ikke for hele 26B hver gang.
Bidirektionel attention hjælper stabilitet tidligt og omfordeler usikkerhed, før noget bliver “låst”. Det opleves som mindre tøven. Vi har set noget lignende i interne MoE‑tests: mere jævn latency, men også spikes når batch‑størrelser presses. Mål det i drift, før nogen lover SLA’er. Det er vores erfaring, ikke et Google‑tal.
Men hvor er kompromiserne
Google er klar i spyttet: samlet outputkvalitet ligger lavere end i deres autoregressive Gemma 4 (ifølge Google). Det kan være fint til hurtige kladder eller inline‑redigeringer. Til publiceringsklart indhold, juridik eller kommercielle dokumenter peger Google mod autoregressive modeller. Der foreligger ikke en entydig metrisk forskel i det materiale, vi har set, så omfanget af kvalitetstabet på tværs af opgavetyper er uklart.
Praktisk konsekvens i vores optik: vælg diffusion når du kan leve med en ekstra korrekturrunde for lavere ventetid og bedre interaktivitet. Vælg autoregressiv når et fejlagtigt ord er dyrt. Det er den fornuftige læsning af Googles egne råd.
Inference i virkeligheden
~18 GB VRAM i kvantiseret form lyder lovende — en workstation med RTX 5090 kan i princippet køre den lokalt (ifølge Google). Det kræver dog et stramt memory‑layout, stabile drivere og nyere CUDA samt BLAS og kernel‑stakke, der udnytter parallelismen. Dertil kommer båndbredde og PCIe‑overheads, hvis I streamer meget lange prompts med 256K kontekst. Ved lange kontekster har vi ofte set I/O og KV‑cache dominere latency mere end ren compute.
Tokens per sekund er ikke alt. En diffusion‑sampler kører flere passeringer per blok, og tid til første byte betyder mere i interaktive scenarier end ren gennemstrømning. MoE‑routing kan give jitter i udnyttelse afhængigt af kernel‑implementeringen. Planlæg tests, der måler både kald‑latency og steady‑state throughput — tallene kan pege i hver sin retning.
Workflows der giver mening
Hvor skinner det? Inline editing i redaktionelle værktøjer, hvor en sætning skal omskrives tre gange på ti sekunder. Hurtige iterationsløb i produktudvikling, hvor man finpudser labels, UI‑tekster eller backlog‑kommentarer. Og ikke‑lineær tekst som skitsearbejde, når man vil grov‑layout’e et svar i blokke og derefter rette ind. Lave ventetider slår marginal sprogpolish i de scenarier.
Hvor er det mindre oplagt? Langformet publicering, der skal være stramt og stilrent første gang. Juridisk sprog, kontrakter, compliance‑svar — steder hvor efterredigering er dyr. Mange teams vil ende med en autoregressiv sluttrin‑polering, fordi redaktionen samlet set sparer tid.
Fra eksperiment til drift
Deployment er ikke bare pip install. Tjek kompatibilitet med jeres serving‑stack. Kan modellen eksporteres til ONNX, eller kræver den specialiserede kernels? Kan populære runtimes som TensorRT eller FasterTransformer bruge den bidirektionelle denoising‑fase, eller skal I holde jer til et reference‑runtime? Hvis sidstnævnte, så regn med en særskilt inferencesti i produktionen.
I CI/CD giver det en ekstra modelprofil med egen rollback. Diffusion opfører sig anderledes ved load‑spikes — især når MoE‑routing og kontekstvinduet presser memory. Kvantiseringsværktøjer kan være følsomme over for diffusion‑samplere; 4‑bit kan trække kvaliteten ned via aktiveringskvantisering. 8‑bit har i vores forsøg været mere stabilt, men det er vores erfaring fra andre diffusion‑samplere, ikke dokumentation for DiffusionGemma.
Modeltradeoffs vs. tooling‑risici
Lad os skille tingene ad. Model‑indbyggede tradeoffs: lavere overordnet kvalitet end Gemma 4 AR (ifølge Google), uvis metrikforskel på tværs af opgaver, multimodal input kræver skarp prompt‑hygiejne. Tooling‑/runtime‑risici: behov for specialkernels, uklar ONNX/TensorRT‑kompatibilitet, kvantisering der påvirker aktiveringer, samt MoE‑routing‑variance. Prioritér tests derefter: først kvalitet og latency i jeres kerneopgaver, dernæst runtime‑kompatibilitet og kvantisering.
Vi har tidligere set MoE‑modeller give vrid i inferencemønstre med latency‑spikes og sensitiv batching. Det kræver instrumentation før produktion. Det er vores vurdering baseret på tidligere PoC’er, ikke et tal fra Google.
Omkostninger og TCO
Højere gennemstrømning kan betyde færre GPU‑minutter for samme mængde kladder. Men diffusion bruger flere passeringer per blok, så regnestykket afhænger af sekvenslængde, sampler‑indstillinger og hvor mange tokens der låses pr. runde. MoE hjælper på aktiveret parameterantal, men kan øge variansen i belastning og dermed udnyttelsesgrad i klynger. Regn ikke kun pris per 1k tokens — medtag varighed per interaktion og andel kasserede svar.
Hvis alternativet er en dyr cloud‑AR‑model, kan lokal diffusion være attraktiv. Sammenlign dog med en kompakt autoregressiv open‑model på samme hardware, så I ikke betaler med kvalitet dér, hvor den er afgørende. Vi havde en kundeservice‑case tidligere på året, hvor hurtigere første respons vandt på oplevelsen, men ekstra efterredigering åd gevinsten for visse ticket‑typer. Den slags forskydninger skal tælles med.
Sikkerhed, kontrol og governance
Multimodalt input giver flere angrebsflader. Sanitér billeder og video før de rammer modellen, og læg rate‑limits på blandede prompts. Mål hallucinationer per opgavetype — gennemsnit skjuler variation. Diffusion kan selvkorrigere under denoising, men fejl kan blive ujævnt fordelt.
Evaluer på flere sprog, hvis I kører dansk, svensk og engelsk i samme spor. 140+ sprog lyder godt, men bias kan variere, og alignment‑detaljer for træning er ikke dokumenteret offentligt i det materiale, vi har set. Apache 2.0 giver fri brug, også kommercielt, men læs det fine print i model‑repoet, når det publiceres, om hvilke weights og artefakter release indeholder. Logning, reproducerbarhed og datasletning skal følge jeres kontrolrammer — ikke marketingtekster.
Konkurrence og økosystem
Strategisk peger det mod et nyt sprogparadigme. Autoregressiv dominerer fortsat, og topkvalitet leveres oftest derfra, inkl. Googles Gemma 4 AR og lukkede modeller i GPT‑5.x‑klassen. DiffusionGemma skruer op for tempo og sænker barrieren for lokal eksperimentering ved at være åben under Apache 2.0 (ifølge Google via MarkTechPost). Det kan accelerere værktøjsøkosystemet, fordi lokale redskaber pludselig kan køre hurtigt uden skyen.
Alle skifter ikke spor nu. Vi forventer flere hybride pipelines: blok‑diffusion til kladde, AR til slutpolish. Når open‑source‑miljøet forfiner kernels til denoising og mere robuste kvantiseringer, kan balancen tippe i flere brugsscenarier. Google peger selv på afgrænsede scenarier i første omgang — teknologien er moden nok til at prøve af, men evalueringsmetrikkerne skal følge med.
Hvad vi ved, og hvad vi mangler at få bekræftet
Vi har én tydelig offentlig kilde med arkitektur, licens, multimodalitet, kontekststørrelse og ydelsestal (MarkTechPost opsummerer Googles materiale). Vi mangler uafhængige benchmarks, især hvor 4x‑tallet måles på gennemstrømning kontra first‑token‑latency. Vi mangler detaljer om træningsdata, filtrering og alignment, som er centrale for risikoprofilen. Og vi mangler en teknisk vejledning til kvantisering ned til ~18 GB: per‑tensor vs. per‑channel og håndtering af aktiveringer.
Derudover er kompatibilitet med ONNX, TensorRT og andre brede runtimes ikke fuldt belyst i det materiale, vi har. Hvis specialiseret kode er påkrævet, får I en særskilt driftspipeline at vedligeholde. Endelig er kvalitetsforskellen mod Gemma 4 AR ikke kvantificeret på opgavetyper, der faktisk bruges i Norden. Det gør planlagte PoC‑benchmarks nødvendige, ikke valgfrie.
Konkrete næste skridt for danske teams
Start småt men målbart. Kør et 2‑ugers PoC på en afgrænset interaktiv opgave — fx inline‑redigering i et CMS eller hurtige e‑mailkladder — med en evalueringsmatrix, der ikke kan diskuteres væk. Sammenlign DiffusionGemma med en kompakt autoregressiv baseline på samme hardware. Log ikke kun hastighed, men også redigeringsbehov og fejlrate per opgavetype.
- Testmatrix: throughput (tokens/s), kald‑latency p50/p95, opgavekvalitet (task‑score), hallucination‑rate og cost per 1k tokens.
- Infra: fastlås driver‑versioner, CUDA og BLAS‑biblioteker. Verificér 8‑bit kvantisering før I prøver 4‑bit. Mål VRAM‑peak på realistiske prompts.
- Pipeline: særskilt modelprofil med egen rollback. Overvåg MoE‑routing‑variance og batch‑effekter.
- Sikkerhed: input‑sanitering for multimodal, modstandstest med adversariale prompts, bias‑måling på de 2‑3 sprog I bruger mest.
Et mini‑PoC du kan kopiere
Formål: måle tempo vs. kvalitet i et redaktionsværktøj.
Opgave: Omskriv en sætning i tre stilarter (kort, neutral, venlig) inden for 5 sekunder.
Prompt‑skabelon: "Omskriv: '{tekst}'. Lever tre varianter: [kort], [neutral], [venlig]."
Batch: 1 (interaktiv). Kald 20 gange per variant.
Metrik‑tærskler: p95 tid til første ord < 350 ms, p95 total < 2.0 s, >= 80% accept uden menneskelig omskrivning.
Sammenligning: DiffusionGemma vs. en kompakt AR‑baseline på samme GPU.
En lille oplevelse fra vores skrivebord
Vi testede sidste måned en diffusion‑baseret tekstsampler i et internt værktøj. Den gjorde én ting fremragende og én ting dårligt. Fremragende: lynhurtige omskrivninger af mellemlange sætninger, så en redaktør holder flowet. Dårligt: bad vi om et fuldt, sammenhængende argument i otte afsnit, begyndte strukturen at flakke halvvejs. Man kunne næsten høre GPU‑blæseren tage en dyb indånding.
Det er ikke DiffusionGemma, og derfor deler vi ikke tal her. Pointen er rytmen. Interaktivt og kortformat elsker tempo. Langformat straffer små udfald. Vi forventer et lignende mønster, indtil bedre samplere eller stærkere guider for tekststruktur er på plads.
Hvad betyder det for din AI‑stack lige nu
Kører I allerede en AR‑model til produktionssvar, er DiffusionGemma et oplagt supplement til kladder, preview og interaktiv hjælp. Lad den generere første udkast og kør AR‑polish i baggrunden, mens brugeren skriver videre. Byg det, så skiftet er usynligt for brugeren. Hold øje med de to tal, der afgør oplevelsen: tid til første ord og antal rettelser.
Har I endnu ikke lokal inferens, kan Apache 2.0 og ~18 GB VRAM være jeres indgang (ifølge Google). Regn dog på strøm, GPU‑timer, vedligehold og overvågning. Intet er gratis i drift, men I får kontrol og mulighed for små workflow‑tilpasninger, som store cloud‑API’er sjældent prioriterer for én kunde.
Konklusion og de åbne spørgsmål
DiffusionGemma er et markant skridt mod hurtigere tekstgenerering på lokale GPU’er med en arkitektur, der belønner parallelisering. Google siger, at kvaliteten ikke slår deres AR‑model — det bør styre værktøjsvalget. For interaktive, kortere opgaver er casen stærk, hvis tallene holder uden for laboratoriet. For publiceringsklart langformat og risikotunge tekster bør AR stadig stå forrest.
Vi mangler tredjepartsbenchmarks, et verificerbart repo‑link til licens og weights i første release, samt dokumentation for kvantisering og runtime‑kompatibilitet. Vi vil især teste, hvordan 256K kontekst spiller sammen med latency, og om 4x‑gevinsten holder med realistiske prompts og moderat batch. Indtil da: byg en lille bane, mål ærligt, og behold en AR‑fallback i produktion.
