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

Cosa serve per eseguire Kimi K3 in self-hosting

Eseguire Kimi K3 in self-hosting significa trovare spazio per 2.8 mila miliardi di parametri. Moonshot ha pubblicato i pesi open in formato MXFP4, che occupa circa mezzo byte per peso; pertanto i soli pesi ammontano a 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. Con una GPU la risposta è no. Con un server la risposta è sì, in due configurazioni. La prima è un nodo con 8 acceleratori da 288 GB, che corrisponde alle ricette pubblicate più compatte per il serving multiutente. La seconda è una singola macchina con circa 1.6 TB complessivi tra RAM e VRAM, che esegue il GGUF Q8 lossless di Unsloth in llama.cpp, con o senza una GPU, servendo un utente alla volta.

Questa è la conclusione. Tutto ciò che segue mostra i calcoli alla base, perché sono la parte che puoi riutilizzare per la versione successiva. Nelle settimane successive all'annuncio del 16 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 dall'altra direzione: quanto costa, cosa puoi eseguire in alternativa e come stabilire in quale delle due configurazioni rientri.

Il numero totale di parametri 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 parametri totali e 104B parametri attivati per token, su 896 esperti instradati, di cui 16 vengono attivati per ogni token, distribuiti su 93 layer.

I due conteggi dei parametri rispondono a domande diverse. Confonderli è 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 parametri. Di conseguenza, il throughput atteso è simile a quello di un modello denso da 104B parametri, non a quello di un modello da 2.8T. Questo è il motivo principale per cui si utilizza un'architettura MoE.

I parametri totali determinano il costo in memoria. Il router può selezionare qualsiasi esperto per qualsiasi token. Per questo motivo, tutti gli esperti devono essere archiviati in una memoria sufficientemente veloce prima dell'arrivo della prima richiesta. È possibile mantenere in VRAM soltanto gli esperti utilizzati più spesso e caricare gli altri quando servono: llama.cpp con --moe-cache-mib mantiene una cache degli esperti sulla GPU, mentre gli esperti rimanenti risiedono nella RAM di sistema e vengono caricati quando il router li seleziona. Questo, però, non riduce le dimensioni complessive del modello. Gli altri esperti devono comunque risiedere nella RAM e un collegamento PCIe trasferisce decine di gigabyte al secondo, contro i terabyte al secondo della HBM. Di conseguenza, ogni cache miss aggiunge latenza. Se il modello non entra nemmeno nella RAM e gli esperti devono essere caricati da NVMe, le prestazioni peggiorano ulteriormente. La guida di Unsloth per K3 avverte infatti che l'offload su disco è molto più lento.

Il modello è quindi economico da elaborare, ma costoso da archiviare. Dimensiona l'hardware in base a 2.8T. Definisci le aspettative sulla velocità in base a 104B.

Byte per peso e origine dei terabyte

Numero di parametri moltiplicato per i byte per peso. Per i pesi, questa è l'intera formula.

[
  {
    "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 ed è stato rilasciato con pesi MXFP4 e attivazioni MXFP8, quindi la riga a 4 bit è quella effettiva. 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, con un overhead di circa 6 percento, mentre la configurazione di Moonshot esclude dal formato a 4 bit i livelli di attenzione, gli esperti condivisi e il vision tower. Per questo il checkpoint completo arriva a circa 1.56 TB secondo il conteggio di Unsloth, invece di 1.4 TB esatti.

Questo riduce il consueto margine di riduzione, ma non lo elimina. Il checkpoint rilasciato è già a 4 bit, quindi il risparmio più semplice è già stato ottenuto; tuttavia, scendere ulteriormente riduce ancora il valore. Al 27 ottobre 2026, le quantizzazioni dinamiche GGUF di K3 misurate da Unsloth vanno da 861.3 GB per UD-Q2_K_XL a 594 GB per UD-IQ1_S. Unsloth pubblica anche il relativo costo: l'accordo top-1 dei token con il modello completo è pari a 90.390 percento per UD-Q2_K_XL, 84.127 percento per UD-IQ2_XXS da 711.1 GB e 78.875 percento per UD-IQ1_S. Il repository Hugging Face contiene anche file 1-bit più piccoli, fino a 466 GB per UD-Q1_0, ma senza una percentuale di accordo pubblicata. Si tratta di una perdita di accuratezza misurata e anche il file più piccolo occupa ancora circa 1.6 volte la capacità della scheda singola più grande.

Quante GPU servono a 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
  }
]

Considerali come un limite minimo, non come un obiettivo. Contano solo i pesi: non includono la cache KV, i buffer delle attivazioni, la frammentazione dell'allocator né lo spazio per una seconda richiesta simultanea. La suddivisione non deve essere necessariamente uniforme: il pipeline parallelism di vLLM suddivide il modello per layer e supporta suddivisioni non uniformi, mentre le ricette di prefill di K3 per SGLang eseguono 8 e 16 pipeline stage su 93 layer.

Le indicazioni pubblicate prevedono valori superiori al minimo. Le indicazioni di lancio di Moonshot raccomandavano un supernodo con almeno 64 acceleratori. Al 27 ottobre 2026, il cookbook di SGLang include una configurazione H100 composta da quattro nodi 8-GPU, per un totale di 32 GPU e 2,560 GB di memoria aggregata, rispetto a un minimo di 18 schede; include inoltre ricette per un singolo nodo con un nodo B300 8-GPU e un nodo MI350X o MI355X 8-GPU, con 2,304 GB a 288 GB per scheda. Questa differenza rispetto al minimo non è uno spreco. Serve per la cache KV, la memoria delle attivazioni e il margine necessario al server per elaborare molte richieste in batch contemporaneamente. La configurazione più accessibile, con 5 schede di classe GB300, richiede in pratica esattamente questo tipo di nodo 8-GPU, che è la macchina più piccola per la quale sia stata pubblicata una ricetta di serving multiutente per K3.

La cache KV è la parte che sorprende

I pesi rappresentano un costo fisso. La cache KV (key-value) non lo è: cresce con la lunghezza del contesto e aumenta di nuovo con ogni utente simultaneo. Per l'attenzione ordinaria la formula è bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element; poi 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 calcolo è 2 64 8 128 1 = 131,072 byte, quindi 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 contesto di 128k richiede 16 GiB. Un utente con il milione completo richiede 128 GiB: quasi metà di una scheda da 288 GB per una sola conversazione, prima ancora di caricare un solo peso.

K3 non usa l'attenzione ordinaria, e quel valore finale 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 con 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. Il file config.json pubblicato da Moonshot indica una dimensione latente pari a kv_lora_rank di 512, oltre a una key rotazionale ampia 64 (qk_rope_head_dim), per un totale di 576 valori per token per ogni layer MLA. Su 24 layer, con 2 byte per valore, il risultato è 27,648 byte, circa 27 KiB per token, ovvero all'incirca 27 GiB per una conversazione completa di 1,048,576 token, oltre allo stato KDA fisso. Consideralo una stima, non una misurazione: i motori applicano padding e organizzano la cache secondo modalità proprie, mentre una cache a 8 bit ne riduce approssimativamente della metà le dimensioni.

Per verificare la quantità utilizzata dalla tua distribuzione, non monitorare nvidia-smi mentre aumenti --max-model-len. vLLM alloca in anticipo il proprio pool di cache KV, dimensionato in base a --gpu-memory-utilization (0.92 per impostazione predefinita nella documentazione corrente) oppure a un limite esplicito della cache per GPU. Per questo la memoria GPU totale mostra il pool, non una singola conversazione. Leggi invece il log di avvio: vLLM indica la dimensione della cache KV in token e la concorrenza massima alla lunghezza di contesto specificata.

La struttura del ragionamento resta valida anche nella prossima release. Se un modello dichiara un contesto di un milione di token e non fornisce informazioni sul design dell'attenzione, considera la cache il vincolo principale finché non viene dimostrato il contrario.

Tier 1: affittare il cluster a ore

Questo è il livello che serve K3 alla precisione distribuita con il modello a molti utenti contemporaneamente. Una macchina con RAM sufficiente può contenere K3 anche alla precisione rilasciata tramite il Q8 GGUF di Unsloth, che Unsloth definisce full precision lossless, ma questa modalità serve un utente alla volta ed è descritta nel tier 2. In questo caso non si acquista l'hardware. Lo si affitta 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. Le tariffe on-demand variano notevolmente in base al provider e alla generazione delle GPU; i componenti da 288 GB necessari per le configurazioni a nodo singolo costano più all'ora di un H100, mentre la capacità riservata è più economica. Usare il valore reale del provider e ripetere il calcolo: GPU per ore per tariffa. Il grafico serve a mostrare il rapporto. Attivare un nodo con 8 GPU per quattro ore al giorno costa 2,400 USD al mese, mentre lasciare in esecuzione la configurazione SGLang con 32 GPU H100 costa 57,600 USD.

Entrambi i server principali pubblicano un comando di avvio nella model card.

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 di base è quello da usare in un cluster reale. Aggiungere i flag di parallelismo corrispondenti all'hardware: SGLang usa --tp-size per il tensor parallel, --pp-size per il pipeline parallel e --ep-size per l'expert parallel. Il tensor parallel moltiplicato per il pipeline parallel deve essere uguale al numero effettivo di GPU disponibili; l'expert parallel suddivide gli esperti all'interno di quel gruppo. Per questo la ricetta per 32 GPU H100 imposta sia --tp-size 32 sia --ep-size 32.

Verificare che il server sia attivo 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; leggere quindi il log del server prima di riprovare.

Nelle prime settimane, il problema più comune era usare un runtime più vecchio del modello. K3 è stato rilasciato con KDA e un nuovo livello MoE che le release stabili di vLLM e SGLang non includevano al momento del lancio. Il sintomo è l'uscita del server durante l'avvio con una riga nella forma Model architectures [...] are not supported for now. Nessuna modifica alla configurazione risolve il problema, perché il codice necessario per eseguire questi livelli non è presente nella build. Da allora la situazione è cambiata: al 27 ottobre 2026 SGLang include il supporto per K3 nelle proprie release dalla v0.5.17, con la v0.5.22 come versione più recente, e le note di rilascio di vLLM dalla v0.28.0 alla v0.32.0 includono tutte attività relative a K3. Installare una release aggiornata. Alcuni percorsi specifici per l'hardware indicano ancora un'immagine dedicata, ad esempio le build NVFP4 di SGLang su Blackwell; controllare quindi la ricetta per la propria scheda.

Un aspetto dei costi può trarre in inganno. Il conteggio inizia quando viene avviata l'istanza, non quando il modello è pronto. Un download di 1.56 TB a 1 GB/s richiede circa 26 minuti di tempo del cluster prima del primo token. Preparare i pesi su un volume che rimanga disponibile oltre la durata dell'istanza, così la seconda esecuzione può iniziare in pochi minuti.

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

In questo tier non esegui K3. Dillo esplicitamente prima di iniziare, perché la maggior parte delle discussioni su "eseguire K3 localmente" si ferma qui senza ammetterlo.

La regola di compatibilità è la stessa formula, su scala ridotta: parametri moltiplicati per byte per peso, più la KV cache, più circa 2 GB di overhead di runtime, devono rientrare nella VRAM. A 4-bit si tratta all'incirca di mezzo byte per parametro, con questi 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

Ogni abbinamento precedente presuppone una richiesta alla volta. Quando una seconda persona invia un prompt, ogni slot concorrente richiede la propria KV cache. Le impostazioni NUM_PARALLEL e MAX_QUEUE di Ollama gestiscono proprio il compromesso tra slot paralleli, richieste in coda e VRAM ancora disponibile.

Esiste un modo per eseguire K3 stesso su una singola macchina di grandi dimensioni, a metà tra questo tier e l'ultimo. Unsloth documenta build GGUF di K3 in llama.cpp, dalle quantizzazioni a 1-bit e 2-bit fino a UD-Q8_K_XL, che definisce lossless a precisione completa, e indica una NVIDIA DGX Station come hardware in grado di eseguirle. La sua regola pratica è avere RAM più VRAM approssimativamente pari alla dimensione della quantizzazione: da circa 610 GB per la build UD-IQ1_S a 1-bit fino a circa 1.6 TB per la Q8. Al di sotto di questa soglia, il modello ricorre al disco e rallenta notevolmente. Una GPU è opzionale: le istruzioni di build di Unsloth disattivano CUDA con la formula "se non hai una GPU o vuoi semplicemente eseguire l'inferenza su CPU". Le build a 1-bit e 2-bit sono versioni di K3 fortemente quantizzate, con il costo in termini di accuratezza descritto sopra. La build Q8 è K3 alla precisione con cui è stato rilasciato, servito a un solo utente alla velocità della RAM. Nessuna delle due è un modello più piccolo.

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. Copia quindi i tag dalla pagina della libreria invece di digitarli a memoria. La procedura completa, inclusa 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 layer venga caricato sulla GPU. Leggi il log del caricamento: indica quanti layer sono stati sottoposti a offload. I layer che finiscono nella RAM di sistema vengono eseguiti alla larghezza di banda 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.

Tier 3: API hosted, 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 l'autenticazione non è riuscita: verificare che la chiave sia corretta, non sia scaduta né disabilitata e che l'header contenga Authorization: Bearer seguito dalla chiave. Un errore di modello non trovato indica in genere che l'id è cambiato, perché i provider ritirano gli id tra un checkpoint e l'altro.

Passiamo al 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, 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 prompt pesanti spostano ulteriormente il punto di pareggio: il contesto ripetuto viene fatturato alla tariffa cache-hit di 0.30 USD per milione, anziché alla tariffa cache-miss di 3.00 USD.

In questo tier, ciò che gestisci in self-hosting è 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 rate limit e i budget per utente. Questo componente viene eseguito su un piccolo VPS senza alcuna GPU. La stessa separazione vale per i pesi chiusi: il self-hosting di Claude non è possibile a livello di modello e l'orchestrazione è l'unica parte che gestisci.

Quale stack di serving corrisponde 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 paged KV cache, oltre a tensor parallelism ed expert parallelism distribuiti su più nodi. Presuppongono acceleratori da datacenter e un'interconnessione veloce tra questi dispositivi. Su una singola scheda consumer sono più complessi da installare e offrono vantaggi difficili da percepire.

llama.cpp e Ollama appartengono al livello 2. Sono pensati per una sola macchina, per la quantizzazione GGUF, per l'offload sulla CPU quando il modello non entra nella memoria disponibile e per una concorrenza ridotta. llama.cpp può caricare un MoE enorme mantenendo i pesi degli esperti nella RAM di sistema (--cpu-moe o --n-cpu-moe) e, con --moe-cache-mib, memorizzando nella cache sulla GPU gli esperti utilizzati; è così che vengono eseguite su una singola macchina le build K3 GGUF di Unsloth. Le prestazioni dipendono quindi dalla larghezza di banda della RAM e dalla frequenza con cui il router non trova gli esperti nella cache; se il file è più grande della RAM più la VRAM, i dati passano sul disco. È una configurazione utilizzabile da un singolo utente. Non è un servizio adatto a molti utenti. Il confronto completo è disponibile in Ollama e 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 checkpoint

1. Il numero totale di parametri moltiplicato per i byte per peso determina il limite minimo di memoria. Nulla può funzionare al di sotto di questo limite alla precisione di rilascio, e quantizzare al di sotto di una release a 4 bit consente di risparmiare fino a circa 70 percento, con un costo in termini di accuratezza, non di un ordine di grandezza.
2. I parametri attivi determinano la classe di throughput. Un MoE da 2.8T con 104B parametri attivi esegue calcoli come un modello da 104B.
3. La cache KV per token, moltiplicata per la lunghezza del contesto e per la concorrenza, è il costo che continua a crescere dopo che sono stati allocati i pesi.
4. I token al secondo per dollaro sono l'unico numero che consente di scegliere un tier. Tutto il resto serve a calcolarlo.

Applicando questi quattro valori a qualsiasi release, si ottiene la risposta corretta prima ancora di aprire la guida del vendor. La prossima release è già stata annunciata: Moonshot ha rilasciato K3.1 Pro, basato su K3 con ulteriore post-training, in Kimi Code il 23 October 2026, e il quickstart della relativa API indica che i pesi completi saranno rilasciati entro il 4 November. Indica quindi sempre la data di ogni valore annotato. I prezzi e gli elenchi delle architetture supportate sono cambiati entrambi nelle due settimane successive al lancio di K3. I valori del lancio riportati in questa pagina sono stati pubblicati a July 2026, mentre le configurazioni di serving, le release dei runtime e i valori di quantizzazione sono stati ricontrollati il 27 October 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 anche la più piccola quantizzazione pubblicata di K3, il file UD-Q1_0 da 466 GB di Unsloth, è circa 1.6 volte la capacità di 288 GB dei più grandi acceleratori ampiamente disponibili. llama.cpp può mantenere gli esperti nella RAM di sistema e memorizzare nella cache sulla GPU quelli attivi, ma questo richiede comunque all'incirca la dimensione della quantizzazione complessivamente tra RAM e VRAM; al di sotto di tale quantità, il modello passa al disco e funziona molto più lentamente. Le ricette di serving più compatte pubblicate usano un nodo con 8 GPU B300 o MI350X/MI355X, mentre la ricetta per H100 ne usa 32.

Quanta VRAM richiede Kimi K3?

Si parte da 1.4 TB per i soli pesi, ovvero 18 schede H100 da 80GB oppure 5 schede della classe GB300. A questo si aggiungono la cache KV e la memoria per le attivazioni. Le indicazioni di lancio di Moonshot raccomandavano 64 o più acceleratori. Al 27 ottobre 2026, il ricettario di SGLang pubblica ricette per un singolo nodo con 8 schede B300 oppure 8 schede MI350X/MI355X, per un totale di 2,304 GB, e una configurazione H100 con 32 GPU e 2,560 GB complessivi; considera quindi la quantità dei pesi un valore minimo, non un requisito sufficiente.

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

Il checkpoint a 4 bit distribuito con il modello entra già in un singolo nodo se quel nodo dispone di otto schede da 288 GB, come nelle ricette di SGLang per B300 e MI355X, e in una singola macchina con circa 1.6 TB complessivi tra RAM e VRAM tramite il GGUF Q8 lossless di Unsloth. Scendere ulteriormente aiuta le macchine più piccole: le build GGUF dinamiche misurate da Unsloth vanno da 861.3 GB a 2 bit a 594 GB a 1 bit, mentre il relativo repository elenca file a 1 bit fino a 466 GB, rispetto a circa 1.56 TB senza perdita. Il costo in termini di accuratezza è stato misurato: l'accordo top-1 con il modello completo scende al 90.390 percento con UD-Q2_K_XL e al 78.875 percento con UD-IQ1_S. Nessuno di questi file entra in una singola scheda.

Noleggiare GPU costa meno dell'API di Kimi K3?

Solo con un volume elevato e costante. Ipotizzando un costo di 2.50 USD per ora e per GPU, un nodo sempre attivo con 8 GPU costa 14,400 USD al mese, mentre la stessa cifra consente di acquistare circa 960 milioni di token di output al prezzo pubblicato di 15.00 USD per milione. Devi inoltre pagare le ore di inattività, il download dei pesi e la persona che mantiene operativo il cluster. Per i carichi intermittenti, noleggia le GPU a ore e confronta il costo con il volume di token misurato sul tuo sistema, non con una stima.

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

Significa che il calcolo per token è quello di un modello da 104B, quindi il throughput rientra in quella classe e non in quella da 2.8 mila miliardi di parametri. Non dice nulla sulla memoria: tutti i 2.8 mila miliardi di parametri restano residenti, perché il router può chiamare qualsiasi esperto per qualsiasi token. Usa il numero di parametri attivi per prevedere i token al secondo e il numero totale per dimensionare la VRAM.