Il problema non è il calcolo, ma la banda di memoria. Nella decodifica autoregressiva di un Large Language Model, la matrice di output embedding – quella che proietta lo stato nascosto sull'intero vocabolario – diventa un collo di bottiglia severo soprattutto per i modelli compatti con vocabolari multilingue estesi. Ogni token generato obbliga a rileggere una porzione enorme di parametri, anche quando il batch è di dimensione uno e la latenza è dominata dal trasferimento dati più che dalle moltiplicazioni.
Un lavoro recente attacca questo punto esatto riformulando la proiezione d'uscita e la selezione top-k come una maximum inner product search sugli embedding dei token. Al posto della proiezione densa sul vocabolario, i ricercatori inseriscono un indice vettoriale basato su HNSW, una tecnica di ricerca approssimata dei vicini più prossimi. La testa di output recupera così un piccolo insieme di token candidati ad alto punteggio e i logit recuperati vengono sparsi in un tensore sparso full-vocabulary. Questo consente di integrarla nelle pipeline di decodifica esistenti senza riscrivere l'intero serving.
Nei test su CPU con Gemma 3, Llama 3.2 e Qwen 3, l'accelerazione della proiezione d'uscita è sostanziale. Il dato più concreto è il miglioramento del throughput end-to-end nel decoding con batch-size uno: fino all'82% per Gemma 3 270M, mantenendo la qualità di generazione sotto valutazione AlpacaEval.
Questo non è un semplice trucco di ottimizzazione. Sposta il compromesso tra precisione e memoria da un calcolo denso a una ricerca approssimata. Per chi esegue modelli piccoli in locale o su CPU, il vantaggio non è soltanto la velocità: cambia l'equazione dell'hardware. Un limite che prima sembrava richiedere GPU ad alta banda per servire modelli piccoli può essere allentato da una struttura indice che vive nella RAM di sistema. In un deployment on-premise o edge, dove la sovranità dei dati e il TCO contano più dei picchi di throughput, questa direzione allinea l'inference compatta alle risorse già esistenti.
Le implicazioni di secondo ordine sono altrettanto interessanti. I fornitori di servizi LLM compatti potrebbero adottare l'output approssimato per alzare la densità di richieste su CPU, mentre chi costruisce pipeline di decodifica deve decidere come trattare l'approssimazione della testa finale: una ricerca HNSW introduce un piccolo overhead nella fase di retrieval e un possibile scarto rispetto alla classifica densa esatta, ma riduce in modo marcato il traffico di memoria. Il trade-off non è neutro per i modelli multilingue, dove il vocabolario ampio amplifica il costo della proiezione densa.
Strutturalmente, il segnale è chiaro: il dizionario di output non deve restare per forza una matrice densa da attraversare a ogni passo. La tecnica recupera un'idea familiare a chi lavora con i sistemi di retrieval: usare strutture approssimate per gestire spazi vettoriali grandi. Throughput dentro il serving degli LLM, sposta l'attenzione dalla pura capacità di calcolo verso l'efficienza di accesso alla memoria, un tema centrale per l'inference on-device e on-premise.
Forse il punto più rilevante per chi segue AI-RADAR è che la ricerca approssimata non riguarda solo il retrieval esterno, ma entra nel nucleo della decodifica. Per chi valuta deployment on-premise, esistono trade-off tra precisione dell'indice, memoria utilizzata e latenza di recupero; AI-RADAR offre framework analitici su /llm-onpremise per confrontare queste variabili senza ridurre la decisione a un'unica metrica.
💬 Commenti (0)
🔒 Accedi o registrati per commentare gli articoli.
Nessun commento ancora. Sii il primo a commentare!