LFM2.5-24B-A2B-DSpark vs LFM2.5-8B-A1B-DSpark: el mismo archivo de 328M, dos apuestas muy diferentes

Descarga cualquiera de los dos archivos y obtienes 655.421.522 bytes. LFM2.5-24B-A2B-DSpark y LFM2.5-8B-A1B-DSpark son del mismo tamaño hasta el byte, comparten una columna vertebral de cinco capas, la misma cabeza Markov de rango 256, el mismo tamaño de bloque de 9 y el mismo vocabulario de 128.000 tokens — y ninguno puede responder a un solo prompt, porque ambos son borradores de decodificación especulativa que solo existen para adivinar tokens para un modelo objetivo. Lo que los separa no es su propia especificación. Es contra qué objetivo se entrenaron y cuánta evidencia existe de que el truco funcione con él. Uno tiene mediciones publicadas de GPU y MacBook de una publicación de lanzamiento; el otro tiene una tabla de GPU y ningún anuncio. Elegir entre ellos, por tanto, no es en absoluto una comparación de modelos: es una comparación de dos apuestas, y solo una de ellas se ha cobrado. Los fallos de IA y los incidentes de agentes documentados que hay detrás de lanzamientos como este se recopilan en el Archivo de Incidentes de IA de OrcaRouter donde cada entrada incluye sus propias fuentes, gravedad, grado de confianza e indicador de disputa.

Los archivos son gemelos; los trabajos no.

Lea los dos config.json en paralelo y casi todos los campos coinciden: tamaño oculto 2.048, tamaño intermedio 6.144, activación SiLU, 32 cabezas de atención sobre 8 cabezas KV con dimensión de cabeza 64, cinco capas de atención completa, tamaño de bloque 9, enable_confidence_head: true, una cabeza Markov convencional de rango 256. El número de parámetros es idéntico, por lo que los archivos safetensors coinciden byte a byte.

Tres campos difieren, y cada uno de ellos es fundamental.

• Tomas de capas objetivo — el borrador de 8B lee estados ocultos de las capas 2, 6, 10, 14 y 18 de un objetivo de 24 capas; el borrador de 24B lee las capas 2, 10, 18, 26 y 34 de un objetivo de 40 capas. Este es el campo que hace que los archivos no sean intercambiables.

• Posiciones máximas — 128.000 para el borrador de 8B frente a 131.072 para el de 24B, en línea con las ventanas de contexto de sus modelos objetivo.

• RoPE theta — 5.000.000 frente a 10.000.000, establecido por la codificación posicional del modelo objetivo en lugar de por cualquier aspecto del modelo borrador.

Ese último par es la evidencia más clara de que estos checkpoints se entrenaron por objetivo en lugar de escalarse desde una base común. El drafter no tiene una identidad independiente: su distribución de entrada es la que tengan los estados ocultos del objetivo, y estos cambian cuando cambian la arquitectura y el entrenamiento del objetivo. Apunta el drafter de 8B al modelo de 24B y solo los índices de capas ya lo vuelven un sinsentido; incluso si coincidieran, los logits que fue entrenado para predecir no coincidirían.

Qué está acelerando realmente cada uno

Los objetivos son más distintos de lo que sugiere la denominación «8B frente a 24B», y la diferencia va en sentido contrario para cualquiera que asuma que el modelo más grande es la carga más pesada en el dispositivo.

• Parámetros totales y activos: LFM2.5-8B-A1B tiene 8,3B en total con 1,5B activos por token; LFM2.5-24B-A2B tiene 24,0B en total con 2,45B activos.

• Profundidad — 24 capas (18 convoluciones con compuertas más 6 GQA) frente a 40 capas (30 convoluciones más 10 GQA).

• Contexto — 128.000 tokens frente a 131.072.

• Presupuesto de entrenamiento — 38T tokens frente a 36T, por lo que el modelo más pequeño no estaba subentrenado en relación con el más grande.

• Enrutamiento — el 8B usa un MoE de 64 expertos con enrutamiento top-4, igual que el 24B, por lo que ambos pagan la penalización de activación de expertos que perjudica la verificación.

Ambos son modelos de razonamiento que piensan antes de responder, lo cual importa aquí más que los recuentos de parámetros. La mayor debilidad de la decodificación especulativa es la salida larga y sin restricciones, y una cadena de pensamiento es exactamente eso. Las tablas del proveedor lo demuestran: las filas de mayor aceptación en ambas versiones son benchmarks de respuesta corta como MBPP y MT-Bench, y las más bajas son aquellas en las que el modelo tiene que inventar una ruta de solución larga.

La brecha de evidencia es la verdadera diferencia

Aquí es donde los dos lanzamientos dejan de ser comparables. El modelo borrador de 8B se lanzó el 20/08/2026 como parte del anuncio de toda la familia, con mediciones en dos máquinas muy diferentes: una única H100 de 80 GB en BF16 mediante SGLang, y un MacBook Pro M4 Max ejecutando pesos GGUF FP16 mediante llama.cpp con kernels Metal experimentales. Promedió 2,54× en la H100, con un pico de 3,18× en MATH-500, y solo 1,18× en el MacBook: de 90 a 106 tokens por segundo, en promedio en cinco conjuntos de datos.

El borrador de 24B tiene una sola fila de hardware: una única NVIDIA B300 con el objetivo FP8, caché KV BF16 y temperatura 0. Promedia 2,38× con concurrencia 1, 2,69× con concurrencia 32 y 1,71× con concurrencia 256 en ocho conjuntos de datos, con un pico de 3,28× en MBPP con concurrencia 32. No hay fila para Mac, ni fila para H100, ni publicación de anuncio que explique la omisión.

Para el modelo cuyo argumento de venta se centra por completo en agentes en el dispositivo —la publicación de lanzamiento de Liquid para el 24B abre con 184 tokens por segundo en un Apple M5 Max—, el dato de MacBook que falta es el vacío más determinante del anuncio. El resultado del 8B indica por qué podría ser pequeño: verificar un bloque de tokens activa más expertos que decodificar uno solo, así que un objetivo MoE mueve más peso por cada token aceptado. Y la aceptación por sí sola no es el predictor: el modelo de borrador del 8B promedió en realidad más tokens aceptados por paso que los que reporta la ficha del 24B (6.95 en cinco conjuntos de datos frente a 5.16 en ocho) y aun así solo alcanzó 1.18× en un MacBook. Ese es el punto que vale la pena conservar: en el 8B, una aceptación sólida no rescató el rendimiento en el dispositivo. Suponer que el 24B se comporta de manera distinta es una apuesta sin un número que la respalde.

Contrastando las dos tablas entre sí

Las ratios destacadas no son comparables entre sí y no deberían restarse unos de otros. Diferente GPU, diferente precisión objetivo, diferentes conjuntos de datos, diferentes barridos de concurrencia. Pero dos patrones sobreviven a la falta de correspondencia.

Primero, el techo es similar. La mejor celda H100 del 8B fue de 3,18× en MATH-500 con tamaño de lote 1; la mejor celda B300 del 24B es de 3,28× en MBPP con concurrencia 32. Los drafters de este diseño quedan en la misma banda de 1,5×–3,3× independientemente del objetivo al que sirvan, que es lo que cabría esperar cuando la arquitectura del drafter se mantiene fija y solo cambian los pesos.

En segundo lugar, y de forma más útil, el límite inferior es donde divergen los objetivos. La celda H100 más débil del 8B fue GSM8K con 1,29×; la celda B300 más débil del 24B con concurrencia 256 fue LiveCodeBench con 1,34× y AIME con 1,36×. Ninguna de las dos versiones produce un caso en el que la especulación sea gratuita, y ambas producen casos en los que apenas compensa la memoria.

También hay un cambio en la documentación entre las dos tarjetas que es fácil pasar por alto y que vale la pena señalar. El material de agosto decía que la salida bajo decodificación greedy es idéntica a la línea base "por construcción"; la tarjeta del 8B promete "exactamente las mismas salidas". La tarjeta del 24B, en cambio, advierte que las diferencias de punto flotante entre la verificación por lotes y la decodificación simple pueden producir texto distinto, incluso con muestreo greedy. La tarjeta posterior es la más cuidadosa, y si ejecutas diferencias de salida a nivel de byte en CI, conviene tratar ambas como potencialmente no idénticas en lugar de confiar en la promesa anterior.

Cuál es relevante para ti lo decide tu objetivo, no tu presupuesto.

No hay ningún escenario en el que un equipo elija uno de estos frente al otro por sus méritos. Se ejecuta el 24B porque se necesita la capacidad de un modelo 24B en una máquina que pueda alojarlo: 14,5 GB en Q4_K_M con GGUF, o una única B300 para la configuración de servicio FP8. Se ejecuta el 8B porque 8,3B de parámetros totales con 1,5B activos es lo que cabe en un dispositivo de borde o en un portátil, y el modelo borrador recupera parte de la velocidad de decodificación que se sacrifica al optar por uno más pequeño. El modelo borrador es un accesorio de esa primera decisión, y esta casi siempre se toma en función de la memoria y la calidad mucho antes de que la especulación aparezca en la conversación.

El único caso en el que la elección está realmente en juego es la evaluación. Si estás probando si DSpark merece adoptarse en tu stack, el emparejamiento de 8B es el experimento más económico: cabe en una H100, tiene cifras para Mac que puedes comparar con las de tu propio portátil, y su modo de fallo en el dispositivo ya lo ha documentado el proveedor. El emparejamiento de 24B es el experimento de producción más interesante y el menos documentado.

Para cualquiera de los dos, el número que decide el resultado es el contador de aceptación, no la tabla del proveedor. SGLang expone la aceptación de la decodificación especulativa por solicitud; llama.cpp informa draft_n y draft_n_accepted en los tiempos por respuesta. Ejecuta tus propios prompts durante diez minutos y divide. Si la aceptación se sitúa cerca de la media de la tarjeta, el borrador compensa; si se sitúa en el extremo bajo, estás pagando pasadas de verificación y deberías desacoplarlo —y esa conclusión se mantendrá en ambos checkpoints, porque el mecanismo es el mismo.

Ninguno de los dos checkpoints es un modelo al que puedas llamar.

Esta es la parte que atrapa a quienes se topan con estos nombres en un catálogo de modelos y asumen que son opciones de un menú. No son endpoints. Ninguno de los dos modelos redactores tiene un precio por millón de tokens, ninguno aparece en un listado de API y ninguna plataforma que sirva modelos enrutará jamás hacia ninguno de ellos, porque el emparejamiento correcto es una configuración del lado del servidor, no un parámetro de solicitud.

Liquid AI vende el propio modelo objetivo de 24B a $0,10 por millón de tokens de entrada, $0,05 en caché y $1,00 por millón de salida, y cualquier especulación que ejecute detrás de ese precio es invisible para el llamador. Esa es la forma habitual del mercado ahora: la ingeniería interesante ocurre dentro de la pila de servicio, y lo que llega a un desarrollador es una tarifa y una cifra de tokens por segundo. Donde las plataformas de enrutamiento se ganan su lugar es en la comparación por encima de esa capa: poner un candidato junto a los modelos a los que tiene que superar. OrcaRouter ofrece un único endpoint para más de 200 modelos con 0 % de margen sobre el precio de lista del proveedor, así que cuando cambia la tarifa de un proveedor, la tarifa que ves se actualiza el mismo día, y la conmutación por error evita que un modelo candidato se convierta en un punto único de fallo mientras lo evalúas. La familia LFM2.5 no está entre ellos hoy, así que un 8B o 24B autoalojado con su modelo de borrador adjunto sigue siendo un despliegue local; los modelos que vale la pena probar contra él — Qwen3.6-35B-A3B en el lado agéntico, Gemma 4 26B-A4B en el lado de la eficiencia — son los que enrutamos.

Lo que un año de lanzamientos de DSpark ha establecido

La familia ahora abarca cuatro objetivos de texto y un objetivo de visión, de 1.2B a 24B, todos compartiendo una misma receta de modelo borrador: alrededor de 300M de parámetros, cinco capas de atención, bloque 9, entrenado con los propios estados ocultos del objetivo. Esa consistencia es el hallazgo real. Liquid ha convertido la decodificación especulativa de un proyecto de investigación por modelo en un paso de fabricación: el mismo modelo borrador, reorientado y lanzado a los pocos días de cada nuevo modelo. Si vale la pena dar ese paso en tu hardware es una cuestión que depende de tu tráfico, y la respuesta varía según la carga de trabajo mucho más de lo que varía según cuál de estos dos archivos descargues.

Lo que la versión de 24B aporta a ese panorama no es una mejor proporción. Es la primera vez que un modelo borrador se lanza sin el informe que lo acompaña, y la primera vez que la propia ficha del proveedor te dice, en lenguaje sencillo, que puede que las salidas no sean idénticas bit a bit después de todo.