Qwen3.6 et MCP : Révolutionner l'IA locale pour les développeurs

Introduction de MCP

Les développeurs travaillant avec des systèmes d'intelligence artificielle locaux rencontrent souvent une difficulté commune : bien que les modèles soient performants en termes de raisonnement et de génération de code, ils ne peuvent pas interagir directement avec des bases de données ou des API internes. Cela oblige les développeurs à créer des wrappers Python personnalisés pour chaque outil, ce qui nécessite une maintenance constante à chaque mise à jour d'API.

Pour résoudre ce problème, Anthropic a introduit le Model Context Protocol (MCP). Ce protocole ouvert et universel vise à simplifier la connectivité des outils d'IA. En définissant un outil en tant que serveur MCP, tout modèle ou cadre compatible peut le découvrir et l'utiliser sans nécessiter de code d'intégration spécifique.

Le modèle Qwen3.6-35B-A3B est actuellement le plus performant pour ce type de tâches. Avec une fenêtre de contexte de 262 144 tokens et une architecture de Mixture of Experts (MoE), il active seulement 3 milliards de ses 35 milliards de paramètres par passage. Cela permet son fonctionnement sur du matériel qui ne pourrait normalement pas supporter un modèle aussi volumineux. Ce modèle a été spécifiquement entraîné pour des tâches agentiques basées sur MCP.

Cet article explore la création d'un assistant développeur GitHub local, capable de lire les problèmes ouverts d'un dépôt, d'identifier le code pertinent, de rédiger une correction et de créer une demande de tirage, le tout sur votre matériel grâce aux serveurs MCP, sans dépendance au cloud.

Comprendre Qwen3.6-35B-A3B

Pour saisir pleinement le fonctionnement de Qwen3.6-35B-A3B, il est crucial de comprendre son architecture. Le modèle comporte 35 milliards de paramètres, mais seulement 3 milliards sont activés à chaque passage, grâce à son architecture MoE. Avec 256 experts par couche et un routage de 8 plus 1 experts partagés par token, il offre la capacité d'un modèle de 35 milliards avec le coût de calcul d'un modèle de 3 milliards.

La structure interne de Qwen3.6 se distingue par l'utilisation de 40 couches avec un ratio de 3:1 entre les couches Gated DeltaNet et Gated Attention. Le mécanisme DeltaNet permet un traitement efficace des séquences longues, tandis que les couches d'attention complète assurent un raisonnement relationnel profond. Cette combinaison est essentielle pour traiter efficacement un dépôt contenant jusqu'à 500 fichiers.

La fenêtre de contexte native de 262 144 tokens peut être étendue à 1 010 000 grâce à l'échelle YaRN. Pour un agent, cette longueur de contexte est cruciale pour maintenir un historique d'appels d'outils et suivre un plan multi-étapes sans perdre de données essentielles.

Qwen3.6 a été formé sur des benchmarks agentiques basés sur MCP, avec deux caractéristiques clés :

• Agentic Coding : Le modèle gère les tâches de refactorisation multi-fichiers avec un raisonnement cohérent à travers les fichiers.
• Thinking Preservation : Avec le drapeau preserve_thinking, le modèle conserve les traces de raisonnement des tours précédents, permettant une continuité dans les conversations multi-tours.

Exigences système

Pour déployer Qwen3.6, trois options s'offrent aux développeurs, selon leur matériel :

• Inférence GPU : Recommandée pour les charges de travail en production, nécessitant environ 70 Go de VRAM en bfloat16. En quantification Q4, le modèle s'adapte à 20–24 Go de VRAM, gérable par un RTX 4090 ou deux RTX 3090.

• CPU/Hybride via KTransformers : Pour ceux sans GPU de 24 Go, KTransformers permet de décharger les calculs lourds sur le GPU et d'exécuter le reste sur le CPU, avec une latence de 30–120 secondes par tour.

• Modèles plus petits pour les tests : Les développeurs peuvent utiliser des modèles plus petits comme Qwen/Qwen2.5-7B-Instruct pour tester l'intégration MCP sans nécessiter le matériel pour le modèle complet.

Exigences logicielles

Pour faire fonctionner Qwen3.6, Python 3.11+ est requis, ainsi que les bibliothèques suivantes :

python --version
python -m venv qwen-mcp-env
source qwen-mcp-env/bin/activate    # macOS / Linux
qwen-mcp-env\Scripts\activate       # Windows

"[openai](/dossier/openai)>=1.30.0" \
"qwen-agent>=0.0.10" \

Pour le cadre de service, choisissez parmi :

pip install "vllm>=0.19.0"       # NVIDIA GPU
pip install "sglang>=0.5.10"     # NVIDIA GPU (pré-remplissage plus rapide)
pip install "ktransformers"      # CPU/hybride

Node.js 18+ est également requis pour les serveurs MCP préconstruits installés via npx.

Servir Qwen3.6 localement avec une API compatible OpenAI

Avant de connecter des serveurs MCP, il est essentiel d'avoir un serveur d'inférence opérationnel. Les outils comme SGLang et vLLM offrent une API compatible OpenAI, pointant vers localhost au lieu de api.openai.com.

SGLang (Recommandé pour les charges de travail à long contexte)

• Installez SGLang avec toutes les dépendances

pip install "sglang[all]>=0.5.10"

• Lancez le serveur avec les parseurs de raisonnement et d'appels d'outils activés.

python -m sglang.launch_server \
--model-path Qwen/Qwen3.6-35B-A3B \
--host 0.0.0.0 \
--reasoning-parser qwen3 \
--tool-call-parser qwen3_coder \
--enable-prefix-caching \
--tp 2    # parallélisme tensoriel sur 2 GPU ; retirez si vous utilisez un seul GPU

• Équivalent vLLM avec les mêmes drapeaux critiques

vllm serve Qwen/Qwen3.6-35B-A3B \
--host 0.0.0.0 \
--reasoning-parser qwen3 \
--tool-call-parser qwen3_coder \
--enable-prefix-caching-v2 \
--tensor-parallel-size 2

Modèle plus petit via Ollama

ollama pull qwen2.5:7b

• L'API d'Ollama est compatible OpenAI à http://localhost:11434/v1

Une fois le serveur en cours d'exécution, vérifiez son état avant de continuer :

Vérification de l'état

curl http://localhost:30000/health

Testez le point de terminaison des complétions de chat

curl http://localhost:30000/v1/chat/completions \
-H "Content-Type: application/json" \
"model": "Qwen/Qwen3.6-35B-A3B",
"messages": [{"role": "user", "content": "Reply with: ready"}],
"max_tokens": 10

Si vous recevez une réponse JSON avec un tableau de choix, le serveur est prêt. Ne passez pas à la configuration de MCP tant que cela ne fonctionne pas. Chaque échec d'intégration que vous rencontrerez plus tard est plus facile à déboguer lorsque vous savez que la couche de service est solide.

Comprendre MCP et pourquoi cela change l'architecture de l'agent

Avant de coder un agent, il est crucial de comprendre le fonctionnement de MCP au niveau du protocole. MCP est un protocole JSON-RPC 2.0 fonctionnant sur un transport stdio ou HTTP. Lorsqu'un client MCP se connecte à un serveur, il commence par appeler tools/list pour découvrir les outils disponibles. Chaque outil est décrit par un nom, une description et un schéma d'entrée défini en JSON Schema.

Lorsque le modèle souhaite appeler un outil, il émet un objet d'appel d'outil structuré. Le client MCP exécute l'appel en envoyant une requête tools/call au serveur, qui gère l'exécution et renvoie un résultat. Le client injecte ce résultat dans la conversation en tant que message de rôle d'outil. Le modèle lit le résultat et décide de la prochaine étape.

Cette séparation des responsabilités est cruciale. Le modèle décide quoi appeler et avec quels arguments, tandis que le client gère l'exécution et le serveur effectue le travail réel. Votre code ne lie jamais un outil à un modèle ; vous indiquez simplement au client quels serveurs sont disponibles.

Il existe deux façons d'utiliser MCP avec Qwen3.6 :

• Via Qwen-Agent : La bibliothèque officielle qwen_agent gère automatiquement la découverte d'outils, l'analyse des appels, l'injection des résultats et la gestion des conversations multi-tours. Moins de code, moins de contrôle. Adapté à la plupart des cas d'utilisation.

• Via le SDK Python MCP directement : Vous gérez la boucle agentique vous-même en utilisant mcp.ClientSession. Plus de code, pleine visibilité sur chaque message, contrôle complet sur la gestion des erreurs et la logique de réessai. Adapté aux systèmes de production où vous devez surveiller chaque étape.

Cet article couvre les deux, en commençant par Qwen-Agent.

Construire l'assistant développeur GitHub local

L'agent effectue quatre actions en séquence : lit les problèmes ouverts d'un dépôt GitHub, trouve le code pertinent, rédige une correction et ouvre une demande de tirage. Tout localement, tout via MCP.

Partie 1 : Configuration de l'environnement et du serveur MCP

• Définissez votre jeton d'accès personnel GitHub

  • Requis par le serveur MCP GitHub pour les appels API

export GITHUB_TOKEN=ghp_your_token_here

• Les serveurs MCP préconstruits s'installent via npx — aucune étape d'installation séparée

• npx gère cela lors de la première utilisation lorsque l'agent