LBS-27B vs LFM2.5 24B A2B: la cuestión de los parámetros activos

El número más importante en LFM2.5 24B A2B no es 24. Es 2,45: los miles de millones de parámetros que el modelo realmente lee para cada token. Por eso Liquid AI puede afirmar 184 tokens de salida por segundo en un Apple M5 Max mientras el modelo alberga 24 mil millones de parámetros de conocimiento, y por eso la empresa lo posiciona como un agente en el dispositivo en lugar de un caballo de batalla de centro de datos. El mismo número falta en LBS-27B, y su ausencia es la razón por la que esta comparación aún no puede resolverse: sin un recuento de parámetros activos, no hay forma de situar el modelo de inclusionAI en la curva de eficiencia que define LFM2.5.

LFM2.5 24B A2B se puede descargar desde el 13 de octubre de 2026, con una ficha del modelo, dieciséis filas de benchmarks y una licencia que la mayoría de las empresas tendrá que leer con atención. LBS-27B es un repositorio creado el 26 de octubre de 2026 que contiene un archivo .gitattributes estándar y un README de 28 bytes que declara Apache-2.0. Sin pesos, sin configuración, sin ficha, sin anuncio. Por lo tanto, lo que sigue es una comparación entre una apuesta de eficiencia completamente especificada y un nombre que aún no ha dicho qué tipo de modelo es.

Para qué optimiza Liquid

LFM2.5 24B A2B es un decodificador de mezcla de expertos con 64 expertos y enrutamiento top-4, 40 capas, un tamaño oculto de 2.048 y un vocabulario de 128.000 tokens. El recuento activo es de 2.450 millones. Acepta 131.072 tokens de contexto, frente a los 32K de la generación anterior, y se preentrenó con 33 billones de tokens, aproximadamente el doble de los 17 billones utilizados para LFM2.

El cambio de vocabulario es un detalle que vale la pena tener en cuenta. Pasar de 65K a 128K tokens es costoso —implica volver a entrenar las capas de embedding y de salida— y la razón habitual para hacerlo es el texto no latino. La tarjeta enumera dieciséis idiomas: inglés, árabe, chino, francés, alemán, italiano, japonés, coreano, portugués, español, vietnamita, tailandés, indonesio, hindi, ruso y polaco. Un vocabulario más grande abarata esas lenguas por palabra y suele mejorar su rendimiento en la parte final.

También es un modelo exclusivamente de razonamiento. El pipeline de post-entrenamiento de Liquid ejecuta ajuste fino supervisado, especialización del profesor, destilación no agéntica y agéntica, y luego aprendizaje por refuerzo agéntico dentro de harnesses como OpenClaw, Hermes Agent, Pi y OpenCode. El modelo produce una cadena de pensamiento antes de responder; no hay un modo separado "rápido, sin pensamiento" documentado en la ficha.

Un perfil de benchmark deliberadamente lleno de picos

Las cifras propias de Liquid, no reproducidas por nosotros, describen un modelo que es excelente en lo que hace un agente en el dispositivo y deficiente en lo que necesita un trabajador del conocimiento. Esa forma no es un accidente; es el diseño.

• Seguimiento de instrucciones — IFEval 96.75, IFBench 74.69, Multi-IF 84.38. Este es el grupo más fuerte de la ficha y el que más importa para un agente que debe obedecer un esquema de herramientas.

• Uso de herramientas — ToolSandbox 80.71, PinchBench 83.18, BFCL v4 65.01, AutomationBench 27.69. Bueno, pero desigual entre los arneses.

• Navegación agéntica y uso del ordenador — LiveClaw 48,09, WebArena Verified 26,75, tau3-Bench Banking 8,04. El resultado bancario es la excepción: una puntuación de un solo dígito en una suite de tareas que otros modelos agénticos manejan mucho mejor. Es un recordatorio de que "agéntico" no es una única capacidad.

• Ingeniería de software — SWE-Bench Verified 51,00 con OpenCode, SciCode 32,71. En la mitad de la tabla.

• Matemáticas — MATH-500 96.04. Sólido para el tamaño.

• Conocimiento — GPQA Diamond 74.42, HLE 7.40, AA-Omniscience −24.90. La puntuación negativa en Omniscience es la señal honesta aquí: en un benchmark que penaliza las respuestas incorrectas dadas con confianza, el modelo pierde más de lo que gana. El propio posicionamiento de Liquid lo reconoce: el modelo está pensado para combinarse con recuperación, no para confiar en él como una enciclopedia.

Leídas en conjunto, esas filas vienen a decir que el modelo sigue instrucciones y llama herramientas con solvencia, pero tiene una base de conocimiento escasa. Para un agente local que lee tus archivos y llama a tus API, ese es el equilibrio correcto. Para un asistente de investigación, es el equivocado.

La afirmación sobre la eficiencia, con sus salvedades

Liquid reporta 184 tokens por segundo en un Apple M5 Max usando unos 15 GB de memoria, y 114 tokens por segundo en un Ryzen AI Max+ 395. Son cifras del fabricante en hardware específico, no un benchmark general, y variarán con la cuantización y el tamaño del lote. La dirección sigue siendo significativa: un modelo de 24B con 2,45B activos puede ejecutarse en un portátil de una forma que uno denso de 24B no puede.

La contrapartida es el ancho de banda de memoria. Los modelos dispersos siguen teniendo que mantener los 24 mil millones de parámetros en memoria: el ahorro está en el cómputo por token, no en el almacenamiento. Por eso la cifra de 15 GB importa tanto como el rendimiento: es aproximadamente una cuantización de 4 bits del conjunto completo de pesos y establece el mínimo de hardware.

Dónde tendría que situarse LBS-27B

Todo en este enfrentamiento depende de dos campos que aún no existen en el repositorio LBS-27B: el número de expertos y el número de parámetros activos.

Si LBS-27B es disperso con algo así como 2B a 4B activos, cae directamente en el territorio de LFM2.5 —una base de conocimiento de clase 27B con el cómputo de un modelo pequeño— y la comparación se convierte en una contienda directa por la calidad por parámetro activo. Si es denso, es un producto completamente distinto: un modelo del lado del servidor con cómputo predecible y un consumo de memoria que descarta a la mayoría de los portátiles. Si es disperso con un número elevado de parámetros activos, se sitúa entre los dos y compite por calidad en lugar de eficiencia.

No hay forma de inferir cuál a partir del repositorio. El nombre dice 27B, el README dice Apache-2.0 y el árbol de archivos no dice nada más. inclusionAI no ha publicado una ficha, una entrada de blog ni un artículo que hayamos podido encontrar.

La comparación, en la medida en que se pueda hacer

• Parámetros totales: 24,0B para LFM2.5 24B A2B; un 27B no verificado para LBS-27B.

• Parámetros activos — 2,45B para LFM2.5; desconocidos para LBS-27B, y esta es la incógnita decisiva.

Arquitectura — 64 expertos con enrutamiento top-4 y 40 capas para LFM2.5; desconocido para LBS-27B.

• Contexto — 131.072 tokens para LFM2.5; desconocido para LBS-27B.

• Modalidad: solo texto para LFM2.5; se desconoce para LBS-27B.

• Idiomas — dieciséis enumerados para LFM2.5; desconocido para LBS-27B.

• Razonamiento — cadena de pensamiento por defecto, sin un modo documentado sin pensamiento, para LFM2.5; desconocido para LBS-27B.

• Licencia — la licencia LFM 1.0, con un requisito de licencia comercial por encima de los 10 millones de dólares en ingresos anuales, para LFM2.5; Apache-2.0 declarada para LBS-27B.

• Evaluaciones publicadas: dieciséis filas reportadas por el proveedor para LFM2.5; ninguna para LBS-27B.

La licencia es una cuestión de adquisiciones, no una nota a pie de página.

Esta es la única dimensión en la que el repositorio vacío ya le da una ventaja a LBS-27B. La licencia LFM 1.0 no es de código abierto en el sentido de la OSI: las empresas con más de 10 millones de dólares en ingresos anuales necesitan una licencia comercial independiente antes de desplegarla. Para un desarrollador individual o una startup por debajo de ese umbral, eso no supone ningún problema. Para una empresa de tamaño medio, implica una revisión legal, una negociación y una partida presupuestaria.

LBS-27B declara Apache-2.0 en su README. Es una licencia permisiva con una concesión explícita de patentes y sin umbral de ingresos, y si se mantiene hasta la publicación de los pesos, elimina todo un paso de adquisición. Es la única ventaja concreta que LBS-27B tiene actualmente en esta comparación, y vale la pena decirlo claramente porque es real — una declaración de licencia hecha en la creación del repositorio es evidencia débil, pero no es poca cosa.

En el dispositivo frente a la API: dos productos diferentes

LFM2.5 24B A2B está diseñado para ejecutarse donde están los datos. El argumento de venta es la privacidad y la latencia: un modelo en un portátil o una estación de trabajo que nunca envía una solicitud a un tercero, con una capacidad de llamada a herramientas lo suficientemente buena como para impulsar la automatización local. La huella de memoria de 4 bits y el contexto de 131K están dimensionados para esa tarea.

LBS-27B no ha dicho para qué sirve. Si inclusionAI lanza un modelo diseñado para ofrecer servicio del lado del servidor, el argumento de la ejecución en el dispositivo no se traslada y los dos modelos son complementos en lugar de sustitutos. Si lanza un MoE con pocos parámetros activos y una propuesta de despliegue local, la comparación es directa y la ventaja de dos generaciones de Liquid en herramientas para dispositivos —soporte de llama.cpp, MLX, ONNX y vLLM, además de un arnés de agentes documentado— se convierte en el desempate.

El soporte de frameworks es una parte subestimada de esto. Un modelo que no está en llama.cpp o MLX desde el primer día no es, en la práctica, un modelo en el dispositivo, independientemente de su número de parámetros activos.

Probar un modelo no comprobado sin apostar por él

Ni LBS-27B ni LFM2.5 24B A2B están disponibles hoy en OrcaRouter, así que no hay endpoint alojado para ninguno de los dos y no vamos a sugerir lo contrario. La razón para mencionar la plataforma aquí es el problema de evaluación que se deriva: si quieres saber si un nuevo modelo de pocos parámetros activos puede reemplazar al que usas actualmente, necesitas ejecutar ambos con tu propio tráfico, no en una tabla de clasificación.

El DSL de enrutamiento de OrcaRouter te permite enviar un porcentaje de las solicitudes a un modelo candidato mientras mantienes el modelo actual como predeterminado, y la conmutación por error automática hace que, si un candidato agota el tiempo de espera o da error, se pase al modelo conocido en lugar de hacer fallar la solicitud. Para los casos difíciles en los que un solo modelo no basta, la fusión de modelos permite que un panel de modelos responda en conjunto y devuelve un resultado combinado; resulta útil cuando la tarea es intensiva en conocimiento y el punto débil del modelo barato es justo lo que estás probando. El catálogo de más de 200 modelos y el recargo del 0 % importan menos aquí que la capacidad de comparar con tus propias entradas sin una segunda integración.

Esa es una forma de generar la evidencia que le falta a esta página. No es un sustituto de que el modelo exista.

Tres lectores, tres respuestas

Si estás creando un agente en el dispositivo y necesitas algo que funcione hoy en un portátil, LFM2.5 24B A2B es un candidato serio: buen seguimiento de instrucciones, buena capacidad de llamada a herramientas en varios marcos de prueba, contexto de 131K y una vía documentada hacia los entornos de ejecución locales habituales. Revisa primero el umbral de licencia y no esperes que conozca hechos sin recuperación.

Si estás eligiendo un 27B del lado del servidor y necesitas una licencia permisiva, vale la pena seguir de cerca LBS-27B precisamente porque Apache-2.0 ya está declarada. Pero no hay nada que evaluar, y una declaración de licencia no es un modelo.

Si usted es una empresa con más de $10 millones en ingresos y un proceso de adquisiciones estricto, la diferencia de licencia puede importar más que cualquier fila de benchmark en este artículo. La licencia personalizada de LFM2.5 es un costo real; la Apache-2.0 de LBS-27B es una ventaja real, siempre que sobreviva hasta el lanzamiento.

El número que cambiaría las tres respuestas es el recuento de parámetros activos. Hasta que exista, la postura honesta es que un modelo tiene un argumento de eficiencia y el otro tiene un repositorio.