Tarifs et facturation de l'API Moonshot (2026) : cache et contexte long

L'API Moonshot désigne l'interface de modèles fournie par la plateforme ouverte de Moonshot AI, c'est-à-dire la plateforme développeur derrière Kimi. Elle se facture à l'usage en tokens, sans forfait par abonnement. Beaucoup d'équipes se trompent à deux endroits lors du budget : elles appellent encore les modèles moonshot-v1 retirés, ou elles mélangent entrées, écritures de cache, sorties et reprises dans un prix unitaire moyen. Cet article décompose la structure de facturation à partir des documents publics d'octobre 2026 ; les prix exacts font foi sur la page Tarifs des modèles et dans la documentation officielle.

Remarque : Moonshot et Kimi sont des marques de leurs détenteurs respectifs. Cet article est purement technique et n'implique aucune affiliation ni relation d'agence avec les détenteurs. La liste des modèles, les longueurs de contexte et les règles de facturation peuvent évoluer ; vérifiez à nouveau les pages officielles avant l'achat.

1. Distinguer les modèles actuels des modèles retirés

En octobre 2026, la documentation de la plateforme ouverte liste comme modèles principaux kimi-k3, kimi-k2.6, kimi-k2.7-code et kimi-k2.7-code-highspeed. L'ancienne série moonshot-v1 a disparu : moonshot-v1-8k, -32k, -128k, -auto et leurs versions de prévisualisation visuelle ont été retirées le 31 août 2026, en même temps que kimi-k2.5. Les préversions plus anciennes kimi-k2 et kimi-latest ne sont plus non plus en service.

Modèle	Contexte	Structure de facturation	État et remarques
`kimi-k3`	1 048 576	Entrée, cache touché, écriture de cache, sortie	Modèle phare actuel, cible de migration recommandée par l'éditeur
`kimi-k2.6`	262 144	Entrée, cache touché, sortie	Usage général et multimodal, fréquent sur les scénarios sensibles au coût
`kimi-k2.7-code`	262 144	Entrée, cache touché, sortie	Génération de code, questions sur dépôt et agents
`kimi-k2.7-code-highspeed`	262 144	Entrée, cache touché, sortie	Tâches de code à faible latence
`moonshot-v1-8k/32k/128k`	Selon le nom	Ancien palier par longueur	Retirés le 31 août 2026

Les noms de modèles des anciens tutoriels ne se recopient pas tels quels. Le « 8k » de moonshot-v1-8k désignait déjà le palier de contexte : un échec d'appel ne vient pas de la clé, mais du modèle qui n'existe plus. Pour migrer, changez d'abord le nom, puis vérifiez le contexte et les postes de facturation ; ne faites pas un simple remplacement de chaîne.

2. Unité de facturation : une requête en quatre postes

La facture actuelle se compose généralement de quatre types de tokens : entrée non touchée par le cache, entrée touchée par le cache, écriture de cache et sortie. Pour K3, l'écriture de cache est facturée séparément selon deux TTL, 5 minutes et 1 heure ; la page tarifs de la série K2 ne distingue pas de poste d'écriture de cache. La formule d'une requête s'écrit :

coût d'une requête =
  tokens d'entrée non touchés × prix non touché
+ tokens d'entrée touchés × prix touché
+ tokens d'écriture de cache × prix du TTL correspondant (K3 uniquement)
+ tokens de sortie × prix de sortie

La documentation officielle donne une conversion utile : un texte chinois standard compte environ 1,5 à 2 caractères par token. Multiplier directement le nombre de caractères par le prix unitaire sous-estime l'entrée ; pour une estimation sérieuse, utilisez l'interface POST /v1/tokenizers/estimate-token-count ou lisez directement usage dans la réponse.

Les champs d'usage de Chat Completions sont usage.prompt_tokens et usage.completion_tokens, le détail du cache se trouvant dans usage.prompt_tokens_details.cached_tokens et cache_write_tokens. Dans l'API Messages, input_tokens exclut la partie en cache : l'entrée totale additionne input_tokens, cache_read_input_tokens et cache_creation_input_tokens. Pour le streaming, activez stream_options.include_usage=true.

3. Comment le cache est facturé et pourquoi il ne touche pas

Le cache de contexte fonctionne par correspondance de préfixe, pas sur l'ensemble de la conversation. Si un élément du préfixe change, tout ce qui suit ne peut pas être réutilisé. Les comportements qui cassent le préfixe incluent : insérer un horodatage ou un identifiant aléatoire dans le prompt système, réordonner les définitions d'outils à chaque appel, assembler dynamiquement des passages de base de connaissances, changer de palier TTL. Le cache est aussi isolé par organisation : il ne se partage pas entre organisations.

Chez K3, l'écriture de cache est facturée à la première écriture, avec un TTL fixé à 5 minutes ou 1 heure ; après écriture, le palier ne peut pas être changé en cours de route. Un hit prolonge gratuitement le cache selon le TTL d'origine, sans nouveaux frais d'écriture. Les deux paliers ne communiquent pas. Si la fin du préfixe ne forme pas un bloc de cache complet, cette partie est généralement traitée comme non touchée.

Le cache n'est pas un interrupteur « activé, donc économies » : c'est de l'ingénierie de préfixe. Placez au début le prompt système, les définitions d'outils, les exemples fixes et la partie commune de la base de connaissances, mettez les variables à la fin, puis vérifiez le taux de hit avec cached_tokens.

4. Coût du contexte long : le prix de la retransmission

K3 prend en charge un contexte de 1 048 576 tokens, la série K2 de 262 144 tokens. K3 applique une facturation uniforme à l'usage et n'a plus, comme l'ancien moonshot-v1, de paliers à 8k, 32k et 128k : on ne peut donc pas extrapoler K3 à partir de l'ancienne grille par paliers.

Le contexte long n'est pas un problème en soi ; le problème est de retransmettre le même matériel à chaque tour. Dans un questions-réponses sur un document de 200 000 tokens, dix tours successifs avec le texte complet font grimper le coût d'entrée rapidement ; les journaux d'outils, le corps des pages web et les résultats de code restent aussi dans l'historique et continuent d'être facturés. L'approche courante consiste à rechercher d'abord les passages pertinents, puis à les faire lire au modèle ; à utiliser un résumé glissant pour les dialogues ; à mettre la partie stable en préfixe de cache ; et à réserver le contexte long aux textes qui doivent être conservés intégralement.

Le contexte long amplifie aussi la latence et le taux d'échec. Une longue requête non streaming rencontre plus facilement un timeout de passerelle, et la reprise ajoute de nouveaux tokens d'entrée. Pour les tâches longues, privilégiez le streaming et fixez un timeout de lecture raisonnable.

5. Reprises et requêtes en échec : comment sont-elles facturées

Les codes d'erreur officiels classent les 429 en trois catégories : rate_limit_reached_error pour un plafond de concurrence, RPM, TPM ou TPD au niveau de l'organisation ; exceeded_current_quota_error pour un solde ou quota insuffisant ; engine_overloaded_error pour une surcharge de capacité côté serveur. Seul un problème de solde se règle par une recharge ; une surcharge de capacité ne disparaît pas nécessairement en rechargeant. Les 500 et 503 invitent généralement à réessayer plus tard ; pour un timeout de passerelle sur une requête longue, mieux vaut passer au streaming que renvoyer la requête telle quelle.

La documentation officielle ne promet pas que les requêtes en échec sont gratuites. La prudence consiste à ne pas supposer que les reprises sont sans coût : rapprochez les journaux de requêtes et le champ usage, et comptez les reprises séparément. La stratégie de reprise peut suivre cet ordre :

Classer d'abord par code d'erreur ; ne réessayez pas un impayé, une erreur de paramètre ou un refus de modération.
Ne réessayez de façon limitée que les 429 de limitation, les 500, les 503 et les coupures réseau.
Utilisez un backoff exponentiel avec gigue aléatoire et respectez Retry-After.
Fixez un plafond de tentatives et une durée totale pour ne pas immobiliser la concurrence.
Pour les appels d'outils, prévoyez une clé d'idempotence ou une table de déduplication afin d'éviter une double commande ou un double message.
Enregistrez request_id, le nom du modèle, l'usage de tokens et le nombre de reprises pour faciliter le rapprochement.

6. Estimer le budget : des tokens au plafond mensuel

Ne partez pas du « prix par million de tokens » pour remonter au budget ; partez des tâches réelles. Choisissez 20 à 50 tâches représentatives, couvrant les niveaux simple, moyen et complexe, avec des critères d'acceptation explicites ; mesurez l'entrée avec l'interface d'estimation, lisez le usage réel, puis comparez les modèles sur le « coût total pour produire un résultat conforme ».

import os
import requests

resp = requests.post(
    "https://api.moonshot.cn/v1/tokenizers/estimate-token-count",
    headers={"Authorization": f"Bearer {os.environ['MOONSHOT_API_KEY']}"},
    json={
        "model": "kimi-k3",
        "messages": [{"role": "user", "content": "Extrais ce contrat en JSON : ..."}],
    },
    timeout=30,
)
print(resp.json()["data"]["total_tokens"])

Après l'estimation de l'entrée d'une requête, ajoutez quatre éléments : l'historique des messages, les retours d'outils, la proportion d'entrées non touchées par le cache et les appels supplémentaires dus aux reprises. Pour le traitement hors ligne, évaluez Batch API : la documentation officielle l'annonce environ 40 % moins cher que l'appel synchrone, mais seuls kimi-k2.7-code et kimi-k2.6 sont pris en charge, kimi-k3 ne l'étant pas encore.

Le contrôle budgétaire se fait sur trois niveaux : un budget journalier et mensuel par projet, la console refusant les requêtes du projet au-delà du plafond avec un délai d'application d'environ dix minutes ; une ventilation par clé ou par membre pour éviter qu'une activité consomme tout le quota de l'organisation ; un rapprochement hebdomadaire par modèle et par scénario pour identifier les appels qui croissent le plus vite. Une alerte de solde ne protège que d'une coupure brutale et ne remplace pas un budget.

7. Ordre de réduction des coûts et habitudes de rapprochement

Ne inversez pas l'ordre. Commencez par le cache et la gouvernance des entrées, limitez ensuite les sorties, et seulement en dernier envisagez de changer de modèle ; sinon, vous rendez simplement les mauvaises réponses moins chères.

Figez le prompt système, les définitions d'outils et le préfixe de base de connaissances, puis vérifiez cached_tokens.
Réduisez le texte transmis à chaque appel par recherche et résumé, et faites un résumé glissant de l'historique.
Fixez max_completion_tokens, exigez du JSON ou des champs fixes, réduisez les sorties longues ouvertes.
Routez par tâche : kimi-k2.6 pour le général, la version code K2.7 pour le code, K3 pour les matériaux très longs.
Passez les requêtes longues en streaming pour réduire les reprises dues aux timeouts et coupures.
Envoyez les tâches hors ligne sur Batch API et gardez l'interface synchrone pour le temps réel.
Rapprochez chaque mois selon trois axes — projet, modèle, scénario — en enregistrant à part le taux de hit du cache, le nombre de reprises et la longueur moyenne de sortie.

Un relevé doit au minimum contenir : heure d'appel, projet, modèle, tokens d'entrée, tokens touchés par le cache, tokens d'écriture de cache, tokens de sortie, nombre de reprises et request_id. Sans ces champs, toute divergence de facture ne peut être que devinée.

Questions fréquentes

Peut-on encore appeler `moonshot-v1-8k` ?

Non. Toute la série moonshot-v1 a été retirée le 31 août 2026, et l'éditeur recommande de migrer vers kimi-k3. La migration ne se limite pas au nom : vérifiez à nouveau la longueur de contexte, les postes de facturation et les paramètres de sortie.

Pourquoi le cache ne touche-t-il pas ?

Vérifiez d'abord si le préfixe est cassé par un horodatage, un identifiant aléatoire, un tri dynamique ou un réordonnancement des outils ; confirmez ensuite que l'intervalle entre requêtes ne dépasse pas le TTL ; enfin, assurez-vous que l'écriture et la lecture du cache sont dans la même organisation et le même palier TTL. Jugez avec cached_tokens, pas à l'impression.

Le contexte long est-il toujours plus cher ?

Pas nécessairement, mais retransmettre un matériel long le devient généralement. Le coût dépend du nombre de répétitions de l'entrée, du taux de hit du cache et de la longueur de sortie. Réduisez d'abord le périmètre par recherche, puis décidez si un contexte de niveau million est nécessaire.

Les requêtes en échec sont-elles facturées ?

La documentation officielle ne promet pas la gratuité en cas d'échec. Ne supposez pas que les reprises sont sans coût : vérifiez avec les journaux et usage, et intégrez le nombre de reprises au coût par tâche.

Où consulter les prix actuels ?

Sur la page Tarifs des modèles et dans la documentation officielle Moonshot/Kimi. Prix, liste de modèles et règles de cache peuvent évoluer : ne réutilisez pas d'anciennes captures d'écran.

Pour aller plus loin

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 puis kimi-k3, en relevant entrées, sorties, hits de cache et reprises, avant de choisir le modèle principal et le budget mensuel. Les prix et modèles disponibles font foi sur la page Tarifs des modèles.