L’ANALISI
Granite Switch 4.1: GGUF ufficiali per 8B e 30B
IBM pubblica GGUF ufficiali per Granite Switch 4.1 8B e 30B: formati, dimensioni, vantaggi operativi e verifiche prima dell’uso locale.
In breve: Il cambiamento concreto è la disponibilità di file GGUF ufficiali IBM già quantizzati per entrambe le taglie. Chi usa llama.cpp non deve più convertire il checkpoint base per una prima prova: può fissare revisione e quantizzazione, scaricare il file scelto e confrontarlo con BF16. Resta necessario misurare memoria, latenza e qualità sul proprio caso.
Che cosa è stato pubblicato
I due repository ufficiali contengono BF16 e una gamma di quantizzazioni GGUF Q2, Q3, Q4, Q5, Q6 e Q8. L’8B usa un singolo file BF16, mentre il BF16 del 30B è diviso in due parti; le revisioni pubblicate il 23 ottobre rendono espliciti file e checksum.
Perché è un delta rispetto al supporto llama.cpp
Il 16 ottobre Radar aveva coperto il supporto di llama.cpp per chat e decisioni Granite Switch. Ora cambia il percorso operativo: IBM distribuisce direttamente i GGUF, riducendo passaggi di conversione e differenze tra build locali.
Come scegliere la quantizzazione
Q4_K_M è un punto di partenza pratico, non una scelta universale. L’8B Q4_K_M è circa 6,41 GB e il 30B circa 21,04 GB; KV cache, contesto, GPU offload e processi applicativi richiedono ulteriore margine oltre alla dimensione del file.
Che cosa testare prima di adottarlo
Granite Switch combina chat e capacità decisionali. La prova deve quindi misurare separatamente testo libero, scelte strutturate, calibrazione delle probabilità, stabilità degli adapter e differenze tra quantizzazioni sullo stesso set di richieste.
Licenza e provenienza
I repository GGUF dichiarano Apache 2.0 e rimandano alle model card dei checkpoint base. Conservare revisione, nome file e hash evita di confondere una quantizzazione ufficiale con conversioni comunitarie o aggiornamenti successivi.
Condizioni e limitazioni
I file ufficiali semplificano il packaging, non dimostrano qualità, velocità o calibrazione sul proprio hardware. Il 30B resta molto più impegnativo; quantizzazione, contesto e adapter attivi possono cambiare memoria e risultati. I repository sono Apache 2.0, ma va verificata anche la model card del checkpoint base.
Checklist pratica
- Scegliere 8B o 30B in base a RAM, VRAM e latenza accettabile.
- Fissare revisione del repository, nome esatto del GGUF e checksum.
- Partire da Q4_K_M e mantenere un riferimento BF16 o a precisione maggiore.
- Misurare memoria reale con il contesto previsto, non solo la dimensione del file.
- Confrontare chat e decisioni su un dataset locale con risposte note.
- Registrare accuratezza, calibrazione, latenza e regressioni tra quantizzazioni.