Liquid AI anunció el 20 de agosto de 2026 la disponibilidad de los checkpoints de borrador DSpark para tres modelos de su familia LFM2.5: LFM2.5-1.2B-Instruct, LFM2.5-2.6B y LFM2.5-8B-A1B. La propuesta está dirigida a cargas de inferencia en las que el modelo genera respuestas o encadena varias llamadas a herramientas.
Según el anuncio de Liquid AI, DSpark incorpora una ruta de decodificación especulativa. Un modelo de borrador más pequeño propone varios tokens y el modelo objetivo los comprueba después. Liquid AI afirma que, cuando se utiliza decodificación codiciosa, la salida resultante es idéntica a la que produciría el modelo objetivo por sí solo. El objetivo del lanzamiento es reducir el tiempo de ejecución, no modificar las respuestas del modelo.
Las cifras cambian según el equipo y la carga
La empresa comunica mejoras máximas de rendimiento de 3,18 veces en GPU y de 2,87 veces en dispositivo para los modelos incluidos. En LFM2.5-2.6B, las mejoras medias publicadas alcanzan 2,67 veces en un H100 y 2,27 veces en un MacBook Pro con chip M4 Max.
Liquid AI también comunica una reducción media del 57 % en la latencia de las llamadas a funciones para LFM2.5-2.6B, medida en varios escenarios con múltiples herramientas. Para una aplicación que debe completar una secuencia de llamadas, esa reducción puede traducirse en respuestas más rápidas. Las cifras, sin embargo, corresponden a configuraciones de prueba concretas: no representan una garantía de velocidad para cualquier equipo, motor o flujo de trabajo.
Qué añade DSpark a la inferencia
El sistema combina una arquitectura base paralela de estilo DFlash, un cabezal secuencial ligero modelado como una cadena de Markov y un verificador de planificación basado en confianza. Los primeros modelos de borrador son redes simplificadas que utilizan únicamente atención, con cinco capas y un bloque de nueve.
Cada modelo de borrador contiene aproximadamente 300 millones de parámetros. El checkpoint asociado a LFM2.5-1.2B-Instruct tiene 295,7 millones, mientras que los otros dos cuentan con 327,7 millones cada uno. Su función es proponer tokens con rapidez; la responsabilidad de comprobarlos sigue recayendo en el modelo objetivo.
Liquid AI evaluó el sistema en MATH500, HumanEval, MBPP, GSM8K y MT-Bench. Las pruebas utilizaron un tamaño de bloque DSpark de nueve, un tamaño de lote de uno y temperatura cero. Por eso, los resultados publicados describen un escenario de evaluación definido, no un modo rápido independiente de la configuración.
Compatibilidad con llama.cpp y SGLang desde el lanzamiento
Los checkpoints están disponibles en Hugging Face en formatos Safetensors y GGUF para los tres modelos. Liquid AI afirma que la integración se incluye desde el lanzamiento en llama.cpp y SGLang. En SGLang, sus ejemplos emplean el algoritmo especulativo DSPARK; en llama.cpp utilizan el tipo especulativo draft-dspark. En ambos casos se necesitan archivos independientes para el modelo objetivo y para el de borrador.
Las mediciones de LFM2.5-2.6B se realizaron con llama.cpp y Metal en un MacBook Pro con chip M4 Max, usando pesos GGUF FP16, y con SGLang en un H100 de 80 GB, usando pesos BF16. Liquid AI atribuye parte de la diferencia entre los resultados de GPU y de dispositivo en LFM2.5-8B-A1B a la implementación actual de Metal en llama.cpp y al tráfico adicional de pesos generado por sus expertos.
Para quienes ya utilizan LFM2.5, DSpark ofrece una vía de inferencia potencialmente más rápida a cambio de un consumo de memoria algo mayor. La decisión depende, por tanto, de si el entorno puede asumir ese coste y de cuánto se parezca su carga a las pruebas publicadas. El modelo objetivo mantiene el control de la salida, mientras el borrador intenta acelerar el proceso; esa es la mejora concreta y también el límite de lo que el anuncio permite concluir.