Liquid AI añade decodificación especulativa a LFM2.5-VL-3B para una inferencia visión-lenguaje más rápida

Liquid AI ha lanzado un modelo experimental de decodificación especulativa diseñado para acelerar su modelo visión-lenguaje LFM2.5-VL-3B, con el objetivo de resolver un cuello de botella central en la inferencia multimodal: generar respuestas rápidamente después de que se ha procesado una imagen y un prompt.

El modelo, llamado LFM2.5-VL-DSpark, añade un modelo draft de 280 millones de parámetros al modelo objetivo de 3 mil millones de parámetros. Liquid AI afirma que la combinación ofreció aceleraciones de decodificación de hasta 3,13x en un Apple M5 Max y hasta 2,66x en un Nvidia H100 en su evaluación interna. Las mejoras de latencia de extremo a extremo fueron menores, alcanzando 2,62x en el M5 Max y 2,27x en la H100.

El lanzamiento es más importante para los equipos que despliegan modelos visión-lenguaje en hardware local, donde la latencia de respuesta y los límites de memoria pueden ser más restrictivos que en grandes clústeres de inferencia. También amplía el enfoque DSpark de Liquid AI desde modelos de texto hacia cargas de trabajo multimodales sin requerir un algoritmo diferente de decodificación especulativa.

Un modelo draft construido para entradas multimodales

La decodificación especulativa utiliza un modelo más pequeño para proponer varios tokens a la vez. Luego, el modelo objetivo más grande verifica esas propuestas, aceptando los tokens que coinciden con su propia distribución del siguiente token y generando reemplazos cuando es necesario. El enfoque puede reducir el número de pasos costosos del modelo objetivo sin cambiar la salida del modelo objetivo bajo verificación exacta.

Según el lanzamiento de Liquid AI en Hugging Face, el modelo draft LFM2.5-VL-DSpark toma estados ocultos de capas seleccionadas de LFM2.5-VL-3B y propone bloques de tokens candidatos. Primero se proyectan imágenes y texto en una representación compartida, lo que permite que el modelo draft reciba vectores con la misma dimensionalidad independientemente de la modalidad de entrada.

Liquid AI dice que el modelo draft de visión usa cuatro capas solo de atención y un tamaño de bloque de nueve durante el entrenamiento. Para la inferencia, la empresa recomienda un tamaño de bloque de ocho o nueve según el hardware. El modelo draft añade aproximadamente un 8,9% al recuento de parámetros del modelo desplegado, un aumento de memoria relativamente pequeño en comparación con ejecutar un modelo grande separado para la misma tarea.

El modelo se entrenó con una mezcla de datos de ajuste fino supervisado de visión-lenguaje ponderados hacia las cargas de trabajo que Liquid AI espera atender. La empresa probó diseños de tres, cuatro y cinco capas y entrenó la configuración seleccionada durante 10 épocas, informando que la aceptación mejoró con tokens adicionales antes de llegar a rendimientos decrecientes.

Las mejoras reportadas varían según el hardware y la tarea

Liquid AI evaluó el sistema en seis cargas de trabajo basadas en visión utilizando el benchmark MMSpec. Las tareas incluyeron preguntas y respuestas visuales generales, preguntas y respuestas visuales centradas en texto, generación de descripciones de imágenes, preguntas y respuestas sobre gráficos, razonamiento complejo y conversación de múltiples turnos.

Los resultados en el dispositivo se midieron con MLX en un M5 Max y con llama.cpp en un M3 Ultra. Liquid AI informa que la decodificación con MLX fue de 2,30x a 3,13x más rápida según la tarea, mientras que la latencia de extremo a extremo mejoró de 1,56x a 2,62x. Con llama.cpp, las mejoras de decodificación oscilaron entre 1,57x y 2,14x, y la latencia de extremo a extremo mejoró de 1,30x a 1,77x.

La evaluación con H100 produjo mejoras de decodificación de hasta 2,66x y mejoras de extremo a extremo de hasta 2,27x, según la empresa. El material de origen incluye una cifra inconsistente de límite inferior para el rango de decodificación en H100, por lo que el resultado más amplio debe tratarse como un máximo informado por el proveedor, no como una expectativa uniforme de rendimiento.

Estas son medidas de Liquid AI, no un benchmark independiente. También describen hardware específico, configuraciones de software, mezclas de tareas y un tamaño de bloque DSpark de ocho. Las mejoras reales dependerán de la tasa de aceptación de los tokens propuestos, la longitud del prompt, la complejidad de la imagen, la cuantización, el tamaño de lote y la proporción de la latencia total dedicada al procesamiento de imágenes y a la ingestión del prompt.

Liquid AI afirma que la decodificación especulativa es exacta porque el modelo objetivo verifica cada token propuesto. En su implementación, la salida greedy debería por tanto coincidir con el modelo objetivo ejecutándose sin especulación. Esa propiedad aborda una de las principales preocupaciones de despliegue en torno a las técnicas de aceleración: mejorar la velocidad sin cambiar silenciosamente el comportamiento del modelo.

Por qué la latencia de extremo a extremo sigue siendo la métrica más difícil

La diferencia reportada entre la velocidad de decodificación y la latencia total es importante para los equipos de producto. La decodificación especulativa acelera la generación de tokens, pero no acelera el codificador de visión ni la fase de prefill que procesa los tokens de imagen y el prompt de texto.

Los modelos visión-lenguaje pueden pasar un tiempo considerable antes de producir el primer token. Una imagen pasa por un codificador de visión, tras lo cual el modelo de lenguaje procesa cientos de tokens visuales junto con la entrada textual. En hardware edge, el menor presupuesto de cómputo puede hacer que esas etapas representen una mayor parte del tiempo total de respuesta. Como resultado, una mejora triple en la decodificación no se traduce en una reducción triple de la latencia visible para el usuario.

Esta limitación es un ejemplo de la ley de Amdahl: las partes de una carga de trabajo que permanecen sin cambios limitan la ganancia global. Para una aplicación como chat con imágenes, análisis de documentos o interpretación de gráficos, los equipos deberán medir por separado el tiempo hasta el primer token y el tiempo total de respuesta. Una ruta de decodificación más rápida puede ser especialmente valiosa para respuestas largas, turnos repetidos o flujos de trabajo en los que la generación de salida domina después de que la imagen ya ha sido codificada.

Los resultados también sugieren que la elección del hardware moldeará la propuesta de valor. El rango de decodificación más fuerte informado por Liquid AI provino de Apple Silicon, mientras que la H100 ofreció ganancias menores pero aún significativas en la prueba de la empresa. Eso hace que el lanzamiento sea relevante tanto para la inferencia local como para servicios respaldados por GPU, pero no establece que cada despliegue vea la misma mejora.

Las integraciones reducen la barrera de prueba

LFM2.5-VL-DSpark está disponible mediante integraciones para llama.cpp, MLX-VLM y SGLang. Liquid AI dice que el modelo draft se ofrece en Hugging Face en formatos Safetensors y GGUF, proporcionando a los desarrolladores rutas para flujos de trabajo de despliegue nativos y cuantizados.

La integración con SGLang requiere una compilación con soporte DSpark para objetivos LFM2, mientras que llama.cpp y MLX-VLM también requieren versiones que incluyan los cambios de implementación pertinentes. En SGLang, los operadores adjuntan el modelo draft al modelo objetivo y consultan un endpoint compatible con OpenAI. El tamaño de bloque se lee desde la configuración del modelo, y el tiempo de respuesta puede revelar cuántos tokens draft fueron propuestos y aceptados.

Para los desarrolladores, este modelo de integración es significativo porque el lanzamiento no requiere reemplazar el modelo visión-lenguaje objetivo ni rediseñar la interfaz de la aplicación. Los equipos pueden comparar un despliegue base con decodificación especulativa usando el mismo modelo objetivo y medir la aceptación, la latencia, el uso de memoria y la equivalencia de salida. Sin embargo, los 280 millones de parámetros adicionales todavía implican un coste de memoria y carga, que puede importar en dispositivos edge más pequeños.

Qué observar a continuación

La señal de seguimiento más clara será la prueba independiente de LFM2.5-VL-DSpark en más tamaños de imagen, niveles de cuantización, tamaños de lote y prompts de estilo producción. Los resultados independientes ayudarían a establecer si las mejoras reportadas se mantienen fuera de la evaluación de seis tareas seleccionada por Liquid AI.

Los desarrolladores también deberían vigilar las tasas de aceptación y la latencia de extremo a extremo en lugar de confiar solo en los multiplicadores de decodificación destacados. El soporte en llama.cpp, MLX-VLM y SGLang será importante a medida que las implementaciones maduren, especialmente para los usuarios que despliegan en Apple Silicon o en hardware local restringido.

Más lanzamientos DSpark para otros modelos visión-lenguaje podrían indicar si la arquitectura se generaliza más allá de LFM2.5-VL-3B. Por el contrario, si las mejoras son muy sensibles a la arquitectura del modelo o a la carga de trabajo, el método podría seguir siendo una optimización dirigida en lugar de una capa de inferencia ampliamente portable.

Perspectiva de Creati.ai

El lanzamiento de Liquid AI es una actualización práctica de inferencia más que un nuevo modelo de capacidades. Su principal aportación es mostrar cómo la decodificación especulativa puede adaptarse a un objetivo multimodal manteniendo la verificación exacta y conservando el modelo adicional relativamente pequeño.

La importancia comercial dependerá de la latencia total percibida por el usuario, no de la cifra máxima de decodificación. Para los equipos que ejecutan cargas de trabajo visión-lenguaje localmente, la combinación de pesos abiertos, integraciones de runtime existentes y mejoras medibles podría justificar pruebas. Pero los compradores deberían tratar las afirmaciones de rendimiento actuales como informadas por el proveedor y validarlas con sus propias imágenes, prompts, hardware y objetivos de latencia.