Liquid AI ha publicado DSpark, una técnica de decodificación especulativa que acelera hasta 3,18 veces la inferencia de sus modelos LFM2.5 sin cambiar la salida. Los checkpoints están en Hugging Face desde el 20 de agosto, en Safetensors y GGUF.
Puntos clave
- En una H100, el LFM2.5-8B-A1B pasa de 428 a 1.362 tokens por segundo. Son 3,18 veces más.
- El 2.6B pasa de 325 a 933 tokens por segundo (2,87x) y el 1.2B de 668 a 1.712 (2,56x).
- En CPU, sobre una MacBook con M4 Max, el 1.2B pasa de 136 a 389 tokens por segundo (2,87x) y el 2.6B de 61 a 161 (2,63x).
- En llamadas a funciones la latencia baja un 57% de media.
- La salida es idéntica a la del modelo sin especulación. No hay pérdida de calidad.
Cómo funciona la decodificación especulativa
La idea lleva tiempo en la literatura y aquí está bien ejecutada. Un modelo borrador muy pequeño propone varios tokens de golpe. El modelo grande los verifica todos en una sola pasada hacia delante, en lugar de generarlos uno a uno.
Si el borrador acierta, te ahorras varias pasadas del modelo grande. Si falla, se descarta desde el punto del error y se sigue. Como la verificación la hace siempre el modelo grande, el texto final es exactamente el que habría salido sin especulación.
Los borradores son pequeños de verdad: unos 296 millones de parámetros para acompañar al 1.2B, y unos 328 millones para el 2.6B y el 8B-A1B.
Los tres componentes
DSpark combina tres piezas. Un backbone paralelo al estilo DFlash condicionado por características del contexto. Una cabeza secuencial ligera modelada como cadena de Markov. Y un verificador con planificación de confianza que predice qué probabilidad tiene cada token de sobrevivir a la verificación.
Esa tercera pieza es la que decide cuánto se gana. De cada diez tokens propuestos, la aceptación va de 3,90 a 8,52 según modelo y dataset. Un borrador que propone mucho y acierta poco no acelera nada, porque el coste de verificar y descartar se come la ganancia.
Los benchmarks usados son MATH500, HumanEval, MBPP, GSM8K, MT-Bench y BFCL.
El número que más importa es el del MacBook
Las cifras de H100 están bien para presentaciones. La que cambia decisiones es la de CPU.
Pasar de 136 a 389 tokens por segundo en un portátil, sin GPU dedicada, mueve un modelo de 1.200 millones de parámetros de "va lento pero funciona" a velocidad de conversación. Y esos tokens salen de tu máquina, sin API, sin factura y sin que el dato salga de tu equipo.
El 8B es la excepción: en CPU solo gana 1,44x, contra 3,18x en H100. En un M4 Max la limitación es el ancho de banda de memoria, no el cómputo, y la especulación ayuda menos.
El 57% menos de latencia en llamadas a funciones es el dato para agentes. Un agente que encadena diez herramientas paga esa latencia diez veces.
Un mes muy activo
Liquid AI lleva semanas publicando. El 20 de agosto contamos que recupera el 97% de la precisión perdida al cuantizar, el 12 de agosto lanzó el LFM2.5-VL-3B de visión para edge y el 5 de agosto el LFM2.5-2.6B para agentes locales con 128K de contexto.
Hay soporte desde el primer día en llama.cpp (PR 27383) y en SGLang (PR 31041), así que no hace falta esperar a que alguien lo integre.
Por qué importa
Si estás descartando modelos locales por lentos, este es el momento de volver a medir. Triplicar tokens por segundo en el portátil que ya tienes cambia qué tareas puedes mover fuera de la API.
Donde más se nota es en volumen repetitivo con dato sensible: clasificar correos, extraer campos de facturas, etiquetar tickets. Miles de llamadas pequeñas donde la factura de API se acumula y el contenido no debería salir de casa.
Y como la salida es idéntica a la del modelo sin especulación, probarlo no tiene coste de calidad. Es cambiar un checkpoint y medir.
Fuente original: Hugging Face
Relacionado
