Qwen3.8-27B e Pi: un agente LLM locale al lavoro

L'AI locale è interessante da anni. È privata, controllabile, indipendente dalle API e affascinante dal punto di vista tecnico. Ma fino a poco tempo fa, almeno nella mia esperienza, rimaneva soprattutto questo: interessante.

Potevi discutere con un modello, chiedergli una funzione, fargli analizzare un documento o generare una porzione di codice. Quando però provavi ad affidargli un lavoro vero — leggere un repository, capire le convenzioni, modificare più file, eseguire test, correggere gli errori e arrivare a una patch coerente — la distanza dai modelli di frontiera diventava evidente.

Con l'arrivo di Qwen3.8-27B ho iniziato a percepire qualcosa di diverso. Non la parità con i migliori modelli commerciali, perché quella distanza esiste ancora. Piuttosto, il superamento di una soglia: per la prima volta ho potuto assegnare a un modello locale un'attività importante e lasciare che fosse lui a realizzarne concretamente l'implementazione.

Il banco di prova non è stato un benchmark. È stato il nostro sito, www.xseven.it.

L'hardware: ASUS Ascent GX10

Abbiamo eseguito Qwen3.8-27B su un ASUS Ascent GX10, una workstation compatta basata sul superchip NVIDIA GB10 Grace Blackwell e dotata di 128 GB di memoria unificata. Non è una GPU server tradizionale e non compete con un cluster di acceleratori, ma porta su una scrivania abbastanza memoria da eseguire localmente modelli che, fino a poco tempo fa, avrebbero richiesto infrastrutture molto meno accessibili.

ASUS la presenta come una piattaforma per inferenza, fine-tuning e agenti locali, con un'architettura CPU-GPU a memoria coerente. Le specifiche dichiarate sono disponibili nella pagina ufficiale dell'ASUS Ascent GX10.

Per l'inferenza ho utilizzato LM Studio, che offre un modo molto semplice per scaricare modelli, gestire quantizzazioni ed esporre un endpoint locale compatibile con le API comunemente usate dagli strumenti AI. Sotto questa ergonomia c'è il mondo di llama.cpp, ma l'esperienza quotidiana è molto più vicina a quella di un servizio pronto all'uso.

LM Studio è stato il motore. La vera differenza, però, l'ha fatta l'agente.

Il modello non era cambiato. Era cambiato il suo corpo

Per utilizzare Qwen3.8-27B come coding agent ho scelto Pi. Pi può collegarsi a modelli locali serviti da LM Studio, vLLM, SGLang e altri endpoint compatibili. Può leggere il repository, cercare file, modificare codice, eseguire comandi, osservare gli errori e continuare a lavorare sulla base del risultato ottenuto.

Questo passaggio ha cambiato radicalmente la percezione del modello. In una chat, un LLM rimane confinato dentro la qualità della singola risposta. Come agente, invece, può costruire una sequenza: legge le istruzioni del progetto, esplora il codice, formula un'ipotesi, applica una patch, esegue i test, legge l'errore e riprova.

Qwen non era improvvisamente diventato più intelligente. Aveva ottenuto un ambiente nel quale la sua intelligenza poteva trasformarsi in lavoro.

È una distinzione importante. Quando valutiamo un modello, tendiamo a separarlo dal sistema che lo circonda. Ma un coding agent è il risultato di almeno tre elementi: il modello, il contesto che gli viene fornito e il ciclo operativo attraverso cui può agire e ricevere feedback. Cambiare agente può quindi modificare radicalmente l'utilità dello stesso LLM.

Il lavoro reale su xseven.it

Il compito affidato a Qwen riguardava alcuni residui della migrazione del nostro sito verso Astro e un CMS Git-based, insieme a correzioni di accessibilità. Non si trattava di generare una pagina isolata. Il modello doveva comprendere una codebase ibrida, nella quale convivono pagine Astro, contenuti gestiti tramite collection e alcune pagine HTML legacy. Doveva inoltre rispettare URL pubblici già indicizzati, versioni italiane e inglesi, sitemap, regole di build e requisiti di accessibilità.

Qwen ha lavorato principalmente su tre problemi.

Il primo era un focus ring ancora insufficiente nella pagina dei Termini. Una variante CSS minificata, rgba(65,208,52,.85), era sopravvissuta ai controlli precedenti perché gli scan cercavano una forma sintattica leggermente diversa. Il modello ha individuato il residuo, lo ha sostituito con un doppio anello bianco e nero e ha esteso i controlli affinché entrambe le varianti venissero rilevate.

Il secondo intervento riguardava il campo translation delle pagine CMS. Qwen ha costruito un contratto esplicito: il valore deve essere un percorso locale con la forma /it|en/<slug>.html. URL esterni, protocolli, query string, fragment, traversal e valori non conformi vengono rifiutati.

Non si è fermato alla validazione sintattica. Ha aggiunto anche una verifica tra i contenuti: la traduzione deve puntare alla lingua opposta, il target deve esistere e il collegamento deve essere reciproco. Se una pagina italiana punta a una pagina inglese che non esiste, o se quella inglese non punta indietro, la build fallisce. Ha poi scritto 38 casi di test, includendo diversi input non validi.

Il terzo intervento era la navigazione mobile da tastiera. Il comportamento del menu era duplicato tra le pagine Astro e quelle generate dal CMS, con il rischio che le due implementazioni divergessero. Qwen ha estratto lo script in una singola sorgente condivisa.

Il nuovo comportamento sposta il focus sul pulsante di chiusura quando il menu viene aperto, contiene Tab e Shift+Tab all'interno del pannello, chiude il menu con Escape, restituisce il focus al pulsante hamburger e mantiene sincronizzati aria-expanded e aria-hidden. Ha accompagnato il lavoro con 18 test DOM basati su jsdom.

Questo è il punto per me più significativo: l'implementazione sostanziale è stata realizzata da Qwen3.8-27B in locale. Non un esempio preparato per mostrare il modello nelle condizioni migliori, ma una modifica trasversale a un repository reale.

Dove è intervenuto Codex

Una volta completato il lavoro, l'ho sottoposto a Codex per una seconda revisione. Codex non ha riscritto l'implementazione di Qwen. Ha trovato alcuni problemi più sottili, concentrati soprattutto sulla riproducibilità e sulla chiusura del processo.

Qwen aveva scritto i test jsdom, ma le relative dipendenze non erano dichiarate nel progetto. I test funzionavano nell'ambiente in cui erano stati sviluppati, ma non necessariamente dopo una nuova installazione o dentro il container di build.

Inoltre, gli script di test erano esclusi dal controllo TypeScript principale e il normale npm run build non li eseguiva. Esistevano quindi buoni test, ma non erano ancora un vero gate della pipeline.

Codex ha dichiarato jsdom e i relativi tipi nelle dipendenze di sviluppo, aggiunto una configurazione TypeScript dedicata agli script e integrato type-check e test nel comando di build. Ha poi controllato l'intero processo partendo da un'installazione pulita.

Ha trovato anche una sfumatura nella gestione del focus. L'implementazione originale riportava il focus dentro il menu quando arrivava un nuovo evento Tab. Questo copriva bene la navigazione ordinaria, ma non impediva a uno script o a un'altra azione di spostare temporaneamente il focus dietro l'overlay. Codex ha aggiunto un listener focusin attivo mentre il menu è aperto. In questo modo il focus viene ricondotto immediatamente nel pannello, senza aspettare la successiva pressione di un tasto.

Il risultato finale è passato attraverso 56 test, build Astro, build Docker con Node 22 e Nginx, controllo degli output generati, confronto degli hash tra build locale e pod, test con Chrome reale e verifica sia in testing sia in produzione.

Qwen contro Codex: una differenza meno semplice di "forte" e "debole"

Questo esperimento non dimostra che Qwen3.8-27B sia equivalente a Codex o agli altri modelli di frontiera. Sarebbe una conclusione troppo comoda. Mostra però una divisione del lavoro interessante.

Qwen ha risolto il problema principale. Ha compreso il repository, progettato una soluzione condivisa, modificato più componenti, costruito una validazione per le traduzioni e scritto una suite di test significativa.

Codex ha ragionato maggiormente sul confine tra "funziona qui" ed "è riproducibile ovunque". Ha osservato la pipeline, l'installazione pulita, il type-check e un caso limite del focus che l'implementazione iniziale non chiudeva completamente.

Qwen ha costruito la feature. Codex ha reso più difficile dichiararla completata prima che lo fosse davvero.

Questa è anche una dimostrazione concreta del valore della cross review tra modelli. Non perché un modello debba fare da giudice assoluto dell'altro, ma perché sistemi diversi tendono a lasciare scoperti errori diversi.

Il merito principale, in questo caso, resta del modello locale. Il modello di frontiera ha supervisionato, criticato e completato. L'implementazione è nata però sul GX10, senza inviare il repository a un provider esterno. Per me è un primo plauso importante.

Perché Qwen3.8-27B è così lento

Arriviamo al limite più evidente: Qwen3.8-27B è lento.

Secondo la model card ufficiale, si tratta di un modello denso da 27 miliardi di parametri, con 64 layer e un contesto nativo fino a 262.144 token.

"Denso" significa, semplificando, che per produrre ogni token viene coinvolto l'intero modello. In un modello Mixture of Experts, invece, possono esistere molti più parametri totali, ma solo una parte viene attivata per ciascun token. Un modello da 35 miliardi con 3 miliardi di parametri attivi può quindi richiedere molto meno lavoro per token rispetto a un 27B denso.

Qwen3.8-27B deve attraversare tutti i suoi parametri, token dopo token. Durante la generazione interattiva il limite non è soltanto la capacità matematica dichiarata dalla GPU: conta moltissimo la velocità con cui i pesi possono essere letti dalla memoria e portati alle unità di calcolo.

La quantizzazione riduce il peso del modello e il traffico di memoria, ma non elimina il problema. Inoltre, un coding agent amplifica la lentezza percepita. Ogni attività contiene diversi cicli: il modello legge il contesto, decide uno strumento, riceve l'output, aggiorna il ragionamento e genera la richiesta successiva. Un singolo compito può quindi richiedere molte inferenze consecutive.

Anche il reasoning ha un costo molto concreto: più il modello ragiona e produce token intermedi, più a lungo aspettiamo. Non è soltanto tempo impiegato a "pensare". Sono token che devono essere realmente calcolati. Il risultato è un agente capace, ma decisamente paziente.

SGLang e vLLM potrebbero migliorare la situazione

LM Studio è estremamente comodo e, per sperimentare, rimane una delle soluzioni che preferisco. Ma comodità e massima efficienza non sono necessariamente la stessa cosa.

Runtime come vLLM e SGLang sono progettati specificamente per servire modelli con un uso più efficiente della GPU e della memoria. vLLM utilizza tecniche come PagedAttention per gestire la cache dei token in blocchi, riducendo frammentazione e sprechi. Supporta inoltre continuous batching e prefix caching. SGLang utilizza RadixAttention per riutilizzare parti del contesto già elaborate e include scheduling, caching e kernel orientati a inferenza con bassa latenza e throughput elevato.

Queste ottimizzazioni sono particolarmente interessanti per un coding agent. Il prompt di sistema, le istruzioni del repository e una parte della conversazione si ripetono infatti tra un passaggio e il successivo. Se il runtime riesce a riutilizzare efficacemente la KV cache di quel prefisso, può evitare di ricalcolare ogni volta tutto il contesto precedente.

Non significa automaticamente che passando a vLLM o SGLang il modello diventerà due o tre volte più veloce. In una sessione con un solo utente, alcune ottimizzazioni pensate per molte richieste concorrenti incidono meno. La generazione di ogni nuovo token rimane comunque vincolata dal costo del modello denso e dalla memoria disponibile.

Serve quindi un benchmark reale sul GX10. Ma credo che questo sia il passo successivo: conservare Pi come agente e sostituire il motore di inferenza, misurando separatamente tempo di prefill, token al secondo, cache hit, latenza delle chiamate agli strumenti e durata completa dei task.

Il significato dell'AI locale sta cambiando

Per anni abbiamo detto che i modelli locali offrivano privacy, indipendenza e controllo. Era vero, ma spesso significava accettare capacità troppo inferiori per affidare loro attività importanti. Ora questa distanza comincia a restringersi.

Non è scomparsa. I modelli di frontiera restano enormemente più forti in molti scenari: mantengono meglio il contesto, individuano più spesso i problemi laterali, sono più veloci, più facili da guidare e generalmente più affidabili nei workflow lunghi. Ma "inferiore" non significa più necessariamente "inutile per il lavoro serio".

Con Qwen3.8-27B abbiamo potuto assegnare a un agente locale una modifica reale, farla revisionare da un secondo modello e portarla fino alla produzione. Questo cambia la natura della discussione. Non stiamo più parlando soltanto di privacy teorica o di sovranità digitale come aspirazione. Stiamo iniziando a parlare di lavoro concretamente eseguibile.

La Cina e la finestra degli open weight

In questa trasformazione il contributo dei laboratori cinesi è difficile da ignorare. Qwen e DeepSeek hanno reso disponibili modelli open weight sempre più competitivi, spesso con licenze utilizzabili anche in contesti commerciali. Qwen3.8-27B, per esempio, è distribuito con licenza Apache 2.0.

Non sono gli unici. Meta, Mistral, Google, NVIDIA e altre organizzazioni occidentali hanno pubblicato pesi e tecnologie importanti. Sarebbe quindi scorretto affermare che l'intero ecosistema open weight esista soltanto grazie alla Cina.

Ma oggi è soprattutto la competizione cinese a impedire che l'AI avanzata diventi esclusivamente un servizio chiuso, accessibile alle condizioni decise da pochi grandi provider statunitensi. La pressione esercitata da Qwen e DeepSeek costringe tutto il mercato a confrontarsi con modelli scaricabili, modificabili ed eseguibili su infrastruttura propria.

Non sappiamo quanto durerà questa finestra. Regole sull'esportazione, tensioni geopolitiche, costi di addestramento, restrizioni sulle licenze o semplici decisioni commerciali potrebbero cambiare il quadro molto rapidamente. Un modello disponibile oggi può non avere un successore altrettanto aperto domani.

Proprio per questo credo che sia il momento di sperimentare seriamente, costruire competenze e imparare a governare questi sistemi mentre ne abbiamo la possibilità.

Conclusione: non siamo ancora indipendenti, ma non siamo più immobili

Qwen3.8-27B non sostituisce i modelli di frontiera. È più lento, commette errori e ha ancora bisogno di supervisione. In questo esperimento Codex ha individuato problemi che il modello locale non aveva chiuso da solo.

Ma questa non è una bocciatura. È il normale funzionamento di un processo di ingegneria. Anche il codice scritto da una persona viene revisionato, testato e corretto. La domanda giusta non è quindi se Qwen produca al primo tentativo lo stesso risultato del migliore modello commerciale. La domanda è se possa assumersi una parte sostanziale del lavoro, produrre qualcosa di valido e arrivare alla produzione attraverso un processo controllato.

In questo caso la risposta è sì.

Siamo ancora lontani da una completa indipendenza dalle big tech. Hardware, framework, toolchain e ricerca restano inseriti in una rete globale di dipendenze. Ma poter eseguire localmente un modello open weight, affidargli il proprio repository e ottenere un'implementazione reale è già una forma concreta di libertà tecnica.

Non sappiamo quanto durerà questa opportunità. Per ora, però, è diventata abbastanza seria da meritare qualcosa di più di un esperimento nel fine settimana. È diventata parte del nostro modo di lavorare.