Liquid AI acelera los agentes locales con los modelos DSpark para LFM2.5

La inferencia local se ve obstaculizada con mayor frecuencia por el ancho de banda de la memoria durante la transferencia de peso que por la potencia de cálculo en bruto. La decodificación especulativa sortea este problema con un modelo preliminar que propone tokens, mientras que el modelo objetivo los verifica en una sola pasada. Liquid AI lanza ahora los modelos DSpark para LFM2.5-1.2B-Instruct, LFM2.5-2.6B y LFM2.5-8B-A1B.

El borrador paralelo poda las ramas muertas a tiempo

DSpark combina la generación paralela de estados ocultos con una ligera cabeza secuencial basada en una cadena de Markov. Un verificador estima la posibilidad de que los tokens propuestos sobrevivan a la comprobación y poda los sufijos de bloques de baja confianza cuando su verificación costaría más de lo que ahorra. Los modelos preliminares tienen aproximadamente 300 millones de parámetros. Con la decodificación codiciosa, la secuencia resultante sigue siendo idéntica a la salida del propio modelo objetivo.

M4 Max reduce la latencia de las herramientas en un 57 por ciento

El impacto práctico es significativo para los agentes que se ejecutan directamente en el equipo del usuario. DSpark redujo la latencia para LFM2.5-2.6B en escenarios con múltiples herramientas en un promedio del 57 por ciento. En una MacBook Pro con M4 Max, el rendimiento promedio aumentó de 61 a 139 tokens por segundo. El modelo 1.2B alcanzó un promedio de 350 tokens por segundo.

llama.cpp y SGLang tienen soporte desde el lanzamiento

Los modelos DSpark se lanzaron con soporte en llama.cpp y SGLang, por lo que no es necesario esperar a su integración en los motores de inferencia más populares. Los puntos de control están disponibles en formatos Safetensors y GGUF. La ejecución en cualquiera de los motores requiere una compilación con el soporte DSpark pertinente.

Metal todavía limita la variante de mezcla de expertos

Los resultados no son uniformes en todas las arquitecturas. LFM2.5-8B-A1B promedió sólo una aceleración del dieciocho por ciento en el M4 Max a pesar de su mayor tasa de aceptación de borradores. Liquid AI atribuye esa brecha a la actual implementación de MoE en el backend Metal para llama.cpp y al tráfico adicional de pesos causado por la activación de más expertos. Por lo tanto, las mejoras adicionales también dependen de la optimización del entorno de ejecución.

El veredicto de Lilith

Cuando un modelo genera más de 130 tokens por segundo directamente en su computadora portátil, el argumento de que los agentes serios requieren una API en la nube comienza a desmoronarse. Esta es la infraestructura para el uso de herramientas locales sin espera.