Benchmark de Qwen3.8: qué está confirmado y qué falta por probar
Comprobación del nombre: Qwen3.8 Max Preview no es Qwen3-8B. Las puntuaciones del antiguo modelo de 8B no son evidencia sobre Qwen3.8.
Esta página puede clasificar hechos y límites documentados. No puede concluir que Qwen3.8 supere en general a Fable 5, GPT-5.6, Kimi K3 o Qwen3.7 Max.
Evidencia actual
| Nivel | ¿Disponible? | Qué respalda | Qué no respalda |
|---|---|---|---|
| Estado y funciones oficiales | Sí | ID, canal, razonamiento/visión/texto | Ranking de calidad |
| Posicionamiento de Qwen | Sí | Hipótesis y competidores | Victoria independiente |
| Tests externos por carga | Limitados | Observaciones de una tarea/ruta | Capacidad general |
| Cobertura independiente amplia | Insuficiente | Futura comparación transversal | Conclusión definitiva actual |
Una función documentada no es una puntuación y un ranking de proveedor no es evidencia independiente.
Qué afirma Qwen
| Afirmación | Hipótesis útil | Conclusión insegura |
|---|---|---|
| 2,4 billones de parámetros | Probar si la escala mejora tareas difíciles | Más parámetros garantizan mejores resultados. |
| Posición near-frontier | Incluir Fable, GPT, Kimi y Qwen3.7 | Qwen3.8 ocupa el segundo puesto independiente. |
| Foco en programación y trabajo complejo | Probar repositorios y bucles de herramientas | Es el mejor modelo de código. |
| Plan Open Weights | Preparar serving y reproducibilidad | Los pesos serán idénticos a la Preview alojada. |
Sin parámetros activos ni arquitectura tampoco se pueden inferir coste de inferencia, latencia, memoria o cómputo por token.
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
Preguntas frecuentes
¿Cuál es la puntuación de Qwen3.8?
No existe una puntuación global única y fiable. El posicionamiento de Qwen y la limitada replicación no bastan.
¿Solo Fable 5 supera a Qwen3.8?
Es el posicionamiento del proveedor, no un ranking universal independiente.
¿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?
Solo describen el consumo del experimento de suscripción; no los convierta en precio API general.
¿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 los tests repetidos superen el umbral de aceptación.
