Quando un programmatore mette a confronto due modelli per il coding locale, non si limita a guardare le classifiche: si siede al terminale e prova bug reali, refactoring, operazioni multi-file. È esattamente quello che ha fatto un utente con una Radeon AI PRO R9700 da 32 GB, una CPU Ryzen 9 5950X e llama.cpp con backend Vulkan, paragonando Qwen 35B-A3B – architettura Mixture of Experts con 35 miliardi di parametri totali ma soli 3 miliardi attivi per token, quantizzato in Q5_K_M – e Qwen 27B denso in Q4_K_XL.

Il dato che salta all’occhio è la velocità: il modello MoE ha prodotto circa 116 token al secondo, quasi quattro volte i ~30 token/s del comparabile denso. In un dominio come la manutenzione del codice, dove spesso si attende una risposta immediata, un incremento di throughput di questa entità cambia radicalmente l’ergonomia dello strumento. Eppure, la sorpresa vera è un’altra: sui compiti di correzione ordinaria e sulle modifiche che toccano più file, entrambi i modelli si sono comportati in modo corretto e spesso indistinguibile. Solo quando i test sono diventati progressivamente più insidiosi – invarianti impliciti, condizioni al contorno inusuali, effetti collaterali non richiesti esplicitamente – il modello denso ha messo a segno qualche vantaggio, ma sempre su aspetti di sottigliezza semantica, mai sulla correttezza di base.

L’autore del test è chiaro: le quantizzazioni sono diverse, quindi non è un confronto architetturale accademico. Ma il responso pratico spinge a riflettere. Trattare il numero di parametri attivi come un indicatore diretto della qualità effettiva di un LLM in contesti specifici diventa sempre più rischioso. Oggi vediamo un MoE da 3B attivi competere in molti scenari con un modello denso da 27B, divorando molta meno VRAM reale per l’inference e spingendo velocità che rendono l’uso locale fluido.

Il nodo hardware e la leva AMD

L’esperimento merita attenzione proprio perché non è stato condotto su una NVIDIA di ultima generazione. La Radeon AI PRO R9700 è una scheda workstation AMD con 32 GB di memoria video, un taglio oggi considerato medio-alto ma non proibitivo. L’abbinamento con il backend Vulkan di llama.cpp, anziché CUDA, evidenzia come l’ecosistema di inference locale stia allargandosi oltre la dipendenza esclusiva dal mondo NVIDIA. Per chi valuta deployment on-premise, questo cambia i calcoli: una GPU non NVIDIA con sufficiente banda e memoria può servire un assistente di coding quasi in tempo reale a costi hardware più contenuti.

Il dato di throughput – 116 tok/s – rende plausibile l’idea di un coding companion che lavora senza latenza percepibile su workstation di fascia media. E quando il divario qualitativo rispetto a un modello denso molto più grande si manifesta solo in corner case cerebrali, l’analisi TCO (Total Cost of Ownership) si sposta inevitabilmente sul bilanciamento tra costo della GPU, consumo energetico e valore pratico restituito. Per molte activity di sviluppo quotidiane, i risultati suggeriscono che non serve per forza cacciare l’ultimo flagship NVIDIA: una configurazione come quella documentata può bastare.

La trappola del parametro attivo

Questa prova si inserisce in un filone più ampio: la corsa a contare i parametri attivi sta diventando un falso amico. Architetture MoE come quella di Qwen distribuiscono il carico tra esperti specializzati, ottenendo un’efficienza computazionale che scompagina i paragoni lineari. In pratica, la qualità di generazione può restare elevata anche quando solo una frazione minima dei pesi viene attivata per ciascun token. Il test di coding locale offre un tassello empirico che si somma ad altre evidenze: su task procedurali e di modifica strutturata, il MoE non sfigura e vince in reattività.

Naturalmente le quantizzazioni non sono neutrali. Qui il modello MoE girava in Q5_K_M, mentre il denso in Q4_K_XL: le scelte di compressione possono aver leggermente favorito il primo o il secondo a seconda dei layer. Ma è proprio la pratica quotidiana a dettare se valga la pena di sacrificare un pizzico di precisione teorica per guadagnare 4× throughput su un debug che richiede risposte immediate. Chi lavora on-premise sa che la scelta della quantization è parte integrante del trade-off, non un dettaglio da laboratorio.

Cosa significa per chi spinge l’inference locale

Per i lettori che seguono AI-RADAR, il segnale è chiaro: la combinazione MoE + accelerazione Vulkan su GPU AMD sta diventando una realtà tangibile per il coding e probabilmente per altre attività tecnico-linguistiche. Non è più solo una curiosità da smanettoni, ma un’opzione concreta per chi ha esigenze di sovranità dei dati e vuole mantenere l’intero stack sotto il proprio controllo fisico.

Il fatto che un modello da 35B con soli 3B attivi possa rivaleggiare in termini pratici con un 27B denso ribalta alcune aspettative consolidate. Se questa tendenza verrà confermata su altri domini, le strategie di provisioning hardware per l’AI locale potrebbero orientarsi sempre più su GPU di fascia media abbinate a modelli MoE ben ingegnerizzati, anziché inseguire unicamente memorie video enormi per ospitare modelli densi mastodontici. Il risultato, in ultima analisi, è un potenziale abbassamento delle barriere economiche e tecniche all’adozione dell’inference auto-gestita.