Kimi 3 API (Kimi K3) : ce que les développeurs doivent savoir

Si vous recherchez l’API Kimi 3, le nom officiel du modèle à utiliser dans le code est Kimi K3. La distinction est importante, car la documentation du modèle, les exemples SDK, les tableaux de tarification et l’identifiant du modèle API utilisent tous kimi-k3, et non kimi-3.

Au 11 septembre 2026, le propre guide Kimi K3 de Kimi présente Kimi K3 comme son modèle phare pour le codage à long horizon, le travail de connaissance de bout en bout, le raisonnement approfondi, la compréhension visuelle, la compréhension vidéo et les workflows de contexte de 1 M jetons. La plateforme API Kimi l’expose via les protocoles Chat Completions compatibles OpenAI, Responses compatibles OpenAI et Messages compatibles Anthropic, afin que les développeurs puissent évaluer Kimi K3 sans reconstruire chaque wrapper de requête depuis zéro.

Ce guide explique ce qui est actuel concernant la requête de recherche API Kimi 3, comment appeler Kimi K3 directement, ce qui a changé depuis la première couverture du lancement de K3, et comment un indie hacker peut tester Kimi K3 via une route fournisseur directe ou une passerelle multi-modèles comme Flatkey.

Kimi 3 API vs Kimi K3 API

Kimi K3 est le nom officiel. API Kimi 3 est une expression de recherche utile, car de nombreux développeurs utilisent un langage de type version lorsqu’une nouvelle génération majeure de modèle est lancée.

Utilisez les termes de cette façon :

• Dans les titres d’articles et les contenus pédagogiques, "Kimi 3 API (Kimi K3)" aide les lecteurs à faire le lien entre l’expression de recherche et le modèle officiel.
• Dans les requêtes API, utilisez kimi-k3 dans le champ model.
• Dans les tickets d’ingénierie et la documentation, privilégiez "Kimi K3" après la première clarification.

Cela évite une erreur simple mais coûteuse : copier une expression de recherche populaire dans le code et déboguer une erreur de type modèle introuvable qui n’a rien à voir avec l’accès au compte.

Faits actuels sur l’API Kimi K3

La documentation actuelle de l’API Kimi décrit Kimi K3 comme un modèle de 2,8 trillions de paramètres avec compréhension visuelle native et une fenêtre de contexte de 1 048 576 jetons. Kimi indique que les poids complets du modèle ont été publiés, ce qui remplace la formulation de la semaine de lancement selon laquelle les poids devaient être publiés d’ici le 27 juillet 2026.

Les prix, la disponibilité des routes et les limites de débit peuvent changer ; considérez donc les chiffres fixes comme un point de vérification avant le déploiement plutôt que comme un contrat permanent. Consultez la documentation de Kimi sur les tarifs et les limites de débit avant d’établir votre budget pour un déploiement en production.

Qu’est-ce qui a changé depuis la semaine de lancement ?

Si vous lisez un ancien article sur Kimi K3, revérifiez ces points avant de recopier ses conseils :

• La documentation K3 de Kimi indique désormais que les poids complets du modèle ont été publiés.
• La liste des modèles de Kimi positionne désormais kimi-k3 comme la cible de migration pour plusieurs identifiants de modèles retirés.
• Les séries kimi-k2.5 et moonshot-v1 ont été retirées le 31 août 2026, et les appels à ces modèles renvoient désormais des erreurs model-not-found, selon la liste des modèles et le journal des modifications de la plateforme de Kimi.
• La vue d’ensemble de l’API documente désormais trois surfaces de compatibilité : OpenAI Chat Completions, OpenAI Responses et Anthropic Messages.
• Le comportement des requêtes spécifique à K3 reste important : K3 raisonne toujours, plusieurs paramètres d’échantillonnage sont figés, et les URL d’images publiques ne sont pas prises en charge pour l’entrée visuelle.

Pour un hacker indie ou une petite équipe produit IA, le constat pratique est simple : si un ancien prototype utilisait un identifiant de modèle Moonshot v1 ou K2.x, ne vous contentez pas de remplacer l’URL de base en espérant que le reste fonctionne. Mettez à jour l’identifiant du modèle, supprimez les paramètres de réflexion non pris en charge, exécutez des tests de fumée et revérifiez les coûts et les limites.

Comment appeler Kimi K3 directement avec le SDK OpenAI

La configuration compatible OpenAI de Kimi utilise le SDK OpenAI avec la clé API Moonshot et l’URL de base Kimi.

import os
from openai import OpenAI

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

response = client.chat.completions.create(
    model="kimi-k3",
    reasoning_effort="low",
    messages=[
        {
            "role": "user",
            "content": "Examinez cette checklist de lancement et listez les trois lacunes les plus risquées.",
        }
    ],
)

print(response.choices[0].message.content)

Cela suffit pour un appel texte de base. Cela ne suffit pas pour une migration en production. Kimi K3 diffère des modèles génériques compatibles OpenAI de manière que votre application doit tester explicitement.

Paramètres Kimi K3 à ne pas négliger

Le paramètre K3 le plus important est reasoning_effort.

Kimi K3 a toujours la réflexion activée. Vous ne pouvez pas la désactiver, mais vous pouvez choisir le niveau d’effort de raisonnement :

• low pour des vérifications à faible latence, des brouillons, de la classification ou une exploration moins coûteuse.
• high pour les tâches de raisonnement plus difficiles lorsque la latence est acceptable.
• max pour le mode de raisonnement K3 le plus approfondi et la valeur par défaut actuelle.

La référence des paramètres Kimi indique également que temperature, top_p, n, presence_penalty et frequency_penalty sont figés pour K3. Fournir des valeurs incompatibles peut renvoyer des erreurs, donc omettez ces paramètres sauf si la documentation actuelle indique le contraire.

Pour les conversations à plusieurs tours et les appels d’outils, Kimi indique de renvoyer le message complet de l’assistant retourné par l’API, y compris les champs de raisonnement et d’appel d’outil. Si votre application existante ne stocke que message.content, corrigez cela avant de juger K3 sur les workflows d’agent.

Vision et saisie vidéo : utilisez les formats pris en charge

Kimi K3 prend en charge la compréhension visuelle, mais la forme de l’entrée est spécifique.

Pour les messages image, message.content doit être un tableau de parties, et non une chaîne JSON. La documentation vision de Kimi prend en charge le contenu d’image en base64 et les références d’identifiant de fichier. Elle ne prend actuellement pas en charge les images au format d’URL publique pour l’entrée vision.

Pour la vidéo, téléversez d’abord le fichier et référencez-le avec le format ms://<file-id> dans une partie video_url. Kimi recommande de maintenir la résolution vidéo à FHD ou en dessous et d’utiliser l’API d’estimation des jetons avant les tâches multimodales coûteuses.

Cela compte pour les équipes produit, car un fournisseur peut être « compatible OpenAI » pour le chat tout en ayant des règles spécifiques au fournisseur pour les images, la vidéo, les téléversements de fichiers, les limites et la facturation.

API Kimi directe ou route Flatkey ?

Les deux approches sont valides. Le bon choix dépend de ce que vous cherchez à apprendre.

Choisissez l’API Kimi directe lorsque :

• vous voulez le chemin le plus proche des fonctionnalités K3 spécifiques à Moonshot ;
• votre application évalue principalement Kimi K3 plutôt que de comparer de nombreux modèles ;
• vous êtes à l’aise avec la gestion d’un autre compte fournisseur, du solde, de la clé, du profil de limitation de débit et de la facture ;
• vous pouvez conserver le traitement des paramètres spécifiques à Kimi dans le code de votre application.

Choisissez une passerelle multi-modèles comme Flatkey lorsque :

• vous voulez une seule URL de base compatible OpenAI tout en comparant Kimi K3 avec GPT, Claude, Gemini, DeepSeek, Qwen, GLM, Seedance et d’autres modèles pris en charge ;
• votre application a besoin d’un routage de secours, de listes d’autorisation de modèles, de journaux d’utilisation, de contrôles de quota ou d’une facturation partagée ;
• vous voulez déplacer les identifiants spécifiques au fournisseur et la politique de routage hors du code métier ;
• vous construisez avec des agents de codage ou des tâches d’automatisation susceptibles de consommer de gros volumes de jetons sur plusieurs fournisseurs.

Le catalogue public de modèles de Flatkey liste actuellement kimi-k3 comme disponible via le type d’endpoint compatible OpenAI. L’URL de base actuelle du routeur de Flatkey pour les requêtes compatibles OpenAI est :

https://router.flatkey.ai/v1

La configuration SDK correspondante est :

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["FLATKEY_API_KEY"],
    base_url="https://router.flatkey.ai/v1",
)

response = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {
            "role": "user",
            "content": "Compare these three onboarding flows and pick the lowest-risk launch path.",
        }
    ],
)

print(response.choices[0].message.content)

Avant toute utilisation en production, confirmez que la route prend en charge tous les champs de requête spécifiques à Kimi dont votre charge de travail a besoin. La compatibilité est un raccourci d’intégration, pas un substitut à la couverture de tests.

Un workflow pratique d’évaluation de Kimi K3

Utilisez cette séquence avant de transférer de vrais utilisateurs vers la route API Kimi 3 :

1. Confirmez l'ID du modèle et l'accès. Vérifiez que kimi-k3 apparaît dans la liste des modèles du fournisseur ou du gateway actuel, et confirmez que votre compte dispose du solde requis ou de l'autorisation de routage.
2. Exécutez un test de fumée en texte brut. Commencez par une courte requête sans streaming avant d'ajouter des outils, le mode JSON, le streaming, le contexte long ou la vision.
3. Testez la charge de travail exacte. Utilisez de vraies requêtes issues de votre produit : tâches d'agent de code, analyse de documents, automatisation du support, recherche, extraction structurée ou revue multimodale.
4. Mesurez l'acceptation des sorties. Ne vous fiez pas uniquement aux affirmations des benchmarks. Suivez si les utilisateurs, les évaluateurs ou les parseurs en aval acceptent la réponse.
5. Mesurez la latence et l'utilisation de tokens. Le contexte long et le raisonnement de K3 peuvent être utiles, mais ils peuvent aussi modifier le temps réel d'exécution et la longueur de la sortie.
6. Testez le comportement des paramètres. Supprimez les paramètres d'échantillonnage fixes, définissez reasoning_effort de manière explicite, et conservez les messages assistant complets dans les sessions multi-tours.
7. Vérifiez les contraintes multimodales. Utilisez base64 ou des téléversements de fichiers pour les images et les vidéos, et estimez le coût en tokens avant les gros traitements de médias.
8. Définissez un mécanisme de repli. Choisissez des modèles de repli avec les mêmes exigences de modalité et de forme de réponse. Décidez quand réessayer, échouer de manière visible ou router ailleurs.
9. Examinez les journaux d'utilisation. Confirmez que vous pouvez voir le modèle, le statut, les tokens, les tokens mis en cache, le coût, la latence, le propriétaire et l'environnement.
10. Déployez une charge de travail à la fois. Commencez par une charge de travail limitée, puis étendez-la après que la route a démontré sa qualité, sa fiabilité et son coût.

Liste de vérification de migration Kimi K3 pour les anciennes applications Kimi

Si votre code utilise déjà d'anciens identifiants de modèles Kimi ou Moonshot, vérifiez ce qui suit :

• Remplacez les identifiants de modèles retirés tels que kimi-k2.5 ou moonshot-v1-* par kimi-k3 ou un autre modèle actuel pris en charge.
• Supprimez la configuration thinking de K2.x lors du passage à K3 ; utilisez plutôt reasoning_effort au niveau supérieur.
• Cessez de transmettre des paramètres d'échantillonnage non pris en charge.
• Conservez les messages assistant complets dans les flux multi-tours et de tool-call.
• Retestez la sortie JSON schema, le comportement du choix d'outil, le comportement du parseur de streaming et la gestion des erreurs.
• Recalculez l'économie des cache-hits et cache-misses à partir du tableau de prix actuel.
• Revérifiez les limites de débit pour votre palier de recharge actuel.
• Mettre à jour les tableaux de bord, les alertes et les runbooks afin que kimi-k3 soit visible comme son propre routeur de modèle.

Erreurs courantes avec l'API Kimi 3

Utiliser le mauvais nom de modèle

Utilisez kimi-k3, pas kimi-3. Conservez l'expression "Kimi 3 API" pour la recherche et l'explication destinée aux utilisateurs.

Considérer compatible OpenAI comme identique

Compatible OpenAI signifie que vous pouvez réutiliser une interface de requête familière. Cela ne garantit pas des paramètres de modèle, une gestion multimodale, des limites de débit, des champs d'utilisation ou un comportement de sortie identiques.

Ignorer les cache misses

La tarification de Kimi K3 distingue les entrées avec cache-hit et cache-miss. Pour les applications à contexte long, une petite différence dans la stabilité du préfixe peut modifier de manière significative le coût effectif.

Évaluer uniquement des captures d'écran de benchmarks

Les éléments de lancement de Kimi incluent des affirmations sur les benchmarks et l’architecture, mais votre décision de production doit venir de votre propre jeu d’acceptation, de votre budget de latence, de la compatibilité avec votre analyseur et du comportement de repli.

Basculer un agent de longue durée en cours de session

Le blog technique de Kimi avertit que K3 peut être sensible à l’historique de réflexion. Pour les workflows d’agent, évitez de faire passer une session active d’un autre modèle vers K3 sans réinitialiser et valider l’état de la conversation.

FAQ

Kimi 3 est-il la même chose que Kimi K3 ?

« Kimi 3 » est une expression de recherche courante. Kimi K3 est le nom officiel du modèle, et kimi-k3 est l’identifiant du modèle API que les développeurs doivent utiliser.

L’API Kimi K3 est-elle disponible maintenant ?

Oui. La liste actuelle des modèles de Kimi inclut kimi-k3, et le guide Kimi K3 documente un accès API direct via la plateforme API Kimi.

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

La documentation actuelle de Kimi indique une fenêtre de contexte de 1 048 576 jetons pour Kimi K3.

Quel est le coût de l’API Kimi K3 ?

La page actuelle de tarification de l’inférence de Kimi indique Kimi K3 à 0,30 $ par 1 M de jetons d’entrée avec cache touché, 3,00 $ par 1 M de jetons d’entrée sans cache touché, et 15,00 $ par 1 M de jetons de sortie, hors taxes applicables. Vérifiez à nouveau la page de tarification avant d’établir votre budget, car les prix des modèles peuvent changer.

Puis-je désactiver le raisonnement de Kimi K3 ?

Non. Kimi K3 raisonne toujours. Vous pouvez définir reasoning_effort sur low, high ou max.

Kimi K3 prend-il en charge les URL d’images ?

Kimi K3 prend en charge les entrées visuelles, mais la documentation visuelle actuelle de Kimi indique que les images au format URL public ne sont pas prises en charge. Utilisez plutôt du contenu d’image en base64 ou des envois de fichiers.

Puis-je appeler Kimi K3 via Flatkey ?

Le catalogue public de Flatkey répertorie actuellement kimi-k3 comme disponible via un type de point de terminaison compatible OpenAI. Utilisez Flatkey lorsque vous voulez une seule clé, une seule URL de base de routeur, une facturation partagée, une visibilité sur l’utilisation et des contrôles de routage sur plusieurs modèles pris en charge.

Concevez pour le prochain changement de modèle

La tendance de recherche autour de l’API Kimi 3 concerne en réalité un problème plus large pour les développeurs : l’accès aux modèles change plus vite que l’architecture des applications.

Kimi K3 mérite d’être évalué pour le codage à long contexte, le travail de connaissance, le raisonnement approfondi et les tâches multimodales. Mais la décision d’ingénierie durable consiste à garder le choix du fournisseur configurable, à tester explicitement le comportement spécifique au modèle et à centraliser le routage, l’utilisation, le repli et la facturation avant que les expérimentations de modèles ne se répandent dans votre base de code.

Flatkey aide à mettre en place ce modèle opérationnel en donnant aux équipes un routeur unique compatible OpenAI, une clé API, un solde et un tableau de bord uniques à travers les modèles officiels et outils pris en charge. Commencez par le guide de démarrage rapide de l’API Flatkey, puis comparez kimi-k3 aux charges de travail où le long contexte et le raisonnement de K3 peuvent réellement faire évoluer les indicateurs de votre produit.