Les poids ouverts de Kimi K3 sont disponibles : 1,56 To et le matériel nécessaire pour l’exécuter

Moonshot a publié les poids ouverts de Kimi K3 le 27 juillet 2026, soit onze jours après la mise en ligne du modèle via son API. Le téléchargement est bien public — mais avec 1,56 To répartis sur 96 shards safetensors, c’est aussi le moment où l’on comprend que « ouvert » ne veut pas forcément dire « exécutable chez soi ». Voici ce qui est disponible, ce que permet la licence et ce qu’il faut réellement pour le servir.

Ce que contient la publication de Moonshot

Le checkpoint complet est disponible sur Hugging Face, à l’adresse moonshotai/Kimi-K3, avec un miroir ModelScope destiné aux utilisateurs en Chine. Le dépôt pèse 1,56 To : 96 shards safetensors, ainsi que config.json, le code de modélisation et de tokenisation — modeling_kimi_k3.py, encoding_k3.py et un modèle tiktoken à vocabulaire de 160K —, le prétraitement visuel et le fichier LICENSE. Le rapport technique a été publié en même temps dans le dépôt GitHub MoonshotAI.

Trois éléments de la model card comptent davantage que le nombre total de paramètres affiché en titre :

• La model card confirme que 104B de paramètres sont activés sur un total de 2,8T : 16 experts routés parmi 896 pour chaque token, auxquels s’ajoutent 2 experts partagés, sur 93 couches. Ce nombre de paramètres actifs n’était pas public avant la sortie des poids.
• Les poids sont nativement en MXFP4. Moonshot a appliqué un entraînement tenant compte de la quantification dès l’étape SFT, avec des activations MXFP8. Il ne s’agit pas d’une quantification a posteriori d’un checkpoint BF16 : les poids 4 bits sont la version publiée.
• L’attention repose sur une répartition 69/24 entre les couches Kimi Delta Attention et Gated MLA, avec une fenêtre de contexte de 1 048 576 tokens.

Les signes d’adoption ont été immédiats. Le dépôt comptait 6,6k likes le 28 juillet 2026, un jour après l’arrivée du commit initial dans son historique des commits. Les conversions communautaires avaient déjà commencé : unsloth/Kimi-K3-GGUF a été créé le soir même, tandis que GrEarl/Kimi-K3-GGUF proposait une conversion Q2_K complète dès le lendemain matin.

La Kimi K3 License n’est pas une licence MIT

Les précédents modèles phares de Kimi étaient publiés sous Modified MIT License. Ce n’est pas le cas de K3. Il est distribué sous un document appelé Kimi K3 License. Son socle reprend l’esprit de MIT — utilisation, copie, modification, fusion, publication, distribution, sous-licence, vente, fine-tuning et création de dérivés —, mais ajoute deux conditions à examiner avant de bâtir un produit dessus.

La clause Model-as-a-Service. Le passage déterminant indique : "If the Licensee or any of its affiliates operates a Model as a Service business, and the aggregate revenue of the Licensee and its affiliates exceeds 20 million US dollars ... in total over any consecutive 12 months, the Licensee must enter into a separate agreement with Moonshot AI before using the Software or its derivative works for any commercial purpose." La licence définit le MaaS comme la fourniture à un tiers d’un accès à l’inférence ou au fine-tuning lui permettant de contrôler les entrées, les paramètres ou les données d’entraînement. Elle exclut explicitement deux cas de cette définition : les produits destinés aux utilisateurs finaux intégrant les capacités du modèle dans des fonctions précises, ainsi que le simple relais de requêtes vers des modèles hébergés par un tiers.

La clause d’attribution. Si un produit commercial fondé sur K3 franchit 100 millions d’utilisateurs actifs mensuels ou 20 millions USD de revenus mensuels, « Kimi K3 » doit apparaître de manière visible dans l’interface du produit.

Ces deux clauses ne s’appliquent pas à un usage strictement interne, c’est-à-dire sans exposition du modèle, de ses sorties ou de ses capacités à des tiers, ni à l’accès via les produits officiels de Moonshot ou des partenaires d’inférence certifiés. À lire les exemptions au pied de la lettre, le fine-tuning de K3 sur des données internes relève de l’exception d’usage interne de la Section 4(a), et son intégration comme fonction d’un produit est explicitement citée en Section 2 comme un cas qui n’est pas du MaaS. Revendre l’inférence K3 sous forme de service est précisément le scénario visé par les clauses ajoutées ; au seuil de $20M, on quitte le terrain de la simple question de licence pour entrer dans celui de la négociation contractuelle. Lisez vous-même la LICENSE avant d’engager une feuille de route : ce résumé est une interprétation du texte et ne constitue pas un conseil juridique.

1,56 To de poids : la réalité côté matériel

Tout le monde peut télécharger les poids ouverts de Kimi K3. Très peu de monde peut les servir.

La recette officielle K3 de vLLM ne laisse guère de place au doute : il faut au moins 8× GB300, et plusieurs nœuds pour absorber un trafic de production réel. Côté AMD, elle cite au minimum 8× MI355X ou MI350X avec l’image ROCm. SGLang publie également un guide K3 visant la même catégorie de matériel.

Pour un déploiement concret, les notes opérationnelles de cette recette méritent d’être relues attentivement. Le service s’exécute depuis l’image dédiée vllm/vllm-openai:kimi-k3 — ou vllm/vllm-openai_rocm:kimi-k3 chez AMD —, et non avec une version standard de vLLM. Les communications inter-nœuds requièrent de préférence --all2all-backend deepep_v2 sur RDMA ou flashinfer_nvlink_one_sided via NVLink, avec UCX_TLS="rc,cuda_copy" afin que le transfert du cache KV reste sur RDMA. Le backend MoE recommandé dépend de la topologie : deep_gemm_mega_moe pour les déploiements en parallélisme d’experts, flashinfer_trtllm pour TP>1. La recette signale aussi que K3 produit occasionnellement un format d’appel d’outil que son propre parseur refuse : validation du schéma et mécanisme de retry doivent donc faire partie de la couche de serving dès le premier jour.

L’échappatoire habituelle — quantifier davantage — fonctionne très peu ici, car le MXFP4 représente déjà environ 4,25 bits par paramètre. La marge de compression qui rendait les modèles de la classe 1T exploitables sur une station de travail a été consommée avant même le téléchargement. La première conversion GGUF communautaire en 2 bits atteint encore 928 Go répartis sur 94 shards : un gain de 40 % sur un chiffre qui n’était de toute façon pas la contrainte déterminante.

Ajoutez le cache KV dès que l’on s’approche du contexte à 1M de tokens, et l’empreinte mémoire grimpe encore. Le rapport d’auto-hébergement le plus marquant du premier jour vient d’une équipe affirmant exécuter les poids MXFP4 officiels sur 80× RTX 5090, via un simple réseau Ethernet, sans HBM ni re-quantification, à environ 20 tokens/seconde en flux unique sans optimisation. Il s’agit d’une affirmation non auditée, publiée le premier jour dans un seul post : pas d’un benchmark. Une configuration unique ne définit pas davantage un minimum matériel. Elle reste intéressante pour ce qu’elle révèle : le chemin le moins coûteux rapporté pour exécuter K3 sur du silicium grand public mobilisait quatre-vingts GPU haut de gamme, pour une vitesse que la plupart jugeraient lente.

Ollama mérite une mention particulière, car c’est souvent le premier réflexe. L’entrée existe dans la bibliothèque, mais elle pointe vers kimi-k3:cloud, autrement dit le routage hébergé d’Ollama, et non un modèle à tirer en local. Il n’existe aujourd’hui aucune voie pour ordinateur portable ou station unique, et le MXFP4 étant le format natif plutôt qu’une quantification de convenance, la re-quantification agressive habituelle de la communauté dispose de moins de latitude que pour la gamme K2. La prise en charge par llama.cpp évolue encore : vérifiez son état actuel plutôt que de partir d’une hypothèse dans un sens ou dans l’autre.

Où utiliser Kimi K3 aujourd’hui

Pour presque tout le monde, l’option réaliste est un endpoint hébergé. La sortie des poids ouverts a produit son effet habituel : les hébergeurs tiers se sont activés en moins d’une journée. Les prix ci-dessous sont exprimés par million de tokens, entrée/sortie, tels qu’affichés le 28 juillet 2026.

Deux vérifications s’imposent avant de choisir. D’abord, la fenêtre de contexte change radicalement d’un fournisseur à l’autre. Nebius affiche le même tarif, mais avec une fenêtre de 8K, ce qui supprime le principal intérêt de K3. Ensuite, la quantification n’est pas uniforme : Moonshot sert le MXFP4 natif, Baseten utilise du FP8 et plusieurs hébergeurs ne précisent pas la précision employée. Pour les tâches agentiques de longue durée, la précision de référence et la fenêtre complète de 1M comptent généralement plus que les écarts de prix ; pour des prompts courts à très gros volume, la latence et la disponibilité régionale peuvent en revanche passer devant ces deux critères.

Au-delà des endpoints directs, OpenRouter les agrège derrière une seule clé API, tandis que des passerelles multi-modèles proposent K3 aux côtés d’autres modèles chinois ouverts de pointe. AIReiter expose cette même catégorie de modèles via une API compatible Anthropic si vos outils parlent déjà ce protocole. L’endpoint de Moonshot offre pour sa part des interfaces compatibles OpenAI et Anthropic. Les détails complets des limites et des paliers figurent dans l’analyse tarifaire de Kimi K3.

Faut-il l’auto-héberger ou passer par une API ?

Commencez par faire le calcul. À $3/$15 par million de tokens, un milliard de tokens de sortie coûte $15,000 et un milliard de tokens d’entrée $3,000. Comparez cela au minimum viable pour l’auto-hébergement : un nœud de classe 8× GB300 — un investissement de datacenter ou une location facturée à l’heure d’accélérateur —, auquel s’ajoutent interconnexion, électricité, refroidissement et un ingénieur qui maîtrise --all2all-backend sur le bout des doigts. Ni NVIDIA ni les grands clouds ne publient de tarif catalogue pour cette configuration : partez d’un devis en cours plutôt que d’une règle approximative. Gardez aussi à l’esprit que le coût matériel est fixe, tandis que la facture API évolue avec l’usage réel.

L’auto-hébergement des poids ouverts de Kimi K3 se justifie dans trois cas, plus restreints qu’ils n’en ont l’air :

1. Des contraintes d’environnement isolé ou de résidence des données auxquelles aucun endpoint tiers ne peut répondre. C’est le cas le plus solide, et le coût n’est alors pas le facteur décisif.
2. Le fine-tuning sur des données propriétaires. La licence l’autorise explicitement, et aucun endpoint hébergé ne vous offre cela. Le coût d’entraînement est distinct du coût de serving et lui est supérieur.
3. Un volume continu à saturation. Si un cluster multi-nœuds reste chargé en permanence, le matériel possédé peut devenir moins cher qu’une tarification au token. Les pics ponctuels ne suffisent pas.

Si aucun de ces cas ne vous correspond, utilisez un endpoint et considérez les poids comme une possibilité, pas comme un plan de déploiement. Pour la plupart des équipes, l’intérêt d’un modèle de pointe à poids ouverts n’est pas de l’exécuter elles-mêmes. C’est que le tarif de sa version hébergée doit désormais composer avec la possibilité qu’elles puissent le faire.

FAQ

Kimi K3 est-il open source ?

C’est un modèle à poids ouverts. Le checkpoint complet de 2,8T est téléchargeable, et la Kimi K3 License autorise l’utilisation, la modification, la distribution et le fine-tuning. Les données d’entraînement et le pipeline complet d’entraînement ne sont pas publiés. En outre, la licence ajoute une clause déclenchée par les revenus pour les opérateurs Model-as-a-Service : ce n’est donc pas de l’open source au sens OSI.

Peut-on exécuter Kimi K3 localement avec Ollama ?

Non. L’entrée kimi-k3 d’Ollama correspond à kimi-k3:cloud, qui redirige vers un endpoint hébergé. Les poids MXFP4 natifs pèsent 1,56 To et un GGUF communautaire en 2 bits atteint encore 928 Go : il n’existe donc pas de solution locale sur matériel grand public.

Sous quelle licence les poids de Kimi K3 sont-ils publiés ?

Sous la Kimi K3 License : elle dérive de MIT, mais impose un accord distinct avec Moonshot si vous exploitez une activité Model-as-a-Service dépassant $20M de revenus sur une période quelconque de 12 mois, et exige une attribution dans l’interface au-delà de 100M d’utilisateurs actifs mensuels ou $20M de revenus mensuels. L’usage interne est exempté de ces deux clauses.

Où utiliser Kimi K3 sans le télécharger ?

Via l’API de Moonshot et l’application Kimi, mais aussi chez Baseten, Fireworks et Nebius. Les quatre affichent un tarif de base de $3/$15 par million de tokens au 28 juillet 2026, mais la comparaison doit être nuancée : Fireworks propose également un palier à $4.50/$22.50, et Nebius applique son tarif de base avec une fenêtre de contexte de 8K au lieu de 1M. Pour savoir ce qu’est le modèle et comment il se situe en benchmark, consultez l’présentation de Kimi K3.