Vai al contenuto

K2 Horizon 32B e 3.7B: pesi, requisiti, limiti e checklist di prova.

L’ANALISI

K2 Horizon 32B e 3.7B: cosa è davvero scaricabile e come testarli

Due nuovi pacchetti completano la parte densa della famiglia K2 Horizon: un 32B ancora Stage 1 e un 3.7B più accessibile. I file sono disponibili, ma il costo operativo e le prove restano separati dalle promesse.

2 min di letturaFatti, limiti e fonti primarie
Grafico ufficiale dei benchmark di K2 Horizon 3.7B
Benchmark ufficiali IFM del 3.7B: indicazioni del produttore, non una validazione indipendente.

In breve: il 32B Stage 1 e il 3.7B si possono ora scaricare con pesi, configurazioni, tokenizer e codice del modello. Il 32B serve a studiare checkpoint e serving multi-GPU; il 3.7B è il candidato pratico per test locali controllati.

Che cosa è cambiato

Il delta è nei repository: 64 shard safetensors per il 32B e 36 shard per il 3.7B, insieme a indici, configurazioni e codice di esecuzione. Il 32B pubblica anche rami intermedi lungo pretraining, midtraining e SFT.

32B: Stage 1, non modello finale

La scheda definisce il checkpoint principale come Stage 1 e rinvia il finale. Dichiara 512K di contesto, ma la ricetta validata usa tensor parallel su due H200: il download non implica una prova economica su hardware consumer.

3.7B: più vicino a un test locale

Il 3.7B usa una ricetta a singola GPU e dichiara 512K. È più adatto a misure ripetibili di latenza, memoria e tool calling, ma la scheda raccomanda fino a 32.768 token di output, che possono alzare molto tempi e memoria KV.

Codice remoto e confine di fiducia

Entrambi richiedono trust_remote_code e parser K2 Horizon. Prima di collegare strumenti reali bisogna fissare lo SHA, revisionare il Python remoto e isolare rete, filesystem e segreti.

Condizioni e limitazioni

I benchmark sono pubblicati da IFM e i protocolli dei modelli di confronto possono differire. Il report tecnico e il repository di training del 32B risultano ancora in preparazione; il contesto massimo dichiarato non prova qualità al limite.

Checklist pratica

  • Fissare revisione e SHA prima del download.
  • Revisionare modeling_k2_horizon.py prima di trust_remote_code.
  • Misurare BF16 con prompt brevi prima del contesto lungo.
  • Registrare VRAM, latenza, token al secondo e lunghezza del reasoning.
  • Testare tool calling con timeout, argomenti errati e azioni negate.
  • Conservare prompt, backend e risultati per confronti ripetibili.

Fonti primarie

Radar AI · a cura di Francesco Gruner

Il sito, in una chat.

Servizi, guide e idee da approfondire

Sono l’assistente AI di questo sito. Ti aiuto a orientarti tra il lavoro di Francesco, il blog, Radar AI e i video, con i link alle fonti.

Risposte AI da verificare nelle fonti. 16 messaggi al giorno per rete.