Amazon Bedrock s’ouvre à Kimi K3 et à un runtime d’agents plus sobre

Amazon Web Services a mis en ligne, le 18 septembre 2026, deux nouveautés distinctes sur Amazon Bedrock : Kimi K3, un modèle open-weight de Moonshot AI, et une version remaniée d’AgentCore runtime pour exécuter des agents. Le premier élargit le catalogue de modèles disponibles pour le code et la connaissance ; le second promet moins de mémoire immobilisée et des démarrages plus constants. Ensemble, ils montrent comment AWS tente de rendre l’IA plus exploitable à grande échelle, sans faire exploser ni les temps de réponse ni la facture.

Bedrock muscle son catalogue avec Kimi K3

Kimi K3, présenté par Moonshot AI comme son modèle le plus capable, arrive sur Amazon Bedrock avec un positionnement clair : servir les tâches de codage et de connaissance, avec une fenêtre de contexte d’un million de tokens et des capacités natives de vision. Moonshot AI le décrit aussi comme le premier modèle ouvert à atteindre 2,8 trillions de paramètres [à vérifier], tout en revendiquant un gain d’efficacité d’environ 2,5x par rapport à Kimi K2. AWS l’ajoute à une liste qui comprend déjà Kimi K2.5 et Kimi K2 Thinking.

Le modèle s’appuie sur deux briques architecturales mises en avant par Moonshot AI, Kimi Delta Attention et Attention Residuals, ainsi que sur une conception mixture-of-experts baptisée Stable LatentMoE. Concrètement, seuls 16 experts sur 896 seraient activés à l’exécution, ce qui vise à limiter le coût de calcul. AWS souligne aussi un point très pratique pour les équipes produits : Kimi K3 est le premier modèle open-weight du service à prendre en charge le prompt caching explicite, utile quand un agent renvoie sans cesse le même contexte de base. En clair, on cesse de repayer la préface à chaque chapitre.

Ce que change l’accès sur Bedrock

Le modèle est accessible dans la console Amazon Bedrock, via les API Invoke et Converse, mais aussi à travers les Responses et Chat Completions APIs compatibles OpenAI. Pour les déploiements sans contrainte géographique, AWS recommande le profil global global.moonshotai.kimi-k3, annoncé comme environ 10 % moins cher qu’un profil géographique. Le profil US us.moonshotai.kimi-k3 reste destiné aux besoins de résidence des données aux États-Unis.

AWS rappelle par ailleurs que les données clients sont traitées dans le périmètre AWS, ne sont pas partagées avec le fournisseur du modèle et ne servent pas à entraîner le modèle sous-jacent. La rétention zéro est activée pour l’inférence, tandis que l’accès opérateur zéro empêche les opérateurs AWS de consulter prompts et complétions pendant l’exécution. C’est le genre de détail qui compte davantage pour les DSI que pour les slogans.

AgentCore runtime corrige deux vieux défauts des agents

En parallèle, AWS a annoncé une nouvelle version d’AgentCore runtime, la couche de calcul managée de Bedrock AgentCore. Elle cible deux irritants bien connus des équipes qui déploient des agents en production : la mémoire gardée trop longtemps et les démarrages à froid trop variables. Dans sa première version, le runtime conservait la mémoire allouée jusqu’à la fin de la session. La nouvelle mouture la récupère quand l’agent libère ses buffers ou quand les données mises en cache expirent entre deux requêtes.

Le changement vise surtout les agents longs ou irréguliers, ceux qui consomment beaucoup au pic puis restent calmes le reste du temps. AWS dit avoir analysé des milliards de sessions pour ajuster ce comportement. Le runtime commence avec un petit profil mémoire, puis charge le reste à la demande. Résultat attendu : moins de mémoire immobilisée, donc une facturation plus proche de l’usage réel.

Des démarrages plus stables, image par image

Sur le front des cold starts, AWS affirme avoir changé la logique de départ. Lorsqu’un runtime est créé ou mis à jour, le conteneur démarre une fois, passe le contrôle de santé, puis un snapshot est capturé. Les instances suivantes restaurent ce snapshot au lieu de repartir de zéro. La conséquence est importante : la latence de restauration resterait à peu près stable, quelle que soit la taille de l’image du conteneur, parce que les caches et la mémoire transitoire sont retirés du snapshot.

Pour mesurer l’effet, AWS a testé un agent “écho” vide, qui renvoie simplement l’entrée sans appeler de modèle ni d’outil. Dans ce test, le nouveau runtime affiche un P75 d’environ 2 secondes pour des images de 200 MB à 2 GB, contre environ 5,4 secondes à près de 30 secondes pour l’ancienne version, selon la taille de l’image. La partie code de l’agent ne prend qu’environ 34 millisecondes au P75 ; le reste vient donc du démarrage de la plateforme.

Une meilleure facture, mais pas sans contreparties

AWS présente ce nouveau modèle de mémoire comme un système où la facture baisse pour la plupart des agents : la plateforme facture la mémoire réellement utilisée, plutôt que la capacité entière maintenue pendant toute la session. Les sessions restent isolées dans des microVM dédiées, avec CPU, mémoire et système de fichiers séparés, pendant un maximum de 8 heures. Elles s’arrêtent après 15 minutes d’inactivité et sont ensuite nettoyées. L’approche reste assez classique côté cloud, mais elle colle mieux aux usages agentiques, souvent intermittents et gourmands en contexte.

Le revers, c’est que le passage à V2 n’est pas instantané. Une création ou une mise à jour prend plusieurs minutes, le temps de préparer et de capturer le snapshot, contre quelques secondes en V1. La nouvelle version est disponible dans plusieurs régions, dont us-east-1, us-east-2, us-west-2, eu-west-1 et ap-northeast-1. AWS précise aussi que CloudFormation et le CDK ne prennent pas encore en charge le paramètre platformVersion. Bref, l’optimisation a son petit supplément de patience.