Nel repository di llama.cpp è comparsa la pull request #29887, firmata da am17an, con un titolo che va dritto al punto: aggiungere una cache GPU per gli esperti MoE mantenuti in memoria di sistema. La descrizione è scarna ma chiara: un possibile speedup significativo per i modelli che non entrano completamente in VRAM, accompagnato da un invito poco accademico a mostrare i propri risultati per chi ha poca memoria video. Nessun benchmark incluso, solo una direzione tecnica.

I modelli Mixture of Experts non attivano tutti i parametri a ogni token: il routing seleziona un sottoinsieme di esperti. Quando il modello supera la capacità della VRAM, gli esperti restano nella RAM di sistema e ogni passaggio di inference richiede di trasferire sulla GPU quelli necessari. È un collo di bottiglia noto a chi usa llama.cpp per eseguire modelli in locale: la GPU aspetta dati che arrivano da un supporto molto più lento.

La proposta tenta di aggirare il problema con una cache: gli esperti usati più spesso restano in VRAM, pronti per i token successivi. Se il routing è sbilanciato e un piccolo gruppo di esperti viene richiamato di continuo, anche una cache limitata può ridurre la quantità di trasferimenti. Non si aggiunge memoria video; si usa meglio quella già disponibile.

La lettura più interessante, però, non è l'ottimizzazione in sé ma il cambio di prospettiva che introduce. Il limite non è più soltanto «quanti parametri stanno in VRAM», ma «come si gestisce il traffico tra memoria host e GPU». Questo sposta l'attenzione dal costo per gigabyte di memoria video alla qualità della gerarchia di memoria complessiva: banda della RAM, latenza del bus, politiche di caching. Per i deployment on-premise e self-hosted, il segnale è strutturale: un sistema con una GPU modesta e molta RAM di sistema può diventare una base più credibile per modelli MoE grandi, a patto che il software sappia sfruttare la località degli accessi. Il TCO cambia, perché la RAM di sistema costa meno della VRAM e permette di aggiornare il parco macchine in modo incrementale.

Da qui si aprono implicazioni di secondo ordine. Se la cache dimostra di funzionare, i progettisti di modelli MoE potrebbero iniziare a pensare il routing anche in funzione dell'hit rate della cache locale, non solo della qualità del singolo esperto. I runtime come llama.cpp potrebbero evolvere verso prefetching predittivo o cache adattive. Chi ci guadagna sono i progetti open source e gli utenti con GPU limitate, che possono sperimentare modelli più grandi senza cambiare scheda. Chi perde, almeno in parte, è l'idea che per l'inference locale di modelli grandi serva per forza una GPU con molta VRAM; la combinazione tra una scheda modesta e una RAM abbondante diventa un'alternativa più concreta per chi ragiona in ottica di controllo e costi.

Non è un caso che la pull request si chiuda con un tono da comunità: «Are you GPU Poor? Show your speedups ;)». È il metodo di llama.cpp, dove il banco di prova sono i test distribuiti su hardware eterogeneo, non le slide di un fornitore. Per chi osserva il deployment locale, la vera domanda non è se la cache verrà accettata nel codice, ma se i test della comunità confermeranno che la strada è percorribile. E questo, in un settore abituato a numeri da datacenter, è già un segnale.