LFM2.5-DSpark: hasta 3.2x más rápida la inferencia y menos latencia en agentes

Resumen ejecutivo

Hugging Face publicó checkpoints DSpark para tres modelos de la familia LFM2.5: LFM2.5-1.2B-Instruct, LFM2.5-2.6B y LFM2.5-8B-A1B. La novedad clave es la integración de un «draft» o borrador especulativo: un modelo ligero que propone tokens candidatos y permite que el modelo objetivo verifique varios tokens en una sola pasada. El resultado es un aumento significativo de la velocidad de decodificación (hasta 3.18x en GPU y 2.87x en dispositivo) sin cambios en la salida final bajo decodificación greedy.

¿Por qué importa DSpark para despliegues reales?

La fase de decodificación en modelos grandes suele estar limitada por memoria: la mayor parte de la latencia proviene del movimiento de pesos entre DRAM y SRAM, no del cómputo puro. DSpark reduce esa sobrecarga al amortizar la carga de pesos verificando múltiples tokens propuestos por un borrador ligero en una sola pasada del modelo objetivo. Para equipos en América Latina, esto puede traducirse en:

• Mayor interactividad en dispositivos locales (laptops y equipos edge), reduciendo dependencia de la nube y costos recurrentes.
• Menor latencia en escenarios multi-herramienta y de llamadas a funciones, útil para asistentes locales, integración con sistemas internos y cumplimiento de políticas de datos.
• Capacidades de despliegue más accesibles en centros de datos locales o estaciones de trabajo con aceleradores, lo que ayuda a conservar soberanía y optimizar presupuesto.

¿Cómo funciona DSpark (en términos prácticos)?

DSpark combina tres componentes principales:

1. Un backbone paralelo al estilo DFlash, condicionado en las características de contexto del modelo objetivo, que produce los estados ocultos para todos los tokens del borrador en una sola pasada.
2. Una cabeza secuencial ligera, modelada como una cadena de Markov entre tokens vecinos, que introduce dependencia entre tokens y mejora la tasa de aceptación en posiciones tardías.
3. Un verificador con programación por confianza (confidence-scheduled verifier) que estima la probabilidad de supervivencia de cada token y poda sufijos de baja confianza cuando la verificación sería más costosa que el beneficio.

Bajo decodificación greedy, un token propuesto por el borrador se acepta solo si coincide con la distribución del modelo objetivo; si se rechaza, el token propio del modelo objetivo lo reemplaza, lo que garantiza paridad en la salida con respecto al baseline.

Entrenamiento y arquitectura de los drafts

Los borradores siguen la receta DSpark pero con una mezcla de datos más amplia que incluye SFT, chat, código y llamadas a funciones. Según el reporte, las primeras versiones son borradores simplificados de “atención-only” con 5 capas y un bloque de tamaño 9. Para cada borrador se entrenaron 15 épocas sobre el dataset completo y se seleccionó la época con mayor tasa de aceptación (no la de menor pérdida). Cada draft queda en el orden de ~300M de parámetros.

Desglose por componente (valores provistos por Hugging Face):

• Pila de decodificador (5 capas): 241.2M
• Proyección de estados ocultos: 21.0M
• Cabeza Markov: 33.6M – 65.5M según modelo
• Normas + cabeza de confianza: 27.5k
• Total aproximado: 295.7M a 327.7M según variante

Rendimiento: GPU y dispositivos locales

Los checkpoints DSpark para LFM2.5 incluyen soporte day-one para llama.cpp (incluyendo kernels experimentales Metal) y para SGLang (implementación DSpark). Las pruebas se realizaron con:

• On-device: llama.cpp + Metal en un MacBook Pro M4 Max con pesos FP16 GGUF, hasta 256 tokens de salida.
• GPU: SGLang en una H100 80 GB en BF16.

Resultados destacados:

• Mejora máxima en GPU: hasta 3.18x de throughput.
• Mejora máxima on-device: hasta 2.87x según modelo y dataset.
• Para LFM2.5-2.6B, la reducción de latencia en escenarios multi-herramienta fue en promedio del 57% (útil para agentes y llamadas a funciones).

Los benchmarks se midieron sobre cinco conjuntos (MATH500, HumanEval, MBPP, GSM8K y MT-Bench). Algunos ejemplos reportados:

• LFM2.5-2.6B (promedio): ~2.67x en H100 (323 → 864 tok/s) y ~2.27x en M4 Max (61 → 139 tok/s).
• LFM2.5-1.2B-Instruct (promedio): ~2.10x en H100 (656 → 1384 tok/s) y ~2.54x en M4 Max (138 → 350 tok/s).
• LFM2.5-8B-A1B (promedio): ~2.54x en H100 (418 → 1074 tok/s) y ~1.18x on-device (90 → 106 tok/s). La ganancia más pequeña on-device para el modelo MoE se atribuye a la implementación actual de MoE en el backend Metal de llama.cpp y al hecho de que verificar k tokens activa más expertos, aumentando el tráfico de pesos.

Importante: para LFM2.5-2.6B en MacBook M4 Max, la tasa de tokens por segundo llega a niveles de interactividad que superan el throughput de muchos modelos propietarios en la nube (referencia aproximada: ~140 tok/s, según dataset).

Implicaciones prácticas para equipos en América Latina

• Ahorro en costos de nube: mayor throughput on-device reduce llamadas a servidores externos y puede disminuir facturación en servicios de inferencia.
• Privacidad y cumplimiento: ejecutar modelos optimizados localmente facilita control de datos sensibles y requisitos regulatorios en la región.
• Herramientas para desarrolladores: el soporte day-one en llama.cpp y SGLang facilita la adopción por equipos que ya usan esas herramientas para despliegues edge y en servidores locales.

Cómo probar LFM2.5-DSpark (pasos básicos)

Hugging Face indica que para usar los drafts con SGLang se requiere una compilación de SGLang con soporte DSpark (PR #31041). Un ejemplo de lanzamiento con el borrador adjunto es el siguiente comando proporcionado por los autores:

python -m sglang.launch_server
—model-path LiquidAI/LFM2.5-2.6B
—speculative-algorithm DSPARK
—speculative-draft-model-path LiquidAI/LFM2.5-2.6B-DSpark
—speculative-draft-attention-backend flashinfer
—disable-radix-cache —mem-fract

Sigan la documentación oficial de llama.cpp y SGLang para detalles de compilación y flags específicos.

Conclusión

Los checkpoints DSpark para LFM2.5 ofrecen una forma práctica de acelerar la inferencia sin sacrificar la salida bajo decodificación greedy. Para organizaciones y equipos técnicos en América Latina representan una oportunidad interesante: mayor interactividad en dispositivos locales, potencial reducción de costos y mejor control sobre la información. La disponibilidad inmediata en herramientas populares como llama.cpp y SGLang facilita la experimentación y la adopción en proyectos de producción.

Si su equipo evalúa despliegues edge o agentes que realizan múltiples llamadas a herramientas, LFM2.5-DSpark merece una prueba controlada con sus cargas de trabajo reales para medir los beneficios en su contexto operativo.