La sigla JetBrains/Mellum2.1-12B-A2.5B-Thinking-GGUF sembra un codice di magazzino, ma in realtà concentra tre scelte progettuali precise. È un modello MoE (mixture of experts) di dimensioni compatte, in cui la notazione A2.5B indica circa 2,5 miliardi di parametri attivi su un totale di 12 miliardi. La variante Thinking aggiunge un'impostazione orientata al ragionamento, mentre il suffisso GGUF lo rende subito utilizzabile nei motori di inference locali basati su llama.cpp e nei flussi self-hosted più diffusi.

Per chi valuta deployment on-premise, questa combinazione non è un dettaglio tecnico. L'architettura MoE riduce il costo computazionale per token: il modello attiva solo una parte degli esperti, abbassando le operazioni necessarie rispetto a un modello denso di pari capacità complessiva. Il formato GGUF, dal canto suo, è il contenitore che ha accompagnato la diffusione della quantization per CPU e GPU consumer. Insieme, MoE e GGUF spostano una parte del lavoro lontano dalle GPU costose e lo avvicinano a hardware più semplice, server interni e memoria di sistema.

Perché il parametro attivo cambia i conti del TCO

Il punto meno ovvio è che la metrica rilevante non è più soltanto il numero totale di parametri. Se ogni token attiva una frazione ridotta della rete, il costo per richiesta dipende molto dal percorso computazionale effettivo, non dalla grandezza del file. Questo cambia il modo in cui si valuta il TCO di una pipeline self-hosted: meno energia per l'inference continua, meno VRAM necessaria per ottenere una latenza accettabile e più spazio per gestire i dati dentro il perimetro aziendale.

Va però evitata una semplificazione: un MoE non elimina il vincolo di memoria. Gli esperti inattivi, se non vengono scaricati o distribuiti su più nodi, devono comunque trovare spazio in RAM o VRAM. Il risparmio principale è sul calcolo per token, non necessariamente sull'impronta di memoria totale. Ma per carichi di automazione quotidiana — assistenti interni, estrazione di informazioni, prima analisi di documenti — questa distinzione basta spesso a rendere praticabile l'LLM locale.

Chi guadagna da questa traiettoria sono i team che operano in ambienti air-gapped, le organizzazioni con vincoli di compliance e gli integratori che vogliono costruire servizi interni senza dipendere da API cloud. Chi perde quote di attenzione sono i fornitori che hanno legato il proprio vantaggio alla sola scala: i data center centralizzati e i modelli densi enormi restano necessari per ragionamenti complessi, ma non sono più l'unica risposta per l'automazione distribuita. La presenza di collezioni come Mellum2.1 in formato GGUF segnala che il mercato dell'inference locale sta maturando, non aspetta più soltanto i modelli di punta.