Benchmark de Qwen3.8 Max: resultados oficiales y evidencia real
Matriz de evidencia
| Área | Resultado Qwen | Límite |
|---|---|---|
| Código | Terminal 86,6; SWE-Pro 67,7 | Separar harness y reparación de repositorio |
| Agentes | Toolathlon Verified 72,5 | Medir herramientas, reintentos e intervención |
| Razonamiento | HLE 43,6; PaperBench 93,0 | No crea una clasificación universal |
| Multimodal | OmniDocBench 92,1 | Falta verificar la ruta multimedia EvoLink |
| EvoLink | Ruta live; evaluación pendiente | Ejecutar 20–50 tareas con éxito, latencia, reintentos, corrección y coste |
Qué dice un primer test externo
Trilogy AI comparó Qwen3.8 Max y Kimi K3 en la arquitectura de un repositorio de 269 archivos. En revisión ciega, Kimi obtuvo 83/100 y Qwen 80/100. Kimi terminó antes y usó menos tokens; Qwen creó límites de sistema más limpios y mejores metadatos de replay.
Es una señal útil pero estrecha: una tarea, poca información de varianza y posible influencia de cliente, herramientas, esfuerzo de razonamiento y ruta. La conclusión segura es que Kimi ganó por poco ese test, mientras Qwen mostró fortalezas de diseño que deben replicarse.
El canal de acceso forma parte del resultado: la ejecución citada de Qwen usó Token Plan internacional en un entorno interactivo de programación, mientras Kimi pasó por una suscripción Kimi Code. Por tanto, 83 frente a 80 compara dos rutas completas y fechadas, no dos API de producción intercambiables. Una réplica sólida debe congelar entradas, puntuar por separado afirmaciones y estructura, separar modelo y ruta, publicar latencia y tokens junto a calidad, cegar al revisor cuando sea posible y mostrar el análisis de fallos.
Evidencia que sigue faltando
Divulgación oficial completa de benchmarks
Una tabla del proveedor útil debe indicar versión del modelo, ajuste de razonamiento, herramientas, política de prompts, número de intentos, método de puntuación y configuración de competidores. Sin el entorno, una puntuación es difícil de reproducir.
Programación reproducible
Se necesitan varios repositorios, lenguajes, tipos de tarea y repeticiones. Tests ejecutables, lint, build y defectos sembrados son más sólidos que el estilo percibido.
Fiabilidad de agentes
Mida llamadas válidas, recuperación tras fallos, bucles, deriva de instrucciones, criterios de parada e intervención humana.
Contexto largo
Una ventana declarada no garantiza uso útil. Pruebe recuerdo, contradicciones, sensibilidad de posición y citas a 64K, 256K, 512K y tamaño real.
Grounding multimodal
Separe OCR, localización visual, razonamiento y extracción. Cuente detalles omitidos e inventados.
Economía de producción
Incluya distribuciones de latencia, longitud de salida, reintentos, fallback, revisión y reparación.
Estabilidad de ruta y ciclo de vida
Una Preview puede cambiar durante la observación. Cada ejecución debe registrar ID exacto, fecha, canal, región, cliente y configuración para evitar que una repetición mida silenciosamente otra versión.
Derechos de acceso reproducibles
Un benchmark no es reproducible en producción si la credencial probada no puede alimentar legal u operativamente la carga objetivo. Registre por separado si permite evaluación interactiva, regresión automatizada, backend de aplicación y tráfico batch.
Por qué los benchmarks públicos suelen fallar en producción
Una puntuación mezcla modelo, ruta, caché, herramientas, reintentos y evaluación. Un equipo de producción debe medir esos factores por separado, especialmente en agentes con estado, recuperación y criterios de parada.
| Punto ciego del benchmark | Fallo de producción que oculta | Mejor medición |
|---|---|---|
| Calidad de una sola respuesta | Plan correcto, implementación rota | Tarea aceptada de extremo a extremo |
| Prompt ideal | Fragilidad con entradas reales | Tasa de éxito entre variantes de prompt |
| Sin fallos de herramientas | Bucle tras una llamada incorrecta | Recuperación tras fallo inyectado |
| Una sola ejecución | Alta varianza y formato inconsistente | Varios intentos e intervalo de confianza |
| Solo precio por token | Llamada barata con muchos reintentos | Coste por tarea aceptada |
| Contexto máximo | Mala recuperación en entradas largas | Recuerdo con posición de evidencia controlada |
| Solo nota final | Afirmaciones sin respaldo ocultas en una respuesta pulida | Auditoría de evidencia por afirmación |
Estos puntos ciegos importan especialmente en programación y agentes: la utilidad depende del estado, las herramientas, la recuperación y la parada correcta, no solo de la respuesta final.
Futuro gate de benchmark de EvoLink
Este protocolo solo se ejecutará cuando exista una ruta API apta para producción. No es un resultado publicado ni una razón para pagar ahora una prueba grande de Token Plan.
1. Congelar cargas reales
Cuando exista la API, empieza con un piloto pequeño y amplíalo solo si aporta evidencia. Documenta entradas, herramientas, tiempo, criterios y gravedad del fallo.
| Categoría | Prueba mínima | Señal de aceptación |
|---|---|---|
| Programación en repositorio | Bugfix y función entre módulos | Tests aprobados, sin cambios ajenos |
| Agente de código | Tarea larga con varias herramientas | Llamadas correctas, sin bucles pendientes |
| Razonamiento | Decisión técnica en varios pasos | Resultado correcto y supuestos trazables |
| Contexto largo | Búsqueda de evidencia en repositorio o documentos | Evidencia correcta con fuentes |
| Comprensión visual | Captura, gráfico o documento | Extracción fundamentada, pocas invenciones |
| Datos/productividad | Análisis de tabla e informe | Precisión numérica y resultado utilizable |
| Carga rutinaria | Tarea pequeña y frecuente | La ruta frontier aporta valor medible |
2. Elegir baselines
Qwen3.7 Max para la generación estable anterior, Kimi K3 como challenger de contexto largo y la ruta Claude o GPT que el producto usa en tareas difíciles.
3. Registrar condiciones
Guarde ID, ruta, fecha, razonamiento, system prompt, permisos, preparación, sampling y reintentos. “Qwen3.8” sin esos campos no es reproducible.
4. Repetir y revisar a ciegas
Ejecute al menos tres veces las tareas no deterministas. Use tests y validadores; para lo subjetivo, rúbrica fija y revisión ciega.
5. Medir de extremo a extremo
| Dimensión | Métricas |
|---|---|
| Calidad | Aceptación, tests, errores factuales, rúbrica |
| Fiabilidad | Errores, herramientas/JSON inválidos, bucles, intervención |
| Latencia | p50, p95, tiempo al resultado aceptado |
| Eficiencia | Entrada, caché, salida, razonamiento, herramientas |
| Coste | Modelo, reintentos, fallback, revisión, reparación |
accepted_task_cost = model_usage + retries + fallback + reviewer_time + defect_repair6. Asignar un rol de ruteo
| Rol | Evidencia necesaria |
|---|---|
| Ruta por defecto | Aceptación, latencia y coste estables en tráfico común |
| Especialista de código | Ventaja clara en repositorios y herramientas |
| Especialista de contexto | Mejor recuerdo y coherencia a tamaños reales |
| Escalado de calidad | Más aceptación en tareas difíciles |
| Solo seguimiento | Sin ruta apta para producción, precio o evidencia API reproducible |
Hasta que EvoLink active y valide la ruta, “solo seguimiento” es el rol correcto.
Cómo leer nuevas puntuaciones
Pregunte quién las publicó, versión y ruta exactas, nivel de razonamiento, herramientas, número de intentos, reproducibilidad, relación con su producto y si incluyen latencia, tokens, reintentos y errores. Si faltan esos datos, márquelas como orientativas.
Acción recomendada
Conserve evidencia reproducible detrás de cada puntuación
Guarde ID, ruta, fecha, región, versión de cliente, nivel de Thinking, permisos de herramientas, caché, hash del prompt, intentos, judge y regla de aceptación. Sin este registro, una revisión de modelo o ruta puede parecer una mejora.
| Resultado | Artefacto mínimo | Uso permitido |
|---|---|---|
| Qwen oficial | Tabla y configuración del harness | Hipótesis y baselines |
| Tercero | Prompts, ruta, repeticiones, judge y fallos | Comparación direccional |
| Comunidad | Tarea reproducible o evidencia primaria | Edge case, no ganador |
| Smoke test EvoLink | Request/response, Usage, latencia y error | Confirmar contrato |
| Workload EvoLink | Acceptance repetida y revisión | Main/Challenger/Fallback |
Publique distribución y fallos, no solo medias. Tool calls inválidas, JSON roto, timeouts, retries, fallbacks y corrección humana permanecen en el denominador. Cuatro éxitos y un bucle infinito pueden ser peores que una nota algo menor pero estable.
Convierte los benchmarks en una decisión de enrutamiento
No te registres solo por el anuncio. Resuelve primero estas preguntas y crea una clave API únicamente si la ruta encaja con tu carga.
- 01
¿Se lanzó?
Sí. Qwen3.8 Max es el modelo de producción; Preview queda como contexto histórico.
- 02
¿Está disponible?
Sí, en EvoLink. Confirma la ruta activa y el ID en la página del producto.
- 03
¿Me conviene?
Para razonamiento de contexto largo, repositorios grandes y agentes con herramientas; las tareas simples deben usar una ruta menor.
- 04
¿Cuánto cuesta?
Consulta el módulo de precios en vivo del producto; no reutilices precios upstream o del plan Preview.
- 05
¿Cómo se llama?
Elige Chat Completions, Responses o Messages y sigue la guía de integración y la referencia de parámetros.
¿Completaste las cinco comprobaciones? Crear una clave API.
Preguntas frecuentes
¿Cuál es la puntuación de Qwen3.8?
No existe una nota global fiable. Qwen publica 86,6 en Terminal-Bench 2.1, 67,7 en SWE-bench Pro, 43,6 en HLE y 92,1 en OmniDocBench 1.5; son resultados del proveedor, no un ranking universal.
¿Solo Fable 5 supera a Qwen3.8?
Sigue siendo una interpretación del proveedor sobre su propia evaluación, no un ranking universal verificado de forma independiente. Asigne roles por carga.
¿Se ha probado de forma independiente?
Hay tests iniciales, incluido el repositorio de 269 archivos, útiles pero demasiado estrechos para un ranking general.
¿Es bueno para programación?
Es un caso central del lanzamiento, pero equipos de producción deben probar repositorios, herramientas, recuperación, tests y revisión.
¿Cómo compararlo con Kimi K3?
Entradas congeladas, permisos iguales, misma rúbrica, varios intentos y medidas separadas de calidad, latencia, tokens, intervención y coste.
¿Puedo comparar costes con Credits?
No. Los Credits describen un experimento Preview; la comparación de producción debe usar el precio real del proveedor o la ruta EvoLink en la misma ejecución.
¿Qué baselines usar?
Qwen3.7 Max, Kimi K3 y la ruta Claude o GPT realmente disponible para el producto.
¿Cuándo está listo para producción?
Cuando ruta, ID, precio, límites, conducta y fallback estén verificados y las tareas reales repetidas superen el umbral de aceptación.
Fuentes
- Registro de lanzamientos de QwenCloud
- Lanzamiento técnico y benchmarks de Qwen3.8 Max
- Anuncio Qwen3.8
- Qwen Token Plan
- Qwen Chat API
- Trilogy AI: Qwen3.8 Max vs Kimi K3
