ZoomGain-4B vs Qwen3.8-27B: la victoria de 11 puntos se debe a un conjunto de datos, no a un modelo

El número que hace que este enfrentamiento merezca una página es 55,81 frente a 44,81. En ZoomGainBench, el benchmark de 1.000 preguntas de detalle fino publicado junto con el ZoomGain-4B de inclusionAI, un modelo de visión de 4,54 mil millones de parámetros obtiene once puntos más que Qwen3.8-27B, un modelo denso de 27,78 mil millones de parámetros que A​libaba publicó bajo Apache 2.0 en agosto y que lee imágenes y vídeo además de texto. Seis veces los parámetros, y pierde por once puntos. Lea el artículo que produjo ambas cifras y la brecha deja de ser una afirmación sobre la visión: ZoomGainBench se construyó con el mismo pipeline automatizado que generó los datos de entrenamiento de ZoomGain-4B, los propios autores lo dicen en su estudio de ablación, y el modelo contra el que competían de verdad no es Qwen3.8-27B en absoluto: es otro conjunto de datos.

Eso no es una refutación. Es lo más útil de la publicación, y es lo que hace que la comparación sea decidible: te dice cuál de los dos modelos elegir y qué cifra citar cuando alguien te pida que justifiques la elección. Lo que sigue separa las tres afirmaciones que aquí se agrupan: que un especialista pequeño supera a un generalista grande, que una canalización de datos supera a otra canalización de datos y que cualquiera de estas es motivo para cambiar tu stack este mes.

Qué se envió, y con qué discreción

El repositorio de ZoomGain-4B se creó en Hugging Face el {{1}}10 de noviembre de 2026 a las 11:38 UTC{{/1}} y se modificó por última vez el {{2}}11 de noviembre{{/2}}. El artículo, arXiv 2611.14076, se envió el 10 de noviembre. El repositorio GGUF se modificó el {{3}}11 de noviembre a las 03:13 UTC{{/3}}. En el momento de escribir esto, ambos repositorios muestran cero descargas y cero me gusta, no hay ningún proveedor de inferencia asignado al modelo y no existe ninguna publicación de lanzamiento del proveedor, entrada de blog ni comunicado de prensa sobre él. La propia lista Updates de la model card, fechada el {{4}}11 de noviembre{{/4}}, es el único anuncio: tres líneas que dicen que ya están disponibles el artículo, el benchmark, el conjunto de datos de RL y los checkpoints.

Así que el planteamiento honesto es que esto se lanzó discretamente y no se ha anunciado. Todo lo que aparece a continuación y procede de un repositorio se puede verificar hoy mismo; cualquier afirmación sobre cómo se comporta el modelo fuera del marco de pruebas de los autores aún no está confirmada, porque nadie fuera de Ant Group y la Universidad de Zhejiang lo ha probado y ha compartido los resultados.

Dos detalles del repositorio conviene tener en cuenta antes de que empiece la comparación, porque ambos reducen lo que se puede hacer con él.

• Arquitectura. Un derivado de Qwen3.5-4B: 32 capas, tamaño oculto de 2.560, 16 cabezas de consulta frente a 4 cabezas KV con una dimensión de cabeza de 256, una programación 3:1 de DeltaNet lineal a atención completa, 262.144 posiciones máximas, un vocabulario de 248.320 tokens y un codificador de visión de 24 capas con tamaño oculto de 1.024. El total, incluidos el codificador y el proyector, es de 4.539.265.536 parámetros.

• Licencia. La sección License de la tarjeta cubre el código, que es Apache 2.0, y luego remite: «Consulta las tarjetas de Hugging Face para conocer los términos de cada conjunto de datos y checkpoint». La tarjeta del checkpoint no incluye ninguna etiqueta de licencia. Qwen3.8-27B es Apache 2.0 en términos inequívocos. Si necesitas una licencia que puedas entregar a un abogado, esa asimetría es lo primero con lo que te encuentras y no queda resuelta por nada de la versión.

La única lista donde ambos modelos aparecen lado a lado

ZoomGainBench es un benchmark bilingüe de 1.000 preguntas sobre 941 imágenes: 472 preguntas de reconocimiento de atributos con entre cuatro y seis opciones, 94 preguntas de conteo y 434 preguntas de OCR, cada una en una versión en inglés y otra en chino, por lo que hay 2.000 instancias de evaluación. Se ejecutaron veintiocho modelos con él bajo un mismo arnés de evaluación: el mismo prompt de sistema, temperatura 0, pensamiento desactivado para cada checkpoint de Qwen y 2.048 tokens de salida para los modelos no agénticos. El mejor resultado del campo es GPT-5.6-Sol con 61,08, y solo cinco modelos superan los 50.

Qwen3.8-27B se sitúa en 44,81 global: 43,84 en inglés a partir de 40,25 en atributo, 54,26 en conteo y 45,49 en OCR, y 45,78 en chino. ZoomGain-4B, en la tabla de entrenamiento en lugar de la tabla de benchmark, se sitúa en 55,81. Ambas cifras son el global en los dos idiomas con las mismas reglas de puntuación, así que esto es lo más cercano a un emparejamiento controlado que ofrece el lanzamiento, y en él el 4B gana por 11,00 puntos.

• Parámetros. 4,54B frente a 27,78B — una diferencia de 6,1× en la dirección que hace que el resultado sea sorprendente.

• Para qué se construyó cada uno. ZoomGain-4B es Qwen3.5-4B sometido a una época de GRPO sobre 9.000 preguntas extraídas, 140 pasos, lote de 64, ocho rollouts por pregunta, tasa de aprendizaje 1e-6, sin término KL. Qwen3.8-27B es un modelo denso general con modo de razonamiento, llamada a herramientas y una ruta de vídeo.

• Datos de entrenamiento. 9.000 preguntas para uno. Para el otro, todo el corpus de preentrenamiento y postentrenamiento de A​libaba, de tamaño no revelado.

• Disponibilidad. ZoomGain-4B: tres precisiones GGUF y un archivo de proyector independiente, sin endpoint alojado. Qwen3.8-27B: pesos Apache 2.0, una compilación FP8, 7,4 millones de descargas y endpoints a los que puedes llamar hoy mismo.

La comparación que el artículo establece realmente

Esta es la parte que se pierde cuando el lanzamiento se reduce a «4B supera a 27B». El artículo necesitaba una línea base para sus propios datos, y utilizó una: ZwZ, un conjunto de datos de percepción de grano fino de ICML 2026 construido mediante destilación de región a imagen. A ambos lados se les dio un tratamiento idéntico. Se muestrearon doce mil imágenes y se generaron 23.610 preguntas; el benchmark tomó 1.000; el resto produjo 8.746 pares de preguntas emparejadas con imágenes, y 254 se duplicaron en ambos lados para llevar cada conjunto a 9.000. Las mismas imágenes, los mismos checkpoints base, los mismos hiperparámetros, los mismos 140 pasos. La única variable son las preguntas.

Los datos de ZoomGain superan a los datos de ZwZ en todos los ejes que reporta el artículo. En Qwen3.5-4B, la puntuación held-in pasa de 40.99 a 55.81 y el promedio held-out de trece benchmarks pasa de 58.94 a 63.96; en Qwen3.5-9B, el mismo par de números es 44.07 a 55.48 y 62.53 a 66.10. Ese es un resultado real y bien controlado sobre cómo se genera la supervisión, y es la contribución que anuncia el título del artículo.

Qwen3.8-27B no contribuye en nada a ese argumento. Aparece una vez, como una sola fila entre otros 27 modelos evaluados. Es una vara de medir —un generalista competente medido en una distribución para la que nadie lo entrenó—, no un competidor. El propio texto del artículo es explícito en que la brecha que explota es compartida: los distractores de error de visión global representan el 71,7 % de todas las respuestas incorrectas en los 28 modelos, por encima del 54,5 % que produciría una elección aleatoria entre las opciones, y los cuatro modelos de código cerrado que no participaron en la construcción del benchmark muestran el mismo comportamiento, con un 75,7 % frente al 57,4 % esperado.

La ablación es el argumento más sólido contra el titular.

Los autores se hicieron la obvia prueba de coherencia, y el resultado es la tabla más informativa del artículo. Reentrenaron con las mismas 9.000 preguntas dos veces, eliminando cada vez una de las dos decisiones de diseño que definen su pipeline: la regla de que las preguntas solo pueden construirse a partir de detalles invisibles en la imagen completa, y la etapa dedicada de generación de distractores.

• Pipeline completo. ZoomGainBench 55,81; promedio sobre los diez benchmarks de retención que reporta la ablación, 60,96.

• Distractores dedicados eliminados. ZoomGainBench 46.85 —una pérdida de 8.96 puntos en la prueba held-in— y el promedio de los diez benchmarks de 59.14, una pérdida de 1.82.

• Se eliminó la evidencia incremental. ZoomGainBench 49,71, una pérdida de 6,10 — y la media de los diez benchmarks 58,57, una pérdida de 2,39.

Ambas decisiones de diseño valen de seis a nueve puntos en ZoomGainBench y unos dos puntos en todo lo demás. Los autores explican el motivo sin rodeos: eliminar los distractores dedicados «provoca la mayor caída en el ZoomGainBench retenido» porque «las opciones del benchmark se construyen con el mismo pipeline». En otras palabras, cerca de tres cuartas partes de la ganancia principal en el benchmark que produjo la cifra principal corresponden a que el modelo aprende a responder el tipo de pregunta que escribe el pipeline, no a que aprenda a ver mejor.

Lo que sobrevive de todo eso sigue siendo sustancial. En los trece benchmarks que el entrenamiento nunca tocó, Qwen3.5-4B pasa de 57,86 a 63,96 —6,10 puntos a partir de 9.000 muestras— con las mayores ganancias justamente en la familia a la que apunta el pipeline: HR-Bench 4K de 81,25 a 87,25, V*Bench de 81,68 a 90,05, VisualProbe de 43,30 a 57,28, O3-Bench de 54,20 a 63,19. Un benchmark retrocede: TreeBench, de 49,38 a 49,14, un quinto de punto. MMStar, una suite multimodal general, pasa de 66,80 a 72,53, y BabyVision sigue flojo, en 21,13.

Ese perfil es la firma de una intervención estrecha, y es el perfil en torno al cual deberías planificar. El modelo mejoró a la hora de resolver cosas pequeñas en una escena. No se convirtió en un mejor generalista, y la aritmética que dice lo contrario es aritmética hecha sobre su propio benchmark.

Lo que el benchmark realmente pregunta, ya que eso es lo que estarías comprando.

Si el uso previsto es la comprobación de detalles finos, la composición de la prueba importa más que la puntuación global, y el análisis de errores del artículo es inusualmente concreto al respecto.

• Los anclajes pequeños dominan.La precisión aumenta con la fracción de la imagen que ocupa el detalle consultado, para cada grupo de modelos: promediada sobre los 28, se eleva del 28,9 % en el cuartil más pequeño, donde el anclaje cubre menos del 0,4 % de la imagen, hasta el 55,2 % en el más grande.

• Contar es contar números pequeños. 67 de las 94 preguntas de conteo tienen un valor de referencia de como máximo tres, y el 71,6 % de las respuestas numéricas incorrectas difieren en exactamente uno. La dificultad está en resolver unas pocas instancias pequeñas, no en enumerar muchas.

• El reconocimiento de atributos es la categoría difícil. Produce la puntuación más baja en 23 de los 28 modelos, y adivinar de forma uniforme entre las opciones ya daría alrededor del 21,5 %.

• El modo de fallo es la sustitución plausible según la escena. En un caso documentado, 46 de 56 evaluaciones llaman naranja a un objeto blanco en el salpicadero de un camión — plausiblemente el color del chaleco que lleva el trabajador de pie frente a él. En otro, casi todas las evaluaciones nombran una marca de equipamiento de hockey en lugar del logotipo realmente impreso en la prenda. Los modelos no dicen «no puedo verlo»; responden a partir del contexto.

Ese modo de fallo es el argumento práctico a favor de este tipo de entrenamiento, porque es el mismo que hace que un pipeline de documentos se equivoque de forma silenciosa en una factura escaneada. También es el argumento a favor de medirlo: un modelo que sustituye una respuesta plausible produce una salida con seguridad aparente, así que nada aguas abajo lo detecta.

Donde Qwen3.8-27B está en otra habitación

El 44.81 es real, y también es el único número de este artículo sobre el que se juzga aquí a Qwen3.8-27B. Su propia ficha informa de un conjunto de cosas completamente distinto, y ninguno de ellos puede compararse con los números de ZoomGain porque los dos modelos nunca se ejecutaron en el mismo arnés para ellos.

• Programación agéntica. Terminal Bench 2.1 en 73.0, SWE-bench Pro 61.7, LiveCodeBench v6 90.3, QwenSWEBench 79.0 — todo reportado por el proveedor en la propia ficha de Qwen, con las notas del arnés publicadas junto a ella.

• Razonamiento y uso de computadora. GPQA Diamond 89.2, HLE 30.8, OSWorld-Verified 84.3, WebArena-Verified 64.8.

• Trabajo multimodal. OmniDocBench 1.5 en 91.1, razonamiento CharXiv 83.7 sin inyección de cadena de pensamiento y 90.2 con ella, RealWorldQA 85.9, MathVision 90.0.

• Superficie de capacidades. Pensamiento activado por defecto con reasoning_effort en xhigh, medio o bajo, pensamiento conservado entre turnos, llamada nativa a herramientas, salidas estructuradas, entrada de video, 262.144 posiciones de forma nativa y ampliable a un millón.

ZoomGain-4B no ha sido evaluado en ninguno de estos y no cabría esperar que le fuera bien en ninguno: su entrenamiento nunca tocó código, tareas de terminal, documentos ni gráficos. Tampoco tiene ninguna evaluación reportada en modo de pensamiento —el propio arnés de la versión se ejecuta con el pensamiento desactivado a temperatura 0, por lo que todo lo publicado sobre él describe su comportamiento de respuesta directa. El 44.81 de Qwen3.8-27B se midió de la misma manera, con enable_thinking=false, que es lo único que hace que la comparación sea justa y lo único que deja sin probar el mejor modo de Qwen.

Dicho sin rodeos: en el eje para el que se entrenó ZoomGain-4B, gana, y en los ejes para los que se construyó Qwen3.8-27B, el 4B no está ni en la sala. Ninguna de esas dos cosas sorprende, y tratar cualquiera de ellas como la historia completa es justo cómo una página de comparación se vuelve inútil.

Cuánto cuesta poner en marcha cada uno, y el que puedes llamar hoy mismo

Aquí es donde ambos divergen de una manera que decide el despliegue y no el benchmark.

ZoomGain-4B no tiene ningún endpoint alojado en ningún sitio. Lo que existe es el repositorio BF16, 4,54 mil millones de parámetros repartidos entre un modelo de lenguaje y un codificador visual independiente, y tres compilaciones GGUF: Q4_K_M de 2,71 GB, Q8_0 de 4,48 GB y F16 de 8,42 GB, cada una emparejada con su propio mmproj proyector —0,23 GB, 0,36 GB y 0,67 GB respectivamente—, que la ficha GGUF indica que es necesario para la entrada de imágenes. Ejecutarlo requiere llama-mtmd-cli o llama-server de una compilación de llama.cpp lo bastante reciente como para conocer la multimodalidad de Qwen3.5; ejecutarlo a precisión completa requiere vLLM 0.19.1 con transformers 5.7.0. No hay compilación MLX, ni ONNX, ni modelo borrador para decodificación especulativa, ni proveedor al que recurrir si tu compilación falla.

Qwen3.8-27B está en el catálogo de OrcaRouter, y ejecutamos esos pesos en nuestra propia infraestructura en lugar de revender el endpoint de otro — por eso el precio de la página de nuestro modelo es el precio, sin ningún margen añadido por encima ni un precio de lista de proveedor inflado por el medio. Son $0.33 por millón de tokens de entrada y $2.40 por millón de salida, con texto, imagen y vídeo de entrada, 262.144 tokens de contexto y una sola clave. Esa misma clave también da acceso a Qwen3.8-Flash a $0.15 y $0.47 por millón con una ventana de un millón de tokens, y a Qwen3.8-Max a $2.00 y $6.00, de modo que una carga de trabajo que supere el 27B o necesite una ventana más larga se traslada sin un segundo contrato ni un cambio de código. La conmutación por error es la parte que importa para cualquier cosa con forma de producción: un proveedor que se atasca reintenta antes de que empiece la respuesta, en lugar de después de que tu solicitud agote el tiempo de espera.

ZoomGain-4B no está en ese catálogo y no se puede invocar a través de nosotros. Es una carpeta de pesos que sirves tú mismo, y la versión honesta de la recomendación tiene que empezar ahí.

¿Quién debería actuar y qué sigue sin confirmarse?

Si tienes trabajo con muchas imágenes en el que la respuesta depende de un pequeño detalle —el número de pieza en una etiqueta, un color en una pantalla, si hay dos tornillos o tres—, un modelo de 4,54B que fue entrenado con RL específicamente para eso, ejecutándose localmente en 2,71 GB en Q4_K_M, es una segunda opinión barata y creíble que puedes usar junto a un generalista alojado. No en lugar de uno. El perfil de fallo del especialista es la sustitución con confianza, que es exactamente el fallo que detecta la comprobación de un generalista, y viceversa.

Si tu carga de trabajo son documentos, gráficos, capturas de pantalla, vídeo, código o agentes, el 27B es al que hay que recurrir, y el 44.81 en un benchmark de detalle fino para el que nadie lo entrenó no es motivo para pensar lo contrario.

Lo que sigue sin confirmarse y merece la pena vigilar en lugar de dar por sentado:

• La licencia de los pesos. Apache 2.0 cubre el código. El checkpoint no lleva ninguna etiqueta de licencia y la tarjeta se remite a «los términos de cada conjunto de datos y checkpoint» sin especificarlos. Hasta que eso se resuelva, el despliegue comercial es una conversación con un abogado, no una casilla que marcar.

• Cualquier reproducción.Todas las cifras anteriores son reportadas por los autores y producidas con el propio arnés de los autores. El benchmark y el evaluador son públicos, por lo que es verificable, pero nadie fuera de Ant Group y Zhejiang University lo ha comprobado.

• Si la mejora se generaliza más allá del pipeline. Las cifras de validación son las que hay que tener en cuenta; son modestas —6,10 puntos por encima del promedio de trece benchmarks del modelo base— y se inclinan fuertemente hacia la familia de grano fino que el entrenamiento tenía como objetivo. Si eso se transfiere a tus imágenes es una pregunta abierta que la publicación no responde.

• Si aguanta en Q4. La ficha del GGUF advierte de que la cuantización puede afectar a la precisión, y no hay nada publicado que compare las compilaciones cuantizadas con el checkpoint BF16 en ZoomGainBench. Para un modelo cuyo valor entero reside en el detalle fino, ese es el experimento que hay que hacer antes de fiarse de un archivo de 2,71 GB.