Kimi K3 chez soi : la vérité sur le matériel nécessaire (2.8T paramètres)

#Kimi K3 en local : ce que Moonshot a réellement publié

La fiche Hugging Face de Moonshot décrit Kimi K3 comme un modèle multimodal à poids ouverts de 2,8 billions de paramètres, avec une fenêtre de contexte d'un million de tokens. C'est un Mixture-of-Experts : 896 experts, dont 16 sont sélectionnés pour chaque token, pour 104 milliards de paramètres activés. Les poids sont distribués en MXFP4 (poids) avec des activations MXFP8, un entraînement conscient de la quantification ayant été appliqué dès la phase de fine-tuning supervisé. Le code et les poids relèvent de la « Kimi K3 License » : lisez ce texte avant tout usage commercial, car ce n'est pas une licence MIT ou Apache standard. Le modèle est arrivé sur Hugging Face autour du 27 juillet 2026 selon la presse spécialisée.

Paramètres totaux / actifs

2,8 T au total, 104 Md actifs par token (fiche Moonshot).

Experts

896 experts, 16 sélectionnés par token, plus 2 experts partagés.

Format publié

MXFP4 pour les poids, MXFP8 pour les activations. Ce n'est pas un GGUF.

Contexte

1 048 576 tokens, avec un cache KV qui s'ajoute à la mémoire des poids.

Moteurs recommandés

vLLM, SGLang et TokenSpeed. llama.cpp passe par les GGUF communautaires.

#Ce que pèsent vraiment les poids

Deux chiffres circulent, et il faut les distinguer. Certains articles estiment « de l'ordre de 1,4 To » en multipliant 2,8 T de paramètres par un demi-octet. La mesure des fichiers est plus haute : Unsloth et Runpod donnent 1,56 To pour la version native, parce que les couches hors experts (attention, routeurs, experts partagés) restent en précision supérieure. Le BF16 non quantifié atteindrait environ 5,6 To, d'après Runpod. La version de ce guide qui annonçait 1,4 To était donc trop basse d'environ 10 %.

Le tableau réfute une idée reçue de l'ancienne version : un Q2 n'est pas « toujours de l'ordre du téraoctet ». Unsloth propose bien des GGUF sous 900 Go. Mais 594 Go restent presque quinze fois la mémoire d'une RTX 5090 de 32 Go, et l'écart de qualité est réel : le 1 bit dynamique ne reproduit le choix du modèle d'origine que dans 78,9 % des cas sur le jeu de mesure d'Unsloth. Pour comprendre ce que les bits font à la qualité, voyez notre guide de quantification.

#Le matériel : ce qui est recommandé, ce qui est possible

Moonshot ne publie pas de configuration minimale sur la fiche du modèle : elle renvoie vers les recettes vLLM, SGLang et TokenSpeed et vers son API. La référence documentée pour l'auto-hébergement natif vient de Runpod : un nœud de huit GPU B300 de 288 Go chacun, soit environ 2,3 To, ou seize B200 répartis sur deux nœuds. Le chiffre de « 64 accélérateurs ou plus » que cette page reprenait ne figure sur aucune source primaire consultée : il est retiré.

Avec un GGUF Unsloth, la règle donnée par leur documentation est simple : la somme RAM plus VRAM doit à peu près égaler la taille de la quantification, sinon le modèle fonctionne mais bascule sur le disque, beaucoup plus lentement. Unsloth cite aussi environ 20 tokens par seconde en génération lorsque le modèle tient sur des B200. C'est un débit d'un fournisseur sur du matériel de datacenter, pas une mesure applicable à une machine domestique.

#Et sur un Mac ? Le calcul plutôt que la rumeur

Le chiffre de « 16 secondes par token sur un MacBook Pro M1 Max » que cette page rapportait n'a retrouvé aucune source vérifiable : nous ne le reprenons pas comme un fait. Ce que les sources établissent est plus net. Kingy AI note que le point de départ (checkpoint de 1,56 To) dépassait déjà un Mac Studio de 512 Go, et que même le fichier de 553,2 Gio de la version 1 bit dépasse cette machine avant surcharge. Un Mac de 128 Go est à environ un cinquième des 610 Go conseillés.

On peut en revanche estimer l'ordre de grandeur soi-même. Si la mémoire ne suffit pas, chaque token relit depuis le SSD les experts qu'il active : 104 milliards de paramètres à environ 4 bits, soit de l'ordre de 50 Go lus par token. Avec un SSD qui délivre 3 Go/s, on obtient environ 17 secondes par token ; à 7 Go/s, environ 7 secondes. C'est un calcul théorique de plafond, pas une mesure, mais il explique pourquoi les témoignages d'exécution « sur disque » se comptent en secondes par token et non en tokens par seconde.

#Ollama, LM Studio, llama.cpp : ce que chaque outil permet

Ollama

La bibliothèque officielle liste une seule variante, kimi-k3:cloud : le modèle s'exécute sur les serveurs d'Ollama, pas sur votre machine. La commande ollama run kimi-k3:cloud sert à essayer le modèle avec l'interface habituelle, avec les limites de confidentialité et de facturation d'un service distant.

LM Studio

Il charge des GGUF locaux. Pour K3, cela suppose de télécharger plusieurs centaines de Go de fichiers Unsloth et de disposer de la mémoire correspondante. Sur une machine grand public, la réponse est non.

llama.cpp

C'est le moteur visé par les GGUF Unsloth, qui s'appuient sur une branche dérivée de llama.cpp avec le support de la vision. Il gère le déchargement des experts sur le CPU et les fichiers en plusieurs parties : c'est la voie réaliste pour une station à plusieurs centaines de Go de RAM.

vLLM et SGLang

Les deux moteurs recommandés par Moonshot pour un service multi-GPU avec le format natif.

#Les options réalistes pour essayer Kimi K3

1. 01
   1. L'API officielle de Moonshot

   Le modèle s'appelle kimi-k3 sur platform.kimi.ai, avec une API compatible OpenAI et Anthropic. C'est le moyen le plus rapide de juger la qualité, avec un paramètre reasoning_effort réglable sur low, high ou max.
2. 02
   2. Ollama cloud

   ollama run kimi-k3:cloud utilise vos habitudes Ollama avec l'inférence déportée. La page de la bibliothèque affiche les tarifs par million de tokens : vérifiez-les avant d'automatiser. Notre guide sur Ollama Cloud détaille les limites.
3. 03
   3. Une location de GPU

   Louer un nœud multi-GPU à l'heure le temps d'un test, avec vLLM. Faites d'abord le calcul de rentabilité (coût horaire divisé par les tokens par seconde soutenus), que Runpod formule dans sa FAQ.
4. 04
   4. Une station à grande RAM

   Seulement si vous avez déjà 700 Go de mémoire : GGUF UD-IQ1_S et llama.cpp, en acceptant une qualité réduite et un débit faible.

#Open weights ne veut pas dire exécutable chez soi

Des poids ouverts garantissent le droit de télécharger, d'auditer, d'affiner et, selon la licence, de redistribuer. Ils ne garantissent pas que quelqu'un puisse les exécuter. Un modèle de 30 milliards de paramètres sur une carte de 24 Go vous appartient réellement ; un 2,8 T que seul un cluster peut charger reste, en pratique, un service. Kimi K3 est une bonne nouvelle pour l'auditabilité et pour les organisations qui ont déjà un cluster, sans changer ce qu'un particulier peut faire chez lui.

#Alternatives que votre matériel peut vraiment charger

Le catalogue QuelLLM estime les besoins mémoire en Q4, hors contexte : DeepSeek V4 Flash 284B environ 170 Go, GLM 5.2 753B-A40B environ 437 Go, Kimi K3 environ 1 624 Go. Pour un usage quotidien, un modèle de 30 à 70 milliards en Q4 reste le meilleur rapport entre qualité et faisabilité.

DeepSeek V4 Flash 284B

Environ 170 Go en Q4 selon le catalogue : possible sur un Mac Studio à grande mémoire ou une station. Voir le guide dédié.

GLM 5.2 753B-A40B

Environ 437 Go en Q4 : c'est le gabarit le plus proche de K3 accessible à une station bien équipée.

Kimi K2.5 et K2.7

Environ 600 Go en Q4 : plus petits que K3, mais encore de l'infrastructure de station.

Modèles de 30 à 70 milliards

Sur une carte de 24 à 32 Go ou un Mac de 64 Go : le choix raisonnable pour un usage réel. Le calculateur de VRAM donne le chiffre exact.

#Verdict : Kimi K3 en local, presque jamais

Poids natifs de 1,56 To, quantifications de 594 à 861 Go, 610 Go de mémoire pour la plus petite : Kimi K3 est un modèle de serveur. Pour l'évaluer, utilisez l'API ou kimi-k3:cloud. Pour un vrai usage chez vous, prenez un modèle qui tient dans votre mémoire avec une marge pour le contexte.

#Pour aller plus loin

• DeepSeek V4 Flash 284B : le premier frontier sur Mac Studio
• GLM-5.2 en local : Ollama et LM Studio
• Choisir sa quantification (Q4, Q5, Q8, FP16)
• MoE expliqué : pourquoi un 30B-A3B tourne comme un petit modèle
• Ollama Cloud : prix, avis et limites
• Calculateur de VRAM

• Source : fiche Hugging Face de Kimi K3
• Source : Unsloth, Kimi K3 en local
• Source : FAQ technique Runpod
• Source : bibliothèque Ollama, kimi-k3