Liquid AI presenta LFM2.5-DSpark, una nueva implementación de decodificación especulativa que promete acelerar hasta 3,18 veces la generación de texto en una GPU H100 y hasta 2,87 veces en un MacBook con chip M4 Max. La propuesta busca que los modelos de lenguaje respondan más rápido sin cambiar la salida producida por el modelo original.
¿La idea es reemplazar el modelo principal? No. DSpark utiliza un modelo auxiliar pequeño para proponer varios tokens y deja que el modelo principal los verifique en una sola pasada. Así reduce el número de veces que se deben cargar los pesos desde la memoria, uno de los principales límites de velocidad durante la fase de decodificación.
Cómo funciona la decodificación especulativa
Durante la generación tradicional, un modelo produce un token, vuelve a ejecutar el proceso y genera el siguiente. Este ciclo puede ser costoso porque la inferencia suele estar limitada por el movimiento de datos entre la memoria DRAM y la memoria rápida del procesador, no únicamente por la capacidad de cálculo.
La decodificación especulativa cambia el flujo. Un modelo auxiliar, conocido como drafter, propone varios tokens. Después, el modelo objetivo los analiza en una única pasada y acepta los que coinciden con su distribución. Si rechaza alguno, utiliza su propio token y continúa la generación.
Con decodificación codiciosa, DSpark conserva exactamente la salida del modelo objetivo. La aceleración no depende de sacrificar precisión para generar más rápido.
DSpark combina tres componentes principales:
- Un bloque paralelo inspirado en DFlash, condicionado por las representaciones internas del modelo objetivo y capaz de producir estados ocultos para varios tokens en una sola ejecución.
- Una cabeza secuencial ligera, modelada como una cadena de Markov entre tokens vecinos, que incorpora dependencias entre posiciones y mejora la aceptación de tokens posteriores.
- Un verificador con programación de confianza, que estima la probabilidad de supervivencia de cada token y elimina sufijos de baja confianza cuando verificarlos costaría más de lo que ahorran.
Modelos auxiliares de unos 300 millones de parámetros
Liquid AI entrenó los modelos DSpark con una mezcla de datos más amplia, que incluye ajuste supervisado, conversaciones, código y llamadas a funciones. Las primeras versiones utilizan arquitecturas simplificadas basadas principalmente en atención, con cinco capas y un bloque de nueve tokens.
Cada modelo fue entrenado durante 15 épocas sobre el conjunto completo de datos. En lugar de elegir el punto con menor pérdida, el equipo seleccionó la época con mayor tasa de aceptación, una decisión coherente con el objetivo de acelerar la verificación.
Los modelos auxiliares resultantes son mucho más pequeños que sus modelos objetivo:
- LFM2.5-1.2B-Instruct-DSpark: 295,7 millones de parámetros.
- LFM2.5-8B-A1B-DSpark: 327,7 millones de parámetros.
- LFM2.5-2.6B-DSpark: 327,7 millones de parámetros.
El modelo auxiliar no necesita tener el mismo tamaño que el modelo principal. Su función es proponer candidatos con rapidez para que el modelo objetivo pueda verificar varios tokens al mismo tiempo.
Resultados en H100 y MacBook M4 Max
Liquid AI evaluó los modelos con SGLang en una GPU NVIDIA H100 de 80 GB usando precisión BF16. Para las pruebas en el dispositivo utilizó llama.cpp, Metal y pesos GGUF en FP16 sobre un MacBook Pro con chip M4 Max.
Las pruebas usaron tamaño de bloque DSpark de nueve, tamaño de lote de uno, temperatura cero y hasta 256 tokens de salida. Los conjuntos evaluados fueron MATH500, HumanEval, MBPP, GSM8K y MT-Bench.
En el modelo LFM2.5-2.6B, el promedio fue de 2,67 veces más velocidad en la H100, al pasar de 323 a 864 tokens por segundo. En el MacBook M4 Max, la mejora media fue de 2,27 veces, con un salto de 61 a 139 tokens por segundo.
| Conjunto | Aceptación media de 10 | H100 | M4 Max |
|---|---|---|---|
| MATH500 | 5,42 | 3,06x | 2,25x |
| HumanEval | 4,54 | 2,56x | 2,63x |
| MBPP | 4,71 | 2,64x | 2,11x |
| GSM8K | 4,32 | 2,22x | 2,36x |
| MT-Bench | 5,07 | 2,87x | 1,99x |
| Promedio | 4,81 | 2,67x | 2,27x |
El resultado es relevante para ejecutar asistentes localmente. Una velocidad cercana a 139 tokens por segundo puede hacer que una aplicación conversacional se sienta mucho más inmediata, incluso sin depender completamente de un servicio en la nube.
Diferencias entre los tres modelos
El modelo LFM2.5-1.2B-Instruct obtuvo un promedio de 2,10 veces más velocidad en la H100 y 2,54 veces en el M4 Max. Sin embargo, Liquid AI advierte que sus resultados varían más entre conjuntos de datos. La mejora puede cambiar hasta un 52% dependiendo de la distribución del texto.
El caso del LFM2.5-8B-A1B muestra una limitación importante. En la H100 alcanzó una aceleración media de 2,54 veces, con un máximo de 3,18 veces en MATH500. En el M4 Max, la mejora promedio fue de apenas 1,18 veces.
La razón está relacionada con su arquitectura de expertos múltiples, conocida como MoE. En la implementación actual de llama.cpp para Metal, verificar varios tokens puede activar más expertos y mover más pesos desde la memoria que una generación convencional. Por eso, una mayor aceptación no siempre se traduce automáticamente en mayor velocidad en un dispositivo.
Menor latencia para agentes con herramientas
Uno de los resultados más interesantes aparece en los escenarios de llamadas a funciones. En pruebas con múltiples herramientas, DSpark redujo en promedio un 57% la latencia del modelo LFM2.5-2.6B.
Esto puede beneficiar a agentes que necesitan consultar una base de datos, ejecutar código, revisar el clima o llamar a una API antes de responder. En estos sistemas, cada token adicional y cada turno de razonamiento pueden acumular retrasos visibles.
¿Significa que cualquier agente será 57% más rápido? No necesariamente. El resultado depende del modelo, las herramientas, la longitud de las respuestas y la tasa de aceptación. Aun así, apunta a un uso práctico: acelerar agentes locales sin cambiar el comportamiento del modelo objetivo.
Compatibilidad con llama.cpp y SGLang
Los modelos DSpark llegan con soporte desde el primer día para llama.cpp y SGLang. Liquid AI publicó las integraciones en los repositorios oficiales mediante los PR #27383 para llama.cpp y #31041 para SGLang.
Para ejecutar el modelo con SGLang, se necesita una compilación con soporte DSpark y un modelo objetivo acompañado por su modelo auxiliar:
python -m sglang.launch_server \\
--model-path LiquidAI/LFM2.5-2.6B \\
--speculative-algorithm DSPARK \\
--speculative-draft-model-path LiquidAI/LFM2.5-2.6B-DSpark \\
--speculative-draft-attention-backend flashinfer \\
--disable-radix-cache --mem-fraction-static 0.75 --port 30000
El servidor expone un endpoint compatible con la API de OpenAI en http://localhost:30000/v1. La línea base se obtiene ejecutando el mismo comando sin las opciones de decodificación especulativa.
En llama.cpp, la configuración equivalente utiliza un archivo GGUF para el modelo objetivo y otro para el modelo auxiliar:
llama-server -m LFM2.5-2.6B-F16.gguf \\
-md LFM2.5-2.6B-DSpark-F16.gguf \\
--spec-type draft-dspark --spec-draft-n-max 10 --spec-draft-n-min 0 \\
-fa on -ngl 99
El tamaño real del bloque se obtiene desde la configuración del modelo o desde los metadatos del archivo auxiliar. Las métricas por respuesta también informan cuántos tokens propuso el modelo auxiliar y cuántos fueron aceptados.
Modelos disponibles para descargar
Los puntos de control están disponibles en Hugging Face en formatos Safetensors y GGUF:
También existen versiones GGUF preparadas para flujos de trabajo con llama.cpp. Como siempre, las cifras de rendimiento deben interpretarse como referencias: el hardware, el backend, la cuantización, el tamaño de contexto y el tipo de texto pueden cambiar significativamente el resultado.
LFM2.5-DSpark no elimina el costo de ejecutar un modelo grande, pero ataca uno de los cuellos de botella más importantes de la inferencia: la memoria. La posibilidad de obtener mejoras cercanas a tres veces en una GPU y más de dos veces en un portátil refuerza una tendencia clara: la IA local no solo depende de modelos más pequeños, sino también de técnicas de ejecución más inteligentes.
Para desarrolladores de agentes, aplicaciones de código y asistentes offline, esa diferencia puede convertir una respuesta que se siente lenta en una experiencia realmente interactiva.