LFM2.5-VL-3B-DSpark: el Drafter de 279,5 M de Liquid AI se lanzó seis días antes de que alguien lo anunciara

Existe una versión de esta historia en la que LFM2.5-VL-3B-DSpark es un modelo nuevo. No lo es. Es un modelo borrador de decodificación especulativa de 279,5 millones de parámetros que existe con exactamente un propósito —hacer que el propio modelo de visión-lenguaje de Liquid AI, LFM2.5-VL-3B, decodifique más rápido— y no puede generar una respuesta utilizable por sí solo. La razón por la que, aun así, vale la pena leer sobre él es la cronología: los pesos llegaron a Hugging Face el 18 de septiembre de 2026, sin ningún anuncio adjunto, permanecieron allí durante seis días y solo recibieron una entrada de blog del proveedor el 24 de septiembre. Radar detectó el repositorio en ese intervalo.

Esa laguna es también el límite de lo que se puede saber en este momento. Todo lo que hay en el repositorio —el desglose de parámetros, el tamaño del bloque, las integraciones con frameworks, la licencia— es un archivo en disco que usted o yo podemos abrir. Cada cifra de aceleración está medida por el proveedor, a partir del propio banco de pruebas de Liquid, y nadie fuera de la empresa ha publicado una reproducción. Este artículo mantiene esos dos montones separados a propósito.

Lo que realmente contiene el repositorio

Abre la tarjeta del modelo y la forma de la cosa es inequívoca. LFM2.5-VL-3B-DSpark es un modelo borrador cuyo objetivo está fijado en sus metadatos: base_model: LiquidAI/LFM2.5-VL-3B. No lo apuntas a un modelo diferente ni lo sirves por sí solo.

• Parámetros totales del borrador — 279,5M, BF16, de los cuales 193,0M corresponden a la pila de decodificador de 4 capas, 65,5M a una cabeza de Markov, 21,0M a una proyección de estado oculto y 6,4k a normalizaciones más una cabeza de confianza

• Backbone — 4 capas de atención completa, tamaño oculto 2,048, tamaño intermedio 6,144 con SiLU/SwiGLU, atención de consulta agrupada con 32 cabezas de atención y 8 cabezas de clave-valor, dimensión de cabeza 64

• Cabezas adicionales — una cabeza de Markov con rango 256 y una cabeza de confianza, que es lo que distingue la generación de borradores de DSpark de un generador de borradores paralelo simple

• Tamaño de bloque — 9 durante el entrenamiento; 8 o 9 en inferencia según el hardware, y 8 específicamente en Apple silicon

• Vocabulario — 128.000, vinculado al objetivo en lugar de ser arrastrado por el borrador

• Peso en la pila desplegada — Liquid afirma que el modelo borrador aumenta el recuento de parámetros desplegados en un 8,9%

El 8,9 % es la cifra a la que hay que aferrarse. El argumento de venta para esta clase de modelo nunca es «una inferencia más rápida es gratis»; es «una inferencia más rápida te cuesta aproximadamente una décima parte de la memoria de un modelo». Con 279,5 M de parámetros adicionales sobre un modelo objetivo de 3,1 B, ese es un impuesto más pequeño de lo que sugeriría el tamaño del modelo borrador por sí solo, porque el embedding y la cabeza del LM están vinculados al modelo objetivo y no se duplican.

DSpark es una técnica de DeepSeek antes que un modelo de Liquid

La denominación invita a confusión, así que vale la pena ser preciso. DSpark no es una invención de Liquid AI ni una familia de modelos. Es un marco de decodificación especulativa de una línea de investigación aparte, descrito en un artículo de julio de 2026 como decodificación especulativa con programación de confianza y generación semiautoregresiva. Sus tres ideas: una columna vertebral paralela que redacta un bloque completo en una sola pasada hacia adelante, un módulo secuencial ligero que restaura cierta dependencia entre tokens de borrador vecinos para que la aceptación no colapse al final del bloque, y un verificador que acorta la ventana de verificación por solicitud cuando la propia confianza del borrador sugiere que la cola será rechazada.

Lo que hizo Liquid fue aplicar esa receta a los modelos de visión-lenguaje y publicar un checkpoint. La tarjeta es sincera al decir que esta transferencia es menos dramática de lo que suena: desde el punto de vista del modelo borrador, la modalidad es irrelevante, porque para cuando los tokens llegan a las capas ocultas, un parche de imagen y un token de texto no son más que tensores. Por eso una técnica desarrollada en modelos de texto se traslada a un VLM sin necesidad de reinventarla, y también por eso el modelo borrador no puede venderse como una nueva capacidad.

Liquid ya había lanzado los borradores DSpark de texto —los modelos complementarios 2.6B, 8B-A1B y 1.2B-Instruct se publicaron en agosto de 2026, con las exportaciones GGUF llegando el 19 de agosto. El borrador de visión es la misma idea extendida a la rama multimodal, y la cuarta o quinta entrada de una línea, no un debut.

Las cifras de aceleración, y quién las midió

Todas las cifras a continuación son propias de Liquid, recopiladas en la infraestructura de benchmarking de Liquid, y ninguna de ellas cuenta con una reproducción independiente. Considerarlas un techo del proveedor, no un resultado esperado. La tarjeta separa la aceleración de decodificación de la aceleración de extremo a extremo, lo cual importa más que el titular.

• Mejor aceleración de decodificación — 3,13× en COCO, medida con MLX-VLM en un Apple M5 Max con tamaño de bloque 8, FP16, tamaño de lote 1, temperatura 0

• Mejor aceleración de decodificación de GPU: 2,66× en COCO, SGLang en una sola H100 80GB, BF16, tamaño de bloque 9

• Mejor aceleración de decodificación de llama.cpp — 2,14× en COCO, Apple M3 Ultra, tamaño de bloque 8

• Rango de decodificación de H100 en seis tareas de visión: de 2,04× a 2,66×, con extremo a extremo de 1,64× a 2,27×

• Rango de decodificación de M5 Max — 2,30× a 3,13×, de extremo a extremo 1,56× a 2,62×

• Rango de decodificación de M3 Ultra: de 1,57× a 2,14×; de extremo a extremo, de 1,30× a 1,77×

• Aceptación de borrador — aproximadamente 3,2 a 4,5 tokens aceptados por pasada de verificación objetivo, en las tres pilas

El patrón en esos rangos es la parte honesta. Las ganancias de extremo a extremo son, de manera consistente, la mitad más pequeña de cada par, porque el borrador acelera la decodificación y nada más. Ten en cuenta también que el mismo borrador con el mismo tamaño de bloque alcanza 3,13× en una pila y 1,57× en otra: la tasa de aceptación es una propiedad del borrador y de la carga de trabajo, pero la ganancia de tiempo de reloj es una propiedad del hardware y de la sobrecarga del entorno de ejecución. Una afirmación de «2,66× más rápido» sin la pila asociada no es una afirmación sobre la que se pueda actuar.

Dos puntos de corrección de la ficha merecen decirse con claridad, porque son lo que hace que un modelo de borrador sea siquiera aceptable en producción. Con decodificación voraz, la decodificación especulativa es exacta: el modelo objetivo verifica cada token propuesto, así que el texto es el que el modelo objetivo habría producido por sí solo. Con ajustes de muestreo emparejados a temperatura distinta de cero, conserva la distribución de salida del modelo objetivo. La formulación de Liquid —obtienes la aceleración, no un modelo diferente— es exacta en lo que dice, y la ficha es honesta al reconocer que aumentar la temperatura reduce la aceptación y, por lo tanto, erosiona el beneficio de rendimiento.

Lo que admite la propia publicación de Liquid

La entrada de blog del 24 de septiembre es más útil que la ficha del modelo por una razón: nombra el límite. La inferencia de visión-lenguaje paga un coste de prefill que la inferencia de texto no — la imagen tiene que pasar por un codificador de visión, y el backbone de lenguaje luego tiene que procesar los cientos de tokens visuales que produce ese codificador. En un dispositivo, ese prefill domina 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 se ven afectados. Liquid invoca la ley de Amdahl contra su propio producto y señala que, donde el prefill es una gran parte del tiempo real, una gran aceleración de decodificación solo compra una modesta mejora de extremo a extremo.

Esa es una restricción real para la decisión de compra, y explica por qué el tiempo hasta el primer token no está en la lista de cosas que mejora este modelo de borrador. También implica que las cargas de trabajo que más se benefician son las que generan salidas largas a partir de una imagen modesta —una descripción, una transcripción OCR larga, una conversación de varios turnos con una sola imagen que se mantiene—, en lugar de las que responden a una pregunta corta sobre una imagen grande.

La publicación añade dos límites de alcance más. Todas las cifras emplean procesamiento de 16 bits tanto para el codificador de visión como para la red troncal del lenguaje, y la aceleración de modelos cuantizados queda fuera del alcance de esta versión. Dado que el principal argumento de venta de un VLM de 3B para el borde es ejecutarse en un par de gigabytes, "las aceleraciones se miden en FP16" es una salvedad importante para cualquiera que planeara combinarlo con una exportación de 4 bits. Liquid también señala que el modelo de borrador se entrenó íntegramente en hardware de AMD.

Ejecutándolo

El soporte desde el primer día es real y abarca tres runtimes, lo cual es más de lo que reciben la mayoría de los drafters. SGLang en NVIDIA requiere la v0.5.19 o posterior y lleva al drafter a través de --speculative-algorithm DSPARK con la ruta de draft y un tamaño de bloque de 9. MLX-VLM en Apple silicon requiere la v0.7.2 o posterior y detecta el drafter cuando se le pasa con --draft-model; hay un detalle delicado: la decodificación de DSpark en MLX-VLM actualmente usa muestreo greedy, así que la temperatura debe configurarse en 0. Para llama.cpp hay un repositorio GGUF aparte, con una única exportación F16 de aproximadamente 567 MB, y la tarjeta es explícita en que se debe emparejar el drafter cuantizado con el objetivo cuantizado en lugar de con el checkpoint safetensors original.

Donde una capa de enrutamiento se gana su lugar aquí no es en este modelo — OrcaRouter no enruta LFM2.5-VL-3B-DSpark ni LFM2.5-VL-3B, y este es un emparejamiento de drafter autoalojado que descargas y sirves tú mismo. Es en el resto del stack que lo rodea. La misma aplicación que ejecuta un pequeño modelo de visión de pesos abiertos en el dispositivo suele tener una ruta de respaldo para las consultas que el modelo pequeño no puede manejar, y apuntar esa ruta a un único endpoint que cubre más de 200 modelos — facturado al precio de lista de cada proveedor sin ningún margen añadido, con conmutación por error automática cuando un proveedor se degrada — es una integración más pequeña que levantar un segundo contrato con un proveedor. El drafter mejora una pata de esa arquitectura; el router es lo que evita que la otra pata se convierta en un segundo proyecto.

Lo que aún no se sabe

El repositorio tiene 37 descargas y 6 me gusta en el momento de escribir esto. No hay ninguna entrada para este modelo de borrador en ningún agregador público de benchmarks, ninguna reproducción por parte de terceros de ninguno de los rangos de aceleración, y ninguna medición independiente de la tasa de aceptación en hardware que Liquid no probó. Tampoco hay benchmarks de calidad en la tarjeta por razones obvias —el modelo de borrador preserva la salida por construcción, así que los números de calidad pertenecen a LFM2.5-VL-3B, y la tarjeta remite a los benchmarks de ese modelo en lugar de inventar los suyos propios.

Un detalle en los metadatos es un pequeño indicio de lo nuevo que es esto: el modelo lleva una etiqueta de biblioteca de SGLang y un flag de algoritmo de SGLang que existe específicamente para invocarlo. El soporte del framework tuvo que llegar antes de que lo hiciera el anuncio, lo cual concuerda con el lapso de seis días entre el repositorio y la publicación del blog.

Así que: una pieza de ingeniería genuina, útil y de alcance limitado, anunciada una semana después de su lanzamiento, cuya propuesta de valor entera es un número medido por el proveedor en hardware que puede que no tengas. Si estás sirviendo LFM2.5-VL-3B en una H100 o una Mac de la serie M y tu carga de trabajo es intensiva en decodificación, el costo de memoria es del 8.9% y la desventaja es casi nula porque la salida es demostrablemente la del objetivo. Si el prefill domina tu latencia, o contabas con la exportación de 4 bits, la propia publicación de Liquid te dice que no ayudará. La reproducción, cuando llegue, es lo que hay que esperar.

OrcaRouter pone más de 200 modelos detrás de una sola clave al precio de lista del proveedor con 0% de margen de beneficio, y expresa la ruta de respaldo como una capa de enrutamiento en lugar de código de aplicación. El modelo borrador se aloja en servidores propios en cualquier caso — el enrutador es lo que evita que el tramo al que tu modelo pequeño cede el control se convierta en un segundo proyecto.