Snorkel ejecuta millones de simulaciones de agentes al mes y ahorra un 20 % en sandboxes

Evaluar agentes no es lo mismo que evaluar un chatbot. El modelo no se limita a responder una pregunta: abre una terminal, instala paquetes, lanza entrenamientos, y rompe y repara servicios. Para entender qué tan bueno es, hay que darle un puesto de trabajo real. De eso trata un caso de Snorkel, un laboratorio de datos que crea datasets y benchmarks para laboratorios de frontera y grandes empresas. Entre otras cosas, participa en Terminal-Bench.

Por qué un agente necesita un entorno realista

El problema es conocido para cualquiera que haya ejecutado evals de agentes. El agente falló la tarea, pero ¿por qué? ¿No pudo el modelo, o simplemente no tenía la herramienta necesaria? Si el entorno está recortado, el benchmark no mide las capacidades del modelo, sino las limitaciones de tu infraestructura.

Las tareas de Snorkel son diversas: programación, infraestructura, ingeniería de ML. Un agente de ML necesita una GPU para entrenar un modelo. Un agente de infraestructura puede necesitar un kernel de Linux completo y varios contenedores. Por eso el equipo ejecuta las simulaciones en sandboxes de Modal, incluidos sandboxes de VM con sistemas multiservicio y cargas de GPU. Un único proveedor para GPU y CPU simplifica tanto la infraestructura como el control de costes. Según Snorkel, solo en Modal consiguieron sandboxes con GPU de la escala necesaria.

La escala: millones de sandboxes al mes, con picos de decenas de miles por hora. No es un capricho. Cuando sale un modelo nuevo o se ajusta uno existente, el cliente quiere saber en menos de un día si encaja en su caso de uso. Eso significa lanzar rápidamente muchas ejecuciones paralelas sobre una mezcla de benchmarks públicos y privados.

Por qué es tan difícil estimar los recursos de un agente

Antes, el equipo estimaba de antemano la CPU y la memoria de cada sandbox. Salía mal en ambas direcciones. Si se asigna poco, el agente falla por falta de recursos y la ejecución es inválida: no es un error del modelo, sino ruido en la métrica. Si se exagera por precaución, se paga por hardware inactivo.

Adivinar es difícil por dos motivos. Primero, la carga es irregular. El agente espera la respuesta del LLM y el consumo es casi nulo; luego ejecuta, por ejemplo, un grep sobre un repositorio grande y se produce un pico. Segundo, todo el código del sandbox lo escribe el propio modelo y hay muchos benchmarks, por lo que el perfil de carga se desconoce de antemano.

La solución es el bursting de Modal. El sandbox amplía la memoria o la CPU sobre la marcha cuando hace falta. Se paga por el consumo real o por el mínimo declarado, lo que sea mayor. Esto permitió solicitar menos recursos sin sufrir caídas. Snorkel habla de un ahorro de alrededor del 20 % en la factura total de sandboxes, y el número de ejecuciones fallidas por límites se redujo.

Una salvedad: por ahora el bursting lo usan solo el 10–15 % de los sandboxes de Snorkel. La cifra del 20 % es una estimación de la propia empresa, además en un caso publicado por un proveedor. Tómala como una referencia, no como una garantía para tu carga de trabajo.

Inferencia para el benchmark

La segunda mitad del problema son los propios modelos. Para las comprobaciones iniciales de nuevos modelos open-weight, Snorkel usa un endpoint compartido ya preparado. Si el cliente necesita un modelo que ha ajustado, el equipo lo despliega con pesos personalizados en un endpoint dedicado. Un detalle importante: todo esto se hace sin la participación de un equipo de infraestructura. Se levanta el modelo, se ejecuta el benchmark y se apaga.

Entre los planes está evaluar Modal también para el entrenamiento, con el fin de cerrar el ciclo «datos → entrenamiento → evaluación» en una sola plataforma.

Qué llevarse

• Si construyes evals de agentes, separa «el agente no pudo» de «el entorno no lo permitió». Registra las causas de los fallos y cuenta aparte los fallos por recursos.
• No asignes recursos a ciegas, ni por la media ni por el máximo. Mide los picos de CPU y memoria en una muestra de ejecuciones (Snorkel elaboró un gráfico así con 5 000 sandboxes) y considera límites elásticos.
• Si los agentes necesitan GPU dentro del sandbox, comprueba que el proveedor la ofrezca a la escala necesaria antes de diseñar el benchmark.
• Si el cliente espera una respuesta en un día, lo importante no es la velocidad media, sino el paralelismo máximo.

En conjunto, esto no es un avance tecnológico, sino un análisis de ingeniería cuidadoso de cómo es la infraestructura aplicada para evaluar agentes. La conclusión principal: una métrica justa de un agente depende no solo del modelo, sino también de lo correctamente que le hayas asignado los recursos.