Kimi K3.1 : rumeurs de fuite, coût du code 3D, quatre niveaux de réflexion et ce que les développeurs doivent vérifier
Selon un article de Leiphone du 23 octobre 2026, un teaser officiel de Kimi contient un easter egg « Kimi K3.1 » ; des développeurs auraient aussi repéré l'identifiant kimi-k3-1 dans la configuration de l'API Moonshot et une option K3.1 dans la liste des modèles Kimi Code. Une requête de fusion SGLang serait liée à l'ajout d'un niveau de réflexion Medium, faisant passer l'intensité de réflexion de trois à quatre niveaux. Le blogueur IA Chris affirme avoir testé le modèle pendant environ une semaine et avance un coût d'environ 70 % de celui de K3 ; l'article indique aussi un coût 3D d'environ 1/14 de celui de GPT-6 Astra. Ces éléments relèvent de rumeurs et de tests unilatéraux.
Ce qui change
Le 23 octobre 2026, Leiphone a rapporté que Kimi avait publié un teaser contenant un easter egg visuel « Kimi K3.1 », interprété comme les prémices d'un nouveau modèle. L'article cite le blogueur IA Chris, qui affirme l'avoir testé pendant environ une semaine : K3.1 serait particulièrement performant sur Three.js, avec un coût d'environ 70 % de celui de Kimi K3 et une meilleure efficacité en tokens ; l'article montre aussi une capture d'une simulation d'environnement jour-nuit de 24 heures. Le rapport recense plusieurs indices de fuite : fin septembre, un développeur aurait trouvé l'identifiant de modèle kimi-k3-1 dans le fichier de configuration de la plateforme API Moonshot ; le 21 octobre, la liste de sélection de modèles de Kimi Code aurait ajouté une option K3.1 ; fin octobre, des modèles anonymes nommés Kibitz et Kalmia seraient apparus dans une arène, Kibitz se montrant solide sur les tâches de code front-end et 3D, et des développeurs auraient déduit qu'il s'agit de K3.1 à partir de caractéristiques de tokenizer. Une requête de fusion dans le dépôt SGLang serait liée à l'ajout d'un niveau de réflexion Medium pour K3.1, étendant l'intensité de réflexion de trois à quatre niveaux. L'article indique que, dans une comparaison de construction dans Minecraft avec GPT-6 Astra, le coût de K3.1 serait d'environ 1/14 de celui de son concurrent, tout en présentant des faiblesses, comme des mouvements peu naturels dans des tâches d'animation telles qu'une girafe qui court. L'article relaie aussi un rapport de Nomura selon lequel Moonshot travaille sur un modèle à plus grand nombre de paramètres, sans lien direct avec K3.1.
Conséquences pour les développeurs
Si ces indices de fuite se concrétisent, l'impact direct pour les développeurs se concentre sur deux points. D'abord la structure de coûts. Les chiffres rapportés — « environ 70 % de K3 » et « environ 1/14 de GPT-6 Astra » — sont des valeurs relatives et non des tarifs, mais ils pointent vers la même chose : dans les tâches de génération de code nécessitant un calcul image par image des sommets, de l'éclairage et des textures, comme Three.js, WebGL ou les grands écrans interactifs, la consommation de tokens et le nombre d'appels par unité produite pourraient être nettement inférieurs à ceux des modèles principaux actuels. Pour les prototypes 3D, les murs d'écrans de visualisation et les pipelines de simulation H5 axés sur la génération de code, cela détermine directement la possibilité de réessayer à faible coût après un échec de génération. Ensuite la granularité de contrôle. L'article indique que l'intensité de réflexion passe de trois à quatre niveaux avec l'ajout d'un niveau Medium, ce qui signifie qu'un même modèle pourrait basculer entre différents niveaux de puissance de calcul selon qu'il s'agit d'une tâche de mise en page simple ou d'une tâche complexe de physique couplée ; si l'orchestration peut être graduée selon la difficulté, les tâches d'agent à longue chaîne pourraient exécuter les étapes courantes en niveau bas et traiter le raisonnement structurel en niveau haut, au lieu de facturer toute la chaîne au niveau le plus élevé. Il faut toutefois noter qu'il s'agit encore de rumeurs et de tests unilatéraux, non confirmés officiellement : la facturation réelle, le nom des niveaux et les politiques de limitation peuvent différer.
Intégration et évaluation
Ce qui suit est une analyse conditionnelle et des recommandations, et non des faits confirmés. Premièrement, face à l'affirmation d'un « coût d'environ 70 % de K3 », le choix est de commencer par un test comparatif à prompt identique, plutôt que de migrer directement le trafic de production. La condition est de pouvoir accéder à K3.1 et que la tâche relève de la génération de code ; le critère d'évaluation est fixé à un même ensemble de prompts de scènes 3D (incluant un exemple de cycle jour-nuit, un exemple de relations spatiales entre plusieurs objets et un exemple de vue éclatée de pièces), en enregistrant le taux de réussite, le nombre de tentatives et la consommation totale ; si la consommation totale après nouvelles tentatives reste inférieure à la référence du modèle actuel, envisager alors une petite part de trafic. Deuxièmement, face à l'« ajout d'un niveau de réflexion Medium », le choix est de spécifier explicitement le niveau selon la complexité de la tâche, plutôt que de conserver un niveau unique. La condition est que l'interface expose réellement un paramètre de niveau ; le critère d'évaluation est de comparer, sur des tâches de raisonnement structurel (comme des liaisons mécaniques ou des vues éclatées) et des tâches de mise en page courantes, si l'écart de qualité entre le niveau haut et le niveau Medium reste dans un seuil acceptable ; si la qualité ne baisse pas sensiblement sur les tâches courantes avec Medium, le définir par défaut. Troisièmement, face à la « déduction des caractéristiques de tokenizer du modèle anonyme Kibitz dans l'arène », le choix est de ne pas assimiler les performances de Kibitz dans les classements à une capacité stable de K3.1 sur la base de suppositions. La condition est que ce qui vous intéresse est le contexte long et le contrôle d'instructions très longues ; le critère d'évaluation est de retester avec votre propre jeu d'instructions longues, en observant où l'adhésion aux instructions se dégrade, plutôt que de se fier uniquement au rang public en test aveugle. Toutes les évaluations devraient être suivies d'une confirmation de la facturation réelle sur les pages de tarifs du fournisseur et de KimiSeek avant de décider d'une montée en charge.
Limites et points à confirmer
Les informations centrales de cet article proviennent d'un easter egg de teaser, de champs de fichiers de configuration, de requêtes de fusion dans une base de code et de suppositions sur des modèles anonymes d'arène ; aucune n'a été confirmée par une publication officielle. Les chiffres (70 %, 1/14) sont des rumeurs ou des tests unilatéraux, et non des références vérifiées. Kimi K3.1 n'apparaît pas actuellement dans le catalogue de vente de KimiSeek ; la configuration API, la liste Kimi Code et la disponibilité d'appel mentionnées renvoient au côté fournisseur, et aucune version de ce type n'est appelable sur KimiSeek ; le Kimi K3 du catalogue est une version différente et ne peut pas être considéré comme le même modèle. Les cas de faiblesse cités (mouvements peu naturels d'une girafe qui court) comme les cas positifs sont des tests d'internautes, dont la taille d'échantillon et la méthode ne sont pas précisées, et les performances des modèles comparés n'ont pas été reproduites indépendamment. Les détails des niveaux de réflexion dans la requête de fusion SGLang, leur nom réel et les différences de facturation ne peuvent pas être confirmés par cet article. Le rapport de Nomura sur un modèle à plus grand nombre de paramètres, relayé par l'article, n'a pas de lien avec K3.1 et ferait état de contraintes de calcul et d'une progression incertaine. Pour les prix et la disponibilité réels, se référer aux pages de tarifs du fournisseur et de KimiSeek ; les prix peuvent être ajustés à tout moment.
Illustrations de l’article original
