Far girare un LLM di ultima generazione in un home lab è sempre un azzardo controllato. Stavolta il banco di prova è Kimi K3, un modello ancora poco documentato, sbarcato su un sistema con 768GB di RAM DDR5 e due GPU NVIDIA 5090. L’utente iVoider ha pubblicato su Reddit i primi risultati, ottenuti con un fork di llama.cpp dedicato e una quantization Q2_K del modello.

Il dato più appariscente è la forbice tra prefill e decodifica: 50-70 token/s per l’elaborazione di prompt lunghi, contro una velocità di generazione che si attesta sui 4 token/s. Sono numeri che, in un contesto on-premise con hardware consumer, segnalano un compromesso riuscito: la capacità di eseguire un modello pensato per infrastrutture ben più costose, accettando un throughput interattivo appena sufficiente per chat o batch processing non urgenti.

Ma è il comportamento della decodifica nel tempo a meritare attenzione. L’utente nota che i token/s aumentano progressivamente durante la generazione, un dettaglio che esula dalla semplice aneddotica e punta a una dinamica tecnica precisa: il caldo della cache. Con ogni probabilità, il meccanismo di offloading di llama.cpp sposta parte della KV cache tra VRAM e RAM di sistema, e i primi token scontano un costo di swap elevato. Man mano che la cache si stabilizza, le richieste di memoria diventano più locali e la banda DDR5, pur lenta rispetto alle HBM delle GPU, comincia a essere sfruttata in modo più efficiente.

Il fenomeno illumina un nodo strutturale per chiunque valuti deployment on-premise di LLM di grandi dimensioni. La capacità di memoria non basta: è la banda a determinare la latenza di ogni token generato. In configurazioni ibride come questa, dove la VRAM totale delle due 5090 è comunque limitata, la RAM di sistema fa da estensione, ma paga un dazio in termini di velocità effettiva. L’accelerazione osservata è un effetto collaterale di un’architettura di memoria gerarchica ancora non ottimizzata per l’inference continua.

L’esperimento, nella sua semplicità, manda un segnale duplice. Da un lato, conferma che il ritmo di sviluppo di tool come llama.cpp sta erodendo il vantaggio competitivo dei sistemi enterprise: con poche migliaia di euro di schede e tanta DDR5 si possono esplorare modelli che fino a ieri sembravano appannaggio di cluster aziendali. Dall’altro, rimette al centro la questione della sovranità dei dati e del controllo dell’infrastruttura: un’organizzazione che volesse mantenere tutto in sede, magari per vincoli GDPR, deve fare i conti con velocità borderline e con la necessità di mettere a punto pipeline di serving tolleranti alla latenza variabile.

Kimi K3 su home lab non è un benchmark da laboratorio, ma una prova di concetto su strada. La prossima sfida non sarà solo spremere più token/s dalla DDR5, ma gestire in modo deterministico l’accelerazione della decodifica, magari con scheduler che sfruttino il warm-up della cache per incanalare più richieste consecutive. Fino a quel momento, chi spinge l’on-premise dovrà convivere con un decode che parte pigro e poi prende ritmo, un piccolo mistero tecnico che racconta quanto sia ancora giovane l’ecosistema del self-hosting AI.

L’esperimento conferma che le quantizzazioni estreme (Q2_K) sono un alleato indispensabile per abbattere la barriera di memoria, ma al tempo stesso ricordano che la qualità del modello può risentirne in carichi complessi. È un trade-off ormai familiare a chi segue il deployment locale, qui reso tangibile da numeri concreti.