L’ANALISI
K2-Type-0.9B: come provare il decision model compatto di IFM
Pesi BF16, server SystemOne, benchmark dichiarati e limiti di K2-Type-0.9B, con una checklist per valutarlo su routing e classificazione.
In breve: K2-Type-0.9B prende uno stato in testo o JSON e più domande tipizzate, poi restituisce probabilità sulle opzioni senza generare testo. I pesi BF16 e il server sono scaricabili, ma serve una GPU CUDA e le prestazioni pubblicate derivano da una H200. È interessante per routing e classificazione controllata, non come sostituto di policy o verifiche umane.
Il delta verificato
Il repository rende disponibili i pesi BF16, la configurazione, il pointer head e un server HTTP minimo. La revisione osservata il 2 ottobre include anche i template e la scheda operativa: il modello è quindi scaricabile e avviabile, non soltanto annunciato.
Come funziona una decisione tipizzata
Lo stato viene condiviso tra più domande, mentre una maschera impedisce alle domande di influenzarsi tra loro. Una testa dedicata assegna probabilità alle opzioni ammesse per domande sì/no, scelte fino a 255 opzioni e scale ordinate, senza produrre testo libero.
Compatibilità e avvio
Il server espone /v1/systemone e segue il formato di Jev e Kev, così i client compatibili possono essere riusati. Il quickstart richiede huggingface_hub, le dipendenze del repository, Transformers almeno 5.17, Torch 2.8 e una GPU CUDA.
Che cosa dicono i benchmark
La model card riporta 176 risposte corrette su 231 nel set pubblico JevBench, ECE 0,065 e latenza p50 di 27 ms su H200. Sono misure del progetto, non una replica indipendente; Jev 1.13.0 resta più accurato sul confronto pubblico indicato dalla stessa scheda.
Dove può essere utile
Il formato chiuso è adatto a routing di ticket, classificazione, priorità e controlli con opzioni note. Riduce parsing e libertà dell’output, ma non risolve automaticamente errori di distribuzione, opzioni incomplete o decisioni ad alto impatto.
Condizioni e limiti
Il modello non esegue ragionamento generativo, soffre su calcoli multi-step, differenze tra date e documenti oltre 8.192 token. Training code e dati non sono rilasciati e la calibrazione può cambiare fuori dai set usati dal progetto.
Checklist per una prova controllata
- Fissare la revisione 61584a8f0e9bd1c89fb7357786508c7135f56e18.
- Verificare GPU, memoria e versioni di Transformers e Torch.
- Avviare il server solo in una rete di test e controllare /health.
- Preparare un set italiano separato da tuning e benchmark pubblici.
- Confrontare accuratezza, calibrazione, latenza e memoria con una regola deterministica.
- Aggiungere sempre un’opzione nessuna delle precedenti quando serve.
- Definire una fascia di incertezza con revisione umana.
- Bloccare azioni sensibili dietro policy esterne al modello.
- Registrare versione, input minimizzato, probabilità e decisione finale.