Il post non arriva con benchmark da laboratorio. Racconta però una soglia che molti team di sviluppo stanno osservando in queste settimane: un LLM da 27 miliardi di parametri, opportunamente quantizzato, entra in una GeForce RTX 3090 da 24 GB di VRAM e regge un contesto da 100.000 token. L'autore ringrazia i team Qwen e Unsloth per la versione Qwen3.8 27b UD Q4_K_XL e la definisce fenomenale per il lavoro sulla propria macchina. Il dettaglio non è tecnico fine a sé stesso: 100.000 token di contesto su una scheda consumer del 2020 cambiano i termini del coding agentico in locale.

La provocazione vera è un'altra: a erodere i ricavi di Anthropic e OpenAI non sarebbero i modelli di frontiera, ma i piccoli modelli self-hosted che coprono l'80-90% del lavoro ripetitivo per ore senza pagare una singola chiamata API. È una tesi che sposta il confronto dai benchmark alla struttura dei costi. Se un team può tenere in casa un modello abbastanza veloce per la maggior parte dei task, la componente variabile della spesa cloud si riduce e la decisione si sposta su hardware, manutenzione e competenze operative. Non è una questione di privacy soltanto: è un problema di TCO.

Il passaggio successivo, però, è dove la strada si fa ripida. L'autore ha due RTX 3090 e 128 GB di DDR4: Qwen3.8-Flash-Next in Q4 gira rapido ma, per sua percezione, non è molto più intelligente del Qwen2.8 27b. MiniMax-M2.7 resta il suo modello di lavoro, ma è troppo lento per il coding. Per un salto verso MiniMax-M3 chiede se un cluster DGX da due a quattro macchine o un server con due o quattro GPU — tra 96 e 192 GB di VRAM e oltre 256 GB di DDR4 — possa sostenere più di 30 token al secondo per coding agentico. È la domanda giusta, perché in questa fascia i colli di bottiglia non stanno solo nel numero di parametri: contano la larghezza di banda della memoria, la quantization, il numero di GPU e la capacità di distribuire il carico di inference senza scaricare i pesi sulla RAM di sistema.

Su una singola GPU da 24 GB i modelli più grandi vanno quantizzati o divisi. Con due schede si può attivare il parallelismo, ma il bus PCIe e la latenza tra le GPU diventano il limite. I server con quattro GPU e tanta DDR4 non risolvono da soli il problema: se il modello non sta nella VRAM aggregata, il trasferimento continuo verso la memoria di sistema fa crollare la velocità di generazione. Per sostenere 30 token al secondo in coding agentico servono non solo teraflop, ma un equilibrio tra capacità VRAM e interconnessione. In questo senso, il post segnala un vuoto di offerta: da una parte ci sono i modelli compatti che girano su hardware consumer, dall'altra i modelli grandi che richiedono infrastrutture di fascia alta; il segmento intermedio, per chi vuole un salto di qualità senza acquistare un DGX, è ancora poco presidiato.

Chi guadagna da questo scenario sono i team che sanno gestire quantization e serving locale e i produttori di GPU consumer con VRAM abbondante. Chi perde terreno sono le API cloud per i carichi ripetitivi, perché ogni token generato in locale ha un costo marginale quasi nullo. Le organizzazioni senza competenze interne, invece, rischiano di sommare il costo dell'hardware alla complessità di gestione. Il post lascia aperta la domanda se il costo valga la pena, ma la riformula correttamente: non è il prezzo della GPU, è il TCO di un'infrastruttura che deve restare accesa, aggiornata e manutenuta.

Per chi valuta deployment on-premise, esistono trade-off tra spesa iniziale, consumo energetico e gestione dei modelli; AI-RADAR propone framework analitici su /llm-onpremise per valutare questi scenari senza ridurli a una lista di specifiche. Il dato più interessante, nel frattempo, resta la soglia d'ingresso: 24 GB di VRAM bastano per un LLM da 27B con contesto da 100k. È il tipo di soglia che cambia le decisioni di acquisto molto più di un benchmark.