Qualche giorno fa Unsloth ha reso disponibile Qwen3.8-27B che io ho scaricato per usarlo in locale con Ollama perché avendo sentito parlare dei benchmark di questo modello, ovviamente mi ha incuriosito immediatamente. Non tanto perché far girare un LLM sul proprio computer sia ormai una novità, ma perché stiamo iniziando ad avere modelli di dimensioni relativamente contenute che, almeno sulla carta, promettono capacità fino a poco tempo fa associate a sistemi molto più grandi. Unsloth indica che Qwen3.8-27B può essere eseguito localmente partendo da circa 17 GB di RAM o VRAM, mentre la versione distribuita attraverso Ollama occupa circa 18 GB e offre una context window da 256K.
Nel mio caso avrei anche una macchina che, a detta di Apple, dovrebbe essere particolarmente adatta alla prova: un Mac mini M4 Pro con 48 GB di memoria unificata. Non è certamente un computer economico, ma non è nemmeno una workstation dedicata all’AI: è semplicemente la macchina sulla quale lavoro tutti i giorni. Programmazione, browser, database, container, applicazioni varie e tutto il resto convivono lì, quindi mi sembrava un buon esempio di quello che potrebbe significare realmente “local AI” per uno sviluppatore.
L’installazione con Ollama è stata davvero banale: dopo aver atteso un paio di minuti mi ritrovo ad avere un modello da 27 miliardi di parametri che girava interamente sulla mia macchina. Se ci fermiamo un secondo a pensarci, la cosa è piuttosto impressionante: non sto chiamando un’API, non sto pagando per ogni token generato e il codice o i documenti che gli passo non lasciano il mio computer. Il problema è che riuscire a far girare un modello e riuscire a lavorarci sono due questioni molto differenti, ed era soprattutto la seconda quella che voglio capire.
Il benchmark ti dice quanto è bravo un modello: a me interessa capire come ci si lavora
Qwen3.8-27B arriva con numeri decisamente interessanti per chi programma. Nei benchmark pubblicati sulla pagina Ollama del modello vengono riportati 73,0 su Terminal Bench 2.1, 61,7 su SWE-bench Pro, 79,0 su QwenSWEBench e soprattutto 90,3 su LiveCodeBench v6. In quella stessa tabella il precedente Qwen3.6-27B ottiene 83,9 su LiveCodeBench, mentre Qwen3.7-Plus arriva a 89,6.
Sono risultati importanti e spiegano bene perché un modello da 27B come questo sia interessante, ma vanno anche letti per quello che sono. Il modello che sto utilizzando attraverso Ollama è quantizzato e gira su un Mac, quindi il mio ambiente non è necessariamente quello utilizzato per produrre quei numeri. Inoltre un benchmark misura molto bene solo alcune capacità del modello, non necessariamente l’esperienza di utilizzo come strumento di programmazione per diverse ore al giorno.
Per curiosità sto comunque eseguendo LiveCodeBench anche localmente, proprio perché voglio avere almeno un riferimento standardizzato accanto alle mie impressioni. Il benchmark sta richiedendo parecchio tempo e inserirò probabilmente qualche dato finale quando avrò completato la prova, ma mentre lo eseguivo mi sono reso conto che avevo già ottenuto la risposta alla domanda che mi interessava di più. Non aveva molto a che fare con qualche punto percentuale in più o in meno.
Per capirlo, invece di sottoporre Qwen soltanto a problemi algoritmici, gli ho chiesto di costruire qualcosa.
Qwen, Ollama e un gioco di Snake
Tempo fa avevo utilizzato GPT con Sol per un esperimento abbastanza semplice: gli avevo chiesto di costruire una versione completa di Snake utilizzando HTML5, CSS, JavaScript e Canvas. Non volevo il solito esempio da tutorial con pochi quadrati sullo schermo, ma un piccolo gioco arcade con una sua identità visiva, modalità differenti, audio, effetti grafici, controlli multipli e abbastanza dettagli da sembrare un prodotto finito.
Ho quindi utilizzato sostanzialmente la stessa specifica con Qwen3.8-27B attraverso Ollama.
Il risultato mi ha sorpreso positivamente. Qwen ha generato un’applicazione di circa 1.600 righe contenuta in un singolo file HTML, con quattro modalità di gioco, power-up, ostacoli, sistema di combo, effetti particellari, audio generato con la Web Audio API, controllo da tastiera, touch e gamepad, high score persistente, impostazioni e tutta una serie di elementi grafici in stile arcade.
Non voglio entrare troppo nella qualità del codice in questo articolo perché finiremmo per trasformarlo in una code review, mentre il punto che mi interessa è un altro. Probabilmente pubblicherò su GitHub il prompt originale insieme alle due versioni, quella prodotta da GPT/Sol e quella di Qwen, in modo che chi vuole possa confrontarle direttamente. Posso comunque dire che non mi sono trovato davanti al classico blocco di codice generato alla buona: Qwen aveva organizzato l’applicazione con componenti distinti per audio, particelle, input e gestione del gioco, e il risultato era sufficientemente completo da poter essere aperto nel browser e utilizzato.
Da questo punto di vista il test era già riuscito. Un modello da 27B, quantizzato e completamente locale, aveva preso una specifica abbastanza articolata e aveva costruito qualcosa di non banale senza utilizzare alcun servizio cloud.
C’era però un dettaglio difficile da ignorare: per completare il lavoro Qwen ha impiegato quasi un’ora.
Ed è proprio quel dato, molto più di qualunque benchmark, che mi ha fatto cambiare prospettiva sull’AI locale.
Qwen può programmare. Il punto però è: riesco a utilizzarlo per programmare “sul serio”?
Un’ora non è necessariamente un tempo assurdo se considero Qwen come un sistema al quale affidare un lavoro e dal quale recuperare il risultato più tardi. Posso dargli un task, lasciarlo elaborare mentre faccio altro e tornare quando ha finito. In alcuni casi potrebbe essere addirittura un ottimo compromesso, soprattutto se sto lavorando su materiale che per ragioni di privacy o riservatezza preferisco non inviare a un servizio esterno.
Il problema nasce quando provo a inserirlo nel normale processo di sviluppo software, perché programmare con un assistente AI è quasi sempre un’attività iterativa. Gli chiedo di implementare una funzione, provo il risultato, mi accorgo che qualcosa non va, gli faccio correggere il problema, cambio un requisito, aggiungo una nuova funzionalità, trovo un edge case e continuo. Il valore non sta soltanto nella qualità della prima risposta, ma nella velocità con cui posso completare questi cicli.
È anche uno degli aspetti che ho notato confrontando l’esperienza con GPT/Sol. Non mi interessa particolarmente stabilire quale dei due abbia scritto la versione migliore di Snake, anche perché sarebbe un confronto fra sistemi che operano in condizioni completamente diverse. Con GPT la parte computazionalmente costosa del lavoro avviene su un’infrastruttura cloud che non vedo e non devo gestire, mentre con Qwen ogni token viene prodotto dal Mac che ho davanti. Il risultato finale può essere confrontabile, ma il modo in cui ci arrivo è molto diverso.
Quando utilizzo un modello cloud non mi interessa quante GPU stiano elaborando la mia richiesta o quanta memoria abbiano a disposizione; dal mio punto di vista invio il lavoro e aspetto il risultato, mentre il mio computer continua a occuparsi delle altre attività. Con Qwen ho invece tutti i vantaggi del locale, perché il modello è sotto il mio controllo, non devo inviare il codice fuori dalla macchina e non esiste un contatore che aumenta il costo a ogni token generato, ma sono anche io a fornire tutta la capacità di calcolo.
Questa differenza diventa particolarmente evidente quando la generazione dura parecchio. Se una richiesta complessa richiede quasi un’ora e la modifica successiva ne richiede un’altra parte significativa, il modello può continuare a produrre ottimo codice ma la mia maniera di utilizzarlo cambia. Inizio ad affidargli lavori che posso lasciare in esecuzione invece di dialogare con lui continuamente, e a quel punto comincia ad assomigliare più a un sistema di elaborazione batch che a un assistente di programmazione interattivo.
Non è necessariamente un difetto del modello. È un problema di feasibility dell’intero sistema, cioè modello, quantizzazione, inference engine e hardware sul quale sto cercando di utilizzarlo.
Ed è proprio per questo che il punteggio di 90,3 dichiarato su LiveCodeBench e l’ora necessaria per produrre Snake non sono affatto in contraddizione. Il primo dato parla delle capacità del modello; il secondo racconta invece quanto costa, in termini di tempo e risorse, mettere quelle capacità a mia disposizione su una macchina personale.
Sono due misure differenti e, se devo scegliere uno strumento con il quale lavorare tutti i giorni, mi interessano entrambe.
Il Mac ha mantenuto la promessa, forse fin troppo bene
A questo punto sarebbe facile concludere che un Mac mini M4 Pro con 48 GB di memoria non sia abbastanza potente per fare seriamente AI locale, ma secondo me sarebbe quasi l’opposto di quello che dimostra l’esperimento.
Il Mac è riuscito a far girare senza particolari problemi un modello quantizzato da 27B che Ollama distribuisce in circa 18 GB, e quel modello ha prodotto un’applicazione completa. Per una macchina general purpose è un risultato notevole, soprattutto considerando che quello stesso computer deve contemporaneamente essere la workstation sulla quale faccio tutto il resto.
Forse il problema non è quindi che il Mac non mantenga la promessa dell’AI locale, ma che quella promessa venga spesso interpretata in maniera troppo semplice. Il fatto che un computer possa eseguire un modello non significa necessariamente che sia anche la soluzione ideale per servirlo continuamente durante un’intera giornata di lavoro.
Quando un LLM locale passa dall’essere qualcosa che apro occasionalmente a diventare una parte permanente del mio ambiente di sviluppo, sto chiedendo alla stessa macchina di svolgere due ruoli piuttosto diversi. Da una parte deve essere la mia workstation, con IDE, browser, container, database, compilazioni e tutto il resto; dall’altra dovrebbe diventare una macchina dedicata all’inference, possibilmente pronta a generare risposte lunghe e complesse ogni volta che glielo chiedo.
Il fatto che possa farlo non significa necessariamente che voglia farlo in questo modo.
Ed è qui che macchine come NVIDIA DGX Spark o alcuni dei nuovi sistemi AMD ad alta memoria hanno iniziato ad avere, almeno per me, molto più senso di prima.
Non necessariamente perché permettono di eseguire qualcosa che sul Mac è impossibile, ma perché separano i due lavori.
“Locale” non significa necessariamente “sullo stesso computer”
Siamo abituati a pensare all’AI locale come a un modello che scarichiamo sul laptop o sul desktop davanti al quale stiamo lavorando. È una definizione naturale, ma non è l’unica possibile.
Il mio computer può contenere diversi terabyte di dati, ma se voglio uno storage sempre disponibile e condiviso fra più dispositivi utilizzo un NAS. Posso eseguire server, database e container sulla mia workstation, ma quando un servizio deve rimanere disponibile continuamente spesso ha più senso spostarlo su una macchina dedicata. Non smette per questo di essere locale.
Non vedo perché l’AI debba necessariamente seguire una logica diversa.
Potrei avere una macchina dedicata sulla mia rete che mantiene in memoria Qwen o altri modelli e alla quale il Mac invia semplicemente le richieste. Ollama espone già API che rendono un’architettura del genere piuttosto naturale, quindi dal punto di vista delle applicazioni cambierebbe relativamente poco. La differenza sarebbe che il computer sul quale sto programmando non dovrebbe più sostenere direttamente tutto il carico dell’inference.
I dati potrebbero comunque rimanere dentro la mia rete, avrei ancora il controllo sui modelli utilizzati e non dovrei pagare un provider per ogni token. Semplicemente, “AI locale” smetterebbe di significare necessariamente “AI che gira sul computer al quale è collegata la tastiera” e inizierebbe a significare “AI che gira su hardware che controllo io”.
Più provo modelli locali di questa dimensione, più questa seconda definizione mi sembra interessante.
Potrebbe perfino nascere una categoria di prodotto abbastanza comune: una sorta di personal AI server, una macchina dedicata principalmente all’inference, con molta memoria e bandwidth, sempre disponibile sulla rete e utilizzabile contemporaneamente dal desktop, dal portatile e magari da altre applicazioni o dispositivi.
In quel caso avremmo qualcosa che oggi tendiamo a confondere dentro la stessa definizione di local AI, ma che in realtà rappresenta tre scenari molto diversi: servizi cloud con infrastruttura completamente esterna, piccoli modelli realmente on-device e modelli più grandi eseguiti su un’infrastruttura personale dedicata.
Dopo questo esperimento, il terzo scenario mi sembra molto meno esotico di quanto mi sembrasse prima.
Quindi, ci puoi davvero lavorare?
Per quanto mi riguarda, Qwen3.8-27B ha già risposto alla parte meno interessante della domanda: sì, un modello locale di queste dimensioni sa programmare. Il test di Snake non dimostra che sia migliore di GPT, né pretende di sostituire benchmark più rigorosi, ma dimostra qualcosa di molto più semplice e concreto: posso dare una specifica piuttosto articolata a un modello che gira interamente sul mio Mac e ottenere alla fine un’applicazione vera.
La parte sulla quale ho ancora dubbi riguarda l’esperienza di utilizzo quotidiana. Aspettare quasi un’ora per una generazione importante può essere perfettamente accettabile se considero il task come qualcosa da lasciare in esecuzione, ma è molto più difficile da accettare quando quella generazione rappresenta soltanto il primo passaggio di una lunga serie di modifiche.
È per questo che, paradossalmente, la prova mi ha convinto più delle capacità dell’AI locale che dell’idea di eseguirla sempre sul mio computer principale.
Il limite che ho incontrato non è stato “Qwen non è abbastanza bravo”. È stato molto più pratico: Qwen è abbastanza bravo da farmi venire voglia di usarlo, ma non ancora abbastanza veloce sul mio hardware da farmi dimenticare che sto usando un modello locale.
Ed è una differenza importante, perché significa che forse il prossimo passo non sarà soltanto avere modelli migliori o computer con più RAM. Potrebbe essere iniziare a considerare l’AI locale come una vera componente dell’infrastruttura personale, separata dalla macchina sulla quale lavoriamo.
Il mio Mac può far girare Qwen3.8-27B, e dopo questa prova non ho molti dubbi sul fatto che modelli locali di questa classe possano diventare strumenti di programmazione seri.
La domanda che mi rimane è un’altra: se voglio davvero lavorarci ogni giorno, forse non mi serve un Mac ancora più potente.
Forse mi serve un altro computer…