Auto-héberger Kimi K3 : calcul VRAM et faisabilité

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 en MXFP4, soit environ un demi-octet par poids ; les poids seuls atteignent donc environ 1.4 To avant même d'allouer le moindre jeton de cache. Aucun accélérateur disponible à la vente aujourd'hui ne peut contenir cela seul. Pour un seul GPU, la réponse est non. Pour un serveur, la réponse est oui, sous deux formes. La première est un nœud à 8 GPU de 288 Go, ce qui correspond aux plus petites recettes de service multi-utilisateurs publiées. La seconde est une machine dotée d'environ 1,6 To de RAM et VRAM combinées, exécutant le format Q8 GGUF sans perte d'Unsloth dans llama.cpp, avec ou sans GPU, pour servir un utilisateur à la fois.

Voilà le verdict. Tout ce qui suit détaille l'arithmétique sous-jacente, car c'est cette méthode que vous réutiliserez pour la prochaine version. Plusieurs fournisseurs d'infrastructure ont publié des guides de déploiement pour K3 dans les semaines suivant l'annonce du 16 juillet 2026, et chacun supposait que vous possédiez déjà un cluster. Cette page aborde le problème sous l'angle opposé : les coûts, les alternatives possibles et la manière de déterminer si vous êtes dans l'un ou l'autre de ces deux cas de figure.

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 (mélange d’experts) divise le réseau en 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 « est-ce que je peux exécuter ce modèle ? ».

Les paramètres actifs déterminent le coût de calcul. Pour chaque token, les calculs utilisent 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 stockés dans une mémoire suffisamment rapide avant l’arrivée de la première requête. Il est possible de conserver uniquement les experts fréquemment utilisés dans la VRAM et de charger les autres à la demande : llama.cpp avec --moe-cache-mib maintient un cache d’experts sur le GPU, tandis que les autres résident dans la RAM système et que les experts manquants sont transférés au fur et à mesure que le routeur les sélectionne. Cela ne réduit toutefois pas la taille totale. Les autres experts doivent toujours rester en RAM. De plus, une liaison PCIe transfère des dizaines de gigaoctets par seconde, contre plusieurs téraoctets par seconde pour la HBM. Chaque défaut de cache entraîne donc une perte de temps. Charger les experts depuis un stockage NVMe parce que le modèle ne tient pas non plus en RAM est encore plus lent. Le guide K3 d’Unsloth précise que le déport vers le disque est nettement plus lent.

Le calcul est donc peu coûteux, mais le stockage est coûteux. Dimensionnez le matériel pour 2.8T. Dimensionnez vos attentes en matière de vitesse pour 104B.

Octets par poids, et origine des téraoctets

Nombre de paramètres multiplié par les octets par poids. Pour les poids, c'est la formule 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 consciente (quantisation aware) et publié avec des poids en MXFP4 et des activations en MXFP8 ; la ligne 4 bits est donc la valeur réelle. Les lignes au-dessus servent d'échelle : en bf16, le même modèle nécessiterait 5.6 To. MXFP4 stocke également une échelle partagée de 8 bits pour chaque bloc de 32 poids, ce qui ajoute environ 6 pour cent. De plus, la configuration de Moonshot exclut l'attention, les experts partagés et la tour de vision du format 4 bits. Le checkpoint complet atteint donc environ 1,56 To selon le calcul d'Unsloth, plutôt qu'un 1.4 To théorique.

Cela réduit l'échappatoire habituelle sans pour autant la fermer. Le checkpoint publié est déjà en 4 bits, l'économie facile est donc déjà réalisée, mais descendre plus bas modifie encore le chiffre. Au 27 octobre 2026, les quantifications GGUF dynamiques de K3 mesurées par Unsloth vont de 861,3 Go pour le UD-Q2_K_XL 2 bits jusqu'à 594 Go pour le UD-IQ1_S 1 bit. Unsloth publie le coût de cette opération : l'accord sur le top-1 token avec le modèle complet est de 90,390 pour cent pour le UD-Q2_K_XL, 84,127 pour cent pour le UD-IQ2_XXS de 711,1 Go et 78,875 pour cent pour le UD-IQ1_S. Son dépôt Hugging Face propose également des fichiers 1 bit plus petits, descendant jusqu'à 466 Go pour le UD-Q1_0, sans chiffre d'accord publié associé. Il s'agit d'une perte de précision mesurée, et même le plus petit fichier représente encore environ 1,6 fois la capacité de la plus grande carte unique.

Combien de GPU sont nécessaires pour Kimi K3

[
  {
    "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 chiffres comme un minimum, pas comme un objectif. Ils ne comptabilisent que les poids : aucun cache KV, aucun tampon d'activation, aucune fragmentation de l'allocateur, et aucune marge pour une seconde requête simultanée. Le découpage n'a pas besoin d'être uniforme : le parallélisme de pipeline de vLLM répartit le modèle par couches et supporte des découpages inégaux, et les recettes de pré-remplissage K3 de SGLang exécutent 8 et 16 étapes de pipeline sur 93 couches.

Les recommandations publiées se situent au-dessus de ce minimum. Les directives de lancement de Moonshot recommandaient un supernœud de 64 accélérateurs ou plus. Au 27 octobre 2026, le cookbook SGLang propose une configuration H100 construite à partir de quatre nœuds de 8 GPU, soit 32 GPU et 2 560 Go de mémoire agrégée, par rapport à un minimum de 18 cartes. Il liste également des recettes sur un seul nœud pour un nœud B300 de 8 GPU et un nœud MI350X ou MI355X de 8 GPU, avec 2 304 Go à raison de 288 Go par carte. Cet écart au-dessus du minimum n'est pas du gaspillage. Il s'agit du cache KV, de la mémoire d'activation et de la marge de manœuvre qui permet au serveur de traiter de nombreuses requêtes simultanément. La ligne la plus accessible, les cartes de classe 5 GB300, s'arrondit en pratique exactement à ce type de nœud de 8 GPU, qui constitue la plus petite machine pour laquelle une recette de service K3 multi-utilisateurs est publiée.

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 de nouveau avec chaque utilisateur concurrent. Pour une attention ordinaire, la formule est bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element, puis vous multipliez le résultat par la longueur du contexte et par la concurrence.

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 contexte complet d’un million de tokens, un utilisateur consomme 128 GiB. Cela représente presque la moitié d’une carte de 288 GB pour une seule conversation, avant même de charger le moindre poids.

K3 n’utilise pas une attention ordinaire, et c’est 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 à chaque token. MLA compresse les clés et les valeurs en un vecteur latent unique de faible rang. Le coût réel par token est donc nettement inférieur à celui de l’exemple détaillé. Le fichier config.json publié par Moonshot indique une taille de latent de kv_lora_rank à 512, plus une clé rotative de largeur 64 (qk_rope_head_dim), soit 576 valeurs par token et par couche MLA. Sur 24 couches, avec 2 octets par valeur, cela représente 27,648 octets, soit environ 27 KiB par token, ou environ 27 GiB pour une conversation complète de 1,048,576 tokens, auxquels il faut ajouter l’état KDA fixe. Considérez ce chiffre comme une estimation et non comme une mesure : les moteurs ajoutent du padding et organisent le cache selon leurs propres méthodes. Un cache 8-bit réduit approximativement cette consommation de moitié.

Pour voir ce que contient votre propre déploiement, ne surveillez pas nvidia-smi pendant que vous augmentez --max-model-len. vLLM préalloue son pool de cache KV. Sa taille est calculée à partir de --gpu-memory-utilization (0.92 par défaut dans la documentation actuelle) ou d’un budget de cache explicite par GPU. La mémoire GPU totale affiche donc la taille du pool, et non celle d’une seule conversation. Consultez plutôt le journal de démarrage : vLLM y indique la taille du cache KV en tokens et la concurrence maximale pour la longueur de contexte utilisée.

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

Niveau 1 : louer le cluster à l'heure

C'est le niveau qui permet de servir K3 à sa précision d'origine à de nombreux utilisateurs simultanément. Une machine dotée de suffisamment de RAM peut également héberger K3 à sa précision de sortie via le format Q8 GGUF d'Unsloth, qu'Unsloth qualifie de précision totale sans perte, mais cette méthode ne sert qu'un utilisateur à la fois et est traitée au niveau 2. Ici, vous n'achetez pas le matériel. Vous le louez pour les heures nécessaires et vous l'arrêtez ensuite.

[
  {
    "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 estimation, pas un devis. Les tarifs à la demande varient considérablement selon le fournisseur et la génération de GPU ; les composants de 288 Go requis par les recettes mono-nœud coûtent plus cher à l'heure qu'un H100, et la capacité réservée est moins onéreuse. Prenez le tarif réel de votre fournisseur et refaites le calcul : nombre de GPU multiplié par le nombre d'heures, multiplié par le tarif. L'intérêt du tableau réside dans le ratio. Faire tourner un nœud de 8 GPU pendant quatre heures par jour coûte 2,400 USD par mois, tandis que laisser tourner la configuration H100 de 32 GPU dimensionnée pour SGLang coûte 57,600 USD.

Les deux serveurs principaux 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 flags de parallélisme correspondant à votre matériel : SGLang utilise --tp-size pour le parallélisme tensoriel, --pp-size pour le parallélisme de pipeline et --ep-size pour le parallélisme d'experts. Le produit du parallélisme tensoriel par le parallélisme de pipeline doit être égal au nombre de GPU dont vous disposez réellement, et le parallélisme d'experts divise les experts au sein de ce groupe, ce qui explique pourquoi la recette H100 à 32 GPU définit à la fois --tp-size 32 et --ep-size 32.

Vérifiez que le serveur est opérationnel avant d'envoyer du trafic réel :

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

Un serveur en état de marche répond par un objet JSON listant l'identifiant du modèle. Connection refused signifie que le processus est encore en train de charger les poids ou qu'il a déjà quitté, lisez donc le journal du serveur avant de réessayer.

L'échec courant des premières semaines était un environnement d'exécution 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 en charge au lancement ; le symptôme est l'arrêt du serveur au démarrage avec une ligne de type Model architectures [...] are not supported for now. Aucun changement de configuration ne corrige cela, car le code nécessaire pour exécuter ces couches est absent de votre build. La situation a évolué : au 27 octobre 2026, SGLang intègre le support de K3 dans ses releases depuis la v0.5.17, la v0.5.22 étant la plus récente, et les notes de version de vLLM de la v0.28.0 à la v0.32.0 incluent toutes des travaux sur K3. Installez une version actuelle. Certains chemins spécifiques au matériel nomment encore une image dédiée, par exemple les builds NVFP4 de SGLang sur Blackwell ; vérifiez donc la recette correspondant à votre carte.

Une remarque sur les coûts qui surprend souvent : le compteur démarre au lancement de l'instance, pas au moment où le modèle est prêt. Un téléchargement de 1,56 To à 1 Go/s représente environ 26 minutes de temps de cluster avant le premier token. Stockez les poids sur un volume persistant au-delà de l'instance, afin que le second lancement ne prenne que quelques minutes.

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

Vous n'exécutez pas K3 dans ce niveau. Dites-le à voix haute avant de commencer, car la plupart des fils de discussion sur l'exécution locale de K3 s'arrêtent ici sans l'admettre.

La règle d'ajustement suit la même formule en miniature : les paramètres multipliés par les octets par poids, plus le cache KV, plus environ 2 Go de surcharge d'exécution, doivent tenir dans votre VRAM. À 4 bits, cela représente environ un demi-octet par paramètre, ce qui donne des combinaisons confortables :

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

Chaque combinaison ci-dessus suppose une requête à la fois. Dès qu'une deuxième personne envoie un prompt, chaque slot concurrent nécessite son propre cache KV. C'est le compromis que font pour vous les paramètres NUM_PARALLEL et MAX_QUEUE d'Ollama entre les slots parallèles, les requêtes en file d'attente et la VRAM qu'il vous reste.

Il existe une façon d'exécuter K3 lui-même sur une seule grosse machine, et elle se situe entre ce niveau et le précédent. Unsloth documente des builds GGUF de K3 dans llama.cpp, allant des quantifications 1 bit et 2 bits jusqu'au UD-Q8_K_XL, qu'il qualifie de précision totale sans perte, et cite une NVIDIA DGX Station comme matériel capable de les exécuter. Sa règle empirique est que la RAM plus la VRAM doivent être approximativement égales à la taille de la quantification, allant d'environ 610 Go pour le build 1 bit UD-IQ1_S à environ 1,6 To pour le Q8. En dessous de ce seuil, le modèle bascule sur le disque et ralentit brutalement. Un GPU est optionnel : les instructions de build d'Unsloth désactivent CUDA « si vous n'avez pas de GPU ou si vous voulez simplement faire de l'inférence CPU ». Les builds 1 bit et 2 bits sont des versions de K3 fortement quantifiées, au prix de la perte de précision mesurée précédemment. Le build Q8 est K3 à sa précision de sortie, servi à un utilisateur à la vitesse de la RAM. Aucun des deux n'est un modèle plus petit.

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 vous place devant un prompt. Un tag inexistant renvoie Error: model "..." not found, donc copiez les tags depuis la page de la bibliothèque plutôt que de les taper de mémoire. La procédure complète, incluant l'unité systemd et l'accès distant, se trouve dans exécuter Ollama sur un VPS.

llama.cpp vous donne plus 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 le déchargement de chaque couche sur le GPU. Lisez le journal de chargement : il indique combien de couches ont été déchargées. Les couches qui débordent sur la RAM système s'exécutent à la bande passante de la RAM au lieu de 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 entièrement dans la mémoire du GPU. Les compromis entre ces deux outils sont abordés dans Ollama et llama.cpp comparés.

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

Le point de terminaison 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 que l'authentification a échoué : vérifiez que la clé est correcte, qu'elle n'a pas expiré ou été désactivée, et que l'en-tête contient Authorization: Bearer suivi de la clé. Une erreur de type « modèle introuvable » signifie généralement que l'identifiant a changé, car les fournisseurs retirent les identifiants entre les points de contrôle.

Abordons maintenant le seuil de rentabilité, en utilisant le tarif de location supposé ci-dessus. Un nœud de 8 GPU fonctionnant en continu coûte 14,400 USD par mois. À 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 réduire les coûts, vous devez générer près d'un milliard de tokens de sortie par mois, soit environ 30 millions par jour, et maintenir le cluster en activité constante, car les GPU inactifs sont facturés au même tarif que les GPU actifs. Les charges de travail d'agents intensives en prompts éloignent encore davantage ce seuil : le contexte répété est facturé au tarif de cache hit de 0.30 USD par million, plutôt qu'au tarif de cache miss de 3.00 USD.

Dans ce niveau, vous auto-hébergez tout ce qui entoure le modèle : une passerelle qui conserve la clé API pour qu'elle n'atteigne jamais le client, les journaux de requêtes et de réponses, les tentatives de nouvelle tentative, les limites de débit et les budgets par utilisateur. Cela s'exécute sur un petit VPS sans aucun GPU. La même séparation s'applique aux poids fermés, où l'auto-hébergement de Claude n'est pas possible au niveau du modèle et où l'orchestration est la seule partie que vous contrôlez.

Quelle pile de service appartient à quel niveau

Les serveurs de classe vLLM et SGLang appartiennent au niveau 1. Ils sont conçus pour traiter de nombreuses requêtes simultanément, grâce au traitement par lots continu (continuous batching) et à un cache KV paginé, ainsi qu'au parallélisme de tenseurs et d'experts réparti sur plusieurs nœuds. Ils supposent l'utilisation d'accélérateurs de centre de données et une interconnexion rapide entre eux. Sur une carte grand public unique, ils sont plus lourds à installer et n'apportent que peu d'avantages perceptibles.

llama.cpp et Ollama appartiennent au niveau 2. Ils ciblent une machine unique, la quantification GGUF, le déchargement sur CPU lorsque le modèle ne tient pas en mémoire, et une faible concurrence. llama.cpp chargera un MoE massif en conservant les poids des experts dans la RAM système (--cpu-moe ou --n-cpu-moe) et, avec --moe-cache-mib, en mettant en cache les experts utilisés sur le GPU ; c'est ainsi que les builds K3 GGUF d'Unsloth s'exécutent sur une machine unique. La vitesse dépend alors de la bande passante de la RAM et de la fréquence à laquelle le routeur manque le cache ; si le fichier est plus volumineux que la somme de la RAM et de la VRAM, il bascule sur le disque. C'est une configuration viable pour un utilisateur. Ce n'est pas un service sur lequel vous pouvez placer de nombreux utilisateurs. La comparaison complète se trouve dans Ollama face à vLLM, et cela ne change pas avec le 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 survivent à ce point de contrôle

1. Le nombre total de paramètres multiplié par le nombre d'octets par poids donne le seuil minimal de mémoire. Rien ne s'exécute en dessous de ce seuil à la précision de la version fournie, et une quantification en dessous de 4-bit permet de gagner jusqu'à environ 70 pour cent au prix d'une perte de précision, mais pas d'un ordre de grandeur.
2. Les paramètres actifs déterminent la classe de débit. Un modèle MoE de 2.8T avec 104B actifs se calcule comme un modèle de 104B.
3. Le cache KV par token, multiplié par la longueur du contexte, multiplié par la concurrence, représente le coût qui continue de croître une fois le paiement des poids effectué.
4. Le nombre de tokens par seconde par dollar est le seul chiffre qui permet de choisir une gamme. Tout ce qui précède constitue des données d'entrée pour ce calcul.

Appliquez ces quatre points à n'importe quelle version et vous obtiendrez la réponse correcte avant même d'ouvrir un guide fournisseur. La prochaine version est déjà annoncée : Moonshot a déployé K3.1 Pro, basé sur K3 avec un post-entraînement supplémentaire, dans Kimi Code le 23 octobre 2026, et son guide de démarrage rapide pour l'API indique que les poids complets seront publiés d'ici le 4 novembre. Datez ensuite chaque chiffre que vous notez. Les prix et les listes d'architectures prises en charge ont tous deux évolué dans les deux semaines suivant le lancement de K3. Les chiffres de lancement sur cette page ont été publiés en juillet 2026, et les recettes de service, les versions de runtime et les chiffres de quantification ont été revérifiés le 27 octobre 2026.

FAQ

Puis-je faire tourner Kimi K3 sur un seul GPU ?

Non. Les poids pèsent environ 1.4 To dans la précision MXFP4 fournie par Moonshot. Même la plus petite quantification publiée de K3, le fichier UD-Q1_0 de 466 Go d'Unsloth, représente environ 1,6 fois la capacité de 288 Go des plus gros accélérateurs largement disponibles. llama.cpp peut conserver les experts en RAM système et mettre en cache les experts actifs sur le GPU, mais cela nécessite tout de même une quantité de RAM et de VRAM équivalente à la taille de la quantification. En dessous, le modèle bascule sur le disque et s'exécute beaucoup plus lentement. Les recettes de déploiement les plus petites utilisent un nœud de 8 GPU de type B300 ou MI350X/MI355X, et la recette pour H100 en utilise 32.

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

Partez sur une base de 1.4 To pour les poids seuls, ce qui correspond à 18 cartes H100 80 Go ou 5 cartes de classe GB300. Ajoutez ensuite la mémoire pour le cache KV et les activations. Les recommandations de lancement de Moonshot préconisaient 64 accélérateurs ou plus. Au 27 octobre 2026, le cookbook SGLang publie des recettes pour un seul nœud sur 8 cartes B300 ou 8 cartes MI350X/MI355X, soit 2 304 Go au total, et une configuration de 32 GPU H100 avec 2 560 Go au total ; considérez donc le chiffre des poids comme un minimum plutôt que comme une exigence stricte.

La quantification permet-elle à Kimi K3 de tenir sur un seul nœud ?

Le checkpoint 4-bit fourni tient déjà sur un nœud s'il est composé de huit cartes de 288 Go, ce qui correspond aux recettes B300 et MI355X de SGLang, ou sur une machine avec environ 1,6 To de RAM et VRAM via le format Q8 GGUF sans perte d'Unsloth. Réduire la quantification aide les machines plus petites : les builds GGUF dynamiques mesurés par Unsloth vont de 861,3 Go en 2-bit à 594 Go en 1-bit, et son dépôt liste des fichiers 1-bit descendant jusqu'à 466 Go, contre environ 1,56 To sans perte. Le coût en précision a été mesuré : la concordance top-1 avec le modèle complet tombe à 90,390 % pour le format UD-Q2_K_XL et à 78,875 % pour le format UD-IQ1_S. Aucun de ces formats ne tient sur une seule carte.

Louer des GPU est-il moins cher que l'API Kimi K3 ?

Uniquement avec un volume élevé et constant. En supposant un coût 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 devez également payer les heures d'inactivité, le téléchargement des poids et la personne qui maintient le cluster en état de marche. Louez à l'heure pour les pics de charge et comparez avec votre propre volume de tokens mesuré plutôt qu'avec une estimation.

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

Cela signifie que le calcul arithmétique par token est celui d'un modèle de 104B, donc le débit se situe dans cette classe plutôt que dans celle des 2,8T. Cela ne dit rien sur la mémoire : l'ensemble des 2,8T paramètres doit rester résident, car le routeur peut appeler n'importe quel expert pour n'importe quel token. Utilisez le nombre de paramètres actifs pour prédire le nombre de tokens par seconde, et le nombre total pour dimensionner la VRAM.