Kimi K3 : combien de GPU pour l’auto-héberger ?

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 ouverts au format MXFP4, qui utilise environ un demi-octet par poids. Les seuls poids occupent donc environ 1.4 To avant même de réserver 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œuds. Pour un seul serveur, la réponse est donc non.

C’est la conclusion. Tout ce qui suit présente les calculs qui la justifient, car ce sont ces calculs que vous pourrez réutiliser lors de la prochaine release. Plusieurs fournisseurs d’infrastructure ont publié des guides de déploiement de K3 dans les semaines qui ont suivi l’annonce du 17 juillet 2026. Tous partaient du principe que vous possédiez déjà un cluster. Cette page part du point de vue inverse : combien cela coûte, ce que vous pouvez faire fonctionner à la place et comment déterminer dans lequel de ces deux cas 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. Un MoE (mixture of experts) divise le réseau en plusieurs sous-réseaux et permet à un routeur d’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 « est-ce que je peux exécuter ce modèle ? ».

Les paramètres actifs déterminent le coût de calcul. Pour chaque token, le calcul utilise environ 104B paramètres. Le débit attendu est donc comparable à celui d’un modèle dense de 104B paramètres, et non de 2.8T. 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 chargés avant l’arrivée de la première requête. Il est impossible de conserver 104B paramètres en VRAM et de charger le reste à la demande : ce chargement devrait être terminé en quelques microsecondes, alors qu’une liaison PCIe ne transfère que quelques dizaines de gigaoctets par seconde. Certains essaient malgré tout. La lecture des experts depuis un NVMe transforme un modèle qui devrait produire plusieurs 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. Évaluez le débit attendu comme pour un modèle de 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, c’est toute la formule.

[
  {
    "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 prise en compte de la quantification et distribué avec des poids MXFP4 et des activations MXFP8. La ligne 4 bits est donc la valeur réelle. Les lignes supérieures servent de référence : en bf16, le même modèle nécessiterait 5.6 To. MXFP4 stocke également une échelle 8 bits partagée 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 To que de 1.4 To tout rond.

Cela élimine l’échappatoire habituelle. « Il suffit de le quantifier » n’aide pas ici, car le checkpoint distribué est déjà en 4 bits. Passer à 2 bits ramènerait les poids à 0.7 To et ferait perdre en précision, sans mesure disponible pour ce checkpoint. Vous resteriez très au-delà des capacités d’une seule carte.

Combien de GPU Kimi K3 nécessite-t-il

[
  {
    "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, et non comme un objectif. Elles comptabilisent uniquement les poids : ni le cache KV, ni les buffers d’activations, ni la fragmentation de l’allocator, ni l’espace nécessaire pour traiter une deuxième requête simultanée. Elles supposent également une répartition parallèle équilibrée, ce que les 93 couches et les 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, et le cookbook SGLang fournit une configuration H100 composée de quatre nœuds de 8 GPU, soit 32 GPU et 2,560 GB de mémoire cumulée, contre un minimum de 18 cartes. Cet écart n’est pas du gaspillage. Il couvre le cache KV, la mémoire des activations et la marge nécessaire pour que le serveur traite de nombreuses requêtes par batch. 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 à la location sous la forme d’une 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, puis de nouveau avec chaque utilisateur simultané. Pour l’attention classique, la formule est bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element. Il faut ensuite multiplier le résultat par la longueur du contexte et par la simultanéité.

Voici un exemple détaillé, qui reste uniquement un exemple : 64 couches, 8 têtes KV, une dimension de tête de 128 et du fp8. On obtient 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 utilisateur consomme 128 GiB. C’est plus que la capacité de n’importe quelle carte unique, 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, tandis que MLA compresse la clé et la valeur dans un seul vecteur latent de faible rang. Le coût réel par token est donc nettement inférieur à celui de l’exemple détaillé. Moonshot n’a pas publié les dimensions latentes. Je ne donnerai donc pas de valeur par utilisateur pour K3 lui-même. Mesurez plutôt votre configuration : 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 pour la prochaine release. Si un modèle annonce un contexte d’un million de tokens sans préciser la conception de son mécanisme d’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 K3 lui-même. 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 à 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 entre les coûts. Faire fonctionner 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 dimensionnée 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, et 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 de lui 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 répertorie 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 a été livré avec KDA et une nouvelle couche MoE que les versions stables de vLLM et SGLang ne prenaient pas encore en charge à leur sortie. Le serveur s’arrête alors 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 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, pas 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. Préchargez les poids sur un volume qui reste disponible après la suppression de l’instance, afin que le deuxième démarrage se fasse 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 explicitement avant de commencer, car la plupart des discussions sur l’exécution de K3 en local s’arrêtent ici sans le reconnaître.

La règle de dimensionnement repose sur la même formule, en plus petit : le nombre de paramètres multiplié par le nombre d’octets par poids, auquel s’ajoutent le cache KV et environ 2 GB de surcharge d’exécution, doit rester inférieur à votre VRAM. En 4 bits, cela représente environ un demi-octet par paramètre, ce qui permet les associations suivantes :

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

Chaque association ci-dessus suppose une seule requête à la fois. Dès qu’une deuxième personne envoie un prompt, chaque emplacement concurrent nécessite son propre cache KV. C’est le compromis que les paramètres NUM_PARALLEL et MAX_QUEUE d’Ollama gèrent pour vous entre les emplacements parallèles, les requêtes mises en file d’attente et la VRAM restante.

Ollama est le chemin le plus court vers 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 affiche 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, y compris l’unité systemd et l’accès distant, est présentée dans exécuter Ollama sur un VPS.

llama.cpp vous donne davantage de contrôle sur la quantification et l’offload :

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 toutes les couches soient chargées sur le GPU. Consultez le journal de chargement : il indique le nombre de couches transféré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. Les compromis entre les deux outils sont expliqué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 indique généralement que la clé est incorrecte ou que le préfixe Bearer est manquant. Une erreur indiquant que le modèle est introuvable signifie généralement que son identifiant a changé, car les fournisseurs retirent certains identifiants entre deux checkpoints.

Passons au seuil de rentabilité, en utilisant le tarif de location indiqué plus haut. Un nœud équipé de 8 GPU et actif en permanence coûte 14,400 USD par mois. Au tarif de 15.00 USD par million de tokens de sortie, cette même somme permet d’acheter environ 960 millions de tokens de sortie via l’API. Pour être moins cher, il faut 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 occupé 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é, et non au tarif de 3.00 USD lorsque le cache ne l’est pas.

À 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 au client, les journaux des requêtes et des réponses, les nouvelles tentatives, les limites de débit et les budgets par utilisateur. Cet ensemble peut fonctionner sur un petit VPS sans aucun GPU. La même séparation s’applique aux poids fermés : l’auto-hébergement de Claude n’est pas possible au niveau du modèle, et l’orchestration est la seule partie que vous contrôlez.

À quelle couche correspond chaque stack de serving

Les serveurs comme vLLM et SGLang appartiennent à la couche 1. Ils sont conçus pour traiter de nombreuses requêtes simultanément, avec le continuous batching et un cache KV paginé, ainsi que le tensor parallelism et l’expert parallelism répartis sur plusieurs nœuds. Ils supposent l’utilisation d’accélérateurs de datacenter et d’une interconnexion rapide entre ceux-ci. Sur une seule carte grand public, leur installation est plus lourde et leurs avantages sont peu perceptibles.

llama.cpp et Ollama appartiennent à la couche 2. Ils ciblent une seule machine, la quantification GGUF, l’offload vers le CPU lorsque le modèle ne tient pas en mémoire, et une faible concurrence. llama.cpp peut techniquement charger un MoE gigantesque en conservant la plupart des couches dans la RAM système, mais avec un modèle de 2.8T, cette approche produit un débit de quelques secondes par token. Cela prouve seulement que le fichier peut être analysé. Ce n’est pas un service que vous pouvez mettre à la disposition d’utilisateurs. La comparaison complète se trouve dans Ollama face à vLLM, et elle ne change pas selon le modèle : la question est toujours de savoir si vous servez plusieurs 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. Une fois que la release est déjà en 4 bits, aucune astuce de quantification ne le réduit beaucoup.
2. Le nombre de paramètres actifs détermine la classe de débit. Un modèle MoE de 2.8T avec 104B paramètres actifs effectue les calculs d’un modèle de 104B.
3. Le cache KV par token, multiplié par la longueur du contexte et par le nombre de requêtes concurrentes, correspond au 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 une offre. Tout le reste sert à le calculer.

Appliquez ces quatre critères à n’importe quelle release pour obtenir la bonne réponse avant même d’ouvrir la documentation d’un fournisseur. Datez ensuite chaque chiffre que vous notez. Les prix et les listes d’architectures prises en charge ont tous deux changé dans les deux semaines qui ont suivi le lancement de K3, et chaque chiffre de cette page provient d’une publication de 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 utilisée dans la version publiée par Moonshot, et le plus grand accélérateur disponible à la vente possède 288 GB de mémoire. Un modèle MoE ne peut pas charger ses experts inactifs depuis le disque à une vitesse exploitable, car le routeur peut sélectionner n’importe quel expert pour chaque token et une lecture via PCIe prend beaucoup plus de temps que le budget disponible par token. Le plus petit déploiement K3 raisonnable est un nœud doté de plusieurs GPU, et les recettes publiées utilisent au moins 32 accélérateurs.

De quelle quantité de VRAM Kimi K3 a-t-il besoin ?

Commencez par 1.4 TB pour les seuls poids, soit 18 cartes H100 de 80GB ou 5 cartes de classe GB300. Ajoutez ensuite la mémoire du KV cache et celle des activations. En août 2026, Moonshot recommande au moins 64 accélérateurs, et le cookbook SGLang publie une configuration de 32 GPU H100 avec 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 de manière exploitable. 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. Passer à nouveau à 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. 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 exécuté en permanence 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 devez également payer les heures d’inactivité, le téléchargement des poids et la personne chargée de maintenir le cluster en fonctionnement. Louez les GPU à l’heure pour les pics de charge et comparez le coût avec votre volume de tokens réellement mesuré, plutôt qu’avec une estimation.

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

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