LFM2.5-VL-DSpark: Cómo tratar el redactor de visión de Liquid AI como un sidecar verificado, no como un segundo modelo

Lo que Liquid AI lanzó realmente: un sidecar redactor de visión para LFM2.5-VL-3B

Liquid AI lanzó su redactor de visión experimental LFM2.5-VL-DSpark el 24 de septiembre de 2026. Es fácil leerlo mal. El pequeño artefacto DSpark parece algo que un equipo podría desplegar junto a un modelo de visión y lenguaje más grande, o quizá en lugar de él. Esa lectura es incorrecta. La pregunta útil no es qué tan rápido es el modelo pequeño. La pregunta útil es si el objetivo, el sidecar, el proyector, el runtime, el punto de toma, la lógica de verificación y la ruta de reversión están emparejados con suficiente precisión como para que el objetivo hubiera producido la misma respuesta.

Liquid AI describe LFM2.5-VL-DSpark como un redactor experimental para LiquidAI/LFM2.5-VL-3B. El redactor tiene aproximadamente 279,5M parámetros BF16, cuenta con cuatro capas de atención y usa cabezales Markov y de confianza. Lee estados ocultos del objetivo en capas de toma fijas después de que las entradas de imagen y texto entran en la representación compartida. En términos simples, no es un modelo de visión y lenguaje independiente. No es un reemplazo comprimido para LFM2.5-VL-3B. No es un atajo alrededor del codificador de visión. Es un sidecar de decodificación especulativa, útil solo cuando el objetivo sin cambios verifica los tokens propuestos.

Esa distinción suena puntillosa hasta que rompe un despliegue. Un equipo puede emparejar el sidecar equivocado, copiar un ejemplo de modelo de texto, servir el redactor solo o medir la latencia antes de comprobar si las salidas greedy siguen coincidiendo con la ruta del objetivo. Ninguno de esos fallos sería exótico. Son exactamente el tipo de errores que ocurren cuando un lanzamiento se trata como un control de velocidad en lugar de como un contrato.

Si todavía estás evaluando el modelo base, la prueba local de aceptación de visión de LFM2.5-VL-3B anterior de Optijara es el contexto principal. Este artículo es más estrecho. Trata sobre DSpark como sidecar verificado. Para equipos que ya trabajan con artefactos cuantizados locales, la guía de ruta empaquetada Transformers GGUF llama.cpp de Optijara también explica por qué un nombre de archivo plausible no basta.

El contrato de ejecución de DSpark: redactar, verificar, revertir y luego aceptar tokens

En una configuración correcta de DSpark de visión, la imagen y el prompt siguen entrando por la ruta objetivo de visión y lenguaje. El objetivo sigue siendo responsable del procesador, el tokenizador, la plantilla de prompt, el proyector de visión, la columna vertebral de lenguaje y la verificación final. DSpark lee información de estados ocultos en puntos de toma compatibles y propone tokens candidatos. El objetivo comprueba esas propuestas. Los tokens aceptados avanzan. Las propuestas rechazadas necesitan reversión de caché para que el sistema vuelva a un estado coherente con el objetivo.

El punto de toma es la frontera que importa. Un redactor entrenado para leer un estado interno no puede soltarse en una ruta de modelo arbitraria y esperar que preserve el comportamiento. El checkpoint objetivo, el proyector, la capa de toma, las suposiciones sobre embedding compartido o cabezal LM, y la implementación del runtime determinan si los tokens redactados son significativos.

La verificación es la protección. Para decodificación greedy bajo condiciones emparejadas, la decodificación especulativa está diseñada para preservar la salida del objetivo mientras reduce pasos costosos del objetivo. Esa idea algorítmica es útil. Tampoco es una garantía para todos los backends. Diferencias de kernel, precisión, preprocesamiento de imagen, plantillas de prompt, revisiones de runtime e implementaciones de muestreo todavía pueden crear divergencias. La discusión del PR de visión de SGLang informa diferencias de tokens de salida en un contexto de prueba debido a diferencias numéricas en la forma de verificación. Trátalo como una invitación a probar con cuidado, no como una razón para descartar el lanzamiento.

Las ganancias también tienen una forma. DSpark no elimina el preprocesamiento de imagen ni el prefill de visión. Puede ayudar cuando se aceptan suficientes tokens de decodificación para compensar el coste de redactar, agrupar verificaciones, propuestas rechazadas y tráfico de caché. Eso está relacionado con la temporización por etapas, pero no es el mismo problema que mapear tiempos de codificación y decodificación con OpenVINO GenAI.

Marco original: el mapa de compatibilidad redactor-objetivo

El marco recomendado de Optijara para este lanzamiento es el mapa de compatibilidad redactor-objetivo. Complétalo antes de medir tiempos de DSpark. Si una fila es desconocida, el benchmark todavía no es confiable.

Para GGUF, prefiere el par VL oficial actual: LiquidAI/LFM2.5-VL-3B-GGUF:F16 con LiquidAI/LFM2.5-VL-3B-DSpark-GGUF:F16, usando las banderas de redacción DSpark descritas en la tarjeta del modelo. Evita comandos genéricos del Hub que impliquen que el redactor se puede servir solo. También evita copiar un ejemplo de redactor de texto en un lanzamiento de visión. Un sidecar DSpark de texto y un objetivo VL no son intercambiables solo porque los nombres se parezcan.

El soporte del runtime merece el mismo escepticismo. La tarjeta del modelo DSpark menciona compatibilidad con versiones de SGLang y compatibilidad con MLX-VLM, pero los equipos deberían verificar que la compilación instalada contiene la capacidad de visión relevante, no solo la cadena de versión. El PR de visión de SGLang expone acceso al cabezal LM del modelo de lenguaje anidado y soporte de capas de captura. El PR de MLX-VLM conecta tomas de estados ocultos al estilo DSpark, verificación especulativa y reversión de caché de estado de convolución. El PR de llama.cpp aborda la arquitectura de vocabulario objetivo y el reordenamiento doble RoPE en la conversión. Esas son capacidades que hay que verificar, no etiquetas que citar en una diapositiva.

Qué probar antes de confiar en la tabla de aceleración

Optijara inspeccionó las tarjetas públicas de modelo y el código de integración para este artículo. No hemos ejecutado estos modelos ni reproducido los benchmarks; el plan de pruebas siguiente es trabajo propuesto.

Empieza con la paridad. Luego mide la latencia. Una prueba de humo útil fija el modelo, el tokenizador, el procesador, el proyector, la plantilla de chat, el commit del runtime o la versión del paquete, la precisión, el preprocesamiento de imagen, los ajustes de generación y el ajuste de bloque. Ejecuta primero la salida greedy solo con el objetivo. Ejecuta después la salida greedy con DSpark. Compara el texto exacto. Si diverge, registra el prompt, el hash de la imagen, los ajustes, la revisión del runtime y el diff de salida antes de hacer cualquier afirmación de velocidad.

Las cifras de rendimiento informadas por Liquid AI son útiles, pero son resultados del proveedor bajo condiciones específicas. La tarjeta del modelo enmarca los resultados alrededor de batch 1, temperatura 0, ajustes de codificador y backbone de 16 bits, H100 BF16 con bloque 9, Apple FP16 con bloque 8; las mediciones de Apple usan hasta 2048 tokens de salida. Informa ejemplos como proporciones de decodificación y de extremo a extremo en COCO con H100, además de resultados de Apple que incluyen filas de M5 Max y M3 Ultra. Trata eso como evidencia direccional del lanzamiento, no como una promesa para tu carga de trabajo. Si la evidencia de benchmark se comparará entre sistemas, usa disciplina de protocolo como en la guía de tarjetas de evaluación y protocolos de benchmark de Optijara: puntuación, conjunto de prompts, runtime, precisión y reglas de medición deben viajar juntas.

La media de tokens aceptados por pase de verificación no es por sí sola un porcentaje de aceptación. La longitud aceptada, el trabajo rechazado, el coste del redactor, el comportamiento de agrupación de verificación, el tráfico de caché y la longitud de salida determinan la velocidad realizada. Una respuesta corta puede pasar la mayor parte del tiempo en preprocesamiento de visión y prefill. Una respuesta más larga y pesada en decodificación da a los tokens redactados aceptados más espacio para importar.

Esta es la regla práctica: si tu evaluación de DSpark empieza por la tabla de aceleración, apunta en la dirección equivocada. Empieza por la paridad de salida y el emparejamiento de artefactos. La velocidad viene después, y solo si las comprobaciones de compatibilidad pasan.

Errores comunes al adoptar LFM2.5-VL-DSpark

El primer error es tratar el sidecar como un segundo modelo de visión desplegable. Es un redactor para una ruta objetivo emparejada. Si tu plan de despliegue dice servir el archivo DSpark como el modelo, el plan es incorrecto.

El segundo error es emparejar un sidecar DSpark de texto con el objetivo VL. El material de lanzamiento de Liquid AI incluye ejemplos que pueden ser fáciles de copiar fuera de contexto. Para el lanzamiento de visión, usa el objetivo de visión actual y los artefactos DSpark de visión actuales, y luego verifica el proyector y la ruta de runtime.

El tercer error es medir tiempos antes de demostrar paridad. Una ruta rápida que cambia la salida greedy no es una ruta de aceleración válida para un decodificador especulativo que preserva el objetivo. Puede seguir siendo investigación interesante, pero no es evidencia de que DSpark acelere de forma segura tu modelo objetivo.

El cuarto error es leer una proporción de velocidad de decodificación como throughput, calidad, ahorro de memoria o latencia de producto. La velocidad de decodificación no es throughput de concurrencia. No es una mejora de calidad. No reduce automáticamente la memoria pico. No elimina el prefill. Mide cada aspecto por separado.

El quinto error es ignorar la licencia y la procedencia de artefactos. La LFM Open License v1.0 incluye términos comerciales condicionados por ingresos y un umbral descrito en el texto de la licencia. Eso no es código abierto sin restricciones. Revisa la licencia actual y obtén asesoramiento legal para los límites del despliegue comercial.

Advertencias y límites: dónde DSpark puede no ayudar

DSpark puede ayudar menos en salidas cortas y prompts muy cargados de visión donde dominan el preprocesamiento y el prefill. Si un caso de uso pide un subtítulo de una línea, quizá el sidecar no tenga suficiente longitud de decodificación para compensar la sobrecarga. Si un caso de uso produce explicaciones de gráficos más largas, razonamiento documental o respuestas de varios pasos basadas en imagen, la evaluación es más prometedora, pero sigue dependiendo de la carga de trabajo.

La deriva de backend es otro límite. H100, Apple MLX, SGLang, llama.cpp, BF16, FP16, FlashAttention, plantillas de imagen y manejo del tokenizador pueden afectar tanto a la paridad como al rendimiento. Un runtime que funciona para una ruta no demuestra que cada conversión o backend sea seguro.

El muestreo necesita cautela adicional. En principio, la decodificación especulativa puede preservar la distribución del objetivo cuando el muestreo emparejado se implementa correctamente. Eso es diferente de producir texto idéntico para cada semilla en todos los backends. Para DSpark hoy, haz de la paridad greedy con temperatura 0 la primera puerta de confianza, y luego evalúa el muestreo solo si tu runtime documenta y soporta el algoritmo emparejado.

Matriz de decisión: cuándo debería un equipo evaluar DSpark ahora

La decisión no es si DSpark es bueno. Es si el contrato de sidecar de este lanzamiento encaja con tu objetivo, backend, carga de trabajo y disciplina operativa. Ese encuadre evita que una técnica de aceleración prometedora se convierta en un atajo de despliegue sin verificar.

Lista de comprobación de implementación

Usa esta lista para el primer sprint de evaluación. Elige prompts de imagen representativos. Fija el objetivo, el proyector, el sidecar DSpark, el tokenizador, el procesador, la plantilla, la revisión del runtime, la precisión, el ajuste de bloque y el preprocesamiento de imagen. Ejecuta una línea base greedy solo con el objetivo. Ejecuta la salida greedy con DSpark y compara el texto exacto. Mide TTFT, latencia p50 y p95 de extremo a extremo, memoria pico, longitud de tokens aceptados, propuestas rechazadas, política de warmup, ajustes de caché y comportamiento de fallback solo con objetivo. Revisa la licencia. Decide el alcance del despliegue solo después de que la evidencia de paridad y medición esté en el mismo informe.

{
  "target": "LiquidAI/LFM2.5-VL-3B",
  "sidecar": "LiquidAI/LFM2.5-VL-3B-DSpark",
  "runtime": "pinned revision with VL DSpark taps, verification, and rollback",
  "parity_status": "greedy target-only versus DSpark comparison required",
  "latency_status": "measure TTFT and p50/p95 end-to-end after parity",
  "memory_status": "measure peak runtime memory, not parameter count only",
  "license_review": "required before commercial rollout",
  "fallback_ready": "target-only path documented"
}

Si tu equipo necesita ayuda para convertir esto en un banco de evaluación de inferencia reproducible, Optijara puede ayudar a definir el mapa de compatibilidad, el plan de fijación de artefactos y el registro de decisión de despliegue. El trabajo de validación todavía tiene que ocurrir en tu carga de trabajo, con tus imágenes, prompts, runtime y restricciones.