Tarification de l'API Kimi K3, mesurée : couper le raisonnement « toujours actif »

La documentation de Kimi K3 affirme qu’on ne peut pas désactiver le raisonnement et que reasoning_effort n’accepte que "max". Dans nos mesures, l’API accepte quand même "none", et ça marche : la même question triviale coûte 0,00179 $ avec le raisonnement par défaut et 0,000285 $ sans, soit un facteur 6,3. K3 est sorti le 16/07/2026 à 3 $ par million de tokens en entrée et 15 $ par million en sortie, le prix catalogue le plus élevé jamais affiché par un labo chinois et le même tarif que Claude Sonnet 5. À ce prix de sortie, les tokens de raisonnement que le modèle dépense par défaut constituent l’essentiel de la facture, ce qui rend cet interrupteur non documenté digne d’être compris avec précision.

TL;DR

• Avec les réglages par défaut, Kimi K3 consacre 69 à 93 % de ses tokens de sortie au raisonnement ; un paragraphe de 120 mots a été facturé 2 289 tokens de sortie, soit 0,0346 $.
• reasoning_effort: "none" est accepté malgré ce que dit la doc, et a divisé par 6,3 le coût de nos requêtes simples, mais l’arithmétique en plusieurs étapes est passée de 3/3 correctes à 0/6.
• Le prompt cache de Kimi K3 se déclenche à partir d’environ 256 tokens de préfixe, par blocs de 256 tokens, avec un tarif de lecture de 0,30 $/M.
• Le chinois est la voie CJK la moins chère de K3 : 52 tokens nets pour 100 caractères, en dessous de GLM-5.2 et DeepSeek à 58.

Tout ce qui suit a été mesuré le 20/07/2026 sur kimi-k3, disponible sur le gateway Synthorai aux prix catalogue de Moonshot, avec des prompts répétés et « salés » pour contourner les caches de réponse, et les affirmations sur le comportement vérifiées via un second chemin de requête indépendant. Chaque chiffre est appuyé par des relevés d’usage bruts.

Combien coûte une réponse Kimi K3 par défaut ?

Le reasoning domine la facture quelle que soit la forme de la tâche envoyée, y compris celles qui n’en ont aucun besoin. Par réponse, avec les réglages par défaut :

Le graphique existe surtout pour ce contraste entre modèles : GPT-5.6 raisonne de façon adaptative (zéro token de thinking sur les questions triviales et factuelles, 65-70% sur les maths et la rédaction), Claude Sonnet 5 est livré avec le thinking désactivé, et GLM-5.2 raisonne encore plus que K3 en proportion. Mais le prix de sortie de GLM est de 4,40 $/M contre 15 $/M pour K3, si bien que la même réponse à 17×23 est facturée $0.00078 sur GLM-5.2, $0.00027 sur GPT-5.6, $0.0001 sur Sonnet 5 et $0.0018 sur K3. L’écart se creuse avec la longueur de sortie : le paragraphe identique de 120 mots coûte $0.0346 sur K3 contre $0.0186 sur GLM-5.2, $0.0072 sur GPT-5.6 et $0.0024 sur Sonnet 5, soit un facteur 15 sur la tâche la plus banale du lot. Le taux d’imposition est comparable aux autres modèles de reasoning chinois ; le montant de la facture, non.

Deux autres faits du mode par défaut à intégrer au budget. D’abord, le mode thinking injecte un préambule caché d’environ 67 tokens dans chaque requête : un message d’un seul mot est facturé 86 tokens de prompt avec le reasoning activé et 19 sans. C’est le « prompt système caché » que les premiers testeurs ont repéré, et il disparaît en même temps que le reasoning. Ensuite, K3 est lent pour l’instant : nos appels sur les questions triviales prenaient environ 19 à 24 secondes de bout en bout avec le reasoning activé, et 3 à 8 secondes sans, conditions de service de semaine de lancement comprises. Prévoyez la latence, pas seulement les dollars.

Peut-on désactiver le raisonnement de Kimi K3 ?

Oui, malgré la documentation. La référence API officielle indique que K3 « active toujours le thinking » et que reasoning_effort n’accepte que "max". En pratique, l’endpoint a accepté "none", "low", "medium" et "high" sans erreur, les a bien pris en compte, et nous avons confirmé le même comportement via un chemin de requête indépendant. Sur le problème arithmétique multi-étapes, le curseur fonctionne, mais reste grossier :

Deux choses ressortent. Les réglages intermédiaires se regroupent : de low à max, on obtient des nombres de tokens similaires et une précision identique sur cette tâche. Le seul vrai basculement est donc binaire. Et none provoque une vraie chute : forcé à répondre de façon lapidaire à un problème arithmétique multi-étapes, K3 s’est trompé six fois sur six, avec des réponses fausses dispersées plutôt qu’une erreur systématique. Quand on n’imposait pas de format concis, le modèle ignorait parfois la consigne de brièveté et déroulait les étapes directement dans sa réponse visible : correct, mais les tokens sont passés du champ de raisonnement au champ texte au lieu de disparaître.

La latence bouge moins que ne le suggèrent les nombres de tokens. En streamant le même problème à chaque niveau d’effort, les temps de premier octet allaient de 6 à 24 secondes, avec des plages qui se chevauchent largement d’un niveau à l’autre. Même none, sans rien à raisonner, attendait 12-13 secondes : à cette taille de tâche, c’est le service qui domine le temps jusqu’au premier token. Ce que le curseur change réellement, c’est l’écart entre le premier octet et le premier token de réponse, c’est-à-dire la phase de thinking que l’utilisateur subit.

En clair : none est un vrai levier de coût pour les tâches de recherche, de formatage ou à une seule étape, et un piège pour tout ce qui demande des étapes intermédiaires. Rien ne garantit dans la documentation que ce paramètre continuera de fonctionner ; considérez-le comme un comportement observé, vérifiez-le dans vos propres champs usage, et attendez-vous à ce qu’il soit formalisé ou supprimé quand la doc sera à jour.

Quand faut-il laisser le raisonnement actif sur des charges agent ?

Nous avons passé K3 dans cinq scénarios de type agent, deux fois chacun, en configuration par défaut contre reasoning_effort: "none", avec des tâches simples identiques que les deux configurations ont réussies intégralement :

La surprise vient de la première ligne : dans les boucles d’appels d’outils, K3 raisonne à peine, même en configuration par défaut (8% de part), il y a donc peu à économiser. Le modèle traite la sélection d’outils comme un réflexe, pas comme une délibération. Les économies se concentrent là où la part du thinking est élevée et la tâche mécanique (recherches RAG et extraction par lots), c’est-à-dire précisément là où une taxe fixe toujours active a le moins sa place. Pour des plans d’agent réellement multi-étapes, la chute de précision de la section précédente s’applique : laissez le raisonnement actif et dépensez les tokens.

À l’échelle, l’effet sur la latence est réel même si les appels isolés sont bruités : sur ces scénarios, les premiers tokens arrivaient en 10-19 secondes en configuration par défaut et en 8-13 secondes avec none, et la génération tournait à une médiane de 35 tokens par seconde sur les sorties substantielles. Ces chiffres, service en semaine de lancement inclus, conviennent mieux à des formats asynchrones et par lots qu’à quoi que ce soit de conversationnel aujourd’hui.

Le reasoning renvoyé est-il refacturé comme de l’input ?

Oui, token pour token. La doc de Kimi précise qu’il faut conserver le reasoning_content de chaque tour assistant dans l’historique des messages, sans le modifier. Nous avons mesuré le coût de cette pratique : un second tour envoyé avec la chaîne de raisonnement du premier tour a facturé 599 prompt tokens ; la même requête sans elle en a facturé 198. La différence de 401 tokens correspond presque exactement aux 402 reasoning tokens du premier tour. Le raisonnement conservé réintègre donc chaque requête suivante au tarif input plein de 3 $/M, et une longue conversation repaie son raisonnement accumulé à chaque tour.

Le supprimer n’est pas automatiquement moins cher pour autant. Privé de la chaîne de raisonnement précédente, K3 a re-raisonné la question de suivi à zéro : les reasoning tokens du second tour ont augmenté de 31 % (de 343 à 449). À 3 $/M en input contre 15 $/M en output, garder la CoT était l’option la moins chère au global dans notre test. Le conseil de la doc tient donc autant sur le coût que sur la qualité. Le vrai levier ici, c’est le prompt cache de la section suivante : un historique conservé forme un préfixe stable, et les préfixes stables cessent d’être facturés au plein tarif.

Kimi K3 met-il les prompts en cache, et à partir de combien de tokens ?

Le prompt cache de K3 est automatique, et son seuil est bas : les hits commencent autour de 256 tokens de préfixe partagé et progressent par blocs de 256 tokens (un prompt de 303 tokens en a mis 256 en cache ; un prompt de 153 tokens n’a jamais été mis en cache malgré les tentatives répétées). L’input en cache est facturé 0,30 $/M, soit une remise fixe de 90 % sur le tarif frais de 3 $/M, sans surcoût d’écriture en cache sur aucun de nos appels. Le warm-up a demandé entre deux et cinq appels identiques avant le premier hit ; un seul essai ne prouve donc rien, dans un sens comme dans l’autre. Il faut mesurer sur plusieurs appels.

Pour situer, ce seuil vaut le quart du minimum de 1 024 tokens documenté par OpenAI, et la taille de bloc est plus grossière que la granularité de 64 tokens mesurée ailleurs. La durée de vie relève du best-effort plutôt que d’un TTL fixe : dans notre test, les entrées en cache ont survécu à des périodes d’inactivité de 4 et 15 minutes, tandis qu’un intervalle de 8 minutes a raté le cache. Traitez donc l’expiration comme une éviction dépendante de la charge et vérifiez la répartition du cache à chaque appel. Un dernier point tarifaire qui mérite un calcul : la fenêtre de contexte de 1M tokens est facturée à tarif fixe, sans palier long-contexte au tarif. Une fenêtre saturée coûte 3,00 $ d’input frais par appel, et 0,30 $ une fois le préfixe chaud. Les workloads à gros contexte dépendent donc bien plus du cache que du prix affiché. Si votre trafic réutilise un system prompt ne serait-ce que de quelques centaines de tokens, le cache de K3 se déclenche là où celui de la plupart des fournisseurs n’aurait même pas commencé. Le fonctionnement et la façon de vérifier les hits via usage sont couverts dans notre guide du prompt caching et l’étude sur les minimums de cache mesurés.

Le chinois coûte-t-il réellement plus cher sur Kimi K3 ?

Non. C’est justement en chinois que le tokenizer de K3 est le plus efficace par rapport à ses concurrents, ce qui répond à une question revenue sans cesse lors des discussions de la semaine du lancement. Voici le nombre net de tokens pour 100 caractères sur des passages sémantiquement équivalents, une fois l’overhead d’enveloppe déduit :

K3 facture le chinois à 52 tokens pour 100 caractères, soit 11 % de moins que GLM-5.2 et DeepSeek, et moins de la moitié de Sonnet 5. Son point faible est le japonais, où il paie 16 à 24 % de plus que les autres modèles open-weight. Nous avons aussi confirmé que le tokenizer est identique dans toute la famille : K3, K2.7-code et K2.5 produisent des comptes identiques sur les 23 échantillons alignés, donc les budgets par langue calculés pour K2 restent valables. Notre étude le LLM le moins cher par langue montre comment la densité du tokenizer se combine avec le prix par token sur neuf langues.

FAQ

Quand les poids open-weight de Kimi K3 seront-ils publiés ?

Moonshot a promis les poids complets sous une licence MIT modifiée d’ici le 27 juillet 2026 ; à la date de cette publication, K3 est disponible uniquement via API. L’expression « le plus grand modèle à poids ouverts jamais créé » est un engagement, pas encore un lien de téléchargement. Le comportement du cache dans l’écosystème à poids ouverts que ces poids rejoindront est cartographié dans prompt caching for open-weight LLMs.

Qu’est-ce qui change réellement dans K3 par rapport à la famille K2 ?

Sur la facture, trois choses que nous avons mesurées : le prix (K3 à 3/15 $ contre K2.7-code à 0,95/4 $, soit un bond de 3,2 à 3,75x), le raisonnement toujours actif (K2.5 ne raisonne pas du tout, K2.7-code a un interrupteur), et rien d’autre : le tokenizer est identique octet pour octet entre K3, K2.7-code et K2.5 sur nos 23 échantillons alignés, donc les budgets de tokens de l’ère K2 restent valables. Sur la fiche technique, d’après Moonshot : un nouveau MoE de 2,8T paramètres (896 experts, 16 actifs par token) avec Kimi Delta Attention, une fenêtre de contexte de 1M tokens contre 256K pour K2.7-code, et l’entrée d’image native. Nous avons mesuré les affirmations de facturation, pas celles sur l’architecture.

Kimi K3 supporte-t-il la sortie structurée ?

Oui. Un response_format avec json_schema a retourné un objet valide et conforme au schéma dans notre test. À noter : le raisonnement tourne toujours en dessous. Sur cet appel d’extraction, 66 des 97 tokens de sortie étaient du raisonnement. Les appels contraints par schéma paient donc la taxe du raisonnement comme le reste, sauf si vous ajoutez aussi reasoning_effort: "none".

Désactiver le raisonnement change-t-il ce que l’on peut voir ?

Oui. Par défaut, K3 renvoie toute sa chaîne de raisonnement dans reasoning_content, et la doc conseille de la repasser telle quelle dans l’historique multi-tours. Avec reasoning_effort: "none", ce champ disparaît complètement, et le préambule de raisonnement d’environ 67 tokens disparaît avec lui de votre facture de prompt.

Mesuré le 2026-07-20 sur kimi-k3 aux prix catalogue de la semaine de lancement (3 $/M en entrée, 0,30 $/M en cache, 15 $/M en sortie). Les prompts répétés ont été salés pour éviter les caches au niveau des réponses ; les comptes de précision reposent sur des tâches à réponse unique vérifiable ; les affirmations comportementales ont été reproduites sur un second chemin de requête indépendant. Les prix et le comportement peuvent évoluer à mesure que la version se stabilise ; vérifiez avec vos propres relevés usage avant de vous fier à un chiffre présenté ici.

← Retour au blog