Auto-héberger Kimi K3 : matériel et VRAM nécessaires

Ce qu’il faut pour auto-héberger Kimi K3

Auto-héberger Kimi K3 signifie trouver de la place pour 2.8 billions de paramètres. Moonshot a publié les poids du modèle en MXFP4, soit environ un demi-octet par poids. Les seuls poids occupent donc environ 1.4 TB avant même d’allouer un seul token de cache. Aucun accélérateur actuellement commercialisé ne peut contenir cette quantité à lui seul. K3 est un modèle multi-nœud. Sur un seul serveur, la réponse est donc non.

C’est la conclusion. Tout ce qui suit détaille les calculs, car ce sont ces calculs que vous pourrez réutiliser pour la prochaine version. Plusieurs fournisseurs d’infrastructure ont publié des guides de déploiement de K3 dans les semaines qui ont suivi l’annonce du 17 July 2026. Tous partaient du principe que vous disposiez déjà d’un cluster. Cette page aborde le problème dans l’autre sens : combien cela coûte, ce que vous pouvez exécuter à la place et comment déterminer dans laquelle de ces deux situations vous vous trouvez.

Le nombre total de paramètres et le nombre de paramètres actifs ne sont pas identiques

K3 est un modèle à mélange d’experts. Le MoE (mixture of experts) répartit le réseau entre de nombreux sous-réseaux et laisse un routeur en sélectionner quelques-uns pour chaque token. La fiche du modèle indique 2.8T paramètres au total et 104B paramètres activés par token, parmi 896 experts routés, dont 16 sont activés pour chaque token, sur 93 couches.

Ces deux nombres de paramètres répondent à des questions différentes. Les confondre est l’erreur la plus fréquente dans les discussions « puis-je exécuter ce modèle ? ».

Les paramètres actifs déterminent le coût de calcul. Un token est traité par environ 104B paramètres. Le débit attendu est donc comparable à celui d’un modèle dense de 104B paramètres, et non à celui d’un modèle de 2.8T paramètres. C’est précisément l’intérêt d’un MoE.

Le nombre total de paramètres détermine le coût mémoire. Le routeur peut sélectionner n’importe quel expert pour n’importe quel token. Tous les experts doivent donc être présents en mémoire avant l’arrivée de la première requête. Vous ne pouvez pas conserver 104B paramètres en VRAM et charger le reste à la demande : le chargement devrait être terminé en quelques microsecondes, alors qu’une liaison PCIe transfère quelques dizaines de gigaoctets par seconde. Certains essaient malgré tout. La lecture des experts depuis un stockage NVMe transforme un modèle qui devrait produire des dizaines de tokens par seconde en un modèle qui ne produit plus qu’un token toutes les quelques secondes.

Le calcul est donc peu coûteux, mais le stockage est coûteux. Dimensionnez le matériel pour 2.8T paramètres. Basez vos attentes de débit sur 104B paramètres.

Octets par poids et origine des téraoctets

Nombre de paramètres multiplié par le nombre d’octets par poids. Pour les poids, la formule est complète.

[
  {
    "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 a été entraîné avec une quantification prise en compte pendant l’entraînement, puis publié avec des poids MXFP4 et des activations MXFP8. La ligne 4 bits est donc la ligne réelle. Les lignes supérieures servent de référence : en bf16, le même modèle nécessiterait 5.6 TB pour ses poids. MXFP4 stocke également un facteur d’échelle partagé sur 8 bits pour chaque bloc de 32 poids, ce qui ajoute environ 6 %, si bien que le dépôt publié est plus proche de 1.5 TB que de 1.4 TB.

Cela élimine l’échappatoire habituelle. « Il suffit de le quantifier » n’aide pas ici, car le checkpoint publié est déjà en 4 bits. Passer à 2 bits réduirait les poids à 0.7 TB, au prix d’une perte de précision que personne n’a mesurée sur ce checkpoint. Vous resteriez toutefois très loin de la capacité d’une seule carte.

De combien de GPU Kimi K3 a-t-il besoin

[
  {
    "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
  }
]

Considérez ces valeurs comme un minimum, pas comme une cible. Elles comptent uniquement les weights : ni le KV cache, ni les buffers d’activation, ni la fragmentation de l’allocator, ni la marge nécessaire pour traiter une deuxième requête simultanée. Elles supposent également une répartition parallèle équilibrée, ce que 93 layers et 896 experts ne permettent pas toujours.

Les recommandations publiées sont nettement supérieures à ce minimum. En août 2026, Moonshot recommande un supernode équipé d’au moins 64 accélérateurs. Le cookbook SGLang fournit aussi une configuration H100 composée de quatre nœuds de 8 GPU, soit 32 GPU et 2,560 GB de mémoire agrégée, contre un minimum de 18 cartes. Cet écart n’est pas du gaspillage. Il correspond au KV cache, à la mémoire d’activation et à la marge nécessaire pour que le serveur traite de nombreuses requêtes par lots. Même la ligne la plus favorable, avec 5 cartes de classe GB300, décrit une machine que la plupart des fournisseurs ne proposent pas comme SKU unique.

Le cache KV est la partie qui surprend

Les poids représentent un coût fixe. Le cache KV (key value) ne l’est pas : il augmente avec la longueur du contexte et avec chaque utilisateur simultané. Pour l’attention classique, la formule est bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element, puis il faut multiplier par la longueur du contexte et par la concurrence.

Voici un exemple de calcul, et ce n’est qu’un exemple : 64 couches, 8 têtes KV, une dimension de tête de 128 et fp8. Cela donne 2 64 8 128 1 = 131,072 octets, soit 128 KiB par 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 utilisateur avec un contexte de 128k consomme 16 GiB. Avec le million de tokens complet, un seul utilisateur consomme 128 GiB, soit plus que la capacité de n’importe quelle carte prise individuellement, pour une seule conversation.

K3 n’utilise pas l’attention classique, et c’est précisément la raison de ce dernier chiffre. Ses 93 couches comprennent 69 couches KDA (Kimi Delta Attention) et 24 couches Gated MLA (multi-head latent attention). KDA conserve un état récurrent de taille fixe au lieu d’un cache qui augmente avec chaque token, et MLA compresse la clé et la valeur dans un seul vecteur latent de faible rang. Le coût réel par token est donc largement inférieur à celui de l’exemple. Moonshot n’a pas publié les dimensions latentes. Je ne donnerai donc pas de valeur par utilisateur pour K3. Mesurez-la sur votre système : démarrez le serveur avec une petite valeur de --max-model-len, surveillez la mémoire avec nvidia-smi, puis augmentez la limite jusqu’à l’échec de l’allocation.

Le raisonnement reste valable dans la prochaine release. Si un modèle annonce un contexte d’un million de tokens sans rien préciser sur sa conception de l’attention, considérez que le cache est la contrainte principale jusqu’à preuve du contraire.

Niveau 1 : louer le cluster à l’heure

C’est le seul niveau qui exécute réellement K3. Vous n’achetez pas le matériel. Vous le louez pendant les heures nécessaires, puis vous l’arrêtez.

[
  {
    "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"
  }
]

Le tarif est une hypothèse, pas un devis. Les tarifs publics à la demande des accélérateurs de datacenter se situaient environ entre 2 et 5 USD par heure et par GPU jusqu’en 2026, et la capacité réservée coûte moins cher. Utilisez le tarif réel de votre fournisseur et refaites le calcul : nombre de GPU multiplié par le nombre d’heures, puis par le tarif. Le graphique sert à montrer le rapport. Utiliser un nœud de 8 GPU pendant quatre heures par jour coûte 2,400 USD par mois, tandis que laisser tourner la configuration SGLang prévue pour 32 GPU coûte 57,600 USD.

Les deux serveurs courants publient une commande de lancement sur la fiche du modèle.

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

Aucune de ces commandes brutes ne correspond à ce que vous exécutez sur un cluster réel. Ajoutez les options de parallélisme adaptées à votre matériel : SGLang utilise --tp-size pour le parallélisme tensoriel et --ep-size pour le parallélisme des experts. Le produit de ces deux valeurs doit être égal au nombre réel de GPU disponibles.

Vérifiez que le serveur a démarré avant d’envoyer du trafic réel :

curl http://127.0.0.1:30000/v1/models

Un serveur opérationnel répond avec un objet JSON qui contient l’identifiant du modèle. Connection refused signifie que le processus charge encore les poids ou qu’il s’est déjà arrêté. Consultez donc le journal du serveur avant de réessayer.

Le problème le plus fréquent le premier jour est un runtime plus ancien que le modèle. K3 est sorti avec KDA et une nouvelle couche MoE que les versions stables de vLLM et SGLang ne prenaient pas encore en charge lors de son lancement. Le symptôme est l’arrêt du serveur pendant le démarrage, avec une ligne de la forme Model architectures [...] are not supported for now. Aucun changement de configuration ne peut résoudre ce problème, car le code nécessaire à l’exécution de ces couches n’est pas présent dans votre build. Installez la version nightly indiquée sur la fiche du modèle ou attendez la version qui l’intègre.

Un point de coût est souvent oublié. La facturation commence au démarrage de l’instance, et non lorsque le modèle est prêt. Le téléchargement de 1.5 TB à 1 GB/s prend environ 25 minutes de temps de cluster avant la génération du premier token. Stockez les poids sur un volume qui reste disponible après la suppression de l’instance. La deuxième exécution démarrera ainsi en quelques minutes.

Niveau 2 : exécuter un modèle plus petit sur un seul accélérateur

Vous n’exécutez pas K3 à ce niveau. Dites-le clairement avant de commencer, car la plupart des discussions sur l’exécution locale de K3 s’arrêtent ici sans le reconnaître.

La règle d’adéquation repose sur la même formule, à plus petite échelle : le nombre de paramètres multiplié par le nombre d’octets par poids, plus le cache KV et environ 2 GB de surcharge d’exécution, doit tenir dans votre VRAM. En 4-bit, cela représente environ un demi-octet par paramètre. Vous obtenez ainsi des associations adaptées :

• Carte de 16 GB : modèle 7B en 4-bit, avec suffisamment de marge pour un long contexte
• Carte de 24 GB : modèle 14B en 4-bit
• Carte de 48 GB : modèle 32B en 4-bit
• Carte de 80 GB : modèle 70B en 4-bit, ou MoE de classe 30B en 8-bit

Ollama est le moyen le plus direct d’obtenir un serveur fonctionnel sur un VPS équipé d’un GPU :

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama run télécharge le modèle lors de la première utilisation, puis vous donne accès à une invite. Un tag inexistant renvoie Error: model "..." not found. Copiez donc les tags depuis la page de la bibliothèque au lieu de les saisir de mémoire. La procédure complète, avec l’unité systemd et l’accès distant, se trouve dans exécuter Ollama sur un VPS.

llama.cpp vous donne davantage de contrôle sur la quantification et le déport des couches :

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 demande que chaque couche soit chargée sur le GPU. Consultez le journal de chargement : il indique le nombre de couches déportées. Les couches qui débordent dans la RAM système s’exécutent à la bande passante de la RAM, et non à celle de la HBM. La vitesse de génération chute donc d’un ordre de grandeur dès que le modèle ne tient plus dans la mémoire disponible. Les compromis entre les deux outils sont présentés dans Ollama et llama.cpp en comparaison directe.

Niveau 3 : API hébergée, orchestration auto-hébergée

[
  {
    "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 est compatible avec OpenAI. Un client existant fonctionne donc après modification de l’URL de 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."}]}'

Une clé valide renvoie un objet JSON contenant un tableau choices. Une erreur 401 signifie généralement que la clé est incorrecte ou que le préfixe Bearer est absent. Une erreur indiquant que le modèle est introuvable signifie généralement que son identifiant a changé, car les fournisseurs retirent des identifiants entre deux checkpoints.

Calculons maintenant le seuil de rentabilité avec le tarif de location retenu plus haut. Un nœud équipé de 8 GPU et exécuté en permanence coûte 14,400 USD par mois. Au tarif de 15.00 USD par million de tokens de sortie, la même somme permet d’acheter environ 960 millions de tokens de sortie auprès de l’API. Pour réduire les coûts, vous devez donc générer près d’un milliard de tokens de sortie par mois, soit environ 30 millions par jour, et maintenir le cluster chargé en permanence. Les GPU inactifs sont facturés au même tarif que les GPU utilisés. Les workloads d’agents fortement dépendants du prompt éloignent encore ce seuil : le contexte répété est facturé au tarif de 0.30 USD par million lorsque le cache est utilisé, au lieu du tarif de 3.00 USD lorsque le cache n’est pas utilisé.

Dans ce niveau, vous auto-hébergez tout ce qui entoure le modèle : une gateway qui conserve la clé API afin qu’elle ne parvienne jamais à un client, les journaux des requêtes et des réponses, les nouvelles tentatives, les limites de débit et les budgets par utilisateur. Ces composants peuvent fonctionner sur un petit VPS sans aucun GPU. La même séparation s’applique aux modèles dont les poids sont propriétaires : auto-héberger Claude n’est pas possible au niveau du modèle, et l’orchestration est la seule partie que vous contrôlez.

Quelle stack de serving correspond à quel niveau

Les serveurs de la catégorie vLLM et SGLang appartiennent au niveau 1. Ils sont conçus pour traiter de nombreuses requêtes simultanément, avec du continuous batching et un cache KV paginé, ainsi qu’un parallélisme tensoriel et par experts réparti sur plusieurs nœuds. Ils supposent l’utilisation d’accélérateurs de datacentre et d’une interconnexion rapide entre ces accélérateurs. Sur une seule carte grand public, leur installation est plus lourde et leurs avantages sont peu perceptibles.

llama.cpp et Ollama appartiennent au niveau 2. Ils ciblent une seule machine, la quantification GGUF, le déport vers le CPU lorsque le modèle ne tient pas en mémoire, et une faible concurrence. llama.cpp peut techniquement charger un très grand modèle MoE en conservant la plupart des couches dans la RAM système, mais avec un modèle de 2.8T cette approche atteint plusieurs secondes par token. Cela prouve seulement que le fichier peut être analysé. Ce n’est pas un service auquel vous pouvez connecter des utilisateurs. La comparaison complète se trouve dans Ollama face à vLLM, et elle ne dépend pas du modèle : la question est toujours de savoir si vous servez de nombreux utilisateurs sur du matériel partagé ou un seul utilisateur sur votre propre machine.

Les quatre chiffres qui restent valables après ce point de contrôle

1. Le nombre total de paramètres multiplié par le nombre d’octets par poids donne le plancher mémoire. Rien ne peut fonctionner en dessous, et aucune méthode de quantification ne le réduit beaucoup une fois que la version est déjà en 4-bit.
2. Le nombre de paramètres actifs détermine la classe de débit. Un MoE de 2.8T avec 104B de paramètres actifs effectue les calculs comme un modèle de 104B.
3. Le cache KV par token, multiplié par la longueur du contexte et par le niveau de concurrence, représente le coût qui continue d’augmenter après le chargement des poids.
4. Le nombre de tokens par seconde et par dollar est le seul chiffre qui permet de choisir un niveau de gamme. Tous les éléments précédents servent à le calculer.

Appliquez ces quatre critères à n’importe quelle version pour obtenir la bonne réponse avant même de consulter le guide d’un fournisseur. Datez ensuite chaque chiffre que vous notez. Les prix et les listes d’architectures prises en charge ont tous deux changé au cours des deux semaines qui ont suivi la sortie de K3, et chaque chiffre de cette page a été publié en juillet 2026.

FAQ

Puis-je exécuter Kimi K3 sur un seul GPU ?

Non. Les poids occupent environ 1.4 TB avec la précision MXFP4 fournie par Moonshot, tandis que le plus grand accélérateur disponible à la vente offre 288 GB. Un modèle MoE ne peut pas charger ses experts inactifs depuis le disque à une vitesse utilisable, car le router peut sélectionner n’importe quel expert pour n’importe quel token et une lecture via PCIe prend beaucoup plus de temps que le budget disponible par token. Le plus petit déploiement raisonnable de K3 est un nœud équipé de plusieurs GPU. Les recettes publiées utilisent 32 accélérateurs ou plus.

De combien de VRAM Kimi K3 a-t-il besoin ?

Comptez d’abord 1.4 TB pour les poids seuls. Cela correspond à 18 cartes H100 80GB ou à 5 cartes de classe GB300. Ajoutez ensuite le KV cache et la mémoire nécessaire aux activations. En août 2026, Moonshot recommande 64 accélérateurs ou plus. Le cookbook SGLang publie une configuration avec 32 GPU H100 et 2,560 GB au total. Considérez donc la taille des poids comme un minimum, et non comme une configuration suffisante.

La quantification permet-elle d’exécuter Kimi K3 sur un seul nœud ?

Pas dans des conditions réellement utiles. Le checkpoint publié est déjà en 4 bits et a été entraîné avec prise en compte de la quantification. Le gain facile a donc déjà été obtenu. Une réduction supplémentaire à 2 bits ramène les poids à 0.7 TB, ce qui représente encore plus du double de la capacité de la plus grande carte. En outre, le coût en précision du 2 bits n’a pas été mesuré sur ce modèle.

La location de GPU coûte-t-elle moins cher que l’API Kimi K3 ?

Seulement avec un volume élevé et régulier. En supposant un tarif de 2.50 USD par heure et par GPU, un nœud de 8 GPU fonctionnant en continu coûte 14,400 USD par mois. Cette même somme permet d’acheter environ 960 millions de tokens de sortie au tarif publié de 15.00 USD par million. Vous payez également les heures d’inactivité, le téléchargement des poids et la personne chargée de maintenir le cluster opérationnel. Louez les GPU à l’heure pour les pics de charge. Comparez ensuite le coût avec votre propre volume de tokens mesuré, et non avec une estimation.

Que signifie 104B paramètres actifs pour la vitesse ?

Cela signifie que le calcul nécessaire pour chaque token correspond à celui d’un modèle 104B. Le débit se situe donc dans cette catégorie, et non dans celle des modèles 2.8T. Cela ne renseigne pas sur la mémoire : les 2.8T paramètres restent chargés, car le router peut appeler n’importe quel expert pour n’importe quel token. Utilisez le nombre de paramètres actifs pour estimer le nombre de tokens par seconde. Utilisez le nombre total de paramètres pour dimensionner la VRAM.