LFM3-VL-2B frente a WeVisOne-VL-4B: qué se consigue realmente con 2,5× los parámetros

La propia tabla de benchmarks de Tencent argumenta en contra de la compra obvia. WeVisOne-VL-4B, el más grande de los dos modelos de percepción que el equipo de WeChat Vision publicó el 22 de octubre de 2026, es peor en matting alfa con indicación de caja que su propio hermano de 2B: 7,3 de diferencia absoluta media en P3M-500-NP frente al 6,6 del 2B, donde cuanto más bajo, mejor. No obstante, el modelo con el que la mayoría de los compradores lo comparará realmente no es su hermano, sino LFM3-VL-2B —el modelo de visión en dispositivo de 1,92B de Liquid AI, cuyos pesos aparecieron el 19 de octubre y que se anunció junto con el resto de la familia LFM3 el 27 de octubre.

Si se ponen esos dos lado a lado, la pregunta interesante no es cuál es más inteligente. Es qué se gana con dos veces y media los parámetros y qué cuestan. La respuesta breve, según las propias tablas de los proveedores: se gana detección densa, precisión de referencias y una tasa mucho mejor de negarse a responder cuando el objeto no está. No se gana un generalista, no se gana vídeo y no se gana un modelo que se pueda poner en un teléfono. Todo lo que sigue procede de las dos tablas publicadas, con las costuras a la vista: ningún banco de pruebas independiente ha reproducido las cifras de ninguno de los dos modelos.

Lo que realmente es cada uno

LFM3-VL-2B tiene 1,92B de parámetros densos: un backbone de lenguaje de 1,73B, un codificador de visión propio de 164M y un proyector de 25M. El backbone es la pila tri-híbrida de Liquid: 24 capas divididas en 13 convoluciones cortas con compuertas, 5 capas de atención de ventana deslizante con una ventana de 256 tokens y 6 capas de atención global. Acepta texto, imágenes y vídeo a resolución nativa, muestrea vídeo a 2 fotogramas por segundo, admite un contexto de 128K tokens, cubre 16 idiomas y tiene un modo de pensamiento opcional que genera una pasada de razonamiento antes de la respuesta. Su salida es prosa.

WeVisOne-VL-4B se basa en una arquitectura base Qwen3-VL y se llama 4B, aunque los metadatos de Hugging Face lo redondean a 5B y las publicaciones de terceros sitúan el recuento real cerca de 4,83B. Más que responder en prosa, emite geometría: cajas y puntos como tokens de coordenadas normalizadas de 0 a 1000, un marcador OBJ (id. de token 152678) después de cada caja predicha, y la cadena literal None cuando el objetivo está ausente. Las máscaras y los mattes alfa requieren un segundo artefacto, mask_decoder.pt, un decodificador de píxeles de 9,6 M de parámetros que toma el estado oculto de cada token OBJ y la caja predicha y devuelve alfa a resolución completa con stride 1. Es de un solo turno y solo para imágenes, y genera directamente una salida estructurada, sin cadena de pensamiento.

El contraste en una sola pasada:

• Tamaño — LFM3-VL-2B denso de 1,92B frente a WeVisOne-VL-4B de aproximadamente 4,83B, más un decodificador de 9,6M que es obligatorio para las máscaras

• Entrada — texto, imagen y vídeo a 2 fps frente a texto y una sola imagen

• Salida — prosa y una pasada de pensamiento vs. tokens de coordenadas, cajas, máscaras, mattes o un None explícito

Contexto — 128K tokens frente a ningún límite de inferencia publicado en la ficha; el artículo describe el entrenamiento con 4,096 y 8,192 tokens

• Cobertura de idiomas — 16 idiomas indicados frente a ninguno indicado

• Licencia — LFM Open License v1.0, gratuita para uso comercial con ingresos anuales inferiores a $10M, frente a Apache 2.0 para el código autorado por Tencent

• Entorno de ejecución — GGUF/llama.cpp, MLX de 4 bits, ONNX y BF16 frente a BF16 mediante Transformers, vLLM o SGLang

La mejora es desigual, y el artículo muestra dónde.

WeVisOne-VL-2B y WeVisOne-VL-4B son la misma arquitectura en dos escalas, entrenados con las mismas aproximadamente 100 M de imágenes mediante el mismo currículo de tres etapas y evaluados en la misma tabla. Eso hace que la comparación entre hermanos sea la evidencia más limpia disponible sobre qué hacen los parámetros adicionales, y no apunta en una sola dirección.

Donde el 4B gana claramente, según las cifras de Tencent:

• Detección Dense200: 71.3 de F1 medio frente a 61.4, la mayor ganancia individual

• LVIS — 55,3 frente a 53,3, una modesta mejora de 2 puntos

• Detección referencial de RefCOCOg — 81,8 en test frente a 78,2

• Segmentación referencial de RefCOCO — 84.5 cIoU en testA frente a 82.9

• ReasonSeg — 71,2 cIoU en val frente a 60,9, un salto de 10 puntos en segmentación de razonamiento

• Apuntado de PointBench — 71,9 vs 62,9

• Matting de referencia WeRefMat: 9,8 de diferencia absoluta media en la partición de referencia frente a 15,8, una reducción del error del 38 %

Donde no lo hace:

• mateado de caja del P3M-500-NP — 7,3 frente al 6,6 del 2B, peor

• Revestimiento de caja PPM-100 — 6,1 vs 5,3, peor

• Ref-ZOM cIoU — 72.2 en test frente a 73.4, el 2B vuelve a estar por delante

El patrón es legible aunque la causa no se haya publicado: el 4B se adelanta en tareas difíciles y condicionadas por el lenguaje —segmentación por referencia, segmentación con razonamiento, matting por referencia en escenas reales— y no aporta nada en los conjuntos más fáciles de matting con caja como indicación, donde ambos modelos ya están cerca del techo y puede que el decodificador de 9.6M esté haciendo la mayor parte del trabajo. Dos de los tres benchmarks de matting con caja como indicación van en la dirección equivocada. Si el alpha matting sobre una caja proporcionada es tu única tarea, el 4B no es una mejora; es una forma más cara de obtener la misma respuesta, ligeramente peor.

Objetos ausentes: mejor, aún sin resolver

La columna más útil del artículo es la que casi ninguna ficha de modelo de visión publica. RefCOCOg-Rej es una variante en la que cada expresión se modifica para que no exista ningún objeto coincidente en la imagen. Un modelo que no sabe decir «no» inventará una caja, y todo recorte, recuento y máscara posteriores heredan esa fabricación.

WeVisOne-VL-4B rechaza correctamente el 67,4 % de las veces, frente al 50,2 % del 2B. Es una mejora real y considerable: una ganancia de 17 puntos que cambia el modo de fallo de un pipeline de cara o cruz a dos de cada tres. También significa que el 4B sigue devolviendo una caja con alta confianza en aproximadamente una de cada tres consultas sobre un objeto ausente. En WeRef-Bench, el benchmark interno de Tencent, la tasa de rechazo es del 96,4 %, pero ese benchmark consta de 2.880 consultas en inglés y chino creadas por el propio laboratorio, así que mide una distribución más favorable que la pública. El resumen honesto es que el modelo tiene un comportamiento de abstención utilizable y no ha resuelto el problema; si tu aplicación no puede tolerar una región alucinada, esto necesita un umbral o una segunda comprobación adicional, elijas el modelo que elijas.

El número que parece comparable y no lo es.

Es tentador poner el 90.5 RefCOCO-avg de LFM3-VL-2B junto al 81.8 RefCOCOg de WeVisOne-VL-4B y anunciar una victoria de 8.7 puntos para el modelo más pequeño. No lo haga. Son particiones distintas y métricas distintas: Liquid reporta un promedio en toda la familia RefCOCO, Tencent reporta el F1 de test de RefCOCOg para detección referencial. Restarlos produce un número sin referente.

La misma trampa está presente en OCR. LFM3-VL-2B obtiene 86,3 en OCRBench v1, una prueba compuesta por reconocimiento de texto, detección de texto y razonamiento; WeVisOne-VL-4B obtiene una media F1 de 52,0 en TotalText, un benchmark de localización de texto en escenas. Una es un examen amplio; la otra, una tarea de predicción densa. No son la misma habilidad medida dos veces.

Así que las dos tablas de proveedores no coinciden en una única cifra comparable. Lo que se puede comparar con honestidad son las capacidades y el costo, y por eso el resto de esta comparación trata de la idoneidad y no de una clasificación. Cualquiera que publique un ganador a partir de estas dos tablas se lo está inventando.

La memoria es el verdadero precio

Ninguno de los dos modelos tiene un precio publicado por token a 28 de octubre de 2026. La ficha de Liquid enlaza el acceso a la API y a Playground a través de su consola, pero no se publicó ninguna tarifa para LFM3-VL-2B; los rastreadores de terceros que listan las tarifas de los modelos de texto de Liquid no cubren el modelo de visión. Tencent no tiene ningún endpoint alojado. Por lo tanto, la comparación es una comparación de autoalojamiento, y la factura se expresa en memoria.

• LFM3-VL-2B — aproximadamente 3,84 GB en BF16 calculado aritméticamente a partir del número de parámetros, con compilaciones de 4 bits de MLX, GGUF y ONNX publicadas junto a él

• WeVisOne-VL-4B — aproximadamente 9,7 GB en BF16 según estimaciones de terceros, alrededor de 19 GB en F32, más el mask_decoder.pt requerido

Esa diferencia de 2,5× no es solo una GPU más grande. Es otra clase de dispositivo. La ficha del LFM3-VL-2B deja claro que el modelo está pensado para trabajo en el dispositivo —preguntas sobre vídeo, documentos, gráficos y pantallas de aplicaciones, localización de objetos, razonamiento espacial para robots— y las compilaciones MLX de 4 bits y GGUF son la forma de cumplir esa promesa: un portátil, un teléfono, un chasis de robot. Las rutas documentadas del WeVisOne-VL-4B son Transformers, vLLM y SGLang en BF16, sin una compilación cuantizada oficial y sin runtime en el dispositivo. Quiere una GPU de servidor.

Conviene comprobar la compatibilidad del framework con tu propia ruta en lugar de con la tabla. El vídeo a 2 fps es una capacidad del modelo en LFM3-VL-2B, pero si un runtime concreto acepta una cuadrícula de vídeo es una cuestión aparte, y la tarjeta del modelo, los ports y las PRs upstream no siempre han estado de acuerdo en eso. Prueba la combinación exacta que piensas desplegar.

OrcaRouter no aloja ninguno de los dos modelos. Eso está verificado contra el catálogo el 28 de octubre de 2026, no es una suposición — ni la línea LFM3 de Liquid ni WeVisOne de Tencent aparecen en la lista de modelos —, así que nada de lo que aquí se dice debe interpretarse como una vía de acceso a ninguno de ellos. Lo que el catálogo de modelos de OrcaRouter sí incluye es Qwen3-VL-8B, en variantes instruct y thinking, que es la opción pragmática si su requisito real es un modelo de visión alojado con un precio publicado hoy, en lugar de un checkpoint autoalojado. Una sola clave da acceso a todo ello al precio de lista del proveedor, sin recargo, y si está creando un prototipo con un modelo de pesos abiertos aún no probado, ejecutarlo a través de un enrutador con conmutación por error es mejor que conectar una ruta de producción a un checkpoint que todavía no ha sido objeto de una evaluación independiente.

¿Cuál elegir?

• Elige WeVisOne-VL-4B cuando el entregable sea geometría —máscaras, mattes alfa, cajas densas, recuentos, señalamiento— sobre imágenes fijas, cuando las consultas estén condicionadas por el lenguaje en lugar de por cajas, y cuando tengas una GPU de sobra

• Elige {{1}}WeVisOne-VL-2B{{/1}} en lugar del 4B cuando tu tarea sea matting con indicación de caja en escenas normales; según las cifras publicadas, el modelo más pequeño es mejor en eso y requiere menos de la mitad de memoria

• Elige LFM3-VL-2B cuando la entrada incluya video, cuando el documento sea largo, cuando la respuesta deba ser una oración en lugar de un polígono, o cuando el dispositivo no sea un servidor.

• No elijas ninguno si necesitas un endpoint alojado con un precio por token publicado esta semana — ninguno de los proveedores ofrece uno, y por mucho benchmarking que se haga no se cierra esa brecha

• Elige ambos solo si aceptas dos esquemas de salida y dos rutas de integración; la banda de parámetros compartida de "aproximadamente 2B a 5B" disfraza dos productos diferentes

¿Qué cambiaría esto?

Tres cosas. Un banco de pruebas independiente que ejecute ambos modelos sobre las mismas imágenes con los mismos prompts; hasta entonces, todo lo anterior es una tabla de proveedor leída con cuidado, lo cual es mejor que una tabla de proveedor leída sin cuidado, pero no es evidencia de calidad. Una compilación cuantizada de WeVisOne, o un entorno de ejecución en el dispositivo, lo que trasladaría el argumento de la memoria de decisivo a negociable. Y un precio publicado por token de cualquiera de las partes, que reemplazaría la aritmética sobre gigabytes por un número con el que alguien pueda hacer presupuesto.

El menos probable de los tres es el que más importaría para este emparejamiento específico: el soporte de vídeo en el decodificador de píxeles de WeVisOne. Ahora mismo, el generalista de 2B acepta vídeo y el instrumento de 4B no puede, y ningún número de parámetros arregla una modalidad que nunca se entrenó.