DiffusionGemma en un PC amb 16 GB de VRAM: velocitat, raonament i límits del nou LLM local

Els models de llenguatge acostumen a escriure d’esquerra a dreta: generen un token, l’afegeixen al context i calculen el següent. DiffusionGemma proposa una via diferent. En comptes de construir la resposta estrictament en aquest ordre, comença amb una seqüència emmascarada i la va refinant en diversos passos, de manera semblant a la difusió utilitzada en generació d’imatges.

Luke’s Dev Lab fa una primera prova del model de Google en un PC local amb 16 GB de VRAM i 32 GB de RAM DDR4. L’objectiu no és presentar un benchmark exhaustiu, sinó veure si la nova tècnica és pràctica en maquinari domèstic, com respon a preguntes de raonament i què passa quan se li demana simular les decisions d’un petit agent.

Com genera text un model de difusió

Un model autoregressiu no pot produir el token número cent abans d’haver calculat els noranta-nou anteriors. La generació per difusió pot predir i revisar diverses posicions dins d’una mateixa seqüència. A cada pas substitueix part de les màscares per candidats i corregeix el conjunt fins a arribar a una resposta llegible.

Aquesta estructura obre la porta a més paral·lelisme. Una GPU pot treballar sobre molts tokens alhora en lloc d’esperar una cadena completament seqüencial. Google afirma que DiffusionGemma pot arribar a generar text fins a quatre vegades més ràpid en GPU dedicades en determinades condicions.

«Fins a» és una part important de l’afirmació. El rendiment depèn de la quantització, la longitud de la resposta, el nombre de passos de difusió, el programari d’inferència i la capacitat del maquinari. No totes les consultes ni totes les GPU obtindran el mateix avantatge.

Un model de 26.000 milions de paràmetres que activa una fracció

DiffusionGemma 26B-A4B és una barreja d’experts. Té aproximadament 26.000 milions de paràmetres totals, però n’activa prop de 3.800 milions per token. Aquesta arquitectura permet ampliar el coneixement representat sense pagar tot el cost de càlcul a cada pas.

La versió instruct està preparada per seguir indicacions i es distribueix amb llicència Apache 2.0. Google assenyala que una versió quantitzada pot cabre en menys de 18 GB de VRAM. Luke utilitza la conversió GGUF Q4_K_M d’Unsloth. Com que no cap sencera en els 16 GB de memòria gràfica, descarrega una part de les capes a la RAM DDR4 del sistema.

La memòria necessària no és només el pes del model. També compten la memòria cau, els búfers, la longitud del context i el backend. Per això dues quantitzacions amb una mida de fitxer semblant poden comportar-se de manera diferent.

La prova local amb 16 GB de VRAM

La compatibilitat encara és primerenca. La versió provada necessita compilar una branca específica de llama.cpp i utilitzar paràmetres recomanats per a aquest patró de generació. Tampoc exposa l’API compatible amb OpenAI que Luke fa servir en el seu banc de proves, de manera que no pot executar la bateria habitual ni comparar els resultats en les mateixes condicions.

La prova serveix per observar el temps de resposta i el patró visual de generació: el text no apareix com una frase que creix de manera lineal, sinó que els caràcters emergeixen en diferents punts i es van completant. En una de les preguntes habituals de raonament, sobre persones que han de travessar un pont, la resposta queda acabada en uns 27 segons tot i que una part del model treballa des de la RAM.

Aquest comportament pot resultar estrany en una interfície de xat. En un model autoregressiu, l’usuari pot començar a llegir mentre arriba la resta. Amb difusió, la latència fins a veure una part estable i el nombre total de tokens per segon són mètriques diferents. Una generació global més ràpida no sempre se sent més immediata.

La prova també mostra que el model es pot executar en maquinari accessible, però 16 GB no el converteixen en una eina lleugera. La resta del sistema, la velocitat de la RAM i la transferència entre CPU i GPU poden limitar-lo si alguna capa no cap completament a la targeta.

Raonament: velocitat no és el mateix que encert

El vídeo sotmet DiffusionGemma a dues preguntes senzilles de raonament. Luke considera la velocitat molt impressionant i veu capacitat de raonament, però insisteix que els resultats no són comparables amb els seus benchmarks normals. Uns pocs prompts són sensibles a la formulació, a la temperatura i a la quantització.

La gràfica de Google que comenta el vídeo situa el DiffusionGemma de 26B per sota del Gemma autoregressiu de 12B en qualitat. El mateix material oficial presenta el model com a experimental i prioritza la velocitat. Per a tasques on l’encert sigui el criteri principal, Luke recomana continuar utilitzant els models estàndard.

La difusió tampoc resol automàticament les al·lucinacions. El model continua predient una resposta probable a partir del seu entrenament. Que pugui revisar diversos tokens durant el procés pot ajudar a mantenir coherència global, però una explicació segura i ben escrita encara pot ser falsa.

Per a una aplicació real convé avaluar un conjunt de casos representatius, comprovar les respostes amb dades externes i mesurar tant qualitat com velocitat. Una xifra alta de tokens per segon té poc valor si la tasca necessita més reintents o verificacions.

Agent simulat i ús d’eines

Luke també prova una situació d’«agència simulada»: el model rep una llista d’eines i ha de dir quina cridaria, però no n’executa cap de veritat. En tres preguntes selecciona una eina quan correspon i supera una prova de contenció en què no n’havia de cridar cap. És un senyal positiu, no una avaluació completa d’un agent.

Els agents necessiten més que un bon text. Cal un format estable per a les crides d’eina, validació d’arguments, control de permisos, gestió d’errors i un bucle que retorni els resultats al model. La velocitat de DiffusionGemma pot ser atractiva quan hi ha moltes iteracions, però la fiabilitat del format i la qualitat de cada decisió són igualment importants.

En un ordinador local hi ha un avantatge addicional: les dades poden quedar dins de la màquina. Això pot interessar per a codi privat, documents sensibles o un homelab sense connexió permanent, sempre que l’aplicació i les dependències també es configurin de manera segura.

On té sentit i quins límits conserva

Google presenta DiffusionGemma com un model experimental. Pot ser especialment interessant per a ús local i baixa concurrència, on la generació paral·lela en una GPU disponible redueix l’espera. En serveis amb moltes peticions simultànies, els models autoregressius ja poden agrupar consultes de manera molt eficient i l’avantatge pot reduir-se o fins i tot augmentar el cost.

La mateixa Google manté els Gemma autoregressius com l’opció estàndard per a moltes càrregues de producció. DiffusionGemma és una exploració prometedora, no un reemplaçament universal.

La primera impressió del vídeo és valuosa perquè trasllada la proposta del laboratori a un PC de 16 GB i mostra tant la velocitat com les dificultats d’integració actuals. Luke vol repetir la prova quan llama.cpp i una API compatible li permetin executar el benchmark complet.

La tecnologia pot accelerar la generació i obrir una nova família de models locals, però encara cal comparar qualitat, consum, compatibilitat i experiència d’usuari. La novetat no és només que escrigui més de pressa: és que qüestiona l’ordre en què un LLM ha d’aprendre a escriure.