Skip to main content
Dernière vérification : 2026-07-21
Kimi K3 est le modèle de pointe de Moonshot AI : 2.8 billions de paramètres au total, ~50 milliards actifs par jeton grâce au routage Stable LatentMoE (16 experts sur 896), une entrée visuelle native et une fenêtre de contexte d’1 million de jetons. Moonshot a lancé K3 le juillet 17, 2026 pour le codage de longue haleine, le travail intellectuel et le raisonnement. Un point essentiel concernant l’inférence locale réside dans le calendrier : K3 est dès à présent accessible via les produits hébergés et l’API de Kimi, mais Moonshot indique que les poids téléchargeables seront mis à disposition d’ici juillet 27, 2026. La fiche descriptive du modèle, la taille du checkpoint, la licence, les paramètres d’exécution ainsi que les instructions pour un auto-hébergement reproductible ne sont pas encore publiés.
Il est impossible d’effectuer le déploiement de Kimi K3 en local actuellement, car les poids du modèle n’ont pas encore été publiés. Ne copiez surtout pas de commande spéculative vllm serve ni de fichier partagé par la communauté portant l’étiquette K3 en pensant qu’il s’agit du modèle officiel. Il convient d’attendre qu’un dépôt officiel soit mis à disposition par Moonshot.

​
Quelles options sont disponibles dès à présent ?

Source : annonce de lancement de Kimi K3 et guide API Kimi K3.

​
Kimi K3 en un coup d’œil

Moonshot n’a pas encore publié de rapport technique ni les fichiers de checkpoint exacts. Toute indication précise concernant les paramètres, la taille de stockage, les commandes d’exécution ou les performances doit être considérée comme provisoire en l’absence de ces éléments.

​
Est-il possible d’exécuter Kimi K3 en local ?

Non — pas aujourd’hui. Kimi K3 est dès à présent disponible via l’API hébergée de Moonshot, mais les poids téléchargeables ne sont pas encore publiés (promis d’ici juillet 27, 2026). Même lorsque les poids arriveront, le plancher de poids de K3, soit ~1.4 To à une précision de 4 bits, exclut toute configuration grand public ou prosumer. Moonshot recommande lui-même un supernœud doté de 64 accélérateurs ou plus. Huit DGX Spark mutualisent 1 To de mémoire unifiée et restent 376 Go en deçà. Consultez le calcul de mémoire DGX Spark pour le calcul complet.
Vous ne souhaitez pas attendre la sortie des poids ? Découvrez les modèles à privilégier en remplacement de Kimi K3 : les meilleurs modèles polyvalents et adaptés au codage pour votre configuration matérielle, qu’il s’agisse d’un processeur Strix Halo ou d’un cluster composé de 4 unités Spark.

​
Configuration matérielle requise pour Kimi K3

Aucune configuration de consommateur ou de prosumer ne peut héberger K3. À exactement 4 bits par paramètre, un ID de modèle amont comptant 2.8T paramètres nécessite environ 1.4 téraoctets rien que pour les poids, sans compter les métadonnées de microscaling, les tampons d’exécution, les activations et l’état du contexte. Pour donner un ordre d’idée : huit nœuds DGX Spark offrent au total 1 téraoctets de mémoire unifiée, mais restent tout de même en déficit de 376 gigaoctets par rapport à la taille minimale requise pour les poids. NVIDIA ne documente actuellement que des clusters Spark composés de quatre nœuds, tandis que Moonshot recommande d’exécuter K3 sur un supernœud doté de 64 accélérateurs ou plus. Consultez le calcul relatif à la mémoire de DGX Spark pour obtenir le calcul complet, le tableau des clusters et les contraintes réseau.
Souhaitez-vous un modèle téléchargeable dès aujourd’hui ? Comparez tous les modèles Kimi actuellement disponibles : Kimi K2.6 et K2.7-Code sont désormais dotés de poids ouverts et peuvent s’exécuter sur du matériel de classe serveur.

​
Pourquoi l’architecture revêt une importance cruciale pour l’auto-hébergement

K3 ne se limite pas à être un checkpoint K2 de plus grande taille. Quatre modifications sont particulièrement pertinentes pour quiconque envisage de le déployer :
  • Kimi Delta Attention (KDA) — il s’agit d’une conception hybride d’attention linéaire qui réduit le coût de pré-remplissage pour les invites comptant des millions de tokens. Cette architecture exige des noyaux logiciels et des sémantiques de cache adaptés : Moonshot précise que le cache de préfixe classique ne s’accorde pas naturellement avec KDA, et que sa contribution au cache de pré-remplissage vLLM est fournie conjointement aux poids. Un environnement d’exécution se contentant de charger les poids ne sera pas automatiquement compatible avec K3.
  • Attention Residuals (AttnRes) — certaines couches récupèrent de manière sélective des représentations utiles issues de profondeurs antérieures, au lieu d’additionner systématiquement les sorties de chaque couche avec un poids fixe. L’article de Moonshot sur AttnRes indique qu’il en résulte un flux d’informations plus stable dans les modèles profonds.
  • Stable LatentMoE — 16 experts sur 896 sont routés par jeton. L’activation éparse réduit le calcul par jeton, mais elle ne réduit pas le checkpoint stocké : chaque expert doit rester résident sur l’ensemble du cluster de service, ce qui fait des interconnexions rapides une exigence de premier ordre.
  • Native MXFP4 — l’entraînement avec quantification (QAT) a été mené dès l’étape de fine-tuning supervisé, en ciblant des poids MXFP4 et des activations MXFP8. Il s’agit du format de service prévu, et non d’un quant communautaire — le chiffre de 4 bits ci-dessus est donc un plancher, pas un compromis.

​
Comportement de l’API K3 à préserver

Que vous testiez K3 via l’API de Moonshot dès à présent ou que vous validiez ultérieurement un environnement d’exécution auto-hébergé, ces spécificités protocolaires sont essentielles :
  • K3 raisonne en permanence. Utilisez le paramètre de premier niveau reasoning_effort: "max" ; n’envoyez pas le paramètre thinking de K2.x.
  • Les réponses en streaming séparent le raisonnement dans reasoning_content et la réponse finale dans content.
  • Pour les conversations à plusieurs tours et les boucles d’outils, il convient de rejouer le message d’assistant complet, en conservant le raisonnement et les champs de requête d’outil. Ne renvoyer que content risque de perturber les tours suivants.
  • max_completion_tokens prend par défaut la valeur 131,072 et peut être réglé jusqu’à 1,048,576.
  • L’API de lancement fixe les paramètres d’échantillonnage. Moonshot conseille de ne pas modifier les paramètres temperature, top_p, n ni les paramètres de pénalité, ou de les laisser tels quels.
  • Les URL d’images publiques ne sont pas acceptées. Il faut envoyer des données de base64 ou une référence ms://<file-id>.
Consultez le guide officiel de l’API K3 pour connaître le schéma de requête actuel.

​
Connectez K3 à Tokios une fois les poids téléchargés.

Tokios s’utilise en complément d’un runtime local. Il ne télécharge pas le modèle ni ne remplace vLLM. Lorsque Moonshot et les gestionnaires du runtime proposeront un mode de service K3 compatible :
1

Vérifiez les artefacts officiels.

Assurez-vous que le dépôt est référencé par Moonshot. Lisez la fiche du modèle, la licence, le manifeste des points de contrôle, la liste des accélérateurs pris en charge et les réglages de parallélisme recommandés. Ne déduisez pas ces informations à partir de K2.
2

Déployez K3 sur le cluster compatible.

Suivez les instructions publiées pour vLLM ou d’autres runtimes. Vérifiez que le serveur local peut traiter une requête en streaming, conserver reasoning_content et exécuter une boucle d’outils à plusieurs tours via son propre API /v1.
3

Appairez le connecteur Tokios

Installez le connecteur sur un nœud capable d’atteindre le point de terminaison de service. Dans le dashboard, ouvrez Setup, sélectionnez Start pairing et utilisez le code d’appairage à usage unique TKS-XXXX-XXXX.
4

Enregistrez un déploiement

Orientez le connecteur vers l’URL de base /v1 compatible OpenAI de votre cluster. Ensuite, enregistrez l’ID de modèle amont sous un nom de déploiement public tel que kimi-k3-tunnel.
5

Générez une clé API

Dans l’onglet Keys, cliquez sur Create key. Copiez immédiatement la clé API sk-tok-… car elle ne s’affiche qu’une seule fois.
6

Testez avant de partager le point de terminaison

Testez les fonctionnalités de diffusion, les longues conversations, la reconnaissance visuelle, la sortie structurée et les appels d’outils via https://api.tokios.com. Utilisez pour cela une clé API sk-tok-… dédiée et maintenez le contexte initial court afin de vérifier l’utilisation de la mémoire.

​
Appelez le modèle depuis n’importe où

Une fois ce processus validé, les clients utiliseront le nom de déploiement que vous avez défini au lieu de l’ID de modèle amont.

​
Points à considérer lors du lancement

  • Les poids du modèle, la fiche technique, la licence, le rapport technique, le manifeste de sommes de contrôle et les commandes d’auto-hébergement ne sont pas encore disponibles.
  • Les résultats du test de performance de K3 proviennent de rapports fournis par Moonshot. Une reproduction indépendante nécessitera l’obtention des poids et de la configuration d’évaluation.
  • Moonshot met en garde contre l’instabilité potentielle des sorties si l’historique de raisonnement est perdu ou si une session existante d’un autre modèle est transférée vers K3.
  • K3 a été entraîné pour gérer des tâches complexes et de longue durée ; il peut agir de manière trop proactive lorsque les instructions sont floues. Il convient donc de définir des limites explicites dans votre invite système ou dans le AGENTS.md.
  • La limite de tokens de K1M constitue un maximum, non un objectif cible. Des contextes très longs augmentent le temps de pré-remplissage, l’espace de stockage du cache ainsi que le coût d’inférence.

​
Questions fréquentes

À sa précision native MXFP4 (4 bits par paramètre), K3 et ses 2.8T paramètres exigent environ 1.4 To rien que pour les poids — avant les échelles de blocs, les tampons d’exécution, les activations et le cache KV. Cela représente environ 11 DGX Spark de 128 Go chacun, uniquement pour le plancher de poids brut. En pratique, il faut au minimum 14-16 Spark pour une hypothétique pile de service distribuée, et NVIDIA ne documente des clusters Spark que jusqu’à 4 nœuds.
Ce n’est guère envisageable. Huit unités DGX Spark offrent au total 1 téraoctet de mémoire unifiée, soit 376 Go en deçà du seuil requis pour les poids. La configuration Spark maximale autorisée par NVIDIA atteint 4 nœuds (512 Go), tandis que Moonshot vise à déployer K3 sur des supernœuds dotés de 64 accélérateurs ou plus. Pour connaître les modèles compatibles avec la plateforme Spark, consultez la compatibilité des modèles DGX Spark.
Moonshot annonce que les poids de K3 seront mis à disposition en téléchargement d’ici juillet 27, 2026 ; toutefois la licence, la fiche descriptive du modèle et les fichiers de checkpoint ne sont pas encore publiés. On ne peut donc qualifier le modèle d’« open source » qu’après la mise en ligne de ces éléments. Actuellement, Kimi K2.6 et K2.7-Code sont déjà dotés de poids ouverts ; découvrez la famille de modèles Kimi.
Aujourd’hui, vous pouvez utiliser l’API hébergée par Moonshot en indiquant l’ID de modèle kimi-k3. Une fois les poids du modèle distribués, vous déployez le checkpoint sur un cluster compatible (le support de vLLM avec le cache KDA est attendu) puis appelez son point de terminaison /v1 conforme à l’API OpenAI. Tokios peut servir de front-end à ce point de terminaison local en gérant des clés API à portée limitée — consultez ci-dessus Connecter K3 à Tokios.
1,048,576 jetons (1M). Le paramètre max_completion_tokens prend par défaut la valeur 131,072 et peut être réglé jusqu’à atteindre la taille maximale de la fenêtre de contexte. Des contextes plus longs allongent le temps de préremplissage, augmentent l’espace de stockage du cache et les coûts d’inférence ; 1M représente une limite maximale, non un objectif à atteindre.
K3 est un modèle de mélange d’experts (Mixture-of-Experts) doté de 4 innovations clés : Stable LatentMoE (16 experts sur 896 activés par jeton, ~50B actifs), Kimi Delta Attention (attention linéaire hybride pour un pré-remplissage efficace d’un million de jetons), Attention Residuals (routage de l’information en profondeur) et MXFP4 natif (entraînement avec quantification dès l’étape SFT). Celles-ci ne sont pas compatibles telles quelles avec le service de transformeurs standard — KDA en particulier exige des noyaux et une sémantique de cache adaptés.

Kimi K3 sur DGX Spark

Calculs détaillés relatifs à la mémoire, contraintes liées aux clusters et tableau récapitulatif des preuves de lancement.

Modèles Kimi

Comparez K3 aux versions téléchargeables K2.6 et K2.7-Code, puis hébergez Kimi vous-même dès à présent.

Quoi exécuter à la place de K3

Le meilleur modèle, tant pour le codage que pour d’autres tâches, adapté à votre matériel, que ce soit Strix Halo ou un cluster 4-Spark.

Diffusion et mise à l’échelle des modèles

Il convient de comprendre le parallélisme tensoriel, le parallélisme de pipeline ainsi que le parallélisme d’expert avant de planifier un cluster destiné à des applications à grande échelle.

Démarrage rapide

Associez un connecteur à un modèle local disponible dès à présent puis enregistrez-le.