Tarifs de l’API Kimi K3, mesures à l’appui : désactivez le raisonnement permanent

La documentation de Kimi K3 affirme que le raisonnement ne peut pas être désactivé et que reasoning_effort n’accepte que "max". Lors de nos mesures, l’API a pourtant accepté "none", et ce réglage fonctionne : la même question triviale coûte $0.00179 avec le raisonnement par défaut, contre $0.000285 sans raisonnement, soit un écart de 6.3x. Lancé le 2026-07-16, K3 est facturé $3 par million de tokens en entrée et $15 par million en sortie. C’est le tarif catalogue le plus élevé jamais proposé par un laboratoire chinois, au même niveau que Claude Sonnet 5. À ce prix de sortie, les tokens de raisonnement consommés par défaut constituent l’essentiel de la facture. Il faut donc comprendre précisément le fonctionnement de ce réglage non documenté.

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 qu’indique la documentation et a divisé par 6.3x le coût de nos requêtes simples. En revanche, la précision sur un calcul en plusieurs étapes est passée de 3/3 à 0/6.
• Le prompt cache de Kimi K3 commence à produire des hits à partir d’environ 256 tokens de préfixe, par blocs de 256 tokens, au tarif de lecture de $0.30/M.
• Parmi les langues CJK, le chinois est la moins coûteuse avec K3 : 52 tokens nets pour 100 caractères, contre 58 pour GLM-5.2 et DeepSeek.

Toutes les mesures ci-dessous ont été réalisées le 2026-07-20 sur kimi-k3, disponible sur la gateway Synthorai aux tarifs catalogue de Moonshot. Nous avons ajouté un sel aux prompts répétés afin d’éviter les caches de réponse, puis vérifié les observations comportementales via un second chemin de requête indépendant. Chaque chiffre s’appuie sur les données d’usage brutes.

Combien coûte une réponse de Kimi K3 avec les réglages par défaut ?

Le raisonnement domine la facture pour tous les types de tâches testés, même lorsqu’aucun raisonnement n’est nécessaire. Voici le coût par réponse avec les réglages par défaut :

Le graphique met surtout en évidence l’écart entre les modèles : GPT-5.6 adapte son raisonnement à la tâche, avec zéro token de réflexion sur les questions triviales et factuelles, puis 65-70% sur les tâches de mathématiques et de rédaction. Claude Sonnet 5 désactive la réflexion par défaut. En proportion, GLM-5.2 raisonne encore davantage que K3. Mais les tokens de sortie de GLM coûtent $4.40/M, contre $15/M pour K3. La même réponse à 17×23 a donc été facturée $0.00078 avec GLM-5.2, $0.00027 avec GPT-5.6, $0.0001 avec Sonnet 5 et $0.0018 avec K3. L’écart augmente avec la longueur de la sortie : le même paragraphe de 120 mots a coûté $0.0346 avec K3, contre $0.0186 avec GLM-5.2, $0.0072 avec GPT-5.6 et $0.0024 avec Sonnet 5. Cela représente un écart de 15x sur la tâche la plus ordinaire de l’échantillon. La part consacrée au raisonnement est comparable à celle d’autres modèles de raisonnement chinois ; son coût ne l’est pas.

Deux autres caractéristiques du mode par défaut doivent entrer dans vos estimations. D’abord, le mode de réflexion ajoute un préambule caché d’environ 67 tokens à chaque requête : un même message d’un mot a été facturé 86 tokens de prompt avec le raisonnement activé, contre 19 sans. C’est ce « prompt système caché » que les premiers testeurs avaient remarqué. Il disparaît avec le raisonnement. Ensuite, K3 est lent pour le moment : nos appels sur des questions triviales ont pris environ 19-24 secondes de bout en bout avec le raisonnement, contre 3-8 secondes sans, dans les conditions de service de la semaine de lancement. Prévoyez un budget de latence, pas seulement un budget financier.

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

Oui, malgré la documentation. La référence officielle de l’API indique que K3 « active toujours la réflexion » et que reasoning_effort n’accepte que "max". En pratique, l’endpoint a accepté "none", "low", "medium" et "high" sans erreur, et a bien appliqué ces valeurs. Nous avons confirmé le même comportement via un chemin de requête indépendant. Sur le problème en plusieurs étapes, le réglage fonctionne, mais reste peu granulaire :

Deux constats se dégagent. Les réglages intermédiaires sont très proches : de low à max, le nombre de tokens et la précision restent similaires sur cette tâche. Le seul vrai choix est donc binaire. Avec none, la qualité chute brutalement : lorsqu’on lui impose une réponse concise à un problème arithmétique en plusieurs étapes, K3 se trompe six fois sur six. Les mauvaises réponses varient, sans erreur systématique unique. Lorsque nous n’imposions pas de format concis, le modèle ignorait parfois la consigne de brièveté et détaillait les étapes directement dans sa réponse visible. Le résultat était alors correct, mais les tokens avaient simplement migré du champ de raisonnement vers le champ texte au lieu de disparaître.

La latence varie moins que le nombre de tokens ne le laisse penser. En streaming, sur le même problème et pour chaque niveau d’effort, le délai avant le premier octet variait entre 6-24 secondes, avec de larges recouvrements entre les niveaux. Même none, qui n’avait aucun raisonnement à effectuer, attendait 12-13 secondes. À cette échelle de tâche, l’infrastructure de service domine donc le délai avant le premier token. Ce réglage modifie surtout l’intervalle entre le premier octet et le premier token de réponse, c’est-à-dire la phase de réflexion pendant laquelle l’utilisateur attend.

En pratique, none permet réellement de réduire les coûts pour les tâches de recherche d’information, de mise en forme ou à une seule étape. C’est en revanche un piège pour tout ce qui exige des étapes intermédiaires. Rien ne garantit officiellement que ce paramètre continuera de fonctionner. Considérez-le comme un comportement observé, vérifiez-le dans vos propres champs usage et prévoyez qu’il puisse être officialisé ou supprimé lorsque la documentation sera mise à jour.

Quand faut-il conserver le raisonnement dans les workloads d’agents ?

Nous avons testé K3 deux fois sur cinq scénarios proches de workloads d’agents : une fois avec les réglages par défaut, puis avec reasoning_effort: "none". Les tâches simples étaient identiques et les deux configurations les ont toutes réussies :

La première ligne est surprenante : dans les boucles d’appels d’outils, K3 réfléchit très peu, même avec les réglages par défaut, puisque cette part n’est que de 8%. Les économies possibles sont donc limitées. Le modèle traite le choix d’un outil comme un réflexe, pas comme une délibération. Les gains se concentrent sur les tâches mécaniques où la part de réflexion est élevée, notamment les recherches RAG et l’extraction par lots. Ce sont précisément les cas où une taxe fixe de raisonnement permanent est la moins justifiée. Pour les plans d’agents qui exigent réellement plusieurs étapes, la chute de précision décrite plus haut s’applique : laissez le raisonnement activé et acceptez le coût en tokens.

À grande échelle, l’effet sur la latence est mesurable, même si les appels individuels restent variables. Sur ces scénarios, les premiers tokens sont arrivés en 10-19 secondes avec les réglages par défaut, contre 8-13 secondes avec none. Pour les sorties substantielles, la génération atteignait une médiane de 35 tokens par seconde. Ces chiffres, qui incluent les conditions de service de la semaine de lancement, conviennent aujourd’hui davantage aux traitements asynchrones et par lots qu’aux usages conversationnels.

Le raisonnement renvoyé dans l’historique est-il refacturé en entrée ?

Oui, token pour token. La documentation de Kimi recommande de conserver sans modification le reasoning_content de chaque réponse assistant dans l’historique des messages. Nous en avons mesuré le coût : un deuxième tour incluant la chaîne de pensée du premier a été facturé 599 tokens de prompt, contre 198 pour la même requête sans cette chaîne. L’écart de 401 tokens correspond presque exactement aux 402 tokens de raisonnement du premier tour. La réflexion conservée est donc réinjectée dans chaque requête suivante au plein tarif d’entrée de $3/M. Dans une conversation longue, le raisonnement accumulé est refacturé à chaque tour.

Le supprimer ne coûte pas forcément moins cher. Sans la chaîne de pensée précédente, K3 a repris tout le raisonnement depuis le début : au deuxième tour, les tokens de raisonnement ont augmenté de 31%, passant de 343 à 449. Avec une entrée à $3/M et une sortie à $15/M, conserver la CoT s’est révélé moins cher au total dans notre test. La recommandation de la documentation se justifie donc aussi bien par le coût que par la qualité. Le levier réellement efficace est le prompt cache présenté dans la section suivante : l’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 ont commencé à environ 256 tokens de préfixe partagé, puis ont progressé par blocs de 256 tokens. Un prompt de 303 tokens en a mis 256 en cache ; un prompt de 153 tokens n’a jamais produit de hit malgré plusieurs tentatives. Les entrées mises en cache sont facturées $0.30/M, soit une réduction fixe de 90% par rapport au tarif de $3/M des entrées non mises en cache. Aucun de nos appels n’a entraîné de surcoût d’écriture dans le cache. La mise en température a demandé entre deux et cinq appels identiques avant le premier hit. Un seul nouvel essai ne suffit donc pas à conclure ; mesurez-en plusieurs.

À titre de comparaison, ce seuil représente un quart du minimum documenté de 1,024 tokens chez OpenAI. La taille des blocs est également moins fine que la granularité de 64 tokens que nous avons mesurée ailleurs. La durée de vie est en best effort plutôt que fondée sur un TTL fixe : dans notre test, des entrées ont survécu à des périodes d’inactivité de 4 et 15 minutes, alors qu’une autre n’a pas produit de hit après 8 minutes. Il faut donc considérer l’expiration comme une éviction dépendant de la charge et vérifier la répartition des tokens en cache à chaque appel. Autre point tarifaire à intégrer au calcul : la fenêtre de contexte de 1M-token est facturée à tarif fixe, sans tranche spécifique pour les contextes longs dans la grille tarifaire. Une fenêtre saturée coûte $3.00 d’entrée non mise en cache par appel, puis $0.30 une fois le préfixe en cache. Pour les workloads à grand contexte, la viabilité économique dépend donc bien plus du cache que du tarif affiché. Si votre trafic réutilise un prompt système de quelques centaines de tokens seulement, le cache de K3 entre en jeu avant même d’atteindre le seuil minimal de la plupart des fournisseurs. Le fonctionnement du cache et la vérification des hits via usage sont détaillés dans notre guide du prompt caching et notre étude sur les seuils minimaux mesurés des prompt caches.

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

Non. Par rapport aux modèles concurrents, le tokenizer de K3 est particulièrement efficace en chinois. Cela répond à une question souvent posée pendant la semaine de lancement. Voici le nombre net de tokens pour 100 caractères sur des passages sémantiquement alignés, après soustraction de l’enveloppe technique :

Avec K3, le chinois représente 52 tokens pour 100 caractères, soit 11% de moins que GLM-5.2 et DeepSeek, et moins de la moitié de Sonnet 5. Le point faible de K3 est le japonais, où il consomme 16-24% de tokens supplémentaires par rapport aux autres modèles open-weight. Nous avons également confirmé que le tokenizer est identique dans toute la gamme : K3, K2.7-code et K2.5 ont produit les mêmes résultats sur les 23 échantillons alignés. Les budgets par langue établis pour K2 restent donc valables. L’effet combiné de la densité de tokenisation et du prix par token dans neuf langues est analysé dans notre étude sur le LLM le moins cher selon la langue.

FAQ

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

Moonshot a promis de publier l’ensemble des poids sous licence Modified MIT d’ici le July 27, 2026 ; à la date de cet article, K3 reste accessible uniquement via API. Sa présentation comme le « plus grand modèle open-weight jamais créé » correspond donc à un engagement, pas encore à un lien de téléchargement. Le fonctionnement du cache dans l’écosystème open-weight que ces poids doivent rejoindre est détaillé dans notre article sur le prompt caching pour les LLM open-weight.

Qu’apporte réellement K3 par rapport à la gamme K2 ?

Sur la facture, nous avons mesuré trois différences : le tarif, avec $3/$15 pour K3 contre $0.95/$4 pour K2.7-code, soit une hausse de 3.2-3.75x ; le raisonnement permanent, alors que K2.5 ne raisonne pas du tout et que K2.7-code propose un réglage ; et rien d’autre. Le tokenizer produit exactement les mêmes octets avec K3, K2.7-code et K2.5 sur nos 23 échantillons alignés. Les budgets en tokens établis à l’époque de K2 restent donc valables. Sur la fiche technique, Moonshot annonce un nouveau MoE de 2.8T paramètres, avec 896 experts dont 16 actifs par token, Kimi Delta Attention, une fenêtre de contexte de 1M-token contre 256K pour K2.7-code, et une prise en charge native des images en entrée. Nous avons mesuré les affirmations tarifaires, pas celles sur l’architecture.

Kimi K3 prend-il en charge les sorties structurées ?

Oui. Dans notre test, un response_format avec json_schema a renvoyé un objet valide et conforme au schéma. Le raisonnement reste toutefois actif en arrière-plan : sur cet appel d’extraction, 66 des 97 tokens de sortie étaient consacrés au raisonnement. Les appels contraints par un schéma paient donc eux aussi la taxe de réflexion, sauf si vous définissez également reasoning_effort: "none".

La désactivation du raisonnement modifie-t-elle ce qui est visible ?

Oui. Avec les réglages par défaut, K3 renvoie l’intégralité de sa chaîne de pensée dans reasoning_content, et la documentation recommande de la réinjecter sans modification dans l’historique multitour. Avec reasoning_effort: "none", ce champ disparaît entièrement, tout comme le préambule de réflexion d’environ 67 tokens ajouté à la facture du prompt.

Mesures réalisées le 2026-07-20 sur kimi-k3, aux tarifs catalogue de la semaine de lancement ($3/M en entrée, $0.30/M pour les entrées en cache, $15/M en sortie). Un sel a été ajouté aux prompts répétés afin d’éviter les caches au niveau des réponses ; les mesures de précision reposent sur des tâches ayant une réponse unique et vérifiable ; les observations comportementales ont été reproduites via un second chemin de requête indépendant. Les prix et le comportement peuvent évoluer à mesure que la version mûrit. Vérifiez vos propres données usage avant de vous appuyer sur les chiffres présentés ici.

← Retour au blog