Liquid AI LFM2.5-VL-3B-DSpark acelera la decodificación visual, pero el titular de 3,13x cuenta solo la mitad de la historia

Liquid AI lanzó LFM2.5-VL-3B-DSpark con un resultado destacado de una decodificación hasta 3,13x más rápida para su modelo compacto de visión-lenguaje. La mejora se dirige a la generación de tokens, no al proceso completo de comprender una imagen y producir una respuesta.

Esa distinción define la relevancia de Liquid AI LFM2.5-VL-3B-DSpark. El modelo borrador experimental demuestra que la decodificación especulativa puede funcionar en tareas visuales y textuales, tanto en centros de datos como en hardware de consumo. Sin embargo, los propios resultados de Liquid AI sitúan la mejor mejora integral en 2,62x, por debajo de la cifra máxima de decodificación.

El lanzamiento impulsa a los desarrolladores a reconsiderar cómo optimizan las aplicaciones locales de visión-lenguaje. La compresión de modelos y las arquitecturas más pequeñas ya no son las únicas vías para reducir la latencia. Un borrador independiente puede acelerar un modelo objetivo existente mientras preserva su comportamiento de salida bajo configuraciones de decodificación equivalentes.

Por tanto, la comparación no enfrenta a Liquid AI con un único modelo rival. Enfrenta la decodificación especulativa con la práctica convencional de hacer el modelo principal de visión-lenguaje más pequeño, más simple o menos preciso para ganar velocidad.

Liquid AI LFM2.5-VL-3B-DSpark incorpora un modelo borrador dedicado

El lanzamiento separa la calidad de las respuestas de una parte importante del problema de la latencia.

Liquid AI LFM2.5-VL-3B-DSpark es un modelo borrador de 279,5 millones de parámetros creado específicamente para LFM2.5-VL-3B. No sustituye al modelo objetivo de 3.000 millones de parámetros ni responde solicitudes de forma independiente. En su lugar, propone varios tokens probables antes de que el modelo mayor los verifique conjuntamente.

Este proceso se denomina decodificación especulativa, un método que utiliza un predictor más pequeño para redactar tokens que el modelo objetivo verifica en paralelo. Los tokens aceptados reducen el número de costosas pasadas por el modelo objetivo necesarias para generar una respuesta. Las propuestas rechazadas son corregidas por el modelo objetivo.

Liquid AI afirma que el borrador contiene cuatro capas de atención completa, una cabeza de Markov y una cabeza de confianza. Su bloque de entrenamiento contiene nueve tokens propuestos. El despliegue utiliza bloques de ocho o nueve, según el hardware y el marco de inferencia.

La compañía publicó el modelo en formatos Safetensors y GGUF a través de su repositorio de modelos. Es compatible con SGLang en GPU Nvidia, MLX-VLM en Apple silicon y llama.cpp mediante el checkpoint GGUF.

Esta cobertura de marcos importa porque la aceleración de inferencia suele quedar limitada a un artículo o a una implementación de investigación personalizada. Aquí, Liquid AI ha conectado su borrador a tres vías de despliegue ya utilizadas para servidores, Mac y modelos locales cuantizados.

SGLang requiere la versión 0.5.19 o posterior para la configuración publicada. MLX-VLM requiere la versión 0.7.2 o posterior y actualmente ejecuta esta implementación de DSpark con muestreo codicioso. Liquid AI indica a los usuarios de MLX que establezcan la temperatura en cero.

El modelo objetivo llegó antes que el borrador. Liquid AI presentó LFM2.5-VL-3B en agosto de 2026 como un modelo de visión-lenguaje de pesos abiertos orientado al despliegue en el borde. El modelo combina una columna vertebral lingüística con un codificador visual para imágenes, documentos, grounding, reconocimiento óptico de caracteres y uso de herramientas visuales.

Liquid AI afirmó anteriormente que el modelo objetivo podía decodificar 228 tokens por segundo en un M5 Max. También reportó 116 tokens por segundo en un Ryzen AI Max+ 395 y 20 en un Galaxy S26 Ultra. Esas cifras anteriores procedían de las propias pruebas de la compañía.

El lanzamiento de DSpark cambia el paquete de despliegue, no las capacidades aprendidas del modelo subyacente. Los desarrolladores incorporan el borrador durante la inferencia, mientras LFM2.5-VL-3B sigue siendo responsable de aprobar cada token generado.

Bajo decodificación codiciosa, el modelo objetivo acepta un token borrador solo cuando coincide con el token que habría seleccionado por sí mismo. Por tanto, la respuesta resultante debería coincidir con la generación codiciosa ordinaria. Con temperaturas distintas de cero, el muestreo equivalente puede preservar la distribución de salida del modelo objetivo en lugar de una única secuencia determinista.

Esta propiedad otorga a la decodificación especulativa una propuesta de valor distinta de la cuantización o la destilación. Esas técnicas pueden alterar la precisión numérica, el tamaño del modelo o el comportamiento aprendido. DSpark, en cambio, intenta reducir el tiempo dedicado a alcanzar las decisiones originales del modelo objetivo.

Por ello, el lanzamiento plantea una competencia relevante entre dos vías de optimización. Los desarrolladores pueden reducir el trabajo realizado por el modelo principal, o pueden predecir una mayor parte de ese trabajo y verificar esas predicciones de manera eficiente.

El resultado de 3,13x depende del hardware, la carga de trabajo y la medición

La cifra más alta de Liquid AI describe un resultado de decodificación, no una aceleración universal de la aplicación.

Liquid AI evaluó el borrador en seis categorías de MMSpec: preguntas y respuestas visuales generales, reconocimiento de texto, descripción de imágenes, análisis de gráficos, razonamiento complejo y conversación de múltiples turnos. La compañía probó un tamaño de lote de uno en hardware Apple y una GPU H100.

En un M5 Max con MLX-VLM, Liquid AI reportó mejoras de decodificación de entre 2,30x y 3,13x. Las mejoras integrales oscilaron entre 1,56x y 2,62x. El máximo de 3,13x se produjo en la carga de trabajo de descripción de imágenes COCO.

La compañía también probó un M3 Ultra con llama.cpp. La decodificación mejoró entre 1,57x y 2,14x, según lo reportado, mientras que el rendimiento integral mejoró entre 1,30x y 1,77x.

En una única GPU H100 de 80 GB con SGLang, Liquid AI midió mejoras de decodificación de entre 2,04x y 2,66x. Las mejoras integrales oscilaron entre 1,64x y 2,27x. La divulgación detallada de benchmarks de la compañía proporciona configuraciones y resultados por tarea.

Estas pruebas utilizaron procesamiento de 16 bits para el codificador visual y la columna vertebral lingüística. La configuración H100 utilizó BF16, un bloque borrador de nueve, tamaño de lote de uno y temperatura cero. Las pruebas de Apple utilizaron FP16, un bloque de ocho y hasta 2.048 tokens generados.

La longitud mediana de respuesta en la evaluación de Apple fue de 90 tokens. Ese detalle es importante porque la longitud de salida modifica cuánto tiempo de una solicitud se dedica a la decodificación. Un sistema que produce una descripción larga da al borrador más tiempo para compensar su sobrecarga inicial.

Las respuestas cortas generan un equilibrio menos favorable. Si una aplicación devuelve una etiqueta, una coordenada o una frase, la codificación de imagen y el procesamiento del prompt pueden dominar. La generación más rápida afecta entonces a una porción menor de la espera total.

La aceptación de borradores ayuda a explicar la aceleración reportada. Liquid AI midió aproximadamente entre 3,2 y 4,5 tokens aceptados por pasada de verificación en los entornos Apple. Sus resultados en H100 oscilaron entre 3,46 y 4,57 tokens aceptados.

Una mayor longitud de aceptación implica que el modelo objetivo valida más salida útil en cada pasada. Sin embargo, la aceptación no se traduce directamente en ganancias de velocidad equivalentes. La ejecución del borrador, la sincronización, el acceso a memoria y la sobrecarga del marco siguen consumiendo tiempo.

Los resultados también varían según la tarea. La descripción de imágenes produjo la mayor mejora de decodificación en MLX, mientras que la conversación de múltiples turnos registró 2,30x. Las ganancias integrales fueron de 2,59x y 1,91x, respectivamente.

Esa variación impide interpretar responsablemente “hasta 3,13x” como un resultado esperado para todos los asistentes visuales. Es un techo observado en una configuración publicada. El resultado de una aplicación dependerá de su hardware, longitud del prompt, longitud de salida, parámetros de muestreo y carga de trabajo visual.

Liquid AI afirma que DSpark mantuvo una ventaja con mayor concurrencia en sus pruebas con H100. Sin embargo, la diferencia se redujo a medida que aumentaba la concurrencia. Esto sugiere que el beneficio relativo del borrador cambia cuando la GPU pasa de una decodificación limitada por memoria a una ejecución limitada por cómputo.

Para los equipos de producto, la pregunta práctica no es si la cifra máxima es real dentro de la prueba de Liquid AI. La pregunta es si su perfil de latencia se parece al de la prueba que la produjo. Esto requiere medir cada fase de inferencia en lugar de copiar un multiplicador llamativo en los planes de capacidad.

Cómo la decodificación especulativa de Liquid AI preserva el modelo objetivo

DSpark intenta avanzar más en el borrador sin convertir los errores de predicción en salida final.

La generación autorregresiva estándar produce un token tras otro. Cada nuevo token requiere otra pasada por el modelo objetivo, incluso cuando la continuación es muy predecible. Esta estructura serial puede dejar el hardware infrautilizado durante la decodificación limitada por memoria.

La decodificación especulativa introduce un modelo más pequeño en ese ciclo. El borrador propone un bloque de tokens futuros y el modelo objetivo evalúa esas posiciones de forma conjunta. Se ahorra trabajo cuando varias propuestas superan la verificación.

El desafío consiste en producir propuestas con suficiente rapidez y precisión como para justificar el modelo adicional. Un borrador débil genera tokens rechazados. Un borrador pesado predice bien, pero consume demasiado tiempo al producir su bloque.

DSpark combina generación paralela con un componente secuencial ligero. Su cabeza de Markov introduce una dependencia limitada entre las posiciones propuestas, mientras que la cabeza de confianza estima si las propuestas posteriores deberían verificarse. Este diseño busca preservar la coherencia del bloque sin hacer que el borrador sea plenamente autorregresivo.

La investigación de DSpark subyacente describe el enfoque como decodificación especulativa programada por confianza con generación semiautorregresiva. Su principal equilibrio se refiere a la calidad de las propuestas, la latencia del borrador y la cantidad de tokens enviados a verificación.

El borrador puramente paralelo puede generar un bloque rápidamente, pero la precisión suele caer para los tokens más alejados dentro de ese bloque. Cada posición depende de un contexto que incluye conjeturas anteriores. Por tanto, los errores pueden acumularse a lo largo de la propuesta.

Un borrador plenamente autorregresivo mantiene dependencias más sólidas, pero recrea parte del cuello de botella serial. La estructura híbrida de DSpark intenta situarse en un punto intermedio. Añade una pequeña cabeza secuencial después de la operación de borrador paralelo.

El mecanismo de confianza aborda otra fuente de desperdicio. Verificar un bloque fijo completo tiene poco sentido cuando el borrador espera que sus tokens posteriores fallen. Un programador puede acortar el prefijo enviado antes de que las posiciones de baja confianza consuman capacidad del modelo objetivo.

La configuración publicada de LFM2.5-VL-3B-DSpark utiliza una cabeza de Markov de rango 256 y una cabeza de confianza independiente. Su vocabulario contiene 128.000 tokens. La arquitectura sigue ligada a su modelo objetivo designado y no puede servir como borrador general listo para usar para cualquier VLM.

Esa relación específica con el modelo es tanto una fortaleza como una limitación. Entrenar frente a un único modelo objetivo puede mejorar la alineación de las propuestas. Sin embargo, un equipo que cambie a otro modelo objetivo necesita un checkpoint compatible, un proceso de entrenamiento y una integración de tiempo de ejecución.

La descripción de “sin pérdida” también requiere una interpretación precisa. Bajo decodificación codiciosa con temperatura cero, la verificación preserva las elecciones exactas de tokens que el modelo objetivo haría por sí solo. El borrador no recibe permiso para sustituirlas por una alternativa meramente plausible.

Con temperaturas distintas de cero, el objetivo cambia de reproducir una secuencia a preservar la distribución del modelo objetivo. El muestreo especulativo correcto puede lograrlo bajo configuraciones equivalentes, según la investigación fundamental sobre muestreo. La velocidad sigue dependiendo de la frecuencia con que se alineen las distribuciones del borrador y del modelo objetivo.

Liquid AI informa de que aumentar la temperatura redujo la aceptación en sus experimentos. La probabilidad se distribuye más hacia tokens de menor rango, lo que crea más oportunidades de desacuerdo entre el borrador y el modelo objetivo. En consecuencia, el muestreo creativo puede ofrecer ganancias menores que la generación determinista.

Esto es importante para el diseño de aplicaciones. La extracción de documentos, el anclaje visual, la lectura de gráficos y las respuestas con restricciones suelen usar temperaturas bajas. Las conversaciones abiertas sobre imágenes pueden requerir más muestreo, lo que hace que los resultados greedy publicados sean menos representativos.

Por tanto, la decodificación especulativa de Liquid AI encaja especialmente bien con salidas predecibles. La generación de subtítulos para imágenes estandarizadas de productos, la lectura de recibos, la descripción de capturas de pantalla de interfaces y la extracción de datos estructurados son cargas de trabajo plausibles. Sus beneficios reales aún requieren medición local.

Una Decodificación Más Rápida No Elimina el Cuello de Botella de Visión-Lenguaje

La principal incertidumbre es qué parte de una solicitud real permanece fuera de la fase de decodificación acelerada.

Una solicitud de visión-lenguaje implica más trabajo que la generación de texto. El sistema debe codificar la imagen, transformarla en representaciones visuales, procesar esos tokens visuales junto con el prompt y, después, decodificar la respuesta.

DSpark acelera únicamente la etapa final. No acelera la codificación de imágenes. También deja sin cambios el prefill, lo que significa que el modelo objetivo aún procesa el prompt y el contexto de tokens visuales antes de generar su primer token de respuesta.

Ese límite explica la diferencia entre los resultados de decodificación y los resultados de extremo a extremo. Liquid AI informó de una decodificación hasta 3.13x más rápida en el M5 Max, pero su mejora total máxima fue de 2.62x. Otras tareas mostraron diferencias más amplias.

En TextVQA, la empresa midió una mejora de 2.69x en decodificación y una ganancia de 1.56x de extremo a extremo en el M5 Max. El resultado implica que el procesamiento de imágenes y el prefill consumían una parte sustancial del tiempo original de la solicitud.

La limitación responde a la ley de Amdahl, que limita la aceleración global cuando una parte de la carga de trabajo permanece sin cambios. Si la decodificación representa la mitad de la latencia base, incluso un decodificador infinitamente rápido no puede mejorar la solicitud completa más allá de 2x.

El hardware de edge hace que esta restricción sea especialmente relevante. Los dispositivos de consumo ofrecen menos capacidad de cómputo que las GPU de centros de datos para la codificación de visión y el prefill de contexto largo. Una imagen grande o un prompt con múltiples imágenes puede retrasar el primer token antes de que la decodificación especulativa empiece a ayudar.

El benchmark independiente MMSpec refuerza la necesidad de una interpretación prudente. Sus autores evaluaron 600 muestras en seis categorías de tareas y diez métodos de decodificación especulativa. Descubrieron que la aceleración del throughput por sí sola no representaba de forma fiable el rendimiento de latencia.

MMSpec también descubrió que las técnicas diseñadas para modelos de lenguaje solo de texto pueden degradarse en entornos multimodales. Las dependencias entre modalidades cambian qué propuestas tienen probabilidades de sobrevivir. La conciencia visual cobra mayor importancia a medida que aumentan los tamaños de lote.

Liquid AI siguió las categorías de tareas de MMSpec, lo que mejora la amplitud de su evaluación interna. Sin embargo, Liquid AI realizó y publicó por sí misma las pruebas de rendimiento de DSpark. Las replicaciones independientes en dispositivos comunes y con prompts de producción siguen siendo limitadas.

La referencia de comparación merece la misma atención. Los multiplicadores publicados comparan el mismo modelo objetivo LFM2.5-VL-3B con y sin su drafter bajo frameworks especificados. No demuestran que el sistema combinado supere a todos los VLM competidores.

Tampoco comparan el sistema con estrategias alternativas de latencia. Los desarrolladores pueden cuantizar el modelo objetivo, reducir la resolución de imagen, almacenar en caché embeddings visuales, acortar los prompts, agrupar solicitudes o elegir un modelo más pequeño. Estos cambios afectan a distintas partes del presupuesto de latencia.

La memoria es otra consideración operativa. El drafter es pequeño junto al modelo objetivo de 3.000 millones de parámetros, pero no es gratuito. Sus pesos, caché, estado de ejecución e integración consumen capacidad, algo relevante en dispositivos con recursos limitados.

La compatibilidad genera más fricción. SGLang, MLX-VLM y llama.cpp ahora ofrecen rutas publicadas, pero los equipos que usan otros sistemas de serving no pueden asumir soporte inmediato. La adopción en producción requiere carga estable, observabilidad, comportamiento de batching y gestión de fallos.

La ruta actual de DSpark solo greedy de MLX-VLM limita sus casos de uso inmediatos. Las aplicaciones que dependen de generación con muestreo necesitan otra pila compatible o deben esperar un soporte de muestreo más amplio. Incluso entonces, temperaturas más altas pueden reducir la aceptación de borradores.

Por tanto, el lanzamiento debe evaluarse como una optimización de sistemas creíble con límites claramente establecidos. No demuestra que la inferencia visual se haya vuelto 3.13x más rápida en todos los sentidos relevantes.

La Competencia Real Es Mejor Predicción Frente a Menos Trabajo del Modelo

DSpark refuerza una vía en la que los desarrolladores mantienen intacto el modelo objetivo y optimizan la frecuencia con la que debe ejecutarse.

La respuesta estándar de la IA en edge a la latencia ha sido reducir la carga de trabajo del modelo objetivo. Los equipos usan menos parámetros, menor precisión, prompts más cortos, imágenes más pequeñas o destilación específica para tareas. Cada técnica puede mejorar la capacidad de respuesta, pero también puede introducir compromisos de calidad o flexibilidad.

Liquid AI LFM2.5-VL-3B-DSpark propone otra vía. Mantener el modelo objetivo existente y predecir varios pasos futuros con un acompañante especializado. Permitir que el modelo objetivo verifique esas conjeturas sin ceder el control sobre la salida final.

Esta vía resulta atractiva cuando un equipo ya acepta las capacidades del modelo objetivo. Sustituirlo exigiría nuevas evaluaciones, cambios de prompts, comprobaciones de seguridad y ajustes del producto. Incorporar un drafter puede preservar una mayor parte de esa inversión.

El enfoque también se adapta al despliegue local, donde el ancho de banda de memoria restringe con frecuencia la generación de tokens. Verificar un bloque puede utilizar el hardware de forma más eficiente que cargar repetidamente el estado del modelo para un solo token. Los resultados de Liquid AI en Apple hacen concreta esa posibilidad.

Sin embargo, los modelos más pequeños conservan ventajas. Simplifican el empaquetado, reducen el uso total de memoria y aceleran etapas que una optimización solo del decodificador no puede tocar. Un codificador visual compacto puede mejorar el tiempo hasta el primer token, mientras que DSpark no puede hacerlo.

La cuantización también puede combinarse con la decodificación especulativa, en lugar de competir exclusivamente con ella. Liquid AI proporciona un drafter GGUF emparejado con su modelo objetivo GGUF. Por tanto, una pila local puede reducir la precisión y añadir drafting, siempre que el runtime admita correctamente la pareja.

Esta combinación desplaza la cuestión de ingeniería de elegir una técnica a asignar cada técnica al cuello de botella adecuado. La cuantización reduce el tamaño de los pesos y el coste aritmético. El preprocesamiento de imágenes modifica el coste de visión. La especulación se dirige a la generación autorregresiva.

Por eso el perfilado a nivel de fase se vuelve esencial. Un asistente documental que analiza páginas de alta resolución puede pasar la mayor parte de su tiempo antes de la decodificación. Una herramienta de chat visual que produce descripciones detalladas puede dedicar mucho más tiempo a generar salida.

La misma distinción se aplica a la experiencia de usuario. El tiempo hasta el primer token determina si una aplicación parece receptiva al inicio. Los tokens por segundo determinan si una respuesta larga se percibe fluida después de que comienza la generación.

DSpark mejora directamente la segunda medida. Mejora la latencia total cuando la decodificación ocupa una porción suficiente de la solicitud. No garantiza una mejora proporcional en la primera.

Los desarrolladores también deben separar la velocidad para un solo usuario del throughput de toda la flota. Liquid AI observó una ventaja en los niveles de concurrencia H100 medidos, pero la diferencia se redujo con cargas más altas. La economía de producción depende de las mezclas de solicitudes, el batching y los objetivos de nivel de servicio.

Por tanto, el aspecto más relevante del lanzamiento es arquitectónico. Liquid AI ha empaquetado la decodificación especulativa como parte de una familia de modelos visuales desplegables, en lugar de presentarla únicamente como investigación.

Si este patrón se extiende, los lanzamientos de modelos podrían incluir cada vez más un modelo objetivo, múltiples cuantizaciones y drafters específicos para hardware. La optimización de inferencia pasaría a formar parte del artefacto del modelo, en lugar de ser una decisión de serving tomada después de su lanzamiento.

Esta dirección presiona a otros desarrolladores de modelos de pesos abiertos. Publicar solo un checkpoint deja a los equipos posteriores la responsabilidad de la aceleración. Distribuir un drafter emparejado ofrece una historia de latencia más completa, incluso cuando las ganancias medidas siguen dependiendo de la carga de trabajo.

Tres Señales Mostrarán Si la Aceleración Importa en la Práctica

Las pruebas independientes, un soporte de muestreo más amplio y los perfiles de aplicaciones reales determinarán si DSpark se convierte en un patrón de despliegue repetible.

La primera señal es la replicación independiente en hardware accesible. Los desarrolladores deberían estar atentos a pruebas en Macs de la serie M, GPU de consumo y sistemas edge que utilicen prompts idénticos con y sin el drafter.

Los informes útiles deben revelar las dimensiones de imagen, la longitud del prompt, la longitud de salida, la temperatura, la cuantización y la versión del runtime. Una única cifra de tokens por segundo no puede explicar si la respuesta completa de la aplicación se volvió significativamente más rápida.

Una replicación cercana a los rangos de Liquid AI reforzaría el caso de la empresa. Ganancias menores o inconsistentes sugerirían que las cargas de trabajo publicadas favorecen al drafter más de lo que lo hacen las aplicaciones cotidianas.

La segunda señal es un soporte más amplio de runtimes y muestreo. MLX-VLM actualmente limita la ruta publicada de DSpark a la generación greedy, mientras que SGLang se orienta al despliegue en Nvidia y llama.cpp atiende casos de uso de GGUF.

El soporte en motores de inferencia adicionales reduciría el coste de integración. Un muestreo estable a temperaturas distintas de cero también haría que el método fuera más relevante para herramientas de chat visual y descripción creativa.

Los desarrolladores deberían examinar las tasas de aceptación a medida que cambia el muestreo. Liquid AI afirma que temperaturas más altas redujeron la aceptación y el throughput en sus experimentos. Las pruebas de producción deberían revelar si esos descensos siguen siendo aceptables para productos conversacionales.

La tercera señal es si los equipos informan de ganancias a nivel de fase en aplicaciones reales. Las métricas decisivas son el tiempo hasta el primer token, la tasa de decodificación, la latencia de extremo a extremo, la memoria máxima y el throughput bajo la concurrencia esperada.

Un asistente visual de formato largo puede beneficiarse de forma sustancial porque la generación domina su sesión. Un flujo de trabajo de OCR que devuelve unos pocos campos puede ganar mucho menos porque la codificación de visión y el prefill ocupan la mayor parte de la solicitud.

Los equipos que evalúen Liquid AI LFM2.5-VL-3B-DSpark deberían empezar con trazas, no con multiplicadores de titulares. Midan la proporción de la referencia consumida por la codificación de imágenes, el prefill y la decodificación. Después, incorporen el drafter y repitan la misma carga de trabajo.

Comprueben la equivalencia de salida bajo decodificación greedy y el comportamiento distribucional bajo muestreo compatible. Midan por separado los arranques en caliente y en frío. Incluyan presión de memoria y condiciones térmicas sostenidas al probar portátiles o sistemas de clase móvil.

El lanzamiento proporciona suficiente detalle de implementación para hacer posibles esas evaluaciones. También ofrece a los desarrolladores un recordatorio útil: la capacidad del modelo y el comportamiento de inferencia son problemas de ingeniería separados.

La cifra de 3.13x de Liquid AI se entiende mejor como evidencia de que un drafter emparejado puede acelerar de manera material una fase de la inferencia multimodal local. Las cifras de extremo a extremo muestran tanto el valor como el límite de esa afirmación.

¿Se convertirán los modelos draft emparejados en acompañantes estándar para los VLM de pesos abiertos, o seguirán siendo optimizaciones especializadas para cargas de trabajo con salidas largas? La respuesta vendrá de trazas de aplicaciones reproducibles, no de un único benchmark máximo.