Comment faire tourner Kimi K3 en local et ses limites

Moonshot AI a publié les poids ouverts de Kimi K3 le 27 juillet, et le compteur de téléchargements sur Hugging Face approche déjà les 100 000. L'argument est évident : un modèle de 2,8 billions de paramètres qui a battu Claude Opus 4.8 sur tous les benchmarks publiés par Moonshot, et que vous pouvez désormais héberger vous-même.

L'inconvénient est également évident une fois que l'on regarde les chiffres. L'inférence en pleine précision nécessite 1,57 To de disque. Même les poids MXFP4 publiés représentent un téléchargement de 594 Go. C'est un modèle que vous pouvez posséder, mais "local" signifie quelque chose de différent à cette échelle que pour un Llama 8B.

Ce guide explique ce qu'il faut pour exécuter K3 sur votre propre matériel, ce que la communauté a réussi à faire sur des machines grand public, et comment intégrer un point de terminaison K3 auto-hébergé dans votre flux de travail API avec Apidog une fois qu'il est en service.

Ce que vous téléchargez

Tout d'abord, la forme de la chose. Si vous voulez le contexte complet, commencez par Qu'est-ce que Kimi K3 ? ; la version courte :

• 2,8 T de paramètres au total, 104 milliards activés par jeton. K3 est un modèle Mixture-of-Experts (MoE) avec 896 experts. Chaque jeton passe par 16 experts sélectionnés plus 2 partagés, de sorte que le calcul par jeton représente une fraction du nombre total affiché.
• 93 couches : 69 couches d'attention Kimi Delta (KDA) et 24 couches MLA gated. La conception KDA est la raison pour laquelle la fenêtre de contexte d'un million de jetons est utilisable.
• Vision native via un encodeur MoonViT-V2 de 401 millions de paramètres. Les poids publiés gèrent l'entrée de texte, d'images et de vidéo.
• Poids MXFP4, activations MXFP8. Moonshot a effectué un entraînement conscient de la quantification, de sorte que la version 4 bits est le format de service prévu, et non une solution de dernière minute. Cela signifie également que les poids se compressent mal au-delà de cela ; la marge de manœuvre en bits faibles est déjà épuisée.
• Réflexion uniquement. K3 raisonne toujours avant de répondre, avec des niveaux d'effort faible, élevé et maximal. Il n'y a pas de mode instantané.

Les poids sont protégés par la licence Kimi K3 sur le dépôt Hugging Face. Acceptez la licence, puis téléchargez avec huggingface-cli. Sur une connexion de 1 Gbps, prévoyez environ 80 à 90 minutes pour les 594 Go.

Option 1 : service de classe centre de données avec vLLM ou SGLang

Moonshot recommande trois moteurs : vLLM, SGLang et TokenSpeed. Leur contribution au cache de préremplissage KDA a été intégrée à vLLM en même temps que les poids, donc vLLM est la voie la moins résistante :

vllm serve moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --max-model-len 131072

Notes du terrain :

• Matériel. Moonshot a évalué sur des clusters H20. Réaliste, vous avez besoin d'un nœud à 8 GPU avec parallélisme de tenseurs comme minimum. Sur du matériel de classe B200, un débit supérieur à 100 jetons/s est réalisable.
• Contexte. Le modèle prend en charge jusqu'à 1 048 576 jetons, mais le cache KV en contexte complet est d'environ 27 Go à lui seul. Commencez à 131K et augmentez-le uniquement si votre charge de travail l'exige.
• Échantillonnage. Les valeurs par défaut de Moonshot sont une température de 1,0 et un top-p de 0,95. Pour les charges de travail agissantes, maintenez la température à 1,0 et passez le top-p à 1,0.

C'est "local" au sens de la souveraineté des données : votre infrastructure, vos journaux, votre historique de conformité. Ce n'est pas local au sens de l'ordinateur portable, et aucune quantification ne change cela pour une utilisation interactive.

Option 2 : Quantifications GGUF sur une grande station de travail

Unsloth a publié des conversions GGUF pour les utilisateurs de llama.cpp, et leurs quantifications dynamiques sont la seule façon réaliste de réduire K3 en dessous de la version officielle :

La règle de base : votre RAM plus votre VRAM doit être à peu près égale à la taille de la quantification. Si vous manquez de mémoire, llama.cpp fonctionnera toujours grâce à l'offloading, mais chaque gigaoctet manquant vous coûtera en vitesse. Un Mac Studio relié à une machine de 128 Go, ou une DGX Station, se situe à la limite inférieure pratique.

Une invocation minimale de llama.cpp, incluant le projecteur de vision :

./llama.cpp/llama-cli \
    --model unsloth/Kimi-K3-GGUF/UD-IQ1_S/Kimi-K3-UD-IQ1_M-00001-of-00015.gguf \
    --mmproj unsloth/Kimi-K3-GGUF/mmproj-F16.gguf \
    --temp 1.0 \
    --top-p 0.95

Si votre matériel est en deçà de cela, ne forcez pas. La liste des meilleurs LLM locaux de 2026 contient des modèles ouverts qui tiennent dans 24 à 128 Go et répondent en temps réel ; K3 à 1 bit sur une RAM insuffisante ne le fera pas.

L'expérience M1 Max : oui, mais 16 secondes par jeton

Un fil de discussion sur Hacker News cette semaine a documenté l'exécution de K3 sur un M1 Max de 64 Go en diffusant les poids depuis un SSD de 2 To au lieu de les maintenir en mémoire. Les chiffres expliquent à la fois pourquoi cela fonctionne et pourquoi vous ne l'utiliseriez pas :

• K3 contient environ 115 Go de paramètres denses que chaque jeton touche, plus environ 25 Go de poids d'experts acheminés par jeton. La partie dense seule dépasse la RAM de la machine, de sorte que le SSD devient une mémoire au ralenti.
• Résultat : environ 16 secondes par jeton. Certaines configurations ont rapporté plus d'une minute par jeton. C'est un paragraphe par heure.
• Le débit du disque est la clé. Les SSD de l'ère M1 lisent beaucoup plus lentement que les puces Apple actuelles, et la diffusion d'experts sur un réseau est encore plus lente.

En tant que preuve que la parcimonie des MoE et mmap peuvent exécuter un modèle de 2,8 T sur un ordinateur portable, c'est un résultat vraiment amusant. Mais ce n'est pas une façon d'utiliser K3. Si vous voulez des réponses K3 sur un MacBook, les niveaux gratuits ou l'API hébergée vous serviront mieux.

Intégrer votre K3 local dans un flux de travail API

Que vous serviez via vLLM ou le mode serveur de llama.cpp, vous obtenez la même chose : un point de terminaison HTTP compatible OpenAI sur localhost. À partir de là, c'est une API comme les autres, et le même flux de travail que nous utilisons pour tester les LLM locaux en tant qu'API s'applique :

1. Dirigez Apidog vers le point de terminaison. Créez un environnement avec base_url défini sur http://localhost:8000/v1 (par défaut de vLLM) et échangez-le ultérieurement avec le point de terminaison hébergé de Moonshot. Mêmes requêtes, deux backends, une variable.
2. Inspectez le flux de réflexion. K3 ne fait que réfléchir, donc les réponses contiennent un contenu de raisonnement avant la réponse. La vue de débogage SSE d'Apidog affiche le flux au fur et à mesure qu'il arrive, ce qui facilite grandement la visualisation des changements de niveaux d'effort de raisonnement.
3. Affirmez la structure, pas les impressions. Ajoutez des tests automatisés qui valident le schéma de réponse, les budgets de latence et les champs d'utilisation des jetons, de sorte qu'un changement de quantification ou une mise à niveau du moteur qui dégrade la sortie apparaisse dans un test échoué au lieu d'un rapport d'utilisateur.
4. Simulez K3 pendant que les GPU sont occupés. Un modèle de 594 Go prend du temps à charger. Enregistrez les réponses réelles une fois, puis laissez un serveur de simulation les renvoyer afin que le travail frontal n'attende jamais la boîte d'inférence. Téléchargez Apidog pour configurer cela gratuitement ; les outils de simulation et de test fonctionnent tous deux avec n'importe quel serveur compatible OpenAI.

Le format de requête lui-même correspond à ce que nous avons couvert dans le guide API de Kimi K3, donc les tests écrits contre l'API hébergée sont directement transférables à votre déploiement local.

Alors, devriez-vous l'exécuter localement ?

Une table de décision rapide :

En résumé honnête : les poids ouverts de K3 sont importants parce que vous pouvez auditer, affiner et auto-héberger un modèle de pointe, pas parce que la plupart des gens devraient le faire. Pour les équipes disposant du matériel, la voie vLLM fonctionne aujourd'hui et est performante. Pour tous les autres, la version ouverte reste rentable indirectement, grâce à un accès hébergé moins cher et à des fournisseurs tiers qui se disputent pour le servir.

Quel que soit le côté de ce tableau où vous vous situez, le point de terminaison est l'endroit où le modèle rencontre votre code. Testez-le comme tel : vérifications de schéma, inspection de flux, et simulations qui maintiennent le développement en mouvement pendant que le modèle réfléchit.