Snorkel exécute des millions de simulations d'agents par mois et économise 20 % sur les sandboxes

Évaluer des agents n'a rien à voir avec évaluer un chatbot. Le modèle ne se contente pas de répondre à une question : il ouvre un terminal, installe des paquets, lance un entraînement, casse et répare des services. Pour savoir ce qu'il vaut, il faut lui donner un véritable poste de travail. C'est le sujet du cas Snorkel — un laboratoire de données qui crée des datasets et des benchmarks pour des laboratoires de pointe et des grandes entreprises. Il participe notamment à Terminal-Bench.

Pourquoi l'agent a besoin d'un environnement réaliste

Le problème est connu de tous ceux qui ont fait tourner des évaluations d'agents. L'agent a échoué à la tâche, mais pourquoi ? Le modèle n'a-t-il pas su faire, ou n'avait-il simplement pas l'outil nécessaire ? Si l'environnement est amputé, le benchmark ne mesure pas les capacités du modèle, mais les limites de votre infrastructure.

Les tâches chez Snorkel sont variées : code, infrastructure, ingénierie ML. Un agent ML a besoin d'un GPU pour entraîner un modèle. Un agent d'infrastructure peut avoir besoin d'un noyau Linux entier et de plusieurs conteneurs. C'est pourquoi l'équipe exécute ses simulations dans des sandboxes Modal, y compris des sandboxes VM avec des systèmes multiservices et de la charge GPU. Un seul fournisseur pour le GPU et le CPU simplifie à la fois l'infrastructure et le suivi des coûts. D'après Snorkel, c'est seulement chez Modal qu'elle a trouvé des sandboxes GPU à l'échelle voulue.

L'échelle est la suivante : des millions de sandboxes par mois, avec des pics de plusieurs dizaines de milliers par heure. Ce n'est pas un caprice. Quand un nouveau modèle sort ou qu'un ancien est affiné, le client veut savoir en moins d'une journée s'il convient à son cas d'usage. Il faut donc lancer rapidement de nombreuses exécutions parallèles sur un mélange de benchmarks publics et privés.

Pourquoi les ressources d'un agent sont si difficiles à estimer

Auparavant, l'équipe estimait à l'avance le CPU et la mémoire de chaque sandbox. Le résultat était mauvais dans les deux sens. Si l'on en donne trop peu, l'agent plante faute de ressources et l'exécution est invalide : ce n'est pas une erreur du modèle, mais du bruit dans la métrique. Si l'on prend trop de précautions, on paie pour du matériel inactif.

Deviner est difficile pour deux raisons. D'abord, la charge est irrégulière. L'agent attend la réponse du LLM, la consommation est quasi nulle, puis il lance, par exemple, un grep sur un gros dépôt — et c'est le pic. Ensuite, tout le code dans la sandbox est écrit par le modèle lui-même, et les benchmarks sont nombreux : le profil de charge est donc inconnu à l'avance.

La solution est le bursting dans Modal. La sandbox étend à la volée sa mémoire ou son CPU quand c'est nécessaire. On paie la consommation réelle ou le minimum déclaré, selon le plus élevé des deux. Cela a permis de demander moins de ressources sans subir de plantages. Snorkel évoque une économie d'environ 20 % sur la facture globale des sandboxes, et le nombre d'exécutions échouées à cause des limites a diminué.

Réserve : pour l'instant, seules 10 à 15 % des sandboxes de Snorkel utilisent le bursting. Le chiffre de 20 % est une estimation de l'entreprise elle-même, dans un cas publié par un fournisseur. Considérez-le comme un repère, pas comme une garantie pour votre charge.

L'inférence pour le benchmark

La seconde moitié du problème, ce sont les modèles eux-mêmes. Pour les premières vérifications de nouveaux modèles open-weight, Snorkel utilise un endpoint partagé prêt à l'emploi. Si l'on a besoin d'un modèle affiné par le client, l'équipe le déploie avec des poids personnalisés sur un endpoint dédié. Détail important : tout cela se fait sans l'intervention de l'équipe infrastructure. On lance le modèle, on exécute le benchmark, on referme.

Parmi les projets : évaluer Modal également pour l'entraînement, afin de boucler le cycle « données → entraînement → évaluation » sur une seule plateforme.

Ce qu'il faut retenir

• Si vous construisez des évaluations d'agents, distinguez « l'agent n'a pas réussi » de « l'environnement ne l'a pas permis ». Consignez les causes des échecs et comptez séparément les défaillances liées aux ressources.
• Ne dimensionnez pas les ressources au hasard, ni sur la moyenne, ni sur le maximum. Mesurez les pics de CPU et de mémoire sur un échantillon d'exécutions (Snorkel a construit un tel graphique sur 5 000 sandboxes) et envisagez des limites élastiques.
• Si les agents ont besoin d'un GPU dans la sandbox, vérifiez que le fournisseur le fournit à l'échelle voulue avant de concevoir le benchmark.
• Si le client attend une réponse sous 24 heures, ce n'est pas la vitesse moyenne qui compte, mais le parallélisme de pointe.

Dans l'ensemble, il ne s'agit pas d'une percée technologique, mais d'une analyse d'ingénierie soignée de ce à quoi ressemble l'infrastructure appliquée à l'évaluation d'agents. Principale conclusion : une métrique d'agent honnête dépend non seulement du modèle, mais aussi de la justesse avec laquelle vous lui avez alloué les ressources.