Modèles et plateformes d’IA
AWS rend Kimi K3.1 Pro Highspeed disponible sur Amazon Bedrock

Amazon Web Services a rendu Kimi K3.1 Pro Highspeed de Moonshot AI disponible sur Amazon Bedrock le 10 novembre 2026, avec une fenêtre de contexte de 1 million de jetons accessible via des profils d’inférence mondiaux, américains et indiens. Moonshot AI indique que la variante Highspeed génère des réponses deux à trois fois plus rapidement que K3.1 Pro.
Le modèle sous-jacent a été lancé le 4 novembre 2026, avant son déploiement sur Bedrock. K3.1 Pro est une version de Kimi K3 ayant fait l’objet d’un post-entraînement. Elle conserve l’architecture à poids ouverts de classe 3T et la fenêtre de contexte du modèle, tout en ayant bénéficié de ressources de calcul nettement plus importantes pour le post-entraînement. Moonshot AI indique que cet entraînement supplémentaire vise à améliorer les tâches agentiques de longue durée et à réduire les erreurs factuelles, ainsi qu’à progresser dans la modélisation financière, les documents bureautiques et le codage pour les moteurs de jeu, les scènes 3D et les scripts de conception assistée par ordinateur.
En programmation agentique, une seule tâche peut nécessiter de nombreux appels successifs au modèle : lire des fichiers, planifier une modification, modifier le code, lancer des tests et corriger les erreurs. Un débit plus élevé de jetons en sortie peut réduire le temps de génération de chaque étape. Les implémentations existantes de Kimi K3 sur Bedrock peuvent passer au nouveau modèle en modifiant l’identifiant du modèle. Celui-ci prend en charge les appels d’outils, les sorties structurées, le réglage du niveau de raisonnement, les entrées d’images et la diffusion en continu via le même point de terminaison et les mêmes API. AWS présente également OpenCode, un agent de programmation en ligne de commande à code source ouvert, connecté au moyen de Chat Completions et d’une clé d’API Bedrock.
Accès et résidence des données
Les développeurs peuvent appeler le modèle au moyen des API Chat Completions et Responses, compatibles avec OpenAI, ou des API Converse et Invoke de Bedrock. AWS recommande Chat Completions. Le profil d’inférence mondial interrégional achemine les requêtes vers n’importe quelle région AWS commerciale prise en charge, tandis que les profils américain et indien limitent le routage à leurs zones géographiques respectives pour répondre aux exigences de résidence des données. Les requêtes en Inde sont acheminées entre Mumbai et Hyderabad.
AWS indique que les données d’inférence restent dans le périmètre de sécurité des données AWS, ne sont pas communiquées à Moonshot AI et ne sont pas utilisées pour entraîner le modèle. La conservation nulle des données est toujours activée pour les requêtes d’inférence, et les opérateurs AWS ne peuvent pas consulter les requêtes ni les réponses pendant l’inférence.
Tarifs et maîtrise des coûts
Les tarifs du niveau Standard dépendent du profil de routage. Tous les prix ci-dessous sont calculés par million de jetons :
| Profil d’inférence | Entrée | Sortie | Lecture du cache | Écriture dans le cache (30 minutes) |
|---|---|---|---|---|
| Mondial interrégional | $4.00 | $20.00 | $0.20 | $5.00 |
| États-Unis, interrégional | $4.40 | $22.00 | $0.22 | $5.50 |
| Inde, interrégional | $4.40 | $22.00 | $0.22 | $5.50 |
Sur la page des tarifs de Bedrock, Kimi K3, le modèle précédent, est affiché au tarif de 3,00 $ par million de jetons en entrée et de 15,00 $ par million de jetons en sortie pour l’inférence Global Standard. Le nouveau modèle affiche donc des tarifs plus élevés en entrée comme en sortie, bien que son tarif mondial de lecture du cache soit inférieur à celui de K3, qui est de 0,30 $ par million de jetons.
Le niveau Flex propose une inférence à la moitié du tarif Standard, au prix de délais de réponse potentiellement plus longs, tandis que le niveau Priority entraîne un supplément de 75 %. Le niveau peut être choisi pour chaque requête : une application peut ainsi utiliser Standard pour le trafic ordinaire, Priority pour les appels où la latence est critique et Flex pour les évaluations, la synthèse ou les tâches agentiques en arrière-plan.
La mise en cache explicite des invites permet de gérer les contextes réutilisés, comme les instructions système, les définitions d’outils et les conventions d’un dépôt de code. Chaque point de rupture doit suivre au moins 256 jetons de contenu stable. La fonctionnalité est compatible avec Responses, Chat Completions et Invoke, mais pas avec Converse. Les lectures du cache bénéficient d’un tarif réduit et ne sont pas comptabilisées dans le quota de jetons d’entrée par minute, tandis que les écritures coûtent plus cher que les entrées standard.
Limites liées au raisonnement et à la compatibilité
La fiche du modèle propose les niveaux de raisonnement none, low, medium, high, xhigh et max, ce dernier étant activé par défaut. Le réglage none désactive le raisonnement pour une requête. Un niveau d’effort inférieur peut réduire la latence et la consommation de jetons, au prix d’une baisse des performances pour certaines tâches ; le réglage par défaut est donc un facteur important pour les charges de travail sensibles aux coûts.
Converse présente d’autres contraintes, en plus de l’absence de mise en cache explicite. Une erreur interne du serveur peut survenir lorsque le contenu de raisonnement des tours précédents est inclus dans une requête à plusieurs tours, ce qui affecte des frameworks comme LangChain et Strands Agents dans leur configuration par défaut. Pour les requêtes Converse à plusieurs tours, AWS recommande de supprimer les blocs de raisonnement précédents. Converse refuse également les documents PDF et HTML joints, et Bedrock ne prend pas en charge les entrées vidéo pour ce modèle.
Chaque jeton de sortie consomme également 10 jetons du quota de compte applicable sur le point de terminaison bedrock-runtime ; il s’agit d’un facteur de capacité distinct de la facturation par jeton.
Pour les utilisateurs actuels de K3, le passage au nouveau modèle ne nécessite que peu de modifications du code, mais les compromis d’exploitation dépassent les questions de compatibilité. Le gain potentiel est une exécution plus rapide des tâches agentiques séquentielles ; en contrepartie, les tarifs en entrée et en sortie sont plus élevés, le raisonnement augmente la consommation de jetons et le quota est également sollicité. Flex, la mise en cache et les réglages du niveau d’effort sont les moyens proposés par AWS pour équilibrer ces facteurs.












