IBM Granite 4.2: tres modelos open-weight para correr local

Qué trae Granite 4.2 y por qué importa para tu startup

IBM presentó Granite 4.2, su nueva familia de modelos de lenguaje open-weight pensada para descargarse y correr en infraestructura propia, en tres tamaños: 3B, 8B y 30B parámetros, todos bajo licencia Apache 2.0. Según Ars Technica, los modelos comparten ventana de contexto nativa de 128.000 tokens y un modo de razonamiento con chain-of-thought que se puede activar o desactivar desde el chat template.

El matiz clave, y la razón del titular reasoning-focused con el que IBM bautizó la línea, es que los tres variantes traen un "switchable thinking mode": pueden entregar una respuesta directa o, por defecto, encadenar un razonamiento interno antes de la respuesta final. En conversación multi-turno, los pensamientos previos se descartan para no gastar contexto, lo que ayuda a mantener latencia baja en producción.

Cómo cambia respecto a versiones anteriores

Hasta ahora, la familia Granite se posicionaba como asistente de instrucciones. Granite 4.2 es su primer giro explícito hacia razonamiento funcional: no "piensa" como un humano, sino que planifica pasos intermedios y los arrastra a lo largo de varios turnos para resolver mejor problemas de varios pasos.

El reporte técnico publicado por IBM Granite Team describe un pipeline de cinco fases de pre-entrenamiento sobre aproximadamente 15 billones de tokens que extiende el contexto a 512K durante el entrenamiento, seguido de un supervised fine-tuning sobre unos 7,2 millones de muestras de razonamiento y trayectorias agentic. Después viene lo más distintivo: un RL multi-etapa donde cada etapa entrena una capacidad y arranca del checkpoint anterior.

• RL fundacional con recompensas verificables (matemáticas con respuesta chequeable, código evaluado por tests ocultos, instrucciones con format checkers) en los tres tamaños.
• Bloque agentic sólo en 8B y 30B: ingeniería de software con el harness OpenHands, uso de terminal con hasta 64 turnos por rollout, y búsquedas web multi-hop.
• RLHF final con penalización por longitud de razonamiento, para evitar las cadenas verbosas que suelen generar los modelos "pensantes".

En resumen: el 3B es un modelo tool-using competente y barato; los 8B y 30B son los que de verdad saben actuar dentro de entornos vivos.

Los números que IBM reporta (y cómo leerlos)

Los benchmarks publicados por IBM, ejecutados sobre el SDK NeMo Evaluator, muestran el patrón esperado: a más parámetros, más capacidad agentic, y la brecha se ensancha donde el bloque agentic es la diferencia.

• SWE-Bench Verified: 57,00 (30B), 47,67 (8B); el 3B no se reporta porque no pasó por el bloque agentic.
• Terminal-Bench 2.1: 29,24 (30B), 20,56 (8B).
• AIME25 (matemáticas): 89,17 (30B), 86,67 (8B), 78,33 (3B).
• GPQA (ciencia): 66,41 (30B), 64,14 (8B), 54,80 (3B).
• RULER 128K (contexto largo): 81,38 (30B), 71,41 (8B), 55,30 (3B).

Para founders, la lectura útil es que el 3B ya pasa el corte de razonamiento matemático puro, y que el salto real a "agente útil" empieza en 8B. Si tu producto necesita ejecutar código o llamar APIs en cadena, el 8B es el mínimo razonable.

El detalle técnico que pocos van a mirar (y tú deberías)

Granite 4.2 entrena con GRPO asíncrono, una variante de optimización por política relativa que elimina la red de valor separada que suelen tener los pipelines de RL. Generación y entrenamiento corren en pools de GPU distintos que no se bloquean entre sí: los workers siguen muestreando trayectorias mientras el entrenador empuja pesos actualizados mid-rollout. Esto importa porque baja el costo marginal de entrenar capacidades nuevas sobre el modelo base.

El stack corre sobre NeMo-Gym (entornos) y NeMo-RL (loop de entrenamiento sobre Megatron-Core con generación vLLM), y se entrenó en un cluster NVIDIA GB200 NVL72 alquilado a CoreWeave. IBM también publicó variantes cuantizadas: FP8 sin calibración, NVFP4, MXFP4 calibrado sobre 2.000 muestras, y 14 formatos GGUF vía llama.cpp para correr en hardware más modesto.

Todo bajo Apache 2.0: pesos, código, datos, hiperparámetros por etapa y receta de mezcla. Eso es lo que separa a Granite 4.2 de modelos que dicen ser "abiertos" pero esconden la receta de post-entrenamiento.

Por qué los modelos locales están de moda (y qué cambia para tu startup)

La conversación sobre Granite 4.2 no ocurre en el vacío. En julio de 2026, un grupo de más de 25 empresas tecnológicas —entre ellas IBM, Nvidia, Microsoft y Meta— firmó una carta abierta pidiendo a los reguladores no imponer "restricciones prematuras" a los modelos open-weight, según reportó CNBC. La motivación es geopolítica (los modelos chinos como Kimi K3 de Moonshot AI están empujando fuerte en benchmarks) pero también económica: correr un modelo en tu propia infraestructura elimina el per-token pricing y te devuelve el control de los datos.

En paralelo, Fastino Labs anunció el 11 de agosto dos modelos open-weight especializados para finanzas y salud, post-entrenados sobre NVIDIA Nemotron 3.5 Lightning por un agente autónomo en menos de diez horas. El comunicado, recogido por TMCnet, reporta que FinQA pasó de 15,86% a 59,23% en el modelo de finanzas; el de salud llevó MEDEC flag accuracy de 53,66% a 64,98%. Es la prueba operativa de que la jugada ya no es "entrenar desde cero", sino post-entrenar modelos abiertos con tus datos propios.

Para un founder, eso significa que el costo de entrada a tener un modelo tuneado a tu dominio cayó varios órdenes de magnitud: ya no necesitas un equipo de research, sólo necesitas acceso a un modelo base decente y a un agente o pipeline de fine-tuning.

Qué significa esto para tu startup

Tres movimientos accionables esta semana:

• Evalúa Granite 4.2 contra tu stack actual. Si hoy pagas por inferencia en la nube y tu caso de uso tolera latencia adicional, descarga los pesos desde Hugging Face y mide costo por token propio vs. tu factura actual de OpenAI/Anthropic. El 3B apunta a despliegues ligeros; el 8B es el equilibrio razonable entre costo y capacidad agentic.
• Diseña pensando en routers de modelo. Si tu producto llama a un LLM por defecto, vale la pena enrutar: prompts triviales al 3B local, razonamiento pesado al 30B en GPU dedicada, y sólo los casos extremos a un frontier cerrado. Ars Technica menciona explícitamente el auge de los model routers como respuesta al desbalance de costo/rendimiento.
• Explora el post-training sobre tus datos. El ejemplo de Fastino muestra que un agente autónomo puede entregar un modelo de dominio funcional en horas, no semanas. Si manejas datos sensibles (financieros, clínicos, legales), un pipeline así te da accuracy de dominio sin ceder el control del dato.

Riesgos y costos que conviene tener en el radar

Granite 4.2 no es el modelo más rápido ni el más agresivo en rankings. Ars Technica lo dice sin rodeos: la propuesta de IBM es despliegues predecibles, no liderazgo en benchmarks. El modo de razonamiento encadenado incrementa latencia y consumo de cómputo frente al modo directo, así que no tiene sentido activarlo para todas las consultas.

Razonar no es gratis: si tu caso de uso exige respuesta en milisegundos (autocompletado, agentes de voz en tiempo real), el modo thinking probablemente no te sirve. Y el bloque agentic del 8B/30B, el que justifica su tamaño, requiere GPUs con memoria suficiente para el contexto de 128K y los entornos de ejecución. Planifica capacidad antes de prometer tiempos de respuesta.

Fuentes

• IBM's new Granite 4.2 models ride the wave of interest in local LLMs
• IBM's Granite 4.2 Models Learn to Think and Act Inside Environments
• Fastino Labs Releases Two Specialized Open-Weight Models for Finance and Healthcare
• Nvidia, Microsoft, Meta warn against 'premature restrictions' of open-weight AI models
• Anthropic and Nvidia come out against blanket bans on open-weight AI models