API Kimi K3 : Pourquoi le contexte de 1M change le routage des modèles

Kimi K3 arrive avec deux chiffres taillés pour les gros titres : 2 800 milliards de paramètres et une fenêtre de contexte d'un million de tokens.

Pour une équipe de production, le chiffre le plus utile est 10.

Sur l'API officielle Kimi K3 de Moonshot, les tokens d'entrée hors cache (cache miss) coûtent dix fois plus cher que les tokens d'entrée en cache (cache hit). L'exigence la plus lourde de conséquences n'est d'ailleurs pas un chiffre : les applications multi-tours et à appels d'outils doivent conserver le message assistant complet, y compris le raisonnement et l'état des outils.

Cela fait de Kimi K3 bien plus qu'un nouvel ID de modèle. Cela transforme la disposition du contexte, la stabilité du cache, la persistance des sessions et le routage aux frontières de tâches en véritable architecture de production.

TL;DR

• Moonshot décrit Kimi K3 comme un modèle ouvert de classe 3T à 2,8T de paramètres, avec vision native et une fenêtre de contexte de 1 048 576 tokens.
• K3 était déjà disponible via les produits Kimi et l'API de Moonshot au moment de la vérification, mais la publication des poids complets était prévue d'ici le 27 juillet 2026.
• Le modèle active 16 experts sur 896 : son nombre total de paramètres n'équivaut donc pas au calcul actif par token.
• Les tarifs officiels de l'API sont de 0,30 $ pour 1M de tokens d'entrée en cache (cache hit), 3,00 $ pour 1M de tokens d'entrée hors cache (cache miss) et 15,00 $ pour 1M de tokens de sortie.
• K3 raisonne aujourd'hui toujours à max et exige que les messages assistant complets soient conservés dans les boucles multi-tours et d'appels d'outils.
• Moonshot avertit qu'un historique de réflexion manquant, ou le basculement d'une session existante vers K3, peut rendre la qualité instable.
• K3 ne figurait pas dans le catalogue en direct de Velokey au moment de la vérification de cet article. Ne devinez pas un ID de modèle ; vérifiez d'abord la disponibilité en direct.

Statut de Kimi K3 : confirmé, en attente et indisponible

Autour du lancement d'un modèle majeur, les sources ont tendance à fondre plusieurs états différents en un seul mot : publié.

Pour Kimi K3, ces états doivent rester distincts.

La page de lancement de Kimi K3 chez Moonshot le présente comme le premier modèle ouvert de la classe 3T. C'est la qualification du fournisseur. La distinction pratique actuelle est que les développeurs peuvent déjà appeler K3 via l'API de Moonshot, tandis que les équipes qui prévoient un déploiement local ont encore besoin des poids eux-mêmes, de la licence, de la fiche modèle et du rapport technique.

Si cet article est mis à jour après le 27 juillet, le statut de publication des poids devra être revérifié. Une publication planifiée et un artefact téléchargeable sous licence ne sont pas la même chose.

Ce que 2,8T de paramètres signifient en pratique

Kimi K3 combine Kimi Delta Attention, Attention Residuals et une architecture Stable LatentMoE. Moonshot indique que le modèle active 16 experts sur 896 pour une requête.

Cela change la façon dont ce chiffre phare doit être lu.

*Moonshot annonce 2,8T de paramètres au total, 16 experts sur 896 effectivement activés, une fenêtre de contexte de 1 048 576 tokens et une vision native.*

Un total de 2,8T de paramètres décrit la capacité globale du modèle. Cela ne signifie pas que chaque paramètre est actif pour chaque token. L'activation éparse d'experts est le mécanisme qui permet à un très grand modèle d'exposer davantage de capacité sans payer à chaque étape le coût de calcul complet d'un modèle dense.

Moonshot annonce également une efficacité de mise à l'échelle globale environ 2,5 fois supérieure à celle de Kimi K2. C'est un résultat d'architecture rapporté par le fournisseur, pas une mesure indépendante en production, mais il pointe vers le véritable objectif d'ingénierie : rendre un très grand modèle utilisable pour du travail à long horizon, plutôt que simplement le rendre grand.

K3 inclut aussi une compréhension visuelle native et se positionne sur le code, le travail de connaissance, le raisonnement, les images et la vidéo. Ces capacités élargissent l'éventail des charges de travail API possibles, mais elles ne disent pas à une équipe lesquelles seront économiques.

Cette réponse vient du contexte, de la sortie, de la latence et du comportement des outils.

Pourquoi une fenêtre de 1M de tokens ne supprime pas l'ingénierie de contexte

La page officielle des tarifs de Kimi indique une fenêtre de contexte de 1 048 576 tokens.

C'est une grande capacité. Ce n'est pas une consigne de remplir chaque requête.

Un agent de codage ou de recherche de longue durée peut accumuler :

• des instructions système
• des règles de permission et de sécurité
• des définitions d'outils
• des fichiers de dépôt et des documents
• des éléments de preuve récupérés
• des messages utilisateur
• du raisonnement de l'assistant
• des appels d'outils et leurs résultats
• des reprises, des corrections et des branches abandonnées

Le contexte peut tenir alors même que la tâche devient plus lente, plus coûteuse et plus difficile à contrôler.

Le long contexte déplace la question principale de « Est-ce que ça tient ? » vers « Qu'est-ce qui mérite de rester actif ? »

Une session de production devrait séparer quatre couches :

1. Préfixe stable : instructions durables, connaissances fixes et définitions d'outils fréquemment réutilisées.
2. Ensemble de travail de la tâche : les fichiers, preuves, images et outils nécessaires à l'objectif en cours.
3. État de session complet : les messages requis pour préserver la continuité du raisonnement et des outils.
4. Points de contrôle redémarrables : des résumés vérifiés qui permettent à une tâche de repartir sans traîner indéfiniment chaque branche échouée.

*Le long contexte est opérationnellement utile lorsque les instructions stables, l'ensemble de travail actif, l'état de session complet et les points de contrôle de redémarrage sont gérés séparément.*

La fenêtre d'un million de tokens donne aux équipes plus de marge. Elle ne remplace pas la récupération, la compaction, les points de contrôle ni les budgets de tokens.

Comment les tarifs de Kimi K3 changent l'architecture des prompts

Les tarifs officiels de K3 chez Moonshot sont :

• Entrée en cache (cache hit) : 0,30 $ pour 1M de tokens
• Entrée hors cache (cache miss) : 3,00 $ pour 1M de tokens
• Sortie : 15,00 $ pour 1M de tokens

Les prix s'entendent hors taxes applicables et peuvent changer. Vérifiez la page officielle en ligne avant tout achat.

Le modèle de coût de base est :

input cost = cache-hit MTok x $0.30 + cache-miss MTok x $3.00
output cost = output MTok x $15.00

*Les tarifs vérifiés le 17 juillet 2026 montrent un écart de 10× entre les taux d'entrée en cache et hors cache, ce qui fait de la stabilité du préfixe un mécanisme de contrôle des coûts. Il s'agit des tarifs officiels de l'API Kimi, pas des tarifs Velokey ; les prix peuvent changer.*

L'écart de un à dix sur le prix d'entrée fait de la structure du prompt une composante de l'architecture des coûts.

Le cache de contexte de Kimi est automatique. Il n'y a ni ID de cache manuel ni TTL à gérer. L'API tente de réutiliser le contexte initial répété, comme les prompts système, les documents de connaissances et les définitions d'outils.

Automatique ne veut pas dire garanti.

Si une application modifie le début du prompt à chaque appel, réordonne les outils, injecte des horodatages dans le préfixe ou sérialise les mêmes connaissances dans un ordre différent, elle peut transformer un contexte réutilisable en cache miss.

Moonshot indique que l'API officielle a atteint des taux de cache hit supérieurs à 90 % sur des charges de travail de codage. Considérez cela comme un résultat rapporté par le fournisseur, pas comme une promesse pour une application différente. Le chiffre auquel une équipe de production doit se fier est celui mesuré sur son propre trafic.

Suivez au minimum :

• les tokens d'entrée en cache (cache hit)
• les tokens d'entrée hors cache (cache miss)
• les tokens de sortie du raisonnement et de la réponse finale
• le temps jusqu'au premier token
• la latence totale de réponse
• le nombre d'appels d'outils
• le taux de reprises
• le coût par tâche accomplie

La tarification par requête ne suffit pas pour un agent. Un seul objectif utilisateur peut déclencher des dizaines d'appels de modèle, d'appels d'outils, de reprises et d'étapes de vérification.

Pourquoi le raisonnement conservé change le routage des modèles

Kimi K3 raisonne en permanence. L'API ne prend actuellement en charge que reasoning_effort="max", et une réponse peut contenir reasoning_content en plus de son content final.

Pour les conversations multi-tours et les appels d'outils, la documentation de Kimi précise que le message assistant complet doit être ajouté à la requête suivante. Les développeurs ne doivent pas conserver uniquement la réponse visible. Le message retourné peut aussi contenir des champs de raisonnement et d'appels d'outils nécessaires à la continuité.

Cela affecte à la fois le coût et le routage.

Le raisonnement passé continue d'occuper la fenêtre de contexte et contribue à la consommation de tokens. Une longue session d'agent grossit donc bien au-delà des seuls messages utilisateur et documents.

Cela signifie aussi qu'on ne peut pas, sans risque, traiter la sélection du modèle comme une opération sans état.

Moonshot avertit que la qualité de K3 peut devenir très instable lorsqu'un harnais ne renvoie pas l'historique de réflexion complet, ou lorsqu'une session en cours avec un autre modèle est basculée vers K3.

La règle de production la plus sûre est simple :

> Routez à la frontière de la tâche ou de la session, puis épinglez le modèle sélectionné jusqu'à un point de contrôle délibéré.

Si un modèle ou un fournisseur échoue au milieu d'une tâche, créez un paquet de redémarrage contenant les faits vérifiés, les actions accomplies, les fichiers courants, les décisions ouvertes et les objectifs restants. Faites démarrer le modèle de remplacement depuis cet état explicite au lieu de changer silencieusement l'ID de modèle au sein de la même boucle d'outils.

*Sélectionnez le modèle à une frontière de tâche, épinglez-le tout au long de la boucle d'outils, et ne changez de modèle qu'après un point de contrôle délibéré ou dans une nouvelle session. C'est une recommandation de production, pas une architecture de routage officielle de Kimi.*

C'est la différence entre le routage par requête et le routage par session.

Où Kimi K3 s'inscrit dans une pile multi-modèles

Le mode de raisonnement maximal de K3 rend la séparation des charges de travail importante dès le premier jour.

Moonshot cite la proactivité excessive comme limitation actuelle. K3 peut prendre des décisions inattendues lorsqu'une longue tâche rencontre une ambiguïté ou un obstacle mineur.

Cela rend la conception des permissions aussi importante que la conception des prompts :

• séparez l'accès en lecture de l'accès en écriture
• gardez les clés API et les identifiants de production côté serveur
• exigez une approbation pour les actions destructives ou externes
• définissez des conditions d'arrêt explicites
• journalisez chaque action d'outil demandée et son résultat
• évaluez le comportement de récupération, pas seulement les exécutions réussies

Le modèle le plus capable ne devrait pas recevoir automatiquement les permissions les plus larges.

API Kimi K3 vs auto-hébergement

La publication open-weight prévue fait entrer le déploiement local dans la discussion. Elle n'en fait pas le vainqueur automatique.

Moonshot indique que K3 utilise un entraînement conscient de la quantification avec des poids MXFP4 et des activations MXFP8. L'entreprise recommande des configurations en supernœuds avec 64 accélérateurs ou plus pour le déploiement.

C'est une recommandation, pas un minimum strict publié, mais elle suffit à montrer que servir K3 à pleine échelle est un projet d'infrastructure à l'échelle du cluster.

L'accès API managé est le premier chemin pratique lorsque :

• le trafic est naissant ou variable
• l'équipe veut valider la qualité avant d'acheter de l'infrastructure
• la vitesse de déploiement compte
• l'équipe ne peut pas exploiter une grande pile d'inférence distribuée
• le produit doit comparer K3 à plusieurs autres modèles

L'auto-hébergement devient plus plausible lorsque :

• la licence finale autorise l'usage prévu
• des exigences de souveraineté des données imposent un contrôle local
• la charge est suffisamment soutenue pour justifier une capacité dédiée
• l'organisation exploite déjà une infrastructure de grands modèles
• l'équipe peut gérer l'utilisation, le batching, le cache, les mises à niveau et la reprise après incident

Les poids ouverts ne rendent pas gratuits le matériel, le réseau, la capacité inutilisée, l'observabilité ni le temps d'ingénierie.

L'ordre le plus sûr est l'évaluation via l'API d'abord, l'engagement d'infrastructure ensuite.

Une checklist de production pour les agents Kimi K3

Avant d'envoyer du trafic de production vers K3, répondez à ces questions.

Adéquation de la charge de travail

• La tâche a-t-elle besoin de raisonnement à long horizon, de grand contexte, de vision ou d'outils complexes ?
• Le résultat a-t-il assez de valeur pour justifier le raisonnement maximal et le coût des tokens de sortie ?
• Un modèle moins cher pourrait-il gérer la première passe de classification, d'extraction ou de réécriture ?

Conception de session

• Le modèle est-il épinglé pour toute la durée de la tâche ?
• Le message assistant complet est-il stocké et rejoué ?
• Le workflow peut-il redémarrer depuis un point de contrôle après un échec ?
• Les définitions d'outils sont-elles chargées uniquement quand c'est nécessaire ?

Coût et latence

• Quel pourcentage des tokens d'entrée sont des cache hits ?
• À quelle vitesse l'historique de raisonnement grossit-il ?
• Quels sont le temps jusqu'au premier token et la durée totale de la tâche ?
• Quelle part de la dépense provient des reprises et des appels d'outils échoués ?
• Quel est le coût par résultat accepté, et pas seulement par requête ?

Sécurité et exploitation

• Quelles actions nécessitent une approbation humaine ?
• Les identifiants sont-ils stockés uniquement sur le serveur ?
• Les actions destructives sont-elles bloquées par défaut ?
• Les appels d'outils, les erreurs, l'usage de tokens, la latence et la dépense sont-ils observables ?

Évaluation

• K3 surpasse-t-il une base de référence solide sur la charge de travail réelle ?
• Surpasse-t-il suffisamment une base de référence moins chère pour justifier le coût ?
• Que se passe-t-il quand la tâche est redémarrée sur un autre modèle ?
• À quelle fréquence le modèle a-t-il besoin d'une correction humaine ?

Le résultat de l'évaluation devrait être une frontière qualité-coût-latence, pas un score de benchmark unique.

Comment préparer un client compatible OpenAI sans inventer d'ID de modèle

Kimi K3 ne figurait pas dans le catalogue en direct de Velokey au moment de la vérification de cet article. La disponibilité peut changer : consultez le catalogue de modèles en direct et interrogez le endpoint des modèles avant d'écrire du code d'intégration.

Ne devinez pas un ID de modèle à partir d'un article de blog.

L'exemple suivant liste les ID de modèles actuellement disponibles pour un compte Velokey. Il ne suppose pas que K3 est présent.

import os

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["VELOKEY_API_KEY"],
    base_url="https://api.velokey.ai/v1",
)

for model in client.models.list().data:
    print(model.id)

Gardez la clé API dans une variable d'environnement côté serveur. Si un ID de modèle Kimi K3 n'apparaît pas dans GET /v1/models, c'est qu'il n'est pas encore disponible pour ce compte via Velokey. Continuez à utiliser un modèle dont la disponibilité est vérifiée, ou l'API officielle Kimi, plutôt que de coder en dur un ID non listé.

Une fois qu'un nouveau modèle devient disponible, un client compatible OpenAI réduit le travail de migration. L'application a toujours besoin d'une évaluation propre au modèle, de règles de session et de télémétrie. La compatibilité d'interface n'efface pas les différences de comportement.

Quand Kimi K3 vaut la dépense

Kimi K3 est le plus convaincant lorsqu'une tâche est coûteuse pour un humain, difficile à découper et assez précieuse pour justifier une longue trace de raisonnement : un grand refactoring, un travail de recherche multi-outils, un workflow d'ingénierie multimodal ou un ensemble de documents complexe qui exige une synthèse soutenue.

Il est moins convaincant comme défaut universel. La classification, l'extraction, l'étiquetage, la réécriture simple et le support de routine sont les domaines où une pile multi-modèles doit protéger le budget.

La décision de production ne devrait pas découler du seul chiffre de 2,8T. Elle devrait venir du taux de cache hit, du coût par tâche accomplie, de la stabilité des sessions, du succès des outils, de la latence, du comportement de récupération et de la correction humaine.

Voilà la vraie histoire de l'API Kimi K3. Le modèle est grand, mais c'est l'architecture de session qui l'entoure qui décide de son utilité.

FAQ sur l'API Kimi K3

Kimi K3 est-il désormais entièrement open source ?

Au 17 juillet 2026, Moonshot indiquait que les poids complets du modèle seraient publiés d'ici le 27 juillet. K3 était déjà disponible via les produits Kimi et l'API officielle. Vérifiez le dépôt, la licence, la fiche modèle et le rapport technique avant de le décrire comme téléchargeable dans un article ultérieur.

Quelle est la fenêtre de contexte de Kimi K3 ?

Moonshot annonce 1 048 576 tokens. La grande fenêtre augmente la capacité, mais ne supprime pas le besoin de récupération, de cache, de contrôle de l'historique et de points de contrôle.

Quel est le tarif officiel de l'API Kimi K3 ?

Moonshot affiche 0,30 $ pour 1M de tokens d'entrée en cache (cache hit), 3,00 $ pour 1M de tokens d'entrée hors cache (cache miss) et 15,00 $ pour 1M de tokens de sortie, hors taxes applicables.

Kimi K3 utilise-t-il l'ensemble de ses 2,8T de paramètres sur chaque token ?

Non. Moonshot indique que l'architecture Stable LatentMoE active 16 experts sur 896. Le nombre total de paramètres décrit la capacité, tandis que l'activation éparse limite le calcul actif.

Puis-je changer de modèle au milieu d'une session Kimi K3 ?

Faites-le avec prudence. Moonshot avertit qu'un historique de réflexion incomplet, ou le basculement vers K3 d'une session en cours avec un autre modèle, peut rendre la génération instable. Routez à une frontière de session ou redémarrez depuis un point de contrôle vérifié.

Kimi K3 est-il disponible via Velokey ?

Il n'était pas listé lors de la vérification de cet article le 17 juillet 2026. Utilisez le catalogue de modèles en direct et GET /v1/models pour connaître la disponibilité actuelle au niveau du compte. Ne vous fiez pas à une affirmation statique de blog.

Sources

• Lancement et limitations de Kimi K3
• Démarrage rapide de l'API Kimi K3
• Tarifs officiels de Kimi K3
• Cache de contexte de l'API Kimi
• Effort de réflexion de Kimi K3

Divulgation : Velokey publie cet article et fournit une couche d'accès API compatible OpenAI pour des modèles de plusieurs fournisseurs. Kimi K3 ne figurait pas dans le catalogue en direct de Velokey au moment de la relecture.

Vous voulez préparer un seul client pour les options de modèles actuelles et futures sans inventer d'ID ? Suivez le [démarrage rapide Velokey](https://docs.velokey.ai/quickstart), puis sélectionnez uniquement un modèle renvoyé par GET /v1/models.