Kimi K2 in locale: 1 trilione di parametri MoE presso soi

#Perché puntare a Kimi K2 in locale

Kimi K2 è il modello principale di Moonshot AI, pubblicato con pesi aperti (Modified MIT) e con un'architettura MoE (Mixture of Experts) composta da 1 trilione di parametri totali e circa 32B esperti per token. Negli standard di ragionamento e di codifica, si colloca tra i modelli di frontiera chiusi, e il suo contesto lungo (annunciato a 128k token) lo rende un candidato serio per l'analisi documentale di grande scala.

Eseguire in locale un modello di queste dimensioni, 18 mesi fa, sembrava un sogno irrealizzabile. Tre evoluzioni hanno cambiato le cose: la diffusione della DDR5 ad alta capacità (192-384 GB per poche centinaia di euro), gli SSD NVMe Gen 4 capaci di raggiungere 7 GB/s in lettura sequenziale e il lavoro del team llama.cpp sulle quantizzazioni molto aggressive come Q2_K_S e IQ1_M.

#Capire il MoE 1T / 32B attivi

L'architettura MoE sostituisce i blocchi FFN densi con uno strato di esperti (spesso 256+) tra i quali un router ne seleziona da 8 a 12 per token. Per il calcolo, vengono elaborati solo i parametri degli esperti selezionati — da qui i circa 32B «attivi». Per la memoria, invece, tutti gli esperti devono essere indirizzabili, altrimenti il router perde l'accesso al 95% del modello.

Parametri totali

≈ 1 000 miliardi (1T). È ciò che rimane in RAM o su disco.

Parametri attivi per token

≈ 32 miliardi. È questo che determina il carico di calcolo e la velocità.

Esperti per layer

Diverse centinaia, verso un numero fisso dei quali viene instradato ogni token (routing top-k).

Strati condivisi (attenzione)

Sempre attive. Sono la componente dominante dell'occupazione di memoria quando il contesto è breve.

Cache KV

Cresce linearmente con il contesto. Con un contesto di 128k, il KV può superare i 30 GB anche se quantizzato.

#Budget di memoria da prevedere

Il calcolo della memoria per un MoE 1T si suddivide in tre voci distinte. Capire questa suddivisione è fondamentale prima di investire in RAM o SSD.

Pesi del modello (quantizzati)

Q2_K_S ≈ 245 GB, Q3_K_S ≈ 320 GB, Q4_K_M ≈ 480 GB, Q8_0 ≈ 1 TB. È la componente che occupa più spazio e la più comprimibile.

Cache KV (contesto)

Calcolare circa 0,25 MB per token in FP16, circa 0,12 MB in Q8. Ovvero 32 GB per 128k token in Q8. Configurabile tramite --cache-type-k/-v.

Buffer di attivazione

Alcuni GB per GPU per i calcoli intermedi. Un consumo marginale, ma da non dimenticare sulle GPU da 24 GB.

#Requisiti hardware

Tre profili di macchine permettono di eseguire Kimi K2 in locale, con compromessi molto diversi sul piano della velocità.

Profilo A — DDR5 potente (192-384 GB RAM)

Workstation Threadripper/Xeon W o piattaforma EPYC. 256 GB DDR5 ECC, nessuna GPU obbligatoria. Il modello entra interamente in RAM in Q2_K_S. Velocità attesa: 4–8 tok/s usando solo la CPU.

Profilo B — DDR5 + 1 GPU da 24 GB

96–128 GB di RAM + RTX 4090/3090. Gli strati condivisi vengono trasferiti sulla GPU, mentre gli esperti restano in RAM. Velocità attesa: 6–12 tok/s, a seconda del numero di esperti che entrano in VRAM.

Profilo C — RAM modesta + SSD NVMe

64-96 GB di RAM + NVMe Gen 4 (7 GB/s in lettura, ≥ 1 TB libero). I pesi vengono mappati in memoria dal SSD tramite mmap. Velocità attesa: 1-3 tok/s, fortemente dipendente dalla velocità di trasferimento effettiva del SSD.

#1. Compilare llama.cpp con il backend corretto

Kimi K2 richiede una versione recente di llama.cpp (build recente dopo dicembre 2025) che supporti la sua architettura MoE e le quantizzazioni IQ. Si compila dal repository ufficiale.

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

Su Mac Apple Silicon, sostituire GGML_CUDA con GGML_METAL. Su AMD con ROCm, GGML_HIP. L'opzione GGML_CUDA_FA_ALL_QUANTS attiva Flash Attention per tutte le quantizzazioni — indispensabile per gestire 128k di contesto senza far esplodere il consumo di VRAM.

#2. Scegliere la quantizzazione GGUF

Per un modello di queste dimensioni, dimentica Q4_K_M e le quantizzazioni a precisione superiore, a meno di avere 512 GB di RAM. La quantizzazione estrema — Q2_K_S, IQ2_XXS, o persino IQ1_M — è ciò che rende praticabile l'esecuzione locale, al prezzo di una perdita di qualità misurabile ma spesso accettabile su un MoE.

Q2_K_S (~245 GB)

Il punto ottimale. Circa il 5 % di calo delle prestazioni nei benchmark di codice, circa il 3 % nel ragionamento. Consigliato se hai 256 GB di RAM o un SSD veloce.

IQ2_XXS (~210 GB)

Ancora più aggressivo grazie alla matrice di importanza. Sta in 192 GB di RAM con un po' di offload. Qualità leggermente inferiore.

IQ1_M (~155 GB)

Quantizzazione ibrida a 1 bit. Per configurazioni con risorse molto limitate. Degrado visibile, ma il modello rimane coerente.

Q3_K_S (~320 GB)

Qualità quasi-Q4 ma richiede 384 GB di RAM. Per workstation EPYC ben equipaggiate.

pip install -U "huggingface_hub[cli]"
huggingface-cli download \
  unsloth/Kimi-K2-Instruct-GGUF \
  --include "*Q2_K_S*" \
  --local-dir ./models/kimi-k2-q2ks

I GGUF di queste dimensioni sono suddivisi in più file (split-00001-of-00007.gguf ecc.). llama.cpp rileva automaticamente le parti se punti al primo file.

#3. Avviare Kimi K2 con mmap e offload

Il comando di base utilizza llama-server, il server HTTP fornito da llama.cpp. Espone un endpoint compatibile con OpenAI sulla porta 8080 per impostazione predefinita.

./build/bin/llama-server \
  --model ./models/kimi-k2-q2ks/kimi-k2-Q2_K_S-00001-of-00007.gguf \
  --ctx-size 32768 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --threads 16 \
  --no-mmap=false \
  --host 0.0.0.0 --port 8080

Con una GPU da 24 GB, si caricano sulla GPU gli strati condivisi (attenzione) e si lasciano gli esperti MoE in RAM o su SSD. Il flag -ot permette di scegliere con precisione cosa viene assegnato alla GPU e cosa alla CPU.

./build/bin/llama-server \
  --model ./models/kimi-k2-q2ks/kimi-k2-Q2_K_S-00001-of-00007.gguf \
  --ctx-size 65536 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --n-gpu-layers 999 \
  -ot "\.ffn_.*_exps\.=CPU" \
  --threads 12 \
  --host 0.0.0.0 --port 8080

L'espressione regolare passata a -ot significa: «tutti i layer FFN degli esperti (la parte principale del modello MoE) restano su CPU/RAM, il resto va sulla GPU». È questo accorgimento a rendere praticabile l'approccio ibrido: si sfrutta la GPU per l'attenzione senza dovervi caricare tutto.

#4. Token/sec effettivamente misurati

Ecco alcuni valori di riferimento della velocità osservati nella pratica. I numeri variano in base al prompt (il prefill è lento, la generazione più stabile) e allo stato della cache delle pagine del sistema operativo.

EPYC 9354P, 384 GB DDR5, Q2_K_S, tutto in RAM

Prefill ~80 tok/s, generazione ~6-8 tok/s. Configurazione di riferimento per attività di ragionamento in batch.

Threadripper 7960X, 256 GB DDR5, Q2_K_S

Prefill ~50 tok/s, generazione ~4-6 tok/s. La latenza della memoria DDR5 domina.

Ryzen 9 7950X, 128 GB DDR5 + SSD NVMe Gen 4

Prefill ~15 tok/s, generazione ~1,5-3 tok/s. L'SSD diventa il fattore limitante non appena si supera la quantità di dati che può risiedere nella RAM.

Mac Studio M2 Ultra 192 GB

Generazione ~4-7 tok/s in IQ2_XXS. La larghezza di banda della memoria unificata (800 GB/s) aiuta moltissimo con i MoE.

Workstation 256 GB + RTX 4090 (ibrida)

Prefill ~60 tok/s, generazione ~7-10 tok/s. L'uso della GPU per l'attenzione dimezza il tempo di prefill.

#5. Casi d'uso con un contesto di 128k

Il grande punto di forza di Kimi K2 rispetto ai modelli locali 7B-70B è la finestra di contesto di 128k token. In pratica, puoi dargli in pasto un rapporto annuale completo, una codebase di medie dimensioni o un centinaio di pagine PDF e chiedergli una sintesi globale che consideri l'insieme — non un RAG per blocchi.

Sintesi di documenti lunghi

Un rapporto di 300 pagine occupa meno di 120k token. Kimi K2 produce una sintesi strutturata in un'unica passata, mentre un RAG assemblerebbe un mosaico di frammenti.

Refactoring della base di codice

Caricare 50 file Python (~80k token), chiedere una revisione coerente dell'architettura. Molto utile per un debito tecnico trasversale.

Analisi correlata dei log

Incollare 50 MB di log (dopo averli filtrati) e chiedere una cronologia dell'incidente. Il modello vede tutte le correlazioni, non solo le finestre scorrevoli.

Traduzione di documenti voluminosi

Mantiene la coerenza terminologica in un intero libro, mentre una traduzione a blocchi perde il filo.

#Risoluzione dei problemi

« failed to load model » o errore di magic number

Il tuo llama.cpp è troppo vecchio per questo GGUF. Aggiornalo a una versione post-dicembre 2025 e verifica la versione di architettura indicata dal repackager del GGUF.

Generazione a 0,2 tok/s anche se la RAM sarebbe sufficiente

Il kernel continuerà a caricare le pagine dal GGUF finché non avrà acceduto a tutte. Una prima «esecuzione di riscaldamento» con un prompt breve precarica le pagine usate più frequentemente. Altrimenti, aumenta --threads per saturare prima la larghezza di banda.

OOM improvviso con un prompt lungo

La cache KV è esplosa. Riduci --ctx-size a 32768 o attiva la quantizzazione Q8 della cache. La cache KV cresce linearmente con il contesto, non con la dimensione del modello.

Output incoerente o linguaggio sgrammaticato

Spesso la causa è un template di chat errato. Verifica --chat-template oppure controlla che il GGUF includa effettivamente il template ufficiale Moonshot (jinja). Un token di fine errato fa degenerare l'output in un ciclo ripetitivo.

SSD a 80°C, velocità di trasferimento che crolla

Gli SSD NVMe di fascia alta riducono le prestazioni per il calore senza un dissipatore. Durante una sessione lunga, installa un dissipatore o riduci il carico passando a una versione quantizzata più piccola che stia nella RAM.

#Per approfondire

Kimi K2 in locale è un campo di prova per i modelli molto grandi. Tre percorsi per andare oltre:

Padroneggiare la compilazione di llama.cpp

La guida "Compilare llama.cpp con CUDA" spiega in dettaglio i flag meno evidenti (offload tensors, MMQ, Flash Attention) che influiscono sulle prestazioni di questo tipo di modello.

Comprendere le quantizzazioni

La guida "Scegliere la quantizzazione" pone le basi concettuali utili prima di immergersi in IQ2_XXS o Q3_K_S e chiarisce cosa si degrada davvero.

Spingere oltre la compressione

La guida TurboQuant descrive nel dettaglio un metodo più recente dei K-quants per far rientrare i modelli di frontiera nelle risorse di memoria dell'hardware di largo consumo, con compromessi diversi.