Moonshot AI a publié Kimi K2.6, un modèle open-weight de 1 000 milliards de paramètres orienté code et agents autonomes. Sur plusieurs benchmarks de codage, il devance Claude Opus 4.6 et GPT-5.4, et ses poids sont librement accessibles sur Hugging Face sous licence Modified MIT.
C'et la période de la lune de miel pour Moonshot AI qui occupe en 2026 la première place des laboratoires chinois sur les modèles ouverts selon Artificial Analysis. K2.6 arrive trois mois après K2.5, avec des scores en nette progression sur l'ensemble des catégories. Sur SWE-Bench Pro, test de résolution d'issues GitHub réelles, K2.6 obtient 58,6 points, GPT-5.4 57,7 et Claude Opus 4.6 53,4. Sur DeepSearchQA, 83,0 pour K2.6, 80,6 pour Claude Opus 4.6, 63,7 pour GPT-5.4. Sur Terminal-Bench 2.0, K2.6 affiche 66,7 contre 65,4 pour ses deux concurrents fermés.
Pour Latent Space, K2.6 est le premier modèle ouvert à concurrencer frontalement les modèles fermés de pointe sur le codage agentique.
Techniquement, K2.6 adopte une architecture Mixture-of-Experts : 1 000 milliards de paramètres au total, 32 milliards activés par token, ce qui maintient un coût de calcul par token proche d'un modèle dense de taille intermédiaire. La fenêtre de contexte atteint 256 000 tokens. La quantification INT4, entraînée en boucle fermée et non ajoutée après coup, produit une inférence environ deux fois plus rapide qu'en FP16, avec des scores à 1-2 % du modèle pleine précision selon AllThings.how. K2.6 fonctionne dès le premier jour sur vLLM, SGLang, KTransformers et OpenRouter, via un endpoint compatible avec les SDK OpenAI et Anthropic.
Des scores produits et mesurés par Moonshot
La quasi-totalité des évaluations publiées sortent du laboratoire lui-même. Moonshot AI a utilisé son propre framework interne adapté de SWE-agent, avec une température fixée à 1.0, une moyenne calculée sur dix runs et un contexte de 262 144 tokens, ainsi que plusieurs benchmarks maison comme « Kimi Code Bench » ou « Claw Bench ».
Les scores de GPT-5.4 et Claude Opus 4.6 marqués d'un astérisque dans le tableau officiel ont été réévalués par Moonshot dans ces mêmes conditions, faute de chiffres publics disponibles. Pour DeepSearchQA, les scores d'Anthropic et d'OpenAI proviennent du System Card officiel d'Anthropic, produit dans un cadre expérimental distinct de celui utilisé par Moonshot pour K2.6.
Au moment de la publication, aucune reproduction indépendante n'avait validé l'ensemble de ces chiffres. Dans le billet officiel de Moonshot, des entreprises comme Vercel, Augment Code, Baseten et Ollama font état de gains par rapport à K2.5 dans leurs environnements propres, sans confrontation directe aux modèles fermés. Latent Space salue l'exécution de Moonshot tout en notant que K2.6 affiche moins d'ambition technique isolément que K2.5 lors de sa sortie en janvier.
Une licence ouverte sur les poids mais fermée sur l'entraînement
Moonshot publie les poids sur Hugging Face sous licence Modified MIT. Le fichier THIRD_PARTY_NOTICES révèle que l'architecture réutilise du code de modélisation de DeepSeek-V3, lui-même sous licence MIT. Les données d'entraînement, la recette complète et le pipeline d'évaluation n'apparaissent dans aucune documentation publiée. Un tiers souhaitant auditer ou reproduire l'entraînement n'a pas les éléments pour le faire, ce qui distingue K2.6 de l'« open-source » au sens de l'Open Source Initiative.
Sur le plan pratique, l'accès aux poids sur Hugging Face n'ouvre pas pour autant un déploiement autonome à faible coût. En version INT4, K2.6 pèse environ 594 Go et requiert au minimum quatre GPU H100 80 Go. En version FP16, le modèle dépasse les deux téraoctets. Selon AllThings.how, l'infrastructure cloud pour un nœud INT4 coûte entre 8 000 et 12 000 dollars par mois, et l'API Moonshot revient moins cher en dessous de cinq milliards de tokens mensuels.
Source : The Information (accès payant)
Dans le cadre du DMA, un « gatekeeper » désigne une grande plateforme numérique considérée comme un passage obligé entre les entreprises et les utilisateurs (app store, moteur de recherche, messagerie, etc.). Ce statut est défini par des critères de taille, d’impact sur le marché et de contrôle durable d’un service central. Une fois désignée, l’entreprise doit respecter des obligations d’ouverture et d’équité, comme éviter certains auto-préférencements et faciliter l’accès de concurrents à des fonctionnalités clés. Le non-respect peut entraîner des amendes importantes et, en cas de récidive, des mesures structurelles. L’objectif est de réduire les effets de verrouillage et d’abaisser les barrières à l’entrée sur les marchés numériques.
Qu’est-ce que le « sideloading » et en quoi diffère-t-il d’un App Store classique ?Le sideloading correspond à l’installation d’applications depuis une source autre que la boutique officielle de l’OS, par exemple via un fichier d’installation ou une boutique alternative. Dans un App Store classique, la plateforme centralise la distribution, la validation, les règles de publication et une partie de la sécurité (revue, signatures, retraits). Avec le sideloading, la responsabilité est davantage répartie entre l’éditeur, la source de téléchargement et l’utilisateur, ce qui peut augmenter la surface de risque (malwares, faux sites, mises à jour détournées). Pour limiter ces risques, certains systèmes imposent des mécanismes techniques comme la signature obligatoire, des permissions plus strictes ou des avertissements renforcés. Sur le plan concurrentiel, cela peut aussi réduire la dépendance à un canal unique de distribution.
À quoi sert la signature de code (code signing) dans la distribution d’applications, et quelles sont ses limites ?La signature de code permet de vérifier qu’une application provient bien d’un éditeur identifié et qu’elle n’a pas été modifiée depuis sa publication. Techniquement, elle repose sur la cryptographie asymétrique : l’éditeur signe, l’OS vérifie la signature avec un certificat de confiance. C’est un garde-fou essentiel pour contrer les versions altérées et sécuriser la chaîne de mise à jour. En revanche, cela ne garantit pas qu’une application est « saine » : un logiciel malveillant peut aussi être signé si l’attaquant obtient un certificat ou compromet un compte développeur. L’efficacité dépend donc aussi de la gestion des certificats, de la révocation et des contrôles côté plateforme.
