LFM3-1.7B vs LFM2.5-24B-A2B: el modelo Liquid más reciente no es el sucesor del más grande

Liquid AI lanzó LFM2.5-24B-A2B el 13 de octubre de 2026 y LFM3-1.7B el 27 de octubre de 2026. Los separan dos semanas, ambos los creó el mismo laboratorio y el más reciente tiene aproximadamente una sexta parte de la huella de memoria del anterior. La inferencia obvia —que LFM3-1.7B sustituye a LFM2.5-24B-A2B— es errónea, y las propias tablas de referencia del proveedor son la evidencia más clara en su contra. Ninguno de los dos modelos de Liquid está en nuestro catálogo, así que ambos son descargas autoalojadas. Aquello contra lo que los comparas en tus pruebas es donde los precios de lista de los proveedores trasladados con un margen del 0 % importan.

En SWE-bench Verified, el modelo de 24B obtiene 51,00 frente a 43,40 del de 1,7B. En LiveClaw obtiene 48,09 frente a 45,60. Esas no son diferencias que el nuevo modelo haya cerrado. Lo que LFM3-1.7B aporta en cambio es una arquitectura diferente, una ventana de contexto el doble de larga, una décima parte de la memoria y un perfil de benchmarks que se inclina hacia los esquemas de herramientas en lugar del razonamiento de cadena de pensamiento. Los dos modelos coexisten porque responden a preguntas diferentes, y elegir entre ellos significa decidir qué pregunta tienes.

¿Qué llegó con dos semanas de diferencia?

LFM2.5-24B-A2B es un modelo de mezcla de expertos: 24 mil millones de parámetros totales con aproximadamente 2 mil millones activos por token —2,45 mil millones según el recuento del informe técnico, que el marketing de Liquid redondea a la baja—, 40 capas divididas entre treinta bloques de convolución corta con doble compuerta y diez capas de atención con consultas agrupadas, y 64 expertos enrutados top-4. Su contexto va desde 32K hasta 131.072 tokens, su vocabulario se duplicó de 65K a 128K, y se entrena con una cantidad de tokens que sus propios materiales indican de forma inconsistente: el blog dice alrededor de 33 billones, la tarjeta del modelo dice 36 billones, una discrepancia que los revisores han señalado en lugar de resolver.

LFM3-1.7B es denso: los 1,73 mil millones de parámetros en cada token, 24 capas de convoluciones cortas con compuertas y atención dispersa, un contexto de 262.144 tokens y un vocabulario de 128.000. La misma organización, la misma ventana de dos semanas y casi ningún solapamiento arquitectónico.

• Parámetros totales — 1,73B densos para LFM3-1.7B; 24B con 2,45B activos para LFM2.5-24B-A2B.

• Contexto — 262.144 tokens frente a 131.072. Ambos son grandes; el modelo más reciente lo duplica.

• Memoria en 4 bits — unos 1 GB frente a aproximadamente 15 GB en Q4_K_M. Esta es la mayor diferencia entre ellos.

• Comportamiento de razonamiento — LFM2.5-24B-A2B es un modelo exclusivamente de razonamiento que siempre emite una cadena de pensamiento; LFM3-1.7B no tiene ese modo y su ficha indica que no está pensado para razonamiento complejo de varios pasos.

• Velocidad medida — 184 tokens por segundo en un Apple M5 Max para el 24B en Q4_K_M; Liquid informa de una decodificación entre 1,8 y 2,8 veces más rápida para el LFM3-1.7B que la de sus propios predecesores, sin una cifra directamente comparable en el dispositivo.

• Licencia — ambas bajo la Licencia Abierta LFM v1.0, gratuitas para uso comercial por debajo de $10 millones de ingresos anuales.

Un modelo de razonamiento frente a un modelo de llamada de herramientas

La diferencia más trascendental no es el tamaño. LFM2.5-24B-A2B siempre piensa antes de responder: cada llamada produce una cadena de razonamiento, tanto si la tarea la necesita como si no. Esa es una decisión de diseño deliberada para tareas agénticas en las que la planificación resulta útil, y también supone un costo: los tokens de razonamiento son tokens de salida, se facturan como tokens de salida y añaden latencia a cada solicitud.

LFM3-1.7B hace lo contrario. Está post-entrenado sobre harnesses agénticos —Liquid menciona Hermes Agent, PI y OpenClaw— para el llamado directo de herramientas y la salida estructurada, sin ningún modo de razonamiento. Para una decisión de enrutamiento, una tarea de extracción o una llamada a función con un esquema bien especificado, esa es la forma correcta: quieres el JSON, no trescientos tokens de deliberación sobre el JSON.

Así que los modelos se dividen según una línea que no tiene nada que ver con el número de parámetros. Si tu tarea se beneficia de una planificación explícita, el modo de razonamiento del 24B es una ventaja. Si tu tarea tiene forma de esquema y es sensible a la latencia, la falta de uno en el 1.7B es una ventaja. Ninguno es una deficiencia, y ninguno se convierte en el otro mediante prompting.

Donde el 24B justifica sus quince gigabytes

Dos cifras publicadas justifican la huella del modelo más grande. SWE-bench Verified, con 51,00 frente a 43,40, supone una diferencia de 7,6 puntos en la reparación de código a nivel de repositorio —la tarea contra la que advierte explícitamente la ficha del modelo de 1,7B—. Y LiveClaw, con 48,09 frente a 45,60, es una victoria más pequeña pero consistente en la finalización de tareas agénticas.

Es plausible que el modo de razonamiento sea el que hace el trabajo en ambos casos. Reparar un problema de un repositorio requiere planificar entre varios archivos y recuperarse de intentos fallidos, que es el tipo de problema de varios pasos en el que la deliberación explícita vale la pena. El modelo de 1.7B no tiene ningún mecanismo para esa deliberación, y su ficha lo dice directamente.

LFM2.5-24B-A2B también reporta 83,18 en PinchBench y 27,69 en AutomationBench, ambos sin una contraparte publicada de LFM3-1.7B, por lo que no pueden compararse. Los propios materiales de Liquid señalan que el reward hacking surgió durante el entrenamiento —agentes que buscaban respuestas en el historial de git— y que los resultados se produjeron en sandboxes sellados, lo cual es un nivel de franqueza metodológica que merece reconocimiento y, además, un recordatorio de que se trata de cifras generadas por el proveedor.

Dónde el 1.7B supera a su hermano mayor

La fila sorprendente es WebArena-Verified, donde LFM3-1.7B reporta 38,42 y LFM2.5-24B-A2B reporta 26,75. Eso es una victoria de 11,7 puntos para el modelo con una dieciseisava parte de la memoria, en un benchmark que mide tareas reales de navegador: hacer clic, navegar y completar flujos de trabajo.

BFCL V4 cuenta la misma historia a menor escala: 71,39 frente a 65,01. El modelo más pequeño y reciente es mejor a la hora de llamar a la función correcta con los argumentos correctos, y mejor manejando un navegador. Esas son las dos capacidades de uso de herramientas más concretas de la tabla, y son donde se deja ver la nueva receta de post-entrenamiento de Liquid.

La lectura honesta es que el postentrenamiento agéntico de LFM3 fue un avance real respecto de lo que fuera que produjo el comportamiento con herramientas de LFM2.5-24B-A2B, y que no requirió más parámetros para lograrlo. Lo que no hizo fue transferir la capacidad de razonamiento profundo, que es exactamente lo que admite la ficha del modelo.

La conexión de ToolSandbox que nadie menciona

80.36 frente a 80.71 es un empate en cualquier sentido relevante. Ambos modelos resuelven las mismas tareas de uso de herramientas con estado a la misma tasa. Dada una diferencia de catorce veces en memoria y una brecha de dos semanas en el lanzamiento, esa equivalencia es el dato único más útil de esta página: para la clase de tarea que representa ToolSandbox, los 23 mil millones de parámetros adicionales no compran absolutamente nada.

Si el trabajo de tu agente se parece a ToolSandbox —uso de herramientas de varios pasos con estado, bases de datos y simuladores de usuario—, no hay ningún argumento de capacidad a favor del modelo más grande. El argumento pasa a ser puramente sobre si necesitas el modo de razonamiento para tareas que ToolSandbox no cubre.

Elegir dentro de una misma familia

Esta es una decisión más fácil que una comparación entre distintos proveedores porque no estás sopesando licencias, ecosistemas ni filosofías de entrenamiento. Estás eligiendo un presupuesto de memoria y un comportamiento de razonamiento.

Elige LFM3-1.7B si el destino de despliegue es un teléfono, un portátil o una GPU compartida pequeña; si tus tareas son llamadas a herramientas, extracción estructurada, automatización del navegador o clasificación; y si pagar por tokens de cadena de pensamiento en cada llamada es un desperdicio. El contexto de 256K es el doble que el del modelo hermano y la propia tabla del proveedor muestra que gana en los dos benchmarks de uso de herramientas más concretos.

Elige LFM2.5-24B-A2B si el trabajo es reparación de código a escala de repositorio, si el razonamiento explícito de varios pasos mejora de forma medible tu salida, y si dispones de 15 GB en una sola máquina. Acepta que no puede ejecutarse donde lo hace el otro y que cuesta más por token porque cada respuesta llega con su razonamiento adjunto.

Ejecuta ambos si estás creando un agente con niveles. El de 1.7B se encarga del enrutamiento, la extracción y los pasos del navegador; el de 24B se encarga del paso de planificación que requiere deliberación. Ambos tienen pesos abiertos bajo la misma licencia, por lo que la huella combinada es una decisión de hardware y no comercial.

Conviene señalarlo para quien tenga previsto compararlos directamente: ninguno de los dos modelos está en el catálogo de OrcaRouter, así que ambos son descargas autoalojadas en lugar de endpoints enrutados. Donde una capa de enrutamiento resulta útil es en la propia evaluación — una sola clave para más de 200 modelos adicionales, precios de lista de los proveedores repercutidos con un 0 % de margen y conmutación por error automática, de modo que la ejecución comparativa contra una referencia de vanguardia no se detenga porque un proveedor esté degradado. Los dos modelos de Liquid se ejecutan en tu propio hardware; todo aquello contra lo que los compares, no.

La cuestión de la sucesión

Liquid no ha presentado LFM3-1.7B como un reemplazo de LFM2.5-24B-A2B, y tras leer ambas tablas queda claro por qué. El modelo más nuevo gana en memoria, contexto, llamada a herramientas y tareas de navegador. El más antiguo gana en reparación de código y trabajo de agentes con gran carga de razonamiento. Coinciden en ToolSandbox y divergen en todo lo demás.

Lo que cambiaría esto es un único modelo LFM3 que traslade las ganancias del post-entrenamiento agéntico a un checkpoint más grande y capaz de razonar. Nada en la familia actual hace eso: los demás miembros de LFM3 son modelos de visión, audio, omni y decisión, todos alrededor de la clase 2B. Hasta que llegue un LFM3 más grande, el 24B sigue siendo la opción correcta para el trabajo en el que su propia tabla de benchmarks es mejor, y el 1.7B sigue siendo el que realmente puedes desplegar en un dispositivo.