Les modèles à poids ouverts sont arrivés : plus de choix, plus de rapidité, moins de coûts
Nima Kaviani
Product
Dès le départ, nous avons conçu Kiro pour vous offrir la meilleure expérience de programmation avec l'IA possible. Cela signifiait lancer le produit avec les modèles de programmation les plus avancés et tout construire autour de la qualité des résultats. Il y a six mois, nous avons présenté Auto, notre mode agent qui combine des modèles de pointe avec des modèles spécialisés, en y ajoutant la détection d'intention, la mise en cache et d'autres techniques d'optimisation pour vous offrir un bon équilibre entre performance, efficacité et qualité des résultats. Aujourd'hui, nous ajoutons des modèles à poids ouverts à Kiro, disponibles à la fois dans l'IDE et la CLI.
Nous suivons attentivement l'évolution des modèles à poids ouverts, et les progrès sont remarquables. Des modèles qui accusaient un net retard par rapport aux options propriétaires il y a un an offrent maintenant des résultats véritablement compétitifs pour de nombreuses tâches de développement. Ils sont rapides, rentables, et ne cessent de s'améliorer. Beaucoup d'entre vous ont expérimenté ces modèles de leur propre chef et nous ont demandé de les prendre en charge directement. Nous vous avons entendus.
Les modèles à poids ouverts vous offrent plus de choix dans votre façon de travailler. Certaines tâches n'ont pas besoin du modèle le plus puissant disponible. Les itérations rapides, la génération de code répétitif et les refactorisations simples nécessitent surtout de la rapidité et un faible coût, plus que de la pure puissance de raisonnement. D'autres tâches exigent de solides capacités agentives ou une prise en charge spécialisée des langages. Disposer d'un éventail de modèles vous permet d'adapter l'outil à la tâche.
Voici ce que nous mettons à votre disposition à partir d'aujourd'hui, et où chacun excelle selon nous.
DeepSeek v3.2 (multiplicateur de crédits de 0,25x) — Construit sur une architecture Mixture-of-Experts parcimonieuse, DeepSeek v3.2 n'active que les paramètres dont il a besoin pour chaque tâche. Il excelle dans les flux de travail agentifs : appels d'outils en plusieurs étapes, maintien de l'état sur de longues sessions et chaînes de raisonnement complexes. Il est excellent pour générer du code initial, mais peut présenter des difficultés en matière de débogage complexe et de qualité de révision de code. Si vous concevez des agents ou traversez des sessions de débogage complexes, c'est un excellent choix.
MiniMax 2.1 (multiplicateur de crédits de 0,15x) — Ce modèle se distingue par sa programmation multilingue. Il offre d'excellents résultats en Rust, Java, Go, C++, Kotlin, TypeScript, JavaScript, et plus encore. Il possède également de très bonnes capacités de génération d'interface utilisateur pour le Web, Android et iOS. Les développeurs ont remarqué qu'il peut avoir de la difficulté avec les tâches de refactorisation complexes par rapport aux modèles de pointe. Si votre équipe travaille avec plusieurs langages ou fait beaucoup de travail frontend, MiniMax 2.1 vaut la peine d'être essayé.
Qwen3 Coder Next (multiplicateur de crédits de 0,05x) — Un modèle MoE parcimonieux de 80 milliards de paramètres qui n'en active que 3 milliards par jeton, Qwen3 Coder Next est conçu spécifiquement pour les agents de programmation. Il obtient un score supérieur à 70 % sur SWE-Bench Verified, prend en charge un contexte de 256 000 jetons et possède de solides capacités de détection d'erreurs, de récupération et d'appel d'outils. La communauté a noté certains défis de compatibilité et d'intégration qui nécessitent une configuration soignée pour obtenir des résultats plus constants. Si vous voulez un modèle efficace qui gère de façon fiable les longues sessions de programmation agentive, particulièrement dans la CLI, essayez Qwen3.
Tous les modèles sont désormais disponibles avec une prise en charge expérimentale dans le sélecteur de modèles de l'IDE et via la CLI de Kiro, pour les utilisateurs gratuits et payants se connectant avec Google, GitHub et AWS BuilderID. L'inférence est effectuée dans la région AWS US East (Virginie du Nord). Passez de l'un à l'autre, combinez-les avec Auto, ou définissez un modèle par défaut pour certains types de projets — selon ce qui convient le mieux à votre façon de travailler. Comme toujours, expérimentez et dites-nous comment ça fonctionne pour vous. Nous suivons attentivement quels modèles trouvent écho et quelles lacunes subsistent. S'il y a un modèle que vous aimeriez voir pris en charge prochainement, faites-le-nous savoir.