LFM3-1.7B frente a Granite 4.2 30B: dos modelos de agentes que dividen el veredicto según el eje

Coloque LFM3-1.7B y Granite 4.2 30B en la misma página y los promedios agregados apuntan en direcciones opuestas según la fila que se lea. En Berkeley Function Calling Leaderboard V4, el modelo de 1.730 millones de parámetros de Liquid AI obtiene 71,39 frente a los 61,39 de IBM —una victoria de diez puntos para un modelo aproximadamente diecisiete veces más pequeño. En SWE-bench Verified, Granite obtiene 57,00 frente a los 43,40 de LFM3-1.7B, una victoria de 13,6 puntos en la dirección opuesta. El enrutamiento no añade margen al precio de lista de un proveedor. Los precios de lista de los proveedores se trasladan con un 0% de margen.

Ambos modelos están diseñados para agentes, ambos se lanzaron con menos de dos meses de diferencia en 2026, y ambos proveedores publican suficientes benchmarks solapados como para que sea posible una comparación real en lugar de un collage. Eso hace que este sea uno de esos raros enfrentamientos en los que la pregunta interesante no es qué modelo es mejor, sino en qué eje se mueve realmente tu carga de trabajo. Muy pocas tareas requieren a la vez una puntuación de 71 en BFCL y una de 57 en SWE-bench, y a las que sí lo hacen no les viene bien ninguno de los dos modelos por sí solo.

Los dos números que se cruzan

Granite 4.2 30B se lanzó el 25 de agosto de 2026 bajo Apache 2.0, un modelo denso de ~30B construido sobre la base de Granite 4.1 30B y entrenado con aproximadamente 15 billones de tokens. El enfoque de IBM es empresarial: tres modos de pensamiento configurables, llamada a herramientas nativa conforme al esquema de OpenAI, doce idiomas probados y un pipeline de entrenamiento de tres etapas que termina en aprendizaje por refuerzo GRPO de múltiples fases.

LFM3-1.7B llegó dos meses después, anunciado el 27 de octubre de 2026, tras un postentrenamiento específico en arneses agénticos: Liquid menciona a Hermes Agent, PI y OpenClaw en la ficha del modelo. Es un modelo denso de 1,73B con un contexto de 256K, y está posicionado explícitamente para agentes locales y llamadas a herramientas en lugar de razonamiento general.

El cruce de benchmarks no es un accidente de un único número débil. Toda la tabla publicada de LFM3-1.7B se inclina por lo agéntico: 71,39 en BFCL V4, 80,36 en ToolSandbox, 68,01 en τ³-bench, 45,60 en LiveClaw, 38,42 en WebArena-Verified. La tabla de Granite se inclina por la ingeniería: 57,00 en SWE-bench Verified, 33,29 en SWE-bench Pro, 41,89 en SWE-bench Multilingual, 38,76 en SciCode, 29,24 en TerminalBench 2.1. Cada proveedor optimizó para una definición diferente de «agente», y las tablas de benchmarks son honestas al respecto.

τ³ en 68,01 frente a 68,05 es el verdadero titular

Bajo las dos brechas dramáticas se esconde un empate técnico. En τ³-bench, la evaluación de uso de herramientas que mide la finalización de tareas de varios turnos con simuladores de usuario y políticas de dominio, LFM3-1.7B obtiene 68.01 y Granite 4.2 30B obtiene 68.05 — una diferencia de cuatro centésimas de punto, indistinguible del ruido.

Ese es un resultado más interesante que cualquiera de las dos grandes brechas, porque τ³ es el benchmark más cercano a lo que la mayoría de los despliegues de agentes realmente hacen: mantener una conversación, seguir una política, llamar a la función correcta, recuperarse de un error. Si un modelo de 1.73B empata ahí con un modelo denso de 30B, el número de parámetros está comprando algo distinto del uso competente de herramientas multiturno.

Lo que se consigue con ello se refleja en BFCL y SWE-bench, que miden cosas diferentes. BFCL V4 evalúa la corrección de llamadas a funciones de un solo turno conforme a un esquema — el 71.39 de LFM3-1.7B sugiere que el post-entrenamiento de Liquid en arneses de agentes reales dio frutos directamente. SWE-bench Verified evalúa la reparación de una incidencia real de GitHub de principio a fin, lo que requiere mantener un repositorio en contexto, planificar entre archivos y producir un parche que pase las pruebas — el 57.00 de Granite refleja un modelo con la capacidad de hacerlo y un conjunto de entrenamiento construido para ello.

Así que la división es legible. Modelo pequeño, bien entrenado en esquemas de herramientas: gana la prueba de llamada a función. Modelo grande, entrenado en reparación de código: gana la prueba de repositorio. Empatan en el terreno intermedio de múltiples turnos, donde ambos fueron entrenados específicamente.

El contexto es donde las especificaciones divergen con más fuerza.

• Contexto — 262,144 tokens para LFM3-1.7B; 128K nativos para Granite 4.2 30B, ampliables a 512K. La ampliación no es gratuita, e IBM es honesta al reconocer que se trata de una ampliación y no de una ventana nativa.

• Retención de contexto largo — 65,56 en RULER a 128K para LFM3-1.7B frente a 81,4 para Granite 4.2 30B en la misma familia de benchmarks. El modelo más grande retiene más de un documento largo, lo que es lo opuesto de lo que sugieren las cifras destacadas de contexto.

• Huella — aproximadamente 1 GB en 4 bits frente a unos 30B de pesos BF16, con versiones oficiales en FP8, NVFP4 y MXFP4. Este es un modelo para una sola GPU, no un modelo para portátil.

• Idiomas — dieciséis para LFM3-1.7B frente a doce probados para Granite, con una superposición diferente. Los doce de Granite incluyen checo y neerlandés; los de Liquid incluyen tailandés, vietnamita e indonesio.

• Modos de pensamiento — Granite 4.2 30B incluye modos completo, de bajo esfuerzo y sin pensamiento. LFM3-1.7B no cuenta con esa interfaz, y su ficha indica que no está pensado para razonamiento complejo de varios pasos de partida.

• Licencia — Apache 2.0 para Granite frente a la LFM Open License v1.0, que es gratuita por debajo de $10 millones en ingresos anuales y requiere una licencia comercial por encima de esa cifra.

¿Qué costos tiene un 30B denso que un 1.73B no?

Granite 4.2 30B es denso, lo que significa que los treinta mil millones de parámetros intervienen en cada token. Aquí no hay descuento por parámetros activos: el coste computacional por token es aproximadamente diecisiete veces el del modelo pequeño, y el coste de memoria es el archivo de pesos completo. IBM ofrece cuantizaciones para hacerlo viable, pero no hay ninguna configuración en la que se ejecute en un teléfono.

La ventaja de LFM3-1.7B no es principalmente la velocidad. Es que el modelo cabe dentro del mismo presupuesto de memoria que el resto de tu aplicación. Un modelo de 1 GB deja espacio para un almacén de documentos, una caché y un segundo modelo en el mismo dispositivo, lo cual es lo que hace posible un agente local en lugar de solo teóricamente local. Liquid informa una decodificación entre 1,8 y 2,8 veces más rápida que sus predecesores en el hardware probado y una caché KV de 1,6 GB a 128K, y ambas cosas importan para un agente en el dispositivo que mantiene una conversación larga.

La contrapartida es que la capacidad de 30B de Granite está haciendo un trabajo real en las cifras de SWE-bench. Si el trabajo de tu agente es cambiar código en todo un repositorio, una brecha de 13,6 puntos no es algo que un modelo más pequeño recupere mediante prompting, y el ahorro de cómputo conlleva un peor resultado.

Licencias, firma y la cuestión de las adquisiciones

Apache 2.0 es la razón por la que una gran organización puede adoptar Granite 4.2 30B sin una revisión legal. No hay umbral de ingresos, ni desencadenante comercial, ni negociación. IBM también ha estado firmando criptográficamente los modelos Granite publicados desde abril de 2026, lo que suena a un detalle hasta que eres la persona que tiene que demostrar que los pesos en producción son los pesos que se verificaron.

La LFM Open License v1.0 de Liquid es genuinamente permisiva a escala de startup —gratuita para uso comercial por debajo de los 10 millones de dólares de ingresos anuales—, pero por encima de ese umbral exige una licencia comercial de pago. Para un desarrollador individual o un equipo pequeño, esto no supone ningún problema. Para una unidad de negocio dentro de una empresa más grande, es una conversación que comienza antes del primer despliegue y que puede que no termine rápidamente. Esa asimetría no se refleja en ningún benchmark y a menudo decide la cuestión por sí sola.

Ejecutar ambos sin apostar por ninguno

El patrón práctico para un equipo que evalúa estos dos no es elegir uno primero. Ambos tienen pesos abiertos y ambos no han sido probados por evaluadores independientes, lo que significa que el único benchmark que importa es el tuyo. Enruta los modelos candidatos a través de un único endpoint, ejecuta las mismas trazas de agente en ambos y compara en tu tarea en lugar de en BFCL o SWE-bench.

OrcaRouter es útil aquí menos como host que como superficie de control: una sola clave y una sola factura para más de 200 modelos, precios de lista de los proveedores trasladados con un 0 % de margen, y conmutación por error automática para que una ejecución de evaluación no se venga abajo porque un proveedor haya tenido una mala hora. Ni LFM3-1.7B ni Granite 4.2 30B están hoy en nuestro catálogo —ambos son descargas de pesos abiertos, y el autoalojamiento es el camino para cada uno. Donde el enrutamiento se gana su lugar es en el stack que lo rodea: el modelo de frontera al que tu agente escala, o la segunda opinión con la que comparas cuando el parche del modelo local no supera sus pruebas.

¿Quién debería tomar cuál?

Elija LFM3-1.7B si el agente se ejecuta en el dispositivo del usuario, si el trabajo consiste en llamadas a herramientas y extracción estructurada contra una API, y si un contexto de 256K con un consumo de 1 GB es lo que hace posible el producto. Acepte la propia advertencia del proveedor de que no es para codificación agéntica, y mantenga un modelo más grande detrás de él para los casos que lo necesiten.

Elige Granite 4.2 30B si el agente toca una base de código, si necesitas Apache 2.0 y pesos firmados para adquisiciones, si la carga de trabajo se beneficia de un esfuerzo de razonamiento configurable y si tienes una GPU para servirlo. El déficit de BFCL es real pero acotado: mide la corrección del esquema en una sola llamada, y un modelo de 30B con un esquema de herramientas bien diseñado cierra gran parte de esa brecha en la práctica.

Adopta el reparto si estás construyendo eso a lo que ambos proveedores apuntan: un agente local que gestiona llamadas de herramientas rutinarias dentro de un gigabyte y deriva a un servidor el trabajo a escala de repositorio. Esa arquitectura usa cada modelo allí donde su propia tabla de benchmarks indica que es fuerte, y es la única configuración en la que los ejes cruzados dejan de ser un problema.

La pregunta que vale la pena seguir es si la receta de posentrenamiento agéntico de Liquid se transfiere a un checkpoint más grande. Si un futuro modelo LFM mantiene el comportamiento de BFCL de la clase 71.39 y añade capacidad para trabajo de repositorio, la división por ejes se desmorona y esta comparación se convierte en una simple decisión de tamaño. Hasta entonces, los dos modelos no compiten por el mismo trabajo: son las dos mitades de uno solo.