LFM2.5-2.6B-DSpark: El borrador de 328M que hace que el agente en-dispositivo de Liquid funcione 2.3× más rápido

Nadie fuera de Liquid AI ha ejecutado LFM2.5-2.6B-DSpark en su propio hardware y publicado un número todavía. Ese es el punto honesto de partida con este modelo, porque todo es una afirmación de rendimiento: no es un 2.6B mejor, es un modelo de borrador de 328M de parámetros que se sitúa delante del modelo agéntico de 2.6B LFM2.5-2.6B y propone tokens para que este los verifique, por lo que el agente corre aproximadamente el doble de rápido sin cambiar su salida.

Lanzado el 20 de agosto de 2026 con un informe técnico en Hugging Face y una publicación complementaria en el blog de Liquid, LFM2.5-2.6B-DSpark es el buque insignia de una pequeña familia de checkpoints de borrador para decodificación especulativa que Liquid publicó ese día. Todo lo que aparece en la columna de velocidad proviene de mediciones del proveedor y aún no ha sido confirmado de forma independiente; todo lo demás —el repositorio, los formatos y el soporte del framework— simplemente está ahí para que se pueda verificar.

Qué es DSpark, en una sola frase

El truco de la decodificación especulativa consiste en ejecutar un modelo borrador barato por delante del modelo real: el borrador predice el siguiente grupo de tokens, el modelo objetivo verifica todo el lote en una sola pasada hacia adelante y conserva los tokens con los que coincide. Cuando las predicciones son correctas, avanzas varios tokens al precio de uno, por lo que el rendimiento aumenta sin tocar los pesos del modelo objetivo. DSpark —la técnica, propuesta originalmente por investigadores de DeepSeek en julio de 2026 y ya implementada en DeepSeek-V4— es una versión de ese truco ajustada para modelos pequeños en el dispositivo. Liquid la llama decodificación especulativa programada por confianza, y tiene tres componentes: una columna vertebral paralela que produce estados ocultos para todos los tokens borrador en una sola pasada, una cabeza secuencial ligera que modela la dependencia entre tokens vecinos para que la tasa de aceptación no se desplome al final del bloque, y un verificador que poda los sufijos de baja confianza cuando comprobarlos costaría más de lo que ahorra.

Esa última pieza es lo que hace que DSpark se sienta diferente a un simple borrador: no siempre empuja un bloque completo a través de la verificación. Cuando la propia confianza del borrador indica que es poco probable que se acepte un sufijo, acorta el bloque y ahorra el cómputo desperdiciado. El bloque de borrador es de nueve tokens, por lo que el objetivo verifica hasta diez a la vez.

El redactor, en números

El checkpoint LFM2.5-2.6B-DSpark es un modelo borrador de solo atención con 0.3B de parámetros: cinco capas de atención completas (tamaño oculto 2,048, atención de consulta agrupada con 32 cabezas y 8 cabezas de clave-valor), un vocabulario de 128K tokens, una cabeza de Markov con rango 256 y una cabeza de confianza. Liquid lo entrenó durante 15 épocas con una mezcla de datos de instrucciones, conversación, código y llamadas a funciones — en hardware AMD — y eligió la época según la tasa de aceptación más alta, no la pérdida más baja.

Esa tasa de aceptación es el número que determina cuánto vale el redactor. En cinco pruebas de referencia con un tamaño de lote de 1 y una temperatura de 0, LFM2.5-2.6B-DSpark promedió 4.83 tokens aceptados por paso de decodificación en una H100 y 4.42 en un M4 Max — se aceptó aproximadamente la mitad del bloque, que es de donde provienen las aceleraciones de dos veces.

Las aceleraciones, etiquetadas

Todas las siguientes cifras provienen de la propia medición de Liquid AI — SGLang en un solo H100 de 80GB en BF16, y llama.cpp con el backend Metal en un MacBook Pro M4 Max en FP16 GGUF, tamaño de lote 1, temperatura 0 — y ninguna ha sido reproducida por un tercero independiente al momento de escribir esto:

• H100 promedio — 2.67×, de 323 a 864 tokens/s. Por benchmark: MATH500 3.06×, HumanEval 2.56×, MBPP 2.64×, GSM8K 2.22×, MT-Bench 2.87×.

• M4 Max media — 2.27×, de 61 a 139 tokens/s. Por benchmark: MATH500 2.25×, HumanEval 2.63×, MBPP 2.11×, GSM8K 2.36×, MT-Bench 1.99×.

• Llamada a herramientas: en escenarios de llamada a funciones con múltiples herramientas, la latencia promedio se redujo un 57%.

• Contexto de la familia — el drafter más grande de la familia, LFM2.5-8B-A1B-DSpark, alcanzó hasta 3.18× en H100 y el drafter de 1.2B hasta 2.87× en M4 Max; los números de 2.6B anteriores se sitúan en la media del grupo.

Dos cosas sobre esos números importan más allá de los promedios. Primero, se miden a temperatura 0 y tamaño de lote 1 — la configuración que favorece la especulación y la que usa mayormente el trabajo interactivo de agentes en el dispositivo. La garantía de identidad también se cumple allí: la decodificación especulativa verifica cada token propuesto, por lo que bajo decodificación codiciosa el texto emitido es exactamente el que el modelo objetivo habría producido por sí solo. Segundo, la brecha se cierra a medida que aumenta la concurrencia: en un solo H100, Liquid informa que la ventaja de DSpark converge alrededor del tamaño de lote 128, por lo que el modelo borrador es una ganancia de latencia para cargas de trabajo interactivas y con uso intensivo de herramientas, no una bala de plata de rendimiento bruto para un servidor a tope.

Qué está confirmado, y qué no

Confirmado, en el sentido de que el repositorio es público y verificable: el drafter se distribuye como Safetensors (BF16) y GGUF; se empareja con el LFM2.5-2.6B post-entrenado, no con el base; el soporte desde el primer día se integró upstream en llama.cpp (con kernels Metal experimentales) y en SGLang; está licenciado bajo la LFM Open License v1.0 de Liquid; y — importante para cualquiera que planifique su uso — la ficha del modelo indica que ningún proveedor de inferencia lo sirve, por lo que es un componente que debes ejecutar tú mismo.

Aún no se ha confirmado: que las aceleraciones se reproduzcan en otro hardware y configuraciones (nadie fuera de Liquid ha publicado una medición), cómo se comporta el drafter bajo muestreo en lugar de decodificación voraz, y si la cifra de latencia de llamada a herramienta del 57% se mantiene en entornos de agentes reales más allá del entorno de referencia que usó Liquid. Ninguna de esas es una acusación — el lanzamiento tiene un día — pero son la diferencia entre un número prometedor y uno verificado.

Ejecutándolo

En SGLang se usa una compilación con soporte para DSpark, se lanza el servidor contra el modelo objetivo y se nombra el drafter: el algoritmo especulativo es DSPARK, la ruta del modelo borrador apunta a LiquidAI/LFM2.5-2.6B-DSpark, y el tamaño de bloque se lee del config.json del borrador. En llama.cpp se carga el GGUF objetivo con el GGUF borrador como modelo de borrador y se establece el tipo de spec en draft-dspark, con el tamaño de bloque leído de los metadatos secundarios. Ambas integraciones están en el upstream, por lo que no se necesitan forks: solo una compilación lo bastante reciente como para incluirlas.

Cuándo vale la pena añadir

LFM2.5-2.6B-DSpark gana aproximadamente 0.3GB de memoria extra cuando realmente estás desplegando el agente 2.6B donde Liquid diseñó que viviera: en un teléfono, una laptop o un dispositivo de borde, para cargas de trabajo interactivas o de llamada a herramientas que están limitadas por latencia y se ejecutan de forma greedy. Ese es precisamente el perfil donde la cifra de 2.27× en el dispositivo y la reducción del 57% en la latencia de llamada a herramientas hacen su trabajo. Es menos interesante si estás sirviendo con alto lote en un servidor (el aumento de velocidad converge hacia 1×), o si tu carga de trabajo se ejecuta con temperatura por encima de cero, donde los números reportados dejan de aplicarse. Y si estás en la variante 8B-A1B de la familia, ten en cuenta el caso límite: su aumento de velocidad en el dispositivo es solo de aproximadamente 1.18× hoy en día, porque la verificación de tokens de borrador activa más expertos en el backend Metal de llama.cpp — Liquid lo señala como conocido.

Nada de DSpark cambia dónde se ejecuta el agente 2.6B — es una historia de autoalojamiento por diseño, y se ubicará junto a los modelos alojados que ya utilizas. Esa combinación de un borrador local y una docena de endpoints de API es exactamente el tipo de infraestructura que una capa de enrutamiento existe para simplificar: una clave de API para más de 200 modelos, conmutación por error automática cuando un proveedor se degrada, y precios de lista de los proveedores transferidos con un margen del 0%, de modo que la comparación de costos entre local y alojado para un agente de clase 2.6B siga siendo legible en lugar de vivir en una hoja de cálculo.

La forma correcta de leer LFM2.5-2.6B-DSpark hoy es como una prometedora afirmación de velocidad medida por el proveedor, aún no independiente, vinculada a un checkpoint real, descargable y ejecutable. Si despliegas el agente 2.6B en el dispositivo, el borrador es barato de probar y fácil de eliminar: añade los dos indicadores especulativos al comando de SGLang, mantén la decodificación greedy, y mide con tu propia carga de trabajo antes de confiar en el 2.3×. El repositorio está ahí; la verificación independiente es el punto pendiente.