Chi gestisce modelli linguistici in locale sa che aggiornare la conoscenza significa quasi sempre interrompere il servizio, ricaricare i pesi e riavviare l'inference. Un progetto pubblicato su Reddit prova a cambiare le regole: modifica llama.cpp per scrivere nella tabella Ngram PLE di Qwen-3.8-Next-Flash mentre il modello è in esecuzione, senza riavvii.

Gli strumenti sono due: una modifica a llama.cpp, chiamata NLTM, e un 'knowledge injector' separato che prepara le patch della tabella. Il metodo sfrutta il fatto che la tabella PLE è aggiornata a ogni prompt; di conseguenza è possibile sostituirne parti a caldo. I vincoli tecnici, però, non mancano. La tabella deve restare mappata in memoria (opzione predefinita in llama.cpp) e il progetto è stato verificato soltanto con quantization q8, il che richiede una quantità di memoria non trascurabile.

Un problema di controllo più che di memoria

L'aspetto più delicato è la posizione dell'iniezione. Le embedding modificate entrano nei primi layer della rete: questo rende difficile prevedere l'effetto esatto sull'output. L'autore del progetto ammette che il controllo non è affidabile, ma mostra come alcune tecniche semplici riescano a orientare le risposte. È una differenza sostanziale rispetto a un database esterno interrogato tramite RAG: lì la conoscenza resta separata e verificabile; qui entra direttamente nella rappresentazione interna del modello, con effetti più profondi ma meno governabili.

Per chi gestisce deployment self-hosted, il segnale strutturale è duplice. Da un lato, la possibilità di aggiornare conoscenza a caldo riduce i tempi morti e apre scenari di personalizzazione continua senza fine-tuning completo. Dall'altro, la difficoltà di controllo rende il metodo più adatto a influenzare stile, preferenze o contesto che a garantire fatti verificati. In ambienti on-premise, dove la sovranità dei dati e la prevedibilità operativa contano, questa distinzione non è accademica. Per chi valuta deployment on-premise, AI-RADAR offre framework analitici su /llm-onpremise per mappare questi trade-off.

Gli incentivi si spostano: chi ha carichi di lavoro locali con domini che cambiano spesso potrebbe trarre vantaggio da un aggiornamento incrementale, mentre chi vende pipeline di fine-tuning o gestione dei pesi vede complicarsi il perimetro del 'riaddestramento'. Non è un sostituto del fine-tuning, ma un'alternativa a basso costo che apre una strada diversa: memoria a lungo termine istantanea e modificabile, la versione LLM del 'I know kung-fu' citata nel repository.

Resta il limite più concreto: senza metriche affidabili di controllo, la memoria a caldo rischia di restare un esperimento brillante ma confinato a contesti non critici. L'infrastruttura on-premise, con i suoi vincoli di memoria e TCO, sarà il banco di prova naturale per capire se il compromesso regge.