Intelligence artificielle

Comment JetBrains a amélioré l’exécution locale de Qwen3.6 au sein de l’agent Junie

JetBrains explique les modifications apportées à Junie et au moteur d’inférence pour exécuter localement Qwen3.6-27B sur des MacBook équipés d’une puce M5. L’expérience montre que les performances des agents de programmation locaux dépendent autant de la gestion du contexte et de l’étape de préremplissage que de la vitesse de génération des tokens.

2026-08-24
9 min de lecture
10 vues
فريق تحرير certi.news
Comment JetBrains a amélioré l’exécution locale de Qwen3.6 au sein de l’agent Junie

JetBrains a révélé des détails techniques sur l’exécution locale de la première version de Junie Local sur un MacBook M5 utilisant le modèle Qwen3.6-27B, en expliquant que l’obtention de performances pratiques ne résultait pas uniquement du choix d’un modèle compressé, mais nécessitait des modifications de l’agent de programmation lui-même, du moteur d’inférence, des paramètres du modèle et de la méthode de gestion du contexte.

L’entreprise indique que le projet visant à faire fonctionner entièrement Junie sur l’appareil, sans inférence cloud, est un projet à long terme ciblant un large éventail de configurations matérielles. La première version actuellement disponible se concentre sur les MacBook M5, ce qui explique l’accent mis par les améliorations annoncées sur les caractéristiques de ces puces.

Maintenir le contexte des tâches au sein de la session

Junie fonctionne, comme les autres agents de programmation, au moyen d’une boucle d’exécution dans laquelle l’utilisateur envoie une tâche au modèle, puis le modèle exécute des appels d’outils tels que des commandes Bash ainsi que la lecture et l’écriture de fichiers, avant de renvoyer les résultats de ces opérations au modèle. À chaque nouvelle requête, le contexte s’étend, et les données de KV-cache traitées par le modèle lors de la requête précédente peuvent être réutilisées.

Dans les modèles cloud, l’agent peut demander à nouveau un fichier lorsque cela est nécessaire, car l’étape de préremplissage, c’est-à-dire le traitement du contexte initial avant la génération de la réponse, est relativement rapide. Mais JetBrains a constaté que la lecture des fichiers était coûteuse en temps dans les modèles locaux. Elle a donc modifié la logique d’inférence locale afin que chaque nouvelle requête soit ajoutée directement au contexte en cours, au lieu de se limiter aux parties jugées pertinentes pour la nouvelle tâche. Ainsi, le fichier lu par le modèle reste dans le contexte, et la mémoire KV-cache peut être réutilisée au lieu d’être retraitée.

L’entreprise a également modifié l’ordre des données envoyées par Junie au début d’une nouvelle session de codage et ajouté au moteur d’inférence une logique permettant de mettre en cache le préfixe jusqu’à la requête de l’utilisateur. Ce préfixe peut ainsi être réutilisé dans les tâches ultérieures au sein du même projet. En revanche, le contexte du projet qui vient après la requête de l’utilisateur n’a pas été mis en cache de la même manière, car il est relativement petit et se compose principalement de fichiers de niveau supérieur susceptibles de changer fréquemment.

Modifications liées au comportement du modèle

Qwen3.6 ne traitait pas les mises à jour de progression comme Junie l’attendait des modèles cloud : il ignorait généralement le bloc consacré aux mises à jour d’état dans un format similaire à XML, mais écrivait une description textuelle de ses actions en plus des appels d’outils. JetBrains a exploité ce comportement et affiché le texte produit comme une mise à jour destinée à l’utilisateur. L’entreprise précise que cette adaptation est spécifique au modèle, car d’autres modèles pourraient n’imprimer aucun texte ou produire un texte excessif.

JetBrains a également désactivé des requêtes facultatives adressées au modèle, notamment la logique qui génère une brève description de la tâche. Selon l’entreprise, cette concession limitée en matière d’expérience utilisateur est acceptable en contrepartie de la réduction du nombre de requêtes. Elle a aussi désactivé le mode multi-agent, car le traitement séquentiel est plus efficace sur un appareil M5 d’après ses tests, tandis que les requêtes parallèles resteraient limitées par la vitesse d’inférence.

Pourquoi Qwen3.6-27B a-t-il été choisi ?

JetBrains a décidé de désactiver complètement le raisonnement dans la version locale. Selon ses tests internes de la version cloud de Qwen3.6-27B, l’activation du raisonnement n’a pas apporté d’amélioration significative de la qualité. Comme les tokens de raisonnement sont comptabilisés parmi les tokens générés par le moteur d’inférence, leur désactivation a réduit d’environ deux à trois fois le nombre de tokens nécessaires, ce qui s’est traduit, selon l’entreprise, par une accélération proche du double dans l’exécution des tâches, avec un impact qu’elle a qualifié d’insignifiant sur la qualité.

L’entreprise a utilisé la version quantifiée en 4 bits, car elle était seulement légèrement moins performante que la version 8 bits dans les tests de référence et parce que la génération de tokens, liée à la mémoire, était environ deux fois plus rapide que dans la version 8 bits. En revanche, la vitesse de préremplissage ne différait pas entre les versions 4 bits, 8 bits et 16 bits lors des tests initiaux, ce qui a poussé l’équipe à examiner les opérations arithmétiques au sein du moteur.

Le goulot d’étranglement invisible : l’étape de préremplissage

Selon les chiffres de JetBrains, la vitesse de préremplissage peut atteindre environ 3 700 tokens par seconde sur une carte RTX 5090 avec les paramètres par défaut, contre environ 650 tokens par seconde sur un M5 avant optimisation. Dans les tâches d’examen des fichiers, la majeure partie du temps était consacrée au traitement du contexte, et non à la génération de la réponse elle-même.

L’équipe a constaté qu’une grande partie des opérations matricielles effectuées pendant le préremplissage était exécutée en précision 16 bits, même lorsque les poids étaient compressés en 4 bits, car les poids étaient convertis en 16 bits avant l’exécution des opérations. Comme le M5 dispose d’instructions spécifiques pour les calculs en précision 8 bits, JetBrains a appliqué un correctif au paquet MLX-VLM afin de transférer certaines opérations matricielles des couches de self-attention en 8 bits, obtenant une augmentation d’environ 40 % de la vitesse de préremplissage. La modification ne concernait pas les couches de full-attention, dont les poids restent en précision 16 bits même avec la quantification.

L’entreprise relie précisément son intérêt actuel pour le M5 à ces instructions de calcul : les puces M4 n’en disposent pas, et JetBrains affirme que les calculs en 16 bits sur M4 sont 20 % à 30 % plus lents au stade du préremplissage que sur M5.

Accélération de la génération et choix du modèle

JetBrains a activé simultanément deux méthodes de speculative decoding : la prédiction multi-tokens MTP à l’aide d’un modèle brouillon distinct et la correspondance n-gram, qui recherche des séquences répétées dans le contexte afin de prédire les tokens suivants. Dans certains cas, environ trois tokens proposés via MTP et jusqu’à huit tokens supplémentaires grâce à la correspondance n-gram peuvent être acceptés, ce qui a permis d’accélérer la génération jusqu’à deux fois.

L’entreprise explique que Qwen3.8-27B n’était pas le meilleur choix sur les appareils Mac, car il a besoin du raisonnement pour fonctionner correctement. Lorsqu’il est désactivé, la qualité se dégrade fortement et le modèle peut rester bloqué dans une boucle où il répète le même appel d’outil. Son activation à un niveau moyen augmente quant à elle d’environ cinq fois le nombre de tokens générés, ce qui entraîne concrètement un ralentissement proche de quatre fois, car le temps de préremplissage ne change pas beaucoup. Qwen3.6-27B reste donc, pour le moment, le choix le plus adapté à l’exécution locale de Junie sur du matériel Mac selon l’évaluation de JetBrains.

Lecture de certi.news : qu’est-ce qui change réellement ?

Cette expérience montre que mesurer un agent de programmation local uniquement par le nombre de tokens générés par seconde peut donner une image incomplète. L’utilisateur attend également le chargement des fichiers, la réutilisation du contexte et l’exécution des appels d’outils, autant d’étapes qui peuvent devenir un goulot d’étranglement avant même le début de la génération. En pratique, les modifications de Junie réduisent la nécessité de relire les fichiers, tandis que le correctif de MLX-VLM augmente la vitesse de traitement du contexte sur M5 et que la désactivation du raisonnement réduit le nombre de tokens nécessaires.

Les limites sont toutefois claires : la première version se concentre sur le M5, la désactivation du raisonnement peut ne pas convenir aux modèles qui en dépendent pour maintenir la qualité, et l’exploitation des mises à jour de progression est liée au comportement de Qwen3.6. JetBrains indique disposer de prototypes prenant en charge DGX Spark et RTX 5090, et étudier également des cartes dotées de 24 Go, mais l’article ne fournit ni calendrier ni spécifications concernant la disponibilité de ces versions. Junie Local représente donc une étape technique importante vers des agents de programmation locaux plus utilisables, et non la preuve que l’expérience est devenue équivalente à celle de tous les modèles cloud ou disponible sur tous les types de matériel.

Source de l’actualité
ف
Auteur

فريق تحرير certi.news

Dans la même catégorie

À lire également

Voir toutes les actualités