Kimi K3.1 Pro Highspeed arrive sur Amazon Bedrock : des tokens 2 à 3 fois plus rapides

Si vous développez un agent de code, vous le savez : le principal problème n'est pas le prix du token, mais l'attente. L'agent lit des fichiers, planifie une modification, écrit du code, lance les tests, corrige ce qui a cassé, et chaque étape attend la fin de la précédente. La vitesse de génération compte donc davantage qu'un joli chiffre dans un benchmark. C'est précisément sur ce terrain que se place la nouvelle version disponible sur Amazon Bedrock : Kimi K3.1 Pro Highspeed, signée Moonshot AI.

Quel est ce modèle ?

Kimi K3.1 Pro Highspeed fait partie de la nouvelle série K3.1. C'est une version post-entraînée de Kimi K3 : même architecture à poids ouverts d'environ 3 000 milliards de paramètres, même fenêtre de contexte d'un million de tokens, mais avec un volume de post-entraînement nettement supérieur. Selon Moonshot AI, ce post-entraînement cible les tâches agentiques longues et la réduction du nombre d'erreurs factuelles. L'entreprise promet aussi de meilleurs résultats dans des scénarios professionnels comme la modélisation financière et les documents bureautiques, ainsi que pour le code destiné aux moteurs de jeu, aux scènes 3D et aux scripts CAO.

Le point clé du suffixe Highspeed : d'après Moonshot AI, le modèle produit ses tokens de sortie 2 à 3 fois plus vite que K3.1 Pro. Il s'agit d'une déclaration du fournisseur ; l'article ne s'appuie sur aucune mesure indépendante. Testez donc vos propres tâches avant de basculer votre production.

Le modèle prend en charge l'appel d'outils, la sortie structurée, le raisonnement paramétrable, les images en entrée et le streaming. Côté sécurité, AWS assure que les données sont traitées à l'intérieur de son périmètre, ne sont pas transmises à Moonshot AI et ne servent pas à l'entraînement. Pour les requêtes d'inférence, la rétention zéro est toujours activée, et les opérateurs d'AWS ne voient ni vos prompts ni les réponses.

Comment se connecter : presque rien à changer

Le modèle est accessible sur l'endpoint bedrock-runtime via les API Chat Completions et Responses compatibles OpenAI, ainsi que via Converse et Invoke. AWS recommande Chat Completions. Si votre application tourne déjà avec le SDK OpenAI, il suffit de la pointer vers l'endpoint Bedrock et de changer le nom du modèle. Pour ceux qui utilisent Kimi K3 sur Bedrock, même cela n'est pas nécessaire : l'endpoint, l'API et les fonctions restent identiques, seul l'ID du modèle change.

L'accès passe par des profils d'inférence inter-régions :

• global.moonshotai.kimi-k3.1 : routage vers n'importe quelle région commerciale prise en charge, moins cher par token, adapté à la plupart des tâches ;
• us.moonshotai.kimi-k3.1 : traitement uniquement dans les régions des États-Unis ;
• in.moonshotai.kimi-k3.1 : traitement uniquement dans les régions d'Inde, pour répondre à des exigences de localisation des données.

Si vous n'avez pas d'exigence stricte de résidence des données, choisissez global.

Un point à noter : le modèle raisonne toujours avant de répondre. La profondeur se règle avec le paramètre reasoning_effort (reasoning.effort dans l'API Responses), qui accepte les valeurs low, high ou max. Si vous ne le précisez pas, c'est max qui s'applique. Pour les requêtes simples, cela ajoute des tokens et de la latence inutiles : définir explicitement low est donc le moyen le plus direct d'accélérer la réponse et de réduire la facture.

Où économiser : Flex et cache explicite

Le tarif Flex propose le modèle à la moitié du prix de Standard, mais le temps de réponse peut être plus long. Il convient à l'évaluation de modèles, à la synthèse de texte et aux tâches de fond au sein de chaînes agentiques. Le tarif se choisit requête par requête : les requêtes sensibles à la latence peuvent passer par Priority, le trafic ordinaire par Standard, et tout le reste par Flex. Le quota, lui, est commun. AWS conseille de commencer avec une petite part du trafic sur Flex, de comparer latence et coût, et de consulter la répartition par tarif dans CloudWatch.

Second levier : le prompt caching explicite. Les agents et assistants renvoient à chaque tour le même long préfixe : instructions système, descriptions des outils, règles du dépôt. Le modèle met en cache automatiquement les préfixes répétés, et les breakpoints explicites permettent d'indiquer où s'arrête la partie stable pour augmenter le taux de succès du cache. Voici les règles :

• fonctionne avec Chat Completions, Responses et Invoke, mais pas avec Converse ;
• le breakpoint doit se situer après au moins 256 tokens de contenu stable ;
• le cache est conservé au moins 30 minutes ;
• l'écriture dans le cache est facturée plus cher qu'une entrée ordinaire ; la lecture coûte moins cher et n'est pas comptée dans le quota de tokens d'entrée par minute.

Vérifier qu'un appel a bien touché le cache est simple : le champ cached_tokens dans usage doit être supérieur à zéro.

Ce qu'il faut en retenir

L'article montre comment connecter le modèle à OpenCode, un agent de code open source en terminal, non lié à un modèle unique. Il faut déclarer un fournisseur compatible OpenAI basé sur Chat Completions, ainsi qu'une clé d'API Bedrock. Les clés à court terme sont valables jusqu'à 12 heures, ne fonctionnent que dans la région où elles ont été créées et sont recommandées pour la production ; les clés à long terme sont destinées aux expérimentations. Dans OpenCode, les niveaux de raisonnement low, high et max apparaîtront comme des variantes du modèle.

Concrètement, que faire ? Pour les développeurs d'agents : changer l'ID sur un environnement de test, mesurer la durée du cycle complet « modification, test, correction » et la comparer à celle de la K3.1 Pro classique. Pour les product managers : répartir le trafic par tarif afin que les tâches de fond passent par Flex. Pour tous : ne pas laisser reasoning_effort à sa valeur par défaut là où low suffit.

Les limites sont évidentes. L'accélération de 2 à 3 fois et la réduction des erreurs sont des affirmations de Moonshot AI, pas le résultat d'une vérification indépendante. L'article ne donne pas les prix : il faudra les consulter sur la page de tarification de Bedrock. Le cache ne fonctionne pas via Converse ; pour passer au cache explicite, il faudra donc changer d'API.