Moonshot ouvre Kimi K2 : un MoE de 1 000 milliards de paramètres conçu pour les agents

Moonshot AI a publié les poids de Kimi K2, un modèle de type Mixture-of-Experts de 1 trillion de paramètres, dont 32 milliards sont mobilisés pour chaque token. Deux versions sont disponibles : Kimi-K2-Base, pour ceux qui veulent affiner le modèle eux-mêmes, et Kimi-K2-Instruct, pour le chat et les scénarios d'agents. Instruct ne raisonne pas longuement : il répond immédiatement. Une mise à jour 0905 est sortie ensuite, avec un meilleur codage agentique et un contexte de 256K. Selon l'entreprise, K2 affiche le meilleur résultat parmi les modèles sans mode thinking en connaissances, en mathématiques et en code.

MuonClip : entraîner un trillion de paramètres sans accroc

La principale nouveauté technique ne tient pas à la taille, mais à l'optimiseur. L'équipe de Moonshot mise depuis longtemps sur Muon. Dans son travail précédent, Moonlight, il avait nettement surpassé AdamW, l'optimiseur habituel, en efficacité d'utilisation des tokens. Pour K2, cette approche a été mise à l'échelle sur une architecture proche de DeepSeek-V3. À partir d'une analyse des scaling laws, les ingénieurs ont réduit le nombre de têtes d'attention pour gagner en efficacité sur le contexte long, et augmenté la sparsité du MoE pour améliorer l'efficacité par token.

À grande échelle, un problème est apparu : avec Muon, les logits d'attention explosent plus souvent. Le logit soft-capping et la normalisation des query et key n'ont pas suffi. La solution est qk-clip. Après chaque pas de Muon, les poids des projections query et key sont multipliés par un coefficient η. Il est égal à min(t / max(qᵀk), 1), où t est fixé à l'avance. L'échelle des logits est ainsi bornée à la source, et non après coup. Résultat : le préentraînement sur 15.5 trillions de tokens s'est déroulé sans un seul pic de loss. Moonshot souligne par ailleurs que cette technique est générale et peut servir à d'autres tâches de stabilisation.

D'où viennent les compétences d'agent

Le modèle a appris à agir en deux étapes. D'abord, l'équipe a construit un pipeline de données synthétiques inspiré d'ACEBench. Il couvre des centaines de domaines et des milliers d'outils, à la fois de vrais outils MCP et des outils synthétiques, et génère des centaines d'agents dotés de jeux d'outils différents. Les agents interagissent avec un environnement simulé et des utilisateurs simulés. Les tâches sont évaluées selon des grilles, et un LLM-juge écarte les trajectoires faibles. Le reste alimente le rejection sampling et le RL.

La seconde étape est un RL généraliste, où les tâches les plus difficiles sont celles sans récompense vérifiable, comme la rédaction d'un rapport de recherche. Ici, le modèle joue son propre critique et évalue le résultat selon des grilles. Le critique est réajusté en continu sur des on-policy rollouts assortis de récompenses vérifiables (mathématiques, code de compétition), afin que l'évaluation reste alignée sur la politique.

Dans les démonstrations, K2 choisit seul ses outils. Une analyse de salaires a nécessité 16 appels IPython. Un plan de voyage à Londres pour un concert de Coldplay a été monté en 17 appels, via la recherche, l'agenda, Gmail, les billets d'avion, Airbnb et les restaurants. Dans la démo Flask-to-Rust, le modèle réécrit un projet et lance des benchmarks.

Paramètres clés

• Architecture : MoE, 1 trillion de paramètres, 32 milliards actifs
• Préentraînement : 15.5 trillions de tokens, optimiseur MuonClip, sans accroc
• Publication : Kimi-K2-Base et Kimi-K2-Instruct
• Contexte après la mise à jour 0905 : 256K
• Moteurs d'inférence : vLLM, SGLang, KTransformers, TensorRT-LLM
• API : compatible avec les interfaces d'OpenAI et d'Anthropic

Que tester, et où sont les pièges

Pour un test rapide, le modèle est accessible gratuitement dans Kimi, en version web et mobile. Les fonctions MCP y sont encore en développement, et la vision n'est pas prise en charge. Pour les développeurs, le plus simple est de passer par l'API, qui accepte les clients OpenAI et Anthropic : il n'y a presque pas de code à modifier, il suffit de changer l'endpoint et le modèle. Pour une installation sur son propre matériel, les auteurs recommandent les moteurs listés ci-dessus et renvoient aux instructions sur GitHub. Un trillion de paramètres exige un cluster sérieux : l'exécution en local convient donc pour l'instant aux équipes qui disposent déjà de l'infrastructure.

Moonshot reconnaît elle-même des limites. Sur les raisonnements complexes, ou quand la description des outils est floue, le modèle peut générer des tokens superflus : la réponse est alors tronquée ou l'appel d'outil reste incomplet. Avec les outils activés, la qualité baisse sur certaines tâches. Un projet logiciel entier généré à partir d'un seul prompt donne de moins bons résultats que dans un harnais d'agent. Conclusion pratique : prévoyez des limites de tokens, décrivez clairement les schémas d'outils et donnez à K2 une boucle avec des tests et des logs plutôt qu'une seule grosse requête. L'entreprise promet d'ajouter plus tard le mode thinking et la vision.