SWE-bench

Exécutez des évaluations SWE-bench en parallèle à l’aide de sandboxs sur CoreWeave. Ce guide s’adresse aux praticiens et chercheurs en ML qui souhaitent évaluer à grande échelle les performances des modèles de langage en matière de correction de code. À la fin de ce guide, vous disposerez d’une configuration opérationnelle qui exécute des évaluations SWE-bench simultanément sur de nombreux sandboxs CoreWeave, et qui enregistre les résultats en local en vue de leur analyse.

Fonctionnement

SWE-bench évalue la capacité des modèles de langage à corriger de vrais bugs dans de vrais dépôts. Chaque tâche applique un patch, exécute la suite de tests et vérifie si le correctif fonctionne. Vous pouvez exécuter SWE-bench localement avec Docker, mais vous êtes alors limité par les ressources de votre machine. Les Sandbox CoreWeave vous permettent d’exécuter des évaluations à grande échelle sur l’infrastructure CoreWeave. Lancez simultanément des dizaines, voire des centaines de Sandbox, sans avoir à vous soucier de leur gestion. Chaque Sandbox démarre à partir d’une image prête à l’emploi issue du registre d’Epoch AI sur GitHub Container Registry (GHCR). C’est la plateforme de Sandbox, et non votre machine, qui récupère l’image : vous n’avez donc besoin ni de Docker ni d’une étape de compilation locale.

Configuration

Suivez les étapes ci-dessous pour installer les outils requis et configurer l’authentification avant d’exécuter des évaluations.

Préparez un environnement virtuel Python, puis installez le SDK et les dépendances d’évaluation :
uv pip install cwsandbox swebench datasets

Clonez le dépôt contenant les exemples de scripts d’évaluation :

git clone https://github.com/coreweave/cwsandbox-client.git
cd cwsandbox-client

Choisissez l’identifiant d’authentification du compte propriétaire des Sandbox d’évaluation. Pour obtenir l’un ou l’autre, consultez Choisir et obtenir des identifiants d’authentification.

Clé API Forge
Jeton d’accès à l’API CoreWeave

Installez l’intégration W&B et exportez votre clé API Forge :

uv pip install 'cwsandbox[wandb]>=1.14.2'
export WANDB_API_KEY="[WANDB-API-KEY]"

Dans examples/swebench/run_evaluation.py, ajoutez AuthStrategy aux éléments importés depuis cwsandbox. Ajoutez auth=AuthStrategy.WANDB à l’appel SandboxDefaults(...) existant. L’authentification W&B est ainsi utilisée pour chaque Sandbox de la session d’évaluation, même si CWSANDBOX_API_KEY est également défini.

Exportez votre jeton CoreWeave :

export CWSANDBOX_API_KEY="[API-ACCESS-TOKEN]"

Le script d’évaluation utilise l’authentification CoreWeave par défaut. Pour rendre ce choix explicite, ajoutez AuthStrategy aux éléments importés depuis cwsandbox dans examples/swebench/run_evaluation.py. Ajoutez auth=AuthStrategy.COREWEAVE_API_KEY à l’appel SandboxDefaults(...) existant.

Les deux options utilisent par défaut la capacité sans serveur. Pour utiliser votre propre capacité CKS, choisissez le jeton CoreWeave, activez un exécuteur et ajoutez placement_mode="cks" au même appel SandboxDefaults(...).

Démarrage rapide

Avant de passer à l’échelle, commencez par un run sur une seule instance afin de vérifier que votre environnement et vos identifiants d’authentification fonctionnent correctement, et qu’une sandbox peut démarrer à partir de son image GHCR. L’option gold utilise le correctif du dataset dont on sait qu’il est correct :

uv run python examples/swebench/run_evaluation.py \
    --predictions-path gold \
    --instance-ids astropy__astropy-12907 \
    --run-id test

Ce run réussit, ce qui confirme qu’une sandbox peut démarrer à partir de son image, appliquer le patch et exécuter la suite de tests de bout en bout.

Exécuter en parallèle

Exécutez plusieurs instances simultanément :

uv run python examples/swebench/run_evaluation.py \
    --predictions-path gold \
    --instance-ids \
        astropy__astropy-12907 \
        django__django-11039 \
        django__django-11099 \
        django__django-11283 \
        matplotlib__matplotlib-23476 \
        scikit-learn__scikit-learn-13142 \
        sympy__sympy-13031 \
        sympy__sympy-13647 \
    --run-id parallel-test \
    --max-workers 8

Cette commande lance huit sandboxs et les exécute en parallèle. Tous réussissent, car les patchs de référence (gold patches) sont les correctifs attendus.

Évaluer les prédictions du modèle

Pour tester la sortie d’un modèle personnalisé :

uv run python examples/swebench/run_evaluation.py \
    --predictions-path predictions.json \
    --instance-ids django__django-11039 scikit-learn__scikit-learn-13142 \
    --run-id eval-run-1 \
    --max-workers 10

Le fichier de prédictions associe chaque ID d’instance à un patch :

[
  {
    "instance_id": "django__django-11039",
    "model_name_or_path": "gpt-4",
    "model_patch": "diff --git a/..."
  }
]

Options

Option	Par défaut	Description
`--predictions-path`	Requis	Chemin vers le fichier JSON des prédictions, ou `gold` pour utiliser les patchs de référence
`--instance-ids`	Requis	ID d’instances, séparés par des espaces
`--run-id`	Requis	Identifiant de ce run
`--max-workers`	10	Nombre maximal de sandboxs exécutés en parallèle
`--timeout`	1800	Délai d’expiration par instance, en secondes (30 minutes)
`--output-dir`	`logs/swebench`	Répertoire de destination des journaux et des rapports
`--dataset`	`princeton-nlp/SWE-bench_Lite`	Nom du dataset Hugging Face
`--force`	false	Réexécuter les instances même si report.json existe déjà

Ajuster les ressources

Par défaut, chaque sandbox dispose de 2 CPU et de 4Gi de mémoire. Modifiez ces valeurs dans run_evaluation.py :

defaults = SandboxDefaults(
    tags=(f"swebench-{run_id}",),
    resources={"cpu": "4", "memory": "8Gi"},
)

Fonctionnement

Cette section présente les rouages du script afin que vous puissiez l’adapter à vos propres flux de travail d’évaluation.

Images de conteneur

Epoch AI héberge des images préconstruites sur GHCR. Chaque instance dispose de sa propre image, avec le dépôt extrait au bon commit, les dépendances installées et l’environnement de test prêt. Le nom de l’image respecte le format suivant : ghcr.io/epoch-research/swe-bench.eval.{arch}.{instance_id.lower()}:latest Le script convertit l’ID de l’instance en minuscules pour le nom de l’image. Il tire arch de l’attribut arch de la spécification de test. Si cet attribut est absent, le script utilise x86_64. La plateforme de sandbox récupère chaque image depuis GHCR au démarrage de la sandbox. Si vous utilisez votre propre capacité CKS, ce sont les nœuds de votre cluster qui récupèrent les images. Votre machine n’a besoin d’aucun accès à ghcr.io et aucune compilation locale n’est nécessaire.

Flux d’évaluation

Chaque instance passe par les étapes suivantes :

Étape	Emplacement	Déroulement
1. Charger le dataset	Local	Récupérer les métadonnées de l’instance depuis Hugging Face
2. Créer la sandbox	Sandbox	Démarrer la sandbox avec l’image de l’instance
3. Écrire le patch	Sandbox	Écrire le patch dans `/tmp/patch.diff`
4. Appliquer le patch	Sandbox	Exécuter `git apply` (repli sur `patch` si nécessaire)
5. Exécuter les tests	Sandbox	Exécuter `/root/eval.sh`
6. Noter les résultats	Local	Analyser la sortie avec `swebench.harness.grading`
7. Écrire le rapport	Local	Enregistrer les résultats dans `logs/swebench/`
8. Nettoyage	Sandbox	Arrêter la sandbox

Les étapes 2 à 5 et 8 s’exécutent à distance, les étapes 1, 6 et 7 sur votre machine.

Exécution parallèle

Le script utilise ThreadPoolExecutor pour exécuter en parallèle les flux de travail des instances. Chaque thread fait avancer une instance tout au long de son flux de travail. Pendant qu’une instance exécute des tests, une autre peut appliquer son patch, une troisième effectuer l’évaluation en local et une quatrième démarrer. C’est ce chevauchement qui permet de gagner en rapidité. Les résultats sont renvoyés via as_completed() au fur et à mesure que les flux de travail se terminent.

Nettoyage

Le script utilise une Session de sandbox pour suivre les sandboxs. Lorsque la session se termine (fin normale, exception ou Ctrl+C), elle nettoie tous les sandboxs.

with cwsandbox.Session(defaults=defaults) as session:
    with ThreadPoolExecutor(max_workers=max_workers) as executor:
        # À sa fermeture, la session nettoie les bacs à sable créés ici

Sortie

Les résultats sont enregistrés dans {output-dir}/{run-id}/{model-name}/{instance-id}/ :

Fichier	Contenu
`report.json`	Statut de résolution, ID de la sandbox, durée et, si l’instance a échoué, l’erreur rencontrée
`test_output.txt`	Sortie complète des tests
`patch.diff`	Le patch appliqué

Format du rapport

{
  "instance_id": {
    "resolved": true,
    "tests_status": {
      "PASSED": ["test_foo", "test_bar"],
      "FAILED": []
    }
  },
  "sandbox_id": "sandbox-abc123",
  "duration_seconds": 45.2
}

Lorsqu’une instance rencontre une erreur, par exemple parce que sa sandbox ne parvient pas à démarrer, report.json contient également "errored": true et une chaîne error_message. Les résultats des tests et sandbox_id peuvent alors être omis. Ce format est compatible avec les outils standard de SWE-bench.

Dépannage

Échec de l’application du patch

Si APPLY_PATCH_FAIL apparaît dans les journaux, le patch est probablement mal formé, cible le mauvais commit ou contient des erreurs de caractères d’espacement. Exécutez git apply --check en local pour identifier le problème. Vérifiez que l’ID d’instance correspond bien à celui de la prédiction.

Délais d’expiration des tests

Certaines suites de tests durent plus de 30 minutes. Le code généré par le modèle peut aussi contenir des boucles infinies. Si nécessaire, augmentez la valeur de --timeout ou consultez la sortie des tests pour identifier l’endroit où ils bloquent.

Erreurs de récupération d’image

Si la plateforme de sandbox ne parvient pas à récupérer l’image d’une instance, la sandbox correspondante ne démarre pas. Le script journalise l’erreur avec l’ID de l’instance, par exemple [astropy__astropy-12907] Error: ..., et l’enregistre dans le champ error_message du fichier report.json de cette instance. La récupération s’effectue sur l’infrastructure CoreWeave, et non sur votre machine : votre accès réseau local à ghcr.io n’est donc pas en cause. Lisez le message d’erreur, puis examinez les causes probables :

Image introuvable : vérifiez qu’Epoch AI publie bien une image pour cet ID d’instance. Un ID d’instance absent du dataset --dataset n’atteint jamais de sandbox : le script journalise Instance IDs not found in dataset et l’ignore.
Votre propre capacité CKS : si vous définissez placement_mode="cks", ce sont les Nœuds de votre cluster qui récupèrent l’image ; ils doivent donc disposer d’un accès sortant à ghcr.io. La politique de sandbox de l’exécuteur doit également autoriser les images provenant de ghcr.io/epoch-research.

Voir aussi

Guide d’exécution des commandes : informations détaillées sur les modèles d’utilisation de exec().
Modèles de nettoyage : gestion du cycle de vie des sandboxes.

Sandbox

Utiliser les Sandbox

Gérer les bacs à sable

Référence

Fonctionnement

Configuration

Démarrage rapide

Exécuter en parallèle

Évaluer les prédictions du modèle

Options

Ajuster les ressources

Fonctionnement

Images de conteneur

Flux d’évaluation

Exécution parallèle

Nettoyage

Sortie

Format du rapport

Dépannage

Échec de l’application du patch

Délais d’expiration des tests

Erreurs de récupération d’image

Voir aussi

​Fonctionnement

​Configuration

​Démarrage rapide

​Exécuter en parallèle

​Évaluer les prédictions du modèle

​Options

​Ajuster les ressources

​Fonctionnement

​Images de conteneur

​Flux d’évaluation

​Exécution parallèle

​Nettoyage

​Sortie

​Format du rapport

​Dépannage

​Échec de l’application du patch

​Délais d’expiration des tests

​Erreurs de récupération d’image

​Voir aussi

Fonctionnement

Configuration

Démarrage rapide

Exécuter en parallèle

Évaluer les prédictions du modèle

Options

Ajuster les ressources

Fonctionnement

Images de conteneur

Flux d’évaluation

Exécution parallèle

Nettoyage

Sortie

Format du rapport

Dépannage

Échec de l’application du patch

Délais d’expiration des tests

Erreurs de récupération d’image

Voir aussi