LFM2.5-24B-A2B-DSpark ya está disponible en Hugging Face — Liquid AI simplemente no lo ha anunciado

La ficha del modelo más grande de Liquid AI todavía dice que su modelo borrador de decodificación especulativa llegará próximamente. El modelo borrador no llegará. LFM2.5-24B-A2B-DSpark tiene un repositorio público desde el 2026-10-19, un checkpoint BF16 de 655 MB, una tabla de benchmarks completa, un sidecar GGUF publicado la noche siguiente y flags de lanzamiento para SGLang escritas en su ficha. Lo que no tiene es un anuncio. LFM2.5-24B-A2B, el modelo de mezcla de expertos de 24B al que está destinado a acelerar, recibió una entrada de blog, un lanzamiento con fecha, una lista de precios y un enlace al playground el 2026-10-13. Su modelo borrador recibió un repositorio y una ficha de modelo, y la propia página de documentación de Liquid AI sobre decodificación especulativa sigue indicando que solo son compatibles los objetivos 1.2B, 2.6B, 8B y VL-3B. Los fallos de IA y los incidentes de agentes documentados que hay detrás de lanzamientos como este se recopilan en el OrcaRouter AI Incident Archive, donde cada entrada incluye sus propias fuentes, gravedad, grado de confianza e indicador de disputa.

Esa brecha es la historia aquí, y merece la pena ser preciso sobre lo que significa y lo que no. Un repositorio cuyos pesos son abiertos, cuyos benchmarks son reproducibles a partir de un CSV que está junto al modelo y cuya ruta de inferencia ya está fusionada upstream es un lanzamiento real, no una filtración. Pero el proveedor no ha confirmado nada de ello en prosa, ningún tercero lo ha medido, y las cifras de la tarjeta son las cifras del mismo equipo, medidas en el mismo hardware que ellos eligieron. Este artículo separa las dos cosas: lo que establece el repositorio y lo que sigue siendo una afirmación.

¿Qué hay realmente en el repositorio?

El checkpoint es lo suficientemente pequeño como para que el listado de archivos en sí mismo sea informativo. Todo el conjunto es un único model.safetensors de 655.421.522 bytes —327,7 M de parámetros en BF16—, además de una configuración, una licencia y un directorio de benchmarks. Nada más. No hay tokenizador, ni matriz de embeddings, ni cabeza LM, porque la arquitectura reutiliza los tres del modelo objetivo en el momento de la carga. Ese es el diseño: el modelo borrador solo tiene que saber cómo adivinar el siguiente bloque de tokens en el vocabulario del modelo objetivo, no cómo representar el mundo.

La configuración confirma la forma que describía el artículo de DSpark de agosto. Cinco capas de atención completa con tamaño oculto de 2,048 y tamaño intermedio de 6,144 con SiLU/SwiGLU; atención con consultas agrupadas con 32 cabezas y 8 cabezas KV con dimensión de cabeza 64; una cabeza Markov de rango 256 y una cabeza de confianza separada; tamaño de bloque 9; vocabulario de 128,000; y un embedding de posición máximo de 131,072, que coincide exactamente con la ventana de contexto del objetivo. El único campo que es específico de este drafter es target_layer_ids: [2, 10, 18, 26, 34] frente a num_target_layers: 40 — las cinco capas del modelo de 24B cuyos estados ocultos el drafter lee como contexto. Esos índices son la razón por la que un drafter entrenado para un modelo LFM2.5 no puede simplemente apuntarse a otro.

La licencia es lfm1.0, la misma licencia personalizada que el resto de la familia, algo que conviene tener en cuenta para quien tenga previsto redistribuir un artefacto empaquetado que incluya tanto el target como el drafter en lugar de usarlo internamente.

La tabla de referencia, leída como una tabla de proveedor

La ficha publica el rendimiento de ocho conjuntos de datos con concurrencia 1, 32 y 256, en una única NVIDIA B300 con el objetivo FP8, una caché KV BF16 y temperatura 0. Cada cifra que aparece a continuación es de Liquid AI y no se ha reproducido fuera de la empresa; las filas sin procesar están en benchmarks/b300-fp8.csv del repositorio si quieres comprobar tú mismo la aritmética.

• Media aritmética de los ocho conjuntos de datos: 2,38× con concurrencia 1, 2,69× con concurrencia 32, 1,71× con concurrencia 256.

• Mejor celda individual — MBPP con concurrencia 32, 3,28×, con MATH-500 muy cerca con 3,04×.

• Peor celda individual — LiveCodeBench con concurrencia 256, 1,34×, y AIME con 256, 1,36×.

• Tokens aceptados por paso — 5,16 en promedio, frente a un techo de 10 establecido por el tamaño del bloque más el token de bonificación del objetivo.

• Mayor aceptación — MBPP con 6,70 tokens por paso; menor — LiveCodeBench con 4,02.

Dos cosas de esa tabla son más interesantes que el titular. La primera es que la aceleración media es mayor con concurrencia 32 que con concurrencia 1 —2,69× frente a 2,38×—, lo que es lo contrario del relato habitual de la decodificación especulativa, en el que el procesamiento por lotes se come el beneficio. La segunda es que se desploma a 256. Con 256 solicitudes concurrentes, el modelo objetivo por sí solo ya genera alrededor de 15.000 tokens por segundo en esa GPU para MATH-500, y la contribución del modelo borrador cae a 1,79×. Un equipo de inferencia que solo leyera «2,4×» dimensionaría mal un clúster; el número que importa para un endpoint por lotes es el 1,71×, y aun así es un número de B300 con un perfil de concurrencia que la mayoría de los despliegues no igualará.

La frase que cambió desde agosto

Cuando Liquid AI lanzó los borradores DSpark para los objetivos de 1.2B, 2.6B y 8B-A1B el 2026-08-20, su entrada de blog hizo una afirmación contundente: como el objetivo verifica cada token propuesto y sustituye los rechazos por su propia elección, «la secuencia emitida es, por tanto, idéntica a la greedy de referencia por construcción». La tarjeta de modelo del borrador de 8B repite la esencia, prometiendo «exactamente las mismas salidas».

La ficha del drafter de 24B no dice eso. Dice que el objetivo verifica cada token propuesto y, luego: "Las diferencias de punto flotante entre la verificación por lotes y la decodificación simple pueden producir texto diferente, incluso con muestreo codicioso". Añade que las mediciones evalúan el rendimiento, no la precisión en la tarea.

Esta es una frase más cuidadosa, y es la correcta. La verificación por lotes no realiza las mismas operaciones de punto flotante en el mismo orden que la decodificación secuencial, así que la identidad bit a bit es una suposición que se cumple en aritmética exacta y no siempre en hardware real. El hecho de que la tarjeta más nueva lo diga mientras que la más antigua no lo hacía es o bien una corrección de la documentación o bien un descubrimiento durante el entrenamiento de este modelo de borrador; el repositorio no te dice cuál, y Liquid no ha publicado una explicación. Lo que significa en la práctica es limitado pero real: si tu suite de pruebas de regresión compara la salida del modelo byte por byte, añadir este modelo de borrador puede hacerla fallar, y eso es una propiedad de la aritmética, no un error en el borrador.

Por qué el redactor llegó seis días después de su propio modelo

Vale la pena exponer la cronología, porque explica el silencio mejor que cualquier especulación sobre la estrategia.

• 2026-08-20 — Liquid publica la familia DSpark: borradores para LFM2.5-1.2B-Instruct, LFM2.5-2.6B y LFM2.5-8B-A1B. Todavía no existe ningún objetivo de 24B.

• 2026-08-31 — SGLang fusiona el PR #31041, que añade soporte de decodificación especulativa DSpark para LFM2 y LFM2-MoE. La ruta MoE que necesita el 24B llega aquí, un mes y medio antes que el modelo al que servirá.

• 2026-10-13 — LFM2.5-24B-A2B se lanza con una publicación de blog y un precio. Ese mismo día, SGLang fusiona el PR #43939, que permite al servidor reutilizar directamente la configuración de LFM2-MoE de Hugging Face.

• 2026-10-19 — aparece el repositorio LFM2.5-24B-A2B-DSpark, con pesos y benchmarks.

• 2026-10-20 — llega el sidecar GGUF: un único archivo F16 de 664 MB para llama.cpp.

• 2026-10-21 — la tarjeta del modelo objetivo incorpora una fila de drafter. Sigue mostrando Próximamente.

Al leer esa secuencia, la explicación más probable es la aburrida. La infraestructura se publicó antes que el artefacto; el artefacto se publicó cuando terminó el entrenamiento; el anuncio es una tarea de marketing que aún no ha ocurrido. Nada en el repositorio sugiere un lanzamiento deliberadamente silencioso: la tarjeta está completa, los benchmarks están documentados hasta el nivel del protocolo, y las invocaciones de SGLang y llama.cpp están escritas por completo. Silencioso aquí significa no anunciado, no oculto.

Lo que todavía no se puede saber

El límite honesto de este texto es una lista breve, y cada elemento es una laguna real en lugar de una formalidad.

Ninguna medición independiente. No existe ninguna entrada en Artificial Analysis, ninguna ejecución de aceptación por parte de terceros, ninguna reproducción de la tabla de rendimiento. A fecha de 2026-10-21, el repositorio mostraba siete descargas y un «me gusta». Todas las aceleraciones de este artículo son del proveedor, en la GPU elegida por el proveedor, con la precisión objetivo elegida por el proveedor.

Sin anuncio, así que no hay encuadre. No sabemos si Liquid pretende que esto sea una recomendación para producción del 24B o un artefacto de investigación. El tono de la ficha —indicadores de lanzamiento completos, una tabla de familias, un enlace de contacto— sugiere lo primero, pero eso es una inferencia.

Sin precio, porque no puede haberlo. Un drafter no es un modelo servido. No tiene tarifa por millón de tokens y nunca aparecerá en un catálogo de modelos como un endpoint invocable. Su coste es los 655 MB de VRAM o de memoria unificada que ocupa junto al modelo objetivo, más el cómputo adicional de verificar un bloque en lugar de un token.

Sin cifras de Apple silicon. Esta es la mayor laguna, y la sección siguiente explica por qué importa más que las demás.

El número de Mac que falta es la omisión interesante.

El modelo de 24B se vende como un modelo en el dispositivo. La publicación de lanzamiento de Liquid abre con 184 tokens por segundo en un Apple M5 Max y lo presenta como diseñado para agentes rápidos y privados en el dispositivo. La ficha del modelo de borrador, en cambio, solo informa cifras del B300. Para el modelo de borrador de 8B en agosto, Liquid publicó resultados tanto de H100 como de M4 Max y fue transparente sobre la diferencia entre ellos: una aceleración media de 2,54× en una H100 se convirtió en 1,18× en un MacBook. Su razón declarada era mecánica: verificar k tokens activa más expertos que un solo paso de decodificación, por lo que un objetivo MoE paga más tráfico de pesos por token verificado, y el backend Metal de llama.cpp lo empeoró.

LFM2.5-24B-A2B también es una mezcla de expertos: 64 expertos por bloque con enrutamiento top-4. Se aplica el mismo mecanismo, y el 24B es un modelo más grande con un conjunto de expertos más grande que recorrer. Eso no demuestra que la aceleración en el dispositivo sea pequeña —el modelo borrador se entrenó específicamente para este objetivo, y la aceptación es mucho mejor que la del 8B al principio—, pero sí significa que el único número que necesita un usuario de portátil es el único número que la ficha no contiene. Considera no verificada cualquier suposición de que la proporción del B300 se traslade a un Mac.

Ejecutarlo, y la única opción que te morderá

En GPU, la receta publicada es SGLang con el target en FP8 y el drafter adjunto, tamaño de bloque 9 y diez tokens de draft. La versión instalada de SGLang debe ser lo bastante reciente como para incluir la ruta DSpark de LFM2-MoE del PR #31041 y la reutilización de configuración del PR #43939; en una compilación más antigua, el servidor no reconocerá en absoluto la arquitectura del drafter. Ten en cuenta que las cifras del benchmark asumen el target en FP8: el target en BF16 se comportará de forma distinta, y no necesariamente mejor, porque el drafter se entrenó con una distribución específica de logits del target.

En CPU y Apple silicon la ruta es llama.cpp con el sidecar GGUF F16. El sidecar lee su tamaño de bloque desde sus propios metadatos y limita --spec-draft-n-max a ese valor, así que fijar la longitud de borrador en 12 no te da 12. Los tiempos por respuesta exponen draft_n y draft_n_accepted, que es el campo que hay que vigilar en tu propia carga de trabajo: si la aceptación en tu tráfico está muy por debajo de la media de 5.16 de la tarjeta, el drafter te está costando una pasada hacia adelante y aportando poco, y lo honesto es desacoplarlo.

Qué significa esto si vas a elegir un modelo esta semana

Para la mayoría de los equipos, la consecuencia práctica es pequeña, porque el modelo borrador cambia la velocidad, no la capacidad. LFM2.5-24B-A2B es lo que responde a los prompts; el modelo borrador solo cambia cuántas de esas respuestas obtienes por segundo. Si el 24B no estaba en tu lista de candidatos la semana pasada, una versión más rápida no lo va a poner ahí.

Si estaba en tu lista de candidatos, el drafter mejora el argumento a favor del autohospedaje y no aporta nada al caso de la API. Esa distinción merece decirse con claridad: un checkpoint de decodificación especulativa es invisible para cualquiera que llame a un endpoint alojado, porque es la pila de servicio la que decide si lo incorpora. Lo que sí puedes comparar en igualdad de condiciones es el propio modelo frente a las alternativas a las que, de otro modo, dirigirías tu tráfico — y si lo estás evaluando frente a algo como Qwen3.6-35B-A3B, el modelo con el que Liquid hace benchmarks en cinco de ocho tareas agénticas, OrcaRouter ofrece ese objetivo de comparación tras una sola clave a 0% de recargo sobre el precio de lista del proveedor, con failover automático entre proveedores. Hoy no servimos la familia LFM2.5, así que el propio 24B tiene que venir de la API del proveedor o de tus propias GPU; lo que ofrecemos es el otro lado de la comparación sin un segundo contrato.

¿Qué cambiaría esta imagen?

Tres cosas, por orden de cuánto harían avanzar la historia. Una entrada de blog de Liquid aclararía el encuadre: si se trata de una combinación recomendada para producción o de un lanzamiento de investigación. Una medición publicada en Mac resolvería la afirmación que importa al público para el que se creó el 24B. Y una ejecución de aceptación independiente con tráfico real, en lugar de ocho conjuntos de datos de referencia a temperatura 0, te diría si los 5,16 tokens por paso sobreviven al contacto con los prompts desordenados, largos y con llamadas a herramientas para los que realmente se vende este modelo.

Hasta entonces, el repositorio es público, los pesos se pueden descargar, el CSV está justo ahí, y la propia model card del proveedor es el último lugar donde deberías buscar noticias al respecto. Es un estado inusual para un lanzamiento — pero es real, y el artefacto no se vuelve menos real porque nadie escribiera la entrada del blog.