El 20 de agosto, Liquid AI publicó en Hugging Face un conjunto de modelos borrador LFM2.5-DSpark, equipando con decodificación especulativa a tres modelos propios: LFM2.5-1.2B-Instruct, 2.6B y 8B-A1B. Según la empresa, la aceleración máxima alcanza las 3,18 veces, con resultados idénticos a los del modelo original.
La idea detrás de la decodificación especulativa no es complicada: un modelo pequeño adivina primero las siguientes palabras, y el modelo grande deja de calcular palabra por palabra para verificar en lote toda esa cadena de candidatas en un solo paso hacia adelante. Si el acierto es correcto se usa directamente; si falla, se recalcula. Todo el tiempo ahorrado proviene de evitar mover los pesos de un lado a otro repetidamente.
655 MB a cambio de dos o tres veces más velocidad
Los modelos borrador que Liquid AI incorpora esta vez son todos muy pequeños. La versión para el 1.2B tiene 295,7 millones de parámetros; 2.6B y 8B-A1B comparten una versión de 327,7 millones de parámetros. La estructura consta de 5 capas de atención completa, dimensión oculta de 2048, capa intermedia de 6144, 32 cabezas de consulta que comparten 8 grupos KV, proponiendo 9 palabras candidatas por ronda. Con precisión BF16, el uso de VRAM es de 655 MB.
Haciendo un cálculo rápido en un Mac con 16 GB de memoria: 655 MB representan alrededor del 4% de la memoria total, a cambio de una respuesta de diálogo local más del doble de rápida. Esa relación de intercambio resulta bastante rentable en escenarios on-device. Lo que más falta en los dispositivos locales nunca ha sido el pico de potencia de cálculo, sino esos segundos vacíos de espera.
Las cifras dependen del hardware
El benchmark oficial se dividió en dos entornos, y los resultados difieren bastante.
| Modelo objetivo | Media H100 | Pico H100 | Media M4 Max | Pico M4 Max |
|---|---|---|---|---|
| 1.2B-Instruct | 2,10x | 2,56x | 2,54x | 2,87x |
| 2.6B | 2,67x | 3,06x | 2,27x | 2,63x |
| 8B-A1B | 2,54x | 3,18x | 1,18x | 1,44x |
El 3,18x del titular proviene del mejor resultado del 8B-A1B en H100. Ese mismo modelo, al pasar a un portátil M4 Max, se queda en solo 1,18x. La propia Liquid AI explicó el motivo: el backend Metal de llama.cpp todavía no implementa bien las arquitecturas de mezcla de expertos (MoE), y el MoE on-device es el punto débil de esta solución.
También se publicaron los datos de tasa de aceptación. En MATH500, el 8B-A1B acepta en promedio 8,27 de cada 10 palabras candidatas; en GSM8K, solo 4,02. Los textos de demostraciones matemáticas tienen una estructura regular y alta previsibilidad, por lo que el modelo borrador acierta mejor; en cambio, con problemas de matemáticas de primaria redactados de forma más libre, la tasa de acierto cae de inmediato a la mitad.
Otro dato más cercano al uso práctico: en escenarios de llamadas a funciones con múltiples herramientas, la latencia de la versión 2.6B se redujo en promedio un 57%. Cada paso de un agente debe esperar a que el modelo genere una llamada estructurada, y este tipo de idas y vueltas es lo que más sufre con la acumulación de latencia.
De dónde viene el método
El nombre DSpark no lo puso Liquid AI. Proviene de un trabajo publicado en código abierto a finales de junio de este año por DeepSeek junto con la Universidad de Pekín, que usa una columna vertebral de borrador paralela combinada con una cabeza de Markov ligera, además de un mecanismo que ajusta la longitud de verificación según la carga de la GPU en tiempo real. Los datos publicados entonces mostraban un aumento del 60% al 85% en la velocidad de generación para un solo usuario, y bajo objetivos estrictos de latencia, un rendimiento por tarjeta hasta 6,6 veces mayor.
Dos meses después, este método apareció en el lanzamiento de una empresa estadounidense de modelos on-device. En SGLang se activa añadiendo el parámetro --speculative-algorithm DSPARK; llama.cpp lo soportó desde el primer día en formato FP16 GGUF sobre el backend Metal. Que los frameworks previos conviertan el nombre del algoritmo en un valor de interruptor dentro de la línea de comandos ya demuestra por sí solo que el método se trata como un estándar de facto.
En los últimos dos años, los laboratorios chinos han publicado en código abierto bastantes avances de ingeniería en el lado de la inferencia, y la discusión se ha centrado sobre todo en el ahorro de tarjetas. Este desbordamiento de DSpark trae otro tipo de retorno: el método entró en la ruta predeterminada de otros, y los despliegues posteriores basados en ese framework ejecutan ahora esta forma de pensar.
La licencia traza una línea
Los pesos se publican en los formatos Safetensors y GGUF, bajo la LFM Open License 1.0: las entidades con ingresos anuales inferiores a 10 millones de dólares pueden usarlos comercialmente de forma gratuita; por encima de esa línea es necesario negociar un acuerdo comercial aparte. El único modo de despliegue es autoalojado, Liquid AI no ofrece una API alojada.
Esa línea se sitúa justo entre las startups y las empresas medianas y grandes, con una intención bastante clara: usar la cuota gratuita para ganarse la elección predeterminada de los desarrolladores, y reservar los ingresos para quienes sí pueden pagar.
Fuentes: blog oficial de Hugging Face, ficha del modelo de Liquid AI, CocoLoop, MarkTechPost; los datos de aceleración, número de parámetros y tasa de aceptación siguen la tabla de benchmark oficial, y los términos de licencia siguen la página del modelo.