I pesi open di Kimi K3 sono disponibili: 1,56 TB e l'hardware necessario per eseguirli

Moonshot ha pubblicato i pesi open di Kimi K3 il 27 luglio 2026, undici giorni dopo il debutto del modello via API. Il download è pubblico e reale; con 1,56 TB distribuiti in 96 shard safetensors, però, chiarisce subito una distinzione che molti scoprono tardi: un modello può essere open senza essere alla portata di chiunque voglia eseguirlo. Vediamo cosa è stato rilasciato, cosa permette la licenza e cosa serve per servirlo.

Cosa include il rilascio di Moonshot

Il checkpoint completo è disponibile su Hugging Face all'indirizzo moonshotai/Kimi-K3, con un mirror su ModelScope per gli utenti in Cina. Il repository pesa 1,56 TB e comprende 96 shard safetensors, config.json, il codice del modello e del tokenizer (modeling_kimi_k3.py, encoding_k3.py, un modello tiktoken con vocabolario da 160K), il preprocessing per la visione e il file LICENSE. In parallelo, nel repository GitHub MoonshotAI è apparso anche il report tecnico.

Nel model card contano soprattutto tre dettagli, più del numero di parametri in copertina:

• 104B sono i parametri attivati per token, su 2,8T complessivi: 16 dei 896 expert instradati per token, più 2 expert condivisi, lungo 93 layer. Prima della pubblicazione dei pesi, questo dato non era pubblico.
• I pesi nascono in formato MXFP4. Moonshot ha applicato il quantization-aware training fin dalla fase SFT, con attivazioni MXFP8. Non si tratta quindi di una quantizzazione successiva di un checkpoint BF16: questa release è direttamente a 4 bit.
• L'attenzione segue una ripartizione 69/24 fra layer Kimi Delta Attention e Gated MLA, con una finestra di contesto da 1.048.576 token.

L'adozione si è mossa rapidamente. Il repository aveva già 6,6k like il 28 luglio 2026, un giorno dopo il commit iniziale nella sua cronologia dei commit; nel frattempo erano già disponibili conversioni della community: unsloth/Kimi-K3-GGUF è stato creato la stessa sera e, la mattina seguente, GrEarl/Kimi-K3-GGUF ospitava una conversione Q2_K completa.

Kimi K3 License: non è una MIT

I precedenti modelli di punta Kimi uscivano con una licenza Modified MIT. Per K3 non è così. La distribuzione adotta un documento chiamato Kimi K3 License: il testo deriva dalla MIT e consente uso, copia, modifica, unione, pubblicazione, distribuzione, sublicenza, vendita, fine-tuning e creazione di opere derivate, ma aggiunge due condizioni da leggere bene prima di costruirci sopra un prodotto.

La clausola Model-as-a-Service. Il passaggio operativo recita: "If the Licensee or any of its affiliates operates a Model as a Service business, and the aggregate revenue of the Licensee and its affiliates exceeds 20 million US dollars ... in total over any consecutive 12 months, the Licensee must enter into a separate agreement with Moonshot AI before using the Software or its derivative works for any commercial purpose." La licenza definisce MaaS l'offerta a terzi di accesso all'inferenza o al fine-tuning in modo da consentire loro di controllare input, parametri o dati di addestramento. Esclude esplicitamente dal MaaS due casi: i prodotti per utenti finali in cui le capacità del modello sono integrate in funzioni specifiche e il semplice inoltro di richieste a modelli ospitati da altri.

La clausola di attribuzione. Se un prodotto commerciale basato su K3 supera 100 milioni di utenti attivi mensili oppure 20 milioni di USD di ricavi mensili, nella sua interfaccia deve comparire in modo ben visibile la dicitura "Kimi K3".

Entrambe le clausole non si applicano all'uso puramente interno, cioè quando modello, output e capacità non sono esposti a terzi, né all'accesso tramite i prodotti ufficiali Moonshot o partner certificati per l'inferenza. Interpretando letteralmente le eccezioni: il fine-tuning di K3 su dati interni rientra nell'esenzione per uso interno della Sezione 4(a), mentre l'integrazione come funzionalità di un prodotto è indicata nella Sezione 2 come attività che non costituisce MaaS. Rivendere inferenza K3 come servizio è proprio il caso a cui mirano le clausole aggiuntive; oltre la soglia di $20M non si tratta più soltanto di licenza, ma di negoziare un contratto. Prima di impegnare una roadmap, leggete direttamente il LICENSE: quanto riportato qui è un'interpretazione del testo, non una consulenza legale.

1,56 TB: il vincolo è l'hardware

I pesi open di Kimi K3 possono essere scaricati da chiunque. Servirli è tutt'altra questione.

La ricetta ufficiale per K3 di vLLM è esplicita: servono almeno 8× GB300, e per traffico di produzione reale occorre una configurazione multi-nodo. Sul fronte AMD indica almeno 8× MI355X o MI350X con l'immagine ROCm. Anche SGLang pubblica un cookbook per K3 rivolto allo stesso livello di hardware.

Per chi deve davvero fare il provisioning, le note operative della ricetta meritano una seconda lettura. Il serving richiede l'immagine dedicata vllm/vllm-openai:kimi-k3, oppure vllm/vllm-openai_rocm:kimi-k3 su AMD, non vLLM standard. Il traffico fra nodi usa preferibilmente --all2all-backend deepep_v2 su RDMA oppure flashinfer_nvlink_one_sided su NVLink, impostando UCX_TLS="rc,cuda_copy" affinché il trasferimento della KV cache resti su RDMA. La scelta del backend MoE dipende dalla topologia: deep_gemm_mega_moe per deployment expert-parallel e flashinfer_trtllm per TP>1. La ricetta segnala inoltre che K3 può talvolta generare un formato di tool call che il suo parser non accetta: validazione dello schema e retry dovrebbero quindi essere presenti nel layer di serving fin dal primo giorno.

La classica via d'uscita, quantizzare ulteriormente il modello, qui aiuta poco: MXFP4 equivale già a circa 4,25 bit per parametro. Il margine di compressione che rendeva gestibili su una workstation modelli della classe da 1T è stato in gran parte consumato prima ancora del download. La prima conversione GGUF a 2 bit della community occupa comunque 928 GB in 94 shard: un risparmio del 40% su una dimensione che non era mai stata il vincolo decisivo.

Aggiungendo la KV cache per avvicinarsi anche solo alla finestra da 1M token, il working set cresce ulteriormente. La testimonianza di self-hosting più notevole del primo giorno arriva da un team che dichiara di eseguire i pesi MXFP4 ufficiali su 80× RTX 5090 con normale Ethernet, senza HBM e senza ri-quantizzazione, a circa 20 token al secondo in single stream senza ottimizzazioni. È una dichiarazione non verificata, pubblicata il primo giorno in un singolo post: non è un benchmark e una configurazione non definisce un minimo. Vale la pena citarla solo per l'ordine di grandezza: il percorso meno costoso riportato per far girare K3 su silicio consumer richiedeva ottanta GPU di fascia alta e offriva una velocità che molti giudicherebbero lenta.

Vale la pena chiarire il caso Ollama, perché è il primo tentativo di molti. La voce in libreria esiste, ma rimanda a kimi-k3:cloud, cioè al routing ospitato di Ollama anziché a un pull locale. Oggi non esiste un percorso pratico per laptop o singola workstation; inoltre, dato che MXFP4 è il formato nativo e non una quantizzazione di comodo, la ri-quantizzazione aggressiva della community ha meno margine rispetto alla linea K2. Il supporto di llama.cpp è ancora in evoluzione: meglio verificarne lo stato attuale anziché darlo per scontato in un senso o nell'altro.

Dove usare Kimi K3 oggi

Per quasi tutti, la scelta pratica è un endpoint ospitato. Come spesso accade con i rilasci open-weight, i provider terzi si sono attivati nel giro di un giorno. I prezzi riportati sotto sono per milione di token, input/output, secondo i listini del 28 luglio 2026.

Prima di scegliere, controllate due aspetti. Il primo è che la finestra di contesto cambia drasticamente: Nebius applica lo stesso prezzo di listino con una finestra da 8K, eliminando il principale motivo per usare K3. Il secondo è che cambia anche la quantizzazione: Moonshot serve il modello in MXFP4 nativo, Baseten in FP8, mentre diversi provider non dichiarano affatto la precisione. Nel lavoro agentico su orizzonti lunghi, la precisione di riferimento e la finestra completa da 1M contano in genere più della differenza di prezzo; per prompt brevi e grandi volumi, latenza e disponibilità geografica possono invece contare più di entrambe.

Oltre agli endpoint diretti, OpenRouter li aggrega dietro un'unica chiave API, mentre gateway multi-modello instradano K3 insieme ad altri modelli frontier open cinesi. AIReiter espone la stessa classe di modelli tramite un'API compatibile con Anthropic, se il vostro stack usa già quel protocollo. L'endpoint di Moonshot offre superfici compatibili sia con OpenAI sia con Anthropic. Per dettagli completi su rate e tier, consultate l'analisi dei prezzi di Kimi K3.

Meglio self-hosting o endpoint ospitato?

Prima fate i conti. A $3/$15 per milione di token, un miliardo di token in output costa $15.000 e un miliardo di token in input $3.000. Confrontate queste cifre con il minimo praticabile per il self-hosting: un nodo della classe 8× GB300, un investimento data center oppure un noleggio fatturato a ore di acceleratore, più interconnessione, energia, raffreddamento e un ingegnere che conosca --all2all-backend a memoria. NVIDIA e i principali cloud non pubblicano un prezzo di listino per questa configurazione, quindi il confronto va costruito su un preventivo aggiornato, non su una regola empirica. E ricordate che il costo hardware è fisso, mentre quello dell'API cresce soltanto con l'uso effettivo.

Il self-hosting dei pesi open di Kimi K3 ha senso in tre scenari, più ristretti di quanto possano sembrare:

1. Requisiti air-gapped o di data residency che nessun endpoint terzo può soddisfare. È il caso più forte, e il costo non è il fattore decisivo.
2. Fine-tuning su dati proprietari. La licenza lo consente esplicitamente, ed è qualcosa che un endpoint ospitato non offre. Il costo dell'addestramento è separato e superiore a quello del serving.
3. Volume sostenuto a saturazione. Se un cluster multi-nodo resta occupato ininterrottamente, l'hardware di proprietà può scendere sotto il prezzo per token. I picchi occasionali non rientrano in questo caso.

Se non vi riconoscete in nessuno di questi casi, usate un endpoint e considerate i pesi un'opzione, non un piano operativo. Per la maggior parte dei team, il valore di un modello frontier open-weight non sta nel fatto che lo eseguiranno direttamente: sta nel fatto che il prezzo della versione ospitata deve ora competere con la possibilità concreta che possano farlo.

FAQ

Kimi K3 è open source?

È open-weight. Il checkpoint completo da 2,8T è scaricabile e la Kimi K3 License consente uso, modifica, distribuzione e fine-tuning. Non sono stati pubblicati i dati di addestramento né l'intera pipeline di training; inoltre, la licenza aggiunge una clausola legata ai ricavi per gli operatori Model-as-a-Service. Non è quindi open source nel senso OSI del termine.

Posso eseguire Kimi K3 in locale con Ollama?

No. La voce kimi-k3 di Ollama corrisponde a kimi-k3:cloud e instrada verso un endpoint ospitato. I pesi MXFP4 nativi pesano 1,56 TB e anche un GGUF a 2 bit della community arriva a 928 GB, quindi non esiste un percorso locale su hardware consumer.

Con quale licenza sono distribuiti i pesi di Kimi K3?

Con la Kimi K3 License: deriva dalla MIT, ma richiede un accordo separato con Moonshot se si gestisce un'attività Model-as-a-Service che supera $20M di ricavi in un periodo qualsiasi di 12 mesi, oltre a imporre l'attribuzione nell'interfaccia sopra 100M di MAU oppure $20M di ricavi mensili. L'uso interno è esente da entrambe le clausole.

Dove posso usare Kimi K3 senza scaricarlo?

Nell'API e nell'app di Moonshot, oltre che tramite Baseten, Fireworks e Nebius. Al 28 luglio 2026, tutti e quattro indicano $3/$15 per milione di token come tariffa base, ma il confronto dipende dalle condizioni: Fireworks offre anche un tier da $4.50/$22.50 e Nebius applica la tariffa base con una finestra di contesto da 8K anziché 1M. Per capire cos'è il modello e come si comporta nei benchmark, consultate la panoramica di Kimi K3.