LFM2.5-VL-3B-DSpark vs LFM2.5-VL-3B: No eliges uno, le acoplas uno

La búsqueda que trae a la gente hasta aquí es una comparación, pero la respuesta honesta es que LFM2.5-VL-3B-DSpark y LFM2.5-VL-3B no son dos cosas entre las que se elija. El segundo es un modelo de visión-lenguaje de 3.1B que puedes descargar y servir. El primero es un modelo borrador de 279.5M de parámetros que existe únicamente para colocarse delante del segundo y hacer que decodifique más rápido. Si sacas el modelo borrador de la pila, no produce nada; no puedes evaluarlo por sí solo, porque "por sí solo" no es una configuración que admita. La verdadera comparación es LFM2.5-VL-3B funcionando solo frente al mismo modelo funcionando con el modelo borrador acoplado.

Léelo así y la decisión se reduce a una sola pregunta: ¿la memoria adicional y la complejidad adicional en tiempo de ejecución te aportan suficiente mejora de latencia como para que importe en tu carga de trabajo? Los propios números de Liquid AI dicen que sí para el trabajo con uso intensivo de decodificación y dicen explícitamente que no cuando predomina el prefill. Ninguno de esos dos lados se ha reproducido fuera de la empresa.

Los dos puntos de control, lado a lado

En lo que se diferencian es toda la historia, así que vale la pena poner los dos repositorios uno al lado del otro antes de que empiece el debate sobre la velocidad.

• Rol — LFM2.5-VL-3B genera texto y responde sobre imágenes; LFM2.5-VL-3B-DSpark propone tokens para que este los verifique y no genera nada utilizable por sí mismo

• Parámetros — 3,1B para el modelo objetivo, 279,5M en BF16 para el modelo borrador, lo que Liquid sitúa como un aumento del 8,9 % en el número de parámetros desplegados

• Arquitectura — el objetivo es un modelo híbrido construido sobre una columna vertebral LFM2.5-2.6B con un codificador de visión SigLIP2 NaFlex; el borrador son 4 capas de atención completa con tamaño oculto de 2,048 con atención de consultas agrupadas más una cabeza de Markov y una cabeza de confianza

• Ventana de contexto — 32.768 tokens para el objetivo; el redactor no tiene contexto propio y hereda el del objetivo

• Codificador de visión — SigLIP2 NaFlex 400M en el objetivo; el borrador no tiene ninguno y nunca ve la imagen directamente

• Vocabulario — 128.000, y el embedding y la LM head del drafter están vinculados al target en lugar de duplicarse, por lo que el coste de memoria es menor de lo que sugerirían 279,5 M de parámetros

• Licencia — ambos se distribuyen bajo la licencia LFM1.0 de Liquid, que figura como «otra» en Hugging Face en lugar de una licencia OSI, así que lee los términos antes de un despliegue comercial

• Formatos — el target se distribuye como cuantizaciones safetensors, GGUF, ONNX y MLX; el drafter se distribuye como safetensors y un único F16 GGUF de aproximadamente 567 MB

Una línea de esa lista merece énfasis porque es la razón mecánica por la que este emparejamiento funciona siquiera: el modelo borrador no es un modelo de visión pequeño. No tiene codificador de visión y nunca toca la imagen. Para cuando los tokens llegan a las capas ocultas de las que parte el borrador, tanto un parche de imagen como un token de texto son solo tensores, así que la modalidad es invisible para el cálculo del borrador. Eso es lo que hizo Liquid: portar a un VLM una técnica desarrollada para modelos de texto sin rediseñarla.

Lo que el redactor cambia, y lo que deja intacto

El modelo objetivo no cambia. Eso no es marketing — es la propiedad de corrección de la decodificación especulativa. En decodificación codiciosa, cada token borrador es verificado por el objetivo, así que la salida es exactamente lo que el objetivo habría producido por sí solo. En configuraciones de muestreo emparejadas a temperatura distinta de cero, la distribución de salida coincide con la del objetivo. El borrador intercambia memoria por tiempo y no toca nada más.

Lo que significa que cada cifra de calidad que puedas encontrar para LFM2.5-VL-3B se aplica sin cambios a la configuración emparejada. Según la propia evaluación de Liquid, el modelo objetivo obtiene 80,7 en ScreenSpot-v2, 61,5 en BLINK, 58,3 en MuirBench, 73,1 en MME, 63,3 en MMStar, 81,3 en ChartQA y 88,7 en POPE —todas reportadas por el proveedor, ninguna reproducida de forma independiente, y todas igualmente ciertas tanto si el modelo borrador está conectado como si no. Aquí no hay ningún compromiso entre calidad y velocidad que sopesar, y cualquier página de comparación que presente uno ha malinterpretado el modelo.

Lo que sí cambia es el coste de un token en tiempo de reloj. Liquid mide aceleraciones de decodificación de 2,04× a 2,66× en una sola H100 en BF16 mediante SGLang con tamaño de bloque 9, de 2,30× a 3,13× en una Apple M5 Max mediante MLX-VLM con tamaño de bloque 8, y de 1,57× a 2,14× en una M3 Ultra mediante llama.cpp. De extremo a extremo, las mismas ejecuciones se sitúan en 1,64×–2,27×, 1,56×–2,62× y 1,30×–1,77×, respectivamente. Esos pares son todo el argumento: la decodificación mejora aproximadamente el doble que de extremo a extremo, y la diferencia es la parte de la carga de trabajo que el modelo borrador no puede tocar.

El problema de prellenado, planteado por el proveedor

La frase más útil en el propio anuncio de Liquid es la que argumenta en contra de una lectura ilimitada de su titular. La inferencia de visión-lenguaje paga un coste de prefill que la inferencia de texto no: la imagen pasa por un codificador de visión, y el backbone de lenguaje procesa después los cientos de tokens visuales que emite ese codificador. En un dispositivo de borde, ese prefill representa una gran parte de la latencia de extremo a extremo. La decodificación especulativa solo acelera la decodificación; la codificación de visión y el prefill no cambian. Cuando el prefill domina, una aceleración de decodificación de 3× se traduce en una mejora de extremo a extremo mucho menor.

Eso es la ley de Amdahl aplicada por el proveedor a su propio producto, y debería determinar quién lee esta página. Una transcripción larga de una única página escaneada, un pie de foto, una conversación de varios turnos que mantiene una imagen — con alta carga de decodificación, y el redactor se gana sus 279,5 millones de parámetros. Una pregunta corta sobre una imagen grande de alta resolución — con alta carga de prellenado, y no lo hace. Ponga el mismo objetivo en un servidor con alta concurrencia y el panorama cambia de nuevo: Liquid mide una frontera de rendimiento-interactividad en lugar de un único número, e informa que DSpark mantiene su ventaja en todos los niveles de concurrencia probados mientras la brecha se estrecha a medida que aumenta la concurrencia.

Dos notas de alcance más pequeñas de la misma fuente. Todas las mediciones utilizan procesamiento de 16 bits tanto para el codificador de visión como para el backbone de lenguaje, y la aceleración de modelos cuantizados queda fuera del alcance del lanzamiento. Si tu plan era emparejar una exportación objetivo de 4 bits con el drafter porque todo el atractivo de un VLM de 3B es caber en unos pocos gigabytes, esa combinación no es la que se midió.

Lo que realmente te cuesta adjuntarlo

La memoria es el coste visible y la tarjeta lo cuantifica: un 8,9 % más de parámetros en el stack desplegado. La complejidad en tiempo de ejecución es la invisible. SGLang necesita la v0.5.0 o posterior y una línea de lanzamiento que incluya --speculative-algorithm DSPARK, la ruta del modelo draft y un tamaño de bloque; el propio ejemplo de la tarjeta también desactiva la caché radix y fija una fracción de memoria estática, que son decisiones de servicio sobre las que ahora tienes que razonar. MLX-VLM necesita la v0.7.2 o posterior y recibe el drafter mediante --draft-model, pero la decodificación de DSpark ahí usa actualmente muestreo greedy, así que hay que forzarlo a 0 — una restricción real si tu aplicación depende de la diversidad de muestreo. llama.cpp funciona a través del GGUF emparejado con el objetivo GGUF, no con el checkpoint original de safetensors.

Hay un costo más que aparece en producción en lugar de en un benchmark: el modelo borrador y el modelo objetivo tienen que viajar juntos. El desfase de versiones entre ambos es un modo de fallo que no existe en un despliegue de un solo modelo, y desplegar cualquiera de los dos de forma independiente es ahora un problema de dos artefactos.

Esto es un emparejamiento autoalojado. OrcaRouter no enruta LFM2.5-VL-3B ni su drafter —tú mismo descargas ambos y los sirves—, así que la cuestión del enrutamiento se refiere a todo aquello a lo que el modelo pequeño delega. La mayoría de los despliegues que emparejan un VLM de borde de 3B con el drafter todavía tienen consultas que el modelo pequeño no debería responder, y enviarlas a un único endpoint que cubre más de 200 modelos al precio de lista de cada proveedor, con conmutación por error automática si un proveedor se degrada, es una sola integración en lugar de una por proveedor. También significa que, en el momento en que un proveedor baja un precio, tu tarifa lo refleja el mismo día en lugar de en la siguiente renovación de contrato.

¿Cuál descargar?

Si tu carga de trabajo está dominada por la decodificación y tu hardware es uno de los tres que Liquid probó, conecta el drafter: la desventaja está acotada, porque se demuestra que la salida es la del objetivo y el costo de memoria es menos de una décima parte de un modelo. Si tu latencia está dominada por el prefill, o ejecutas un objetivo cuantizado, o dependes de un muestreo no greedy en un runtime que no ha eliminado esa restricción, ejecuta LFM2.5-VL-3B por sí solo. Es rápido en sus propios términos: 228 tokens por segundo en una M5 Max, 116 en una AMD Ryzen AI Max+ 395 y 20 en una Galaxy S26 Ultra, todas cifras del proveedor, en aproximadamente 3 GB de memoria.

Lo que todavía nadie puede decirte es si las cifras de Liquid se mantienen en tu hardware. El drafter tenía 37 descargas en Hugging Face en el momento de escribir esto y ninguna reproducción independiente de ninguna cifra de sus tablas. La ingeniería es sólida y el argumento de corrección es una demostración más que una afirmación, pero la magnitud es una medición, y las mediciones de un laboratorio en un conjunto de máquinas son exactamente el tipo de número que conviene verificar por tu cuenta antes de incluirlo en un plan de capacidad.

OrcaRouter llega a más de 200 modelos con una sola clave, con el precio de lista de cada proveedor traspasado directamente con un 0% de margen y conmutación por error automática entre proveedores. precio de lista del proveedor traspasado directamente con un 0% de margen El emparejamiento de esta página es autoalojado en cualquier caso; el enrutador es para todo aquello a lo que el modelo pequeño delega, y significa que una rebaja de precio de un proveedor se refleja en tu tarifa el mismo día.