Llama 4 Scout: il nuovo MoE di Meta e l'inferenza locale
Meta ha presentato Llama 4 con due modelli principali: Scout e Maverick. Scout è un Mixture-of-Experts multimodale con 17 miliardi di parametri attivi per token, 109 miliardi di parametri totali e 16 esperti. Meta dichiara una finestra di contesto fino a dieci milioni di token in configurazioni specifiche.
La domanda utile non è soltanto se il modello sia grande. È quanto sia accessibile nell’inferenza locale e quali compromessi richieda davvero.
Cos’è Llama 4 Scout?
Ecco le caratteristiche dichiarate pubblicamente:
- Architettura: Mixture-of-Experts, 16 esperti, 17B attivi per token e 109B totali.
- Contesto: fino a 10 milioni di token nelle condizioni indicate da Meta.
- Modalità: testo e visione.
- Licenza: Llama 4 Community License, con termini da leggere prima di un uso commerciale.
- Valutazioni: Meta pubblica confronti con altri modelli; sono un punto di partenza, non un verdetto indipendente.
Il numero di parametri attivi è essenziale per capire il lavoro svolto a ogni token. Il totale rappresenta invece la capacità complessiva di tutti gli esperti. Un MoE prova a combinare le due cose: grande capacità potenziale e costo per token inferiore a quello di un modello denso della stessa dimensione totale.
La situazione delle quantizzazioni
L’accesso locale dipende da formati, quantizzazione e supporto del runtime. Le quantizzazioni disponibili possono ridurre la memoria necessaria, ma ogni scelta modifica qualità, velocità e compatibilità. Non esiste una dimensione che garantisca da sola che il modello sia utilizzabile su ogni macchina.
Il supporto multimodale è un altro caso separato. Avere una capacità visiva nell’architettura non implica che ogni formato o runtime locale la esponga già in modo completo. Prima di scegliere un file, bisogna verificare documentazione del modello, runtime e strumenti di conversione.
Supporto nei runtime
Un’architettura nuova richiede che il runtime la conosca: struttura dei pesi, router MoE, template conversazionale e componenti multimodali non si caricano per intuizione. Il supporto evolve rapidamente dopo un rilascio, quindi la fonte affidabile è la documentazione o il registro delle modifiche del runtime in uso, non una frase copiata da un post datato.
Questa è una delle ragioni per cui “può essere eseguito localmente” è una frase incompleta. Bisogna specificare la versione del software, il formato dei pesi, la quantizzazione, l’hardware e il tipo di input. Senza questi dettagli è uno slogan, non una verifica.
Capacità e limiti pratici
Scout rende interessante l’inferenza locale per la combinazione tra capacità MoE e disponibilità dei pesi. Ma i requisiti pratici non si deducono dalla sola cifra di 17B parametri attivi. La memoria per pesi, cache del contesto, attivazioni e componenti visive può dominare l’esperienza reale, soprattutto con contesti lunghi.
Anche la finestra di contesto massima va trattata con disciplina. Una finestra supportata dall’architettura non equivale a un contesto utile, veloce o economico in ogni implementazione. Le prove che contano misurano qualità di recupero, latenza, memoria e affidabilità degli strumenti sul carico di lavoro effettivo.
Il quadro più grande
Llama 4 Scout è significativo perché i modelli MoE stanno rendendo normale una domanda che qualche anno fa sembrava assurda: quanta capacità totale si può rendere disponibile senza pagare il costo di un modello denso a ogni token?
Questo non significa che i modelli densi siano finiti, né che un MoE elimini i vincoli dell’hardware. Significa che il rapporto tra capacità, memoria e costo è diventato una scelta di architettura, non solo una gara a chi ha più parametri.
Prima di adottare Scout, leggere la licenza, confermare il supporto nel runtime e misurare il proprio flusso di lavoro. I numeri dichiarati possono motivare un test; solo un test riproducibile può motivare una decisione.