Pensare di far funzionare un assistente vocale come JARVIS su una scheda video da gaming non è più fantascienza. L’ultima dimostrazione arriva da un utente Reddit, Mrinohk, che ha documentato un’architettura software capace di trasformare un piccolo Large Language Model in un agente affidabile per compiti complessi, il tutto su una modesta RX 6600 XT.

L’idea centrale è tanto semplice quanto controintuitiva: invece di sovraccaricare il modello con decine di tool generici, lo si costringe a operare all’interno di “applicazioni” dedicate – l’utente le chiama workflow – ciascuna con un set limitato di azioni, un proprio clipboard e uno scratch pad per trasferire informazioni tra una vista e l’altra. Quando l’agente esce da un’applicazione, il contesto viene alleggerito e al rientro lo stato è esattamente quello lasciato, eliminando la necessità di ricostruire ogni volta la sessione.

In pratica, per navigare il web l’agente non riceve un URL da digitare – operazione in cui i modelli locali tendono a sbagliare caratteri – ma interagisce con un menu testuale. Un verbo e un numero (“apri 1”, “copia 2”) bastano a guidare l’azione senza errori. Lo stesso vale per il controllo del computer: ciò che prima richiedeva venti strumenti diversi ora si riduce a pochi comandi interni a un’interfaccia semplificata.

Il test è stato effettuato con Gemma 4 in due taglie: la versione E4B (circa 4 miliardi di parametri) e la 26B, entrambe quantizzate in Q4_K_XL con il metodo Unsloth QaT. L’inference gira su llama.cpp con backend Vulkan, sulla già citata RX 6600 XT. Alla fine del task, che consisteva nel trovare un componente raro per un’auto d’epoca, il modello processava tra 70 e 85 token al secondo con un contesto di circa 10mila token; il prefill toccava gli 800 t/s. Numeri più che dignitosi per un hardware consumer senza accelerazione CUDA.

La sorpresa più grossa, però, è stata il comportamento: il modello più piccolo ha superato il fratello maggiore. La versione da 26B mostrava una certa avversione per gli strumenti di pianificazione dedicati, mentre il modello da 4B, inserito nella stessa architettura ad applicazioni, portava a termine il compito con maggiore efficacia. Non è la prima volta che si osserva come un design accorto dell’agente possa compensare le dimensioni ridotte di un LLM, ma vederlo confermato su un banco di prova reale aggiunge un tassello importante per chi sviluppa soluzioni on-premise.

La scoperta, per quanto artigianale, tocca un nervo scoperto del deployment locale: i modelli grandi richiedono GPU costose e memoria video abbondante; i modelli piccoli, se incapsulati in architetture che ne limitano il raggio d’azione, possono diventare sorprendentemente performanti. Non si tratta di una soluzione pronta per l’uso aziendale – l’autore stesso ammette di aver realizzato solo due applicazioni, un browser testuale e un controller di sistema – ma indica una direzione chiara: la qualità di un agente non dipende solo dai parametri del modello, ma da come viene ingegnerizzato il suo spazio d’azione.

In un panorama in cui le aziende valutano il Total Cost of Ownership di uno stack AI on-premise, esperimenti come questo suggeriscono che investire in design può abbattere la necessità di hardware estremo. Certo, la strada è ancora lunga, ma il messaggio è nitido: non servono per forza centinaia di miliardi di parametri per costruire un assistente utile. A volte, basta dargli dei buoni confini.