Come eseguire Kimi K3 localmente: hardware, memoria e limiti di distribuzione

Running the full Kimi K3 locally is possible with released weights, but practical deployment still requires cluster-scale memory, accelerators, and interconnects.

After the July 27 open-weight release, the question is no longer whether a checkpoint exists, but whether your system can download, load, and serve it at useful speed. The public repository is about 1.56 TB across 96 safetensor shards, while the model contains 2.8 trillion total parameters and activates 104 billion per token. Those numbers keep a normal PC, Mac, home NAS, or single-GPU server outside the practical full-model range, so the sections below separate storage, memory, accelerator topology, runtime support, and realistic fallback paths.

What Is Available Now That Kimi K3 Weights Are Released?

Il rilascio open-weight di Kimi K3 include il checkpoint completo del modello e il rapporto tecnico. Il repository pubblico del modello mostra attualmente circa 1,56 TB di file e 96 frammenti safetensor numerati. Questa cifra è utile per pianificare download e capacità disco, ma non rappresenta una specifica minima di VRAM.

Il riepilogo del modello rilasciato conferma 2,8T parametri totali, 104B parametri attivati, 93 livelli, 69 livelli di Kimi Delta Attention e 24 livelli di Gated MLA. Il routing Stable LatentMoE seleziona 16 esperti su 896 per token e utilizza anche due esperti condivisi. I pesi sono MXFP4, le attivazioni sono MXFP8 e il contesto massimo pubblicizzato è di 1.048.576 token.

Il supporto alla distribuzione è anche più concreto rispetto a prima del rilascio. vLLM, SGLang e TokenSpeed sono elencati come motori di inferenza raccomandati, ma ciascuno richiede kernel, codice modello, sharding e impostazioni di memoria compatibili con K3. Un comando generico mostrato da una libreria client non trasforma il checkpoint in un modello locale a scala consumer.

Perché MoE sparso richiede ancora una memoria enorme?

Kimi K3 esegue il calcolo con 104 miliardi di parametri attivati per ogni token, ma tutti gli esperti MoE consumano ancora memoria di archiviazione e di servizio. Il router può selezionare esperti diversi per il token successivo, quindi l'intero set di pesi da 2,8T deve rimanere accessibile da qualche parte nella distribuzione.

Selezionare 16 esperti su 896 riduce il lavoro degli esperti eseguito per un token. Non significa che una macchina possa mantenere solo 16 esperti, scartare il resto e continuare a eseguire il modello rilasciato senza modifiche. La potatura degli esperti, la distillazione o lo streaming creerebbero un compromesso operativo diverso e non devono essere confusi con l'attivazione sparsa normale.

La cifra di 104 miliardi di parametri attivati è quindi una descrizione della scala di calcolo, non un modo rapido per stimare la dimensione del checkpoint. Moltiplicare 104 miliardi per quattro bit e affermare che il modello necessita solo di circa 52 GB ignorerebbe i pesi degli esperti inattivi ma ancora necessari, le componenti dense, gli esperti condivisi, i livelli di attenzione, i pesi visivi e lo stato di runtime.

Qual è il limite minimo di memoria per i pesi?

Con 2,8 trilioni di parametri, il calcolo più semplice del limite inferiore è il totale dei parametri moltiplicato per i bit memorizzati per parametro. MXFP4 offre un limite minimo di quattro bit: 2,8T × 4 bit sono circa 1,4 TB, o circa 1,27 TiB, solo per il payload grezzo dei pesi.

Il repository rilasciato è di circa 1,56 TB, il che spiega perché la memoria di servizio si estende oltre un semplice calcolo dei pesi. Il confezionamento del checkpoint, le scale dei blocchi, l'allineamento dei tensori, i file di configurazione, le risorse del tokenizer, i componenti visivi e altri dati del modello spingono il download reale oltre il limite teorico a quattro bit.

Quattro diversi budget devono essere pianificati separatamente: spazio di archiviazione persistente per il download, spazio temporaneo di staging, RAM host e HBM o VRAM dell'acceleratore. Un servizio in esecuzione necessita poi di spazio aggiuntivo per lo stato KDA, cache KV MLA, attivazioni, buffer di comunicazione, kernel, cattura del grafo e margine per guasti. La dimensione del repository di 1,56 TB non è quindi né un requisito completo di RAM né un requisito completo di memoria GPU.

Quale hardware può effettivamente eseguire Kimi K3 localmente?

Non esiste una lista onesta di GPU consumer minime per il modello completo. Un sistema che tecnicamente può mappare o trasmettere il checkpoint non è automaticamente in grado di fornire un servizio stabile e interattivo. I requisiti hardware pratici per Kimi K3 dipendono dalla residenza del peso, dai kernel MXFP4 supportati, dalla larghezza di banda dell'interconnessione, dalla capacità della cache, dalla lunghezza del contesto, dalla concorrenza e dal motore di servizio.

Il supporto day-zero Kimi K3 pubblicato da vLLM colloca la classe di partenza realistica in un nodo enterprise con otto acceleratori. I materiali attuali di vLLM descrivono acceleratori di classe GB300 o MI350X/MI355X come punti di partenza, mentre SGLang pubblica esempi topologicamente consapevoli tra cui B300 1×8, GB300 2×4, B200 2×8, H200 2×8, H100 4×8 e MI350X/MI355X 1×8.

Queste sono ricette di runtime pubblicate e configurazioni iniziali, non un singolo minimo certificato per ogni carico di lavoro. Acceleratori più vecchi o più piccoli potrebbero richiedere più nodi, kernel di quantizzazione diversi, contesto ridotto o parallelismo esperto aggiuntivo. Il traffico di produzione necessita anche di capacità per richieste concorrenti, lavoratori falliti e margine di prestazioni, non solo di adattarsi al checkpoint una volta.

Perché una singola workstation o NAS è ancora la topologia sbagliata?

La semplice divisione della capacità sottovaluta il problema. Anche se si assembla abbastanza memoria aggregata, il parallelismo esperto trasforma il routing in traffico di rete. I token devono raggiungere gli acceleratori che ospitano gli esperti selezionati e poi tornare al resto della pipeline del modello.

I nodi acceleratori aziendali offrono più della memoria. Combinano collegamenti GPU ad alta larghezza di banda, networking abilitato RDMA, librerie di comunicazione collettiva e kernel progettati per parallelismo tensoriale, esperto, dati o pipeline. Una collezione di GPU consumer connesse tramite PCIe ordinario o una rete domestica può mostrare una capacità nominale sufficiente ma rimanere troppo lenta o fragile per un servizio utile.

Un NAS è prezioso per memorizzare frammenti di checkpoint, log, dataset, indici di recupero e dati applicativi, ma lo storage di rete non sostituisce la larghezza di banda della memoria dell'acceleratore. Il ruolo migliore per un server domestico è solitamente mantenere i dati privati e il recupero vicino all'utente lasciando l'inferenza del modello all'avanguardia a un cluster adatto o a un endpoint ospitato. In questo design, un server domestico separa il livello dati locale dall'inferenza all'avanguardia.

Come aumentano il budget lo stato KDA, la cache MLA KV e la lunghezza del contesto?

Kimi K3 non utilizza una cache di attenzione completa uniforme su tutti i 93 strati. I suoi 69 strati KDA e 24 strati MLA a porte creano due diverse esigenze di memoria di servizio: un pool di stato KDA con geometria modello fissa per le richieste ammesse e un pool MLA KV paginato che cresce con i token memorizzati.

Questa divisione significa che KDA può ridurre la crescita del contesto lungo riscontrata nell'attenzione convenzionale, ma non rende gratuita una richiesta di un milione di token. Poiché lo stato KDA e la memoria KV MLA competono per la capacità dell'acceleratore, il lato KDA può limitare le richieste ammesse mentre il lato MLA limita il totale dei token memorizzati nella cache.

Dimensione del batch, concorrenza, lunghezza media del prompt, lunghezza del ragionamento generato, input multimodali, precisione della cache e strategia di prefill/decodifica cambiano tutti la capacità utilizzabile. La cifra di 1M token è una capacità massima del modello, non un valore predefinito consigliato. Una prima distribuzione dovrebbe iniziare con un contesto massimo più breve, batch size uno e bassa concorrenza prima di misurare errori di memoria, tempo di prefill, velocità di decodifica e traffico cross-node.

Come puoi eseguire Kimi K3 localmente dopo il rilascio del peso aperto?

Eseguire Kimi K3 localmente ora significa costruire un servizio di inferenza distribuito attorno al checkpoint rilasciato, non installare un'applicazione desktop normale. La sequenza più sicura è convalidare storage, supporto runtime, topologia e un piccolo punto operativo prima di aumentare contesto o traffico.

1. Prepara lo storage. Riserva almeno l'ingombro del repository di circa 1,56 TB più spazio extra per download parziali, cache, immagini container, log e file temporanei.
2. Seleziona un motore supportato. Usa un percorso di distribuzione vLLM, SGLang o TokenSpeed specifico per Kimi K3 con il codice modello, i kernel e la versione del container o del branch richiesti.
3. Adatta la topologia. Scegli una configurazione enterprise multi-GPU o multi-nodo con sufficiente HBM e il percorso NVLink, MNNVL o RDMA previsto dalle impostazioni di parallelismo tensoriale ed esperto.
4. Inizia sotto i limiti indicati. Riduci la lunghezza massima del modello, la dimensione del batch e la concorrenza, quindi verifica il caricamento, il comportamento OOM, la correttezza dell'output, la velocità di prefill, la velocità di decodifica e il traffico all-to-all.
5. Scala solo dopo la misurazione. Aggiungi contesto, richieste concorrenti, funzionalità di cache, input multimodali o decodifica speculativa una variabile alla volta.

Un comando come vllm serve o sglang serve descrive come avviare un runtime distribuito compatibile; non elimina il requisito hardware. Quando la classe di acceleratore richiesta non è disponibile, le scelte realistiche sono un'API ospitata, un'architettura ibrida che mantiene file e recupero locali, o un modello locale più piccolo che si adatti alla memoria effettiva e al budget di affidabilità del server domestico.

FAQ

Posso eseguire Kimi K3 localmente su un PC normale, Mac o NAS domestico?

Non alla velocità pratica del modello completo. Il repository occupa circa 1,56 TB prima del sovraccarico di servizio, mentre un sistema locale normale manca anche della memoria acceleratore e della topologia ad alta larghezza di banda prevista dagli ambienti di esecuzione attuali. Lo streaming esperto sperimentale o un pesante offloading potrebbero dimostrare che un lancio è tecnicamente possibile, ma non equivale a un servizio reattivo o pronto per la produzione.

Quanta memoria e spazio di archiviazione richiede Kimi K3?

Il limite trasparente del carico di peso MXFP4 è circa 1,4 TB, mentre il repository pubblico è circa 1,56 TB. Poi servono spazio su disco extra, RAM host, HBM o VRAM dell'acceleratore, stato KDA, cache KV MLA, attivazioni, spazio di lavoro per la comunicazione e margine operativo. Non esiste un singolo numero che rappresenti tutti questi livelli.

Qual è la configurazione GPU minima pubblicata per Kimi K3?

Le configurazioni pubblicate più piccole al day-zero sono nodi aziendali con otto schede acceleratrici, con i percorsi attuali vLLM e SGLang centrati su hardware di classe B300, GB300 o MI350X/MI355X. Considera questi come punti di partenza per il runtime, non come un minimo garantito universale; contesto, concorrenza, versione del motore e obiettivi di produzione possono richiedere più risorse.

Kimi K3 può essere eseguito da SSD o NAS con offloading?

Lo storage SSD o NAS può contenere frammenti di checkpoint, e runtime sperimentali possono trasmettere i pesi attraverso la memoria host. Il problema limitante è il movimento ripetuto dei pesi esperti e dello stato attraverso storage, rete, RAM e collegamenti PCIe. Questi percorsi sono molto più lenti rispetto alla HBM degli acceleratori e ai tessuti GPU ad alta velocità, quindi un avvio sperimentale può causare latenze inutilizzabili.

Ollama esegue il modello completo Kimi K3 localmente?

L'attuale inserimento Ollama Kimi K3 utilizza il tag kimi-k3:cloud. Eseguire un client Ollama locale non significa che il checkpoint da 1,56 TB sia caricato sulla macchina locale; il percorso indicato è supportato dal cloud.

Conclusione finale

Kimi K3 è ora realmente disponibile come modello a pesi aperti, quindi gli operatori di cluster possono scaricare e distribuire il checkpoint completo invece di affidarsi a stime pre-release. Il rilascio modifica la verifica e la disponibilità degli strumenti, ma non cambia la scala fisica di un modello da 2,8 trilioni di parametri.

I numeri di memoria più utili di Kimi K3 rispondono a domande diverse: circa 1,4 TB è il limite trasparente per i pesi a quattro bit, circa 1,56 TB è l'ingombro attuale del repository, e 104B è la scala di calcolo attivata per token. Nessuno di questi numeri da solo descrive la memoria completa necessaria per un servizio in esecuzione.

Per la maggior parte degli individui e degli utenti di server domestici, il limite è chiaro: senza un nodo aziendale con otto acceleratori o un cluster distribuito, utilizzare l'inferenza ospitata, mantenere i dati privati e il livello di recupero locale, oppure scegliere un modello più piccolo. Questo è il modo pratico per beneficiare di Kimi K3 senza trattare un NAS, una workstation o una singola GPU come un supernodo di modello all'avanguardia.