Microsoft montre Qwen3.8-27B dans Foundry Local relié à GitHub Copilot : 64K de contexte avec 24 Go de VRAM NVIDIA ; le texte ne chiffre pas la vitesse, les graphiques et la méthode complète restent non vérifiés

Le 5 novembre 2026, Microsoft a publié sur son blog Foundry un article montrant comment exécuter localement le modèle de codage ouvert Qwen3.8-27B avec Foundry Local et le relier à GitHub Copilot par apportez votre propre clé (Bring Your Own Key, BYOK). L’argument est que le code et le contexte restent sur la machine du développeur, que les coûts d’inférence sont prévisibles et que le travail peut continuer hors ligne. L’article est un guide pratique avec une affirmation de performance, et le texte ne donne aucun chiffre de vitesse précis ; nous n’avons pas vérifié les valeurs des deux graphiques ni la méthode complète. Nous avons vérifié la description de l’inférence locale et de la connexion du point de terminaison Copilot, sans tester hors réseau l’IDE, l’authentification, la télémétrie ni la chaîne d’outils de bout en bout.

Le modèle est Qwen3.8-27B, que le fil de demande GitHub décrit plus bas attribue à Alibaba. Microsoft en fait sa cible principale d’optimisation parce qu’il associe des capacités de codage à une taille adaptée à l’usage local, et montre des scores qu’il décrit comme publiés : 73,0 sur Terminal Bench 2.1, 61,7 sur SWE-bench Pro, 42,3 sur NL2Repo-Bench et 42,2 sur DeepSWE 1.1. L’article les cite comme des benchmarks publiés, ne dit pas que Microsoft a mené ces tests et ne compare pas le modèle à des modèles cloud. Il dit clairement que les modèles locaux peuvent raisonner moins bien que les modèles cloud avancés et propose un flux hybride : en local pour le codage courant et les sous-tâches ciblées, dans le cloud pour le travail difficile qui exige beaucoup de raisonnement.

Les affirmations d’ingénierie portent sur la façon de faire tenir le modèle sur du matériel grand public. Foundry Local utilise ONNX Runtime pour optimiser tout le chemin d’inférence sur les GPU NVIDIA. Pour la vitesse, il emploie le décodage spéculatif DFlash2, où un petit modèle brouillon prédit plusieurs jetons à la fois, ainsi que des fusions de graphes CUDA et des noyaux réglés pour l’architecture NVIDIA SM121. Pour la mémoire, il combine des poids INT4, la quantification du cache KV, le partage de la mémoire des plongements et le déchargement sur le CPU. En quantification 4 bits, le modèle fait environ 18 Go. Un GPU de 24 Go de VRAM peut l’exécuter avec une fenêtre de contexte allant jusqu’à 64K jetons, et un GPU de 32 Go ou plus peut prendre en charge des contextes plus longs jusqu’au maximum du modèle, 262K jetons. La mise en cache des préfixes et le traitement par lots continu servent les invites répétées et les requêtes parallèles.

La comparaison avec llama.cpp demande une lecture prudente. Microsoft a testé le modèle 4 bits sur une NVIDIA GeForce RTX 5090 de 32 Go de VRAM et sur un NVIDIA DGX Spark avec 128 Go de mémoire unifiée, avec un jeu de données de vrais tickets GitHub, et dit que Foundry Local générait les jetons plus vite pour toutes les longueurs d’invite testées, l’écart se creusant au-delà de 131K jetons. L’article précise que le modèle comparé est à 4 bits, mais ne donne dans le texte ni jetons par seconde, ni format précis de quantification, version ou réglages complets de llama.cpp, ni mesure de la qualité des réponses. Les graphiques montrent peut-être des chiffres, mais nous n’avons pas pu les vérifier par rapport à une méthode indiquée : le résultat est donc une affirmation du fournisseur sur la vitesse de génération relative sur deux machines.

L’installation a des limites claires. Elle exige Foundry Local CLI 0.13.0 ou plus récent, qui inclut selon l’article ces optimisations. L’installation passe par WinGet, les commandes sont des commandes batch Windows, et l’exécution sur GPU NVIDIA demande d’installer séparément CUDA et un runtime cuDNN compatible, car Foundry Local ne les télécharge pas. Après `foundry model load qwen3.8-27b`, l’utilisateur lit le point d’accès avec `foundry server status`, ajoute ensuite Foundry Local comme fournisseur de modèles dans l’application GitHub Copilot et choisit Qwen3.8-27B dans le sélecteur de modèles. Les Mac et les GPU AMD sont annoncés comme travaux futurs ; pour l’instant, l’article vise donc du matériel NVIDIA avec au moins 24 Go de VRAM.

Une vérification sur GitHub montre l’historique du catalogue. Un utilisateur a demandé le 19 août d’ajouter Qwen3.8-27B au catalogue de Foundry Local, et un collaborateur du dépôt a répondu le 4 novembre qu’il était désormais disponible dans le catalogue. Cela correspond à la date de l’article du blog. Le fil est une demande de la communauté : il confirme l’inscription au catalogue mais ne dit rien du niveau de prise en charge.

Notre lecture : c’est un guide pratique pour les développeurs qui disposent d’un GPU NVIDIA à grande mémoire et veulent un assistant de codage privé, et il précise que les modèles locaux plus petits peuvent avoir un raisonnement limité face aux modèles cloud avancés. Considérez l’affirmation de vitesse comme non vérifiée, testez sur votre propre dépôt et vérifiez qu’un contexte de 64K sur une carte de 24 Go suffit à vos tâches avant de remplacer un modèle cloud.