L'API Kimi est facturée à l'usage, sans formule d'abonnement. Comparer uniquement le « prix par million de tokens » conduit facilement au mauvais choix : ce qui détermine réellement la facture, ce sont le modèle, la longueur du contexte, le taux de cache et la longueur de sortie. La série K2 offre un contexte de 262 144 tokens, et K3 va jusqu'à 1 048 576 ; cette capacité de contexte long est un atout, mais elle signifie aussi que le coût d'entrée s'accumule plus facilement.

Cet article décompose la structure de facturation de la série K2, les sources de coût du contexte long, une méthode d'estimation reproductible et l'ordre de réduction des coûts, sans figer de prix unitaire. Les prix exacts sont régis par la documentation officielle et les prix des modèles du site.

Note : Moonshot et Kimi sont des marques de leurs titulaires. Les modèles, les longueurs de contexte et les règles de facturation peuvent évoluer. Cet article décrit les pratiques courantes d'octobre 2026 ; vérifiez à nouveau la page officielle avant tout achat.

1. Comment se répartit la série K2

Modèle Positionnement Contexte Tâches adaptées Point d'attention sur le coût
kimi-k2.6 Généraliste 262 144 Dialogue, extraction, support, traitement documentaire Taux de cache
kimi-k2.7-code Code 262 144 Génération de code, questions sur un dépôt, agents Entrée longue, nombreux résultats d'outils
kimi-k2.7-code-highspeed Code haute vitesse 262 144 Complétion à faible latence, codage interactif Équilibre entre prix unitaire et débit
kimi-k3 Nouvelle génération 1 048 576 Documents très longs, tâches multi-étapes complexes Contexte long et écriture de cache

Les modèles évoluent et la série K2 pourrait recevoir de nouvelles versions. Pour un achat, référez-vous à la liste officielle des modèles et aux prix des modèles ; ne considérez pas les noms cités ici comme un engagement permanent.

Pour les tâches générales, inutile d'utiliser par défaut le contexte maximal. Envoyer tout un dossier dans un contexte de 1M fait grimper le coût d'entrée à chaque tour ; il est généralement plus économique de réduire d'abord par recherche, puis de faire lire au modèle les extraits clés. Pour les tâches de code, c'est l'inverse : la structure du dépôt et les retours d'outils doivent souvent être conservés, et l'enjeu est de stabiliser le préfixe et d'améliorer le taux de cache.

2. Une facture composée de trois blocs

La série K2 facture trois postes : entrée en cache touché, entrée hors cache et sortie. K3 facture en outre l'écriture de cache selon deux durées de vie distinctes, 5 minutes et 1 heure ; on ne peut donc pas multiplier un prix unitaire moyen par le total de tokens.

Poste de facturation Quand il apparaît Effet sur le coût Moyen de contrôle
Entrée hors cache Prompts, documents et résultats d'outils nouveaux Croissance linéaire avec le contexte Recherche, résumé, réduction de l'historique
Entrée en cache touché Prompt système répété, préfixe fixe Généralement bien inférieur au prix hors cache Préfixe stable, ordre d'outils fixe
Tokens de sortie Contenu et réflexion générés par le modèle Les sorties longues gonflent la facture Limiter max_completion_tokens
Écriture de cache (K3) Écriture d'un préfixe en cache Tarif selon la durée de vie Ne mettre en cache que le contenu stable et réutilisé

En décomposant une requête, la formule de coût est :

Coût d'une requête =
  tokens d'entrée hors cache × prix hors cache
+ tokens d'entrée en cache × prix du cache touché
+ tokens de sortie × prix de la sortie

Pour K3, il faut ajouter l'écriture de cache. Le champ usage de la réponse fournit prompt_tokens, completion_tokens et prompt_tokens_details ; le cache touché et l'écriture de cache sont tous deux inclus dans prompt_tokens, et la partie non mise en cache s'obtient en soustrayant ces deux postes du total.

3. Pourquoi le contexte long coûte vite cher

Scénario Structure de tokens typique Coût principal Axe d'optimisation
Questions sur document long Entrée élevée, sortie moyenne Document renvoyé plusieurs fois Recherche et cache
Agent sur dépôt de code Entrée et sortie élevées Résultats d'outils et historique Résumé, réduction, cache
Support multi-tours Entrée croissante avec les tours Historique répété Résumé glissant
Extraction par lots Entrée moyenne, sortie courte Document relu plusieurs fois Traitement par lots et petit modèle

Les écarts viennent généralement de cinq points :

  1. Accumulation de l'entrée avec les tours : renvoyer le texte complet à chaque tour fait approximativement doubler la facture avec le nombre de tours.
  2. Taux de cache : un préfixe fixe est réutilisable ; des horodatages, identifiants aléatoires ou tris dynamiques à chaque requête cassent le cache.
  3. Sorties d'outils : une recherche ou une exécution de code renvoie un journal entier, renvoyé tel quel au tour suivant, et le coût s'additionne.
  4. Longueur de sortie : une consigne ouverte comme « analyse détaillée » produit facilement une sortie longue, généralement plus chère qu'une entrée en cache.
  5. Mauvais choix de modèle : un grand modèle pour une classification simple, ou des tentatives répétées avec un modèle inadapté sur une tâche complexe, gonflent le coût.

4. Réaliser une estimation reproductible

  1. Sélectionnez 20 à 50 tâches réelles couvrant les niveaux simple, moyen et complexe, avec des critères d'acceptation explicites.
  2. Quantifiez l'entrée avec une interface d'estimation de tokens, sans deviner à partir du nombre de caractères.
  3. Exécutez le même lot sur kimi-k2.6 et sur le modèle de code, en relevant qualité, latence et nombre de reprises.
  4. Lisez dans usage l'entrée, la sortie, le cache touché et l'écriture de cache.
  5. Comparez le coût « par tâche conforme terminée », et non le tarif par million de tokens.
  6. Intégrez au coût par tâche les nouvelles tentatives, les échecs et l'écriture de cache.
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.cn/v1",
)

resp = client.chat.completions.create(
    model="kimi-k2.6",
    messages=[{"role": "user", "content": "Extrais ce contrat en JSON : ..."}],
    max_completion_tokens=1024,
)

u = resp.usage
print("entrée", u.prompt_tokens, "sortie", u.completion_tokens)
print("détail du cache", getattr(u, "prompt_tokens_details", None))

En streaming, ajoutez stream_options={"include_usage": True} ; l'usage complet n'arrive que dans le dernier bloc. Multipliez ensuite par les prix unitaires réels du contrat ou de la page des prix, sans réutiliser une capture d'écran vieille de plusieurs mois.

5. L'ordre de réduction des coûts

  1. Traiter d'abord le cache : fixez le prompt système, les définitions d'outils et le préfixe de base de connaissances, puis vérifiez avec cached_tokens que le cache est réellement touché.
  2. Réduire ensuite l'entrée : ne récupérez que les extraits pertinents, résumez l'historique, n'envoyez pas toute la base dans le contexte.
  3. Limiter la sortie : définissez un max_completion_tokens raisonnable, exigez du JSON ou des champs fixes, réduisez les formules de politesse.
  4. Router par modèle : kimi-k2.6 pour les tâches générales, les versions K2.7 de code pour le code, K3 seulement pour les documents très longs.
  5. Passer les requêtes longues en streaming : le streaming ne change pas le prix unitaire, mais réduit les nouvelles tentatives dues aux délais dépassés et aux connexions interrompues.
  6. Surveiller et alerter : suivez l'usage par projet, modèle et scénario, fixez des plafonds budgétaires et passez en revue chaque semaine le classement des consommations.

N'inversez pas l'ordre. Traitez d'abord le cache et l'entrée, puis envisagez un modèle moins cher ; sinon, vous ne ferez que produire des réponses erronées à moindre coût.

6. Gérer budget et facturation

  • une clé par projet, avec un budget quotidien par projet pour éviter qu'une activité consomme tout le quota ;
  • un rapprochement mensuel par projet, modèle et scénario, pour identifier les appels qui progressent le plus vite ;
  • une trace séparée du taux de cache, du nombre de nouvelles tentatives et de la longueur moyenne de sortie, sans laquelle l'effet des optimisations ne peut pas être démontré ;
  • pour les équipes ayant besoin de paiement en yuans et de factures, une passerelle IA locale peut unifier la facturation multi-modèles ; les prix et règles de facturation sont régis par les prix des modèles.

Questions fréquentes

K2 ou K3 : lequel est le plus avantageux ?

Cela dépend de la tâche. La série K2 offre un contexte de 262 144 tokens, suffisant pour la plupart des documents et scénarios de code ; K3 dispose d'un contexte plus grand, adapté aux documents très longs. Comparez le coût total « par tâche conforme terminée », pas le seul prix unitaire.

Combien le cache permet-il d'économiser ?

Cela dépend du taux de réutilisation du préfixe et du taux de réussite. L'entrée en cache touché est généralement bien inférieure à l'entrée hors cache, et un cache touché prolonge sa durée de validité ; mais si le préfixe change à chaque fois ou reste trop court, il n'y aura pas de cache.

Le streaming coûte-t-il moins cher ?

Il ne change pas directement le prix unitaire. Son intérêt est de réduire les coûts cachés liés aux délais dépassés, aux connexions interrompues et aux nouvelles tentatives sur les requêtes longues.

Pourquoi la facture dépasse-t-elle l'estimation ?

Les oublis fréquents incluent l'historique des messages, les retours d'outils, le texte intégral des documents, les nouvelles tentatives, les sorties longues et les entrées hors cache. Recoupez les journaux de requêtes avec usage pour localiser l'écart.

Comment une équipe locale peut-elle payer en yuans ?

Elle peut appeler Kimi via une passerelle IA proposant la recharge en yuans et des factures, avec une facturation multi-modèles unifiée. Les modèles disponibles, les prix et les règles de facturation sont régis par les prix des modèles.

Étape suivante

Créez d'abord une clé de test sur ZSQH AI Gateway, exécutez un lot de tâches réelles avec kimi-k2.6 et avec le modèle de code, en relevant tokens, cache et qualité, puis choisissez le modèle principal. La disponibilité des modèles et les prix sont régis par les prix des modèles.

Lectures associées :