Il salto è difficile da ignorare. inclusionAI ha pubblicato su Hugging Face Ling-3.1-flash, un Large Language Model con 560 miliardi di parametri totali, 25 miliardi di parametri attivi per token e una context window da 1 milione di token. La discussione parte da un confronto immediato: il precedente Ling 3.0 veniva indicato a 127 miliardi di parametri. Ma leggere questi numeri come un semplice aumento di scala sarebbe riduttivo.

La distanza tra 560B totali e 25B attivi per token è il dettaglio che spiega la natura del modello. Siamo di fronte a un'architettura di tipo mixture-of-experts: a ogni token non vengono usati tutti i parametri, ma solo una parte. Questo riduce la quantità di calcolo per token rispetto a un modello denso della stessa dimensione complessiva. Il costo computazionale per token si avvicina a quello di un modello da 25 miliardi, non da 560. Ma il costo di memoria resta legato ai parametri totali.

Dove si nasconde il costo

Per chi ragiona in ottica self-hosted, il problema non è il numero di parametri attivi, ma la quantità di VRAM necessaria a tenere in memoria tutti gli esperti. In FP16, 560 miliardi di parametri occupano circa 1,12 TB solo per i pesi, prima ancora di considerare la cache KV. Con una context window da 1 milione di token, la cache cresce in modo significativo e può diventare la voce di memoria più costosa in scenari con molte richieste concorrenti o sequenze lunghe.

La quantization diventa quindi il primo strumento per ridurre il fabbisogno: passare a INT8 o a 4-bit taglia l'ingombro dei pesi in modo rilevante, ma introduce un trade-off sulla qualità e sulla complessità di serving. Anche con compressione aggressiva, il modello resta al di fuori della portata di una singola GPU consumer. Servono macchine con VRAM elevata, distribuzione su più schede e strategie di offloading degli esperti, con effetti diretti su latenza, throughput e TCO.

Questo cambia gli incentivi per chi ospita modelli on-premise. La corsa a context window da 1 milione di token non è neutrale: sposta il collo di bottiglia dalla potenza di calcolo alla capacità di memoria e alla gestione della cache KV. Un'infrastruttura dimensionata solo sui parametri attivi rischia di trovarsi satura sulla memoria molto prima di saturare i core di calcolo. È un segnale strutturale: i modelli di nuova generazione con window estreme impongono alle operazioni locali di investire in paging della cache, quantization della KV e distribuzione della memoria, non solo in acceleratori più veloci.

Per chi valuta deployment on-premise, esistono trade-off tra costo della memoria, latenza di risposta e qualità del modello. La scheda tecnica di Ling-3.1-flash, per quanto parziale, funziona come un promemoria: i parametri attivi raccontano solo metà della storia. L'altra metà sta nella memoria necessaria a servire tutti gli esperti e a gestire contesti molto lunghi senza far esplodere il costo operativo. AI-RADAR offre framework analitici su /llm-onpremise per confrontare queste variabili senza ridurre la scelta a un singolo benchmark.