Le dimos a Qwen3.7-Plus 10 errores reales y 15 problemas de AIME. Superó al modelo insignia en ambos.

Resumen

A mediados de mayo de 2026, Qwen3.7-Max y Qwen3.7-Plus aparecieron discretamente en LM Arena. @Alibaba_Qwen fijó las expectativas de la comunidad con la frase: "Alibaba #6 en Texto, #5 en Visión". El 2 de junio, el equipo de Alibaba Cloud Tongyi Qianwen lanzó oficialmente este modelo de agente multimodal. Ya está disponible en Alibaba Cloud Model Studio y Qwen Chat, con acceso a API bajo

1alibaba/qwen3.7-plus

El posicionamiento oficial es claro: Plus es el modelo multimodal rentable; Max es el buque insignia para texto.

Pasamos una tarde ejecutando una suite de pruebas rigurosas en Qwen3.6-plus, Qwen3.7-plus y Qwen3.7-

1Max

Los resultados deben interpretarse como 5 observaciones a nivel de tarea, no como una clasificación general de modelos:

1. Ejecución única de BugFind-10: Plus superó todas las pruebas externas de pytest. Bajo esta suite de 10 tareas, el framework oficial Stirrup y una configuración de ejecución única, Plus obtuvo 10/10 mientras que Max y 3.6-Plus obtuvieron 9/10. Esto indica un buen ajuste a la tarea en este entorno; no debe extrapolarse a una clasificación general de programación.
2. Matemáticas: Plus con "thinking" activado alcanzó la misma puntuación de ejecución única que Max. En 15 problemas matemáticos de concurso, tanto Plus como Max respondieron 14 correctamente; en esta ejecución, Qwen3.7-plus requirió mucho menos tiempo que Qwen3.7-Max (113 s vs 303 s por problema).
3. Un salto generacional en velocidad: En tareas de agentes, el rendimiento de extremo a extremo para Qwen3.7-plus alcanzó 147.5 t/s, mientras que Qwen3.6-plus solo llegó a 41.5 t/s, una mejora de 3.55x. Las tareas matemáticas que la generación anterior no lograba finalizar se volvieron sencillas de completar.
4. La multimodalidad aún tiene fallos: En nuestras pruebas multimodales controladas, Qwen3.7-plus respondió correctamente a preguntas sencillas sobre imágenes, pero la imagen de ejemplo oficial
   textCopy

   1dog_and_girl.jpeg

   fue descrita como "un tren y una multitud".
5. Algunas capacidades estuvieron cerca de Max, con una ventaja en latencia: En varias pruebas de esta ejecución, Qwen3.7-plus obtuvo resultados cercanos a Qwen3.7-Max mostrando una latencia menor. Esto no es una afirmación de clasificación general.

A continuación se presentan los datos de prueba completos, la metodología y las recomendaciones de selección de modelos para líderes de ingeniería. Todas las comparaciones están limitadas a esta pequeña muestra, ejecución única y framework fijo.

0. Contexto de capacidad del modelo y Leaderboard

La línea de productos de Alibaba Qwen ya se había asentado en un patrón en la generación 3.6: Max = buque insignia de texto, Plus = modelo multimodal de contexto largo. La versión 3.7 continúa esa lógica:

1. ¿Cómo posiciona la historia oficial a Plus?

La publicación de lanzamiento de Alibaba Qwen resume el mensaje en una frase:

"Un modelo. Ve, piensa, programa, actúa."

Los puntos de venta principales son: un agente híbrido interactivo multimodal con operación unificada GUI y CLI, un agente de programación versátil y generalización entre frameworks de agentes. El desarrollador principal de Qwen, shuai bai_, lo explicó más a fondo:

Nuestro objetivo es transformar la IA multimodal de un simple captioning de imágenes pasivo a un solucionador de problemas activo: uno que pueda ver, razonar, escribir código, operar interfaces y verificar resultados. Es un paso hacia una inteligencia multimodal verdaderamente agéntica.

Las publicaciones de rendimiento del hilo oficial ofrecen el posicionamiento clave:

• El rendimiento de texto está "cerca del nivel de Max" (afirmación del proveedor).
• Las mejoras multimodales se centran en capacidades centrales de agente: comprensión visual compleja, razonamiento visual, uso de herramientas y ejecución de código/GUI.

2. Nuestro método de evaluación: Cuatro tipos de tareas y una regla estricta

Para mantener la prueba justa, mantenemos una suite llamada BugFind-10: 10 bugs del mundo real que abarcan cálculo de precios, límites de arrays, manejo de rutas, concurrencia, JSON, SQL, comportamiento de caché, Unicode, configuración y más. Cada bug viene con pruebas de pytest. El modelo debe ejecutarse dentro del framework de agente oficial Stirrup con herramientas locales de ejecución de código y completar el ciclo completo por sí mismo: "reproducir → localizar → editar código de producción → ejecutar pruebas".

¿Por qué construir nuestra propia suite de pruebas?

Los leaderboards públicos tienen tres modos de fallo comunes:

1. Memorización y filtraciones: los modelos insignia ya están saturados con problemas antiguos. Seleccionamos AIME 2025, un concurso publicado después de los probables cortes de entrenamiento del modelo.
2. Los autoinformes de los proveedores pueden alejarse de los reanálisis independientes: la misma métrica puede cambiar significativamente según la versión del dataset, si el pensamiento (thinking) está habilitado y si se permiten herramientas.
3. Los benchmarks de agentes dependen del andamiaje (scaffold): diferentes frameworks de agentes pueden desplazar las puntuaciones en 2-3 puntos porcentuales. Fijamos el framework al Stirrup oficial y añadimos verificación externa.

Las cuatro tareas de prueba

Nuestra regla estricta: Las puntuaciones de código solo cuentan bajo Pytest externo

Este es el fundamento de toda la revisión. También aborda directamente la preocupación de Hacker News de que un agente diga "pruebas aprobadas" no es suficiente.

Proceso:

1. El agente edita el código en el espacio de trabajo, ejecuta pytest por sí mismo y escribe un CHANGELOG.
2. Copiamos el código de producción modificado en un entorno aislado y ejecutamos pytest de forma independiente.
3. Publicamos solo el código de salida y la pila de fallos del paso 2.

Una analogía: el agente es quien realiza el examen. No solo leemos la respuesta que entrega; tomamos la respuesta y la llevamos a otra habitación para calificarla de nuevo, de modo que no confiamos en su propia creencia de que tuvo éxito.

3. Código y capacidad de agente

Descripción general de tres modelos

Que Plus obtuviera el mejor resultado de ejecución única en BugFind fue inesperado:

1. Plus fue la única ejecución 10/10 en esta prueba.
2. Max utilizó la menor cantidad de llamadas pero no obtuvo la puntuación máxima. 3.7-Max se detuvo después de solo 20 llamadas al modelo. Tendía a "pensar durante mucho tiempo y realizar un gran cambio", con menos iteraciones. Por el contrario, 3.7-Plus usó 52 llamadas y estuvo dispuesto a editar, ejecutar, inspeccionar comentarios y volver a editar.
3. Plus tuvo el menor tiempo real y el mayor rendimiento. Para la experiencia de agente en IDE, eso importa mucho más que unos pocos puntos Elo en un leaderboard.

Una tarea, tres filosofías de reparación: Análisis profundo de task05

Esta tarea prueba la regla de que el JSON no válido no debe ser ignorado silenciosamente. Cuando el análisis detecta datos incorrectos, no debe fingir éxito y devolver un objeto vacío; debe informar el error claramente. El bug original:

pythonCopy
1def safe_parse(data: str):
2    try:
3        return json.loads(data)
4    except Exception:
5        return {}   # Bug: ignora la excepción

Las pruebas requieren:

• Para una entrada como "esto no es json {", la función no debe devolver un dict vacío {}.
• Para una entrada no válida sin llaves, como "bad", debe generar una excepción.

El enfoque de Max (prueba externa ✗): generar un

1JSONParseError

3.6-Plus (externa ✗): falló en el mismo primer obstáculo.

3.7-Plus (externa ✓):

pythonCopy
1if re.search(r'[\{\[\]\}]', data):
2    return {"error": str(e), "raw": data}
3raise ValueError(f"Invalid JSON: {e}") from e

Para entradas malformadas que contienen llaves, devuelve un objeto de error distinguible de

1{}

Conclusiones de ingeniería:

• Para tareas de agente, la disposición a trabajar con el entorno (Plus tuvo 52 turnos de diálogo y 98 ejecuciones de código) importa más que la iteración mínima.
• Max se detuvo tras 20 turnos y creyó prematuramente que task05 estaba resuelta.

4. Razonamiento y matemáticas: El modo "Thinking" es una decisión de costo

La serie Qwen3.7 enfatiza el "pensamiento híbrido", controlado a través del interruptor

1enable_thinking

Conclusión sobre el interruptor de pensamiento:

Desactiva el pensamiento para tareas simples y ahorra dinero; actívalo para tareas difíciles y compra precisión. Dejar el razonamiento activado globalmente significa pagar continuamente más de 4 veces más por solicitudes simples sin ganancia de precisión.

5. Velocidad y brecha generacional

Comparación de rendimiento de agente de extremo a extremo:

• 3.7-Plus: 147.5 t/s
• 3.7-Max: 51.8 t/s
• 3.6-Plus: 41.5 t/s

La mejora generacional (3.6 → 3.7 Plus) fue de aproximadamente 3.55x. El ejemplo más dramático del salto generacional provino de ejecutar matemáticas en 3.6-Plus. Fue demasiado lento para terminar: cada problema tomaba entre 297 y 932 segundos. "Poder resolver" y "poder terminar dentro de un tiempo que los usuarios toleren" son afirmaciones diferentes.

6. Conclusión final

En el universo reproducible de una tarde de nuestras pruebas:

• Es el modelo que fue el único en obtener 10/10 en esta ejecución de reparación de bugs reales.
• El modelo que alcanzó la misma puntuación que Max en este concurso de matemáticas con thinking activado, mostrando menor latencia.
• El modelo que entregó una mejora de rendimiento de 3.55x sobre la generación anterior.
• El modelo que todavía alucinó en la imagen de ejemplo oficial mientras pasaba nuestra prueba de imagen controlada.

Para los ingenieros, la narrativa oficial es responsable de la visión; el directorio

1outputs/