Una sera di maggio 2026, sabato, le 22:30. Apro Claude Code in locale, con il backend puntato al modello GLM 4.7 Flash che gira sulla RTX 5090 del server di casa. Gli chiedo, in italiano, di farmi un clone funzionante di Tetris in HTML/JS singolo file, con rotazioni, livelli, scoring. Premo invio. Il modello pensa per quaranta secondi, sputa fuori 800 righe di codice, lo apro in browser. Funziona. Non a metà: funziona davvero, livelli aumentano, le tessere ruotano correttamente, lo scoring sale. Non sto chiamando un’API cloud. Non sto pagando per token. È tutto sulla mia scheda da 2000 euro, in casa, con la fibra spenta.
Ottobre 2024 ho scritto qui di routing multi-LLM in produzione con cinque provider commerciali e Llama via Ollama come fallback economico. Il fallback Ollama era marginale: per task batch a bassa criticità, normalizzazione, classificazione semplice. Per qualunque cosa con un minimo di ragionamento, l’unica scelta seria era il cloud. Diciotto mesi dopo, lo scenario è cambiato abbastanza da meritare un secondo post. Vedi anche gli altri post di questa rubrica: Production.
Lo stato del 2024 (richiamo veloce)
Per chi non ha letto il post di ottobre 2024: il routing multi-LLM in AI Multisite girava su quattro provider commerciali (OpenAI, Anthropic, Gemini, xAI) più Llama 3 self-hosted via Ollama come quinto backend. Il modello locale serviva i task batch a basso costo: estrazione entità, classificazione tag, embedding di basso livello. Per qualunque task con ragionamento (generazione articolo, riformulazione titolo, suggerimento bozza creativa) la qualità di Llama 3 13B/70B in locale era visibilmente sotto rispetto a Claude o GPT-4. Il routing premiava il cloud per qualità, il locale per costo marginale zero.
Due limiti strutturali nel 2024:
- Capability agentica nulla in locale. I modelli open-weight 2024 non gestivano bene il function calling complesso, il multi-step reasoning, la chiamata iterativa di tool. Tutto l’agentico (cioè un modello che decide autonomamente quali strumenti chiamare, in che ordine, e itera fino a chiudere il task) era cloud-only.
- Hardware proibitivo. Per far girare decentemente un Llama 3 70B in locale serviva una scheda da 80 GB di VRAM, mercato enterprise, prezzi sopra i 9-10mila euro.
Il salto 2025-2026
Tre modelli hanno cambiato il calcolo, in tre direzioni diverse:
GLM 4.7 Flash (Zhipu AI, fine 2025/inizio 2026): un modello open-weight cinese ottimizzato per agentico e coding. La variante Flash è quantizzata e ottimizzata per girare su GPU consumer high-end (32 GB VRAM tipo RTX 5090 o equivalenti). Performance generative comparabili a Claude Sonnet 3.5 (il modello cloud di metà 2024), capability agentica funzionante: function calling, multi-step reasoning, tool use iterativo. È il primo modello open che integra in modo decente con Claude Code e altri agent framework senza degradare oltre soglia.
Qwen3 30B MoE (Alibaba, 2025/2026): mixture of experts da 30B parametri totali, di cui solo 4B attivi per inference. Il modello pesa intorno ai 26 GB quantizzato, sta intero in una RTX 5090 da 32 GB con margine per il contesto. Eccellente su task di coding (refactoring, generazione di codice strutturato, debugging), velocità di inference comparabile a Sonnet 3.5 cloud per task brevi. La MoE come architettura ha sbloccato qualità superiore a parità di VRAM, perché il routing interno tra esperti permette di concentrare la capacità solo dove serve.
GPT OSS 20 (OpenAI, 2025): finalmente un modello open-weight da OpenAI, 20B parametri, ottimizzato per task testuali. Pesa 14-15 GB quantizzato, sta in una RTX 5080 da 16 GB. Ottimo per classificazione, riformulazione, generazione di testo strutturato. NON adatto ad agentico complesso: il contesto utile è più piccolo del necessario per workflow Claude Code seri.
Whisper Large v4 (OpenAI, modello più vecchio ma rilevante qui): da 4 GB di pesi, voice-to-text con accuratezza che misuro intorno al 99.5% su lingue note (italiano, inglese), funziona su qualunque GPU con almeno 6 GB di VRAM. È il modello che mi ha sostituito Otter e simili servizi cloud per le trascrizioni di interviste e meeting.
Il setup di casa
Hardware su cui giro tutto:
- RTX 5080 16 GB dentro un server Proxmox con CPU 8 core / 16 thread e 64 GB RAM. La uso per GPT OSS 20 e Whisper, oltre a VM di sviluppo standard.
- RTX 5090 32 GB in un server dedicato all’AI, comprata a listino Nvidia (2000 euro contro i 4000-4500 euro dei rivenditori). Una volta nella vita ho beccato una promo direttamente sul sito Nvidia con acquisto aziendale e ho preso al volo. La uso per GLM 4.7 Flash e Qwen3 30B MoE.
- Cluster Proxmox che orchestra tutto: VM dev, LXC con i runtime di inference (Ollama, vLLM), Tailscale per accesso da qualunque rete.
Sopra ci giro:
- Ollama come runtime di base per modelli quantizzati GGUF, quando voglio start rapidi e API compatibile con OpenAI.
- vLLM per modelli più grandi e workload con concorrenza, dove ho bisogno di batching automatico e prestazioni sopra i 100 token/s.
- Whisper.cpp per la trascrizione voce, runtime ottimizzato in C++ che gira anche su CPU pura se serve.
- Claude Code in locale con backend custom puntato al server Ollama/vLLM, per agentico coding sui modelli open-weight.
Il principio che ha cambiato tutto, ed era già emerso al WP Meetup di Pisa di marzo: il modello deve entrare interamente in VRAM, peso più contesto. Se inizia ad andare in offload sulla RAM di sistema (CPU offload), la GPU lavora al 5%, la CPU al 100%, e quello che dovrebbe richiedere un minuto richiede ore o giorni. Una scheda grafica fa in un minuto quello che un PC senza scheda fa in tre giorni, e basta sforare di 1 GB la VRAM per cadere nel secondo regime.
Test 1: GLM 4.7 Flash su Claude Code, clone Tetris
Apertura del post: il clone Tetris. Ripeto il setup per chiarezza. Claude Code in locale, configurazione per puntare al server di inference della 5090 invece che alle API Anthropic. Il modello attivo è GLM 4.7 Flash, quantizzato 4-bit, 26 GB di VRAM occupati con un contesto di 32k token. Velocità di inference intorno ai 60 token/s in output.
Prompt: “Crea un clone di Tetris in un singolo file HTML, con CSS e JS inline. Rotazione delle tessere con i tasti freccia, scoring per linea completata, gameover, livello che aumenta velocità ogni 10 linee.”
Output: 800 righe di HTML/JS, prodotte in 35 secondi. Apro il file in Chrome. Funziona al primo colpo. La griglia è disegnata correttamente, le tessere cadono, le rotazioni funzionano (anche la rotazione contro il muro, che è un caso edge classico), lo scoring sale, il gameover compare quando la pila raggiunge il top. Livello che aumenta la velocità: implementato, funziona.
Lezione: per task ben definiti, scope chiuso, output deterministico, il modello locale è completamente equivalente al cloud. Non è il cloud Sonnet 4.6 di oggi, è il cloud Sonnet 3.5 di 18-24 mesi fa, ma è in casa, gratuito a marginal cost, e va bene per la maggior parte dei task di coding.
Cosa non funziona altrettanto bene: feature più complesse aggiunte in iterazione successive (“aggiungi un sistema di power-up”, “fai un boss mode”) iniziano a entrare in loop, dove il modello rigenera la stessa modifica, peggiora il codice o introduce bug che poi tenta di sistemare con altri bug. È esattamente il comportamento dell’agentico cloud di un anno fa. Il salto rispetto a Llama 3 del 2024 è enorme. Il gap rispetto a Sonnet 4.6 cloud è quello.
Test 2: Qwen3 30B MoE per refactoring di FastAPI
Caso d’uso reale: ho un microservizio FastAPI di un progetto interno, una settantina di endpoint, organizzazione cresciuta male nel tempo. Mi serve dividere routes.py (un file da 1800 righe) in moduli per dominio funzionale, mantenendo i tipi di richiesta/risposta, gli import, i decorator di autorizzazione.
Test condotto su Qwen3 30B MoE, sempre su 5090, 26 GB VRAM, contesto 32k.
Pattern: passo il file routes.py intero, chiedo di proporre uno splitting in moduli con motivazione (perché questo gruppo di endpoint sta insieme), poi gli faccio generare i nuovi file uno alla volta.
Output: refactor in 5 moduli, organizzati per dominio (auth, user, content, billing, internal). Ogni modulo è coerente, gli import sono corretti, i decorator di FastAPI sono mantenuti, i tipi Pydantic sono importati correttamente. Velocità di generazione: comparable a Sonnet 3.5 cloud, 70-80 token/s. Latenza al primo token: 800 ms (locale, niente roundtrip cloud).
Una cosa che mi ha sorpreso: la qualità del refactor era leggermente sopra le mie aspettative, in particolare nella scelta dei nomi dei moduli e nell’organizzazione dei file di routes nested. Non spaccato Claude Sonnet 4.6 (che ti propone direttamente una architettura con dependency injection rivista), ma in linea con quello che mi aspetto da un buon middle dev.
Lezione: per task di coding strutturati, scope chiaro, codebase non gigantesca, Qwen3 30B MoE è oggi il default sensato in casa. Lo uso per il refactoring quotidiano di codice senior, e tengo Sonnet 4.6 cloud per i task dove serve davvero ragionamento architetturale o capacità di sintesi su grandi codebase.
Test 3: GPT OSS 20 per classificazione editoriale
Caso d’uso: ho una pipeline editoriale che classifica articoli in arrivo per categoria, sottocategoria, tag, sentiment, audience target. Sul cloud uso GPT-4o-mini per costo ragionevole. Volevo testare se GPT OSS 20 in locale potesse sostituirlo per i tenant a budget stretto.
Hardware: RTX 5080 16 GB, GPT OSS 20 quantizzato a 14 GB, contesto 8k.
Setup: 1000 articoli campione, già classificati manualmente come ground truth. Misurazione: F1 score per categoria principale, accuracy per sentiment, e tempo medio di inference per articolo.
Risultati:
- Categoria principale: F1 0.91 vs 0.93 di GPT-4o-mini. Differenza non significativa per il caso d’uso.
- Sottocategoria (granularità più fine): F1 0.78 vs 0.86 di GPT-4o-mini. Gap reale, GPT OSS 20 fatica sui distinguo fini.
- Sentiment (positive/neutral/negative): accuracy 0.87 vs 0.89. Equivalente.
- Tempo per articolo: 1.2 s in locale vs 600 ms cloud. Più lento, ma assolutamente accettabile per una pipeline notturna.
Cosa NON funziona: appena ho provato a metterlo in modalità agentica (function calling, scelta di chiamare un classifier specifico per dominio invece di rispondere diretto) è collassato. Il contesto utile è troppo piccolo per gestire schema di tool definition + storia conversazionale + reasoning. È un classificatore eccellente, non è un agent.
Decisione finale: per i tenant a budget stretto, sposto la classificazione su GPT OSS 20 in locale come primary, GPT-4o-mini cloud come fallback. Risparmio mensile stimato: 60-70% sul costo di classificazione di quei tenant.
Test 4: Whisper su intervista di 47 minuti
Caso d’uso quotidiano: ho un’intervista di 47 minuti registrata in studio, audio pulito, due voci alternate, italiano. Voglio trascrizione + diarization (chi parla quando) per usarla come base di un articolo.
Setup: Whisper Large v4, 4 GB pesi, gira su RTX 5080. Whisper.cpp come runtime, modalità GPU.
Tempo di esecuzione: 4 minuti di processing per 47 minuti di audio. Ratio 12x real-time, niente male.
Qualità: misuro l’accuratezza confrontando con una trascrizione manuale di un campione di 5 minuti. Whisper sbaglia 3 parole su 627 totali nel campione. Accuratezza misurata: 99.5%. Le 3 parole sbagliate sono nomi propri (un cognome straniero, un nome di prodotto custom), niente di drammatico.
Diarization: Whisper Large v4 da solo non fa diarization, serve un modulo separato (pyannote-audio o simili) per associare segmenti a speaker. Tempo aggiuntivo: 90 secondi. Accuratezza diarization: 96% sui passaggi di voce, qualche errore solo su sovrapposizioni.
Output finale: trascrizione in markdown con timestamp e identificazione speaker, pronta per essere editata. Lavoro che 24 mesi fa avrei dato a un servizio cloud a 10-15 euro per ora di audio, oggi è gratis a marginal cost, gira sulla 5080 mentre faccio altro.
Quando ha senso il routing locale
Quattro assi su cui valutare se spostare un task da cloud a locale:
Privacy. Documenti riservati, contratti, trascrizioni di meeting confidenziali, codice proprietario. Tutto quello che non vuoi su un’API che non hai sotto controllo, anche se contrattualmente OK, va in locale. Il cliente che ci tiene alla sovranità del dato si sente più a suo agio sapendo che la trascrizione del board meeting non è mai uscita dal suo perimetro fisico.
Costi a volume. Sopra una certa soglia di volume mensile, il break-even si sposta dal cloud al locale. La 5090 a 2000 euro, 35 euro/anno di corrente, ammortizzata su 24 mesi: 85 euro/mese per VRAM equivalente a un servizio cloud che ti costerebbe centinaia di euro al mese di sole API. Il break-even dipende dal task: per chi fa 100k chiamate al mese di classificazione, il locale paga in 6 mesi. Per chi fa 500 chiamate al mese di Sonnet 4.6 cloud, non paga mai.
Lock-in dei provider. Al WP Meetup di Pisa è uscita questa frase, dal pubblico, che mi è rimasta: siamo diventati i giardini dei cinque grandi. Chi controlla il modello, controlla cosa ci puoi fare sopra. Chi fa girare un modello in casa ha un’opzione di uscita. Se domani Anthropic alza i prezzi del 50% (è già successo a OpenAI quando ha rilanciato GPT-5), o cambia le policy d’uso, o decide di non servire più il tuo settore, hai un’alternativa pronta. Non serve che il locale sia equivalente al cloud, basta che sia “abbastanza” per la maggior parte dei task.
Latenza. Un task interattivo che parte da locale evita il roundtrip Internet, salta il TLS handshake con i server del provider, e risponde al primo token in 200-500 ms invece di 800-1500. Per un IDE assistant che ti suggerisce mentre scrivi, la differenza si sente. Per un task batch notturno, no.
Cosa NON funziona ancora in locale
Onestà al netto dell’entusiasmo: tre cose dove il cloud resta strettamente superiore.
Agentico complesso. Workflow lunghi con 30-50 step, decisioni di tool selection in cascata, gestione di errori che richiede ragionamento sul contesto storico. Claude Code con Sonnet 4.6 o Opus 4.7 cloud regge questi flussi, GLM 4.7 Flash in locale entra in loop o sbaglia tool dopo i primi 8-10 step. Il gap è di quel “circa un anno” che cito prima.
Contesti enormi. Sonnet 4.6 ti porta 200k token di contesto, Opus 4.7 il milione di token. Sui modelli open in locale, il contesto utile reale (cioè dove il modello attinge davvero alle informazioni passate, non dimentica) sta sui 32k token. Per task come “leggi questa codebase di 3000 file e proponimi un refactor”, il cloud è ancora obbligato.
Multi-step reasoning su problemi non strutturati. “Date queste 5 fonti contraddittorie, identifica le tre più probabili cause della discrepanza” è un task dove i modelli reasoning di OpenAI (o-series) e Claude con extended thinking restano avanti di una generazione rispetto a tutto l’open-weight.
Per tutto il resto (la maggior parte del coding quotidiano, la maggior parte della classificazione, la trascrizione voice, la generazione di testi brevi strutturati) il locale 2026 è abbastanza.
Cosa avrei rifatto diversamente
Una cosa, retroattiva: avrei iniziato a fare benchmark sistematici già a fine 2025. La mia partenza è stata opportunistica: ho preso la 5090 a listino quando si è presentata, ho installato Ollama, ho testato qualche modello in modo casuale. Solo a febbraio 2026 ho iniziato a costruire un set di benchmark riproducibili (una decina di task standard per categoria, ground truth fissato, misurazione automatica) per confrontare ogni nuovo modello rilasciato con quelli precedenti.
Sapere oggi che GLM 4.7 Flash è arrivato a livello di Sonnet 3.5 è facile. Saperlo a gennaio 2026, quando il modello è stato rilasciato, mi avrebbe permesso di spostare prima una buona fetta di routing locale, abbassando i costi cloud di tre mesi. Lezione generale: in un campo che evolve mensilmente, il benchmark sistematico vale più di qualunque ottimizzazione singola.
L’altra cosa, marginale: avrei comprato due 5090 invece di una. Una per il server AI dedicato, una per il backup hardware. Quando una scheda esce di stock e arriva a costare il doppio, avere il pezzo di ricambio già in casa è il margine che paga la differenza.
I numeri di esercizio
| Modello | Hardware | Use case | Vs cloud equivalente |
|---|---|---|---|
| GLM 4.7 Flash | RTX 5090 32 GB | Coding agentico Claude Code | ~Sonnet 3.5 cloud |
| Qwen3 30B MoE | RTX 5090 32 GB | Refactoring strutturato | ~Sonnet 3.5 cloud |
| GPT OSS 20 | RTX 5080 16 GB | Classificazione testi | ~GPT-4o-mini cloud |
| Whisper Large v4 | RTX 5080 16 GB | Voice-to-text | Trascrizioni studio |
| Sonnet 4.6 cloud | API Anthropic | Reasoning architetturale | (lui stesso) |
| Opus 4.7 cloud (1M) | API Anthropic | Contesti enormi, plan | (lui stesso) |
La filosofia di routing nel 2026 mette i pezzi in cascata: Opus per il piano e per i contesti enormi, Sonnet 4.6 per il ragionamento ad alto livello quando il prezzo per token è giustificato dal task, GLM 4.7 Flash o Qwen3 in locale per l’esecuzione del piano (la maggior parte del lavoro effettivo in volume), GPT OSS 20 per task testuali ad alto throughput, Whisper per il voice-to-text, fallback cloud quando il locale non basta.
Il routing del 2024 era cloud-first con Ollama come fallback economico marginale. Il routing del 2026 è ibrido, con il locale che gestisce circa il 60-70% del volume e il cloud i task che richiedono davvero la potenza di Opus o Sonnet 4.6. La curva del prossimo anno la vedo continuare in questa direzione: ogni sei mesi un modello open-weight arriva a chiudere ulteriormente il gap, e il cloud resta riserva per il reasoning di frontiera. Le partnership tecniche con i clienti che hanno volumi alti sono il vero R&D di questa scelta: ci hanno permesso di misurare il break-even in produzione, non in astratto, e di tarare il routing su numeri reali invece che su benchmark di laboratorio.