LFM2.5-DSpark: inferencia 3,2x más rápida en H100 y Mac

¿Qué es LFM2.5-DSpark y por qué importa para los founders?

Liquid AI presentó el 20 de agosto de 2026 LFM2.5-DSpark, una familia de modelos draft (de borrador) open-source que acelera la inferencia de sus modelos LFM2.5 hasta 3,18x en GPU H100 y 2,87x en un MacBook Pro M4 Max, sin alterar la calidad de la salida. La compañía publicó los checkpoints en Hugging Face, junto con integración nativa para llama.cpp y SGLang desde el día uno. Para un founder que corre LLMs en producción, esto significa una reducción directa del costo por token y de la latencia de respuesta, dos variables que definen la viabilidad económica de cualquier producto agéntico.

El dato más relevante para casos de uso empresarial: DSpark recorta la latencia de function-calling un 57% de media en LFM2.5-2.6B, según las mediciones de Liquid AI. En un mercado donde cada llamada a una herramienta externa encadena varios round-trips al modelo, ese recorte se traduce en experiencias agenticas sensiblemente más fluidas.

Cómo funciona DSpark: tres componentes para romper el cuello de botella del decoding

El decode phase de un LLM está limitado por el ancho de banda de memoria: la mayor parte del tiempo se pierde moviendo pesos desde DRAM a SRAM, no haciendo cálculos. El speculative decoding clásico aborda esto con un draft model ligero que propone varios tokens y un modelo target que los verifica todos en un solo forward pass, repartiendo el coste de cargar pesos entre muchos tokens verificados.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

DSpark refina esa receta combinando tres bloques:

Backbone paralelo estilo DFlash: condicionado por las features de contexto del modelo target, produce los hidden states de todos los tokens draft en un único forward pass, en lugar de generarlos uno a uno.
Cabeza secuencial tipo Markov chain: modela la dependencia entre tokens vecinos para elevar la tasa de aceptación en posiciones tardías, donde los métodos puramente paralelos suelen fallar.
Verificador con schedule de confianza: predice la probabilidad de supervivencia de cada token y descarta los sufijos de baja confianza cuando verificarlos costaría más de lo que ahorrarían.

El resultado, según la documentación de Liquid AI en Hugging Face, son draft models de alrededor de 300 millones de parámetros (entre 295,7M y 327,7M, dependiendo del target), entrenados con 15 épocas sobre una mezcla que cubre SFT, chat, código y function-calling. Cada bloque de salida es de 9 tokens.

Resultados de rendimiento: del H100 al MacBook M4 Max

Las mediciones oficiales se hicieron con llama.cpp + Metal sobre un M4 Max MacBook Pro (FP16 GGUF, hasta 256 tokens de salida) y con SGLang sobre una sola H100 80 GB en BF16, con temperatura 0 y batch size 1, en cinco benchmarks.

LFM2.5-2.6B es el caso más llamativo: pasa de 61 tok/s a 139 tok/s de media en MacBook (2,27x) y de 323 a 864 tok/s en H100 (2,67x). En MATH500, el speedup en GPU llega a 3,06x (de 326 a 1000 tok/s) y en HumanEval a 2,56x (de 326 a 835 tok/s). Liquid AI destaca que estos 139 tok/s en MacBook superan el rango típico de modelos propietarios en la nube (alrededor de ~140 tok/s dependiendo del dataset), pero corriendo on-device.

LFM2.5-1.2B-Instruct muestra un speedup más volátil en GPU (de 1,66x en MT-Bench a 2,56x en MATH500, media 2,10x), pero estable en MacBook (media 2,54x, con picos de 2,87x en HumanEval).

LFM2.5-8B-A1B, el modelo MoE, presenta el caso más irregular: 2,54x de media en H100 pero solo 1,18x en MacBook (de 90 a 106 tok/s). Liquid AI lo atribuye a la implementación MoE actual en el backend Metal de llama.cpp: verificar k tokens activa más expertos y, por tanto, más tráfico de pesos que un solo paso de decode. Es una señal de que el stack on-device para arquitecturas MoE todavía tiene margen de optimización.

La propiedad clave del método: la salida es idéntica a la del modelo target en greedy decoding. Como el target verifica cada token propuesto, las métricas de accuracy (pass@1, exact match) no cambian. Esto importa en producción: no hay que ajustar prompts ni revalidar benchmarks.

El contexto: la nueva ola de speculative decoding en 2026

DSpark no llega solo. Forma parte de una camada de técnicas que durante 2026 han elevado el techo del speculative decoding clásico, históricamente limitado a 2–3x de speedup, según recogió TechTimes.

El antecedente más directo es DFlash, liberado el 24 de junio de 2026 por el z-lab de UC San Diego (investigadores Jian Chen, Yesheng Liang y Zhijian Liu). DFlash sustituye el draft autoregresivo por un modelo de block diffusion que propone un bloque entero en un solo forward pass, con lo que su latencia apenas crece al aumentar el tamaño del bloque. NVIDIA confirmó el día anterior, en tests sobre TensorRT-LLM con hardware Blackwell, que DFlash servía más de 15 veces la carga concurrente del decoding autoregresivo estándar al objetivo de interactividad de 500–600 tok/s por usuario. En single-stream sobre Qwen3-8B, DFlash promedió 4,86x de speedup lossless frente al 1,76x de EAGLE-3.

La diferencia con DSpark está en el equilibrio: DFlash apuesta por bloques más grandes con mayor profundidad de draft (5–8 capas), mientras que Liquid AI mantiene bloques de 9 tokens, draft models de 5 capas y suma una cabeza Markov para reforzar la coherencia entre tokens consecutivos. Ambos comparten la misma observación estructural: inyectar los hidden states del target en cada capa del draft (no solo en los embeddings de entrada) preserva la señal predictiva del modelo grande a través de toda la profundidad del draft.

El ecosistema Liquid AI que rodea a DSpark se completa con el LFM2.5-2.6B (texto, lanzado el 4 de agosto de 2026), los encoders de contexto largo para CPU (finales de julio de 2026) y el LFM2.5-VL-3B (visión, 12 de agosto de 2026, 3,1B parámetros, 228 tok/s en M5 Max), según Unite.AI. DSpark es, por tanto, el complemento de inferencia para una familia completa, no un experimento aislado.

Qué significa esto para tu startup

Si tu producto depende de un LLM self-hosted o de frontera, la pregunta operativa ya no es si conviene acelerar la inferencia, sino qué técnica elegir según tu workload:

Evalúa el coste por token en tu caso real. Un speedup medio de 2,5x en GPU o MacBook puede convertir un producto con margen negativo en uno rentable, sobre todo en flujos de function-calling donde DSpark recorta la latencia un 57%.
Apunta a on-device cuando el dato sea sensible. 139 tok/s de media en un MacBook Pro M4 Max con LFM2.5-2.6B abre la puerta a productos que procesan datos del cliente sin enviarlos a la nube, algo especialmente valioso en mercados con regulación estricta como la UE o en sectores como salud y legal.
Prioriza DSpark o DFlash según el hardware. DSpark tiene day-one support en llama.cpp (ideal para Apple Silicon y CPUs) y SGLang (ideal para GPUs NVIDIA). DFlash luce más fuerte sobre Blackwell con TensorRT-LLM en cargas de alta concurrencia.
No releas tu evaluación de calidad. Como la salida greedy es idéntica al target, no hay que revalidar prompts, ni reentrenar evaluadores, ni renegociar SLAs con clientes por cambios de comportamiento del modelo.

Los checkpoints están disponibles en Hugging Face en formatos Safetensors y GGUF para los tres targets (LFM2.5-2.6B-DSpark, LFM2.5-1.2B-Instruct-DSpark y LFM2.5-8B-A1B-DSpark). El PR de llama.cpp es el #27383 y el de SGLang el #31041, ambos ya mergeados upstream, lo que elimina la fricción de mantener un fork.