Passer au contenu principal
Guide pratique Kimi K3 : mode de réflexion, chargement dynamique d'outils et cache de contexte
Cet article présente les nouveaux paramètres de Kimi K3 et les points d’attention lors de son appel. Sur AIHubMix, K3 est accessible via les API Chat Completions, Responses et Messages (compatible Claude). Lecture complémentaire : documentation officielle de la plateforme Moonshot. Les conclusions « Vérifié » et les exemples de réponses de chaque section proviennent d’appels réels effectués le 2026-07-17 via les API AIHubMix (Chat Completions / Responses / Messages).

1. Aperçu des spécifications du modèle

Vérifié : les deux limites de stop sont bien contrôlées, tout dépassement renvoie une erreur 400 ; le paramètre stop_sequences de l’API Messages applique les mêmes contrôles. L’API Messages ne suit pas la sémantique Anthropic lorsqu’une séquence d’arrêt est atteinte : en pratique, stop_reason vaut "end_turn" (et non "stop_sequence"), stop_sequence vaut null, et le texte visible précédant la séquence d’arrêt peut être vide. Les clients qui s’appuient sur ces deux champs pour déterminer la cause de la troncature doivent en tenir compte.

2. Mode de réflexion : reasoning_effort limité au niveau max

La réflexion de K3 est activée par défaut, et reasoning_effort ne prend en charge que le niveau "max". En conversation multi-tours, l’historique de réflexion doit être renvoyé tel quel : selon les indications officielles de Moonshot, K3 est entraîné avec la méthode preserved thinking ; en conversation multi-tours, le message assistant renvoyé au tour précédent doit être retransmis intégralement et à l’identique (contenu de réflexion inclus). Un historique de réflexion manquant entraîne une qualité de sortie instable. Si vous utilisez un framework de gestion de session ou une couche proxy, vérifiez que le contenu de réflexion n’est pas tronqué avant le renvoi.
Le contenu de réflexion est renvoyé dans le champ reasoning_content de la réponse ; en multi-tours, retransmettez tel quel le message assistant du tour précédent (avec reasoning_content).
Vérifié : la réponse renvoie reasoning_content ; après retransmission telle quelle du message assistant du tour précédent (avec reasoning_content), les tours suivants répondent normalement.

3. Paramètres d’échantillonnage à valeurs fixes

Les paramètres d’échantillonnage de K3 sont fixés par les valeurs officielles : temperature 1.0, top_p 0.95, n 1, presence_penalty / frequency_penalty 0. La recommandation officielle est de ne pas transmettre ces paramètres dans les requêtes.
Remarque : les valeurs d’échantillonnage fixes relèvent de la spécification officielle et ne peuvent pas être vérifiées à partir des signaux de réponse ; conformément à la recommandation officielle, omettez ces paramètres.

4. Appel d’outils et chargement dynamique d’outils

tools prend en charge jusqu’à 128 outils ; tool_choice permet de forcer ou de désactiver l’appel d’outils. K3 prend également en charge le chargement dynamique d’outils : injection de nouveaux outils en cours de conversation via le champ tools d’un message system (forme de message propre à l’API Chat).
tool_choice prend en charge auto / none / required ; required force le modèle à appeler un outil. Chargement dynamique d’outils : le message system injectant les outils ne porte pas de content, les outils injectés prennent effet aux tours suivants, et chaque requête doit les inclure de nouveau.
Vérifié : tool_choice: "required" force un appel d’outil même sur une question sans rapport ; "none" supprime l’appel d’outils ; un outil injecté en cours de conversation via un message system sans content peut être appelé normalement.

5. Sortie structurée

La sortie structurée permet au modèle de renvoyer un contenu strictement conforme au JSON Schema fourni.
response_format prend en charge json_schema et le mode strict.
Vérifié : la sortie est un JSON valide conforme au schema.

6. Cache de contexte activé automatiquement

Le cache de contexte de K3 est activé automatiquement, sans aucun paramètre à transmettre. Lorsqu’un long préfixe répété touche le cache, le volume touché est rapporté dans usage (le nom du champ varie selon l’API). Le tarif du cache est indiqué sur la page du modèle.
Vérifié : la deuxième requête avec un long préfixe identique rapporte le hit de cache dans usage.prompt_tokens_details.cached_tokens.

7. Continuation de préfixe avec partial

La continuation de préfixe fait poursuivre la génération du modèle à partir d’un préfixe donné, ce qui convient à la complétion de code et aux sorties au format contrôlé.
Passez "partial": true dans le dernier message assistant.
Vérifié : la génération se poursuit à partir du préfixe donné, sans répéter le préfixe.

8. Entrée visuelle

Les images sont transmises en base64 ; l’écriture du bloc de contenu varie selon l’API.
Vérifié : l’entrée d’image en base64 fonctionne, le modèle décrit correctement le contenu de l’image de test.

9. Référence mesurée : durée et consommation d’un appel unique sur une tâche longue

La réflexion de K3 est fixée au niveau max ; sur les tâches complexes, la durée d’une requête unique est nettement plus longue que celle des modèles classiques. Données mesurées sur une tâche de génération d’un jeu HTML en fichier unique (un seul prompt avec image de référence, génération en une passe, sans itération) : durée de la requête unique 2,541 secondes (environ 42 minutes), 74,994 completion tokens dont 54,486 de réflexion (73 %), pour un résultat final de 1,275 lignes de code directement exécutable, avec finish_reason à stop. Recommandations côté appelant :
  • réglez le délai d’expiration du client à l’échelle de la minute au minimum, et privilégiez le streaming pour les tâches longues ;
  • prévoyez une marge suffisante pour max_completion_tokens : dans cet exemple, la réflexion seule consomme 54,486 tokens.

10. Matrice de prise en charge capacités × API

Chaque cellule du tableau ci-dessous correspond à un résultat vérifié le 2026-07-17 par appel réel des API AIHubMix en production ; la cellule indique l’écriture du paramètre / champ pour l’API correspondante.

FAQ

Quelles API K3 prend-il en charge sur AIHubMix ? Chat Completions (/v1/chat/completions), Responses (/v1/responses) et Messages compatible Claude (/v1/messages). Peut-on désactiver la réflexion ou en réduire l’intensité ? Non. La réflexion de K3 est activée par défaut et reasoning_effort ne prend en charge que le niveau "max". Pourquoi faut-il retransmettre reasoning_content en conversation multi-tours ? K3 est entraîné avec la méthode preserved thinking ; la consigne officielle est de retransmettre intégralement et à l’identique le message assistant du tour précédent. Un historique de réflexion manquant entraîne une qualité de sortie instable. Quelles sont les limites du paramètre stop ? Au plus 5 séquences d’arrêt, chacune de 32 octets maximum ; tout dépassement renvoie une erreur 400. L’API Messages prend-elle en charge la sortie structurée ? ❗ Non. Le point de terminaison officiel Messages (compatible Anthropic) de Kimi K3 ignore silencieusement les champs de sortie structurée (retour 200 avec du texte libre, sans erreur). Pour une sortie structurée, utilisez response_format de Chat Completions ou text.format de Responses. Pourquoi une requête unique K3 prend-elle autant de temps ? La réflexion de K3 est fixée au niveau max ; sur les tâches complexes, la part des tokens de réflexion est élevée (73 % des completion tokens dans le cas mesuré). Il est recommandé de régler le délai d’expiration du client à l’échelle de la minute au minimum et d’utiliser le streaming.
Les tarifs et l’état en temps réel du modèle sont disponibles sur la page du modèle Kimi K3 ; retrouvez plus de modèles sur la place des modèles. Dernière mise à jour : 2026-07-17