LFM2.5-24B-A2B-DSpark vs LFM2.5-24B-A2B: ¿Deberías adjuntar realmente el drafter?

Aquí está la decisión en una frase: LFM2.5-24B-A2B-DSpark es un archivo de 327,7 M de parámetros que se coloca junto a LFM2.5-24B-A2B para que el modelo de 24B produzca el mismo tipo de salida más rápido. No es una alternativa al modelo ni algo que se elija en su lugar. La única cuestión real que plantean los dos nombres es de ingeniería —si se conecta el modelo borrador a tu despliegue o se deja fuera—, y la respuesta depende menos del aumento de velocidad anunciado por Liquid AI que de dos cifras que nadie publicita: en cuántos tokens se acepta el borrador en tu tráfico, y cuánta concurrencia ya tienes en marcha. Los fallos de IA documentados y los incidentes de agentes 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, su gravedad, su grado de confianza y su indicador de disputa.

Liquid AI no ha publicado una entrada de lanzamiento para el drafter. El repositorio se hizo público el 2026-10-19 con los pesos, un CSV de benchmark y flags de lanzamiento de SGLang, mientras que la propia model card del modelo objetivo todavía etiqueta al drafter como «próximamente» y la página de documentación sobre decodificación especulativa de Liquid solo enumera los objetivos 1.2B, 2.6B, 8B y VL-3B. Por lo tanto, esto es una comparación de un artefacto ya lanzado frente a un modelo ya lanzado, escrita a partir del repositorio y no de una nota de prensa, lo que significa que todas las cifras de rendimiento siguientes son reportadas por el proveedor y ninguna ha sido reproducida de forma independiente.

Qué cambia realmente el redactor, y qué no.

Vale la pena dedicarle treinta segundos al mecanismo porque determina todo lo demás. La decodificación de un token está limitada por la memoria: la GPU pasa la mayor parte del tiempo transmitiendo pesos a la SRAM, no haciendo aritmética. La decodificación especulativa se aprovecha de eso haciendo que un modelo pequeño adivine los siguientes varios tokens a la vez y luego haciendo que el modelo real compruebe toda la conjetura en una sola pasada hacia adelante. Si la conjetura era buena, produjiste nueve tokens por aproximadamente el coste de uno. Si era mala, el modelo objetivo se queda con su propio token y pagaste un poco más.

Lo que cambia: los tokens por segundo y la forma de la utilización de tu GPU. Lo que no cambia: los pesos del modelo, su ventana de contexto, su comportamiento a la hora de llamar herramientas ni sus precios allí donde se vende. LFM2.5-24B-A2B mantiene 24.0B de parámetros totales con 2.45B activos por token, 40 capas repartidas entre convoluciones cortas con compuerta y atención de consultas agrupadas, 64 expertos por bloque con enrutamiento top-4, un contexto de 131,072 tokens y un vocabulario de 128,000 tokens. El drafter añade cinco capas de atención, una cabeza Markov de rango 256 y una cabeza de confianza, y reutiliza los embeddings y la cabeza LM del modelo objetivo en lugar de llevar los suyos propios.

Una advertencia cambió de sitio entre las dos versiones y merece una línea. En agosto, el análisis de DSpark de Liquid decía que la secuencia emitida es «idéntica al greedy de referencia por construcción». La ficha del drafter de 24B, en cambio, dice que las diferencias de coma flotante entre la verificación por lotes y la decodificación simple «pueden producir texto diferente, incluso con muestreo greedy». Ambas afirmaciones son defendibles —la primera es cierta en aritmética exacta—, pero si tu arnés de evaluación compara las salidas byte a byte, cuenta con que lo notará.

El lado de los costos del libro mayor

El borrador no es gratis. Ocupa 655 MB en BF16 en la GPU (o un GGUF F16 de 664 MB en CPU), reside en el mismo pool de memoria que el objetivo y cada paso que propone cuesta una pasada forward de verificación sobre un bloque de tokens en lugar de sobre un solo token. En un objetivo MoE, esa última parte es más costosa de lo que parece: verificar nueve tokens activa más expertos que decodificar uno, así que los bytes movidos por token verificado aumentan, no disminuyen. Liquid citó exactamente esto como la razón por la que su borrador de 8B solo rindió 1,18× en un M4 Max pese a una alta aceptación.

Frente a eso, el ahorro es lo bastante grande como para medirse en horas de GPU. Usando las propias cifras del B300 del proveedor procedentes de benchmarks/b300-fp8.csv, y sin hacer nada más que dividir mil millones de tokens de salida entre el rendimiento observado:

• MATH-500, concurrencia 1 — 324 tok/s por sí solo (857 horas de GPU por cada mil millones de tokens) frente a 853 tok/s con el modelo borrador (326 horas de GPU). Una reducción de 2,63× en el tiempo de cómputo.

• MATH-500, concurrencia 256 — 15.423 tok/s por sí solo (18,0 GPU-horas) frente a 27.579 tok/s con el drafter (10,1 GPU-horas). Una reducción de 1,79×.

• GSM8K, concurrencia 256 — 4.491 tok/s en solitario (61,9 horas-GPU) frente a 9.660 tok/s con el drafter (28,8 horas-GPU). Una reducción de 2,15×.

• LiveCodeBench, concurrencia 256 — 18.812 tok/s por sí solo (14.8 horas de GPU) frente a 25.231 tok/s con el drafter (11.0 horas de GPU). Solo una reducción de 1.34×, la celda más débil de la tabla.

Esos son cocientes de rendimiento convertidos en tiempo, no en dinero, porque el dinero depende de lo que pagues por GPU-hora y este artículo no va a inventarse una tarifa. Pero el orden se mantiene a cualquier tarifa: acoplar el modelo borrador vale de dos a tres horas por cada diez para el tráfico de razonamiento y generación de código con baja concurrencia, y vale aproximadamente un tercio de eso con alta concurrencia. Si tu despliegue de 24B es un agente de un solo usuario en una estación de trabajo, el caso es sólido. Si es un endpoint de lotes saturado, el caso es real pero mucho más débil de lo que sugiere el titular de 2,4×.

Donde el redactor justifica su utilidad, en términos de carga de trabajo

La dispersión entre los ocho conjuntos de datos en la tabla del proveedor no es ruido; se corresponde con tipos de prompt, y esa correspondencia es lo más útil del lanzamiento. La aceptación osciló entre 6,70 tokens por paso en MBPP y 4,02 en LiveCodeBench. Los conjuntos de datos que obtuvieron puntuaciones altas son aquellos en los que la salida del modelo está limitada por el prompt: funciones cortas al estilo de pruebas unitarias, aritmética con una ruta verificable, respuestas de opción múltiple. Los que obtuvieron puntuaciones bajas son aquellos en los que el modelo tiene que inventar una solución larga y sin restricciones: problemas de programación competitiva y matemáticas al estilo AIME.

Esa es la intuición que conviene llevar a tu propia evaluación. Un modelo de razonamiento de 24B vendido para trabajo agéntico consume la mayor parte de sus tokens de salida dentro de una cadena de razonamiento, que se parece más a LiveCodeBench que a MBPP. Un modelo usado para extracción estructurada, clasificación con un esquema o un formato fijo de llamada a herramientas se parece mucho más a las filas de alta aceptación. Si tu carga de trabajo es la primera, espera quedar más cerca del extremo inferior de 1,34× que del superior de 3,28×. Nadie ha publicado la aceptación por carga de trabajo para este modelo borrador, y los ocho conjuntos de datos de la ficha del modelo son lo más parecido a una guía.

En contraposición: el 24B es un modelo exclusivamente de razonamiento. Liquid dice que siempre piensa antes de responder; la plantilla de chat inserta automáticamente una etiqueta <think>. Esa es la peor configuración posible para la especulación, porque el tramo de razonamiento es exactamente la parte larga y de baja aceptación. El modelo borrador seguirá ayudando; ayudará más en la respuesta final y menos en la parte que más tarda.

Cómo saberlo, en tu propio hardware, en una tarde

No tienes que confiar en nada de lo anterior. Ambas rutas de inferencia exponen el contador de aceptación, que es el único número que decide si el drafter se amortiza con tu tráfico.

En SGLang, inicia el modelo objetivo con el drafter adjunto, tamaño de bloque 9 y diez tokens de borrador, luego lee las métricas de decodificación especulativa que el servidor informa por solicitud. La tasa de aceptación en la tabla del proveedor se sitúa entre 0,33 y 0,65 según el conjunto de datos; una ejecución que quede muy por debajo de la fila correspondiente significa que el drafter está adivinando mal y estás pagando por la verificación sin obtener la aceleración. En llama.cpp con el sidecar GGUF F16, los tiempos por respuesta llevan draft_n y draft_n_accepted directamente. Divide uno por el otro.

Dos detalles operativos te costarán una hora si los pasas por alto. El servidor SGLang necesita una compilación que incluya la ruta DSpark de LFM2-MoE fusionada el 31 de agosto de 2026; en cualquier versión anterior, la arquitectura del modelo borrador simplemente es desconocida. Y el tamaño de bloque es una propiedad del checkpoint, no un parámetro libre: llama.cpp limita --spec-draft-n-max al valor de 9 de los metadatos del sidecar, así que pedir 12 no aporta nada.

La pregunta que esta comparación no puede responder

Hay una versión de «¿debo adjuntar el drafter?» que no tiene nada que ver con las GPU, y es la que realmente afrontan la mayoría de los equipos. Si llamas a LFM2.5-24B-A2B mediante una API alojada, la decisión del drafter no es tuya. La pila de servicio o adjunta un decodificador especulativo o no lo hace; ves una cifra de tokens por segundo y un precio, y ambos se decidieron aguas arriba. La propia Console de Liquid lista el 24B a $0.10 por millón de tokens de entrada, $0.05 de entrada en caché y $1.00 por millón de salida — una tarifa publicada que ya refleja cualquier ruta de decodificación que ejecuten, y que puede cambiar sin previo aviso.

Ese es el punto de unión donde el enrutamiento ayuda en lugar de complicar. Una llamada a un servicio alojado y un despliegue autoalojado no son tanto planes que compiten como dos ajustes del mismo control de costos: el autoalojamiento más el modelo borrador minimiza el costo por token si tu volumen mantiene ocupada la GPU, y un endpoint alojado minimiza el trabajo de obtener una respuesta. OrcaRouter está diseñado para lo segundo: una sola clave para más de 200 modelos con 0% de recargo sobre el precio de lista del proveedor, de modo que un cambio de precio del proveedor se refleja en nuestro lado el mismo día, con conmutación por error automática si un proveedor se degrada y un DSL de enrutamiento para dividir el tráfico en lugar de fijar en el código un único backend. Actualmente no servimos la familia LFM2.5, así que para este modelo en concreto el lado alojado significa la propia API de Liquid o tus propias GPU; la comparación que vale la pena hacer es con los modelos que sí ofrecemos, como Qwen3.6-35B-A3B —el modelo que Liquid usa como referencia en tareas agénticas— o Gemma 4 26B-A4B.

Entonces: ¿adjuntarlo o no?

Adjúntalo si estás sirviendo LFM2.5-24B-A2B tú mismo con una concurrencia moderada, especialmente para salidas estructuradas o con forma de extracción, y si tienes 655 MB de margen junto al objetivo. Las cifras del proveedor indican que ahí reducirás aproximadamente a la mitad o a un tercio tu tiempo de decodificación, y la desventaja está acotada: un mal drafter cuesta una pasada de verificación, no una respuesta incorrecta.

Déjalo desactivado si tu endpoint ya está saturado en los cientos, si tu salida es razonamiento extenso de forma libre, o si necesitas cifras de Apple silicon antes de comprometerte: la tarjeta no tiene ninguna, y el análogo más cercano de la misma familia se lanzó a 1,18× en un MacBook. Y déjalo desactivado, obviamente, si no vas a ejecutar el modelo en absoluto: un drafter es una optimización para un despliegue, y no hay nada que optimizar hasta que exista el despliegue.

Lo que zanjaría el resto es una publicación del proveedor y una medición en Mac. Ninguna de las dos existe a fecha de 2026-10-21, lo cual es un estado extraño para un lanzamiento cuyos pesos ya se pueden descargar —y, para cualquiera dispuesto a ejecutar el contador de aceptación por su cuenta, una oportunidad inusualmente barata de ser el primer número independiente en la tabla.