A quasi quattro anni dall’arrivo di ChatGPT 3.5 il dibattito su AI ruota ancora attorno al concetto di modello e al numero dei suoi parametri. Ma se i primi modelli erano densi e bastava dire che GPT 3.5 fosse un modello da 175B per caratterizzare molti dei suoi comportamenti e il costo per la sua esecuzione, oggi è necessario possedere una ragionevole comprensione del funzionamento interno di questi modelli per poter capire le opzioni per poterli eseguire localmente, specialmente con l’arrivo di modelli con prestazioni paragonabili a quelli di frontiera chiusi ma i cui pesi sono disponibili e scaricabili, come ad esempio Kimi K3 e i suoi 2.8T parametri (2.800 miliardi di parametri).Già pochi mesi fa Google aveva cominciato a far trasparire la complessità dei modelli introducendo nella classe di modelli Gemma 4 il modello e4B (effective 4B) che non pone più l’accento sul numero complessivo di parametri del modello (che si stima essere un 20B) bensì sul numero dei parametri effettivamente attivati per ciascuna generazione di token. Come sempre accade al complicarsi dei sistemi, segue una ricerca per ottimizzarne l’esecuzione sfruttando caratteristiche di una classe di modelli e ignorando gli altri.Non a caso il recente lavoro nato da ricercatori americani e che ha prodotto il framework FreeToken si concentra solo su modelli basati sull’architettura Mixture of Experts (MoE) e rinuncia ad ottimizzare modelli basati su altre architetture. Cerchiamo di capire quali ambienti di esecuzione locale capaci di caricare grandi modelli su sistemi piccoli si stanno affermando e quali sono realmente impiegabili in contesti reali (il fatto che AirLLM riesca ad eseguire Kimi K3 con soli 48GB di Video RAM non rende i 292 secondi per generare un singolo token realmente utilizzabile il modello).Indice degli argomenti