L’ANALISI
K2 Horizon SFT2 su main: cosa cambia per test e rollback
I repository 3.7B e 32B puntano ora a un checkpoint SFT2 da 2.500 step. Il cambiamento è operativo soprattutto per chi scaricava main senza fissare una revisione.
In breve: Il 14 settembre IFM ha spostato su main il checkpoint SFT2 da 2.500 step per K2 Horizon 3.7B e 32B. I download non fissati cambiano contenuto; per una prova riproducibile bisogna registrare l’hash e confrontare il nuovo checkpoint con quello usato in precedenza.
Il delta verificato nei repository
Il commit 394b703c del 3.7B e il commit e0fe3043 del 32B uniscono su main il tag sft_2_2500. Non è un semplice aggiornamento della scheda: cambia la revisione risolta dai client che seguono main.
Perché main può cambiare un test
from_pretrained, vLLM e SGLang risolvono normalmente il branch indicato dal repository. Senza un parametro revision, due esecuzioni in date diverse possono usare checkpoint differenti pur conservando lo stesso identificatore di modello.
Cosa resta invariato
Le taglie, il formato BF16, il contesto dichiarato e le ricette generali di serving restano quelli della famiglia già pubblicata. Il 32B continua a essere indicato come Stage 1; il merge SFT2 non equivale al checkpoint finale promesso.
Condizioni e limitazioni
Il repository prova il cambio di checkpoint ma non fornisce nel commit una misura indipendente del guadagno. I benchmark restano dichiarazioni IFM e il comportamento su italiano, tool calling e hardware consumer deve essere misurato sul proprio harness.
Checklist pratica
- Registrare l’hash del checkpoint attualmente in produzione.
- Scaricare SFT2 in un ambiente separato e verificarne gli hash.
- Fissare revision nei comandi Transformers, vLLM o SGLang.
- Ripetere lo stesso set di prompt italiani, codice e tool calling.
- Misurare qualità, errori, latenza, throughput e memoria.
- Promuovere il nuovo checkpoint solo con una soglia definita e rollback pronto.