Xiaomi-Lens-0 quiere entrar en los Transformers estándar — y su decodificador de máscara es el inconveniente

Hoy a las 12:01 UTC, se abrió un pull request con el número 50028 contra huggingface/transformers con el título menos dramático del repositorio: «Add Xiaomi-Lens-0». No es un stub. El diff abarca 19 archivos y 4.251 líneas añadidas, 2.199 de ellas en un único archivo de modelado, además de 552 líneas de pruebas y una página de documentación de 143 líneas. Su estado es la parte poco destacable: abierto, sin revisar, sin fusionar. El modelo que hay detrás es la parte interesante, y lleva seis días en Hugging Face sin ninguna publicación de lanzamiento asociada. Xiaomi-Lens-0 es un modelo multimodal de 4B construido sobre Qwen3.5-4B que escribe máscaras de región como tokens, y la consecuencia práctica es limitada pero real: hasta que se lance un cambio como este, no se puede cargar en absoluto con una clase estándar de Transformers.

Esa brecha —entre que un modelo se pueda descargar y que un modelo sea algo común— es lo que decidirán las próximas semanas. Todo lo que sigue separa lo que Xiaomi publicó de lo que propone un PR de un framework, porque son dos niveles de certeza distintos y la cobertura hasta ahora los ha mezclado.

Qué lanzó realmente Xiaomi, y cuándo

El lanzamiento se produjo por partes a lo largo de cinco días, y eso es parte de por qué se percibió como una publicación de investigación más que como el lanzamiento de un producto.

• Artículo — "Xiaomi-Lens-0 Technical Report", arXiv:2610.23279, enviado el 16 de octubre de 2026, revisado el 19 de octubre.

• Pesos y código — públicos el 21 de octubre en SeerRay-Lab/Xiaomi-Lens-0 en Hugging Face, con un repositorio de inferencia correspondiente en GitHub.

• Licencia: Apache 2.0 para los pesos, con los pesos base Qwen3.5-4B también bajo Apache 2.0. La ficha atribuye la base a Alibaba Cloud y las modificaciones a Xiaomi.

• Equipo — acreditado como Xiaoai Plus y el equipo SeerRay, que es el grupo de comprensión visual de Xiaomi.

• Tamaño — 4B en todas partes, en el título y en el texto del artículo y de la ficha; los metadatos de Hugging Face indican 5B parámetros en BF16. Xiaomi no explica la discrepancia, y la lectura honesta es que "4B" describe el núcleo lingüístico, mientras que el checkpoint completo con la torre de visión resulta ser mayor.

• Alojamiento — la barra lateral de la tarjeta indica que ningún proveedor de inferencia ha desplegado el modelo. No hay una API propia ni un punto de acceso alojado al que llamar.

• Tracción — 723 descargas en el último mes y 25 me gusta en el repositorio de Hugging Face, seis días después de que se publicaran los pesos.

Lo que no pude encontrar fue un lanzamiento: ninguna entrada de blog de Xiaomi, ningún hilo del equipo, ninguna página de producto. La cobertura se remonta al informe técnico y a los artículos de la prensa especializada después de que aparecieran los pesos. Eso importa para cualquiera que intente datar el modelo: el 16 de octubre es el artículo, el 21 de octubre es el artefacto, y ninguno de los dos es un anuncio.

Una máscara es un token, no un segundo modelo

La forma habitual de obtener máscaras de píxeles de un modelo de visión-lenguaje es acoplarle un segmentador. Se obtienen cajas o puntos del lado del lenguaje, se pasan a algo como un decodificador estilo SAM y se paga por una segunda red, un segundo conjunto de pesos y una segunda pasada hacia delante.

Xiaomi-Lens-0 omite eso. El modelo genera un token especial <|mask|>, y el estado oculto de ese token —lo que el artículo llama un latente visual— se usa como consulta contra la cuadrícula de parches del codificador de visión. Una única capa de refinamiento Transformer, una proyección lineal, un producto punto contra cada parche, luego dos pasos de sobremuestreo con convolución transpuesta y una sigmoide. Las características de los parches se toman antes del fusionador espacial, por lo que la cuadrícula sigue siendo de grano fino, y se calculan una vez por imagen y las reutiliza cada token de máscara en la respuesta.

El entrenamiento consta de dos etapas y no resulta sorprendente una vez que la arquitectura está clara. La primera etapa congela el backbone y entrena únicamente el decodificador de máscaras con datos internos, además de Objects365, LVIS, PACO, PhraseCut y la familia RefCOCO. La segunda etapa ajusta conjuntamente el backbone y el decodificador con el objetivo estándar de siguiente token, además de una pérdida de máscara que combina BCE a nivel de píxel y Dice.

La consecuencia que merece la pena tener en cuenta no es el ahorro de parámetros. Es que las máscaras pueden aparecer dentro de el razonamiento, no solo en la respuesta final. Xiaomi entrena con trazas de razonamiento fundamentadas en las que una cadena de pensamiento se refiere a regiones y emite máscaras sobre la marcha, y por eso un modelo de 4B puede responder "¿cuál de estas dos es la que debería recoger?" con una máscara asociada al paso intermedio en lugar de solo a la última frase.

La tabla de referencia, leída correctamente.

Las cifras destacadas son sólidas y todas son de Xiaomi. A día de hoy no hay entrada de Artificial Analysis, ni posición en arena, ni reproducción por terceros. Considera lo siguiente como una afirmación del fabricante con un apéndice inusualmente detallado, no como un hecho medido.

• Segmentación por referencia — 81,4 de cIoU medio en las ocho divisiones de RefCOCO / RefCOCO+ / RefCOCOg, frente a 78,6 de Qwen3-VL-Seg 4B. SAM 3, promediado sobre las mismas ocho divisiones en la propia tabla de Xiaomi, asciende a aproximadamente 71,7.

• Comprensión de referencias — una ganancia media de 5,6 puntos en Prec@0.5 sobre el modelo base Qwen3.5-4B, con RefCOCO+ subiendo 7,6 puntos.

• Grounding multiinstancia en COCO 2017: 63,9 de F1 medio, por delante del 63,0 de GroundingPI y del 46,5 de Qwen3-VL 4B.

• Segmentación por razonamiento — 68,0 gIoU en ReasonSeg Test, el mejor de los modelos comparados.

• Referencia encarnada — 87,0 gIoU en RoboRefIt TestA.

• Conteo — 50,6 en CountQA, 6,8 más que el 43,8 del backbone.

Dos de esos merecen una segunda mirada, porque los resúmenes que circulan los simplifican demasiado.

El primero es el grounding de múltiples instancias de COCO. Xiaomi-Lens-0 supera a GroundingPI en F1 medio, pero en el umbral holgado de IoU 0.50 en realidad pierde: 80.4 de F1 frente a 81.2. La victoria proviene del extremo estricto: 27.4 de F1 con IoU 0.95 frente a 22.8. Es una diferencia significativa de tipo. El modelo produce máscaras más ajustadas, no más cantidad de ellas, y un pipeline que solo comprueba el solapamiento holgado no verá la mejora.

El segundo es LensBench, el benchmark de 1.200 unidades y 4.800 instrucciones que Xiaomi creó y publicó junto con el modelo. Abarca imágenes generales, aéreas, de conducción y panorámicas con revisión humana, y es lo más útil del lanzamiento para cualquiera que trabaje fuera de RefCOCO. También es la prueba en la que el modelo parece menos excepcional. En imágenes generales, Qwen3.8-Max lidera con 74,2 cIoU frente a los 63,9 de Xiaomi-Lens-0. En instrucciones implícitas, el modelo ocupa el quinto lugar, por detrás de Qwen3.8-Max, GPT-5.6-Sol, Gemini-3.6-Flash y Seed-2.1-Pro. Xiaomi publicó un benchmark que su propio modelo no domina por completo, lo que vale más que un resultado perfecto.

Donde el modelo 4B realmente falla

El modo de fallo no es aleatorio. Es la brecha entre una descripción que nombra la cosa y una descripción que la implica.

• De explícito a implícito: el cIoU de máscara cae de 71.4 a 54.7, y el Prec@0.5 de caja, de 85.0 a 70.0 en LensBench.

• Varios objetivos en escenas panorámicas — el peor subconjunto del artículo, donde box Prec@0.5 cae de 81,3 a 48,7 y cIoU, de 71,8 a 48,9.

• Regiones pequeñas, ocluidas y ambiguas: la tarjeta indica explícitamente que las predicciones pueden no detectar objetos o producir cajas y máscaras inexactas en estos casos.

• Conteo — 50,6 en CountQA es una mejora de 6,8 puntos y sigue siendo más o menos una moneda al aire, pero con mejores modales.

También hay una salvedad mecánica que afectará a cualquiera que integre esto en un producto. Las máscaras se decodifican sobre el lienzo de imagen del procesador, no sobre tu archivo original. Si cambias el tamaño antes de la inferencia y olvidas invertir la asignación, la máscara vuelve con la forma correcta y en el lugar equivocado. La ficha indica que se conserven el cambio de tamaño y la asignación de coordenadas; no dice qué ocurre cuando no lo haces, y la respuesta es un error silencioso y de aspecto plausible.

Qué cambia el pull request y qué no

El PR 50028 está en curso desde el 23 de octubre: cuatro commits, y el último se registró aproximadamente un minuto antes de que se abriera la solicitud de extracción. Añade un archivo de configuración, un archivo modular, un archivo de modelado de 2199 líneas, un procesador, un script de conversión de pesos, autoasignaciones para el modelo, el procesador de imágenes y el tokenizador, una página de documentación y 552 líneas de pruebas. Un bot de CI ya ha solicitado la suite de pruebas lentas para xiaomi_lens0. No hay ninguna revisión.

Si se fusiona, cambian tres cosas. La carga pasa a ser con AutoModel y AutoProcessor en lugar de un pip install -e . contra el repositorio de Xiaomi. El modelo queda incluido en la documentación que la gente realmente lee. Y pasa a ser elegible para las herramientas del ecosistema —cuantización, adaptadores, frameworks de entrenamiento— que asumen que existe una clase de Transformers antes de tocar un checkpoint.

Si se fusiona, cuatro cosas no cambian. Sigue necesitando una GPU CUDA con bfloat16 y FlashAttention-2. Sigue sin tener un endpoint alojado. La decodificación de máscaras sigue ejecutándose a través del procesador en lugar de una llamada de generación simple. Y las cifras se mantienen exactamente tal como las reporta el proveedor hoy, porque portar un framework es un evento de empaquetado, no una evaluación.

También vale la pena ser franco sobre el estado. Un PR abierto no es una funcionalidad. Transformers hace fusiones a su propio ritmo, los mantenedores no se han pronunciado y las adaptaciones de este tamaño suelen pasar por varias rondas antes de llegar a fusionarse. Cualquiera que escribiera hoy «Xiaomi-Lens-0 ya funciona en Transformers» se equivocaría por una fusión.

Lo que hace falta para ejecutarlo esta semana.

La vía oficial es el paquete propio de Xiaomi, y presupone una máquina con GPU real.

• Configuración — Python 3.10 o posterior, CUDA con bfloat16 y FlashAttention-2, luego pip install -r requirements.txt y pip install -e . dentro del repositorio de inferencia.

• Imagen única — infer.py toma un checkpoint, una imagen, una consulta de texto y una ruta de salida, y escribe una imagen anotada además del texto generado.

• Formato de salida — los cuadros se normalizan a un rango de 0 a 1000 dentro de las etiquetas <bbox>, las máscaras se emiten como tokens <|mask|> dentro de las etiquetas <mask>, y cualquier contenido dentro de un bloque de pensamiento se excluye de la superposición final.

• Servicio — existe soporte para vLLM, pero se ejecuta como dos servicios coubicados, la generación de texto en el puerto 8000 y la decodificación de máscaras en el 8001, con el cliente en la misma máquina porque pasa una ruta de imagen en lugar de bytes. Si sobrescribes MAX_PIXELS, ambos servicios necesitan el mismo valor.

Existen dos vías comunitarias y ninguna es la de Xiaomi. Un paquete de PyPI llamado xiaomi-lens-mnn reimplementa la inferencia sobre MNN para CPU en fp16 o int8, sin dependencia de torch, y un paquete de nodos no oficial para ComfyUI informa una salida idéntica bit a bit respecto al código oficial. Ambas son señales útiles —el port a MNN en particular, porque sugiere que la arquitectura es lo bastante simple como para reimplementarla en lugar de solo envolverla.

Xiaomi no publica ninguna cifra de VRAM, ninguna medición de latencia ni ningún dato de rendimiento. Para un modelo de 4B, los pesos no son el problema; la torre de visión a alta resolución y la pasada de decodificación de máscaras sí lo son, y ninguna de las dos tiene un coste publicado. Mide antes de dimensionar una flota en torno a ello.

¿Quién debería descargarlo esta semana?

Si necesitas máscaras precisas a nivel de píxel a partir de una descripción en lenguaje natural y controlas el hardware, esta es una de las mejores opciones de 4B disponibles bajo una licencia permisiva, y los pesos no requieren autorización. Las cifras de instrucciones explícitas son competitivas con modelos varias veces más grandes, la arquitectura elimina toda una segunda red de tu pipeline y Apache 2.0 significa que la revisión legal es breve.

Si necesitas un endpoint de segmentación alojado hoy, esto no es eso. Xiaomi-Lens-0 no está en el catálogo de OrcaRouter — no lo servimos, y nada de lo que aquí se dice debe interpretarse como que afirmamos lo contrario. Lo que sí servimos es el conjunto de comparación. Si la verdadera pregunta es si un modelo abierto de 4B supera a un modelo de visión alojado con tus imágenes, el método honesto es ejecutar Lens-0 localmente y llamar al lado alojado mediante una sola clave. Qwen3-VL-8B-Instruct, por ejemplo, está disponible a $0.18 por millón de tokens de entrada y $0.70 por millón de salida, transferido al precio de lista del proveedor sin recargo, y la misma clave llega a el resto del catálogo si quieres una segunda opinión o conmutación por error automática cuando un proveedor se degrada. Esa comparación con tus datos vale más que cualquier tabla del artículo.

¿Qué cambiaría esta evaluación?

Cuatro cosas, en orden aproximado de cuánto importarían.

Un merge del PR 50028, porque convierte un artefacto de investigación en algo que un entorno de Python normal puede cargar. Una evaluación independiente en LensBench o RefCOCO realizada por alguien que no sea Xiaomi, porque las cifras actuales tienen un solo autor y los propios segmentos débiles del artículo sugieren que el promedio oculta una varianza real. Una ruta de máscaras nativa en vLLM o SGLang que reduzca la configuración de dos servicios a un único endpoint, que es la diferencia entre una demo y un despliegue. Y una oferta alojada de cualquier procedencia, que convertiría el modelo en una línea de presupuesto en lugar de un proyecto.

Hasta entonces, la descripción correcta es precisa: Xiaomi-Lens-0 es un modelo real, descargable, Apache-2.0 de 4B con un enfoque poco habitual y bien documentado para la segmentación, de seis días de antigüedad, con cifras sólidas del proveedor, un benchmark publicado que no lo favorece y un port de framework que está propuesto en lugar de entregado. Eso es algo más útil de saber que cualquiera de estas dos cosas: «Xiaomi acaba de lanzar un asesino de Segment Anything» o «no hay nada que ver hasta que se integre».