Cosa serve per eseguire Kimi K3 in self-hosting

Cosa serve per eseguire Kimi K3 in self-hosting

Eseguire Kimi K3 in self-hosting significa trovare spazio per 2.8 trilioni di parametri. Moonshot ha pubblicato i pesi open in MXFP4, che occupa circa mezzo byte per peso. I soli pesi richiedono quindi circa 1.4 TB, prima di allocare anche un solo token per la cache. Nessun acceleratore attualmente in commercio può contenere da solo una quantità simile. K3 è un modello multi-node e, su un singolo server, la risposta è no.

Questa è la conclusione. Tutto ciò che segue riporta i calcoli che la motivano, perché sono la parte riutilizzabile per la prossima release. Nelle settimane successive all'annuncio del 17 July 2026, diversi fornitori di infrastrutture hanno pubblicato guide per il deployment di K3, dando per scontato che disponessi già di un cluster. Questa pagina parte dall'altra estremità: quali sono i costi, che cosa puoi eseguire in alternativa e come capire in quale delle due situazioni ti trovi.

Il numero di parametri totali e quello dei parametri attivi non coincidono

K3 è un modello mixture of experts. MoE (mixture of experts) suddivide la rete in molte sottoreti e consente a un router di selezionarne alcune per ogni token. La scheda del modello indica 2.8T di parametri totali e 104B di parametri attivati per token, distribuiti su 896 esperti instradati, di cui 16 vengono attivati per ogni token, in 93 layer.

Questi due conteggi dei parametri rispondono a domande diverse. Scambiarli è l'errore più comune in ogni discussione del tipo "posso eseguire questo modello".

I parametri attivi determinano il costo computazionale. Per ogni token vengono elaborati circa 104B di parametri. Il throughput atteso è quindi simile a quello di un modello dense da 104B, non a quello di un modello da 2.8T. Questo è il motivo principale per cui si utilizza un MoE.

I parametri totali determinano il consumo di memoria. Il router può selezionare qualsiasi esperto per qualsiasi token. Per questo tutti gli esperti devono essere residenti prima dell'arrivo della prima richiesta. Non è possibile mantenere 104B nella VRAM e recuperare gli altri parametri quando servono. Il recupero dovrebbe completarsi in microsecondi, mentre un collegamento PCIe trasferisce decine di gigabyte al secondo. Alcuni provano comunque a farlo. Trasmettere gli esperti da NVMe riduce un modello che dovrebbe generare decine di token al secondo a un modello che genera un token ogni pochi secondi.

Il calcolo è quindi relativamente economico, mentre l'archiviazione è costosa. Dimensiona l'hardware in base a 2.8T. Definisci le aspettative di velocità in base a 104B.

Byte per peso e da dove derivano i terabyte

Numero di parametri moltiplicato per byte per peso. Per i pesi, la formula completa è questa.

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

K3 è stato addestrato tenendo conto della quantizzazione ed è stato rilasciato con pesi MXFP4 e attivazioni MXFP8, quindi la riga a 4 bit è quella effettiva. Le righe superiori servono come riferimento: in bf16, lo stesso modello richiederebbe 5.6 TB. MXFP4 memorizza inoltre una scala condivisa a 8 bit per ogni blocco di 32 pesi. Questo aggiunge circa il 6 percento, quindi il repository pubblicato occupa circa 1.5 TB, anziché i 1.4 TB teorici.

Questo elimina la consueta possibilità di aggirare il problema. In questo caso, «basta quantizzarlo» non è una soluzione, perché il checkpoint rilasciato è già a 4 bit. Passare a 2 bit ridurrebbe i pesi a 0.7 TB, ma comporterebbe una perdita di accuratezza che nessuno ha misurato su questo checkpoint. Anche così, il modello supererebbe ampiamente la capacità di una singola scheda.

Quante GPU richiede Kimi K3

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

Considerateli come un valore minimo, non come un obiettivo. Il calcolo considera solo i pesi: non include la cache KV, i buffer delle attivazioni, la frammentazione dell'allocator né lo spazio necessario per una seconda richiesta simultanea. Presuppone inoltre una suddivisione parallela uniforme, che 93 layer e 896 esperti non consentono sempre.

Le indicazioni pubblicate sono nettamente superiori a questo minimo. Ad agosto 2026, Moonshot raccomanda un supernode con almeno 64 acceleratori, mentre il cookbook di SGLang include una configurazione H100 basata su quattro nodi da 8 GPU, per un totale di 32 GPU e 2,560 GB di memoria complessiva, rispetto a un minimo di 18 schede. Questa differenza non rappresenta uno spreco. Include la cache KV, la memoria delle attivazioni e il margine necessario per consentire al server di elaborare molte richieste in batch contemporaneamente. Anche la configurazione più favorevole, con 5 schede della classe GB300, descrive una macchina che la maggior parte dei provider non offre come singolo SKU.

La cache KV è la parte che sorprende

I pesi hanno un costo fisso. La cache KV (key value) no: cresce con la lunghezza del contesto e aumenta nuovamente con ogni utente simultaneo. Per l'attenzione ordinaria, la formula è bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element; quindi il risultato va moltiplicato per la lunghezza del contesto e per la concorrenza.

Ecco un esempio completo, che resta soltanto un esempio: 64 layer, 8 teste KV, dimensione della testa pari a 128, fp8. Il risultato è 2 64 8 128 1 = 131,072 byte, cioè 128 KiB per token.

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

Un utente con un contesto di 128k richiede 16 GiB. Un utente con il contesto massimo di un milione richiede 128 GiB, una quantità superiore alla capacità di qualsiasi singola scheda, per una sola conversazione.

K3 non usa l'attenzione ordinaria, e l'ultimo valore spiega il motivo. I suoi 93 layer sono composti da 69 layer KDA (Kimi Delta Attention) e 24 layer Gated MLA (multi-head latent attention). KDA mantiene uno stato ricorrente di dimensione fissa invece di una cache che cresce a ogni token, mentre MLA comprime key e value in un unico vettore latente a bassa dimensionalità. Di conseguenza, il costo reale per token è molto inferiore a quello dell'esempio. Moonshot non ha pubblicato le dimensioni latenti, quindi non indicherò un valore per utente relativo a K3. Misuralo invece nel tuo ambiente: avvia il server con un --max-model-len ridotto, monitora la memoria con nvidia-smi, quindi aumenta il limite finché l'allocazione non fallisce.

Il principio resta valido anche nella prossima release. Se un modello dichiara un contesto di un milione di token e non specifica il tipo di attenzione utilizzato, considera la cache il vincolo principale finché non viene dimostrato il contrario.

Livello 1: noleggiare il cluster a ore

Questo è l'unico livello che esegue direttamente K3. Non si acquista l'hardware. Lo si noleggia per le ore necessarie e lo si arresta al termine.

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

La tariffa è un'ipotesi, non un preventivo. Nel 2026, i prezzi on-demand pubblicati per gli acceleratori nei datacenter erano indicativamente compresi tra 2 e 5 USD per ora di GPU, mentre la capacità riservata costa meno. Usare il valore effettivo del provider e ripetere il calcolo: GPU per ore per tariffa. Il grafico serve a mostrare il rapporto. Attivare temporaneamente un nodo da 8 GPU per quattro ore al giorno costa 2,400 USD al mese, mentre lasciare in esecuzione la configurazione SGLang dimensionata per 32 GPU costa 57,600 USD.

Entrambi i server principali pubblicano un comando di avvio nella scheda del modello.

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

Nessuno dei due comandi, preso senza modifiche, è adatto a un cluster reale. Aggiungere i flag di parallelismo corrispondenti all'hardware: SGLang usa --tp-size per il parallelismo tensoriale e --ep-size per il parallelismo degli esperti; il prodotto dei due valori deve essere uguale al numero effettivo di GPU disponibili.

Verificare che il server sia stato avviato prima di inviargli traffico reale:

curl http://127.0.0.1:30000/v1/models

Un server operativo risponde con un oggetto JSON che contiene l'ID del modello. Connection refused indica che il processo sta ancora caricando i pesi oppure è già terminato; consultare quindi il log del server prima di riprovare.

Il problema più comune il primo giorno è usare un runtime più vecchio del modello. K3 è stato rilasciato con KDA e un nuovo livello MoE che le versioni stabili di vLLM e SGLang non includevano al momento del rilascio. Il sintomo è l'uscita del server durante l'avvio, con una riga del tipo Model architectures [...] are not supported for now. Nessuna modifica alla configurazione può risolvere il problema, perché il codice necessario per eseguire questi livelli non è presente nella build. Installare la nightly indicata nella scheda del modello oppure attendere la release che la includa.

Un dettaglio sui costi spesso trascurato: il conteggio inizia quando viene avviata l'istanza, non quando il modello è pronto. Un download da 1.5 TB a 1 GB/s richiede circa 25 minuti di tempo del cluster prima del primo token. Preparare i pesi su un volume che resti disponibile oltre la durata dell'istanza, così il secondo avvio richiederà pochi minuti.

Livello 2: eseguire un modello più piccolo su un solo acceleratore

In questo livello non esegui K3. Dillo esplicitamente prima di iniziare, perché la maggior parte delle discussioni su «eseguire K3 localmente» finisce qui senza ammetterlo.

La regola di compatibilità è la stessa formula, in scala ridotta: il numero di parametri moltiplicato per i byte per peso, più la KV cache e circa 2 GB di overhead del runtime, deve rientrare nella VRAM disponibile. Con 4-bit si considera circa mezzo byte per parametro. Questo consente abbinamenti adeguati:

• Scheda da 16 GB: modello 7B a 4-bit, con spazio per un contesto lungo
• Scheda da 24 GB: modello 14B a 4-bit
• Scheda da 48 GB: modello 32B a 4-bit
• Scheda da 80 GB: modello 70B a 4-bit oppure un modello MoE della classe 30B a 8-bit

Ollama è il percorso più rapido per ottenere un server funzionante su un VPS con una GPU collegata:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama run scarica il modello al primo utilizzo, quindi mostra un prompt. Se un tag non esiste, restituisce Error: model "..." not found. Copia quindi i tag dalla pagina della libreria invece di digitarli a memoria. La procedura completa, inclusi l'unità systemd e l'accesso remoto, è disponibile in eseguire Ollama su un VPS.

llama.cpp offre un controllo maggiore sulla quantizzazione e sull'offload:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

-ngl 99 richiede di caricare ogni layer sulla GPU. Controlla il log di caricamento: indica quanti layer sono stati sottoposti a offload. I layer che finiscono nella RAM di sistema vengono eseguiti alla velocità della RAM anziché a quella della HBM. Di conseguenza, la velocità di generazione diminuisce di un ordine di grandezza non appena il modello non rientra più nella memoria disponibile. I compromessi tra i due strumenti sono descritti in Ollama e llama.cpp a confronto.

Livello 3: API gestita, orchestrazione self-hosted

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

L'endpoint è compatibile con OpenAI, quindi un client esistente funziona dopo aver modificato l'URL di base.

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

Una chiave valida restituisce un oggetto JSON con un array choices. Un 401 indica che la chiave è errata oppure che manca il prefisso Bearer. Un errore di modello non trovato indica di norma che l'ID è cambiato, perché i provider ritirano gli ID tra un checkpoint e l'altro.

Passiamo ora al punto di pareggio, usando la tariffa di noleggio indicata sopra. Un nodo con 8 GPU sempre attivo costa 14,400 USD al mese e, al prezzo di 15.00 USD per milione di token di output, con la stessa cifra si acquistano circa 960 milioni di token di output tramite l'API. Per ottenere un vantaggio economico devi generare quasi un miliardo di token di output al mese, circa 30 milioni al giorno, e mantenere il cluster occupato per tutto il tempo, perché le GPU inattive vengono fatturate alla stessa tariffa di quelle occupate. I carichi di lavoro degli agenti con molti prompt spostano ulteriormente il punto di pareggio: il contesto ripetuto viene fatturato alla tariffa cache-hit di 0.30 USD per milione, non a quella cache-miss di 3.00 USD.

In questo livello, ciò che gestisci in proprio è tutto ciò che circonda il modello: un gateway che conserva la chiave API in modo che non raggiunga mai un client, i log delle richieste e delle risposte, i retry, i limiti di frequenza e i budget per utente. Tutto questo può essere eseguito su un piccolo VPS senza GPU. La stessa separazione vale per i pesi chiusi: l'hosting autonomo di Claude non è possibile a livello di modello e l'orchestrazione è l'unica parte sotto il tuo controllo.

Quale stack di serving appartiene a ciascun livello

I server della classe vLLM e SGLang appartengono al livello 1. Sono progettati per gestire molte richieste contemporaneamente, con continuous batching e una paged KV cache, oltre a tensor parallelism ed expert parallelism distribuiti su più nodi. Presuppongono acceleratori da datacenter e un'interconnessione veloce tra questi ultimi. Su una singola scheda consumer sono più complessi da installare e offrono pochi vantaggi concretamente percepibili.

llama.cpp e Ollama appartengono al livello 2. Sono destinati a una sola macchina, alla quantizzazione GGUF, all'offload sulla CPU quando il modello non entra nella memoria disponibile e a una concorrenza ridotta. llama.cpp riesce tecnicamente a caricare un MoE di dimensioni enormi mantenendo la maggior parte dei layer nella RAM di sistema, ma con un modello da 2.8T questo percorso richiede diversi secondi per token. Dimostra che il file viene analizzato correttamente. Non è un servizio su cui far lavorare gli utenti. Il confronto completo è disponibile in Ollama rispetto a vLLM e non cambia in base al modello: la domanda è sempre se si devono servire molti utenti su hardware condiviso oppure un solo utente sulla propria macchina.

I quattro numeri che restano validi oltre questo checkpoint

1. Il numero totale di parametri moltiplicato per i byte per peso determina il limite minimo della memoria. Nessun modello può funzionare al di sotto di questo limite e, quando una release è già a 4 bit, nessun trucco di quantizzazione lo riduce in misura significativa.
2. Il numero di parametri attivi determina la classe di throughput. Un modello MoE da 2.8T con 104B parametri attivi esegue i calcoli come un modello da 104B.
3. La cache KV per token, moltiplicata per la lunghezza del contesto e per la concorrenza, rappresenta il costo che continua a crescere dopo che la memoria per i pesi è già stata allocata.
4. I token al secondo per dollaro sono l'unico numero che determina il tier. Tutto il resto serve a calcolarlo.

Applica questi quattro criteri a qualsiasi release e otterrai la risposta corretta prima ancora di aprire la documentazione del fornitore. Indica sempre la data di ogni valore riportato. I prezzi e gli elenchi delle architetture supportate sono cambiati nelle due settimane successive al lancio di K3, e tutti i numeri riportati in questa pagina sono stati pubblicati a luglio 2026.

FAQ

Posso eseguire Kimi K3 su una singola GPU?

No. I pesi occupano circa 1.4 TB alla precisione MXFP4 distribuita da Moonshot e il più grande acceleratore disponibile sul mercato ha 288 GB. Un modello MoE non può caricare in streaming gli esperti inattivi dal disco a una velocità utilizzabile, perché il router può selezionare qualsiasi esperto per qualsiasi token e un trasferimento tramite PCIe richiede molto più tempo di quello disponibile per elaborare il token. La configurazione minima sensata per K3 è un nodo con più GPU; le ricette pubblicate usano almeno 32 acceleratori.

Quanta VRAM richiede Kimi K3?

Considera almeno 1.4 TB per i soli pesi: equivalgono a 18 schede H100 da 80GB oppure a 5 schede della classe GB300. Devi poi aggiungere la memoria della KV cache e delle attivazioni. Ad agosto 2026 Moonshot raccomanda almeno 64 acceleratori, mentre il cookbook di SGLang pubblica una configurazione con 32 GPU H100 e 2,560 GB complessivi. Considera quindi la dimensione dei pesi come un valore minimo, non come un requisito sufficiente.

La quantizzazione consente di eseguire Kimi K3 su un solo nodo?

Non in modo utile. Il checkpoint distribuito è già a 4 bit e usa un addestramento consapevole della quantizzazione, quindi il risparmio più semplice è già stato ottenuto. Una riduzione ulteriore a 2 bit porta i pesi a 0.7 TB, ancora più del doppio rispetto alla scheda più capiente; inoltre, il costo in termini di accuratezza dei 2 bit non è stato misurato su questo modello.

Noleggiare GPU costa meno dell'API di Kimi K3?

Solo con un volume elevato e costante. Ipotizzando un costo di 2.50 USD per GPU all'ora, un nodo sempre attivo con 8 GPU costa 14,400 USD al mese. Con la stessa cifra puoi acquistare circa 960 milioni di token di output alla tariffa pubblicata di 15.00 USD per milione di token. Devi inoltre pagare le ore di inattività, il download dei pesi e la persona che mantiene operativo il cluster. Noleggia le GPU a ore per i carichi intermittenti e confronta il costo con il volume di token misurato nel tuo ambiente, non con una stima.

Che cosa significa avere 104B parametri attivi per la velocità?

Significa che il calcolo richiesto per ogni token è quello di un modello da 104B parametri. Il throughput rientra quindi in quella classe, non in quella da 2.8T parametri. Questo dato non indica il fabbisogno di memoria: tutti i 2.8T parametri restano residenti, perché il router può chiamare qualsiasi esperto per qualsiasi token. Usa il numero di parametri attivi per stimare i token al secondo e il numero totale di parametri per dimensionare la VRAM.