Kimi K2 en local : 1 trillion de paramètres MoE chez soi

#Pourquoi viser Kimi K2 en local

Kimi K2 est le modèle phare de Moonshot AI, publié en poids ouverts (Modified MIT) avec une architecture MoE (Mixture of Experts) à 1 trillion de paramètres totaux et environ 32B actifs par token. Sur les benchmarks de raisonnement et de code, il joue dans la cour des modèles frontière fermés, et son long contexte (128k tokens annoncés) en fait un candidat sérieux pour de l'analyse documentaire massive.

Faire tourner un modèle de cette taille en local relevait, il y a 18 mois, du fantasme. Trois évolutions ont changé la donne : la généralisation de DDR5 grande capacité (192-384 Go pour quelques centaines d'euros), les SSD NVMe Gen 4 capables de débiter 7 Go/s en lecture séquentielle, et le travail de l'équipe llama.cpp sur les quantizations très agressives type Q2_K_S et IQ1_M.

#Comprendre le MoE 1T / 32B actifs

L'architecture MoE remplace les blocs FFN denses par une couche d'experts (souvent 256+) parmi lesquels un routeur en sélectionne 8 à 12 par token. Côté calcul, on ne traite que les paramètres des experts élus — d'où les ~32B « actifs ». Côté mémoire en revanche, tous les experts doivent être adressables, sinon le routeur perd l'accès à 95 % du modèle.

Paramètres totaux

≈ 1 000 milliards (1T). C'est ce qui dort en RAM ou sur disque.

Paramètres actifs par token

≈ 32 milliards. C'est ce qui détermine le calcul et la vitesse.

Experts par couche

Plusieurs centaines, dont un nombre fixe est routé par token (top-k routing).

Couches partagées (attention)

Toujours actives. Elles dominent le coût mémoire à petit contexte.

Cache KV

Croît linéairement avec le contexte. Sur 128k, le KV peut dépasser 30 Go même quantizé.

#Budget mémoire à prévoir

Le calcul mémoire pour un MoE 1T se décompose en trois postes distincts. Comprendre cette décomposition est crucial avant d'investir dans la RAM ou le SSD.

Poids du modèle (quantizés)

Q2_K_S ≈ 245 Go, Q3_K_S ≈ 320 Go, Q4_K_M ≈ 480 Go, Q8_0 ≈ 1 To. C'est le poste dominant et le plus compressible.

Cache KV (contexte)

Compter ~0,25 Mo par token en FP16, ~0,12 Mo en Q8. Soit 32 Go pour 128k tokens en Q8. Configurable via --cache-type-k/-v.

Buffers d'activation

Quelques Go par GPU pour les calculs intermédiaires. Marginal mais à ne pas oublier sur des GPU 24 Go.

#Prérequis matériels

Trois profils de machines permettent de faire tourner Kimi K2 en local, avec des compromis très différents en vitesse.

Profil A — DDR5 musclée (192-384 Go RAM)

Workstation Threadripper/Xeon W ou plateforme EPYC. 256 Go DDR5 ECC, pas de GPU obligatoire. Le modèle tient entièrement en RAM en Q2_K_S. Vitesse attendue : 4-8 tok/s en CPU pur.

Profil B — DDR5 + 1 GPU 24 Go

96-128 Go RAM + RTX 4090/3090. On offload les couches partagées sur GPU, les experts restent en RAM. Vitesse attendue : 6-12 tok/s, dépend du nombre d'experts qui rentrent en VRAM.

Profil C — RAM modeste + SSD NVMe

64-96 Go RAM + NVMe Gen 4 (7 Go/s lecture, ≥ 1 To libre). On mmap les poids depuis le SSD. Vitesse attendue : 1-3 tok/s, fortement dépendante du débit SSD réel.

#1. Compiler llama.cpp avec le bon backend

Kimi K2 nécessite une version récente de llama.cpp (build récent post-décembre 2025) qui supporte son architecture MoE et les quantizations IQ. On compile depuis le repo officiel.

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

Sur Mac Apple Silicon, remplacer GGML_CUDA par GGML_METAL. Sur AMD avec ROCm, GGML_HIP. Le flag GGML_CUDA_FA_ALL_QUANTS active Flash Attention pour toutes les quantizations — indispensable pour tenir 128k de contexte sans exploser la VRAM.

#2. Choisir la quantization GGUF

Pour un modèle de cette taille, oubliez Q4_K_M et au-dessus à moins d'avoir 512 Go de RAM. La quantization extrême — Q2_K_S, IQ2_XXS, voire IQ1_M — est ce qui rend le local viable, au prix d'une perte de qualité mesurable mais souvent acceptable sur un MoE.

Q2_K_S (~245 Go)

Le sweet spot. ~5 % de dégradation sur les benchmarks de code, ~3 % en raisonnement. Recommandé si vous avez 256 Go de RAM ou un SSD rapide.

IQ2_XXS (~210 Go)

Encore plus agressif via importance matrix. Tient sur 192 Go RAM avec un peu d'offload. Qualité un cran en dessous.

IQ1_M (~155 Go)

Quantization 1-bit hybride. Pour les configs très contraintes. Dégradation visible mais le modèle reste cohérent.

Q3_K_S (~320 Go)

Qualité quasi-Q4 mais demande 384 Go RAM. Pour les workstations EPYC bien équipées.

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

Les GGUF de cette taille sont split en plusieurs fichiers (split-00001-of-00007.gguf etc). llama.cpp détecte automatiquement les splits si vous pointez vers le premier fichier.

#3. Lancer Kimi K2 avec mmap et offload

La commande de base utilise llama-server, le serveur HTTP fourni par llama.cpp. Il expose un endpoint compatible OpenAI sur le port 8080 par défaut.

./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

Avec un GPU 24 Go, on offload les couches partagées (attention) sur GPU et on laisse les experts MoE en RAM ou sur SSD. Le flag -ot permet de cibler précisément ce qui va sur GPU vs 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

Le regex passé à -ot signifie : « toutes les couches FFN des experts (le gros du modèle MoE) restent sur CPU/RAM, le reste va sur GPU ». C'est cette astuce qui rend l'hybride viable : on profite du GPU pour l'attention sans devoir tout y charger.

#4. Tokens/sec réels mesurés

Voici quelques repères de débit observés en pratique. Les chiffres bougent en fonction du prompt (le prefill est lent, la génération plus stable) et de l'état du cache de pages OS.

EPYC 9354P, 384 Go DDR5, Q2_K_S, tout en RAM

Prefill ~80 tok/s, génération ~6-8 tok/s. Configuration de référence pour du batch raisonnement.

Threadripper 7960X, 256 Go DDR5, Q2_K_S

Prefill ~50 tok/s, génération ~4-6 tok/s. La latence mémoire DDR5 domine.

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

Prefill ~15 tok/s, génération ~1,5-3 tok/s. Le SSD devient le facteur limitant dès qu'on dépasse la RAM résidente.

Mac Studio M2 Ultra 192 Go

Génération ~4-7 tok/s en IQ2_XXS. La bande passante mémoire unifiée (800 Go/s) aide énormément sur les MoE.

Workstation 256 Go + RTX 4090 (hybride)

Prefill ~60 tok/s, génération ~7-10 tok/s. Le GPU sur l'attention divise par 2 le temps de prefill.

#5. Cas d'usage 128k contexte

La grande force de Kimi K2 face aux modèles 7B-70B locaux, c'est la fenêtre 128k tokens. Concrètement, vous pouvez lui faire avaler un rapport annuel complet, un code base de taille moyenne, ou une centaine de pages de PDF, et lui demander une synthèse globale qui voit l'ensemble — pas du RAG par chunks.

Synthèse de documents longs

Un rapport 300 pages tient sous 120k tokens. Kimi K2 produit une synthèse structurée en une passe, là où un RAG mosaïquerait.

Refactoring de code base

Charger 50 fichiers Python (~80k tokens), demander une revue d'architecture cohérente. Très utile pour une dette technique transversale.

Analyse de logs corrélée

Coller 50 Mo de logs (après filtrage) et demander une chronologie d'incident. Le modèle voit toutes les corrélations, pas seulement les fenêtres glissantes.

Traduction de gros documents

Garde la cohérence terminologique sur un livre entier, là où une traduction par chunks perd les fils.

#Dépannage

« failed to load model » ou erreur de magic number

Votre llama.cpp est trop ancien pour ce GGUF. Mettez à jour vers un build post-décembre 2025 et vérifiez la version d'architecture annoncée par le repackager du GGUF.

Génération à 0,2 tok/s alors que la RAM suffirait

Le kernel paginera depuis le GGUF tant qu'il n'a pas touché toutes les pages. Un premier « run de chauffe » sur un prompt court précharge les pages chaudes. Sinon, augmentez --threads pour saturer plus tôt la bande passante.

OOM brutal sur prompt long

Le cache KV a explosé. Ramenez --ctx-size à 32768 ou activez la quantization Q8 du cache. Le KV grossit linéairement avec le contexte, pas avec la taille du modèle.

Sortie incohérente ou langue cassée

Souvent un template de chat incorrect. Vérifiez --chat-template ou que le GGUF embarque bien le template officiel Moonshot (jinja). Un mauvais token de fin produit du dérapage en boucle.

SSD chaud à 80°C, débit qui s'effondre

Les NVMe haut de gamme throttlent sans dissipateur. Sur une session longue, mettez un radiateur ou réduisez la charge en passant à une quantization plus petite qui tient en RAM.

#Pour aller plus loin

Kimi K2 en local est un terrain de jeu pour les très gros modèles. Trois pistes pour pousser plus loin :

Maîtriser le build llama.cpp

Le guide "Compiler llama.cpp avec CUDA" détaille les flags moins évidents (offload tensors, MMQ, Flash Attention) qui changent les performances sur ce type de modèle.

Comprendre les quantizations

Le guide "Choisir sa quantification" pose les bases conceptuelles utiles avant de plonger dans IQ2_XXS ou Q3_K_S, et clarifie ce qui se dégrade vraiment.

Pousser plus loin la compression

Le guide TurboQuant détaille une méthode plus récente que K-quants pour faire tenir des modèles frontière sur du matériel grand public, avec des compromis différents.