Skip to main content
Exécutez AutomationBench dans des sandboxes CPU afin d’évaluer un modèle capable d’appeler des outils sur des flux de travail d’entreprise simulés. Ce tutoriel s’appuie sur Harbor pour planifier les tâches indépendamment les unes des autres, relancer certaines défaillances d’infrastructure et conserver les résultats. Commencez par une seule tâche, puis augmentez la simultanéité dans la limite de vos quotas de sandbox et d’inférence. L’exemple utilise CoreWeave Serverless Inference. Pour évaluer un autre modèle, il vous suffit de modifier le point de terminaison Chat Completions compatible avec OpenAI, l’ID du modèle et la clé d’inférence.

​
Flux de travail d’évaluation

La recette AutomationBench exécute Harbor sur votre machine locale. Chaque essai dispose d’une sandbox CPU dans laquelle AutomationBench installe sa boucle d’agent, ses applications simulées et son évaluateur fondé sur des assertions. Le modèle s’exécute sur votre point de terminaison d’inférence. La sandbox ne nécessite ni GPU ni identifiants d’authentification d’applications réelles. La recette implémente les interfaces BaseAgent et BaseEnvironment de Harbor et s’appuie sur des appels publics du kit de développement logiciel (SDK) CoreWeave Sandboxes. Elle exécute l’évaluateur natif auto-bench tel quel et ne nécessite aucun adaptateur Harbor pour AutomationBench en amont. Les versions de Harbor, d’AutomationBench et du SDK cwsandbox sont épinglées dans la recette.

​
Prérequis

Avant de commencer, préparez les éléments suivants :
  • uv et Git sur votre machine locale. La recette nécessite Python 3.13 ou une version ultérieure. Si Python n’est pas installé, uv télécharge une version compatible.
  • Un jeton d’accès à l’API CoreWeave disposant d’un accès aux sandbox.
  • Un quota de sandbox simultanées suffisant pour le niveau de simultanéité choisi, ainsi que des stratégies de ressources autorisant 2 vCPU et 4 Gio de mémoire par sandbox.
  • Un point de terminaison d’inférence prenant en charge l’appel d’outils, une clé API et un quota d’inférence suffisant. Pour cet exemple, créez une clé API Serverless Inference.
  • Un accès réseau depuis votre machine vers l’API des sandbox et les dépôts de paquets, ainsi que depuis les sandbox vers GitHub, les dépôts de paquets Debian et Python, et votre point de terminaison d’inférence.
La vérification initiale crée une sandbox CPU. Les ressources des sandbox et l’inférence sont facturées séparément. Avant d’étendre l’évaluation à plus grande échelle, consultez la tarification des sandbox ainsi que les limites d’utilisation et la tarification de votre fournisseur d’inférence.

​
Installer la recette

Clonez le dépôt des recettes et installez les dépendances aux versions figées :
Exécutez les commandes suivantes depuis le répertoire de cette recette. L’environnement local contient Harbor et le SDK Sandbox. Chaque sandbox installe AutomationBench à partir de son checkout épinglé, en s’appuyant sur le lockfile figé du benchmark.

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

Chargez les identifiants d’authentification depuis votre gestionnaire de secrets dans l’environnement du processus. Définissez CWSANDBOX_API_KEY sur votre identifiant d’authentification de sandbox CoreWeave, et MODEL_API_KEY sur votre identifiant d’authentification d’inférence. N’enregistrez pas de clés dans le fichier .env. Dans le fichier .env, définissez uniquement le point de terminaison du modèle, le nom du modèle et, éventuellement, le projet. Pour l’exemple Serverless Inference, utilisez les paramètres suivants. Remplacez [WANDB-TEAM] et [WANDB-PROJECT] par des noms auxquels vous avez accès :
MODEL_PROJECT définit l’en-tête OpenAI-Project pour le suivi de l’utilisation de Serverless Inference. L’ID du modèle est donné à titre d’exemple et n’a rien d’obligatoire. Choisissez un modèle compatible avec l’appel d’outils parmi les modèles disponibles. Si vous utilisez un autre fournisseur compatible ou un modèle que vous servez vous-même, remplacez les paramètres du modèle dans le fichier .env. Remplacez [INFERENCE-HOST] et [MODEL-ID] par les valeurs de votre fournisseur :
Chargez la clé de ce fournisseur dans MODEL_API_KEY dans l’environnement du processus, sans retirer la définition de CWSANDBOX_API_KEY. Si le fournisseur n’utilise pas l’en-tête de projet, supprimez MODEL_PROJECT du fichier .env et annulez la définition de toute variable d’environnement MODEL_PROJECT héritée avant d’exécuter la commande. Le point de terminaison doit être accessible depuis la sandbox. localhost désigne la sandbox elle-même, et non votre machine. Pour les autres protocoles d’API, vous devez adapter les options de l’évaluateur natif. La recette utilise explicitement l’authentification CoreWeave pour les opérations sur la sandbox. Le jeton de la sandbox reste sur l’hôte. Seules la configuration du modèle et la clé d’inférence sont injectées dans la sandbox lors de sa création. La configuration de la tâche ne contient aucun identifiant d’authentification. Pour des conseils plus généraux sur la gestion des identifiants d’authentification, consultez variables d’environnement et secrets. Protégez les journaux et les traces téléchargés, car ils peuvent contenir des données de tâche et des messages d’erreur du fournisseur.

​
Lancer une vérification de la configuration

Évaluez une tâche simple avec une seule sandbox :
Le répertoire de sortie ne doit pas déjà exister. Harbor démarre la sandbox, installe AutomationBench, exécute la tâche, récupère les résultats, puis supprime la sandbox. Une fois la tâche terminée, la sortie suivante s’affiche :
Consultez le fichier results-smoke/job-result.json pour connaître le nombre d’essais terminés et en erreur. Un code de sortie nul signifie qu’aucun essai n’est en erreur ni manquant, et non que le modèle a satisfait les assertions de la tâche. L’export natif agent/automationbench.json enregistre passed, score, les durées et l’utilisation des jetons. Le vérificateur associe passed et score à des récompenses Harbor nommées pass et partial_credit. Dans job-result.json, l’entrée stats.evals indique sous metrics la moyenne de chaque récompense sur l’ensemble des essais. Les essais sans récompense comptent pour zéro. reward_stats liste les essais pour chaque valeur de récompense. L’agent utilise l’ensemble d’outils api, un maximum de 50 étapes de réponse, une tâche à la fois par sandbox et le paramètre de raisonnement par défaut du fournisseur. L’autoréparation native à l’échelle de la tâche entière est désactivée afin que Harbor gère les nouvelles tentatives d’essais. Le client du modèle peut néanmoins relancer en interne des requêtes individuelles.

​
Augmenter le parallélisme

Une fois la vérification de la configuration réussie, commencez par un petit sous-ensemble :
Chaque essai requiert 2 vCPU et 4 Gio de mémoire ; quatre essais simultanés requièrent donc jusqu’à 8 vCPU et 16 Gio. Harbor affecte chaque tâche indépendamment : dès qu’une tâche se termine, une autre peut prendre sa place. La configuration propre à chaque tâche entraîne une surcharge, car chaque sandbox installe l’évaluateur. La recette inclut deux listes de tâches pour la révision épinglée du benchmark : Pour évaluer l’ensemble noté, sélectionnez sa liste de tâches et un niveau de simultanéité compatible avec vos quotas :
Seize essais simultanés demandent au total jusqu’à 32 vCPU et 64 Gio. Il s’agit d’un exemple de configuration, et non d’un objectif de débit validé. Augmentez la simultanéité progressivement et surveillez les limites d’inférence ainsi que la capacité des sandboxes. Exécutez les tâches de référence en écrivant leurs résultats dans un répertoire de sortie distinct. N’incluez pas les 200 tâches simples dans le dénominateur de l’ensemble évalué. Ces tâches sont publiques. Le leaderboard officiel d’AutomationBench s’appuie sur un ensemble distinct de tâches privées ; les scores ne sont donc pas directement comparables.

​
Nouvelles tentatives en cas d’échecs liés à la capacité et aux limites d’inférence

La recette configure le RetryConfig de Harbor pour autoriser cinq nouvelles tentatives après la tentative originale, avec des délais d’attente de 30, 60, 120, 240 et 300 secondes. La liste d’autorisation des nouvelles tentatives inclut les exceptions suivantes :
  • SandboxResourceExhaustedError
  • SandboxUnavailableError
  • SandboxRequestTimeoutError
  • EnvironmentStartTimeoutError
  • ApiRateLimitError
  • ApiUsageLimitError
Par défaut, Harbor exclut ApiUsageLimitError. La recette la retire de cet ensemble d’exclusions et l’ajoute à la liste d’autorisation. L’adaptateur fait correspondre les messages d’erreur terminale reconnus de l’évaluateur natif, relatifs aux quotas d’inférence et aux rate-limits, aux exceptions Harbor correspondantes. Ce mappage dépend du texte d’erreur du fournisseur. Consultez les journaux si un fournisseur renvoie un format différent. En cas d’épuisement persistant de la capacité ou des crédits, il faut toujours attendre que de la capacité ou des crédits redeviennent disponibles. Si des erreurs subsistent après les nouvelles tentatives, le script se termine avec un code de sortie non nul et conserve la dernière erreur. Les échecs d’assertion ordinaires, les refus, le JSON d’appel d’outil mal formé et les délais d’expiration d’exécution de l’agent ne déclenchent pas la politique de nouvelles tentatives. Harbor supprime les répertoires des essais échoués avant de relancer. Le hook de fin d’essai de la recette archive au préalable chaque tentative, y compris son résultat et les journaux disponibles. Conservez ces tentatives et signalez toute récupération d’infrastructure lorsque vous publiez des scores. Ne remplacez pas discrètement les échecs du modèle par de meilleurs résultats obtenus lors de nouvelles tentatives.

​
Inspecter les résultats et les essais lents

Chaque répertoire de sortie contient les artifacts suivants : Utilisez les exports natifs pour connaître la durée des tâches et l’utilisation des jetons. L’adaptateur ne renseigne pas les champs agrégés de jetons et de coût de l’agent dans Harbor. Consignez avec les résultats le modèle, le point de terminaison, la révision du benchmark, la liste des tâches, les paramètres de raisonnement, la concurrence et la politique de nouvelles tentatives. Si vous arrêtez un run, ne présentez comme évaluations terminées que les tâches exportées et signalez que les résultats sont partiels. Le temps de réponse du modèle peut représenter l’essentiel de la durée d’une tâche, même avec peu d’étapes ou de jetons de sortie. Comparez model_time_s à tool_time_s et examinez le fichier agent/eval.log avant d’imputer des retards aux ressources de la sandbox. Si le fournisseur rejette un JSON d’appel d’outil mal formé, il s’agit d’une défaillance du modèle ou du protocole, et non d’un signe d’épuisement du quota de sandboxes. AutomationBench répertorie les enregistrements de session interrompus en cours de tour de conversation dans le champ summary.aborted_tasks de l’export. Leurs tableaux errors par tâche peuvent être vides : vérifiez donc ce champ et les journaux, en plus des erreurs des tâches. La configuration est soumise à un délai d’expiration de 11 minutes. L’exécution de l’agent dispose d’un délai d’expiration distinct de 45 minutes, au sein duquel la commande d’évaluation native dispose de son propre délai de 40 minutes. Chaque sandbox est soumise à un plafond de durée de vie d’une heure, qui y met fin même si aucun délai d’expiration n’est écoulé. Cette politique ne prévoit pas de nouvelle tentative lorsque l’exécution de l’agent dépasse son délai d’expiration.

​
Arrêter et nettoyer

Pour arrêter un run au premier plan, appuyez sur Ctrl+C et laissez Harbor se fermer. La tâche définit delete=True pour la suppression des ressources. Si le processus est arrêté de force ou si le nettoyage échoue, arrêtez l’exécuteur local avant de supprimer les bacs à sable restants, afin qu’il ne puisse pas en recréer de nouveaux. Une fois l’exécuteur arrêté, utilisez son répertoire de sortie pour vérifier le nettoyage :
Remplacez results-smoke par le répertoire de la tâche que vous avez arrêtée. Le script supprime uniquement les ID de sandbox enregistrés et affiche leurs états terminaux. Une sandbox déjà absente est signalée comme not_found. Examinez tout code de sortie non nul, qui signale un échec de la suppression ou de la vérification de l’état terminal. Si le processus hôte disparaît, le plafond de durée de vie configuré borne également la durée de vie de la sandbox.

​
Portée de la validation

Pendant le développement de la recette, l’évaluateur natif a exporté les résultats de 730 des 800 tâches publiques sur huit sandboxes CPU en parallèle, avec openai/gpt-oss-120b sur Serverless Inference. Ce run a été arrêté avant son achèvement : ses résultats ne constituent donc pas un score de benchmark. L’ordonnancement des nouvelles tentatives de Harbor a été vérifié séparément : une erreur SandboxResourceExhaustedError injectée, un délai d’attente de 30 secondes, puis une tâche réelle qui s’est achevée, a exporté ses résultats et a été nettoyée. La recette remplace les hooks d’environnement de l’expérience initiale par une implémentation de BaseEnvironment qui s’appuie sur des appels du SDK public. Cette refactorisation est couverte par des tests hors ligne, mais n’a pas encore été exécutée sur le service réel. L’exécution d’un dataset complet avec une concurrence Harbor élevée n’a pas été validée. Pour les tests hors ligne et une vérification contrôlée facultative des nouvelles tentatives, consultez le README de la recette.
Dernière modification le 15 octobre 2026