LFM2.5-DSpark: inferencia 3,2x más rápida en H100 y MacBook sin pérdida de calidad

139 tokens por segundo en MacBook, sin enviar datos a la nube
LFM2.5-2.6B con DSpark supera la velocidad típica de modelos propietarios en la nube, ejecutándose completamente en el dispositivo.
Mark

¿Por qué importa que DSpark mantenga la salida idéntica al modelo objetivo? Parece un detalle técnico.

Mimi

En producción, es la diferencia entre poder desplegar algo mañana y tener que revalidar todo tu sistema. Si cambias el comportamiento del modelo, aunque sea ligeramente, tienes que reentrenar evaluadores, ajustar prompts, renegociar SLAs. Con DSpark, la salida greedy es exactamente la misma, así que no hay fricción.

Mark

Entiendo. Pero ¿por qué la aceleración es tan diferente entre un MacBook y una H100? 2,27 veces en MacBook versus 2,67 veces en GPU.

Mimi

El cuello de botella es distinto. En GPU, el ancho de banda de memoria es enorme, así que el speculative decoding brilla. En MacBook, el ancho de banda es más limitado, pero Metal está optimizado para Apple Silicon. El modelo MoE es el que realmente sufre en MacBook porque verificar más tokens activa más expertos, y eso genera más tráfico de pesos que un solo paso de decodificación.

Mark

Entonces, ¿cuándo elegiría un founder DSpark sobre DFlash?

Mimi

DSpark tiene soporte nativo en llama.cpp desde el día uno, ideal para Apple Silicon y CPUs. DFlash brilla en Blackwell con TensorRT-LLM cuando tienes muchos usuarios concurrentes. Si tu producto es on-device o corre en MacBooks, DSpark. Si es un servicio de alta concurrencia en GPU NVIDIA nueva, DFlash.

Mark

¿Y el costo? ¿Cuánto ahorra realmente una startup con esa aceleración de 2,5 veces?

Mimi

Depende de tu volumen, pero si tu margen es negativo porque el costo por token es demasiado alto, una aceleración de 2,5 veces puede hacerlo rentable. Además, si reduces latencia un 57 por ciento en function-calling, tus usuarios ven un producto más rápido sin que tú hayas tocado el modelo base.

Mark

¿Hay algún riesgo en usar modelos de borrador de 300 millones de parámetros?

Mimi

No, porque el modelo objetivo verifica cada token. El borrador solo propone, el objetivo decide. Si el borrador falla, el objetivo lo corrige. La calidad está garantizada.

  • Aceleración de 3,18x en H100 y 2,87x en MacBook Pro M4 Max
  • Reducción de latencia en function-calling del 57 por ciento
  • Modelos de borrador de ~300 millones de parámetros, entrenados 15 épocas
  • Integración nativa en llama.cpp y SGLang desde el lanzamiento (20 de agosto de 2026)
  • Salida idéntica al modelo objetivo en decodificación greedy

DSpark logra speedups de 2,27x a 3,06x según el modelo y hardware, con reducción de latencia en function-calling del 57%, manteniendo idéntica calidad de salida. La técnica combina backbone paralelo tipo DFlash, cabeza Markov para coherencia entre tokens y verificador con schedule de confianza, usando draft models de ~300M parámetros.

Liquid AI lanzó LFM2.5-DSpark, modelos draft open-source que aceleran la inferencia hasta 3,18x en H100 y 2,87x en MacBook Pro M4 Max, reduciendo costos y latencia para productos con LLMs en producción.

El 20 de agosto de 2026, Liquid AI presentó LFM2.5-DSpark, una familia de modelos de borrador en código abierto diseñados para hacer lo que parecía cada vez más difícil: acelerar significativamente la velocidad de inferencia sin sacrificar la calidad de las respuestas. Los números son los que importan aquí. En una GPU H100, LFM2.5-DSpark logra acelerar la inferencia hasta 3,18 veces más rápida. En un MacBook Pro M4 Max, alcanza 2,87 veces. Para cualquier fundador que ejecuta modelos de lenguaje en producción, eso se traduce directamente en dos cosas que definen si un producto es viable o no: costo por token más bajo y latencia de respuesta más corta.

La compañía publicó los checkpoints en Hugging Face el mismo día, con integración lista para llama.cpp y SGLang desde el primer momento. Pero el dato que más importa en casos de uso empresarial es otro: DSpark reduce la latencia en function-calling un 57 por ciento de promedio en el modelo LFM2.5-2.6B. En un mundo donde cada llamada a una herramienta externa genera múltiples viajes de ida y vuelta al modelo, ese recorte significa experiencias de agentes notablemente más fluidas.

La arquitectura de DSpark resuelve un problema fundamental de los modelos de lenguaje: la fase de decodificación está limitada por el ancho de banda de memoria. La mayor parte del tiempo se gasta moviendo pesos desde DRAM a SRAM, no realizando cálculos. El speculative decoding clásico aborda esto con un modelo de borrador ligero que propone varios tokens y un modelo objetivo que los verifica todos en un único paso hacia adelante, distribuyendo el costo de cargar pesos entre muchos tokens verificados. DSpark refina esa receta combinando tres componentes: un backbone paralelo inspirado en DFlash que genera los estados ocultos de todos los tokens de borrador en un único paso, una cabeza secuencial tipo cadena de Markov que modela la dependencia entre tokens vecinos para mejorar la tasa de aceptación en posiciones tardías, y un verificador con un programa de confianza que 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 son modelos de borrador de alrededor de 300 millones de parámetros, entrenados durante 15 épocas en una mezcla que cubre ajuste supervisado, chat, código y function-calling, con cada bloque de salida conteniendo 9 tokens.

Los números de rendimiento varían según el hardware y el modelo. El LFM2.5-2.6B es el caso más impresionante: en un MacBook Pro M4 Max pasa de 61 tokens por segundo a 139 tokens por segundo de promedio, una aceleración de 2,27 veces. En una H100, salta de 323 a 864 tokens por segundo, una aceleración de 2,67 veces. En benchmarks específicos como MATH500, la aceleración en GPU llega a 3,06 veces, y en HumanEval a 2,56 veces. Liquid AI subraya que esos 139 tokens por segundo en MacBook superan el rango típico de modelos propietarios en la nube, pero ejecutándose completamente en el dispositivo. El modelo LFM2.5-1.2B-Instruct muestra una aceleración más variable en GPU, pero estable en MacBook. El modelo MoE LFM2.5-8B-A1B presenta el caso más irregular: 2,54 veces de aceleración de promedio en H100 pero solo 1,18 veces en MacBook, una limitación que Liquid AI atribuye a la implementación actual de MoE en el backend Metal de llama.cpp.

Lo que hace que DSpark sea especialmente valioso en producción es una propiedad fundamental: la salida es idéntica a la del modelo objetivo en decodificación greedy. Como el modelo objetivo verifica cada token propuesto, las métricas de precisión no cambian. No hay que ajustar prompts, no hay que revalidar benchmarks, no hay que renegociar acuerdos de nivel de servicio con clientes por cambios en el comportamiento del modelo.

DSpark no llega solo. Forma parte de una ola de técnicas que durante 2026 han elevado el techo del speculative decoding clásico, históricamente limitado a aceleraciones de 2 a 3 veces. El antecedente más directo es DFlash, liberado el 24 de junio de 2026 por investigadores de UC San Diego, que sustituye el borrador autoregresivo por un modelo de difusión de bloques que propone un bloque entero en un único paso hacia adelante. NVIDIA confirmó que DFlash servía más de 15 veces la carga concurrente del decodificación autoregresivo estándar. La diferencia entre DSpark y DFlash está en el equilibrio: DFlash apuesta por bloques más grandes con mayor profundidad de borrador, mientras que Liquid AI mantiene bloques de 9 tokens, modelos de borrador de 5 capas y suma una cabeza Markov para reforzar la coherencia entre tokens consecutivos.

Para una startup, esto significa que la pregunta operativa ya no es si conviene acelerar la inferencia, sino qué técnica elegir según la carga de trabajo. Una aceleración media de 2,5 veces en GPU o MacBook puede convertir un producto con margen negativo en uno rentable, especialmente en flujos de function-calling. Ejecutar modelos en el dispositivo 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 Unión Europea o en sectores como salud y legal. Los checkpoints están disponibles en Hugging Face en formatos Safetensors y GGUF, y los pull requests para llama.cpp y SGLang ya han sido integrados upstream, eliminando la fricción de mantener un fork personalizado.

Para un fundador que ejecuta 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.
— Liquid AI, sobre el impacto de DSpark
139 tokens por segundo en MacBook Pro M4 Max superan el rango típico de modelos propietarios en la nube, pero corriendo on-device.
— Liquid AI, sobre el rendimiento de LFM2.5-2.6B
Contáctanos FAQ