Infraestructura altera resultados en evals de código IA | Keryc
Mientras calibraba una corrida de Terminal-Bench 2.0 en un clúster de Google Kubernetes Engine, notamos algo incómodo: los puntajes no coincidían con el leaderboard oficial y hasta 6% de las tareas fallaban por errores de pod, sin relación con la habilidad del modelo. ¿La sorpresa? Solo cambiar cómo se aplicaban los recursos bastaba para mover resultados varios puntos porcentuales.
Qué encontraron
Los evals de agentes para programación no son pruebas estáticas. Aquí el modelo escribe código, instala dependencias, ejecuta pruebas y reintenta en varios turnos. El entorno de ejecución deja de ser un simple contenedor y pasa a ser parte de la prueba.
Anthropic corrió Terminal-Bench 2.0 con seis configuraciones de recursos: desde aplicar estrictamente las especificaciones por tarea (1x) hasta no imponer límites (uncapped). Todo lo demás se mantuvo igual: mismo modelo Claude, mismo harness, mismo set de tareas.
Los resultados clave:
Las tasas de error de infraestructura cayeron de 5.8% en 1x a 0.5% en uncapped.
De 1x a 3x, los errores infra bajaron de 5.8% a 2.1% (p < 0.001).
El salto total de 1x a uncapped fue de +6 puntos porcentuales en éxito (p < 0.01).
En SWE-bench, al aumentar RAM hasta 5x, el efecto fue más chico pero presente: +1.54 puntos porcentuales en 5x vs 1x.
Además, observaron que a partir de alrededor de 3x los puntajes suben más rápido que la simple caída de errores infra. Es decir, con más headroom los agentes no solo dejan de fallar por causas infraestructurales: empiezan a usar estrategias que solo funcionan con recursos generosos.
Por qué importa el detalle de la implementación
No basta con publicar una especificación de recursos por tarea. En runtimes de contenedores hay dos parámetros distintos: la asignación garantizada (reservation) y el límite duro a partir del cual el contenedor es eliminado (kill threshold). Si ambos son iguales, no hay margen para picos transitorios: una pequeña fluctuación de memoria puede provocar un OOM-kill, y la tarea muere antes de que el agente resuelva algo.
En la práctica, distintos sandboxing providers aplican estas reglas de forma diferente. El proveedor usado por el leaderboard de Terminal-Bench permite overcommit temporal y evita kills inmediatos, haciendo la ejecución más estable. Nuestra implementación en Kubernetes, por otra parte, trató la especificación como piso y techo a la vez y eso generó fallas evitables.
Qué cambian las restricciones: eficiencia versus fuerza bruta
Con límites estrictos, se favorecen agentes que escriben código muy lean y eficiente. Con límites generosos, se favorecen agentes que instalan grandes dependencias, spawn procesos costosos o ejecutan suites de tests pesadas. Ambos estilos son válidos, pero colapsarlos en una sola cifra sin decir bajo qué condiciones se corrió hace difícil interpretar la generalizabilidad real.
Un ejemplo concreto: en la tarea bn-fit-modify, algunos agentes instalan pandas, networkx y scikit-learn y funcionan bien con headroom. Con límites estrictos, la pod se queda sin memoria durante la instalación, y el agente ni siquiera llega a escribir la primera línea de código. Otros agentes optan por implementar la matemática desde la librería estándar y pasan con menos recursos. La configuración decide qué enfoque triunfa.
Otras fuentes de variación
La infraestructura no es solo memoria y CPU. Límites de tiempo, concurrencia, egress bandwidth, latencia de API según la hora del día y salud general del clúster pueden influir. Anthropic documentó fluctuaciones anecdóticas según la hora del día, probablemente por cambios en latencia de la API. En suma, los evals agenticos son pruebas end-to-end: cualquier parte del sistema puede ser un confounder.
Un modelo puede perder por un OOM-kill que no refleja su capacidad, sino el detalle de cómo el runtime aplica límites.
Recomendaciones prácticas (técnicas)
Especifica dos parámetros por tarea: guaranteed_allocation y hard_kill_threshold. No pongas un único valor que sea a la vez piso y techo.
Calibra el margen entre ambos. En Terminal-Bench 2.0, un techo de 3x sobre la especificación por tarea redujo errores infra de 5.8% a 2.1% (p < 0.001) y mantuvo la ganancia de score dentro del ruido (p = 0.40). Ese tipo de calibración empírica es la forma correcta de encontrar un tradeoff entre estabilidad y presión de recursos.
Corre los evals varias veces y en distintos días. Probar múltiples ejecuciones y promediar ayuda a promediar ruido de red, latencias y eventos puntuales del clúster.
Publica tanto las especificaciones recomendadas como la metodología de enforcement (qué runtime, cómo manejas overcommit y los parámetros reales usados). Sin eso, las comparaciones entre leaderboards son frágiles.
Trata la configuración de recursos como una variable experimental más, al mismo nivel que el prompt o la temperatura de muestreo.
Implicaciones para quien usa o mantiene benchmarks
Si usas scores para decidir qué modelo desplegar, ten en cuenta que una diferencia de 1 o 2 puntos porcentuales puede estar dentro del ruido infraestructural. Hasta que la metodología sea estándar o reproducible, las diferencias por debajo de 3 puntos merecen escepticismo, especialmente si no se publican los detalles de ejecución.
Para mantenedores de evals: publicar recursos recomendados es un buen primer paso. Publicar además cómo se aplican (garantía vs límite, proveedor de sandbox, políticas de overcommit) cerraría la brecha que permite interpretaciones erradas.
Reflexión final
Los evals agenticos son útiles porque prueban al sistema completo, pero eso es exactamente lo que los hace frágiles frente a detalles de infraestructura. No es un problema de magia: un par de gigabytes de memoria o un manejo distinto del overcommit pueden decidir quién lidera un leaderboard.
¿Quieres medir la capacidad del modelo o la potencia de la VM que lo rodea? La respuesta debería estar explícita en la ficha del benchmark.
