WeVisOne-VL-2B vs LFM2.5-VL-3B: un creador de máscaras contra un lector de pantalla

Dale a ambos modelos la misma fotografía y la misma frase —«el perro de la izquierda»— y vuelven dos cosas distintas. LFM2.5-VL-3B responde con una ubicación y, si se lo pides, una descripción: una caja, un punto o una frase breve sobre lo que encontró. WeVisOne-VL-2B también responde con una caja, y luego un pequeño decodificador convierte esa caja en una máscara alfa de bordes suaves que podrías componer sobre un fondo nuevo sin un halo alrededor del pelaje. Un modelo se creó para leer una interfaz y responder. El otro se creó para entregarte píxeles.

Esa diferencia es toda la comparación, y se mantiene en cada tabla de benchmarks que cualquiera de los dos proveedores ha publicado. También explica por qué los dos modelos rara vez se evalúan uno frente al otro: la ficha de Liquid AI no menciona WeVisOne, el artículo de Tencent no menciona a Liquid, y ningún tercero los ha ejecutado en paralelo. A continuación se presenta lo que cada lanzamiento realmente consignó, cuáles de sus cifras pueden compararse entre sí y cuáles no.

Dos lanzamientos, dos cantidades de evidencia muy diferentes

LFM2.5-VL-3B fue publicado por Liquid AI el 11 de agosto de 2026 —primero los pesos, el anuncio al día siguiente— y llegó con una tabla numérica de benchmarks, una línea base con nombre para cada fila y una sección de velocidad medida en hardware identificado. Es un modelo denso de 3,12 mil millones de parámetros: una columna vertebral lingüística LFM2.5-2.6B combinada con un codificador de visión SigLIP2 NaFlex 400M, un contexto de 32.768 tokens, un vocabulario de 128.000 tokens y dieciséis idiomas identificados. Su licencia es la propia LFM Open License v1.0 de Liquid, que es gratuita para uso comercial por debajo de un umbral de ingresos en lugar de gratuita sin condiciones.

{{1}}WeVisOne-VL-2B{{/1}} fue publicado por {{2}}Tencent{{/2}}, concretamente por su equipo {{3}}WeChat Vision{{/3}}, el 22 de octubre de 2026, y su ficha del modelo no contiene en absoluto ninguna tabla de benchmarks —ni puntuaciones, ni longitud de contexto, ni cifras de rendimiento, ni requisitos de hardware. Las cifras existen, pero están en el artículo que lo acompaña, que reporta siete tablas de tareas en lo que los autores describen como más de treinta benchmarks. Así que los dos lanzamientos no son solo modelos diferentes; son tipos de documento diferentes. {{4}}Liquid{{/4}} publicó una especificación de producto. {{5}}Tencent{{/5}} publicó un resultado de investigación y dejó la hoja de especificaciones casi en blanco.

Esa asimetría importa cuando se lee una comparación como esta. Las cifras de Liquid se reunieron para leerse frente a sus propias líneas de base. Las de Tencent se reunieron para ganar una tabla académica. Ninguno de los proveedores eligió sus números pensando en el otro modelo, y precisamente por eso los números no coinciden.

El número que parece comparable y no lo es

Ambos modelos publican una puntuación de RefCOCO, y ponerlos uno al lado del otro produce un titular de aspecto limpio: LFM2.5-VL-3B con 87,9 frente a WeVisOne-VL-2B con 79,7. Esa comparación no tiene sentido, y merece la pena explicar por qué, porque ese mismo error se está cometiendo ahora mismo en hojas de cálculo.

• Liquid informa de RefCOCO precision@1 promediada entre las divisiones. Es una estadística de detección: ¿la caja predicha mejor clasificada se superpuso lo suficiente con la caja real de referencia como para contar como correcta?

• El 79,7 de Tencent aparece en una tabla de segmentación, y el artículo indica claramente que las cifras de la familia RefCOCO que figuran allí son IoU acumulada: intersección total sobre unión total en todo el conjunto de evaluación.

• La tabla de Tencent para detección referencial no reporta RefCOCO en absoluto. Reporta RefCOCOg, donde el 2B obtiene una F1 media de 77.1.

Así que el 87.9 y el 79.7 miden tres cosas diferentes en dos tareas distintas. Una caja delimitadora que apenas se solapa con un objetivo puede obtener una buena puntuación en precision@1 y una mala en cIoU; una máscara que cubre bien un objeto grande puede obtener una puntuación alta en cIoU mientras su caja delimitadora es imprecisa. No hay ninguna operación aritmética que las concilie.

La misma trampa está presente en el OCR. Liquid publica OCRBench v1 con 84,2 y OCRBench v2 en inglés con 47,5 — benchmarks de transcripción. Tencent publica OCR como F1 de localización con un umbral de IoU de 0,5: 62,1 en SROIE, 42,6 en ICDAR2015, 42,5 en TotalText, 30,5 en HierText. Esos miden si el modelo encontró y delimitó el texto, no si lo leyó correctamente. Citar «84,2 frente a 62,1» sería comparar una prueba de lectura con una prueba de señalamiento.

¿Qué es realmente una comparación justa?

Quita las puntuaciones y los dos modelos se alinean en dimensiones que no necesitan un arnés:

• Tamaño — aproximadamente 3,12B de parámetros densos para LFM2.5-VL-3B frente a aproximadamente 2B para WeVisOne-VL-2B, además de un decodificador de 9,5M de parámetros que debe descargarse por separado y es necesario para las salidas densas.

• Base — el backbone híbrido LFM2.5-2.6B propio de Liquid frente a Qwen3-VL.

• Contexto — 32.768 tokens publicados en la tarjeta frente a ninguna longitud de contexto publicada. Las etapas de entrenamiento del artículo de WeVisOne se ejecutaron con 4.096 y 8.192 tokens, y la inferencia limita cada imagen a 1.960 tokens visuales, pero nada de eso constituye una ventana de despliegue.

• Tipos de salida: cajas, puntos y texto frente a cajas, puntos, máscaras binarias y mattes alfa continuos.

• Razonamiento — LFM2.5-VL-3B es deliberadamente no razonador, y responde directamente para mantener baja la latencia; WeVisOne también es no razonador, pero por una razón distinta: genera salida estructurada sin cadena de pensamiento para lograr eficiencia de inferencia. Ninguno de los modelos "piensa" antes de responder, y ningún proveedor pretende lo contrario.

• Llamada a herramientas: compatible y evaluada en LFM (ToolSandbox 59,5; BFCL v4 32,5) frente a una capacidad no declarada en WeVisOne.

• Idiomas — dieciséis indicados en la tarjeta LFM frente a no indicados en la tarjeta WeVisOne.

• Licencia — LFM Open License v1.0, con un umbral de ingresos, frente a Apache 2.0 para el código creado por Tencent.

• Compilaciones cuantizadas — exportaciones GGUF, ONNX y MLX ofrecidas por Liquid frente a ninguna anunciada por Tencent.

• Evaluación independiente: ninguno de los modelos tiene una entrada en Artificial Analysis hasta la fecha. Todas las cifras de este artículo, de ambos proveedores, están reportadas por los propios proveedores.

La brecha de despliegue es más amplia que la brecha de parámetros.

LFM2.5-VL-3B se diseñó para funcionar en un teléfono y la ficha lo demuestra con cifras: menos de 3,3 GB de memoria, 20 tokens por segundo en un Galaxy S26 Ultra, 228 tokens por segundo en un Apple M5 Max, 116 en un AMD Ryzen AI Max+ 395 y unos 11.000 tokens de salida por segundo con alta concurrencia en una sola H100. Se distribuye en formatos que los entornos de ejecución de consumo pueden cargar realmente.

WeVisOne-VL-2B no publica nada de eso. Lo que sí publica implica una cuenta diferente. La etapa final del decodificador produce una máscara alfa a resolución completa con stride 1, lo que significa que la salida densa tiene el tamaño de la imagen de entrada en lugar de un vector de tamaño fijo: un costo que escala con la resolución, no con el número de parámetros. Para un modelo de 2B en una GPU moderna, eso es manejable. Para un teléfono, no es evidentemente manejable en absoluto, y Tencent no ha afirmado que lo sea.

La consecuencia práctica es que estos dos modelos no compiten por el mismo espacio de despliegue. Uno es un componente que se podría distribuir dentro de una aplicación. El otro es un componente que se ejecutaría en un servidor, o en una estación de trabajo, junto a cualquier otra cosa que necesite enmascaramiento.

Elige por tipo de salida, no por puntuación

Si el trabajo consiste en leer una pantalla —analizar un flujo de pago, encontrar el botón etiquetado «Continuar», extraer una tabla de un documento fotografiado—, LFM2.5-VL-3B es el candidato obvio. Tiene ScreenSpot-v2 en 80,7, DocVQA en 91,1, ChartQA en 81,3 y una puntuación en ToolSandbox que sugiere que puede actuar sobre lo que ve en lugar de limitarse a describirlo. También tiene una media de 69,4 en 28 benchmarks que Liquid publica frente a modelos de su misma familia mencionados por nombre, lo que al menos te dice cómo ve el proveedor su propio segmento.

Si el trabajo consiste en aislar un objeto —un recorte de producto, una persona sobre un fondo recargado, un primer plano con cabello suelto o un borde transparente—, LFM2.5-VL-3B no genera esa salida y ninguna cantidad de prompting logrará que lo haga. WeVisOne-VL-2B sí lo hace, y el margen en las tablas de matting es amplio: 6,6 de diferencia absoluta media frente a 15,4 de SAM2-Matting en P3M-500-NP, y 15,8 frente a 23,0 de una canalización de Qwen3-VL-8B más SAM2 en el split WeRefMat con prompt de lenguaje.

Hay un caso más en el que WeVisOne tiene una afirmación que merece la pena destacar: la ausencia. Tencent informa de una tasa de rechazo del 50,2 % en RefCOCOg para consultas cuyo objetivo no está en la imagen, frente a 0,5 y 0,6 de dos modelos especializados de grounding en la misma tabla. Si tu pipeline ejecuta miles de recortes y la mayoría no contiene nada que te importe, un modelo que diga de forma fiable «no está» te ahorra un clasificador posterior. La ficha de LFM2.5-VL-3B no informa de una cifra de rechazo comparable, así que no hay nada que poner al lado — una laguna en la evidencia, no una pérdida.

Nada de esto es motivo para elegir uno y retirar el otro, y vale la pena ser honestos sobre dónde encaja un enrutador. OrcaRouter no sirve ninguno de los dos modelos; ninguno está en nuestro catálogo, y ninguno está alojado en ningún lugar que podamos verificar para WeVisOne en particular. Lo que sí ofrecemos es el stack que lo rodea: si tu pipeline usa un modelo de visión alojado para la mitad de lectura y un modelo autoalojado para la mitad de enmascaramiento, las llamadas alojadas pasan por una sola clave de API al precio de lista del proveedor y sin recargo, la conmutación por error las traslada a otro proveedor cuando uno se degrada, y el DSL de enrutamiento te permite poner ambas mitades detrás de un único endpoint para que tu aplicación nunca sepa cuál respondió.

¿Qué lo resolvería realmente?

Un único arnés independiente, ejecutado por alguien que no pertenece a ninguno de los dos proveedores, sobre las mismas imágenes, que informe tanto una estadística de detección como una estadística de segmentación para ambos modelos. Eso no existe. Hasta que exista, la postura defendible es la aburrida: estos modelos responden a preguntas distintas, sus cifras publicadas se miden con instrumentos distintos, y la elección entre ellos la decide lo que tu código posterior espera recibir: una frase o una máscara.

Si solo te llevas una cosa de esta comparación, que sea la forma de la evidencia. Liquid AI te dio una tabla que puedes refutar. Tencent te dio un artículo que puedes leer y una ficha que te dice, con franqueza, lo que el modelo no hará. Ninguno de los dos te dio un número que pueda compararse con el otro, y cualquier artículo que imprima 87.9 junto a 79.7 sin esa advertencia te está vendiendo un ranking que no existe.