LFM2.5-8B-A1B-DSpark vs LFM2.5-2.6B-Base: la parte de velocidad vs la materia prima

Si ordenas la familia LFM2.5 según lo que cada checkpoint puede hacer por sí solo, LFM2.5-8B-A1B-DSpark y LFM2.5-2.6B-Base quedan en extremos opuestos de la línea — y ninguno de los dos extremos puede responder una pregunta. El primero es un modelo de borrador de 327,7 millones de parámetros que existe únicamente para hacer que el modelo de mezcla de expertos de borde de Liquid AI genere tokens más rápido. El segundo es un checkpoint preentrenado en bruto de 2,69 mil millones de parámetros que existe únicamente para ser afinado y convertirse en otra cosa. Ambos se lanzaron en agosto de 2026 bajo la LFM Open License v1.0 de Liquid, ambos están a una descarga de distancia en Hugging Face, y ambos son extremadamente fáciles de obtener por error — porque sus nombres los hacen sonar como dos versiones de la misma cosa.

Los nombres son la trampa. "DSpark" suena como el nuevo buque insignia chispeante de la familia, y "Base" suena como el sencillo valor predeterminado que realmente puedes ejecutar. Ninguna de las dos cosas es cierta. El checkpoint DSpark no puede responder nada por sí solo: solo propone tokens para que LFM2.5-8B-A1B los verifique. El Base tampoco puede responder nada, pero por la razón opuesta: es un modelo fundacional sin ajustar que predice texto, pero nunca fue post-entrenado para convertirse en un modelo de chat o agente. Esto no es una rivalidad; es un pipeline. Un checkpoint se encuentra justo al final de un stack de serving; el otro, justo al comienzo de una ejecución de entrenamiento.

Dos puntos de control que comparten un nombre, no un trabajo.

LFM2.5-8B-A1B-DSpark (lanzado el 20 de agosto de 2026) es un modelo de borrador de decodificación especulativa: una red de solo atención de cinco capas, un bloque de nueve tokens propuestos por paso y una cabeza de Markov sobre el vocabulario de 128 000 tokens del objetivo. Lo cargas junto al LFM2.5-8B-A1B — un MoE de 8.3B en total y ~1.5B activos que se publicó el 28 de mayo — el borrador predice los próximos tokens, y el objetivo verifica todo el bloque en una sola pasada hacia adelante, conservando lo que acepte. Debido a que el objetivo revisa cada token, la salida bajo decodificación voraz es idéntica a ejecutar el LFM2.5-8B-A1B solo: "sin pérdidas por construcción", según la frase de Liquid. El borrador es una pieza de velocidad, no un cerebro. Se lanzó junto con borradores hermanos para LFM2.5-1.2B-Instruct y LFM2.5-2.6B, cada uno en Safetensors y GGUF, con soporte desde el primer día en SGLang y llama.cpp.

LFM2.5-2.6B-Base (lanzado el 4 de agosto de 2026) es el otro extremo del pipeline: una base de 2.69B parámetros en una pila híbrida de 30 capas — 22 bloques de convolución corta de doble compuerta más 8 bloques de atención de consulta agrupada — preentrenada con aproximadamente 34 billones de tokens, con una fase de entrenamiento intermedio que extiende el contexto a 128K. No tiene plantilla de chat, ni ajuste por instrucciones, ni benchmarks publicados, y la propia ficha del modelo de Liquid lo recomienda solo para un ajuste fino extenso. Su único propósito es ser la materia prima que un pipeline de posentrenamiento de cuatro etapas — dos rondas de SFT, especialización del profesor, destilación on-policy, y luego aprendizaje por refuerzo agéntico — convierte en el agente de llamada a herramientas LFM2.5-2.6B. Misma familia, misma licencia, misma página de descarga. Trabajos completamente diferentes.

Lado a lado: siete dimensiones, dos trabajos

Como los dos puntos de control cumplen funciones distintas, la comparación honesta mantiene claros los roles de ambas partes:

Qué es — LFM2.5-8B-A1B-DSpark es un modelo borrador de decodificación especulativa de 0.3B; LFM2.5-2.6B-Base es un modelo base preentrenado en bruto de 2.69B.

• Con qué se ejecuta — el borrador DSpark se empareja con el MoE LFM2.5-8B-A1B (8.3B en total, ~1.5B activos por token); el Base funciona por sí solo, pero solo como predicción de texto sin ajustar.

• Uso independiente — DSpark no produce nada por sí mismo; solo acelera un objetivo. Base produce texto pero ningún comportamiento útil de producto: no sigue instrucciones, no llama herramientas, no tiene plantilla de chat.

• Calidad de salida — DSpark hereda la salida greedy exacta del objetivo, porque cada token propuesto se verifica; Base no tiene ningún benchmark publicado en ninguna tarea, por diseño.

• Velocidad — DSpark añade una media medida por el proveedor de 2,54× en una H100 (hasta 3,18× en MATH500) y 1,18× en una M4 Max a su objetivo, no reproducida; Base no tiene ninguna afirmación de velocidad de inferencia.

• Huella de memoria: DSpark añade aproximadamente 0,3 GB de pesos de borrador junto al objetivo; Base es el completo de 2,69B, ejecutable en menos de 2,5 GB, la base seria más pequeña de la familia.

• Formatos y disponibilidad — DSpark se distribuye en Safetensors y GGUF con soporte desde el primer día para SGLang y llama.cpp; Base se distribuye en Safetensors, GGUF, ONNX y MLX y funciona con Transformers, vLLM, SGLang, llama.cpp y MLX. Ninguno de los dos es servido por un proveedor de inferencia hoy en día — ambos son checkpoints autoalojados.

Los únicos números en este enfrentamiento provinieron de un solo laboratorio

Todo lo cuantitativo aquí es una medición de un solo proveedor, tomada el día en que se publicó el borrador y aún no reproducida de forma independiente: considérelo prometedor, no verificado. Liquid midió el LFM2.5-8B-A1B-DSpark con tamaño de lote 1, temperatura 0, en una sola H100 de 80 GB en BF16 con SGLang y en una MacBook Pro con M4 Max en FP16 GGUF con los kernels Metal experimentales de llama.cpp. En la H100, el par promedió 2.54× (418 → 1,074 tokens por segundo), con un mejor resultado individual de 3.18× en MATH500 (428 → 1,362 tok/s) y una aceptación promedio de aproximadamente 7 de cada 10 tokens propuestos. En la M4 Max, el mismo par promedió solo 1.18× (90 → 106 tok/s) — el caso límite en el dispositivo que la propia Liquid señaló, porque verificar un bloque activa más expertos en el backend Metal MoE actual y mueve más tráfico de pesos a través del bus de memoria.

El lado Base de este enfrentamiento no tiene números en absoluto, y esa ausencia es en sí misma la especificación. LFM2.5-2.6B-Base fue preentrenado, no postentrenado; nunca fue evaluado para chat, uso de herramientas o comportamiento de agente, porque nadie tenía la intención de que se usara de esa manera. Sus cifras relevantes son arquitectónicas: 2.69B de parámetros, contexto de 128K, un tokenizador de 16 idiomas, menos de 2.5GB para ejecutar. No se evalúa una base; se evalúa aquello en lo que se convierte mediante fine-tuning.

Hay una ironía de familia que conviene mencionar antes de que decidas nada. El borrador del que trata este artículo — el de la 8B-A1B — es precisamente el que menos gana en un portátil (1.18×), mientras que el borrador hermano de la familia 2.6B, que acelera el hermano post-entrenado de esta misma Base, promedia 2.27× en un M4 Max con un recorte del 57% en la latencia de llamada a funciones multi-herramienta. Si el dispositivo en cuestión es un teléfono o un portátil en lugar de una máquina con GPU, la vía 2.6B es donde reside la historia de la velocidad.

Entonces, ¿cuál descargas?

Nunca tienes que elegir directamente entre estos dos, porque no son alternativas — pero sí tienes que saber en qué trabajo estás:

Si sirves LFM2.5-8B-A1B en GPUs propias y quieres más tokens por segundo con el mismo silicio, LFM2.5-8B-A1B-DSpark es un complemento reversible: compila SGLang o llama.cpp con las integraciones de DSpark del 20 de agosto, especifica el draft en el comando de lanzamiento, mantén la decodificación greedy, y el tamaño de bloque se lee automáticamente de la configuración del draft. La ventaja es un rendimiento aproximadamente 2.5× mayor sin ningún cambio en las salidas; la desventaja son 0.3GB de pesos adicionales y una compilación lo bastante nueva como para incluir los PR. Quita las dos opciones especulativas y vuelves al modelo objetivo original.

Si quieres construir tu propio especialista — un modelo de dominio, un asistente de lenguaje personalizado, un ajuste fino con datos propietarios — LFM2.5-2.6B-Base es uno de los puntos de partida serios más baratos en el ecosistema de pesos abiertos: 2.6B, menos de 2.5GB, contexto de 128K, un tokenizador multilingüe. El checkpoint DSpark no puede ayudarte con eso en absoluto, porque no es una base.

Si en realidad quieres el agente en el dispositivo de Liquid — llamada de herramientas, tareas de varios pasos — entonces no quieres ninguna de estas dos. Quieres el LFM2.5-2.6B post-entrenado, y puedes decidir después si acoplarlo con su propio borrador. La Base es materia prima para quienes quieren entrenar; el borrador 8B-A1B es una pieza de velocidad para quienes ya implementan el MoE. El error es descargar la Base porque querías un agente más rápido, o el borrador porque querías una base para entrenar.

Dónde se conectan los dos — y dónde encaja un router

Ambos checkpoints son de tipo autoalojado. El borrador es un accesorio de la capa de servido que solo existe dentro de tu propia pila de SGLang o llama.cpp; la Base es un artefacto de entrenamiento. Ninguno aparece en ningún catálogo alojado, y ninguno tiene un precio de lista por token. Lo que eso significa en la práctica es que cualquiera de las dos vías termina situándose junto a los modelos alojados que ya invocas, y esa mezcla es exactamente la plomería que una capa de enrutamiento existe para consolidar.

En el lado del servicio, la economía del borrador es simple y real: 2.5× más tokens por segundo desde la misma GPU significa 2.5× menos tiempo y aproximadamente 2.5× menos GPUs para la misma carga de trabajo, sin cambio de calidad. Pero esa palanca solo existe si eres dueño de la inferencia. En el momento en que llamas al 8B-A1B a través de una API, el proveedor se queda con la aceleración — que es donde la comparación del lado de la API se convierte en la que importa: cuánto cobra un proveedor y si una reducción de precio te llega el mismo día en que se anuncia. Ese es el propósito de un router de paso directo: una API para más de 200 modelos, precios de lista del proveedor transmitidos con un margen del 0%, de modo que un recorte del vendedor se refleja inmediatamente en tu lado, y conmutación automática por error para que un pico de latencia de un solo proveedor no se convierta en tu latencia. También puedes poner tu propia pila LFM autoalojada al frente del mismo endpoint, que es como pruebas un modelo borrador completamente nuevo contra tráfico real sin apostar una ruta de producción en él.

LFM2.5-8B-A1B-DSpark y LFM2.5-2.6B-Base comparten un apellido y trabajos opuestos: uno es una pieza de velocidad atornillada al borde del MoE, el otro es el cerebro sin afinar del que crece el agente de 2.6B. Ninguno funciona por sí solo. Elige el borrador para acelerar un MoE que ya sirves en GPUs, elige la Base para ajustar un modelo base de 2.6B hasta convertirlo en algo propio, y evita ambos si lo que querías era un agente funcional — porque lo único que ambos checkpoints tienen en común es que ninguno, por sí mismo, hace nada que puedas usar.

Preguntas frecuentes

¿Puedo ejecutar LFM2.5-8B-A1B-DSpark por sí solo?

No. Es un modelo de borrador sin salida independiente: propone tokens candidatos que el modelo objetivo LFM2.5-8B-A1B luego verifica, por lo que solo existe dentro de un stack de servicio de decodificación especulativa construido sobre las integraciones del 20 de agosto de SGLang o llama.cpp. Descargarlo por sí solo no te da nada que puedas consultar.

¿Es LFM2.5-2.6B-Base el checkpoint que se ejecuta en el dispositivo como agente?

No tal cual. La Base es el modelo fundacional preentrenado en bruto, sin ajuste de instrucciones y sin plantilla de chat. El modelo que funciona como agente en el dispositivo de Liquid es el LFM2.5-2.6B post-entrenado, que se produce a partir de la Base mediante el pipeline de post-entrenamiento de cuatro etapas — y, si lo quieres más rápido, combinado con el borrador LFM2.5-2.6B-DSpark.