MoonshotAI: Kimi K3 (batch)

Kimi K3 est le modèle agentique multimodal à poids ouverts de Moonshot AI pour la programmation de longue durée, le travail intellectuel et le raisonnement. Il associe le texte à une compréhension visuelle native des images et des vidéos et produit une réponse textuelle ou une demande d’outil. Le fabricant souligne les sessions d’ingénierie prolongées, les grands dépôts et les tâches utilisant des captures ou des retours visuels avec le code. Une consigne utile définit le livrable souhaité, les éléments à utiliser et la condition marquant l’achèvement.

Architecture et contexte long

La fiche décrit un mélange clairsemé d’experts avec 2 800 milliards de paramètres au total et 104 milliards de paramètres activés. Sa conception Stable LatentMoE sélectionne 16 experts parmi 896 par token, utilisant Kimi Delta Attention et Attention Residuals avec une attention à portes. La longueur exacte de contexte est de 1 048 576 tokens. Cela offre de la place pour un contexte de tâche important, sans justifier l’abandon des délimitations de sources ni de l’espace nécessaire au résultat.

L’artefact natif publié utilise un entraînement tenant compte de la quantification, avec des poids MXFP4 et des activations MXFP8. C’est le 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. Les poids ouverts et un grand nombre de paramètres ne transforment pas le nombre de paramètres actifs en besoin total de stockage ou de matériel.

Préparer une tâche de programmation importante

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

Pour une tâche de développement visuel, incluez une capture ou une vue claire du résultat prévu, avec le code pertinent et un écart précis. Le fabricant décrit des processus de frontend, de jeux et de CAO utilisant les retours visuels. Demandez la modification reliant le code au résultat observé et conservez la référence pour vérifier le livrable obtenu par rapport à elle.

Préparer images, vidéos et 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 résultante avec une question sur son contenu. Donnez une source lisible et précisez l’observation, l’intervalle ou la relation pertinente. Le processus visuel 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 des vidéos. Fournissez la source SVG comme 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 comme fichiers.

Pour une recherche documentaire dense, identifiez les sources et indiquez les questions auxquelles le rapport final doit répondre. Pour expliquer une vidéo, identifiez les événements ou la séquence à analyser plutôt que de demander un commentaire sans limites. K3 utilise les contenus visuels comme éléments 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.

Réflexion 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, max étant la valeur par défaut. Ces choix sont propres au modèle ; il ne faut pas supposer un réglage sans réflexion ni une valeur d’effort venant d’une autre famille. Les consignes de migration du fabricant distinguent K3 de K2.x par l’utilisation de reasoning_effort plutôt que la reprise de l’ancienne configuration thinking.

Le producteur documente reasoning_content et le contenu de réponse finale séparément dans les résultats en streaming. Pour une conversation à plusieurs échanges ou un processus outillé, il exige que l’intégralité du message d’assistant retourné soit retransmise sans changement, y compris reasoning_content et tool_calls. Conserver uniquement la réponse finale visible perd 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 une sortie stricte selon un schéma JSON pour le contenu du message final. Définissez les champs et leur sens autour du livrable nécessaire à l’application 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 des éléments fournis ou un format de rapport défini ; le schéma contraint sa forme, tandis que les sources déterminent l’exactitude des valeurs.

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

Outils et continuité des résultats

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

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

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

Le producteur documente une autorisation de complétion par défaut de 131 072 tokens, configurable jusqu’à 1 048 576 dans les contraintes globales de contexte 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 du profil exact 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 TTL documentées de 5 minutes et 1 heure, et 5 minutes par défaut. Les blocs partiels restent des échecs de cache. Gardez le contexte réutilisable stable et vérifiez l’usage réel au lieu d’affirmer un succès de cache sur la seule répétition du texte. Pour le livrable final, préservez les sources fournies, les éléments réels issus des outils et la structure de sortie requise, puis vérifiez qu’une réponse longue ou un résultat d’ingénierie satisfait les critères d’achèvement indiqués.