Il 27 luglio Moonshot AI ha pubblicato i pesi di Kimi K3 (moonshotai/Kimi-K3 su Hugging Face), undici giorni dopo aver aperto l’API (blog di lancio): chiunque può ora scaricare il modello e farlo girare sui propri server, invece di usarlo da remoto a consumo. Sono 2.800 miliardi di parametri (i 2,8 trilioni della notazione anglosassone, da cui la sigla 2,8T) sotto Kimi K3 License, una licenza propria di Moonshot che copre sia il codice sia i pesi: il modello aperto più grande mai distribuito. Di seguito le specifiche che contano, cosa serve per farlo girare e i punti su cui documentazione ufficiale e fonti indipendenti non concordano.
Architettura del modello
Tre scelte architetturali reggono il modello.
Kimi Delta Attention (KDA), affiancata da Attention Residuals (AttnRes), riduce il costo dell’attenzione sui contesti lunghi mantenendo espressività piena sui layer critici. L’implementazione con prefill cache è stata contribuita alla community vLLM.
Stable LatentMoE porta la sparsità a 16 esperti attivi su 896, per 104 miliardi di parametri attivi per token, meno del 4% della rete: è così che un modello da 2.800 miliardi di parametri risponde in tempi utili. Il bilanciamento del router (Quantile Balancing) deriva l’allocazione degli esperti dai quantili degli score, senza loss ausiliaria.
Quantization-aware training dalla fase SFT in poi: pesi MXFP4, attivazioni MXFP8. Non è quantizzazione post-hoc, ed è la ragione per cui il checkpoint a 4 bit non collassa. Moonshot dichiara 2,5x di efficienza di scaling rispetto a K2.
Performance del modello
Al debutto del 16 luglio l’Artificial Analysis Intelligence Index v4.1, indice indipendente che media nove prove, lo colloca a 57,1: dietro Claude Fable 5 (59,9) e GPT-5.6 Sol (58,9), sopra Opus 4.8 (55,7). Il 34% del peso va ai compiti agentici, il terreno per cui K3 è stato ottimizzato; la classifica cambia ogni settimana: il dato è la fotografia del lancio.
Su DeepSWE v1.1 è il miglior open-weight in classifica: 0,69 al 30 luglio, quarto assoluto dietro GPT-5.6 Sol (0,73), Claude Fable 5 e GPT-5.6 Terra (0,70).
Il quadro regge sulle altre classifiche indipendenti: su GDPval-AA v2, dove il riferimento degli esperti umani è fissato a 1.000, segna 1.687, terzo al debutto e settimo al 30 luglio a punteggio invariato, scavalcato solo da nuove configurazioni di Claude Opus 5; sulla Code Arena WebDev, dove a votare sono sviluppatori umani, ha debuttato primo e al 30 luglio è secondo, dietro Claude Opus 5 Max.
Sui costi, Artificial Analysis misura una media di 0,94$ per task dell’Intelligence Index, contro 1,04$ di GPT-5.6 Sol e 1,80$ di Opus 4.8. Il listino è 3 $/MTok (milione di token) in input, che scendono a 0,30$ quando la richiesta è già in cache, e 15 $/MTok in output.
Modalità di utilizzo e installazione
Via API l’endpoint è OpenAI-compatible: il codice già scritto per i modelli OpenAI funziona puntando base_url a https://api.moonshot.ai/v1, modello kimi-k3, con temperature=1.0 e top_p=1.0 raccomandati da Moonshot. Due dettagli fanno la differenza in produzione: il reasoning effort di default è max e va tarato per workload, altrimenti si pagano output token che non servono; e la thinking history dei turni precedenti va conservata nei messaggi, perché il modello degrada quando la si rimuove.
Per il self-hosting, i pesi su Hugging Face pesano 1,56 TB in 96 file safetensors, già in versione MXFP4: non c’è un checkpoint compresso separato da scaricare. Per il server di inferenza i profili di parallelismo dipendono dalla topologia della macchina: meglio non improvvisare e seguire le ricette ufficiali per vLLM, SGLang e TokenSpeed.
I requisiti della ricetta vLLM vanno letti prima di ordinare hardware: vLLM 0.27.0 o superiore, build CUDA 13 con driver NVIDIA r580 o successivo, almeno 8x GB300 per il nodo singolo (su AMD, 8x MI355X o MI350X), multi-nodo raccomandato per la produzione. Il motivo è la memoria: 1,56 TB di pesi non entrano in una scheda sola, e nemmeno in otto della generazione precedente. È la voce di costo che decide se il self-hosting abbia senso rispetto all’API.
Licenza
Prima di costruire un prodotto sui pesi scaricati conviene leggere le condizioni. La Kimi K3 License è un testo proprio di Moonshot, non una licenza open source standard, e concede molto: uso commerciale, modifica, redistribuzione, vendita di copie. Le condizioni scattano su due soglie: chi rivende il modello come servizio e supera 20 milioni di dollari di ricavi in dodici mesi consecutivi deve firmare un accordo separato con Moonshot; chi offre un prodotto con più di 100 milioni di utenti attivi mensili, oppure oltre 20 milioni di dollari di ricavi al mese, deve mostrare «Kimi K3» in evidenza nell’interfaccia.
L’uso interno, in cui gli output del modello non vengono resi disponibili a terzi, è esente da entrambe le soglie: per la quasi totalità dei progetti aziendali la licenza non pone ostacoli pratici, e il vincolo riguarda solo chi costruisce sul modello un business di rivendita su larga scala. Il software è fornito così com’è, senza garanzie.
FInestra di contesto e sicurezza
Il contesto dichiarato è 1M token, ma le configurazioni di serving pubblicate si fermano a 131.072 e più fonti indicano 128K come finestra realmente efficace. Il 90,4 su BrowseComp, il benchmark di ricerca autonoma sul web, è dichiarato nel post di lancio a contesto pieno e resta un numero vendor, non ancora replicato da terzi. Mancano valutazioni pubbliche di cybersecurity, e Moonshot stessa segnala nello stesso post una tendenza del modello a essere troppo proattivo quando l’intento dell’utente è ambiguo.
Conclusione
Per workload cost-sensitive con vincoli di sovranità del dato, K3 è la prima opzione aperta che non impone un compromesso sulla capacità. Per tutto il resto il conto dell’hardware resta il fattore decisivo: prima di parlare di on-premise va misurato il costo per task contro l’API. E lì il numero da guardare non è la posizione in classifica ma la cache hit rate: Moonshot dichiara oltre il 90% sui workload di coding, e con l’input a 0,30 $/MTok in cache contro 3 pieni quella percentuale sposta l’economia del progetto più di qualsiasi benchmark. È la prima cosa che misureremo sulle nostre pipeline agentiche long-horizon: lo stesso esercizio che accompagniamo nei progetti dei clienti, misurare il costo reale prima di scegliere l’infrastruttura.