LiquidAI LFM2.5-24B-A2B: razonamiento con 2B activos en el dispositivo

Qué anunció Liquid AI el 13 de octubre de 2026

El 13 de octubre de 2026, Liquid AI anunció el LFM2.5-24B-A2B, modelo de razonamiento MoE con 24B de parámetros totales, 2B activos por token, contexto de 131K tokens y pesos abiertos en HuggingFace. El posicionamiento del anuncio es explícito: razonamiento y agentes corriendo en el dispositivo. La verificación del blog, en 2026-10-16, confirma los pesos en el repo LiquidAI/LFM2.5-24B-A2B.

Los dos números cargan la historia. Un modelo denso de 24B activa la totalidad de los parámetros en cada token generado. Un MoE de 24B con 2B activos paga compute por una fracción del conjunto, y es esa fracción la que el anuncio señala como el mecanismo que permite correr razonamiento en hardware propio. La arquitectura de parámetros activos, por sí sola, no es novedad. Lo que el evento de 2026-10-13 hace es combinarla con dos propiedades que, juntas, cambian una decisión de compra: capacidad de razonamiento, que suele exigir modelos grandes, y pesos que cualquiera descarga. Un modelo pequeño cerca del líder ya era lectura conocida aquí; la diferencia es que ahora la eficiencia vino acompañada de razonamiento y de pesos públicos, en el mismo artefacto.

Por qué importa: la ruta de agentes gana una tercera opción

Cuando el razonamiento de un agente corre con 2B activos en hardware propio, la política de ruta deja de ser una elección entre endpoints de pago y pasa a tener una tercera opción: correr local cuando la tarea cabe, rutear a la nube cuando no cabe. La eficiencia de parámetros activos es decisión de ruta, no curiosidad de benchmark. Es la tesis de esta pieza.

La tercera opción es el evento.

La semana ya había mostrado la frontera hospedada: Claude Haiku 4.5 bajó el piso de costo de inferencia en un endpoint. El LFM2.5-24B-A2B ataca la ecuación por el otro lado. En vez de abaratar el token hospedado, elimina el token hospedado en las tareas en que el hardware local da cuenta. Para quien corre agentes en volumen, esa es la variable que mueve el break-even: cada tarea que migra a ejecución local deja de aparecer en la factura por millón de tokens, y lo que sigue en la nube pasa a necesitar justificación.

Arquitectura e innovaciones técnicas: 24B totales, 2B activos por token

El LFM2.5-24B-A2B es un MoE: de los 24B de parámetros totales, solo 2B están activos en cada token, según el anuncio de Liquid AI de 2026-10-13. El costo de compute por token acompaña los parámetros activos, mientras que la capacidad del modelo acompaña los totales. El contexto declarado es de 131K tokens. Los pesos están abiertos en HuggingFace.

La diferencia con un modelo denso vale un párrafo, porque es la que decide la cuenta de ejecución. En un modelo denso, todo parámetro participa del procesamiento de cada token, así que el costo por token escala con el tamaño completo del modelo. En un MoE, un mecanismo interno selecciona, por token, la fracción de parámetros que entra en operación. El resultado práctico es un modelo con la capacidad asociada a 24B y el costo de ejecución asociado a 2B, con una salvedad que el anuncio no elimina: la huella de memoria sigue los parámetros totales. Guardar 24B de pesos en disco y memoria es condición para activar 2B de ellos.

Ficha técnica, según el anuncio y el repo:

La descripción anterior sigue el anuncio de Liquid AI y la ficha del repo de pesos. Este blog no ejecutó el modelo para este texto, y cada línea de la tabla es rastreable a la fuente primaria datada.

Benchmarks y desempeño real: lo que se reporta y lo que se valida

El anuncio de 2026-10-13 posiciona el LFM2.5-24B-A2B para razonamiento y ejecución de agentes. Este texto no reproduce marcador ninguno: la verificación del blog, en 2026-10-16, no abrió evaluación independiente, y un número reportado por el propio laboratorio no es validación. Donde la fuente primaria reporta desempeño, la lectura es "Liquid AI reporta", con fecha, nunca un valor convertido en verdad de producción.

El marcador de lanzamiento no decide la ruta.

La regla de lectura vale para todo lanzamiento y vale doble para los modelos de pesos abiertos, porque el ciclo de validación es más rápido. El número que el laboratorio reporta mide el modelo en las condiciones que el laboratorio eligió. El número que decide ruta mide el modelo en su tráfico, con sus prompts, en su hardware. Entre los dos existe una distancia que solo una prueba paralela cierra, y el método para cerrarla es el mismo que decidió el costo de ruta entre modelos hospedados. Al momento de la publicación, el blog no confirma score, latencia ni throughput para este modelo, y no cita valores que circulen sin fecha ni metodología.

Economía de inferencia y costo por token: activos versus totales

La economía de este lanzamiento no está en el precio por millón de tokens, que Liquid AI publicó en el anuncio de 2026-10-13 (US$ 0,10 por 1M de tokens de entrada, US$ 0,05 con entrada en caché, y US$ 1,00 por 1M de tokens de salida, en Liquid Console). Está en la razón entre parámetros activos y totales: el compute pagado por token escala con los 2B activos, no con los 24B totales. Esa es la razón económica real del evento, y opera antes de cualquier negociación de precio con proveedor.

La ejecución local con pesos abiertos es otro régimen. Cambia costo variable por costo fijo. El endpoint hospedado cobra por token facturado, sin capital adelantado y sin hardware que gestionar. El hardware propio cobra por adelantado, en adquisición y operación, y después cobra poco por token adicional. El punto de equilibrio entre los dos depende del volumen y del perfil de las tareas, y la decisión por tarea es el método que la guía de reducción de costos de inferencia ya describe en detalle.

Integración y enrutamiento en producción: los pesos abiertos entran en la malla de ruta

Los pesos abiertos cambian la integración antes de cambiar la ejecución: el modelo pasa a ser un artefacto versionado bajo gestión propia, con gobernanza y auditoría de versión, y no un endpoint del proveedor. La ruta gana un destino nuevo, el hardware propio, con política escrita como cualquier otro. La selección entre pesos abiertos y modelos hospedados es una decisión de gobernanza que antecede cualquier deploy.

Donde la ejecución local sustituye la llamada hospedada: tareas de agente que caben en 131K de contexto y en la capacidad del modelo, con frecuencia suficiente para amortizar el hardware. Donde no sustituye: picos de demanda por encima del hardware, tareas que exigen capacidad mayor de la que el modelo entrega y operaciones sin hardware disponible. La malla de ruta que trata los dos destinos como complementarios, cada uno con criterio de entrada, es la que sobrevive al próximo lanzamiento.

El Router no corre en el dispositivo. No es eso lo que aporta a esta decisión. Su papel es el plano de control que decide qué corre dónde: prueba paralela del mismo prompt en destinos locales y hospedados con tráfico real, reglas de ruta por clave, techo de gasto por clave, agente y proyecto, failover y fallback configurables cuando el destino local no sostiene la tarea, y rastro de auditoría de cada llamada. El cambio de modelo ocurre sin reintegración, algo que importa en un momento en que la malla de destinos acaba de ganar una categoría nueva. El pilar del Router en escala cubre esa arquitectura en detalle.

Preguntas frecuentes sobre el LFM2.5-24B-A2B

Bloque marcado para FAQPage, con las preguntas que llegan antes de la decisión de compra.

¿Qué cambia un modelo con 2B de parámetros activos? El compute por token. En un modelo denso de 24B, todo parámetro trabaja en cada token generado. En un MoE con 2B activos, solo una fracción entra en operación por token, así que el costo de ejecución acompaña la fracción activa mientras la capacidad acompaña el conjunto total, según el anuncio de Liquid AI. La contrapartida es la huella de memoria, que sigue los 24B totales.

¿El LFM2.5-24B-A2B corre agentes en el dispositivo? Ese es el posicionamiento del anuncio, no una medida verificada por este blog. Liquid AI presenta el modelo para razonamiento y agentes corriendo en el dispositivo, con contexto de 131K tokens y pesos descargables en HuggingFace. Que la ejecución sostenga su agente en su hardware es una pregunta que solo una prueba con su tráfico responde.

¿Los pesos abiertos prescinden del endpoint de pago? No de forma absoluta, y esta pieza no lo sugiere. Los pesos abiertos crean la opción de ejecución local para las tareas que caben en el modelo y en el hardware. Los picos de demanda, las tareas por encima de la capacidad del modelo y las operaciones sin hardware disponible siguen dependiendo de un endpoint hospedado. El cambio real es que la nube deja de ser el default y pasa a ser un destino justificado por capacidad.

¿Cómo decidir qué corre local y qué va a la nube? Por tarea, con dato del tráfico real: perfil de cada agente, tamaño de contexto, frecuencia y tolerancia a fallas. Una tarea frecuente que cabe en el modelo y en el hardware es candidata a ejecución local. Una tarea esporádica o por encima de la capacidad sigue hospedada. La prueba paralela en el Router compara los dos destinos con el mismo prompt antes de que la regla de ruta se escriba.

¿El Nexforce Router ejecuta el modelo en el dispositivo? No. El Router es el plano de control: decide qué corre dónde, aplica reglas de ruta por clave, techo de gasto, failover, fallback y auditoría por llamada. La ejecución local ocurre en su hardware; la decisión de cuándo usarla es la que pasa por el Router, con observabilidad central sobre los dos destinos.

Referencias y Lectura Complementar

• Liquid AI, anuncio del LFM2.5-24B-A2B, 13 de octubre de 2026: liquid.ai/blog/lfm2-5-24b-a2b
• Pesos abiertos en HuggingFace, repo LiquidAI/LFM2.5-24B-A2B: huggingface.co/LiquidAI/LFM2.5-24B-A2B
• Anthropic lanza Claude Haiku 4.5: el nuevo piso de costo de inferencia
• Qwen 3.8 Max: el costo que decide la ruta
• Cómo reducir costos de inferencia de LLM
• Modelo pequeño cerca del líder: qué cambia en el enrutamiento
• Open weights o modelos hospedados: selección y gobernanza
• Nexforce Router: middleware de modelos en escala

Siguiente paso

Para quien opera agentes en producción, el paso siguiente no es descargar pesos por impulso. Es medir qué fracción del tráfico actual cabe en el perfil de 2B activos y 131K de contexto, y convertir esa fracción en una regla de ruta probada antes de volverse default. El camino cabe en una lista:

1. Mapee las tareas de agente por perfil: contexto promedio, frecuencia y tolerancia a fallas.
2. Arme una prueba paralela en Nexforce Router con el mismo prompt yendo al destino local y al endpoint hospedado, con tráfico real.
3. Escriba la regla de ruta por clave para la fracción que la prueba valide, con techo de gasto por clave, agente y proyecto.
4. Configure el fallback del destino local hacia el hospedado, para el caso en que el hardware no sostenga la tarea.
5. Audite cada llamada desde el inicio. La gobernanza de pesos abiertos es suya, no del proveedor.

El LFM2.5-24B-A2B no termina la era del endpoint de pago. Obliga a cada token a justificar por qué subió.