Il mio punto di partenza è un PC con Ryzen 9 9900X, RTX 5070 da 12 GB e 32 GB di RAM. Fra settembre e ottobre 2026 l’ho usato per provare modelli locali e collegarli a Hermes Agent: chat, lettura dei file e lavoro su piccoli progetti. Qui raccolgo le sessioni che hanno lasciato appunti utili, compresi i tentativi che non sono arrivati a una risposta.
Il PC e le variabili che cambiano davvero
La configurazione di riferimento usa Corsair Vengeance DDR5-6000, scheda madre ASUS TUF GAMING B650-PLUS WIFI, raffreddamento ARCTIC a liquido da 360 mm e case Antec. Nelle sessioni storiche ho alternato la RTX 5070 e una Radeon RX 570 da 8 GB. L’ambiente era Windows, con server llama.cpp locali e build CUDA o Vulkan a seconda del tentativo.
La lezione più concreta è stata che il nome del modello racconta solo una parte della storia. Contano il file scelto, la quantizzazione, il backend, l’offload e il contesto. La stessa macchina può essere piacevole in una sessione e lenta o instabile in un’altra.
Gli appunti delle sessioni
I numeri seguenti provengono da log e annotazioni d’uso di settembre e ottobre 2026. Sono sessioni diverse, non una classifica ottenuta con un unico prompt e identiche impostazioni.
| Sessione | Configurazione registrata | Risultato |
|---|---|---|
| Qwen3.8-27B LowGPU · 13 settembre | RTX 5070, server locale; i log della sessione riportano uno slot di contesto da 131.072 token | Log: 38,088 token/s in generazione; 9,060 token/s nell’elaborazione del prompt |
| Qwen3.6 e Qwen3.8 · 14 settembre | Altri tentativi sul PC con RTX 5070; annotazioni d’uso senza un riepilogo completo delle impostazioni | Circa 4 token/s annotati durante l’utilizzo |
| GLM-4.7-Flash Q4_K_M | RTX 5070; variante unsloth/GLM-4.7-Flash-GGUF | Circa 27–28 token/s in generazione negli appunti d’uso |
| Bonsai 2 27B PQ2_0 · 1 ottobre | RTX 5070, build CUDA, contesto configurato a 131.072 | Modello caricato e server in ascolto |
| Bonsai 2 27B PQ2_0 · 30 settembre | RX 570 8 GB, build Vulkan; tentativi con contesti e offload diversi | Errori nell’adattamento alla memoria disponibile e sessioni terminate durante l’avvio |
Qwen: la risposta veloce e l’attesa prima di leggerla
Il log del 13 settembre mi ha dato due numeri che vale la pena tenere separati. La generazione era a circa 38,1 token/s, mentre l’elaborazione del prompt era a circa 9,1 token/s. La velocità con cui compaiono le parole non descrive tutta l’attesa: prima di rispondere il server deve lavorare sul testo in ingresso.
Nei tentativi successivi abbiamo annotato anche circa 4 token/s. Non abbiamo conservato tutte le condizioni per isolare la causa della differenza. Per me è un motivo per salvare la configurazione di una sessione riuscita prima di cambiare file, build o contesto. La variante LowGPU-NoMTP IQ3_XXS compare negli appunti del 15 settembre: non la attribuisco automaticamente al log veloce del 13.
Con un agente la cosa diventa ancora più evidente. Una richiesta può generare più chiamate al modello, ognuna con nuovi risultati e file da leggere. Preferisco partire da un compito piccolo e capire se il ciclo completo è pratico, invece di guardare soltanto il contatore dei token.
GLM: un riferimento pratico per lavorare sui file
Negli appunti della variante GLM-4.7-Flash Q4_K_M con RTX 5070 ho riportato circa 27–28 token/s in generazione. È stato uno dei riferimenti del percorso con Hermes. Questo numero è un’annotazione d’uso: non ho un protocollo completo con prompt, occupazione della memoria e ripetizioni da confrontare direttamente con Qwen.
L’esperienza mi porta a valutare insieme risposta e azione. Una patch leggibile, il file corretto e una verifica conclusiva sono più interessanti di una risposta lunga prodotta in fretta. Per una modifica chiedo prima di individuare il punto rilevante, poi di intervenire e infine di controllare il risultato.
Bonsai: il ritorno alla build CUDA
Il file usato è Ternary-Bonsai-2-27B-PQ2_0.gguf, circa 6,70 GiB. Il 1 ottobre, con la RTX 5070 e la build CUDA, i log riportano il caricamento del modello e il server in ascolto con contesto configurato a 131.072 token. Questo è il risultato conservato: un avvio operativo. Non equivale a una prova con tutti quei token realmente occupati.
Nella configurazione Bonsai-demo abbiamo lavorato anche con cache KV a 4 bit e proiettore multimodale sulla CPU. Sono scelte che rendono importante guardare l’insieme dei consumi: il file dei pesi non è tutta la memoria richiesta dal server.
La RX 570 e il caso dell’offload che inganna
Il 30 settembre la build Vulkan riconosceva la RX 570 da 8 GB. Durante i tentativi, però, comparivano buffer CPU_REPACK di circa 6.485 MiB, buffer Vulkan molto piccoli e problemi di adattamento alla memoria. Alcune sessioni terminavano prima di lasciare un server utilizzabile.
Il dettaglio che mi è rimasto è questo: una riga che dichiara layer offloaded non basta a capire dove avviene il lavoro. Bisogna leggere i buffer effettivi e arrivare a una risposta. Con quella combinazione di build, formato e scheda non ho una prova riuscita da presentare; non ne ricavo un giudizio su tutte le applicazioni Vulkan o su tutti i modelli utilizzabili dalla RX 570.
Hermes: quando il problema è il ciclo di lavoro
In una delle sessioni di sviluppo l’agente si è fermato dopo otto ricerche search_files senza fare progressi; nell’output comparivano tentativi con espressioni regolari. Da quell’episodio ho ricavato una regola di lavoro: dopo alcuni tentativi identici, cambiare strategia. Una ricerca letterale o la lettura del file già individuato può essere più utile di un’altra regex.
Ho usato questo percorso anche per il sito: contenuti Astro, categorie, percorsi e controlli delle modifiche. Prima di chiedere un’intera migrazione preferisco definire una modifica verificabile e conservare una versione funzionante. L’agente è utile quando il lavoro lascia tracce che posso controllare.
Cosa porto nel prossimo tentativo
- Salvare nome completo del file, revisione della build e comando di avvio.
- Annotare separatamente elaborazione del prompt e generazione.
- Verificare modello caricato, buffer e una risposta prima di collegare l’agente.
- Provare una richiesta ripetibile e una piccola modifica reale nel codice.
- Conservare anche gli errori: spesso spiegano la scelta successiva meglio di un picco di velocità.
Le annotazioni CPU e i benchmark di altre GPU discussi durante le ricerche non entrano in questa tabella: qui raccolgo le sessioni del mio PC. Il prossimo passo è rendere le prove più ripetibili, senza perdere il lato pratico che mi ha portato a iniziare.