IBM presenta Granite 4.2, una nueva familia de modelos de lenguaje centrados en el razonamiento, el uso de herramientas y la ejecución de tareas en entornos reales. La serie incluye versiones de 3.000, 8.000 y 30.000 millones de parámetros, todas publicadas bajo la licencia Apache 2.0.
¿Qué cambia frente a un asistente tradicional? Granite 4.2 puede pensar antes de responder, trabajar en modo rápido o deliberativo y realizar llamadas nativas a herramientas. En los modelos de 8B y 30B, IBM además entrenó agentes capaces de editar código, utilizar una terminal y buscar información en la web.
Tres modelos con una misma base
Granite 4.2 utiliza una arquitectura transformer densa, de tipo decoder-only. En términos sencillos, cada modelo genera texto de forma autoregresiva, prediciendo el siguiente token a partir del contexto anterior.
Los tres tamaños comparten el diseño principal, aunque cambian su profundidad y capacidad:
- Granite 4.2 3B: 40 capas, embeddings de 2.560 dimensiones y aproximadamente 3.000 millones de parámetros.
- Granite 4.2 8B: 40 capas, embeddings de 4.096 dimensiones y aproximadamente 8.000 millones de parámetros.
- Granite 4.2 30B: 64 capas, embeddings de 4.096 dimensiones y aproximadamente 30.000 millones de parámetros.
La arquitectura incorpora Grouped Query Attention o GQA, con 8 cabezas para claves y valores. Esta técnica reduce el consumo de memoria durante la inferencia sin eliminar por completo la capacidad de atención del modelo.
También utiliza RoPE para representar posiciones, activaciones SwiGLU en la red de alimentación, RMSNorm para estabilizar el entrenamiento y precisión bfloat16. La longitud de secuencia base es de 131.072 tokens, aunque el entrenamiento de contexto largo amplía la capacidad hasta 512.000 tokens.
Un contexto de 512K tokens permite trabajar con repositorios de código, documentos extensos o grandes historiales de conversación sin dividirlos en tantos fragmentos.
Cómo entrenó IBM a Granite 4.2
IBM entrenó los modelos desde cero con aproximadamente 15 billones de tokens. El proceso de preentrenamiento se organizó en cinco fases, en lugar de utilizar una única mezcla de datos durante todo el recorrido.
Las primeras dos fases se enfocan en adquirir conocimientos generales. Las fases tres y cuatro aumentan progresivamente la proporción de datos de mayor calidad. La quinta fase introduce el entrenamiento de contexto largo y lleva la ventana hasta 512K tokens.
Esta estrategia permite que el modelo no solo aprenda información, sino también que se adapte gradualmente a datos más seleccionados y a tareas que requieren manejar entradas muy extensas.
Después del preentrenamiento llegó el ajuste supervisado, conocido como SFT. IBM utilizó alrededor de 7,2 millones de muestras, equivalentes a unos 100.000 millones de tokens, de los cuales aproximadamente 65.000 millones fueron utilizados directamente para entrenar el modelo.
La mezcla incluyó un 31,6% de datos agentivos y un 68,4% de datos no agentivos. Entre las tareas agentivas aparecen ingeniería de software, llamadas a herramientas, uso de terminal, matemáticas, búsqueda y ejecución de acciones.
Los datos no agentivos cubren seguimiento de instrucciones, programación, matemáticas, idiomas, ciencia, razonamiento y seguridad. Antes de entrar en la mezcla final, IBM normalizó los formatos, eliminó duplicados y utilizó modelos como GPT-OSS-120B y Gemma 4 para evaluar la calidad de las muestras.
También se descartaron ejemplos con información inventada, llamadas a funciones inexistentes o interacciones inválidas con herramientas. Esto es importante: entrenar un agente no consiste solo en darle conversaciones, sino en mostrarle qué acciones son válidas y cuáles producen resultados confiables.
Razonamiento con tres niveles de esfuerzo
Una de las características más visibles de Granite 4.2 es su interruptor entre pensamiento y no pensamiento. El usuario o la aplicación puede decidir cuánto debe deliberar el modelo antes de responder.
Los tres modos principales son:
- Modo no-thinking: responde directamente y reduce la latencia.
- Modo thinking: genera una cadena de razonamiento antes de entregar la respuesta.
- Modo low-effort: utiliza un presupuesto breve de razonamiento para preguntas sencillas.
Por ejemplo, para una pregunta como cuál es la capital de Francia, el modelo puede responder directamente. Para resolver un problema matemático, depurar un programa o planificar una secuencia de acciones, puede activar un proceso de razonamiento más largo.
Esta separación resulta útil en productos reales. No todas las consultas merecen el mismo gasto de cómputo. ¿Tiene sentido emplear varios segundos de deliberación para responder cuánto es 2 + 2? Probablemente no.
El formato también permite conservar o eliminar el razonamiento previo en el historial. IBM incluye opciones para recortar esas partes y ahorrar espacio de contexto cuando una conversación continúa.
De chatbot a agente con herramientas
Todos los modelos Granite 4.2 admiten llamadas nativas a herramientas mediante el esquema de funciones de OpenAI. El modelo puede analizar la solicitud, elegir una función, completar sus argumentos y esperar el resultado antes de redactar una respuesta final.
Un ejemplo sencillo sería una aplicación meteorológica. Si el usuario pregunta por el clima de una ciudad, Granite puede seleccionar una función como get_current_weather, enviar el nombre de la ciudad y luego explicar el resultado recibido.
La ventaja no está únicamente en llamar a una función. El modelo también puede razonar sobre cuál herramienta necesita y encadenar varias acciones. Esto abre la puerta a asistentes capaces de consultar bases de datos, ejecutar código, buscar documentos o interactuar con servicios empresariales.
Servido mediante un endpoint compatible con OpenAI, por ejemplo con vLLM, Granite 4.2 puede conectarse a distintos entornos de agentes sin crear adaptadores especiales. IBM también señala compatibilidad con SGLang.
El refuerzo como una escalera de habilidades
Después del ajuste supervisado, IBM aplicó un proceso de aprendizaje por refuerzo en varias etapas. No se trata de una única pasada de optimización, sino de una escalera donde cada fase se concentra en una capacidad distinta y utiliza el resultado anterior como punto de partida.
La secuencia general es:
SFT → RLVR → refuerzos de habilidades → agente SWE → terminal → búsqueda → RLHF
RLVR significa aprendizaje por refuerzo con recompensas verificables. En esta etapa, el modelo recibe una señal objetiva cuando una respuesta coincide con la solución correcta, el código supera pruebas o la salida respeta un formato definido.
Las tareas incluyen matemáticas, demostraciones formales en Lean, programación competitiva, ciencia, seguimiento de instrucciones, llamadas a funciones y acertijos de razonamiento.
IBM utiliza GRPO, un método que compara varias respuestas generadas para el mismo problema. En lugar de entrenar una red adicional que estime el valor de cada respuesta, calcula una ventaja relativa usando las recompensas del grupo.
En el caso de Granite 4.2, una tanda de entrenamiento puede utilizar 256 indicaciones y 16 respuestas por indicación, para un total de 4.096 ejemplos. El sistema emplea un entrenamiento asíncrono: mientras unos trabajadores generan respuestas, otros actualizan los parámetros del modelo.
Para controlar las diferencias entre la versión que genera los datos y la versión que aprende de ellos, IBM limita cuánto puede retrasarse cada trabajador y utiliza muestreo de importancia truncado. Dicho de forma simple, se evita que ejemplos demasiado antiguos tengan una influencia desproporcionada.
Los modelos grandes aprenden a actuar
El modelo de 3B recibe entrenamiento de razonamiento, habilidades específicas y alineación. Los modelos de 8B y 30B avanzan además por un bloque de aprendizaje por refuerzo agentivo.
Ese bloque se organiza en tres entornos:
- SWE agent: trabaja en repositorios reales dentro de contenedores aislados. Lee archivos, modifica código, ejecuta pruebas y recibe una recompensa si los tests ocultos pasan.
- Terminal agent: opera en una terminal real. Planifica comandos, interpreta sus resultados y se recupera de errores en tareas que pueden durar hasta 64 turnos.
- Search agent: investiga preguntas complejas mediante búsquedas web de varios pasos y recibe una evaluación sobre la calidad de la respuesta final.
La diferencia es significativa. Una cosa es responder cómo se arreglaría un error de software y otra muy distinta es abrir un repositorio, editar los archivos correctos, ejecutar las pruebas y entregar una solución funcional.
Para entrenar estos comportamientos, IBM utilizó NeMo-RL en el lado del entrenamiento y NeMo-Gym para coordinar herramientas, entornos, verificadores y recompensas. La misma interfaz puede representar tanto un comprobador matemático como un entorno completo de ingeniería de software.
Resultados: razonamiento, código y contexto largo
IBM evaluó Granite 4.2 en razonamiento, programación, uso de herramientas, seguimiento de instrucciones y contexto largo. Los resultados mejoran generalmente con el tamaño del modelo.
Algunos datos destacados son:
- En SWE-Bench Verified, Granite 4.2 obtiene 47,67% en 8B y 57% en 30B.
- En Terminal-Bench 2.1, alcanza 20,56% en 8B y 29,24% en 30B.
- En AIME25, registra 78,33% en 3B, 86,67% en 8B y 89,17% en 30B.
- En GPQA, obtiene 54,80% en 3B, 64,14% en 8B y 66,41% en 30B.
- En MMLU-Pro, alcanza 67,84% en 3B, 74,04% en 8B y 77,60% en 30B.
- En RULER a 128K, registra 55,30% en 3B, 71,41% en 8B y 81,38% en 30B.
El modelo de 30B lidera en las pruebas agentivas, algo coherente con su mayor capacidad y con el entrenamiento adicional en ingeniería de software, terminal y búsqueda. El modelo de 3B, por su parte, puede ser más atractivo para despliegues locales donde la memoria y el costo de inferencia son limitantes.
Granite 4.2 admite inglés, alemán, español, francés, japonés, portugués, árabe, checo, italiano, coreano, neerlandés y chino.
Despliegue local y versiones cuantizadas
IBM publicó variantes cuantizadas para reducir el consumo de memoria durante la inferencia. Hay versiones en FP8, NVFP4 y MXFP4, además de archivos GGUF compatibles con llama.cpp.
Entre los formatos GGUF disponibles se encuentran Q8_0, Q6_K, Q5_K_M, Q4_K_M, Q4_0, Q3_K_L y Q2_K. En la práctica, los formatos con menos bits permiten ejecutar el modelo con menos memoria, aunque pueden reducir ligeramente la calidad o la precisión.
Las versiones FP8 utilizan pesos dinámicos por canal y activaciones por token. Las variantes NVFP4 y MXFP4 se cuantizaron con GPTQ a partir de 2.000 muestras del conjunto de ajuste supervisado.
Para comenzar con Transformers, IBM muestra una instalación basada en PyTorch y transformers:
pip install torch accelerate transformers
El modelo puede cargarse con bfloat16 y utilizar el chat template para activar el razonamiento. Un ejemplo conceptual sería:
from transformers import AutoModelForCausalLM, AutoTokenizer
model_path = "ibm-granite/granite-4.2-3b"
tokenizer = AutoTokenizer.from_pretrained(model_path)
model = AutoModelForCausalLM.from_pretrained(
model_path,
device_map="cuda",
torch_dtype="auto"
)
Para aplicaciones agentivas, IBM documenta integraciones con herramientas como OpenCode, Pi y OpenHands. Estos sistemas pueden conectarse a un servidor vLLM mediante una API compatible con OpenAI y utilizar Granite como modelo local para programar, ejecutar comandos o coordinar tareas.
Qué significa para desarrolladores y empresas
Granite 4.2 combina tres tendencias que ya están cambiando el desarrollo de aplicaciones con IA: modelos de razonamiento, llamadas a herramientas y entrenamiento en entornos reales.
La licencia Apache 2.0 facilita su uso en proyectos comerciales y de investigación, siempre que se cumplan sus condiciones. Las diferentes escalas permiten elegir entre menor costo de inferencia y mayor capacidad para tareas complejas.
Pero conviene mantener una expectativa realista. Que un modelo pueda utilizar una terminal o una herramienta no significa que sea autónomo e infalible. Los agentes necesitan permisos limitados, entornos aislados, registros de actividad y validaciones antes de ejecutar acciones importantes.
La idea más interesante de Granite 4.2 no es que una IA simplemente responda mejor. Es que IBM entrenó parte de la familia para completar tareas verificables dentro de sistemas reales. El salto práctico aparece cuando el modelo deja de ser solo una interfaz conversacional y empieza a funcionar como una pieza operativa dentro de un flujo de trabajo.