SWE-bench expliqué : tester son LLM code en local

Évaluer un SWE-bench LLM en local permet de mesurer la capacité réelle d'un modèle open-weights à résoudre des bugs GitHub authentiques, bien au-delà des scores HumanEval. Le SWE-bench LLM se distingue parce qu'il impose au modèle de naviguer dans un dépôt complet, comprendre un ticket d'issue, modifier plusieurs fichiers et passer la suite de tests. Cet article détaille la mécanique du benchmark, la variante SWE-bench Verified, les exigences matérielles, les modèles candidats du catalogue, la procédure d'exécution locale, puis répond aux questions fréquentes des praticiens self-host.

Comprendre la mécanique de SWE-bench

SWE-bench est un benchmark publié en 2023 par l'université de Princeton qui collecte 2 294 problèmes GitHub réels issus de 12 projets Python populaires (Django, scikit-learn, sympy, matplotlib, etc.). Chaque tâche fournit au modèle un dépôt à un commit donné et l'énoncé d'une issue. Le LLM doit produire un patch (diff) qui, une fois appliqué, fait passer les tests précédemment en échec sans casser les tests existants. Pour les détails de construction du dataset, voir le papier original SWE-bench et le dépôt GitHub officiel.

Contrairement à HumanEval qui évalue des fonctions courtes isolées, SWE-bench mesure :

• Compréhension contextuelle : lire un dépôt de plusieurs dizaines de milliers de lignes
• Localisation de bug : identifier les bons fichiers à modifier sans guidance explicite
• Édition multi-fichiers : produire un patch cohérent qui ne casse rien
• Raisonnement de longue chaîne : alterner exploration, hypothèse, vérification

Un score brut de 20 % sur SWE-bench correspond souvent à un score supérieur à 80 % sur HumanEval, ce qui explique pourquoi de nombreux modèles affichent un excellent HumanEval mais s'effondrent sur SWE-bench.

SWE-bench Verified : la version filtrée

SWE-bench Verified est un sous-ensemble de 500 instances annotées manuellement par OpenAI en collaboration avec les auteurs de Princeton. L'objectif : retirer les tâches dont l'énoncé est ambigu, dont les tests cachés sont trop spécifiques, ou dont le patch de référence dépend d'un contexte non fourni. Détails complets sur le blog OpenAI consacré à Verified.

Pour un test local, SWE-bench Verified est le bon choix :

• 500 instances au lieu de 2 294 : exécution réalisable en quelques jours sur une station
• Évaluation plus fiable du raisonnement réel du modèle
• Comparaison directe avec les scores publiés par les vendors

L'agent de référence le plus utilisé est SWE-agent, un harnais qui expose un terminal interactif au LLM, lui permettant d'éditer des fichiers, lancer des commandes et exécuter des tests. Une alternative populaire est OpenHands, qui supporte nativement les backends OpenAI-compatibles (vLLM, llama.cpp server, SGLang).

Modèles du catalogue adaptés au benchmark

Le LLM agent code doit conjuguer un contexte large (le harnais injecte des stack traces, du code source, l'historique d'actions) et de bonnes performances en raisonnement. Voici les candidats du catalogue triés par profil matériel.

Stations workstation à très haut budget VRAM (≥ 400 GB)

• DeepSeek V3.2 (685B, MIT) — VRAM Q4 ~410 GB, ctx 128k. Référence open-weights actuelle sur SWE-bench Verified selon les évaluations indépendantes.
• DeepSeek R1 671B (671B, MIT) — VRAM Q4 ~400 GB, ctx 128k. Modèle de raisonnement à longue chaîne, particulièrement adapté à la localisation de bug.
• Mistral Large 3 675B (675B, Apache 2.0) — VRAM Q4 ~405 GB, ctx 256k. Licence permissive, intéressant pour usage commercial.
• Kimi K2.6 (1000B, Modified MIT) — VRAM Q4 ~600 GB, ctx 256k. Optimisé pour les workflows agentiques selon Moonshot.

Cluster multi-GPU (140-250 GB)

• Qwen 3 235B-A22B (235B, Apache 2.0) — VRAM Q4 ~142 GB, ctx 131k. MoE actif à 22B, bon rapport coût/qualité.
• Llama 4 Maverick 400B (400B, Llama 4 Community) — VRAM Q4 ~240 GB, ctx 1M. Contexte exceptionnel pour gros dépôts.
• GLM-5.1 (744B, MIT) — VRAM Q4 ~445 GB, ctx 200k.

Station unique (≤ 80 GB)

• Qwen3-Coder-Next 80B-A3B (80B, Apache 2.0) — VRAM Q4 ~48 GB, ctx 262k. Spécialisé code, exécutable sur une A100 80GB ou deux 3090.
• gpt-oss 120B (117B, Apache 2.0) — VRAM Q4 ~70 GB, ctx 128k. Modèle d'OpenAI publié en open-weights.
• Mistral Small 4 (119B, Apache 2.0) — VRAM Q4 ~72 GB, ctx 256k.

Pour un comparatif détaillé sur le terrain du code, voir Qwen3-Coder vs DeepSeek V3.2 et la page meilleur LLM pour le code.

Tokens/sec et impact sur la durée du run

Un run SWE-bench Verified complet consomme entre 500 millions et 2 milliards de tokens selon le harnais et le nombre de tentatives autorisées. Le débit en tokens/sec détermine donc directement la durée du benchmark.

Estimations indicatives (à confirmer sur votre setup) :

• DeepSeek V3.2 sur 8×H100 80GB en Q4 : ~25 tokens/sec en génération, run Verified estimé entre 5 et 8 jours
• Qwen 3 235B-A22B sur 4×H100 : ~40 tokens/sec en Q4 (MoE actif à 22B aide), run estimé 3 à 5 jours
• Qwen3-Coder-Next 80B-A3B sur 2×A100 80GB : ~60 tokens/sec en Q4, run estimé 2 à 3 jours
• gpt-oss 120B sur 1×H200 141GB en Q4 : ~35 tokens/sec, run estimé 3 à 4 jours

Le contexte effectif compte autant que la vitesse brute : SWE-agent injecte régulièrement 30k à 60k tokens dans le prompt pour reconstituer l'état du dépôt. Un modèle limité à 32k de contexte est mal adapté ; visez 128k minimum. Voir aussi le guide VRAM par quantification pour ajuster votre budget mémoire.

Procédure d'exécution locale

Voici une procédure simplifiée pour un setup self-host strict.

1. Préparer l'environnement Docker : SWE-bench Verified exige des images Docker par projet (Django, sympy, etc.) pour isoler l'exécution des tests. Comptez 80 GB de disque pour les images officielles publiées par les mainteneurs.

2. Lancer un serveur d'inférence OpenAI-compatible : avec vLLM ou llama.cpp en mode serveur, exposez votre modèle sur localhost:8000/v1. Pour Qwen3-Coder-Next en Q4 sur 2×A100, une commande vLLM type configure --tensor-parallel-size 2 --max-model-len 131072 --quantization awq.

3. Cloner SWE-agent et configurer le harnais pour pointer vers l'endpoint local. Le fichier de configuration accepte api_base: http://localhost:8000/v1 et model_name: <votre-modèle>.

4. Lancer un run de calibration sur 10-20 instances pour vérifier que le formatage des actions est respecté. Beaucoup de modèles open-weights échouent ici parce qu'ils inventent des balises XML que le harnais ne reconnaît pas.

5. Run complet : 500 instances, plusieurs jours, journaliser systématiquement les patches générés pour analyse post-mortem.

6. Soumission optionnelle au leaderboard officiel pour comparaison publique.

Astuce pratique : limitez le nombre d'actions par instance (50-75) pour éviter qu'un modèle entre dans une boucle infinie qui consomme votre budget tokens.

Interprétation des résultats

Un score brut sur SWE-bench Verified s'interprète relativement, pas absolument.

• < 10 % : le modèle ne maîtrise pas le format d'action de l'agent, ou son contexte est trop court
• 10-25 % : niveau correct pour un modèle open-weights généraliste
• 25-50 % : niveau attendu d'un modèle de raisonnement spécialisé (DeepSeek R1 671B, Kimi K2.6)
• > 50 % : niveau frontière, atteint par les meilleurs modèles propriétaires

Au-delà du score, regardez la distribution des échecs : tests qui timeout, patches qui ne s'appliquent pas, fichiers modifiés hors scope. Cette analyse révèle souvent que le modèle est limité non pas par son raisonnement mais par le harnais (taille de fenêtre, parsing des actions). Pour aller plus loin sur la sélection de modèle agentique, consultez le guide LLM pour agents.

FAQ

Q : SWE-bench ou SWE-bench Verified pour un premier test ?

Verified, sans hésitation. Les 500 instances sont annotées manuellement, les ambiguïtés sont retirées, et la durée d'exécution reste raisonnable sur une station unique. Le SWE-bench complet (2 294 instances) contient des tâches mal spécifiées qui pénalisent injustement les modèles. Verified offre aussi une comparaison directe avec les scores publiés par les vendors de modèles propriétaires.

Q : Quelle quantification choisir pour préserver le score code ?

Q4_K_M (GGUF) ou AWQ 4-bit dégradent typiquement de 1 à 3 points le score SWE-bench par rapport au FP16, ce qui reste acceptable. Évitez Q3 et Q2 sur les modèles de raisonnement, où la perte devient significative. Si votre VRAM le permet, Q5_K_M ou Q8 offrent un meilleur ratio. Voir le comparatif quantification GGUF vs AWQ.

Q : Faut-il un modèle "coder" spécialisé ou un généraliste ?

Les deux profils marchent. Les modèles spécialisés code comme Qwen3-Coder-Next 80B-A3B excellent sur la génération de patches, mais les modèles de raisonnement généralistes comme DeepSeek R1 671B sont souvent supérieurs sur la localisation de bug et la planification multi-étapes, qui dominent le coût d'une tâche SWE-bench.

Q : Peut-on faire tourner SWE-bench Verified sur une seule RTX 4090 ?

Difficile. 24 GB de VRAM limitent à des modèles ≤ 30B en Q4, et ces modèles plafonnent généralement sous 10 % sur Verified faute de raisonnement suffisant. Vous pouvez l'utiliser pour valider votre pipeline avec un modèle léger comme Qwen3-Coder-Next en offload partiel CPU, mais visez plutôt 2×3090 ou 1×A100 80GB pour un résultat exploitable.

Q : Combien de tokens consomme un run complet ?

Estimé entre 500 millions et 2 milliards de tokens selon le harnais (SWE-agent, OpenHands, custom) et le nombre maximum d'actions autorisées par instance. Avec un budget de 50 actions par instance et 30k tokens de contexte moyen, comptez environ 1 milliard de tokens pour 500 instances. Plus le modèle "réfléchit" en chaîne (R1-style), plus la facture token grimpe.

Q : Les résultats locaux sont-ils comparables aux scores du leaderboard ?

Oui, à condition d'utiliser le harnais officiel, la même version du dataset et de respecter le protocole de soumission (un seul patch par instance, pas de re-tentative oracle). Toute modification du harnais ou du prompt système doit être documentée. Le leaderboard SWE-bench accepte les soumissions self-host et vérifie la reproductibilité.

Conclusion

Exécuter un SWE-bench LLM en local reste l'épreuve la plus parlante pour départager un modèle code open-weights et un simple bon élève de HumanEval. Avec SWE-bench Verified, une station 2×A100 ou 4×H100 et un modèle adapté (Qwen3-Coder-Next, DeepSeek V3.2 ou gpt-oss 120B), un run réaliste tient en quelques jours. Pour calibrer votre setup avant de lancer le benchmark, utilisez le configurateur de quelllm.fr ou parcourez le catalogue complet.