L’ANALISI
Granite Switch 4.1 8B: 12 adapter in un solo checkpoint
Analisi pratica di Granite Switch 4.1 8B Preview: checkpoint aggiornato, 12 adapter attivabili, RAG, sicurezza, vLLM, firme e limiti.
In breve: Il delta operativo è un checkpoint aggiornato che concentra dodici funzioni specializzate in un solo Granite 4.1 8B: riscrittura e chiarimento delle query, answerability, citazioni, rilevamento e correzione della factuality, guardrail, incertezza e verifica dei requisiti. Riduce la necessità di distribuire una copia completa per ogni funzione, ma resta una preview da misurare su accuratezza, memoria e latenza reali.
Che cosa è cambiato il 15 ottobre
La revisione 8a22410 sostituisce i quattro shard Safetensors e aggiorna configurazione, tokenizer, chat template e metadati di composizione. Le sorgenti delle tre librerie RAG, Guardian e Core puntano a nuove revisioni e il checkpoint composto conta 9.568.116.736 parametri.
Come funziona la selezione degli adapter
Ogni funzione ha un token di controllo registrato nel tokenizer. Il template di chat inserisce il token corrispondente e Granite Switch applica il relativo LoRA o activated LoRA nei layer del modello, mantenendo un unico endpoint e un contratto di output specifico per il compito.
Le dodici funzioni disponibili
La raccolta comprende cinque funzioni RAG, quattro funzioni Guardian e tre funzioni Core: citazioni, riscrittura e chiarimento delle query, answerability, rilevamento delle allucinazioni, factuality, correzione, policy, sicurezza generale, incertezza, controllo dei requisiti e attribuzione al contesto.
Distribuzione e confine operativo
Il checkpoint può essere caricato con Transformers dopo la registrazione dell’architettura granite-switch oppure servito con vLLM e API compatibile OpenAI. Il vantaggio è la concentrazione delle funzioni; il confine resta self-hosted soltanto se pesi, runtime, documenti e richieste rimangono nell’infrastruttura controllata.
Che cosa misurare davvero
Il confronto utile non è solo contro il modello base. Va misurato ogni adapter contro la pipeline attuale, includendo falsi positivi, copertura delle citazioni, qualità della riscrittura, memoria GPU, throughput e costo del routing. La firma aiuta a verificare la provenienza degli artefatti, non garantisce l’adeguatezza del comportamento.
Condizioni e limitazioni
La model card mantiene la data originaria del 5 maggio 2026: la novità del 15 ottobre è la revisione dei pesi e delle tre librerie di adapter, non il primo annuncio del progetto. È ancora una preview, i risultati sono del progetto e ogni adapter va validato sul proprio dominio; il checkpoint composto sale a circa 9,57 miliardi di parametri.
Checklist pratica
- Fissare la revisione 8a22410 e verificare la firma prima del test.
- Scegliere due adapter con output facilmente verificabile, per esempio answerability e requirement-check.
- Preparare un set locale con casi positivi, negativi e ambigui del proprio dominio.
- Servire il checkpoint in una rete isolata con vLLM o Transformers e registrare VRAM e latenza.
- Confrontare ogni adapter con la pipeline esistente usando le stesse richieste.
- Controllare manualmente citazioni, factuality e casi di mancata astensione.
- Promuovere un adapter alla volta e mantenere un percorso di rollback al modello base.