LFM2.5-VL-DSpark: acelerar modelos visión‑lenguaje en el edge

Resumen

Liquid AI presentó una versión experimental DSpark para su modelo visión‑lenguaje LFM2.5-VL-3B que incorpora un “drafter” especulativo. El objetivo es acelerar la fase de decodificación sin degradar la calidad de salida, aceptando un pequeño aumento de la huella de parámetros (aprox. 280M adicionales, un 8.9% sobre el modelo de 3B). El drafter llega con soporte “día uno” para llama.cpp, MLX-VLM y SGLang.

Qué es LFM2.5-VL-DSpark

El componente DSpark es un modelo auxiliar (drafter) que propone bloques de tokens candidatos durante la generación y permite verificar rápidamente cuáles aceptar. La idea proviene de las drafters de texto de LFM2.5: capturan estados ocultos en capas concretas del modelo objetivo y condicionan en ellos la propuesta de un bloque de k tokens. Para modelos visión‑lenguaje, las imágenes (como parches) y los tokens de texto se proyectan a una representación compartida, por lo que el drafter opera sobre vectores de la misma dimensionalidad independientemente de la modalidad de entrada.

Esto hace que el algoritmo de inferencia especulativa sea igual que en los modelos de solo texto, pero adaptado a las características de los VLMs: primero la imagen pasa por un encoder visual y luego la columna vertebral lingüística procesa las decenas o cientos de tokens visuales junto con el prompt de texto.

Cómo funciona la decodificación especulativa en VLMs

Durante la inferencia el drafter sugiere un bloque de k tokens que se intentan aceptar de forma especulativa. El modelo objetivo verifica cada token propuesto; si coinciden con lo que produciría de forma determinista, se aceptan y se evita parte de la decodificación tradicional. Específicamente:

• El drafter captura estados ocultos en un conjunto fijo de capas “tapped” del modelo objetivo.
• Con esa información genera un bloque de candidatos (tamaño k).
• El modelo objetivo valida token por token; la salida es exactamente la misma que si no hubiera especulación (es decir, la decodificación es exacta).

Esta aproximación acelera la fase de decodificación sin cambiar la calidad de las respuestas, pero no reduce el coste de la codificación visual ni del prefill del prompt.

Arquitectura y entrenamiento

El drafter de visión sigue la receta DSpark utilizada en texto, entrenada con una mezcla de datos SFT visión‑lenguaje ponderada hacia las cargas de trabajo esperadas para el modelo. Tras realizar ablaciones en drafters de 3, 4 y 5 capas se seleccionó una arquitectura simplificada de solo atención con 4 capas y un bloque de entrenamiento de tamaño 9.

Entrenamiento y configuración clave:

• Entrenamiento final: 10 epochs sobre la mezcla de datos; la tasa de aceptación mejoró con más tokens hasta llegar a rendimientos decrecientes.
• Configuración recomendada en inferencia: bloque de 8 o 9 tokens según hardware.
• Tamaño del drafter: ~279.5M parámetros (aprox. 280M), lo que supone un incremento del 8.9% sobre el modelo objetivo de 3B.

Desglose aproximado del drafter:

• Pila del decoder (4 capas): 193.0M
• Proyección de estados ocultos: 21.0M
• Markov head: 65.5M
• Normas + cabeza de confianza: ~6.4k
• Total: 279.5M

Resultado: velocidad de inferencia en CPU y GPU

El modelo LFM2.5-VL-DSpark incluye soporte inmediato para llama.cpp, MLX-VLM y SGLang. Se evaluó en seis tareas diversas de visión siguiendo el benchmark MMSpec: VQA general, text VQA, captioning, chart VQA, razonamiento complejo y conversación multivuelta.

Principales mediciones (DSpark con block size 8 en evaluación):

• En dispositivo (on-device) con MLX en un M5 Max: la decodificación fue entre 2.30x y 3.13x más rápida según la tarea; la latencia end‑to‑end mejoró entre 1.56x y 2.62x.
• En dispositivo con llama.cpp en un M3 Ultra: la decodificación mejoró entre 1.57x y 2.14x; la latencia end‑to‑end entre 1.30x y 1.77x.
• En GPU (H100): la decodificación se aceleró hasta 2.66x en las pruebas, con mejoras end‑to‑end entre 1.64x y 2.27x.

Estos números muestran que la mayor ganancia es en la etapa de decodificación; el impacto en la latencia total depende de cuánto ocupen la codificación visual y el prefill del prompt.

Limitaciones y consideraciones prácticas

La decodificación especulativa solo acelera la fase de generación de tokens, no la codificación visual ni el prefill. En VLMs, el flujo incluye un encoder visual que transforma la imagen en muchos tokens a procesar por la columna lingüística, de modo que en dispositivos con capacidad limitada (por ejemplo, algunos edge o móviles) la codificación y el prefill pueden dominar la latencia total. Según la ley de Amdahl, el máximo aceleramiento global estará limitado por la fracción de tiempo que no se pueda paralelizar o acelerar con el drafter.

Para aplicaciones en América Latina donde los despliegues en edge o infraestructura con GPUs menos potentes sean frecuentes, esto implica:

• Evaluar el perfil de latencia real de su pipeline: si la codificación visual ocupa la mayor parte del tiempo, la ganancia end‑to‑end será menor que la ganancia de decodificación.
• Considerar optimizaciones en la parte visual (quantización del encoder, reducción de tokens visuales, uso de aceleradores locales) para maximizar el beneficio de DSpark.

Cómo probar LFM2.5-VL-DSpark hoy

Los modelos están disponibles en Hugging Face en formatos Safetensors y GGUF. A continuación se muestran ejemplos de lanzamiento con SGLang, llama.cpp y MLX‑VLM.

SGLang (necesita build con soporte DSpark para LFM2):

python -m sglang.launch_server —model-path LiquidAI/LFM2.5-VL-3B —speculative-algorithm DSPARK —speculative-draft-model-path LiquidAI/LFM2.5-VL-3B-DSpark —speculative-draft-attention-backend flashinfer —speculative-dspark-block-size 9 —disable-radix-cache

Luego pueden consultar el endpoint compatible con OpenAI en http://localhost:30000/v1 . El block size se lee desde el config.json del drafter; la línea base es lanzar el servidor sin las tres banderas —speculative-*.

llama.cpp (requiere build con PR relativo a DSpark):

llama-server -m models/LFM2.5-VL-3B-F16.gguf —mmproj models/mmproj-LFM2.5-VL-3B-F16.gguf -md LFM2.5-2.6B-DSpark-F16.gguf —spec-type draft-dspark —spec-draft-n-max 8 —spec-draft-n-min 0 -fa on -ngl 99 -c 8192

MLX-VLM (requiere build con soporte correspondiente):

mlx_vlm.server —model LiquidAI/LFM2.5-VL-3B —draft-model LiquidAI/LFM2.5-VL-3B-DSpark

Nota: el tamaño del bloque (n-max) se lee de la metadata del sidecar del drafter y se clamppea a ese valor.

Garantía de exactitud y apertura

La decodificación especulativa es exacta: cada token propuesto por el drafter es verificado por el modelo objetivo, por lo que la salida codiciosa es igual a la del modelo sin especulación. Los tiempos por respuesta informan cuántos tokens propuso el drafter y cuántos fueron aceptados.

Además, estos modelos son de peso abierto (open-weight): pueden descargarse, ajustarse y desplegarse sin restricciones, lo que facilita su adopción local en proyectos industriales y de investigación en la región.

Conclusión

LFM2.5-VL-DSpark es una opción interesante para organizaciones que necesitan acelerar la generación en modelos visión‑lenguaje, especialmente en despliegues on‑device o en infraestructuras heterogéneas. Su aumento de parámetros es modesto frente a las ganancias en decodificación, y el soporte inmediato para herramientas populares facilita la experimentación. Para maximizar el beneficio en entornos latinoamericanos, conviene medir el perfil de latencia completo (codificación visual + prefill + decodificación) y explorar optimizaciones complementarias en la parte visual.