Un esperimento da weekend pubblicato su Reddit mostra che il salto dal cloud alla scrivania non è più una questione di principio ma di numeri. L'autore ha messo in piedi un piccolo simulatore di parkour completamente locale, usando un LLM GLM 5.3 Flash su due NVIDIA DGX Spark, con vLLM configurato in tensor parallelism a due vie. Il flusso è orchestrato da Claude Code come scheletro, con una finestra di contesto da 260.000 token. I numeri dichiarati raccontano la storia: circa 1.500 token al secondo in prefill e circa 40 token al secondo in decode con 100.000 token di contesto. Non sono cifre da datacenter, ma per un assistente di coding interattivo si avvicinano alla soglia del 'abbastanza buono' — l'autore lo dice apertamente, e il dettaglio non è banale.

La soglia si sposta in salotto

La prima implicazione riguarda dove finisce il vincolo. Fino a poco tempo fa, un setup simile avrebbe richiesto una GPU con ampia VRAM e un rack, oppure un abbonamento cloud. Oggi due workstation compatte, unite da tensor parallelism e spinte da quantization in formato NVFP4, reggono un modello che l'autore colloca tra GLM 5.1 e GLM 5.3 nei compiti di coding, con buone capacità visive e di comprensione 3D. Il vero segnale non è la velocità di picco: è che il compromesso tra memoria, qualità e latenza si è spostato dentro un budget domestico. Questo cambia gli incentivi per chi sviluppa applicazioni che toccano dati sensibili o per chi vuole iterare senza costi variabili.

Il prezzo nascosto del 'abbastanza buono'

Ma il setup racconta anche una storia meno comoda. Il decode a 40 token al secondo con 100.000 token di contesto è interattivo, ma non lascia molto margine quando il modello deve ragionare su codebase lunghe o generare più passaggi in parallelo. Il prefill alto indica che il collo di bottiglia non è il riempimento del contesto, ma la generazione sequenziale. Chi punta su sistemi locali deve accettare un trade-off preciso: la sovranità dei dati e la prevedibilità dei costi si pagano in throughput, almeno su questa classe di macchine. Il tensor parallelism a due vie su due DGX Spark è un compromesso intelligente, ma non elimina il problema di fondo: la VRAM aggregata e la larghezza di banda di memoria restano le variabili critiche.

La seconda conseguenza è per l'ecosistema dei modelli e degli strumenti. Un esperimento come questo non funziona senza un serving engine maturo: vLLM, con il supporto al tensor parallelism e alle quantizzazioni a bassa precisione, diventa un pezzo centrale della catena, non un dettaglio operativo. Allo stesso tempo, l'uso di Claude Code come scaffold suggerisce che il valore si sta spostando dal singolo checkpoint all'orchestrazione: il modello è importante, ma il flusso di lavoro intorno è ciò che rende il setup utilizzabile giorno per giorno. Per i vendor hardware, la notizia è duplice: da un lato, c'è una domanda nuova per workstation AI compatte; dall'altro, la competizione si sposta sulla capacità di far girare modelli sempre più grandi su memoria unificata senza costringere l'utente a smanettare con configurazioni estreme. Per chi valuta deployment on-premise, questi trade-off sono al centro dei framework analitici che AI-RADAR propone su /llm-onpremise.

Il weekend dell'autore è un segnale: la soglia del 'good enough' per l'assistenza al codice in locale si è spostata dalle sale server ai tavoli di casa. Non è ancora la fine del cloud, ma è l'inizio di un mercato in cui la scelta non è solo tecnica, ma di controllo e prevedibilità.