Chi immagina che per migliorare un LLM piccolo serva sempre un fine-tuning aggressivo ha un controesempio concreto. Qwengram-0.8B parte da Qwen3.5-0.8B, congela il backbone e gli affianca una memoria PLE n-gram pretrained di circa 51 miliardi di parametri. Sul set di validazione congelato, la perplexity scende da 18,2759 a 17,3534, con una riduzione del 5,05 per cento. L'autore è esplicito: è un risultato di language model validation, non un guadagno di accuratezza sui benchmark.

L'impianto tecnico è scarno per scelta. Un reader R=1 viene addestrato ai livelli 3 e 9 del decoder, mentre una gate lineare dipendente dal token regola l'iniezione tardiva. Non c'è fine-tuning del backbone. Il checkpoint bilanciato usa un reader addestrato su 15 milioni di token e una gate dinamica calibrata separatamente. Il percorso di inference, invece, è implementato in llama.cpp.

I risultati intermedi spiegano il perché delle scelte. La memoria PLE reale supera i controlli con memoria casuale e con memoria permutata. La loss del reader continua a migliorare oltre i 5 milioni di token. Il reader da 20 milioni riduce ulteriormente la loss aggregata, ma regredisce nei compiti matematici; il checkpoint da 15 milioni resta il punto di equilibrio. Un reader R=4 warm-started, con lo stesso budget di memoria, offre un piccolo miglioramento aggregato ma introduce regressioni su codice e matematica. L'architettura R=1 è una scelta di compromesso, non una semplificazione ingenua.

La parte più interessante riguarda la gate. Un'iniezione fissa e forte negli strati finali peggiora LAMBADA; l'arbitraggio dinamico per token recupera gran parte del compromesso. La gate non si comporta come una costante appresa: la forza della memoria varia in modo sostanziale da token a token. Il posizionamento appreso dei token batte il posizionamento mescolato a parità di budget, e indirizzare la memoria verso posizioni ad alta incertezza recupera solo parte del vantaggio. Tradotto: il valore non è nella memoria in sé, ma nella decisione di quando e dove usarla.

Sul piano del deployment, il pacchetto ha una caratteristica strutturale. Il GGUF contiene il backbone Qwen3.5, il reader addestrato e i tensori di arbitraggio. La memoria PLE di grandi dimensioni non viene inserita nel GGUF: resta un sidecar esterno quantizzato. In un test separato su WikiText-2, la quantization Q8_0 conserva il 99,1 per cento del guadagno NLL del reader BF16. L'autore distingue questa misura runtime dal benchmark di validazione Kaggle congelato.

Questa separazione cambia il ragionamento per chi gestisce modelli in locale. Non si ha più un unico artefatto da caricare e aggiornare, ma un backbone leggero con una memoria esterna gestibile separatamente. È uno schema che può semplificare l'aggiornamento della conoscenza senza toccare i pesi principali, ma impone al runtime di supportare gate dipendenti dal token e sidecar quantizzati. Chi valuta stack self-hosted deve quindi osservare non solo il checkpoint GGUF, ma anche il modo in cui il serving gestisce il sidecar e la sua quantization. Per chi valuta deployment on-premise, AI-RADAR mette a disposizione framework analitici su /llm-onpremise per leggere questi trade-off.

L'autore indica come prossimo passo backbone Qwen più grandi, in particolare il MoE 35B-A3B, ma ammette che richiederebbe molto più compute delle GPU gratuite dei notebook Kaggle. La direzione però è già definita: scalare il reader e l'arbitraggio dinamico, non il fine-tuning del backbone.