Self-hostare Kimi K3: VRAM, costi e opzioni reali

Cosa serve per self-hostare Kimi K3

Il self-hosting di Kimi K3 richiede spazio per 2.8 trilioni di parametri. Moonshot ha pubblicato i pesi in formato 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 oggi disponibile sul mercato può contenere da solo una quantità simile. K3 è un modello multi-nodo. Per un singolo server, quindi, la risposta è no.

Questa è la conclusione. Tutto ciò che segue mostra i calcoli alla base, perché questi calcoli possono essere riutilizzati per la prossima release. Nelle settimane successive all'annuncio del 17 July 2026, diversi fornitori di infrastruttura hanno pubblicato guide per il deployment di K3, dando per scontato che disponessi già di un cluster. Questa pagina parte dal punto opposto: quanto costa, cosa puoi eseguire in alternativa e come capire in quale delle due situazioni ti trovi.

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

K3 è un modello mixture of experts. Un modello 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 parametri totali e 104B parametri attivati per token, su 896 esperti instradati, di cui 16 vengono attivati per ogni token, distribuiti su 93 layer.

Questi due conteggi dei parametri rispondono a domande diverse. Confonderli è l'errore più comune nelle discussioni del tipo "posso eseguire questo modello?".

I parametri attivi determinano il costo computazionale. Per ogni token vengono elaborati circa 104B parametri. Le prestazioni attese sono quindi simili a quelle di un modello denso da 104B parametri, non da 2.8T. Questo è il motivo principale per cui si usa un'architettura MoE.

I parametri totali determinano il costo in 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 parametri nella VRAM e recuperare gli altri quando servono: il trasferimento dovrebbe completarsi in pochi microsecondi, mentre un collegamento PCIe trasferisce decine di gigabyte al secondo. Alcuni provano comunque a farlo. Trasmettere gli esperti da NVMe trasforma un modello che dovrebbe generare decine di token al secondo in un modello che genera un token ogni pochi secondi.

In sintesi, il calcolo è economico, mentre la memorizzazione è costosa. Dimensionare l'hardware in base a 2.8T. Stimare la velocità in base a 104B.

Byte per peso e origine dei 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 con consapevolezza della quantizzazione e distribuito con pesi MXFP4 e attivazioni MXFP8, quindi la riga a 4 bit è quella reale. Le righe precedenti servono come riferimento: con 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, invece di 1.4 TB netti.

Questo elimina la consueta via d'uscita. «Basta quantizzarlo» non aiuta, perché il checkpoint distribuito è già a 4 bit. Scendere a 2 bit porterebbe i pesi a 0.7 TB e comporterebbe una perdita di accuratezza che nessuno ha misurato su questo checkpoint. Anche in questo caso si supererebbe di molto 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 expert non consentono sempre.

Le indicazioni pubblicate sono molto superiori a questo minimo. Ad agosto 2026 Moonshot raccomanda un supernode con almeno 64 acceleratori, mentre il cookbook di SGLang include una configurazione H100 composta da quattro nodi con 8 GPU ciascuno, per un totale di 32 GPU e 2,560 GB di memoria aggregata, rispetto a un minimo di 18 schede. Questa differenza non rappresenta uno spreco. Serve per la cache KV, la memoria delle attivazioni e il margine necessario per consentire al server di elaborare molte richieste in batch contemporaneamente. Anche la riga 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 di nuovo per 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 calcolato, 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 completo di un milione di token richiede 128 GiB, una quantità superiore alla memoria di qualsiasi singola scheda, per una sola conversazione.

K3 non usa l’attenzione ordinaria, e quell’ultimo numero 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 basso rango. Il costo reale per token è quindi molto inferiore a quello dell’esempio calcolato. 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 valore --max-model-len ridotto, monitora la memoria con nvidia-smi, quindi aumenta il limite finché l’allocazione non fallisce.

Il principio resta valido anche per la 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: noleggia il cluster a ore

Questo è l'unico livello che esegue direttamente K3. Non acquisti l'hardware. Lo noleggi per le ore necessarie e lo arresti 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. Fino al 2026, i prezzi on-demand dei dispositivi di accelerazione nei data center sono rimasti indicativamente tra 2 e 5 USD per GPU/ora, mentre la capacità riservata costa meno. Usa il valore reale del tuo provider e ripeti il calcolo: numero di GPU per ore per tariffa. Il grafico serve a mostrare il rapporto. Eseguire un nodo con 8 GPU per quattro ore al giorno costa 2,400 USD al mese, mentre lasciare in esecuzione la configurazione da 32 GPU dimensionata per SGLang 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 da solo, è quello da eseguire in un cluster reale. Aggiungi i flag di parallelismo corrispondenti al tuo 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.

Verifica che il server sia avviato prima di inviargli traffico reale:

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

Un server funzionante 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; consulta 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 con un nuovo livello MoE che le release stabili di vLLM e SGLang non includevano al momento del lancio. Il sintomo è l'arresto 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. Installa la nightly indicata nella scheda del modello oppure attendi la release che la includa.

Un'ultima considerazione sui costi. Il contatore parte quando viene avviata l'istanza, non quando il modello è pronto. Il download di 1.5 TB a 1 GB/s richiede circa 25 minuti di tempo del cluster prima che venga generato il primo token. Prepara 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 singolo acceleratore

A questo livello non esegui K3. Dillo esplicitamente prima di iniziare, perché la maggior parte delle discussioni su «eseguire K3 in locale» termina 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 di runtime, deve rientrare nella VRAM disponibile. Con 4-bit si considera circa mezzo byte per parametro, ottenendo abbinamenti adeguati:

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

Ogni abbinamento precedente presuppone una sola richiesta alla volta. Quando una seconda persona invia un prompt, ogni slot concorrente richiede una propria KV cache. Questa è la scelta che le impostazioni NUM_PARALLEL e MAX_QUEUE di Ollama applicano tra slot paralleli, richieste accodate e VRAM ancora disponibile.

Ollama è il percorso più breve 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. Un tag inesistente restituisce Error: model "..." not found, quindi copia 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 che ogni livello venga caricato sulla GPU. Controlla il log di caricamento: indica quanti livelli sono stati scaricati sulla GPU. I livelli che passano nella RAM di sistema vengono eseguiti alla larghezza di banda della RAM anziché a quella della HBM, quindi 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 ospitata, 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 funzionante restituisce un oggetto JSON con un array choices. Un 401 indica che la chiave è errata oppure che manca il prefisso Bearer. Un errore relativo a un modello non trovato indica in genere che l'ID è cambiato, perché i provider ritirano gli ID tra un checkpoint e l'altro.

Consideriamo ora il punto di pareggio, usando la tariffa di noleggio ipotizzata 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 API. Per ottenere un risparmio devi generare quasi un miliardo di token di output al mese, cioè 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 molto contenuto nel prompt spostano ulteriormente il punto di pareggio: il contesto ripetuto viene fatturato alla tariffa di 0.30 USD per milione in caso di cache hit, non alla tariffa di 3.00 USD in caso di cache miss.

In questo livello, ciò che gestisci in modalità self-hosted è tutto ciò che circonda il modello: un gateway che conserva la chiave API affinché non raggiunga mai un client, i log delle richieste e delle risposte, i tentativi ripetuti, i limiti di frequenza e i budget per utente. Questo componente viene eseguito su un VPS di piccole dimensioni, senza alcuna GPU. La stessa suddivisione vale per i pesi proprietari: l'hosting autonomo di Claude non è possibile a livello di modello e l'orchestrazione è l'unica parte sotto il tuo controllo.

A quale livello appartiene ciascuno stack di serving

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 al parallelismo tensoriale e al parallelismo degli expert 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 concreti.

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

I quattro numeri che restano validi oltre questo punto di controllo

1. Il numero totale di parametri moltiplicato per i byte per peso determina il limite minimo di memoria. Nessun modello può funzionare al di sotto di questo limite e, una volta che la release è già a 4 bit, nessun metodo di quantizzazione lo riduce in misura significativa.
2. I parametri attivi determinano la classe di throughput. Un modello MoE da 2.8T con 104B di 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 aver allocato la memoria per i pesi.
4. I token al secondo per dollaro sono l'unico valore che determina il tier. Tutto il resto serve a calcolarlo.

Applica questi quattro criteri a qualsiasi release per ottenere la risposta corretta prima di consultare la documentazione del vendor. 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 valori riportati in questa pagina sono stati pubblicati a luglio 2026.

FAQ

È possibile eseguire Kimi K3 su una singola GPU?

No. I pesi occupano circa 1.4 TB con la precisione MXFP4 distribuita da Moonshot, mentre il più grande acceleratore singolo disponibile ha 288 GB. Un modello MoE non può caricare da disco gli esperti inattivi a una velocità utilizzabile, perché il router può selezionare qualsiasi esperto per qualsiasi token e il recupero tramite PCIe richiederebbe molto più tempo di quello disponibile per elaborare il token. La configurazione minima sensata per Kimi K3 è un nodo con più GPU; le configurazioni pubblicate usano 32 acceleratori o più.

Quanta VRAM richiede Kimi K3?

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

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

Non in modo utile. Il checkpoint distribuito è già a 4 bit e usa il quantisation-aware training, quindi il principale risparmio facilmente ottenibile è già incluso. Ridurre nuovamente a 2 bit porta i pesi a 0.7 TB, una quantità comunque più che doppia rispetto alla scheda più grande. Inoltre, il costo in termini di accuratezza della rappresentazione a 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/ora, un nodo con 8 GPU sempre acceso costa 14,400 USD al mese. Con la stessa somma 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 i costi 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 per token è quello di un modello da 104B, quindi il throughput rientra in questa classe e non in quella da 2.8T. Questo non indica il fabbisogno di memoria: tutti i 2.8T parametri restano residenti, perché il router può richiamare 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.