L’ANALISI
llama.cpp b11700: Granite Switch ora gestisce chat e decisioni locali
Analisi pratica di llama.cpp b11700: supporto Granite Switch 4.1 8B, endpoint chat e decisioni, conversione GGUF, Q4_K_M, limiti e checklist locale.
In breve: Il delta concreto è che Granite Switch 4.1 8B può essere convertito in GGUF e servito da llama.cpp come chat model e decision model nello stesso processo. La nuova route `/v1/systemone` restituisce scelte, probabilità e confidenza, mentre la chat resta disponibile sull’endpoint OpenAI-compatible. È un percorso locale più semplice, ma non dimostra da solo che le probabilità siano calibrate sul proprio dominio.
Che cosa aggiunge b11700
La release integra il pull request 30676: conversione del checkpoint Granite Switch, riconoscimento dell’adapter `decision` e supporto nel server. La build pubblica pacchetti pronti per CPU, CUDA, ROCm, Vulkan, OpenVINO, SYCL, Snapdragon e piattaforme desktop o mobili.
Due capacità nello stesso server
Il checkpoint può rispondere come normale modello chat attraverso `/v1/chat/completions` e produrre decisioni strutturate attraverso `/v1/systemone`. Per le domande a scelta il server restituisce la distribuzione di probabilità sulle opzioni e un valore di confidenza; sono supportate anche risposte numeriche tra zero e uno.
Conversione e quantizzazione
Il percorso documentato usa `convert_hf_to_gguf.py` e, facoltativamente, `llama-quantize` per creare una variante Q4_K_M. Il contributore dichiara test sia sul GGUF BF16 sia sul quantizzato Q4_K_M. Questo rende possibile una prova su hardware più accessibile, ma non stabilisce l’impatto della quantizzazione su ranking e calibrazione.
Che cosa contiene Granite Switch
La model card del checkpoint 8B indica una base Granite 4.1 con contesto 128K, un adapter decisionale aLoRA, un adapter Guardian Core e un encoder speech-to-text. Il supporto b11700 verificato riguarda chat e decisioni; non va esteso automaticamente alle altre capacità senza test specifici.
Dove serve davvero
Il formato decisionale è adatto a routing, classificazione e scelte tra opzioni note, dove è utile ottenere probabilità esplicite invece di testo libero. In produzione servono dataset locali, soglie di astensione, confronto con regole esistenti e logging delle decisioni, soprattutto quando l’output influenza accessi, pagamenti o persone.
Condizioni e limitazioni
Il test pubblicato nel pull request è del contributore e non una verifica indipendente. Il supporto riguarda il checkpoint Granite Switch 4.1 8B con adapter `decision`; accuratezza, calibrazione delle probabilità, memoria e velocità vanno misurate sui propri casi. La componente speech documentata dal modello non è il delta verificato di questa build llama.cpp.
Checklist pratica
- Fissare llama.cpp b11700 e il checkpoint esatto `ibm-granite/granite-switch-4.1-8b`.
- Convertire prima in BF16 GGUF e creare una copia Q4_K_M separata, conservando hash e comandi.
- Avviare `llama-server` in rete isolata e verificare separatamente chat e `/v1/systemone`.
- Preparare casi con etichette note, ambiguità e opzione di astensione del proprio dominio.
- Confrontare accuratezza, ranking, probabilità e latenza tra BF16 e Q4_K_M.
- Non usare la confidenza come garanzia: definire soglie e revisione umana per decisioni ad alto impatto.