In questo articolo Indice dei contenuti 3 sezioni
Con DeepSeek V4.1 Flash l’azienda cinese ha presentato un modello che sulla carta sembra una contraddizione: è molto più grande del precedente, eppure chiede meno risorse per girare. L’aggiornamento, pensato per abbattere costi e latenza, porta con sé modifiche architetturali che di solito non ci si aspetta da una release minore. E il risultato è un sistema capace di servire molti più utenti senza far esplodere il consumo di memoria.
Partiamo dai numeri, perché sono la parte più sorprendente. Il nuovo modello conta 763 miliardi di parametri, oltre 2,5 volte le dimensioni del predecessore V4 Flash. È più voluminoso persino di V3 e R1, i due modelli che a inizio 2025 avevano fatto conoscere DeepSeek al grande pubblico. Ma la crescita delle dimensioni non si è tradotta in una richiesta proporzionale di memoria, ed è qui che sta il lavoro interessante fatto dagli sviluppatori.
Cache KV più leggere e un nuovo codificatore
Il punto su cui si è intervenuti riguarda la gestione delle cache chiave-valore, le famose KV, che servono a tenere traccia dello stato del modello tra una sessione e l’altra. Sono notoriamente affamate di memoria, soprattutto in applicazioni pesanti come i chatbot, dove ogni conversazione lascia una scia di dati da mantenere. Con gli aggiustamenti ai meccanismi di attenzione e con l’introduzione di un nuovo codificatore decodificatore causale, chiamato CED, il consumo di queste cache scende di una quota compresa tra il 13% e il 25% rispetto a V4 Flash.
Tradotto in pratica: a parità di impronta di memoria dedicata alle cache KV, il modello riesce a gestire da quattro a otto volte più utenti contemporaneamente. Per chi offre servizi basati su AI è una differenza che si vede subito sui costi di esercizio, non un dettaglio da paper accademico.
C’è poi la seconda novità, forse la più curiosa. Dei 763 miliardi di parametri totali, ben 196 miliardi sono N grammi, un tipo di peso che DeepSeek ha raccolto in quello che definisce modulo di memoria condizionale. L’obiettivo dichiarato è separare la memoria dal calcolo, così da rendere il modello più intelligente senza chiedere hardware più muscoloso per farlo funzionare.
Come lavorano gli N grammi
Gli N grammi sono gruppi di token, per esempio coppie o terzine di parole, e funzionano come una riserva di conoscenza implicita. I grandi modelli linguistici di solito calcolano quali combinazioni di token siano più probabili, un processo costoso. Qui invece i pesi N grammi affiancano quel lavoro fornendo in fretta informazioni pertinenti tramite una ricerca poco dispendiosa, una specie di scorciatoia intelligente.
Nella sostanza si comportano come tabelle di consultazione molto grandi. La differenza rispetto agli altri parametri è che non devono essere caricati per intero nella memoria GPU a ogni token generato. Bastano poche decine di ricerche per token, il che permette di parcheggiarli nella memoria di sistema o addirittura su uno storage veloce senza pagare pegno in termini di prestazioni.
Il conto finale è eloquente. In teoria V4.1 Flash richiederebbe 763 GB di memoria GPU per i suoi pesi in FP8, ma spostando altrove gli N grammi il fabbisogno scende a circa 567 GB. In produzione le cifre saliranno, ovviamente, perché entrano in gioco le cache KV, la cui dimensione varia in base alla lunghezza del contesto e al numero di utenti collegati nello stesso momento.
Una strada già battuta anche da altri
L’approccio non è un’esclusiva cinese. Google adotta una tecnica concettualmente simile chiamata Per Layer Embedding, sigla PLE, nei suoi modelli Gemma, che consente di spostare una parte dei pesi verso uno storage locale. Fino a oggi però quel metodo era stato applicato soprattutto a modelli di piccole dimensioni, mentre qui si parla di un sistema da centinaia di miliardi di parametri.
Fonte: TecnoAndroid
