La pull request #27000 aperta nel repository ggml-org/llama.cpp da AlexGabbia introduce il supporto a Maple 20B-A1B, un LLM a mistura di esperti (MoE) con pesi ternari pensato per l'esecuzione su CPU. La discussione su Reddit la pone nei termini giusti: è un'opzione concreta per chi ha poca VRAM e vuole restare in self-hosted?

I modelli ternari vincolano i pesi a un insieme ristretto di valori, tipicamente -1, 0 e 1. Questo riduce l'ingombro in memoria rispetto ai formati a 16 o 8 bit, prima ancora di applicare la quantization. In un'architettura MoE, solo una parte degli esperti viene attivata per ciascun token, quindi il costo computazionale per token resta contenuto rispetto al totale dei parametri. Maple 20B-A1B combina queste due leve: un totale dichiarato di 20 miliardi di parametri e una sigla che suggerisce un'attivazione ridotta, coerente con l'obiettivo di abbassare la soglia hardware.

Il segnale strutturale non è da poco. Finora i modelli dense ad alta VRAM hanno spinto i team verso GPU costose o API cloud; un'architettura progettata per CPU a bassa VRAM riduce la barriera per pipeline self-hosted e per ambienti con memoria limitata, dai server ricondizionati all'edge. Non significa che la latenza o la qualità siano risolte, ma sposta il TCO: il costo di adozione smette di dipendere da una singola componente hardware.

Il secondo effetto riguarda llama.cpp, il framework di inference locale più diffuso. Ogni nuova architettura integrata ne rafforza il ruolo di framework di compatibilità per modelli non mainstream. Chi sperimenta formati ternari può testare su CPU, misurare i token al secondo e costruire deployment in container o bare metal senza attendere il supporto dei grandi vendor. In questo scenario, Maple 20B-A1B diventa un banco di prova per capire se il ternario è una direzione praticabile per la sovranità dei dati o una nicchia da laboratorio.

A guadagnare sono i team con budget ridotti e requisiti di residenza dati, oltre ai progetti open source che vivono di hardware riusato. A perdere, almeno in parte, sono i fornitori che basano il valore sulla VRAM elevata. Ma il ternario non è gratis: la compressione spinta può incidere sulla qualità delle risposte e sulla stabilità del fine-tuning, e il supporto CPU non garantisce throughput elevati in produzione. Per chi confronta questa strada con il cloud, restano da pesare i trade-off tra TCO, latenza e controllo; AI-RADAR dedica a questi scenari analisi e framework su /llm-onpremise.

La PR è ancora in valutazione, ma il solo fatto che un runtime come llama.cpp consideri l'integrazione dice molto sulla direzione del deployment locale. La risposta tecnica arriverà dai test su CPU, non dalle etichette.