> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Exécuter des évaluations DeepSWE v1.1

> Générez des patchs de code et notez-les dans des bacs à sable distincts avec un petit échantillon DeepSWE v1.1.

Évaluez un agent de développement sur un petit échantillon de [DeepSWE](https://github.com/datacurve-ai/deep-swe) 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](https://github.com/SWE-agent/mini-swe-agent) sur votre machine locale et envoie ses commandes shell à une sandbox sans serveur. Une fois que l’agent a terminé, [Pier](https://pypi.org/project/datacurve-pier/0.3.1/), 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](https://docs.wandb.ai/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.

<Note>
  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.
</Note>

<h2 id="prerequisites">
  Prérequis
</h2>

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`](https://docs.astral.sh/uv/getting-started/installation/).
* Un [jeton d’accès à l’API CoreWeave](/fr/products/sandboxes/placement#coreweave-api-access-token) disposant du rôle Sandbox User dans une organisation où les bacs à sable sans serveur sont activés.
* Une [clé API Forge](https://wandb.ai/authorize) 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](/fr/products/sandboxes/placement#choose-and-get-credentials) ainsi que les [tarifs d’inférence](https://docs.wandb.ai/inference/usage-limits/). Les limites d’étapes et la durée maximale encadrent l’exécution, mais ne plafonnent pas les dépenses.

<h2 id="install-the-recipe">
  Installer la recette
</h2>

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

```bash theme={"system"}
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 :

```bash theme={"system"}
git clone https://github.com/datacurve-ai/deep-swe.git
git -C deep-swe checkout 0b9fabbb63b9104d678fe965e1632f2dd9eaa2ea
```

<h2 id="configure-the-example-model-and-credentials">
  Configurer le modèle d’exemple et les identifiants d’authentification
</h2>

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 :

```bash theme={"system"}
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 :

```python theme={"system"}
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 :

```python theme={"system"}
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 :

```bash theme={"system"}
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.

<h2 id="run-a-sample">
  Exécuter un exemple
</h2>

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

```bash theme={"system"}
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 :

```bash theme={"system"}
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](https://github.com/coreweave/cwsandbox-recipes/blob/main/recipes/deepswe/README.md).

<h3 id="configure-concurrency-and-retries">
  Configurer la simultanéité et les nouvelles tentatives
</h3>

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](https://github.com/coreweave/cwsandbox-recipes/blob/main/recipes/deepswe/README.md#configure-concurrency-and-retries) de la recette.

<h3 id="handle-inference-throttling">
  Gérer la limitation du débit d’inférence
</h3>

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](https://docs.wandb.ai/inference/usage-limits/#concurrency-limits).

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](https://github.com/coreweave/cwsandbox-recipes/blob/main/recipes/deepswe/README.md#recover-from-inference-throttling) de la recette.

<h2 id="inspect-the-results">
  Inspecter les résultats
</h2>

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 :

```bash theme={"system"}
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](https://github.com/coreweave/cwsandbox-recipes/blob/main/recipes/deepswe/README.md#4-inspect-the-results) 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.

<h2 id="clean-up">
  Nettoyage
</h2>

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 :

```bash theme={"system"}
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.

<h2 id="troubleshooting">
  Résolution des problèmes
</h2>

| 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](#handle-inference-throttling). 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. |

<h2 id="next-steps">
  Étapes suivantes
</h2>

Pour plus d'informations, consultez les ressources suivantes :

* [Aperçu des évaluations](/fr/products/sandboxes/evals) : choisissez un flux de travail d'évaluation et dissociez l'inférence du modèle de l'exécution du benchmark.
* [Recette DeepSWE](https://github.com/coreweave/cwsandbox-recipes/tree/main/recipes/deepswe) : examinez l'adaptateur, les tests et les options d'échantillonnage.
* [Évaluation SWE-bench](/fr/products/sandboxes/client/guides/swebench) : évaluez des patchs existants sur un autre benchmark.
* [Modèles de nettoyage](/fr/products/sandboxes/client/guides/cleanup-patterns) : gérez le cycle de vie des sandboxes dans vos propres applications.