Exécuter des évaluations DeepSWE v1.1

Évaluez un agent de développement sur un petit échantillon de DeepSWE v1.1. CoreWeave Sandboxes fournit les environnements dans lesquels l’agent modifie le code et le benchmark vérifie ses patchs. La recette DeepSWE fournit le script d’évaluation, le fichier de verrouillage des dépendances et l’adaptateur de sandbox. La recette exécute l’agent de développement mini-swe-agent sur votre machine locale et envoie ses commandes shell à une sandbox sans serveur. Une fois que l’agent a terminé, Pier, le framework d’évaluation, récupère les modifications commitées par l’agent et arrête sa sandbox. Une nouvelle sandbox de vérification applique ensuite le patch et exécute les tests réservés. L’exemple utilise moonshotai/Kimi-K2.7-Code via Serverless Inference pour les requêtes au modèle. DeepSWE et Sandboxes n’imposent pas ce fournisseur. La recette fournie définit en dur le point de terminaison Forge et la gestion des identifiants d’authentification. Son option --model permet de sélectionner un autre modèle sur ce point de terminaison. Pour utiliser un autre fournisseur, vous devez adapter la configuration du modèle et l’authentification de la recette. Seule la sandbox de vérification reçoit les fichiers de tests réservés. La recette crée les deux bacs à sable en bloquant tout accès réseau sortant. Les identifiants d’authentification de la sandbox et de l’inférence restent sur votre machine locale.

Ce guide valide une intégration sur un petit échantillon. L’adaptateur d’agent côté hôte et les limites de run diffèrent de la configuration officielle du leaderboard DeepSWE. Les résultats obtenus sur deux tâches ne permettent pas d’estimer les performances sur l’ensemble du benchmark.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

Python 3.12 ou version ultérieure, Git et le gestionnaire de paquets uv.
Un jeton d’accès à l’API CoreWeave disposant du rôle Sandbox User dans une organisation où les bacs à sable sans serveur sont activés.
Une clé API Forge donnant accès au modèle d’exemple sur Serverless Inference.
Un accès réseau depuis votre machine locale vers l’API Sandboxes et https://api.inference.wandb.ai/v1.

Chaque tâche demande 2 CPU et 8 Gio de mémoire. Par défaut, les tâches s’exécutent séquentiellement, dans des bacs à sable distincts pour l’agent et le vérificateur. Aucun GPU ni aucune installation locale de Docker n’est nécessaire. L’adaptateur applique les paramètres de CPU et de mémoire de la tâche, mais ignore son paramètre storage_mb. Vérifiez quel compte est facturé pour l’utilisation des bacs à sable ainsi que les tarifs d’inférence. Les limites d’étapes et la durée maximale encadrent l’exécution, mais ne plafonnent pas les dépenses.

Installer la recette

Clonez le dépôt des recettes et installez ses dépendances verrouillées :

git clone https://github.com/coreweave/cwsandbox-recipes.git
cd cwsandbox-recipes/recipes/deepswe
uv sync --locked

La recette fixe les versions de Pier (0.3.1), de mini-swe-agent (2.2.6) et de cwsandbox (1.14.2). Exécutez les commandes suivantes depuis le répertoire recipes/deepswe. Pour que les images des tâches et la structure du vérificateur correspondent à l’adaptateur, récupérez la révision testée de DeepSWE :

git clone https://github.com/datacurve-ai/deep-swe.git
git -C deep-swe checkout 0b9fabbb63b9104d678fe965e1632f2dd9eaa2ea

Configurer le modèle d’exemple et les identifiants d’authentification

Dans le terminal où vous exécutez la recette, définissez les deux identifiants d’authentification. Remplacez [API-ACCESS-TOKEN] par votre jeton d’accès à l’API CoreWeave et [FORGE-API-KEY] par votre clé API Forge, ou exportez-les depuis votre gestionnaire de secrets :

export CWSANDBOX_API_KEY="[API-ACCESS-TOKEN]"
export FORGE_API_KEY="[FORGE-API-KEY]"
export MSWEA_MODEL_RETRY_STOP_AFTER_ATTEMPT=3
export MSWEA_SILENT_STARTUP=1

La recette sélectionne explicitement l’authentification CoreWeave pour les bacs à sable. Configurez votre copie locale afin qu’elle lise FORGE_API_KEY pour l’inférence ; la recette en amont ne reconnaît pas cette variable automatiquement. Dans run.py, remplacez la vérification des identifiants d’authentification dans parse_args() par :

for key in ["CWSANDBOX_API_KEY"] + (
    ["FORGE_API_KEY"] if args.agent == "mini" else []
):
    if not os.environ.get(key):
        parser.error(f"Set {key} in the environment")

Dans host_agent.py, remplacez l’attribution de la clé d’inférence au début de HostMiniSweAgent.run() par :

os.environ["OPENAI_API_KEY"] = os.environ["FORGE_API_KEY"]

OPENAI_API_KEY est la variable qu’utilise LiteLLM pour ce point de terminaison compatible avec OpenAI. L’identifiant d’authentification reste ainsi dans la mémoire du processus au lieu de figurer dans la configuration du modèle sérialisée. La recette lit les variables dans l’environnement de votre processus et ne charge pas automatiquement le fichier .env d’un projet. Avant de créer une sandbox, vérifiez l’accès au modèle :

uv run --locked python - <<'PY'
import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.inference.wandb.ai/v1",
    api_key=os.environ["FORGE_API_KEY"],
    timeout=60,
)
response = client.chat.completions.create(
    model="moonshotai/Kimi-K2.7-Code",
    messages=[{"role": "user", "content": "Respond with exactly OK."}],
    max_tokens=64,
)
print(response.choices[0].message.content)
PY

Une requête réussie renvoie une réponse courte, par exemple OK. Avant de lancer l’exemple, corrigez toute erreur d’authentification, d’accès au modèle ou de crédits.

Exécuter un exemple

Pour vérifier une première fois l’intégration, exécutez une tâche Python :

uv run --locked python run.py \
  --tasks deep-swe/tasks \
  --task tomlkit-toml-table-converters \
  --steps 160 --agent-timeout 1800 \
  --job-name kimi-smoke

Un run comportant une seule tâche peut malgré tout consommer l’essentiel du budget d’étapes ou de temps. Ce run sert à vérifier l’intégration, et sa réussite n’exige pas que le modèle résolve la tâche. Pour élargir l’échantillon, exécutez une tâche Go et une tâche Python sous un nouveau nom de tâche :

uv run --locked python run.py \
  --tasks deep-swe/tasks \
  --task abs-stepped-slices \
  --task tomlkit-toml-table-converters \
  --steps 160 --agent-timeout 1800 \
  --job-name kimi-sample

La recette indique la création du sandbox, les étapes du modèle effectuées et l’arrêt du sandbox. Chaque tâche est limitée à 160 étapes de l’agent et à un délai d’expiration de l’agent de 30 minutes. Les commandes shell ont un délai d’expiration de 120 secondes. Lorsqu’une commande dépasse son délai d’expiration, l’agent reçoit une observation qui lui permet de poursuivre. Le hook de collecte de la tâche extrait la différence entre son commit de base et la référence HEAD. L’agent doit valider (commit) ses modifications pour qu’elles apparaissent dans le patch soumis. Les modifications non validées ne sont pas collectées. Pour un nouveau run, utilisez un nouveau nom de tâche. Comme Pier peut reprendre un répertoire de tâche existant, réutiliser le nom de tâche kimi-sample ne relance pas une exécution à partir de zéro. Pour un échantillonnage aléatoire déterministe et les autres options de la recette, consultez le README de la recette.

Configurer la simultanéité et les nouvelles tentatives

Pier gère la file d’attente des essais de la recette. Utilisez --concurrency pour définir le nombre maximum d’essais simultanés. La valeur par défaut est 1. Vérifiez l’ensemble du flux de travail avec ce paramètre. Augmentez ensuite progressivement la simultanéité dans les limites du quota inclus de votre fournisseur d’inférence, en tenant compte des requêtes émises par d’autres tâches qui utilisent le même compte. La réussite de la vérification de l’accès au modèle ne garantit pas une capacité suffisante pour traiter des requêtes simultanées. Par défaut, la recette utilise --max-retries 2. Après une erreur RateLimitError, APIConnectionError ou ServiceUnavailableError, Pier peut redémarrer un essai jusqu’à deux fois. Pier attend 30 secondes avant la première nouvelle tentative et 60 secondes avant la seconde. Chaque nouvelle tentative lance une nouvelle exécution de l’agent et peut entraîner des frais supplémentaires. Les limites d’étapes et de temps d’agent s’appliquent séparément à chaque exécution. Les nouvelles tentatives créent de nouveaux bacs à sable ; leur nombre total peut donc dépasser la limite d’essais simultanés. Les erreurs d’authentification, les échecs de démarrage de sandbox tels que SandboxFailedError, les autres exceptions non listées et les scores faibles du vérificateur ne déclenchent pas de nouvelle tentative automatique. Pour désactiver les nouvelles tentatives d’essai, définissez --max-retries 0. La recette conserve les tentatives infructueuses dans jobs/[JOB-NAME]/failed-attempts/[TRIAL-NAME]/[ATTEMPT-ID]/ avant que Pier ne remplace les répertoires d’essai correspondants. Le répertoire d’essai habituel et la synthèse de la tâche contiennent le résultat de la dernière exécution. Pour obtenir une commande d’exécution en parallèle, consultez les paramètres de simultanéité et de nouvelles tentatives de la recette.

Gérer la limitation du débit d’inférence

Une réponse HTTP 429 contenant rate_limit_exceeded et concurrency limit reached for requests signifie que le fournisseur d’inférence a rejeté une requête adressée au modèle. Forge applique des limites par projet et par utilisateur. Réduisez --concurrency ainsi que les requêtes simultanées au modèle émises par d’autres tâches qui utilisent le même compte d’inférence. Pour obtenir une limite plus élevée, contactez l’assistance en suivant la documentation sur les limites d’inférence. Avec le paramètre MSWEA_MODEL_RETRY_STOP_AFTER_ATTEMPT=3 de l’exemple, mini-swe-agent effectue jusqu’à trois tentatives par requête au modèle ayant échoué, tentative initiale comprise. Si une requête aboutit, ces nouvelles tentatives poursuivent la même conversation. Le client du modèle peut également effectuer ses propres nouvelles tentatives au sein d’une même tentative. Si les nouvelles tentatives de requête sont épuisées sur une exception éligible, Pier applique la politique de nouvelle tentative des essais. Pier 0.3.1 limite les essais dans leur globalité. La recette ne prévoit ni limite de concurrence distincte pour les requêtes d’inférence ni ajustement automatique de la concurrence. Augmenter le nombre de nouvelles tentatives ne suffit pas à résoudre une surcharge prolongée. Au sein d’une même tâche, certains essais limités peuvent aboutir tandis que d’autres épuisent leurs nouvelles tentatives. Ces derniers conservent leur exception finale, et la recette se termine avec un statut non nul. Ils ne sont pas ignorés silencieusement. Une fois la limitation persistante résolue, relancez uniquement les tâches concernées avec une concurrence plus faible et un nouveau nom de tâche. Si une nouvelle tentative se termine par une autre erreur, examinez également le répertoire failed-attempts/. La limitation du débit d’inférence et les échecs de démarrage de la sandbox doivent être diagnostiqués séparément. Pour les commandes et la récupération de tâches intégrée à Pier, filtrée par erreur, suivez la procédure de récupération après limitation de la recette.

Inspecter les résultats

Les exemples suivants examinent la tâche à deux sous-tâches. Pour le run à une seule sous-tâche, remplacez kimi-sample par kimi-smoke. Lisez la synthèse de la tâche :

uv run --locked python -m json.tool jobs/kimi-sample/result.json

stats.n_completed_trials compte les essais terminés, y compris ceux en erreur. stats.n_retries compte les exécutions d’essai supplémentaires, et non des échantillons de benchmark supplémentaires. Un essai récupéré peut comporter des erreurs archivées alors que son résultat final ne présente aucune exception. Avant d’interpréter le score agrégé de la tâche, vérifiez stats.n_errored_trials ainsi que les valeurs finales exception_info et verifier_result de chaque essai. La moyenne agrégée peut valoir 0 lorsque la vérification n’a pas pu démarrer et qu’aucun patch n’a été évalué. Un essai dont la récompense binaire du vérificateur vaut 0 ou 1 et qui ne présente aucune exception a mené le flux de travail à son terme. Une récompense de 1 signifie que toutes les vérifications requises ont réussi. Une récompense de 0 signifie que le patch n’a pas satisfait à toutes les vérifications requises. Une exception, une récompense manquante ou une récompense de -1 constitue une erreur de run. Analysez les erreurs de run indépendamment des performances du modèle. Chaque répertoire d’essai sous jobs/kimi-sample/ contient :

Fichier	Contenu
`result.json`	Statut de l’essai, durées, nombres de jetons et résultat du vérificateur
`agent/mini.trajectory.json`	Conversation du modèle et actions shell
`artifacts/model.patch`	Patch généré à partir des commits de l’agent
`verifier/reward.json`	Récompense binaire et scores partiels
`verifier/ctrf.json`	Résultats de tests structurés
`verifier/test-stdout.txt`	Sortie du vérificateur

Examinez les résultats des tests réservés, même si l’agent indique que ses propres tests ont réussi. Dans reward.json, f2p_passed et f2p_total comptent les vérifications portant sur le nouveau comportement, tandis que p2p_passed et p2p_total comptent les vérifications existantes. Un score partial élevé peut tout à fait coexister avec une reward binaire de 0 lorsqu’une vérification requise échoue. Les nombres de jetons enregistrés peuvent être incomplets. Dans cet adaptateur, une réponse rejetée faute d’appels d’outils peut consommer des jetons sans que son utilisation soit conservée dans la trajectoire. Considérez les coûts calculés à partir de ces nombres comme des estimations partielles et reportez-vous à la facturation du fournisseur pour connaître les montants réels. Les requêtes préalables et les frais de sandbox sont facturés séparément. Si l’agent a soumis un patch mais que le démarrage du vérificateur a échoué, conservez artifacts/model.patch et le résultat d’erreur original. La recette ne propose aucune commande prise en charge permettant de relancer uniquement le vérificateur. Un nouveau run du modèle produit une nouvelle tentative, et non une réévaluation du patch enregistré. Toute réévaluation distincte doit utiliser le patch inchangé et la révision de tâche correspondante, et conserver son propre résultat. Pour contrôler le vérificateur de manière indépendante, suivez les contrôles sans modification et avec solution de référence décrits dans la recette. Ces contrôles n’appellent pas le modèle et doivent rester séparés des résultats du modèle.

Nettoyage

Pier arrête les sandboxes de l’agent et du vérificateur lorsqu’elles se terminent normalement, ainsi que lors du nettoyage en cas d’erreur. Chaque sandbox dispose en outre d’une durée de vie maximale de 90 minutes. Si vous avez besoin des patchs, des trajectoires ou des rapports de test, conservez le répertoire de la tâche. Si le processus d’évaluation local est interrompu avant la fin du nettoyage, arrêtez toute sandbox encore active. Remplacez [SANDBOX-ID] par l’ID de la sandbox indiqué dans les journaux du run :

uv run --locked python - <<'PY'
from cwsandbox import AuthStrategy, Sandbox

sandbox = Sandbox.from_id(
    "[SANDBOX-ID]", auth=AuthStrategy.COREWEAVE_API_KEY
).result()
sandbox.stop(missing_ok=True).result()
PY

La recette ne crée ni déploiement GPU, ni point de terminaison de modèle, ni volume persistant.

Résolution des problèmes

Symptôme	Action
Erreur d’authentification ou d’autorisation lors de l’inférence	Vérifiez la clé API Forge, l’accès au modèle et les crédits d’inférence. L’authentification de la sandbox est gérée séparément.
Erreur HTTP `429` ou `RateLimitError` lors de l’inférence	Lisez le message d’erreur du fournisseur. Pour les erreurs de concurrence, suivez la procédure Gérer la limitation de l’inférence. Lorsque toutes les nouvelles tentatives sont épuisées, il s’agit d’une erreur du run, et non d’un score du modèle.
La sandbox échoue avant une étape du modèle ou un résultat du vérificateur	Consultez le statut de la sandbox pour repérer un échec de récupération de l’image ou un manque de capacité. Conservez les artifacts de la tâche et corrigez l’erreur d’infrastructure avant de relancer.
`Unsupported verifier Dockerfile`	Utilisez la révision épinglée du dataset et les tâches d’exemple prises en charge. Toute autre structure de vérificateur nécessite de modifier l’adaptateur.
Fichier `model.patch` vide	Vérifiez que l’agent a bien commité ses modifications avant d’atteindre sa limite.
L’agent atteint sa limite d’étapes ou sa durée maximale	Examinez la trajectoire enregistrée et l’utilisation des jetons avant d’augmenter les valeurs de `--steps` ou `--agent-timeout`.
L’installation des dépendances échoue dans la sandbox	L’accès réseau sortant est bloqué. Utilisez les dépendances préinstallées de la tâche ou examinez l’image de la tâche.

Étapes suivantes

Pour plus d’informations, consultez les ressources suivantes :

Aperçu des évaluations : choisissez un flux de travail d’évaluation et dissociez l’inférence du modèle de l’exécution du benchmark.
Recette DeepSWE : examinez l’adaptateur, les tests et les options d’échantillonnage.
Évaluation SWE-bench : évaluez des patchs existants sur un autre benchmark.
Modèles de nettoyage : gérez le cycle de vie des sandboxes dans vos propres applications.

Sandbox

Utiliser les Sandbox

Gérer les bacs à sable

Référence

Exécuter des évaluations DeepSWE v1.1

Prérequis

Installer la recette

Configurer le modèle d’exemple et les identifiants d’authentification

Exécuter un exemple

Configurer la simultanéité et les nouvelles tentatives

Gérer la limitation du débit d’inférence

Inspecter les résultats

Nettoyage

Résolution des problèmes

Étapes suivantes

​Prérequis

​Installer la recette

​Configurer le modèle d’exemple et les identifiants d’authentification

​Exécuter un exemple

​Configurer la simultanéité et les nouvelles tentatives

​Gérer la limitation du débit d’inférence

​Inspecter les résultats

​Nettoyage

​Résolution des problèmes

​Étapes suivantes

Prérequis

Installer la recette

Configurer le modèle d’exemple et les identifiants d’authentification

Exécuter un exemple

Configurer la simultanéité et les nouvelles tentatives

Gérer la limitation du débit d’inférence

Inspecter les résultats

Nettoyage

Résolution des problèmes

Étapes suivantes