Liquid AI lanza LFM2.5-VL-DSpark: modelo de visión de 3B con modelo borrador, hasta 3,13 veces más rápido en decodificación
Según una publicación de septiembre de 2026 en el blog de Liquid AI, Liquid AI presentó un modelo borrador experimental DSpark para su modelo de lenguaje visual de pesos abiertos LFM2.5-VL-3B, con unos 280 millones de parámetros adicionales (un 8,9 % más respecto al modelo objetivo de 3B), y afirma una aceleración de decodificación de hasta 3,13 veces en dispositivo y hasta 2,66 veces en H100, con soporte desde el primer día para llama.cpp, MLX-VLM y SGLang.
Qué ha cambiado
Liquid AI publicó en septiembre de 2026 un modelo borrador experimental DSpark que acompaña a su modelo de lenguaje visual LFM2.5-VL-3B. Según el blog del fabricante, este modelo borrador sigue el enfoque arquitectónico de la versión de texto LFM2.5-DSpark: captura los estados ocultos del modelo objetivo en una capa de acceso fija y, a partir de ellos, redacta un lote de tokens candidatos; los parches de imagen y los tokens de texto se proyectan a un espacio de representación compartido antes de entrar en esas capas, por lo que el modelo borrador procesa estados ocultos de dimensión uniforme y el algoritmo de inferencia es idéntico al del modelo de texto. El modelo borrador usa una estructura de 4 capas solo con atención, con un block size de 9 y unos 279,5 millones de parámetros, desglosados en 193 millones para la pila del decodificador, 21 millones para la proyección de estados ocultos, 65,5 millones para la cabeza de Markov y 6.400 parámetros para las normas y la cabeza de confianza. El fabricante afirma que en un M5 Max con MLX la decodificación se acelera entre 2,30 y 3,13 veces por tarea y el extremo a extremo entre 1,56 y 2,62 veces; en un M3 Ultra con llama.cpp la decodificación se acelera entre 1,57 y 2,14 veces; los datos de decodificación y extremo a extremo en H100 parecen presentar anomalías tipográficas en el texto original. El fabricante subraya que la decodificación especulativa es exacta, que el modelo objetivo verifica cada token propuesto y que la salida con greedy es igual a la de usar solo el modelo objetivo, y que el modelo borrador se ofrece en Hugging Face en formatos Safetensors y GGUF.
Impacto para desarrolladores
Para los desarrolladores que despliegan modelos multimodales en local o en el borde, lo relevante de este lanzamiento no son las cifras absolutas de velocidad, sino la proporción de parámetros entre el modelo borrador y el objetivo —unos 8,9 %—, lo que implica un aumento controlable de memoria de vídeo y de sistema. Sin embargo, la mayoría de las aceleraciones son métricas de la fase de decodificación, y el beneficio extremo a extremo depende del peso de la codificación visual y del prefill en la carga de trabajo, algo que el propio fabricante explica citando la ley de Amdahl. Esto genera una bifurcación: los escenarios dominados por salidas largas, diálogo multiturno o descripción de imágenes podrían acercarse a las cifras extremo a extremo declaradas; los escenarios de una sola pregunta sobre una imagen larga, que requieren procesar muchos tokens visuales y terminan pronto, obtendrán un beneficio notablemente menor. Además, ejecutar el modelo borrador depende de ramas de llama.cpp, MLX-VLM o SGLang que aún no están integradas en la rama principal o que requieren compilaciones específicas, por lo que el coste de integración no es despreciable. Cabe señalar que, en el momento de esta verificación, el catálogo vigente de KimiSeek no incluye ninguna entrada de LFM2.5-VL-3B ni de LFM2.5-VL-DSpark, y que la disponibilidad de API y pesos mencionada en la fuente es la versión del fabricante.
Integración y evaluación
Recomendación uno: mide primero qué proporción de la latencia total corresponde a la decodificación antes de decidir si incorporas el modelo borrador. La fuente señala que la decodificación especulativa solo acelera la decodificación, no la codificación visual ni el prefill, y que en dispositivos de borde el prefill representa una mayor proporción de la latencia extremo a extremo. El requisito es disponer ya de datos desglosados de latencia del primer token y de tiempo de decodificación; se recomienda ejecutar dos configuraciones, la de referencia y la del modelo borrador, con el mismo conjunto de seis tipos de tareas visuales (VQA general, VQA de texto, descripción de imágenes, VQA de gráficos, razonamiento complejo y diálogo multiturno), y evaluar con percentiles de latencia extremo a extremo, no solo con el rendimiento de decodificación. Si tu carga se compone sobre todo de imágenes cortas con salidas largas, el modelo borrador puede compensar; si predominan las preguntas de un solo turno sobre imágenes largas, el límite de beneficio lo marcará el prefill. Recomendación dos: elige entre llama.cpp y SGLang según la forma de despliegue, no según la aceleración máxima declarada. La fuente indica que sus formas de arranque difieren: SGLang monta el modelo borrador mediante parámetros como --speculative-dspark-block-size y exige explícitamente desactivar la caché radix; en llama.cpp se necesita --spec-type draft-dspark junto con --spec-draft-n-max 8. El requisito es que la compilación que uses incluya el PR correspondiente, pues de lo contrario esos parámetros no estarán disponibles. Al evaluar, conviene registrar los valores draft_n y draft_n_accepted de cada respuesta y usar la tasa de aceptación para decidir si conviene un block size de 8 o de 9; si la tasa de aceptación es baja, habría que revisar si la distribución de tareas se aparta de la mezcla de datos de entrenamiento. Son prácticas recomendadas, no compromisos del fabricante.
Límites y cuestiones pendientes
Primero, en el momento de esta verificación el catálogo vigente de KimiSeek no contiene ninguna entrada exacta de LFM2.5-VL-3B ni de LFM2.5-VL-DSpark, por lo que esta versión no está publicada actualmente en KimiSeek; la descarga de pesos, los formatos y los métodos de integración mencionados en la fuente son la versión del fabricante y no representan disponibilidad en este sitio. Segundo, en el texto original del fabricante uno de los intervalos de aceleración de decodificación en H100 aparece escrito como «20,4 veces a 2,66 veces», una anomalía evidente de composición o transcripción que no debe citarse como límite fiable. Tercero, el fabricante describe el modelo borrador como experimental, con una estructura de 4 capas y un block size de 9 procedentes de ablaciones de 3, 4 y 5 capas, y con una mezcla de datos de entrenamiento ponderada según la carga prevista, por lo que la tasa de aceptación y las aceleraciones variarán según la distribución real de tareas. Cuarto, las cifras de aceleración provienen de pruebas del fabricante en M5 Max, M3 Ultra y H100, evaluadas según las seis categorías de tareas del benchmark MMSpec, y su comportamiento en otro hardware, formatos de cuantización, longitudes de contexto y configuraciones de procesamiento por lotes no ha sido verificado de forma independiente. Quinto, la fuente describe el modelo como de pesos abiertos y libremente descargable, ajustable y desplegable, pero el blog no ofrece los términos concretos de licencia; la disponibilidad de los pesos no equivale a una licencia de código abierto, y los derechos de uso comercial y redistribución deben regirse por la licencia real de la página del modelo en Hugging Face.
Ilustraciones de la noticia original
