AIREITERUna famiglia di sei modelli, da 0.9B a 375B, può sembrare una scaletta completa per ogni tipo di deployment. I conti, però, sono meno lineari. La licenza Apache 2.0 di K2 Horizon elimina il costo della licenza del modello; MoVA riduce il calcolo attivo; nessuna delle due cose azzera i costi di storage, KV cache, runtime o hardware.
Cosa comprende il rilascio Apache 2.0 dei sei modelli
IFM ha annunciato K2 Horizon il 3 settembre 2026 come una famiglia coordinata di sei modelli: 375B-A23B, 36B-A4B, 32B, 7B, 3.7B e 0.9B. L'annuncio specifica che modelli e codice sono rilasciati con licenza Apache 2.0, mentre i dataset adottano le rispettive licenze applicabili (annuncio IFM).
Una famiglia di sei modelli, ma non tutti allo stesso stadio di rilascio
I sei membri della famiglia sono:
| Modello | Architettura | Posizionamento ufficiale | Contesto indicato nei materiali ufficiali |
|---|---|---|---|
| K2 Horizon 0.9B | Dense | Orologi, occhiali e dispositivi edge con risorse limitate | 128K / 131,072 token |
| K2 Horizon 3.7B | Dense | Telefoni, fine-tuning e carichi locali leggeri | 512K / 524,288 token |
| K2 Horizon 7B | Dense | Telefoni, assistenti locali, coding e agenti | 512K / 524,288 token |
| K2 Horizon 32B | Dense | Workstation e server on-premises | 512K / 524,288 token |
| K2 Horizon MoVA 36B-A4B | MoE sparsa + MoVA | Serving locale ed efficiente | 512K / 524,288 token |
| K2 Horizon 375B-A23B | MoE sparsa | Deployment enterprise e multi-acceleratore | 512K / 524,288 token |
La famiglia condivide architettura e strumenti di deployment, con l'eccezione dello 0.9B, che utilizza un vocabolario più piccolo. Questa base comune punta a rendere più semplice migrare o instradare le richieste tra taglie diverse (comunicato stampa IFM).
C'è però un'importante distinzione sul grado di maturità: la card ufficiale di K2-Horizon-32B identifica il checkpoint disponibile come Stage1 e indica che il checkpoint finale deve ancora essere rilasciato. Le card di MoVA 36B-A4B e 375B-A23B, al contrario, descrivono i rispettivi checkpoint finali come già rilasciati. Dire che sono stati annunciati sei modelli è corretto; dire che esistono sei checkpoint finali equivalenti per la produzione non lo è (model card 32B, model card 375B).
Cosa offre davvero Apache 2.0 a chi fa self-hosting
Apache 2.0 consente di modificare, ridistribuire e integrare commercialmente il modello e il suo codice senza pagare una tariffa per token. IFM precisa che i dataset seguono condizioni proprie, come ODC-BY, e che le fonti soggette a restrizioni non possono essere ridistribuite direttamente (annuncio IFM).
Apache 2.0 elimina il costo della licenza, non quello operativo. Noleggio o ammortamento delle GPU, storage dei modelli, capacità della KV cache, engineering del runtime, monitoraggio e revisione della sicurezza restano voci di spesa; anche la ricetta di serving del 36B e la model card del 375B mostrano trust_remote_code=True nei rispettivi esempi.
Le sei taglie lette prima di tutto in termini di memoria
Le etichette basate sui parametri aiutano a confrontare la capacità dei modelli, ma per il self-hosting il primo vincolo è lo spazio richiesto dai pesi grezzi. Le stime seguenti assumono due byte per parametro in BF16 e mezzo byte per parametro in una rappresentazione a 4 bit idealizzata; non includono metadati, buffer del runtime, KV cache, file del tokenizer né memoria del sistema operativo.
| Modello | Parametri totali usati per la pianificazione | Parametri attivi per token | Soglia minima BF16 grezza | Soglia minima idealizzata a 4 bit | Fascia pratica |
|---|---|---|---|---|---|
| K2 Horizon 0.9B | 0.9B | 0.9B | ~1.8 GB | ~0.45 GB | Esperimenti edge ed embedded |
| K2 Horizon 3.7B | 3.7B | 3.7B | ~7.4 GB | ~1.85 GB | Attività locali o mobile compatte |
| K2 Horizon 7B | classe 7B | classe 7B | ~14 GB* | ~3.5 GB* | Primo test locale serio |
| K2 Horizon 32B | 32B | 32B | ~64 GB | ~16 GB | Workstation o server |
| K2 Horizon MoVA 36B-A4B | 36B | ~4B | ~72 GB | ~18 GB | Workstation quantizzata o serving multi-GPU |
| K2 Horizon 375B-A23B | 375B | ~23B | ~750 GB | ~187.5 GB | Scala enterprise o cluster |
\*La model card del 7B definisce il modello “7B-core”, mentre i metadati di Hugging Face mostrano 9B parametri. Per pianificare la capacità occorre usare i file effettivi del repository, non solo l'etichetta della famiglia (model card 7B).
I repository concreti spiegano perché si tratta di soglie minime e non di promesse. Il GGUF BF16 dello 0.9B è indicato a 2.16 GB, quello BF16 del 3.7B a 10.1 GB, il GGUF BF16 Stage1 del 32B a 69.6 GB e il GGUF BF16 del MoVA 36B a 74.9 GB (GGUF 0.9B, GGUF 3.7B, GGUF 32B, GGUF 36B).
Le fasce edge: 0.9B, 3.7B e 7B
0.9B e 3.7B riducono al minimo lo storage e sono adatti a carichi mirati e vincolati, non ad agenti che richiedono frequenti tentativi di recupero (model card 0.9B, card GGUF 3.7B).
Per un primo esperimento locale, il 7B è l'opzione più documentata della famiglia: la sua card tratta parser per reasoning e tool call, un'impostazione di tensor parallelism su singolo dispositivo e varianti quantizzate. La tabella dei benchmark riportata dichiara 70.6% su SWE-bench Verified, 39.1% su Terminal-Bench 2.1 e 25.8% su tau3-Banking, ma tutti i risultati usano un elevato sforzo di reasoning e la card avverte che i dettagli del protocollo possono differire (model card 7B).
La card del 7B raccomanda un elevato sforzo di reasoning e almeno 32,768 token di output; un reasoning più lungo aumenta il tempo di generazione e può rendere costoso in termini di tempo effettivo un modello che pure entra in memoria.
Workstation e server: 32B e 36B-A4B
Il 32B è interamente dense e quindi più semplice da valutare, ma il suo stato Stage1 e il GGUF ufficiale da 69.6 GB sono i vincoli reali di pianificazione (GGUF Stage1 32B).
Il MoVA 36B-A4B pone una domanda diversa: un modello con calcolo attivo molto più basso può avvicinarsi alle capacità di un modello dense mantenendo una capacità totale maggiore? La tabella di benchmark del GGUF di IFM riporta 26.8% su tau3-Banking e 58.6% su Terminal-Bench 2.1, dove guida il gruppo di confronto elencato, ma non primeggia in tutte le misure di scienza, fattualità o contesto lungo (card benchmark GGUF 36B).
Una volta caricati i pesi, il minor numero di parametri attivi può migliorare il throughput sostenuto, ma il risultato dipende da backend, batching, interconnessione e quantizzazione.
Il modello di punta: 375B-A23B
La model card ufficiale documenta una configurazione SGLang validata per K2 Horizon 375B-A23B con otto GPU H200, tensor parallelism a 8, expert parallelism a 8, BF16 e FlashAttention-3 (model card 375B).
Il rapporto fra parametri totali e attivi può ridurre il calcolo rispetto a un modello dense da 375B, ma la soglia di pianificazione BF16 di circa 750GB resta il confine infrastrutturale. Artificial Analysis riporta un Intelligence Index di 47 e una posizione #11 su 112 nella classe mostrata, ma non fornisce né una velocità di output né un costo per task per il modello (profilo Artificial Analysis).
In base al profilo validato attualmente documentato con otto H200, va considerato un deployment su scala cluster.
MoVA migliora l'economia del calcolo, non la soglia di storage
MoVA significa Mixture-of-Value Attention. Le architetture mixture-of-experts convenzionali applicano di norma il routing sparso nei layer feed-forward; IFM descrive MoVA come un'estensione del routing degli esperti alla componente value dell'attenzione, mantenendo la compatibilità con tecniche quali FlashAttention e grouped-query attention (spiegazione dell'architettura IFM).
Cosa comunica la sigla 36B-A4B
Il nome “36B-A4B” riporta due quantità differenti: sono disponibili circa 36B parametri totali, mentre per ciascun token ne risultano attivi circa 4B. Questo può ridurre le operazioni multiply-and-accumulate e il traffico di memoria nel percorso attivo, soprattutto nei carichi con generazione continuativa.
Non significa che gli esperti non utilizzati scompaiano. Il file GGUF ufficiale pesa 74.9 GB in BF16 e la ricetta vLLM descrive un modello con 37.44B parametri memorizzati inclusi gli embedding e 5.95B parametri attivi per token. Sono due modalità di packaging e conteggio della stessa architettura, non la prova dell'esistenza di un modello separato da 37B (ricetta vLLM).
Un modello mentale utile è questo:
- Capacità residente: storage e memoria devono contenere i pesi che possono essere selezionati.
- Calcolo attivo: ogni token coinvolge soltanto un sottoinsieme instradato.
- Stato del runtime: KV cache, buffer temporanei, batching e overhead del framework restano necessari.
- Costo di sistema: interconnessione, energia, RAM host e tempo operativo determinano la spesa.
Perché la promessa di 512K di contesto non è un budget
Le card di K2 Horizon pubblicizzano un contesto nativo di 524,288 token per i modelli maggiori. Le ricette vLLM pubblicate per MoVA 36B-A4B e 375B-A23B impostano però --max-model-len 131072, un quarto del massimo dichiarato (ricetta vLLM 36B, model card 375B).
Le ricette a 131K mostrano che il contesto nativo da 512K non è un'impostazione di serving gratuita: contesti più lunghi consumano KV cache, riducono la concorrenza e aumentano la latenza dei prompt.
Scenari di self-hosting con costi
K2 Horizon non ha un prezzo API trasparente e universale da usare come riferimento. La pagina ufficiale del GGUF MoVA afferma che nessun provider di inferenza distribuisce al momento il modello, mentre Artificial Analysis mostra prezzi input e output di $0.00 per il profilo 375B ma segnala come non disponibili velocità e costo per task; non è una prova dell'esistenza di un endpoint di produzione gratuito (card GGUF MoVA, Artificial Analysis).
| Scenario | Cosa offre | Principale rischio economico | Verdetto |
|---|---|---|---|
| GPU classe 24GB con una quantizzazione 4 bit 36B adatta | Sperimentazione a basso costo e privacy | Poco margine per contesto e concorrenza; supporto a quantizzazione e runtime potenzialmente immaturo | Ideale per un pilota, non come obiettivo di produzione garantito |
| Workstation 32B BF16 o 36B BF16 | Maggiore fedeltà e confronti qualitativi più semplici | 64–75GB di pesi prima di cache e memoria di runtime | Di norma un sistema multi-GPU o ad alta memoria |
| Serving 36B su due H200 | Rispecchia la configurazione MoVA documentata | Costi di noleggio, host, storage e utilizzo | Sensato per un servizio continuativo o una valutazione controllata |
| Serving 375B su otto H200 | Capacità di punta e throughput su scala enterprise | Elevato impegno infrastrutturale, in conto capitale o a ore | Solo scala cluster |
Un esperimento su GPU classe 24GB
La soglia idealizzata a 4 bit per un modello da 36B è circa 18GB, lasciando meno di 6GB su una scheda da 24GB per metadati di quantizzazione, buffer del runtime e KV cache. L'aritmetica rende plausibile un test su GPU classe 24GB con contesto moderato, ma non definisce un minimo universale: quantizzazione precisa, backend, policy di offload e lunghezza del prompt stabiliscono ancora se l'esecuzione sarà utilizzabile.
L'artefatto GGUF MoVA ufficiale citato è BF16, non una piccola quantizzazione consumer. La raccolta Hugging Face elenca varianti GGUF e FP8 per l'intera famiglia, ma il lavoro di conversione e compatibilità al momento del rilascio rientra comunque nel budget di deployment (collezione K2 Horizon).
“Presumo stiano ancora caricando altri GGUF--per ora vedo soltanto un GGUF BF16” — u/apoptosist in r/LocalLLaMA.
Due H200 per il percorso 36B documentato
La ricetta vLLM di IFM per MoVA usa tensor parallelism a 2, expert parallelism, BF16 e un limite di serving di 131,072 token. La documentazione SGLang indica che la configurazione è stata validata su 2× H200, un segnale hardware più solido di quanto suggerisca il solo nome del modello (ricetta vLLM, card GGUF ufficiale).
Le tariffe pubblicate dai provider mostrano perché l'utilizzo sia decisivo. DigitalOcean indica una NVIDIA H200 dedicata a $4.47 per GPU-ora e una configurazione 8× H200 a $35.78 all'ora; Google Cloud indica una macchina A3 Ultra con 8× H200 a $84.806908493 all'ora, con vCPU, memoria e SSD collegati inclusi nel prezzo della tipologia di macchina (prezzi DigitalOcean, prezzi Google Cloud).
Alla tariffa indicata per singola GPU, due H200 equivalgono a circa $8.94 all'ora o $6,526 per un mese di 730 ore prima dei costi di host e storage; va usato soltanto come riferimento sensibile al tasso di utilizzo, non come preventivo per due GPU.
Otto H200 per 375B-A23B
La ricetta di serving ufficiale del modello di punta usa otto H200, TP=8, EP=8 e BF16. Questa configurazione è coerente con la soglia di pianificazione BF16 grezza di circa 750GB del modello e rende esplicito il confine enterprise (model card 375B).
Il prezzo pubblicato da Google per una macchina con 8× H200, $84.81 all'ora, equivale a circa $61,909 per 730 ore, prima di tasse, trasferimento dati, storage persistente e operatività dell'applicazione. È un riferimento infrastrutturale, non un prezzo di K2 Horizon né una garanzia che la ricetta pubblicata raggiunga un determinato valore di token al secondo.
Cosa possono dimostrare, e cosa non dimostrano, i primi test di self-hosting
I primi riscontri mostrano che K2 Horizon è eseguibile, ma quantizzazioni e runtime eterogenei non definiscono ancora una curva universale di costo-prestazioni.
Un resoconto dettagliato su X offre un buon esempio di quanto possa contare il backend:
“36B-A4B MoVA fa 131-142 tok/s su 2x 5090 con llama.cpp (fork di IFM, Q8_0, ctx 131K) contro 52 con vLLM...” — @abtraore_.
Questo riscontro utile ma non controllato spiega perché dire semplicemente “MoVA è più veloce” è incompleto senza indicare backend e configurazione.
Le discussioni su Reddit segnalano questioni ancora aperte su quantizzazione, VRAM ridotta, confronti e tool call, non prestazioni validate (thread r/LocalLLaMA).
Per una decisione d'acquisto seria mancano misurazioni di memoria residente per quantizzazione, crescita della KV cache in funzione del contesto, velocità di prompt e generazione, affidabilità delle tool call, consumo energetico e costo per task completato con successo su un unico carico controllato.
Scegliere in base all'utilizzo, non al marketing dei parametri attivi
Il modello K2 Horizon più adatto dipende dalla frequenza d'uso, dal contesto necessario e dal fatto che la qualità dell'output giustifichi l'infrastruttura. Un pilota breve dovrebbe privilegiare la reversibilità; un servizio privato sempre attivo deve privilegiare utilizzo e stabilità operativa.
| Il tuo carico di lavoro | Da cui partire | Perché | Fermati o passa oltre quando |
|---|---|---|---|
| Wearable, embedded o task ristretto in stile classificatore | 0.9B | Ingombro minimo e contesto dichiarato di 128K | Profondità nell'uso dei tool o copertura del dominio diventano il collo di bottiglia |
| Assistente locale compatto o esperimento di fine-tuning | 3.7B | Basso carico di storage e reasoning più ampio rispetto allo 0.9B | Dominano gli errori nel coding e nel recupero |
| Primo pilota serio locale per coding/agenti | 7B | Documenta parser, tensor parallelism e varianti quantizzate | I task lunghi richiedono pianificazione o uso dei tool più affidabili |
| Workstation ad alta capacità con baseline dense | 32B Stage1, con cautela | Il comportamento dense è più facile da confrontare, ma il checkpoint attuale non è finale | Checkpoint finale e risultati misurati giustificano la memoria richiesta |
| Inferenza locale/server ripetuta dove conta il calcolo attivo | MoVA 36B-A4B | Minor numero di parametri attivi e percorso TP=2/EP documentato | Contesto, concorrenza o attriti del runtime annullano il guadagno di efficienza |
| Reasoning enterprise e agenti a lungo orizzonte | 375B-A23B | Membro della famiglia con la maggiore capacità e percorso 8× H200 documentato | Il costo per task o l'utilizzo non reggono il caso di business |
Per il primo pilota, registra cinque valori prima di cambiare modello: picco VRAM/RAM, lunghezza del prompt, tempo al primo token, token generati al secondo e costo per task completato. Mantieni il limite di contesto ai 131,072 token documentati finché il carico non dimostra che andare oltre valga il costo in cache e latenza.
Se la domanda è quale membro della famiglia entra in una determinata macchina, la guida al dimensionamento dei modelli K2 Horizon tratta questo problema di selezione più circoscritto. Questa pagina dà invece priorità all'utilizzo e al costo misurato per task, non alle etichette dei parametri attivi.
FAQ sui modelli K2 Horizon
Apache 2.0 significa che tutti i dataset di K2 Horizon sono Apache 2.0?
No. IFM afferma che modelli e codice usano Apache 2.0, mentre i dataset seguono le licenze applicabili, come ODC-BY. Prima di ridistribuire o usare commercialmente i dati per il training, verifica ogni repository e dataset (annuncio IFM).
4B attivi significa che K2 Horizon MoVA 36B-A4B richiede la memoria di un modello da 4B?
No. Il modello attiva circa 4B parametri per token, ma il suo GGUF BF16 ufficiale è di circa 74.9GB. Storage dei pesi, KV cache, buffer del runtime, overhead di quantizzazione e concorrenza determinano il fabbisogno di memoria effettivo.
Una singola GPU da 24GB può eseguire K2 Horizon MoVA 36B-A4B?
Una quantizzazione a 4 bit adatta può rendere plausibile un esperimento a contesto moderato, perché la soglia idealizzata dei pesi per 36B è circa 18GB. L'artefatto BF16 ufficiale e il percorso di serving validato su due H200 richiedono molto più margine; un risultato su 24GB va quindi considerato una configurazione pilota, non una garanzia generale di produzione.
Servire il contesto pubblicizzato da 512K è economicamente sostenibile?
Non automaticamente. Le model card dichiarano un contesto nativo di 524,288 token, mentre gli esempi vLLM documentati usano 131,072 token; un contesto più lungo aumenta la richiesta di KV cache e la latenza, e spesso riduce la concorrenza.
K2 Horizon 375B-A23B è un normale modello da self-hosting?
No. IFM documenta una configurazione SGLang con otto H200 e la soglia di pianificazione BF16 grezza è circa 750GB prima dell'overhead del runtime. Va trattato come deployment enterprise o su cluster, salvo che un provider pubblichi una configurazione validata più piccola.
Il prezzo di $0.00 mostrato per K2 Horizon 375B indica una vera API gratuita?
No, i dati disponibili non sostengono una conclusione del genere. Artificial Analysis mostra prezzi input e output di $0.00, ma indica velocità e costo per task come non disponibili, mentre la pagina ufficiale del modello non ha un provider di inferenza Hugging Face; prima di inserire quella cifra in un budget, verifica contratto e listino di un provider nominato.