La storia, in ordine

Le tappe

1. Il punto di partenza

   Un PC con un i5-4570, 7,9 GiB di RAM, nessuna scheda video e nessun budget per affittarne una. Volevo un assistente che funzionasse davvero lì. Da subito ho fissato quattro regole: compatibile con i modelli del mondo, adattabile a qualsiasi PC, tutto automatico dalla finestra, e solo affermazioni verificate.

2. NEXUS 2.0

   Il programma Windows che trova i modelli, valuta se il PC li regge e li avvia. Ha anche un modulo di ricerca sul web per le domande che richiedono dati aggiornati. Ho dovuto correggere un errore di decompressione delle risposte (deflate) passando alla compressione GZip.

3. VELA e MOSAICO: 80 miliardi di parametri in 8 GB

   Un modello da 48 GB eseguito su un computer con 8 GB di RAM, a circa 1,39 token al secondo in italiano. Ho raccolto misure, grafici e istruzioni per ripeterle in un dossier tecnico. I limiti li ho scritti nel dossier stesso: un solo PC, prompt brevi, 32 token per prova.

4. VELA-TOK

   Il tokenizzatore in C, senza librerie esterne. Trasforma il testo in numeri per i miei motori.

5. VELA-G: un motore per i modelli di tutti

   MOSAICO funziona solo con il mio formato. Per essere compatibile con il mondo mi serviva un motore per i GGUF. L'ho confrontato con llama.cpp sugli stessi file: su 6 prove (3 modelli, 2 prompt) il testo è identico in 5. Nella sesta ci sono due scelte diverse su 40, con logit a distanza di circa 0,05: due candidati quasi alla pari.

6. Il determinismo (27 ottobre 2026)

   Ho fissato l'ordine di ogni somma e riscritto le funzioni matematiche in modo che il risultato non dipenda da compilatore, sistema operativo, istruzioni AVX2 o numero di thread. Quattro modelli piccoli, quattro modi di calcolo: 16 prove su 16 identiche, su Windows contro un riferimento calcolato su Linux. Le ho ripetute anche dopo una nuova compilazione.

7. La decodifica speculativa: un risultato che ho tenuto anche se negativo

   Un modello bozza piccolo propone alcuni token, quello grande li verifica in blocco. In prove controllate guadagna fino al 28% sul codice, con testo identico. Nell'uso reale in NEXUS, con temperatura 0,7 e prompt con pagine web, non c'è stato un vantaggio netto: da +2% a −13%. Quindi la funzione c'è, ma è spenta per impostazione predefinita.

8. Più veloce, con gli stessi numeri (28 ottobre)

   La lettura del prompt era il punto debole: dal 23-45% della velocità di llama.cpp sono arrivato al 65-85%. Ho tolto il lavoro ripetuto (seno e coseno di RoPE, quantizzazione delle stesse attivazioni), ho messo al lavoro tutti i core nelle parti che ne usavano uno solo e ho riscritto il kernel dei prodotti. Dopo ogni passo le 16 prove di determinismo sono rimaste identiche.

9. Cosa c'era già, e il pacchetto per ripetere le prove

   Ho cercato in letteratura chi avesse già fatto qualcosa di simile (vedi lo stato dell'arte) e ho preparato uno zip per far ripetere le prove a una persona esterna.

10. BUD

    Ho cominciato a ragionare su un modello nuovo, con una memoria compressa. Per ora è carta: nessun codice, nessuna misura.

Errori trovati e corretti

• La bozza si spegneva quando serviva. Sul modello da 4 miliardi, in codice, la stima del costo era sbagliata perché misuravo la velocità di partenza su soli 2 token. Ora la misuro su 4 token, scarto il primo giro e limito i valori anomali.
• NEXUS rifiutava la bozza per mancanza di memoria. Contavo la cache del modello piccolo come se avesse un contesto di 4096 token. Ora ne conto 1024 e il margine è 0,2 GB.
• Prompt lunghi più lenti con la bozza. Leggere un prompt lungo con due modelli costava circa 10 secondi. Ora la bozza parte solo se la risposta è lunga (almeno 64 token) e la lettura aggiuntiva è al massimo 400 token.
• Misurare sulla macchina giusta. Sulla CPU da cui lavoro nessuna variante del kernel batteva quella che avevo già. Sul mio i5-4570 la migliore era il 23% più veloce. Per questo i kernel li confronto sul mio PC, con un programma di prova che lancio io.
• Una tabella letta male. Nel commentare una prova avevo scambiato prosa e codice. L'ho corretto confrontando con i dati grezzi, prima di scrivere conclusioni.