Ce qui est désormais confirmé et ce qui reste en attente
Cette distinction est cruciale. Bien que K3 soit présenté comme un modèle ouvert, l’engagement de publier ultérieurement ses poids ne signifie pas qu’ils soient disponibles dès à présent.
Quelles sont les modifications apportées par rapport à Kimi K2
K3 increases scale from K2’s 1T parameters to 2.8T, expands the context from 256K to 1M tokens, and changes the architecture in four important ways.Kimi Delta Attention permet de gérer des séquences très longues
Kimi Delta Attention (KDA) constitue un mécanisme d’attention linéaire appartenant à la famille Kimi Linear. Les architectures hybrides utilisant cette approche évitent d’appliquer une attention quadratique à chaque couche. Cela revêt une importance particulière lors du traitement de prompts volumineux, où le serveur doit analyser une grande quantité de texte avant de générer le premier token. KDA ne se limite pas à un simple paramètre de vitesse. Il exige des noyaux logiciels adaptés ainsi qu’une sémantique de cache spécifique. Moonshot affirme que le cache de préfixe classique ne s’accorde pas naturellement avec KDA, et que sa contribution relative au cache de préchargement pour vLLM sera livrée en même temps que les poids du modèle. Par conséquent, un environnement d’exécution capable de charger des poids de modèles transformeurs génériques ne sera pas automatiquement compatible avec K3.L’approche Attention Residuals répartit les informations en profondeur du réseau
Les connecteurs de résidu PreNorm classiques additionnent de manière répétée les sorties des couches en utilisant des poids unitaires fixes. Attention Residuals permet à chaque couche d’analyser les représentations précédentes afin de choisir ce qu’il convient de réutiliser. Le document sur Attention Residuals décrit une variante de bloc qui diminue la consommation mémoire et les échanges entre composants du pipeline, tout en conservant la plupart des avantages initiaux. Il s’agit d’un routage effectué en profondeur, distinct de l’attention sur les jetons. KDA détermine comment les positions des jetons interagissent entre elles. AttnRes indique quelles représentations issues des couches antérieures restent pertinentes.Stable LatentMoE favorise une plus grande rareté d’activation
K3 emploie Stable LatentMoE pour orienter 16 sur un total de 896 experts. Cette activation parcimonieuse réduit le calcul par jeton par rapport à un modèle dense de type 2.8T. Toutefois, la taille du checkpoint stocké ne se limite pas à celle des experts actifs : tous les experts doivent néanmoins être présents dans le cluster. À cette échelle, le positionnement des experts et l’équilibrage de la charge influencent directement le débit. Moonshot mentionne également l’équilibrage quantile ainsi qu’une méthode de formation parallèle des experts totalement équilibrée, mais les détails techniques restent à préciser dans le rapport technique.La formation sensible à la quantification débute dès le stade du déploiement
Selon Moonshot, la formation sensible à la quantification a été appliquée dès la phase de réglage fin sur données supervisées, en utilisant des poids MXFP4 et des activations MXFP8. Il ne s’agit pas d’une quantification appliquée ultérieurement par la communauté. Le modèle a été entraîné pour supporter la précision utilisée lors de son déploiement. MXFP4 stocke les valeurs avec une précision de 4 bits, ainsi que des informations de mise à l’échelle partagées. Le calcul effectué sur 4 bits ne constitue donc qu’une borne minimale, et non une estimation exacte du checkpoint final.Calcul de la mémoire requise par DGX Spark
NVIDIA lists 128 GB of LPDDR5x unified memory per DGX Spark. The GPU and CPU share that pool. It is not 128 GB for weights plus separate system RAM. À raison de quatre bits par paramètre :- les échelles de blocs MXFP4 ainsi que les métadonnées tensorielles
- les allocations d’exécution et les tampons de communication
- les activations et les espaces de travail temporaires
- l’état KV ou récurrent nécessaire selon le contexte choisi
- l’état de l’encodeur visuel pour les requêtes multimodales
- la mémoire consommée par le système d’exploitation DGX et les processus de service
le tableau de décompte des Spark
Pourquoi la mémoire globale ne suffit pas
Même un cluster Spark hypothétique comportant 16 nœud rencontrerait trois problèmes pratiques.La topologie prise en charge se limite à quatre nœuds
Les directives actuelles de NVIDIA concernant les déploiements multi-nœuds autorisent jusqu’à quatre nœuds DGX Spark. Ce cluster de 512 Go convient aux modèles comptant jusqu’à environ 700B paramètres. K3 représente un volume de paramètres quatre fois supérieur. NVIDIA propose des exemples de configuration pour deux nœuds, trois nœuds en anneau et quatre nœuds connectés via un commutateur, mais aucune procédure de déploiement pour des clusters de 14 ou 16 nœuds, ni pour K3.L’inférence des LLM exige une synchronisation constante
Each Spark has 273 GB/s local memory bandwidth and a 200 GbE ConnectX-7 network interface. A 200-gigabit link carries at most 25 GB/s before protocol overhead, far below local memory bandwidth. L’inférence distribuée des LLM se déroule couche par couche, avec un échange répété de résultats partiels. NVIDIA met en garde expressément contre le fait que ce type de communication granulaire réduit l’efficacité du déploiement à mesure que le nombre de nœuds augmente. Ajouter davantage de nœuds accroît la capacité globale, mais chaque token généré doit alors attendre plus longtemps pour transiter via le réseau de communication.Le système K3 vise à créer un supernœud
Moonshot recommande l’utilisation d’un 64-plus-accelerator supernode afin que le parallélisme expert puisse s’appliquer au sein d’un domaine de communication vaste et doté d’une large bande passante. Cette recommandation concerne le débit et la topologie, et non simplement la capacité à contenir le fichier. Une unité Spark demeure utile pour développer des clients, des invites, des schémas d’outils et des modèles locaux de taille modeste. Elle ne constitue toutefois pas la plateforme d’inférence K3 visée par Moonshot.Comment interpréter le tableau de référence de Moonshot
Moonshot présente des résultats prometteurs dès le lancement, tant en matière de codage, de travail d’automatisation, de raisonnement que de traitement visuel. Voici quelques scores représentatifs obtenus sur K3 (max) :
Il s’agit de résultats communiqués par les éditeurs, et non d’une validation indépendante. Les notes de bas de page de Moonshot indiquent également que les modèles ne sont pas toujours évalués avec le même environnement d’essai : K3 utilise parfois Kimi Code, un autre modèle utilise Claude Code, et les modèles GPT font appel à Codex. La qualité de l’environnement, les règles d’utilisation des outils, la gestion du contexte et les mécanismes de secours influencent fortement les résultats des tests.
En pratique, cela signifie que K3 semble suffisamment performant pour être testé, mais le tableau de lancement ne garantit pas qu’il reproduira ces performances dans votre propre environnement. Il convient d’attendre les poids du modèle, les instructions, les détails de l’environnement d’essai ainsi que les évaluations réalisées par des tiers.
Le comportement de l’API ne correspond pas à un remplacement direct de K2
K3 is live askimi-k3 on Moonshot’s OpenAI-compatible Chat Completions API, but it is not a drop-in K2 configuration: thinking is always on, reasoning_effort replaces the thinking parameter, streaming splits reasoning_content from content, and multi-turn replay must preserve the complete assistant message. The Kimi K3 model page keeps the full list of protocol details to preserve when you test the API or validate a self-hosted runtime later.
Limites connues lors du lancement
Moonshot identifie trois limites principales :- Sensibilité à l’historique. K3 exige que l’historique de réflexion soit conservé. Une reprise de session incorrecte ou un changement de modèle en cours de session risquent de perturber les résultats.
- Proactivité excessive. Le modèle peut prendre des décisions inattendues lorsque une tâche complexe comporte des zones d’ambiguïté. Il est conseillé de définir des autorisations explicites, des conditions d’arrêt et des limites d’édition.
- Écart d’expérience utilisateur persistant. Selon Moonshot, K3 reste inférieur aux meilleurs modèles propriétaires en termes d’expérience globale, même si ses performances sur certains critères d’évaluation sont compétitives.
AGENTS.md, d’exiger une validation pour toute action destructrice ou externe, et de tester la gestion du contexte avant de lancer des exécutions autonomes de longue durée.
Que faire en attendant la publication des poids du modèle
Attendez que les artefacts fournis par Moonshot lui-même — et non par des dépôts communautaires portant un nom similaire — soient disponibles, puis recalculez à partir du manifeste de point de contrôle officiel avant d’effectuer tout achat. La page du modèle Kimi K3 détaille le plan d’étape pour le déploiement : vérification des artefacts officiels, mise en service sur un cluster compatible, et connexion du déploiement via Tokios. En attendant, la page ce qu’il convient d’utiliser à la place de Kimi K3 indique le modèle le plus adapté à votre matériel actuel.Sources primaires
- Kimi K3 : Intelligence frontalière ouverte — lancement, architecture, indicateurs de performance, disponibilité et limites
- Guide API Kimi K3 — ID de modèle amont, comportement des requêtes, fonctionnalités visuelles, outils et limites de contexte
- Article sur les résidus d’attention — conception du routage en profondeur et expérimentations de mise à l’échelle
- Présentation matérielle de DGX Spark — mémoire unifiée de 128 Go, bande passante de 273 Go/s et connecteur ConnectX-7
- Directives de NVIDIA pour la mise à l’échelle sur quatre nœuds Spark — nombre de nœuds supportés, positionnement 700B et limites de communication
Kimi K3
Suivez la disponibilité de K3, les exigences matérielles et la procédure Tokios dès que les poids officiels seront publiés.
Modèles Kimi
Comparez K3 aux modèles K2.6 et K2.7-Code téléchargeables que vous pouvez héberger vous-même dès à présent.
Ce qu’il convient d’utiliser à la place de K3
Le modèle de codage et général le plus performant pour votre matériel, accompagné de guides de déploiement détaillés.
DGX Spark
Exécutez les modèles compatibles avec Spark et attribuez-leur un point de terminaison Tokios privé.
Mise en service et mise à l’échelle des modèles
Parallélisme tensoriel, de pipeline et d’experts — le vocabulaire technique sous-jacent aux exigences des supernodes.
FAQ
Quelle quantité de VRAM Kimi K3 nécessite-t-il ?
Quelle quantité de VRAM Kimi K3 nécessite-t-il ?
Environ 1.4 téraoctets à la précision MXFP4 native (soit 4 bits par paramètre pour un total de 2.8 trillions de paramètres), sans compter les échelles de blocs, les tampons d’exécution, les activations ni le cache KV. En pratique, un cluster de mise en service requiert bien davantage ; Moonshot préconise l’utilisation de plus de 64 accélérateurs dans une configuration de supernode.
Combien de DGX Sparks faut-il pour exécuter Kimi K3 ?
Combien de DGX Sparks faut-il pour exécuter Kimi K3 ?
Au minimum, 11 Spark suffirait à atteindre le seuil de poids brut de 1.4 téraoctets (11 multiplié par 128 gigaoctets équivaut à 1,408 gigaoctets), mais cela ne laisserait aucune marge pour le système d’exploitation, les surcharges CUDA, le cache KV ou l’état d’inférence. Une estimation réaliste se situe entre 14 et 16 Spark. Toutefois, NVIDIA ne documente que des clusters Spark allant jusqu’à 4 nœuds (soit 512 gigaoctets), et aucune topologie K3 sur Spark n’est officiellement prise en charge.
Pourquoi les modèles MoE tels que K3 ne peuvent-ils pas fonctionner avec moins de mémoire alors que seuls 16 experts s’activent ?
Pourquoi les modèles MoE tels que K3 ne peuvent-ils pas fonctionner avec moins de mémoire alors que seuls 16 experts s’activent ?
L’activation parcellaire des modèles MoE réduit le calcul par jeton, mais n’affecte pas la taille du checkpoint stocké. Tous les poids des 896 experts doivent impérativement rester chargés dans la mémoire du cluster de mise en service. Les ≈50B paramètres actifs dictent la vitesse d’inférence (en FLOPs par jeton) tandis que le total de 2.8 trillions de paramètres détermine les besoins mémoire.
Quel matériel peut réellement exécuter Kimi K3 ?
Quel matériel peut réellement exécuter Kimi K3 ?
Moonshot recommande l’utilisation d’un supernode doté de 64 accélérateurs ou plus, c’est-à-dire un domaine d’interconnexion à haut débit où le parallélisme spécialisé fonctionne de manière optimale. Les GPU grand public (24 Go), les unités de mémoire unifiée destinées aux utilisateurs avancés (128 à 192 Go), voire les clusters Spark à 4 nœuds (512 Go) restent tous largement en deçà des exigences de K3.
Quand les poids de Kimi K3 seront-ils disponibles ?
Quand les poids de Kimi K3 seront-ils disponibles ?
Moonshot a annoncé la mise à disposition des poids téléchargeables d’ici juillet 27, 2026. La licence, la fiche descriptive du modèle, le manifeste des points de contrôle ainsi que les instructions pour l’auto-hébergement n’ont pas encore été publiés. vLLM a confirmé avoir reçu de Moonshot une contribution relative au cache de préfixes KDA, qui devrait être intégrée le jour 0 de la sortie officielle.