L'importanza di gestire localmente il modello AI
Giugno 2026 segnerà la consapevolezza che i modelli chiusi possono essere persi. Con la recente rimozione del modello Anthropic Claude Fable 5, è evidente quanto sia cruciale possedere e gestire il proprio stack AI, soprattutto per coloro che costruiscono aziende sull'intelligenza artificiale. Per questo motivo, abbiamo condiviso come utilizziamo modelli locali come Gemma e Qwen all'interno di agenti, per eseguire compiti di classificazione.
Questo approccio differisce dall’uso di modelli come BERT per la classificazione. Un modello locale inserito in un ambiente di agenti, ad esempio Pi, può lavorare con output strutturati per attribuire etichette. Abbiamo scelto questa strategia perché già avevamo a disposizione modelli e agenti e riteniamo fortemente che configurazioni simili diventeranno sempre più popolari man mano che i modelli locali miglioreranno.
I contributi open source e le richieste da gestire
Il nostro punto di partenza è stato costituito dagli apporti community nel progetto OpenClaw, che riceve hàng centinaia di problemi e PR al giorno, e che richiede quindi categorizzazione e priorizzazione. Io, Onur, sto lavorando per rendere operativi i modelli locali in questo spazio. Essendo co-maintainer di quel progetto, devo rispondere in fretta agli errori critici.
Che impatto avrebbero modelli di ultima generazione come GPT-5, Opus o Sonnet? Il risultato sarebbe una triage immediata e semplice. Invece, disponendo di 128 GB di memoria unificata su un sistema con scheda grafica NVIDIA GB10, mi sono chiesto: posso utilizzare modelli locali e a costo zero per creare un sistema di notifiche istantanee?
Le strategie per la triage con modelli locali
I modelli locali open-weight permettono una classificazione più economica e veloce. Ma come si inquadra una richiesta pull (Pull Request)? Un normale singolo invio su un endpoint JSON, con le etichette come enum?
Con gli agenti di oggi, possiamo fare di meglio. Siamo testati su due modelli: gemma-4-26b-a4b e qwen3.6-35b-a3b. Questi modelli, sottoposti ad ottimizzazioni, generano centinaia di token al secondo localmente.
La triage automatizzata
Usiamo un agente che guida l’esecuzione della classificazione. Questo agente si alimenta delle informazioni della richiesta pull, incluso il corpo e un estratto del diff. Il modello ha accesso ad alcuni strumenti, come il “bash” limitato, che permettono operazioni di lettura esclusivamente sull'OpenClaw. Si utilizza il reposhell invece del bash per limitare il rischio di manipolazioni esterne.
Un esempio pratico: nel classificare openclaw/openclaw#84621, qwen3.6-35b-a3b inizialmente considerò codingagentintegrations. Con operazioni come ls extensions e cat package.json, fu chiaro che l’etichetta fosse scorretta, e il modello la corresse in inferenceapi e toolcalling.
La configurazione e l’architettura
La configurazione specifica, denominata localpager-agent, gestisce esclusivamente dati di classificazione e output. Le richieste o problemi vengono sottoposti a un prompt, gestito tramite interfaccia CLI come segue:
- Titolo della richiesta
- Corpo principale
- Estratto differenziale
La gestione tra la ricezione e la notifica finale su Discord è semplice, limitando l’uso LLM soltanto alla parte critica: la triage. Notifiche sono basate su regole deterministiche, per velocizzare il workflow.
La progettazione architetturale
L’architettura adottata è semi-agente. La classificazione è agente-guidata, mentre l'invio della notifica segue una logica predeterminata, per non impiegare tempo nella generazione. I modelli locali generano riserve computazionali per le sole inferenze richieste, evitando sprechi e errores.
Testing e confronto dei modelli
I primi tentativi con modelli locali erano rumorosi e poco precisi. Gemma-4-e4b-it aveva portato a un’end-to-end locale funzionante, ma soffriva di etichettatura errata. Per testare i modelli, abbiamo valutato 330 pull requests e problemi GitHub. Ciascuno è stato etichettato 5 volte per testare l’accuratezza dei modelli.
Non abbiamo bisogno di ottimizzare ulteriormente i prompt per Gemma-4-26b-a4b o Qwen3.6-35b-a3b prima di raggiungere risultati validi. Utilizzando lo stesso prompt di routing, l'efficacia si diversifica: Gemma ha altezza e tempi ridotti, Qwen eccelle in precisione e riconoscimento esatto.
Risultati e confronti
- Gemma: Maggiore recall (rispetta l’etichetta) e minore tempo medio.
- Qwen: Maggiore precisione, confronto esatto e minori falsi positivi.
- Deepseek-V4-Flash: Meno falsi positivi, ma troppo lento per il GB10.
I risultati di Qwen presentati qui includono anche i test ripetuti dove c'è stato esaurimento token. Per Gemma e Qwen, i dati riportano la media e la deviazione standard in tre esecuzioni. Deepseek-V4-Flash viene incluso una sola volta come riferimento.
Prospettive future e valutazioni
I numeri di throughput e tempi qui non rappresentano il massimo che questi modelli possono raggiungere. Sono le impostazioni utilizzate in questo esperimento. Siamo fiduciosi che configurazioni ottimizzate permetteranno risultati ancora migliori.
Questi modelli e configurazioni sono solo l'inizio. Con il costante avanzamento, il calcolo locale fornirà un'alternativa valida ai modelli chiusi, permettendo aziende di lavorare in autonomia e senza rischi di sospensione.