Un tercio de los parches de código que pasan todas las demás pruebas fallan en la validación de serving end-to-end en tareas de SGLang, revelando que la finalización de tareas locales no garantiza corrección en producción. Investigadores de NVIDIA y UC Berkeley construyeron SWE-Serve, un benchmark de 53 tareas fundamentado en cambios de producción a SGLang, un sistema de inference-serving de código abierto, para medir esta brecha directamente.

El benchmark abarca seis familias de ingeniería de inferencia: habilitación de modelo y backend, decodificación especulativa y avanzada, kernels y cuantización, caché y estado de runtime, ejecución distribuida y APIs de serving. Las tareas van desde correcciones de corrección localizadas hasta integraciones que cruzan límites de API, scheduling y estado de runtime. La solución oracle mediana cambia 553 líneas en siete archivos, con algunas tareas requiriendo hasta 6,077 líneas en 35 archivos. Cada tarea se ejecuta en CPU o una única GPU H100 e incluye pruebas funcionales y de regresión ocultas, con 19 tareas añadiendo pruebas end-to-end de model-serving que lanzan un proceso de serving independiente y validan el comportamiento a través de interfaces de solicitud públicas.

En 11 modelos y 31 configuraciones de esfuerzo de modelo, la configuración de mejor desempeño logra 75% de pass@1 medio. Claude Opus 5 y GPT-5.6 Sol alcanzan ambos 75% de pass@1, aunque con costos de recursos diferentes: Opus 5 con esfuerzo máximo cuesta $17.40 por tarea con 122k tokens de salida, mientras que Sol con esfuerzo máximo cuesta $12.26 con 52k tokens. El benchmark revela una dispersión de 40 puntos porcentuales en desempeño entre modelos, desde 75% para los mejores hasta 35% para Inkling S.

La brecha de corrección en producción emerge claramente cuando las pruebas end-to-end de model-serving se eliminan de la puntuación. En 19 tareas con cobertura end-to-end, la tasa de pass salta de 45.9% bajo el verificador completo a 69.4% cuando se excluyen las pruebas E2E, un aumento de 23.4 puntos porcentuales que se mantiene en todas las 11 configuraciones principales por modelo. Un control emparejado que elimina el mismo número de pruebas no-E2E produce solo 8.0 transiciones fail-to-pass en promedio, comparado con 16.1 para eliminación de pruebas E2E—una diferencia de 2.0×. En la tarea core-serving de mezcla de expertos de Gemma 4, 48.5% de los parches creados por agentes pasaron cada prueba no-E2E pero fallaron al menos una prueba E2E, incapaces de servir el modelo especificado correctamente a través de las interfaces públicas del servidor en vivo.

Más allá del serving end-to-end, las tareas que prueban múltiples dominios de runtime muestran tasas de pass sustancialmente más bajas. Las 26 tareas de dominio de runtime único promedian 69.0% de tasa de pass, mientras que las 27 tareas de multi-dominio de runtime promedian 47.7%—una brecha de 21.3 puntos porcentuales. Las tareas que prueban explícitamente coordinación concurrente muestran caídas aún más pronunciadas, con tasas de pass 29.0 puntos porcentuales más bajas que tareas sin ese requisito. Los requisitos de estado persistente se correlacionan con tasas de pass 20.8 puntos porcentuales más bajas en tareas de GPU. Estas brechas persisten incluso con esfuerzo de razonamiento máximo: aumentar el esfuerzo mejora las tasas de pass agregadas pero no cierra consistentemente las brechas de corrección en producción.

El benchmark impone evaluación de libro cerrado, bloqueando acceso a web pública y repositorio upstream durante la ejecución del agente. Un piloto de libro abierto confirmó que los tres modelos evaluados recuperaron soluciones upstream específicas de tareas, así que la configuración de libro cerrado previene que los agentes copien soluciones. Cada trayectoria de evaluación fue auditada para recuperación prohibida; ningún ensayo fue invalidado en esta base. El benchmark admite solo 34% de candidatos de tareas después de calificación: 53 de 156 candidatos pasaron controles ejecutables requiriendo parches no-op para fallar todas las pruebas fail-to-pass y pasar todas las pruebas pass-to-pass, mientras que las soluciones oracle pasan todas las pruebas. El sondeo adversarial asistido por agentes identificó vulnerabilidades en instrucciones de tareas y verificadores, llevando a 27 candidatos de tareas requiriendo cambios de verificador antes de admisión.

Para equipos que envían sistemas de inferencia, la conclusión es directa: el paso de pruebas locales no valida serving en producción, y las pruebas end-to-end a través de rutas de serving en vivo deben ser parte de la puerta de evaluación.