MoonshotAI: Kimi K3 (batch)

Kimi K3 est le modèle agentique multimodal à poids ouverts de Moonshot AI pour la programmation de longue haleine, le travail intellectuel et le raisonnement. Il associe le texte à la compréhension visuelle native des images et de la vidéo et produit une réponse textuelle ou une demande d’outil. Le fabricant met en avant les sessions d’ingénierie prolongées, les grands dépôts et les tâches qui utilisent des captures d’écran ou du retour visuel avec du code. Une mission utile définit le livrable souhaité, les éléments à utiliser et la condition qui marque l’achèvement du travail.

Architecture et contexte long

La fiche du modèle décrit un mélange parcimonieux d’experts comptant 2’800 milliards de paramètres au total et 104 milliards activés. Sa conception Stable LatentMoE sélectionne 16 experts sur 896 par jeton, utilisant Kimi Delta Attention et Attention Residuals avec une attention à portes. La longueur exacte du contexte est de 1’048’576 jetons. Cela offre de la place pour un contexte de tâche volumineux, sans justifier l’abandon des frontières entre sources ni de l’espace nécessaire au résultat.

Le livrable natif publié utilise un entraînement tenant compte de la quantification, avec des poids MXFP4 et des activations MXFP8. Il s’agit du format de publication du fabricant, distinct d’une édition quantifiée fournie séparément ou d’une affirmation sur la manière dont une route particulière sert le modèle. Des poids ouverts et un grand nombre de paramètres ne font pas du nombre de paramètres actifs l’exigence totale de stockage ou de matériel.

Préparer une tâche de programmation substantielle

Fournissez les éléments pertinents du dépôt, le comportement existant, le changement demandé et les contraintes de compatibilité. Identifiez les fichiers ou l’interface que le résultat doit toucher, les vérifications qui déterminent la réussite et toute erreur ou entrée fournie qui révèle le problème. Un résultat utile peut être une modification ciblée de code avec une explication et des éléments issus des vérifications réellement exécutées, plutôt qu’une description d’actions jamais effectuées.

Pour une tâche de développement visuel, incluez une capture ou une vue claire du résultat souhaité avec le code pertinent et un écart précis. Le fabricant décrit des processus couvrant les interfaces web, les jeux et la CAO qui utilisent le retour visuel. Demandez le changement qui relie le code au résultat observé et conservez la référence afin de vérifier le livrable par rapport à elle.

Images, vidéo et préparation du travail intellectuel

Le guide de démarrage du producteur utilise des objets de contenu typés pour les messages visuels ; content est un tableau, et non une représentation sérialisée de ce tableau. Son processus image utilise des données d’image encodées ou une référence de fichier prise en charge plutôt qu’une adresse publique d’image. L’exemple vidéo téléverse un fichier vidéo et fournit la référence obtenue avec une question sur son contenu. Donnez une source lisible et précisez l’observation, l’intervalle ou la relation pertinente. Le processus de vision du producteur accepte les images JPEG, PNG, GIF, WebP, BMP, HEIC et HEIF, ainsi que les vidéos MP4, MPEG, MOV, AVI, FLV, MPG, WebM, WMV et 3GPP. Les GIF ou WebP animés peuvent être décodés comme vidéo. Fournissez le code source SVG en texte. Le fabricant recommande des images jusqu’à 4096 × 2160 et des vidéos jusqu’à 1920 × 1080 ; ce sont des recommandations de résolution et non des seuils de rejet. Gardez le corps de requête dans la limite de taille documentée de 100M et téléversez les médias volumineux ou réutilisés fréquemment comme fichiers.

Pour une recherche à forte composante documentaire, identifiez les sources et indiquez les questions auxquelles le rapport final doit répondre. Pour une explication vidéo, identifiez les événements ou la séquence à analyser plutôt que de demander des commentaires sans limite. K3 utilise le contenu visuel comme élément de raisonnement et renvoie du texte ou des demandes d’outils. Une application peut transmettre ces demandes à des outils média pour créer des livrables image ou vidéo séparés.

La réflexion est toujours activée

L’interface du producteur K3 a toujours la réflexion activée. Le réglage de premier niveau reasoning_effort accepte low, high et max, avec max par défaut. Ces choix sont propres au modèle ; un réglage sans réflexion ou une valeur d’effort d’une autre famille ne doit pas être supposé. Les consignes de migration du fabricant distinguent K3 de K2.x en utilisant reasoning_effort plutôt qu’en reprenant l’ancienne configuration thinking.

Le producteur documente des champs reasoning_content et content de réponse finale séparés dans les résultats diffusés progressivement. Pour une conversation à plusieurs tours ou un processus avec outils, il exige que le message complet renvoyé par l’assistant soit retransmis sans modification, y compris reasoning_content et tool_calls. Conserver uniquement la réponse finale visible fait perdre des informations attendues par le processus de réflexion préservée du modèle à l’étape suivante.

Réponses finales structurées et continuation partielle

Le guide de démarrage documente la sortie stricte par schéma JSON pour le contenu du message final. Définissez les champs et leur sens autour du livrable dont l’application a besoin, et analysez ce contenu final plutôt que de le combiner au champ de raisonnement. Un résultat structuré peut représenter des informations extraites d’éléments fournis ou un format défini de rapport ; le schéma contraint sa forme, tandis que les éléments sources déterminent la justesse de ses valeurs.

Le mode partial peut poursuivre un préfixe textuel fourni. L’exemple du producteur place un message partiel de l’assistant à la fin de l’historique et combine ce préfixe à la continuation renvoyée pour l’affichage. Utilisez-le lorsque le livrable requis a un début fixe significatif, en gardant le préfixe distinct de la suite générée.

Outils et continuité de leurs résultats

K3 prend en charge les outils de fonction personnalisés. L’exemple du producteur impose un outil au premier tour, préserve le message complet de l’assistant, exécute chaque appel renvoyé et ajoute un résultat d’outil correspondant avant de demander la réponse finale. Un appel proposé ne prouve pas la réussite de l’opération ; le résultat réellement renvoyé devient l’élément probant pour l’étape suivante.

Son processus de chargement dynamique introduit une définition complète d’outil à un point précis de l’historique des messages. La définition nécessite son nom, sa finalité et ses paramètres et doit rester dans l’historique ultérieur, car le serveur ne conserve pas cette déclaration indépendamment. Gardez associés les capacités des outils, les arguments fournis et les observations réelles afin qu’une tâche longue puisse poursuivre le travail déjà achevé.

Contrôles de sortie et contexte répété

Le producteur documente une allocation de complétion par défaut de 131’072 jetons, configurable jusqu’à 1’048’576 dans les contraintes du contexte global du modèle. Son API K3 actuelle fixe temperature à 1.0, top_p à 0.95, un seul résultat et des pénalités de présence et de fréquence nulles, en demandant aux appelants d’omettre ces contrôles d’échantillonnage. Ce sont les réglages exacts du profil du producteur, et non une liste transférable de contrôles réglables.

La mise en cache du contexte est automatique pour les préfixes répétés admissibles, avec des durées de vie documentées de 5 minutes et 1 heure, et 5 minutes par défaut. Les blocs de cache partiels restent des absences de correspondance. Gardez le contexte réutilisable stable et vérifiez l’usage réel plutôt que d’affirmer une lecture en cache sur la seule base d’un texte répété. Pour le livrable final, conservez les sources fournies, les éléments réels issus des outils et la structure de sortie requise, et vérifiez qu’une longue réponse ou un résultat d’ingénierie satisfait aux critères d’achèvement indiqués.