Comment déployer Kimi K3 en local ?

TL;DR

Kimi K3 est à poids ouverts mais pas à l’échelle d’une station de travail : servir le modèle natif exige des GPU de classe centre de données et de la mémoire distribuée. Utilisez vLLM pour la voie de mise en production la plus directe, ou SGLang lorsque la topologie, le parallélisme d’experts et le contrôle du cache sont déterminants. Les builds communautaires GGUF abaissent le seuil matériel, mais requièrent tout de même environ 500 Go à bien plus de 1 To de mémoire adressable et échangent vitesse ou qualité contre la faisabilité. Pour les PC et Mac ordinaires, testez d’abord via une API hébergée et n’auto-hébergez que lorsque la confidentialité, l’utilisation soutenue ou le contrôle de l’infrastructure justifient le coût.

What Is Kimi K3?

Kimi K3 est le modèle phare multimodal natif à poids ouverts de Moonshot AI pour la programmation à long horizon, le travail cognitif agentique, le raisonnement et la compréhension visuelle.

Moonshot le décrit comme le premier modèle ouvert de classe 3T au monde. Son architecture combine Kimi Delta Attention and Attention Residuals avec une conception MoE clairsemée qui ne sélectionne qu’un sous-ensemble d’experts pour chaque token.

L’échelle est inhabituelle, même selon les standards des modèles de pointe. Au lieu d’activer tous les 2.8T paramètres pour chaque token, K3 sélectionne 16 experts parmi 896 experts routés, plus des experts partagés. Cela réduit sensiblement le calcul par token, bien que tous les poids du modèle doivent tout de même être disponibles quelque part dans le système d’inférence.

K3 applique également un entraînement sensibilisé à la quantification dès l’étape SFT, plutôt que de traiter le service en basse précision comme une simple compression post-entraînement.

Son architecture est donc optimisée pour un service à très grande échelle — mais « calcul clairsemé » ne doit pas être confondu avec « faible empreinte mémoire ». Seule une partie du réseau calcule chaque token, mais l’ensemble complet des experts doit rester accessible.

How Does Kimi K3 Perform?

La suite de benchmarks officielle Kimi K3 place le modèle au plus proche des modèles propriétaires de pointe, en particulier sur l’ingénierie logicielle à long horizon et les charges agentiques.

La sélection suivante couvre le raisonnement, le code, les agents et la vision. Plus c’est élevé, mieux c’est pour tous les scores.

Les scores officiels placent Kimi K3 près de GPT-5.6 Sol, Claude Fable 5 et Claude Opus 4.8 sur les tâches de raisonnement, de codage, d’agents et de vision. Considérez ces résultats fournis par le fournisseur comme un contexte de capacités plutôt qu’un classement universel ; l’analyse détaillée des benchmarks est couverte séparément. Pour ce guide, le point opérationnel est que l’auto-hébergement offre des capacités de classe frontière et un contrôle de l’infrastructure, mais pas un raccourci peu coûteux sur desktop.

Can You Actually Run Kimi K3 Locally?

Oui, mais il existe deux définitions très différentes de « local ».

Serveur local / centre de données privé : réaliste.

Bureau ou ordinateur portable normal : expérimentalement possible avec des builds communautaires fortement quantifiés, mais généralement peu pratique pour un usage interactif.

La recette vLLM Kimi K3 actuelle fixe une base très élevée :

• NVIDIA : au moins 8× GB300
• AMD ROCm : au moins 8× MI355X ou MI350X
• Pilote NVIDIA : R580+ pour l’image CUDA 13 K3 actuelle
• Infrastructure multi-nœuds recommandée pour un trafic de production réel

Le guide vLLM d’origine (jour 0) a également démontré une voie de démarrage rapide 8 GPU B300 ou 8 GPU MI355X. Pour un nouveau déploiement de production, suivez la recette la plus récente car elle reflète la pile de service après les optimisations du jour du lancement.

C’est le point clé : K3 est à poids ouverts, mais ce n’est pas un modèle ouvert à l’échelle grand public.

Official Weights vs Community GGUF Quantizations

Il existe un autre moyen de réduire le seuil matériel : la quantification communautaire.

Le dépôt Unsloth K3 actuel fournit plusieurs variantes GGUF pouvant s’exécuter via des logiciels compatibles avec llama.cpp.

Comparaison consolidée. Les chiffres de mémoire adressable sont des estimations de planification (taille de téléchargement plus environ 10–15 % de marge d’exécution), pas des garanties ; le contexte, le cache, la vision et les paramètres d’offload peuvent exiger davantage.

Cette distinction explique aussi pourquoi certains articles de déploiement local précoces citaient 594 Go : 594 Go correspond désormais au build communautaire UD-IQ1_S GGUF, et non à une description utile du checkpoint natif complet actuel.

Un modèle de 466–649 Go est considérablement plus petit que l’empreinte de déploiement d’origine, mais il reste énorme selon les standards des stations de travail. Prévoyez aussi de la mémoire pour l’état d’exécution, le contexte, les caches, le projecteur vision, les processus du système d’exploitation et autres surcharges.

La capacité disque n’est pas la même chose que la mémoire d’inférence. Disposer d’un SSD de 1 To ne signifie pas qu’un modèle de 600 Go s’exécutera rapidement sur une machine avec 64 Go de RAM. L’offload sur SSD peut rendre des expériences extrêmes techniquement possibles, mais la génération de tokens peut devenir douloureusement lente.

How to Deploy Kimi K3 with vLLM

Pour un auto-hébergement sérieux, vLLM est le point de départ le plus simple.

Moonshot liste actuellement vLLM comme l’un des moteurs d’inférence K3 recommandés, et vLLM fournit une prise en charge spécifique à K3 pour KDA, MXFP4 MoE, l’analyse du raisonnement, l’appel d’outils, le cache de préfixe et le déploiement distribué.

Check the prerequisites

Pour un déploiement de production NVIDIA, la recette testée actuelle utilise le conteneur vllm/vllm-openai:kimi-k3.

Vérifiez les GPU :

nvidia-smi

Confirmez Docker :

docker --version

Confirmez que NVIDIA Container Toolkit voit les accélérateurs :

docker run --rm --gpus all nvidia/cuda:13.0.0-base-ubuntu24.04 nvidia-smi

Si la dernière commande ne voit pas tous les GPU, corrigez l’exécution GPU hôte/conteneur avant de télécharger un modèle de plusieurs téraoctets.

Set your Hugging Face token

Si une authentification est requise pour le dépôt du modèle, stockez le jeton dans une variable d’environnement plutôt que de le coder en dur dans des scripts.

export HF_TOKEN="YOUR_HUGGING_FACE_TOKEN"

Pull the K3 vLLM container

docker pull vllm/vllm-openai:kimi-k3

La recette actuelle spécifie une build CUDA 13 et un pilote NVIDIA R580 ou plus récent.

Launch Kimi K3

Modèle de départ Blackwell TP8 actuel (recette vLLM mise à jour le 2026-09-10) : utilisez ceci comme base, puis régénérez ou benchmarkez le profil pour votre matériel et votre trafic exacts.

docker run --rm \
  --gpus all \
  --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HF_TOKEN="$HF_TOKEN" \
  -e VLLM_USE_V2_MODEL_RUNNER=1 \
  vllm/vllm-openai:kimi-k3 \
  --model moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --gpu-memory-utilization 0.95 \
  --kv-cache-dtype fp8 \
  --attention-backend TOKENSPEED_MLA \
  --attention-config '{"use_prefill_query_quantization":true,"mla_prefill_backend":"TOKENSPEED_MLA"}' \
  --prefix-match-unit 128 \
  --enable-prefix-caching \
  --max-model-len 131072 \
  --enable-auto-tool-choice \
  --tool-call-parser kimi_k3 \
  --reasoning-parser kimi_k3

La recette actuelle nécessite l’image CUDA 13 K3 et un pilote NVIDIA R580 ou plus récent. Le cache KV en FP8 doit être associé à un backend de prefill/decode MLA compatible ; benchmarkez les alternatives avant de modifier la configuration d’attention.

Source : recette vLLM Kimi K3. Cela remplace la commande du jour 0 plutôt que de la présenter comme recette de production actuelle.

Pour une première exécution de validation, envisagez de limiter la longueur maximale du modèle au lieu d’allouer immédiatement la capacité complète de 1,048,576 tokens. La recette vLLM actuelle recommande explicitement d’ajuster max-model-len à la charge.

Par exemple :

--max-model-len 131072

Cela ne change pas la limite de contexte architecturale de K3. Cela donne simplement au moteur de service un périmètre d’exploitation plus gérable pour vos tests initiaux.

Test the local endpoint

vLLM expose une API compatible OpenAI sur le port 8000.

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/Kimi-K3",
    "messages": [
      {
        "role": "user",
        "content": "Explain the difference between tensor parallelism and expert parallelism."
      }
    ],
    "max_tokens": 512
  }' 

Ou utilisez le SDK Python OpenAI :

python

from openai import OpenAI

 client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="EMPTY",
    timeout=3600,
 )

response = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=[
        {
            "role": "user",
            "content": "Write a Python function that validates a JSON schema.",
        }
    ],
    max_tokens=1024,
 )

print(response.choices[0].message.content)

La recette vLLM officielle utilise le même schéma local compatible OpenAI, ce qui facilite le basculement d’une application entre l’inférence locale et hébergée.

How to Deploy Kimi K3 with SGLang

SGLang est l’autre voie de déploiement majeure officiellement recommandée par Moonshot.

Elle est particulièrement pertinente lorsque vous souhaitez un contrôle plus poussé sur le service distribué, le parallélisme d’experts, les kernels spécifiques au matériel ou une topologie de production complexe.

Utilisez le Cookbook Kimi K3 dédié de SGLang et sélectionnez une topologie spécifique au matériel. Ce qui suit est le profil Unified/Balanced 8×B300 mono-nœud vérifié issu du cookbook ; il a été mesuré avec SGLang v0.5.18 au commit 71de97b2.

Installez une build compatible K3 :

pip install --upgrade pip
pip install uv
uv pip install --prerelease=allow sglang

Lancez le profil vérifié B300 TP8/DCP8 :

sglang serve \
  --trust-remote-code \
  --model-path moonshotai/Kimi-K3 \
  --tp-size 8 \
  --dcp-size 8 \
  --mem-fraction-static 0.85 \
  --mamba-full-memory-ratio <value-from-official-calculator> \
  --reasoning-parser kimi_k3 \
  --tool-call-parser kimi_k3 \
  --host 0.0.0.0 \
  --port 30000

--mamba-full-memory-ratio dépend de la charge : calculez-le à partir de la longueur moyenne entrée + sortie dans le cookbook officiel. Ne copiez pas cette topologie B300 vers H100/H200, GB200/GB300, AMD ou des déploiements multi-nœuds ; ces profils utilisent des dispositions TP/PP/DCP/EP différentes.

Testez le serveur :

curl http://localhost:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/Kimi-K3",
    "messages": [{"role": "user", "content": "Give me a five-step debugging plan for a distributed Python application."}]
  }'

Pour un déploiement réel, validez la capacité, la qualité de sortie et la reprise après incident sur la version SGLang, la topologie, la longueur de contexte et le mix de trafic exacts que vous comptez exécuter.

vLLM vs SGLang vs llama.cpp

Le choix du moteur d’inférence dépend principalement de votre matériel et de l’objectif du déploiement.

Si vous possédez un serveur 8 GPU de classe Blackwell/MI35x, commencez par vLLM.

Si vous concevez un cluster d’inférence distribué spécialisé et souhaitez davantage de contrôles de bas niveau, évaluez également SGLang.assistant_message

Si votre objectif est simplement « je veux prouver que K3 peut s’exécuter sur le matériel que je possède », GGUF plus llama.cpp est bien plus abordable — à condition que votre machine dispose d’une quantité de mémoire réellement exceptionnelle.

How to Run a Quantized Kimi K3 with llama.cpp or Ollama

Le dépôt GGUF Kimi K3 communautaire fournit désormais des variantes compatibles avec llama.cpp.

Cette voie abaisse considérablement la barrière d’entrée par rapport à un déploiement natif de centre de données, mais « considérablement » est relatif : même les plus petites variantes font plusieurs centaines de gigaoctets.

Install llama.cpp on macOS or Linux

La carte du modèle GGUF actuelle fournit :

curl -LsSf https://llama.app/install.sh | sh

Sous Windows :

winget install llama.cpp

Start an OpenAI-compatible server

Le dépôt documente actuellement UD-Q4_K_XL comme exemple :

llama serve \
  -hf unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

Vous pouvez également exécuter le CLI directement :

llama cli \
  -hf unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

Ces commandes proviennent directement de la carte du modèle Kimi K3 GGUF actuelle.

Cependant, UD-Q4_K_XL pèse environ 1.51 TB, ce n’est donc pas la variante par laquelle la plupart des utilisateurs de stations de travail commenceront. Si votre priorité est de réduire les exigences mémoire plutôt que de préserver un maximum de qualité, examinez d’abord les variantes 1 bit et 2 bits plus petites.

Par exemple :

llama serve \
  -hf unsloth/Kimi-K3-GGUF:UD-IQ1_M

Le répertoire UD-IQ1_M actuel fait environ 649 GB.

Un modèle de 649 Go n’est toujours pas un modèle pour ordinateur portable normal. Idéalement, l’état de modèle fréquemment accédé devrait résider en mémoire rapide. Un offload massif sur SSD peut rendre une expérience extrême techniquement possible sans la rendre utile pour un travail interactif.

Run the Same GGUF Build with Ollama

Ollama est une couche de commodité pour la même voie de déploiement GGUF, pas une quatrième méthode d’auto-hébergement indépendante.

Le dépôt K3 GGUF expose également une voie via Ollama.

Par exemple :

bash

ollama run hf.co/unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

Ollama simplifie la gestion des modèles et l’expérience API, mais ne change pas les exigences mémoire de K3.

Changer le lanceur de llama.cpp vers Ollama ne transformera pas une quantification de plusieurs centaines de gigaoctets en un modèle 24 Go sur GPU. Les données de modèle sous-jacentes doivent toujours être stockées et accessibles.

Pour cette raison, Ollama doit être considéré comme un wrapper d’exécution pratique, pas comme une solution matérielle.

Which Kimi K3 Quantization Should You Choose?

Pour des expériences, le choix est surtout un compromis entre taille du modèle et fidélité.

Important Kimi K3 Serving Behavior

Il y a un détail de mise en œuvre propre à K3 facile à négliger.

K3 utilise une historique de pensée préservée. Moonshot indique que les conversations multi-tours et les workflows d’appels d’outils doivent renvoyer le message assistant précédent complet au modèle, y compris reasoning_content et tool_calls, plutôt que de ne préserver que le contenu visible.

Un schéma d’application simplifié ressemble à ceci :

messages = [
    {
        "role": "user",
        "content": "Inspect this project and propose a migration plan.",
    }
 ]

first = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=messages,
    max_tokens=2048,
 )

assistant_message = first.choices[0].message

 # Preserve the whole message object, not just assistant_message.content.
 messages.append(
    assistant_message.model_dump(exclude_none=True)
 )

messages.append(
    {
        "role": "user",
        "content": "Now identify the riskiest part of that plan.",
    }
 )

second = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=messages,
    max_tokens=2048,
 )

Cela devient particulièrement important pour les agents de codage, les boucles d’outils et les sessions autonomes de longue durée.

K3 garde également le raisonnement activé et prend en charge un effort de raisonnement faible, élevé et maximal. Lorsque votre couche de service expose ces paramètres, traitez l’effort de raisonnement comme un autre levier latence/qualité plutôt que de le maximiser systématiquement pour chaque requête.

How to Optimize a Local Kimi K3 Deployment

Do not allocate the full 1M context immediately

K3 prend en charge 1,048,576 tokens, mais la capacité maximale du modèle et une configuration serveur sensée sont deux choses différentes.

En développement, commencez par quelque chose comme :

--max-model-len 131072

Puis augmentez le contexte seulement après avoir mesuré la mémoire disponible, le temps jusqu’au premier token, le débit et la concurrence attendue.

Enable prefix caching

Les agents de codage réutilisent fréquemment des instructions de dépôt, des schémas d’outils, des messages système et de longs préfixes.

Avec vLLM :

--enable-prefix-caching

L’architecture d’attention hybride de K3 nécessite un traitement spécial pour le cache de préfixe, et vLLM a implémenté une prise en charge spécifique au modèle.

Use the K3 parsers

Pour les charges d’agents, incluez :

--tool-call-parser kimi_k3 \
--reasoning-parser kimi_k3

Cela maintient les appels d’outils et la sortie de raisonnement alignés avec le format de service de K3.

Keep storage fast

Un modèle à cette échelle exerce une pression inhabituelle sur le stockage local lors du premier téléchargement, du chargement de checkpoint, des mises à jour et de la reprise.

Le stockage NVMe est préférable aux disques lents montés en réseau. Si plusieurs machines partagent les fichiers du modèle, la topologie du cache de modèle et la bande passante réseau deviennent des parties de l’architecture d’inférence plutôt que de simples détails de déploiement.

Monitor more than GPU utilization

Suivez :

• l’utilisation HBM/VRAM
• la RAM CPU
• le taux de réussite du cache
• le temps jusqu’au premier token
• les tokens décodés par seconde
• la profondeur de la file de requêtes
• la communication inter-GPU
• la bande passante inter-nœuds
• les échecs d’analyse des appels d’outils
• le temps de chargement du modèle

À l’échelle K3, un chiffre d’utilisation GPU apparemment sain ne vous dit pas si la topologie de service est efficace.

Local Kimi K3 vs Hosted Kimi K3

L’auto-hébergement offre un contrôle maximal sur le chemin des données, l’exécution et les poids du modèle, tout en vous rendant responsable de la capacité GPU, de la montée en charge, des mises à jour, de la supervision et de la reprise. L’accès hébergé supprime la plupart des travaux d’infrastructure et constitue généralement la voie la plus rapide pour l’évaluation ou une demande variable.

Pour l’analyse complète du matériel et du point mort, lisez Kimi K3 Self-Hosting vs API. Pour les prix par token, le caching et les comparaisons avec K2.7, utilisez le guide de tarification Kimi K3. Cet article se concentre donc sur les commandes de déploiement, la configuration et le dépannage.

Common Kimi K3 Local Deployment Problems

The model does not fit in GPU memory

C’est l’échec le plus prévisible.

Ne calculez pas la mémoire à partir des 104B de paramètres activés. Ce chiffre décrit le calcul par token, pas la quantité de poids d’experts que le système de service doit rendre disponible.

Utilisez une topologie distribuée prise en charge, une quantification GGUF plus petite ou un service hébergé.

CUDA or NVIDIA driver errors

L’image vLLM K3 actuelle est basée sur CUDA 13 et requiert un pilote hôte R580+.

Si l’hôte est encore sur une pile R575/CUDA 12.9, mettez-la à jour ou suivez la voie de compilation depuis les sources décrite par vLLM plutôt que de supposer que le conteneur résoudra l’incompatibilité du pilote hôte.

The first request is extremely slow

Vérifiez si le checkpoint est encore en cours de chargement, de compilation de kernels, de préchauffage des caches ou de téléchargement de fichiers.

Avec des artefacts de classe multi-téraoctets, « processus serveur démarré » et « modèle prêt pour le trafic de production » ne sont pas des états équivalents.

Tool calls fail intermittently

La recette vLLM actuelle note que K3 peut occasionnellement produire une forme d’appel d’outil que son parseur n’attend pas. Les systèmes de production doivent donc valider les schémas d’appel d’outils et implémenter des retries plutôt que de faire confiance aveuglément à chaque appel généré.

Long conversations become less stable

Assurez-vous de renvoyer le message assistant complet — y compris les informations de raisonnement et d’outils — aux tours K3 suivants.

Supprimer des champs d’état de raisonnement cachés peut casser le schéma d’historique de pensée préservée pour lequel K3 a été entraîné.

So, What Is the Best Way to Deploy Kimi K3 Locally?

Pour la plupart des organisations disposant du matériel adapté, vLLM est la meilleure première voie de déploiement. Il offre un support dédié à K3, une API compatible OpenAI, des parseurs spécifiques au modèle, le cache de préfixe, le décodage spéculatif et des recettes matérielles à jour.

Choisissez SGLang lorsque l’ingénierie d’inférence distribuée et le contrôle fin du service priment sur la mise en place la plus courte.

Choisissez llama.cpp plus une quantification GGUF communautaire uniquement lorsque votre objectif est l’expérimentation sur station/serveur et que vous comprenez que même les versions 1 bit restent de plusieurs centaines de gigaoctets.

Pour une station de travail développeur conventionnelle, la conclusion la plus pratique est différente : n’achetez pas des centaines de gigaoctets de RAM uniquement pour forcer K3 sur un desktop. Testez Kimi K3 via CometAPI d’abord, mesurez son bénéfice sur vos tâches, puis passez à l’auto-hébergement seulement lorsque la confidentialité, l’utilisation soutenue ou le contrôle de l’infrastructure rendent l’économie pertinente.

FAQ

Can Kimi K3 run on a single consumer GPU?

Pas réellement. Le modèle est bien au-delà de la capacité VRAM des GPU grand public. Les quantifications GGUF communautaires à faible précision réduisent fortement l’empreinte, mais les plus petites variantes actuelles comptent encore plusieurs centaines de gigaoctets.

Can I run Kimi K3 on a Mac?

L’exécution expérimentale CPU/Apple Silicon avec GGUF et offload de stockage est possible en principe, mais les performances interactives et la capacité mémoire sont les facteurs limitants. Un MacBook typique ne doit pas être traité comme une plateforme pratique de service K3.

Does Kimi K3 support Ollama?

Les builds GGUF communautaires peuvent être lancés via Ollama. Le runtime simplifie la mise en place mais ne change pas l’exigence mémoire sous-jacente.

Is vLLM or SGLang better for Kimi K3?

vLLM est le choix par défaut le plus simple pour un nouveau déploiement de production. SGLang est attractif pour les équipes construisant des topologies de service distribué sophistiquées. Les deux font partie des moteurs d’inférence K3 recommandés par Moonshot.

How much context does Kimi K3 support?

La spécification officielle du modèle prend en charge 1,048,576 tokens. Un serveur local n’a pas à exposer toute la fenêtre de contexte ; définir un max-model-len plus bas peut être plus pratique pour un déploiement précoce et une plus grande concurrence.

Is Kimi K3 open source?

La description la plus précise est à poids ouverts. Moonshot a publié les poids du modèle sous la Kimi K3 License. Consultez directement cette licence avant toute redistribution commerciale ou autre usage où les conditions de licence comptent.

What is the easiest way to use Kimi K3 without local GPUs?

Une API hébergée est la voie la plus simple. Kimi K3 est disponible via CometAPI avec une interface chat-completions compatible OpenAI, de sorte que le code applicatif peut rester proche de ce que vous utiliseriez face à un serveur vLLM ou SGLang local.