Kimi K3 ouvre 2,8 T de paramètres, pas un modèle local

Le chiffre 2,8 T cache deux budgets différents

Un modèle dense paie deux fois sa taille. Tous ses paramètres doivent résider en mémoire et tous participent au calcul de chaque token. Un MoE MoE Mixture-of-Experts. Architecture où le réseau est découpé en de nombreux « experts » dont un routeur n'active qu'un petit sous-ensemble par token. Le calcul par token suit le nombre de paramètres actifs ; la mémoire, elle, suit le nombre total, car tous les experts doivent rester résidents en VRAM, prêts à être sollicités. Approfondir dans le glossaire sépare ces deux coûts. Kimi K3 contient 2,8 billions de paramètres au total, mais son routeur ne sélectionne que 16 experts parmi 896 pour chaque token, auxquels s’ajoutent deux experts partagés. Moonshot chiffre ainsi le chemin actif à 104 milliards de paramètres.

Cette distinction ne transforme pas Kimi K3 en modèle 104B. Elle indique seulement combien de poids participent aux multiplications d’un token. Le token suivant peut être envoyé vers d’autres experts. Pour répondre sans recharger le réseau depuis le stockage à chaque décision, le serveur doit maintenir l’ensemble des experts dans une mémoire rapidement accessible et les répartir entre ses GPU.

Caractéristique	Valeur publiée	Conséquence système
Paramètres totaux	2,8 billions	Capacité de stockage et répartition des experts
Paramètres actifs	104 milliards par token	Ordre de grandeur du calcul, pas de la mémoire
Experts	896 routés, 16 sélectionnés, 2 partagés	Communication all-to-all entre rangs
Couches	93 : 69 KDA + 24 Gated MLA	Deux formes d'état à gérer dans le runtime
Contexte	1 048 576 tokens	Capacité maximale, pas débit garanti à cette longueur
Poids / activations	MXFP4 / MXFP8 après QAT	Kernels et matériel basse précision requis
Checkpoint officiel	96 shards, 1 560 936 091 448 octets	1,56 To avant caches et mémoire de travail

À quatre bits par valeur, 2,8 billions de poids demanderaient 1,40 To dans un calcul idéal sans échelle, index ni alignement. La somme réelle des tenseurs publiés atteint 1,56 To. Cette différence contient les facteurs d’échelle du MXFP4, les tenseurs qui ne suivent pas tous le même encodage et les structures nécessaires au checkpoint. Même avant le KV cache KV cache Mémoire des vecteurs clé et valeur déjà calculés pour chaque token traité par un LLM. Évite de recalculer l'attention sur tout l'historique, au prix d'une consommation mémoire qui croît avec le contexte. Approfondir dans le glossaire , les buffers d’activations, les graphes CUDA et le modèle de brouillon, l’image disque dépasse donc la mémoire unifiée de douze machines de 128 Go.

Le mot « ouvert » décrit ici l’accès aux poids, pas la proximité du matériel. Moonshot met à disposition le checkpoint complet, le code et une licence permissive sur l’usage et la modification. L’exécution de référence reste distribuée.

KDA réduit l’historique, MLA conserve la vue globale

Une attention complète compare chaque nouveau token à tout le passé. Son coût de prefill croît quadratiquement avec la longueur si aucune approximation n’intervient, et son cache continue de grandir pendant la génération. À un million de tokens, répéter ce mécanisme sur 93 couches rendrait le contexte maximal difficile à exploiter, même avec une attention latente.

Kimi K3 remplace trois couches sur quatre par Kimi Delta Attention. KDA lit la séquence par blocs, met à jour une matrice d’état récurrente et transporte cette matrice vers le bloc suivant. Pendant le decode decode Phase de génération autorégressive d'un LLM : un token est produit à la fois en relisant les poids et l'état de contexte utile. À faible batch, ce trafic peut limiter le decode par la bande passante mémoire. Sa part dans le coût total dépend toutefois des longueurs d'entrée et de sortie, du batching et de la réutilisation du cache. Approfondir dans le glossaire , la taille de cet état ne croît pas avec chaque token comme une liste complète de clés et de valeurs. Moonshot borne aussi le facteur d’oubli de la récurrence, ce qui permet d’exécuter les tuiles diagonales sur les unités matricielles au lieu d’un chemin position par position.

Une récurrence compacte perd cependant l’accès exact à chaque token ancien. Kimi K3 intercale donc une couche Gated MLA après trois couches KDA, puis termine le réseau par une dernière MLA. Ces 24 couches conservent une attention globale. MLA compresse les clés et valeurs de toutes les têtes dans une représentation latente plus petite que le cache multi-têtes classique. L’architecture ne supprime pas la mémoire de contexte ; elle limite le nombre de couches qui la font croître.

Token état entrant séquence

KDA ×3 récurrence compacte mémoire fixe

Gated MLA attention globale latente cache croissant

LatentMoE 16 experts routés calcul sparse

AttnRes mélange entre profondeurs résiduel

Attention Residuals traite un autre axe. Dans un transformer standard, une couche reçoit la somme issue de la précédente. AttnRes apprend à pondérer des représentations venues de plusieurs profondeurs, par blocs, au lieu de laisser toute l’information traverser une seule chaîne résiduelle. Moonshot attribue à KDA, AttnRes, Stable LatentMoE et à sa recette d’entraînement un gain d’environ 2,5× d’efficacité de scaling face à Kimi K2.

Ce 2,5× n’est ni un débit d’inférence, ni une réduction de mémoire, ni un score agentique. Il vient de la loi d’échelle interne du modèle et agrège plusieurs changements simultanés. Le papier ne publie pas une ablation permettant d’attribuer ce ratio à KDA seul ou au passage de 384 à 896 experts.

Le MXFP4 est une décision d’entraînement, pas un fichier recompressé

Kimi K3 est livré en poids MXFP4 MXFP4 Microscaling FP4. Format à blocs où 32 valeurs FP4 partagent un facteur d'échelle commun. C'est ce facteur d'échelle partagé qui permet de tenir en 4 bits sans effondrer la précision. La variante NVFP4 de NVIDIA utilise des blocs plus fins (16 valeurs). Approfondir dans le glossaire et activations MXFP8. Moonshot applique la QAT QAT Quantization-Aware Training. Plutôt que de comprimer un modèle déjà entraîné (et d'en subir la perte de précision), on le réentraîne brièvement en simulant la quantification, pour qu'il apprenne à vivre en basse précision (souvent int4). Réduit fortement la dégradation par rapport à une quantification post-entraînement naïve. dès l’étape de supervised fine-tuning. Le modèle apprend donc après pré-entraînement à produire sous la contrainte de sa représentation quatre bits, au lieu d’être arrondi une fois l’entraînement terminé.

Ce choix réduit la quantité de données à lire pour chaque expert et rend possible un checkpoint de 1,56 To plutôt qu’un ensemble BF16 qui approcherait 5,6 To pour les seuls poids. Il ne garantit pas une exécution efficace sur tout GPU capable de stocker quatre bits. MXFP4 utilise des blocs de valeurs partageant une échelle ; le runtime doit disposer de kernels qui décompressent ou multiplient ce format sans repasser tout le tenseur en précision haute.

vLLM 0.27 et SGLang 0.5.17 ont ajouté ces chemins au lancement. SGLang annonce une validation sur GB300 et MI35x. vLLM couvre Hopper, Blackwell et MI355X, mais son guide pratique ne propose actuellement que des images Docker en raison de dépendances encore en préversion, dont FlashInfer. Le poids ouvert n’est donc pas séparé de son runtime : la qualité du kernel, du routage d’experts et de l’interconnexion décide du débit réel.

Huit B300 constituent le point d’entrée, pas une fiche de coût

Le démarrage rapide vLLM présente huit B300 ou huit MI355X comme les chemins les plus simples. Sa FAQ fixe le minimum NVIDIA à un nœud de huit B300 ou GB300 NVL72 et prend aussi en charge seize B200. Les déploiements de production ajoutent du parallélisme d’experts et de données sur plusieurs nœuds, reliés par NVLink ou RDMA.

Le routeur MoE impose son propre trafic. Chaque rang détient une partie des experts. Après que le modèle a choisi les 16 experts d’un token, les activations doivent rejoindre les GPU qui les hébergent, puis revenir pour poursuivre la couche. Le calcul sparse évite de multiplier par les 896 experts ; il remplace une partie de ce calcul par un all-to-all. Une mauvaise distribution des tokens ou une interconnexion saturée peut effacer l’avantage théorique.

Le contexte hybride complique aussi le prefix caching. Pour une couche MLA, réutiliser un préfixe consiste à retrouver ses blocs de KV. Pour KDA, le runtime doit restaurer l’état récurrent exact à la limite du préfixe. vLLM gère les deux dans un cache hybride, mais désactive encore cette fonction par défaut pour Kimi K3. Il faut passer explicitement --enable-prefix-caching, signe que le mécanisme existe tout en restant sous évolution.

Les 370 tokens/s ne forment pas un ratio contrôlé

vLLM publie 111 tokens/s en TP8 et 118 tokens/s en TP16 sur des GPU GB300 NVL72, à batch 1. Avec le drafter DSpark, le projet annonce 331 et 370 tokens/s, soit environ trois fois plus d’interactivité pour une seule requête. DSpark propose plusieurs tokens en parallèle à partir des états intermédiaires de Kimi K3, puis le modèle complet les vérifie.

Le matériel et la concurrence sont documentés. La comparaison des jeux de données l’est moins. La recette sans speculative decoding utilise des entrées aléatoires d’environ 8 192 tokens et 1 024 tokens de sortie. La recette DSpark utilise SPEED Bench en catégorie low_entropy, jusqu’à 10 240 tokens d’entrée et 1 536 de sortie. Le billet associe pourtant 118 et 370 pour annoncer 3,14×.

La faible entropie augmente la longueur de proposition acceptée par un drafter. Deux longueurs, deux distributions de texte et deux protocoles ne permettent pas d’isoler l’effet de DSpark. Les 370 tokens/s restent un résultat reproductible à viser avec la recette fournie ; le ratio contre 118 doit être traité comme une revendication vLLM, pas comme une ablation contrôlée.

Le même billet annonce plus de 2 000 tokens par seconde et par GPU sur sa frontière de Pareto en haut débit, sans publier dans le texte les traces complètes qui permettraient de relier ce point à un contexte, une concurrence et un objectif de latence précis. Ce nombre ne peut pas être comparé aux 370 tokens/s par utilisateur.

Les benchmarks mesurent autant le harnais que le modèle

Le tableau Moonshot place Kimi K3 à 67,5 sur DeepSWE, 88,3 sur Terminal-Bench 2.1, 42,0 sur SWE-Marathon et 91,2 sur BrowseComp. Le papier reconnaît que le modèle reste derrière Claude Fable 5 et GPT-5.6 Sol dans l’agrégat retenu, tout en devançant les autres modèles de sa sélection.

Ces scores ne partagent pas tous le même harnais harnais Tout ce qui entoure un modèle pour en faire un agent : le jeu d'outils exposés et leurs schémas, le prompt système, les injections de contexte projet, la boucle d'exécution avec permissions et bac à sable, les sous-agents, hooks et serveurs MCP. À modèle identique, changer de harnais déplace les résultats de dizaines de points sur les évaluations agentiques. . Kimi K3 utilise Kimi Code sur DeepSWE et Terminal-Bench ; GPT-5.6 Sol utilise Codex ; certains modèles Claude utilisent Terminus 2 ou Claude Code. SWE-Marathon repose sur une branche recalibrée pour H20 antérieure à la version 1.1 finale, et 35 % des tâches de Claude Fable 5 ont subi un fallback. PostTrainBench mélange lui aussi H20 et H100 ainsi que plusieurs agents.

BrowseComp ajoute un autre traitement : Kimi K3 compacte son contexte à partir de 300 000 tokens et obtient 91,2. Sans gestion de contexte, malgré sa fenêtre 1M, il obtient 90,4. La différence est intéressante pour un système agentique, mais elle appartient au couple modèle et stratégie de contexte.

Le verdict factuel tient donc en deux phrases. Kimi K3 se place au niveau des meilleurs modèles sur plusieurs évaluations publiées. Le tableau ne démontre pas qu’il est supérieur à modèle, agent, budget de raisonnement, matériel et protocole identiques. Une évaluation interne doit conserver le même harnais et mesurer le taux de tâches terminées, le nombre d’appels d’outils, les tokens consommés, la latence et le coût du cluster.

Une licence ouverte avec deux seuils commerciaux

La licence Kimi K3 permet de copier, modifier, distribuer, déployer et créer des dérivés. Elle ne correspond pourtant pas à une licence de logiciel standard sans condition sectorielle. Un fournisseur de « Model as a Service » dont le groupe dépasse 20 millions de dollars de revenus sur douze mois consécutifs doit conclure un accord séparé avec Moonshot avant un usage commercial. Un produit dépassant 100 millions d’utilisateurs actifs mensuels ou 20 millions de dollars de revenus mensuels doit afficher « Kimi K3 » de manière visible.

Ces clauses ne s’appliquent pas à l’usage interne défini par la licence, ni à l’accès via les produits officiels ou partenaires certifiés. Elles comptent peu pour un laboratoire qui audite les poids et beaucoup pour une plateforme qui veut les transformer en API commerciale. « Open-weight » reste donc le terme le plus exact : les paramètres sont inspectables et modifiables, sans prétendre que toutes les libertés de l’open source OSI s’appliquent sans seuil.

L’ouverture déplace la frontière vers l’infrastructure

Kimi K3 rend auditable une classe de modèle qui restait enfermée derrière une API. Il permet d’étudier un routeur à 896 experts, une attention hybride pensée pour un million de tokens et une quantification quatre bits intégrée au post-entraînement. Cette ouverture n’efface pas la rareté ; elle change son emplacement.

La contrainte n’est plus d’obtenir le fichier. Elle consiste à réunir 1,56 To de poids, une interconnexion adaptée à l’all-to-all, des kernels MXFP4 récents, un cache hybride correct et un protocole de mesure qui ne confonde pas le modèle avec son agent. Le prochain progrès utile ne sera pas un paramètre total encore plus grand. Ce sera la capacité à servir ces experts avec un coût, une latence et une reproductibilité que l’extérieur peut vérifier.

Sources et méthode

• Kimi Team, « Kimi K3: Open Frontier Intelligence », arXiv:2607.24653v2, 7 août 2026. Source primaire pour l’architecture, l’entraînement, le contexte, la loi d’échelle et les évaluations. Les résultats sont ceux de l’équipe du modèle, sans reproduction indépendante commune à toute la matrice.
• Moonshot AI, dépôt Kimi K3 et model card, checkpoint Hugging Face et licence Kimi K3, consultés le 12 août 2026. Les 96 fichiers safetensors totalisent 1 560 936 091 448 octets selon les tailles exposées par l’API Hugging Face ; ce total exclut les fichiers de documentation et de tokenizer.
• vLLM, « Kimi K3 Is Here: Efficient Day-0 Support on vLLM », 27 juillet 2026 et recettes Kimi K3. Sources primaires pour le matériel minimal, les backends, le cache hybride, DSpark et les mesures de serving. Notre revue sépare les protocoles random 8K/1K et SPEED Bench low_entropy publiés dans les commandes de reproduction.
• vLLM 0.27.0, notes de version, 10 août 2026. Source primaire pour l’intégration du modèle, des kernels, du frontend Rust, de DeepGEMM et du checkpoint compressed-tensors.
• SGLang 0.5.17, notes de version, 8 août 2026. Source primaire pour les 69 couches KDA, les 24 couches MLA et les fonctions validées sur GB300 et MI35x.