Kimi K3 : les poids sont libres, le compute ne l'est pas (encore)

Posons d’entrée la question qui gêne quand on défend la souveraineté numérique en Europe : peut-on, sans rougir, utiliser le modèle le plus fort du moment quand il sort des laboratoires de Moonshot AI, une entreprise chinoise, même si ses poids sont ouverts ? Moonshot vient d’annoncer Kimi K3 : 2 800 milliards de paramètres, vision native, contexte d’un million de tokens, premier modèle « ouvert » de la classe 3T. Les poids complets seront publiés d’ici le 27 juillet.

Petite nuance d’honnêteté d’entrée, parce que ce carnet n’est pas un support promotionnel : « meilleur LLM au monde » se discute. Moonshot reconnaît lui-même que K3 reste derrière Claude Fable 5 et GPT 5.6 Sol en performance globale et en expérience utilisateur. Mais pour la première fois, un modèle ouvert s’invite à cette table-là, et c’est précisément ce qui rend la question du titre légitime. J’écris ce billet à chaud, le jour de l’annonce, en m’appuyant sur l’article officiel : les benchmarks cités sont ceux de l’éditeur, à prendre avec la prudence d’usage en attendant les évaluations indépendantes.

Les faits

Ce qu’il faut retenir de l’architecture :

2,8T de paramètres en Mixture of Experts, avec 16 experts activés sur 896 (framework « Stable LatentMoE ») ;
Deux nouveautés architecturales maison : Kimi Delta Attention (KDA) et Attention Residuals (AttnRes), censées améliorer la circulation de l’information en longueur (séquence) et en profondeur (couches) ;
Vision native : texte, image et vidéo compris dans le même modèle, pas un adaptateur greffé après coup ;
1 million de tokens de contexte ;
Entraînement conscient de la quantification dès le SFT : poids en MXFP4, activations en MXFP8, un choix assumé pour la compatibilité matérielle.

Moonshot revendique un gain d’efficacité de scaling d’environ 2,5× par rapport à Kimi K2. Autrement dit, le modèle convertit mieux le compute en intelligence. Et un fait qui vaut son pesant de petaflops : sur neuf des douze derniers mois, ce sont les modèles Kimi qui ont fixé la borne supérieure de la taille des modèles ouverts.

Ce que le modèle sait faire (selon Moonshot)

Les études de cas publiées sont spectaculaires, et je pèse mes mots :

Un compilateur GPU from scratch : K3 a développé « MiniTriton », un compilateur type Triton avec sa propre couche IR sur MLIR, ses passes d’optimisation et sa génération de PTX, à la parité voire au-dessus de Triton sur certains workloads, et capable de faire tourner un entraînement nanoGPT de bout en bout ;
Une puce : en 48 heures d’exécution autonome, le modèle a conçu, optimisé et vérifié avec des outils EDA open source (bibliothèque Nangate 45 nm) une puce pour servir un nano-modèle de sa propre architecture : 1,46 M de cellules, timing bouclé à 100 MHz, plus de 8 700 tokens/s en simulation. Une puce dessinée par un modèle, pour un modèle ;
De l’astrophysique computationnelle : reproduction des relations universelles I-Love-Q en deux heures, avec 20+ papiers croisés, 300+ équations d’état évaluées, 3 000 lignes de Python, et au passage des incohérences relevées dans des formules publiées. Le devis habituel d’un chercheur expérimenté : une à deux semaines ;
Optimisation de kernels GPU sur H200, où une version préliminaire de K3 a déjà pris en charge, en fin de développement, la majorité du travail d’optimisation de l’équipe elle-même.

Côté benchmarks, le discours est honnête, et c’est assez rare pour le souligner : K3 se place « au niveau frontière » devant les autres modèles testés, sans prétendre coiffer les deux leaders propriétaires. L’écart se resserre, vite. C’est exactement le verdict auquel j’arrivais dans mon banc d’essai d’un modèle ouvert de 35B le mois dernier, sauf que l’échelle a changé.

Premiers retours terrain : Kimi Code sur deux vrais projets

Les communiqués, c’est une chose. Mon clavier, c’en est une autre. J’ai commencé à tester Kimi Code sur deux cas bien réels, pas des jouets de démo :

Un projet greenfield : une application PWA partie de zéro, le genre de terrain où l’agent doit tout structurer, du squelette au manifest ;
Une refonte de feature sur mon projet Visio Mobile, avec une reprise de code conséquente, donc navigation dans l’existant, compréhension du contexte et réécritures profondes.

Premiers retours, à chaud : l’ensemble est un peu lent et très verbeux. K3 aime expliquer ce qu’il fait, détailler ses plans, commenter ses choix ; il faudra apprendre à le canaliser. Mais la qualité est au rendez-vous : le code produit tient la route, y compris sur la reprise conséquente, et c’est bien ce qu’on demande en priorité à un agent de coding.

Second point de vigilance : pour le moment, pas trop de possibilités de régler les hyperparamètres. Au lancement, K3 fonctionne par défaut en effort de raisonnement « max », et les modes low et high ne sont pas encore là. On prend le modèle comme il est, avec sa latence et sa verbosité. À suivre, donc : je reviendrai avec un banc d’essai plus systématique quand j’aurai accumulé assez d’heures de vol, et quand les réglages seront ouverts.

L’angle souveraineté : ouvert, oui. Mais chez qui ça tourne ?

C’est ici que ce billet répond à son titre. Trois observations.

Un. La frontière ouverte n’est plus un sous-frontière. Quand le premier modèle de la classe 3T est ouvert (poids publiés, rapport technique annoncé, contribution déjà poussée à vLLM pour le cache de préfill spécifique à KDA), le débat « open vs propriétaire » change de nature. On ne parle plus de rattrapage, on parle d’un écart qui se mesure en mois, pas en générations. Et pour répondre franchement à la question posée en ouverture : non, il n’y a rien de honteux à utiliser un outil excellent parce qu’il est né ailleurs, du moment qu’on peut lire ses poids, auditer son comportement et le faire tourner ailleurs que chez son éditeur. La honte, si honte il y a, serait plutôt de refuser de regarder ce qui se passe par confort doctrinal.

Deux. Le point dur de la souveraineté se déplace vers l’infrastructure, mais la partie n’est pas jouée d’avance. Commençons par la raison d’espérer : dès que les poids seront publiés, le 27 juillet au plus tard et vraisemblablement sur Hugging Face comme les précédents modèles Kimi, il est fort à parier que la communauté s’en empare. Quantisations communautaires (GGUF, AWQ et consœurs), mécanismes de compression, distillations en modèles plus compacts : tout ce qui avait permis de faire tourner K2 ou DeepSeek R1 sur des environnements plus raisonnables va se rejouer, à cette échelle-ci. Des montages hybrides CPU-GPU façon KTransformers ont déjà fait tourner les gros Kimi sur quelques cartes seulement. Il est donc probable que des déclinaisons de K3 deviennent accessibles à des infrastructures nettement plus faciles à mettre en œuvre en Europe que la configuration de référence.

Car il faut être précis sur ce que cette configuration de référence attend exactement. Quand Moonshot recommande un « supernode » de 64 accélérateurs ou plus, il ne s’agit pas de 64 cartes éparpillées sur un réseau classique : il s’agit d’un même domaine d’interconnexion à très haute bande passante (la famille NVLink chez NVIDIA, ou un équivalent), où les GPU échangent presque comme s’ils partageaient une mémoire commune. Et l’arithmétique explique pourquoi. Une simple règle de trois : 2 800 milliards de paramètres à 4 bits (MXFP4), cela fait environ 1,4 To de poids bruts, avant même de compter les métadonnées de quantification, les activations, les buffers d’exécution et le cache de contexte, qui doit pouvoir absorber des sessions d’un million de tokens. Un serveur de 8 H200, déjà une belle bête avec plus d’un téraoctet de mémoire HBM, ne charge même pas les poids. La parcimonie du MoE n’y change rien : 16 experts actifs par token, certes, mais les 896 doivent tous résider en mémoire en permanence, et le routage impose un trafic intense entre GPU, d’où l’exigence d’un domaine haute bande passante. En ordre de grandeur, 64 accélérateurs de cette classe représentent quelques millions d’euros de matériel : un déploiement de centre de données, pas un serveur d’entreprise.

Les poids seront donc libres ; le compute, lui, ne l’est pas. C’est toute la tension du moment : l’ouverture des poids est une condition nécessaire de la souveraineté, pas une condition suffisante. Ce qui rend l’API officielle intéressante économiquement (tarifs à 0,30 $/MTok en entrée avec cache hit, 3,00 $ sans, 15,00 $ en sortie, taux de hit annoncé au-dessus de 90 % en coding grâce à l’architecture Mooncake) illustre aussi la dépendance : au prix où on sert un 2,8T, l’ingénierie d’inférence compte autant que le modèle. La voie européenne réaliste tient dans cette équation : compression communautaire et dérivés distillés pour les usages modestes, hébergement mutualisé des poids chez des fournisseurs d’inférence européens pour les usages sérieux.

Trois. La transparence monte d’un cran, et il faut s’en saisir. Publication des poids, rapport technique à venir, et, fait notable, une section « Limitations » qui dit les choses : sensibilité à l’historique de pensée (ne pas basculer une session d’un autre modèle vers K3 au milieu du gué), propension à la sur-initiative qu’il faut borner par des contraintes explicites, écart assumé avec les deux leaders propriétaires. Ce niveau de franchise devrait être la norme du secteur. Pour l’écosystème européen, et je pense évidemment aux dynamiques OpenLLM France et EuroCommons, la fenêtre est claire : ces poids-là, on pourra les étudier, les distiller, les adapter. Encore faut-il s’organiser pour le faire, et mutualiser le compute qui va avec.

Et concrètement, pour essayer ?

K3 est disponible dès aujourd’hui sur kimi.com, dans Kimi Work (desktop 3.1.0+, Windows et Mac Apple Silicon), dans Kimi Code en terminal (commande /model), et via l’API (kimi-k3). Kimi Work en profite pour introduire Widgets et Dashboard, des composants interactifs persistants dans la conversation, dont je reparlerai : c’est précisément l’environnement dans lequel ce billet a été préparé, et il y a quelque chose d’assez neuf dans cette façon de rendre le travail avec un agent visible et durable.

En conclusion

Assumons-le sans détour : le premier modèle ouvert de la classe 3T sort d’un laboratoire chinois, et ce n’est pas une coïncidence. Depuis DeepSeek R1, puis Qwen, puis les précédents Kimi, la Chine a pris sur l’open weight un lead qui devient difficile à contester. Sur neuf des douze derniers mois, ce sont les modèles Kimi qui ont fixé la borne supérieure de la taille des modèles ouverts. Autrement dit, la carte du poids ouvert le plus puissant se dessine à Pékin, à Hangzhou, à Shanghai, et il faut arrêter de jouer les surpris.

Il n’y a rien de honteux à tester ces modèles, même s’ils sont chinois, ni à s’en servir pour apprendre. Au contraire : refuser de les évaluer par réflexe géopolitique, ce serait se priver du seul terrain d’observation où l’écart entre l’ouvert et le fermé se resserre vraiment, et surtout se priver d’un outil réellement utile pour travailler dès aujourd’hui. La vraie question, celle qui doit occuper les industriels européens dans les prochains mois, n’est pas de savoir s’il est légitime d’ouvrir Kimi Code sur son poste. Elle est de savoir comment, très concrètement et à courte échéance, l’Europe se donne les moyens d’exécuter ces modèles chez elle, sur ses propres supernodes, sous ses propres règles, de manière autonome et souveraine.

Poids libres, compute captif : la partie qui commence n’est plus celle des modèles, c’est celle des infrastructures. Rendez-vous très vite pour la suite de mon retour d’expérience Kimi Code, quand les réglages seront ouverts et les heures de vol accumulées. Et rendez-vous, tous ensemble, pour que la question de l’autonomie de calcul européenne cesse d’être un chapitre parmi d’autres et devienne le sujet.

Références

Source primaire

Kimi K3 · l’annonce officielle sur le blog Moonshot, 22 juillet 2026. Architecture, études de cas, benchmarks, section « Limitations ».
Moonshot AI · éditeur du modèle.
Modèles Kimi sur Hugging Face · où les poids seront publiés d’ici le 27 juillet.

Écosystème logiciel cité

vLLM · moteur d’inférence open source, contribution Moonshot pour KDA.
KTransformers · déploiement hybride CPU-GPU des gros MoE.
Mooncake · architecture d’inférence désagrégée (cache de préfill mutualisé).
Triton et MLIR · l’écosystème de compilation GPU réimplémenté par K3 en 48h.

Sur ce carnet, la ligne éditoriale continue

Souverain et open source : j’ai fait écrire, tester et corriger un vrai projet par un modèle de 35B · le même exercice, un ordre de grandeur plus bas, le mois dernier.
La Fable que nous raconte Anthropic · pourquoi l’ouverture des poids est la vraie assurance quand un modèle propriétaire peut être coupé en 90 minutes ou surtaxé du jour au lendemain.
How LINAGORA is Building Open AI Models for Europe With NVIDIA Nemotron · la brique européenne (Luciole 1B / 8B / 23B, Apache 2.0), sur Jean Zay, en collaboration avec NVIDIA.
Tout ce que vous avez toujours voulu savoir sur les World Models et JEPA · le débat de fond sur les limites structurelles des LLM autorégressifs, et l’alternative que défend Yann LeCun.
De l’utilisateur augmenté à l’organisation orchestrée · où doivent aller ces modèles ouverts pour créer de la valeur souveraine, côté digital workplace.

Écosystème européen

OpenLLM France · la communauté française des modèles ouverts, dont je suis cofondateur.