SWE-bench: clasificación 2026 de LLM open-source para programar

Evaluar un LLM con SWE-bench en local permite medir la capacidad real de un modelo de pesos abiertos para resolver errores auténticos de GitHub, mucho más allá de las puntuaciones de HumanEval. SWE-bench se distingue porque obliga al modelo a navegar por un repositorio completo, comprender un ticket de incidencia, modificar varios archivos y superar la batería de pruebas. Este artículo detalla la mecánica del benchmark, la variante SWE-bench Verified, los requisitos de hardware, los modelos candidatos del catálogo, el procedimiento de ejecución local y, después, responde a las preguntas frecuentes de quienes trabajan con sistemas autoalojados.

Entender la mecánica de SWE-bench

SWE-bench es un benchmark publicado en 2023 por la Universidad de Princeton que recopila 2.294 problemas reales de GitHub procedentes de 12 proyectos populares de Python (Django, scikit-learn, sympy, matplotlib, etc.). Cada tarea proporciona al modelo un repositorio en un commit específico y el enunciado de una issue. El LLM debe generar un parche (diff) que, una vez aplicado, permite superar las pruebas que antes fallaban sin romper las pruebas existentes. Para los detalles de construcción del dataset, ver el artículo original de SWE-bench y el repositorio oficial de GitHub.

A diferencia de HumanEval, que evalúa funciones cortas aisladas, SWE-bench mide:

Comprensión contextual : leer un repositorio de decenas de miles de líneas
Localización de error : identificar los archivos correctos para modificar sin guía explícita
Edición de varios archivos : producir un parche coherente que no rompa nada
Razonamiento en cadenas largas : alternar exploración, hipótesis, verificación

Una puntuación bruta del 20 % en SWE-bench suele corresponder a una puntuación superior al 80 % en HumanEval, lo que explica por qué muchos modelos muestran un excelente HumanEval pero se desmoronan en SWE-bench.

SWE-bench Verified: la versión filtrada

SWE-bench Verified es un subconjunto de 500 instancias anotadas manualmente por OpenAI en colaboración con los autores de Princeton. Objetivo: eliminar tareas cuyo enunciado es ambiguo, cuyos tests ocultos son demasiado específicos o cuyo patch de referencia depende de un contexto no proporcionado. Detalles completos sobre el blog de OpenAI dedicado a Verified.

Para un test local, SWE-bench Verified es la opción adecuada :

500 instancias en lugar de 2.294: ejecución factible en unos días en una estación de trabajo
Evaluación más fiable del razonamiento real del modelo
Comparación directa con las puntuaciones publicadas por los proveedores

El agente de referencia más usado es SWE-agent, un entorno de ejecución que proporciona al LLM un terminal interactivo, permitiéndole editar archivos, ejecutar comandos y realizar pruebas. Una alternativa popular es OpenHands, que soporta nativamente backends compatibles con OpenAI (vLLM, llama.cpp server, SGLang).

Modelos del catálogo adaptados al benchmark

El LLM de un agente de programación debe combinar un contexto amplio (el arnés de ejecución incorpora trazas de pila, código fuente e historial de acciones) y un buen rendimiento en razonamiento. Estos son los candidatos del catálogo ordenados por perfil de hardware.

Estaciones de trabajo con una capacidad de VRAM muy elevada (≥ 400 GB)

DeepSeek V3.2 (685B, MIT) — VRAM Q4 ~410 GB, ctx 128k. Referente actual entre los modelos con pesos abiertos en SWE-bench Verified según las evaluaciones independientes.
DeepSeek R1 671B (671B, MIT) — VRAM Q4 ~400 GB, contexto 128k. Modelo de razonamiento con cadenas largas, especialmente adecuado para localizar errores.
Mistral Large 3 675B (675B, Apache 2.0) — VRAM Q4 ~405 GB, ctx 256k. Licencia permisiva, interesante para uso comercial.
Kimi K2.6 (1000B, Modified MIT) — VRAM Q4 ~600 GB, ctx 256k. Optimizado para flujos de trabajo agénticos según Moonshot.

Clúster multi-GPU (140-250 GB)

Qwen 3 235B-A22B (235B, Apache 2.0) — VRAM Q4 ~142 GB, ctx 131k. MoE con 22B parámetros activos, buena relación costo/calidad.
Llama 4 Maverick 400B (400B, Llama 4 Community) — VRAM Q4 ~240 GB, contexto 1M. Contexto excepcional para grandes repositorios.
GLM-5.1 (744B, MIT) — VRAM Q4 ~445 GB, contexto 200k.

Una sola estación de trabajo (≤ 80 GB)

Qwen3-Coder-Next 80B-A3B (80B, Apache 2.0) — VRAM Q4 ~48 GB, contexto 262k. Especializado en código, ejecutable en una A100 80GB o en dos 3090.
gpt-oss 120B (117B, Apache 2.0) — VRAM Q4 ~70 GB, ctx 128k. Modelo de OpenAI publicado con pesos abiertos.
Mistral Small 4 (119B, Apache 2.0) — VRAM Q4 ~72 GB, ctx 256k.

Para una comparación detallada en el ámbito del código, ver Qwen3-Coder vs DeepSeek V3.2 y la página Mejor LLM para código.

Tokens/s e impacto en la duración de la ejecución

Una ejecución completa de SWE-bench Verified consume entre 500 millones y 2 mil millones de tokens según el arnés de evaluación y el número de intentos permitidos. El rendimiento en tokens/segundo determina, por tanto, directamente la duración del benchmark.

Estimaciones orientativas (a confirmar en tu configuración) :

DeepSeek V3.2 en 8×H100 80GB en Q4: ~25 tokens/sec en generación, ejecución de Verified estimada entre 5 y 8 días
Qwen 3 235B-A22B en 4×H100: ~40 tokens/segundo en Q4 (los 22B de parámetros activos del MoE ayudan), ejecución estimada de 3 a 5 días
Qwen3-Coder-Next 80B-A3B en 2×A100 80GB: ~60 tokens/seg en Q4, ejecución estimada de 2 a 3 días
gpt-oss 120B en 1×H200 141GB en Q4: ~35 tokens/segundo, tiempo estimado de ejecución de 3 a 4 días

El contexto efectivo cuenta tanto como la velocidad bruta: SWE-agent inyecta regularmente entre 30k y 60k tokens en el prompt para reconstruir el estado del repositorio. Un modelo limitado a 32k de contexto no resulta adecuado; busca al menos 128k. Consulta también el guía de VRAM por cuantización para ajustar tu presupuesto de memoria.

Procedimiento de ejecución local

Aquí tienes un procedimiento simplificado para una configuración estrictamente autoalojada.

Preparar el entorno Docker : SWE-bench Verified exige imágenes Docker por proyecto (Django, sympy, etc.) para aislar la ejecución de las pruebas. Calcula 80 GB de espacio en disco para las imágenes oficiales publicadas por los mantenedores.
Iniciar un servidor de inferencia compatible con OpenAI : con vLLM o llama.cpp en modo servidor, expón tu modelo en localhost:8000/v1. Para Qwen3-Coder-Next en Q4 en 2×A100, un comando típico de vLLM configura --tensor-parallel-size 2 --max-model-len 131072 --quantization awq.
Clonar SWE-agent y configurar el harness para apuntar al endpoint local. El archivo de configuración acepta api_base: http://localhost:8000/v1 et model_name: <votre-modèle>.
Iniciar una ejecución de calibración en 10-20 instancias para comprobar que se respeta el formato de las acciones. Muchos modelos con pesos abiertos fallan aquí porque inventan etiquetas XML que el entorno de evaluación no reconoce.
Ejecución completa : 500 instancias, varios días, registrar sistemáticamente los parches generados para análisis post-mortem.
Envío opcional au leaderboard oficial para comparación pública.

Consejo práctico: limita el número de acciones por instancia (50-75) para evitar que un modelo entre en un bucle infinito que consuma tu presupuesto de tokens.

Interpretación de los resultados

Una puntuación bruta en SWE-bench Verified debe interpretarse en términos relativos, no absolutos.

< 10 % : el modelo no domina el formato de acción del agente, o su contexto es demasiado corto
10-25 % : nivel adecuado para un modelo generalista de pesos abiertos
25-50 % : nivel esperado de un modelo especializado en razonamiento (DeepSeek R1 671B, Kimi K2.6)
> 50 % : nivel de vanguardia, alcanzado por los mejores modelos propietarios

Más allá del puntaje, mira la distribución de los fallos : pruebas que superan el tiempo límite, parches que no se aplican, archivos modificados fuera del alcance previsto. Este análisis revela a menudo que el modelo no está limitado por su razonamiento, sino por el arnés de evaluación (tamaño de la ventana, análisis de las acciones). Para profundizar en la selección de un modelo para agentes, consulta la guía de LLM para agentes.

FAQ

P: ¿SWE-bench o SWE-bench Verified para una prueba inicial?

Verified, sin duda. Las 500 instancias están anotadas manualmente, se eliminan las ambigüedades y el tiempo de ejecución sigue siendo razonable en una sola estación de trabajo. El SWE-bench completo (2294 instancias) incluye tareas mal especificadas que penalizan injustamente a los modelos. Verified también ofrece una comparación directa con las puntuaciones publicadas por los proveedores de modelos propietarios.

P: ¿Qué cuantización elegir para preservar el puntaje de código?

Q4_K_M (GGUF) o AWQ de 4 bits suelen reducir entre 1 y 3 puntos la puntuación SWE-bench en comparación con FP16, lo cual sigue siendo aceptable. Evita Q3 y Q2 en los modelos de razonamiento, donde la pérdida se vuelve significativa. Si tu VRAM lo permite, Q5_K_M o Q8 ofrecen un mejor ratio. Consulta el comparativo de cuantización GGUF vs AWQ.

P: ¿Se necesita un modelo "coder" especializado o un generalista?

Ambos perfiles funcionan. Los modelos especializados en código, como Qwen3-Coder-Next 80B-A3B destacan en la generación de parches, pero los modelos generalistas de razonamiento como DeepSeek R1 671B suelen ser superiores en la localización de errores y la planificación en varios pasos, que representan la mayor parte del coste de una tarea SWE-bench.

P: ¿Se puede ejecutar SWE-bench Verified en una sola RTX 4090?

Difícil. 24 GB de VRAM limitan a modelos ≤ 30B en Q4, y estos modelos suelen quedarse por debajo del 10 % en Verified por su capacidad de razonamiento insuficiente. Puedes usarlo para validar tu pipeline con un modelo ligero como Qwen3-Coder-Next mediante offload parcial a la CPU, pero apunta más bien a 2×3090 o 1×A100 80GB para obtener un resultado aprovechable.

P: ¿Cuántos tokens consume una ejecución completa?

Estimado entre 500 millones y 2 mil millones de tokens según el esqueleto (SWE-agent, OpenHands, custom) y el número máximo de acciones permitidas por instancia. Con un presupuesto de 50 acciones por instancia y 30k tokens de contexto promedio, considera aproximadamente 1 mil millones de tokens para 500 instancias. Cuanto más el modelo 'piensa' en cadena (estilo R1), mayor será el costo en tokens.

P: ¿Los resultados locales son comparables a las puntuaciones de la clasificación?

Sí, siempre que se use el harness oficial, la misma versión del dataset y se respete el protocolo de envío (un solo parche por instancia, sin reintentos de tipo oráculo). Cualquier modificación del harness o del prompt del sistema debe documentarse. El clasificación de SWE-bench acepta resultados de ejecuciones en infraestructura propia y verifica la reproducibilidad.

Conclusión

Ejecutar SWE-bench con un LLM en local sigue siendo la prueba más reveladora para distinguir un modelo de programación con pesos abiertos de otro que simplemente obtiene buenos resultados en HumanEval. Con SWE-bench Verified, una estación con 2×A100 o 4×H100 y un modelo adecuado (Qwen3-Coder-Next, DeepSeek V3.2 o gpt-oss 120B), una ejecución realista se completa en unos días. Para calibrar tu configuración antes de lanzar el benchmark, utiliza el configurador de quelllm.fr o explora el catálogo completo.