Granite 4.1: arquitectura, entrenamiento y benchmarks

Granite 4.1 es la nueva familia de LLMs densos de IBM (3B, 8B y 30B) entrenados en ~15T tokens con un pipeline de preentrenamiento en cinco fases y extensión de contexto hasta 512K tokens. Lo interesante: un modelo denso de 8B iguala o supera a un MoE de 32B en muchos benchmarks, y todo se publica bajo Apache 2.0.

Qué es Granite 4.1 y por qué importa

¿Para qué sirve este avance? Granite 4.1 demuestra que la calidad del entrenamiento y la estrategia de datos pueden compensar el tamaño del modelo. En vez de solo escalar parámetros, el equipo priorizó mezclas de datos progresivamente más curadas, fine-tuning supervisado riguroso y una pipeline de RL por etapas.

Esto importa si eres ingeniero que busca modelos eficientes para producción, emprendedor que quiere desplegar asistentes con herramientas o investigador que estudia alternativas a MoE costosas.

Diseño y arquitectura (resumen técnico)

Granite 4.1 usa un transformador decoder-only denso con estas decisiones de diseño clave:

• Grouped Query Attention (GQA)
• Rotary Position Embeddings (RoPE)
• Activación SwiGLU
• Normalización RMSNorm
• Embeddings compartidos entrada/salida

Dimensiones principales por variante:

• 3B: 40 capas, embedding 2560, MLP 8192
• 8B: 40 capas, embedding 4096, MLP 12800
• 30B: 64 capas, embedding 4096, MLP 32768

Todas las variantes comparten el mismo pipeline de entrenamiento y estrategia de datos; solo cambian las dimensiones internas.

Pipeline de preentrenamiento en 5 fases

Entrenaron desde cero en ~15T tokens usando cinco fases:

1. Fase 1 - Fundacional: mezcla amplia (CommonCrawl dominante), power LR schedule y warmup.

   • Data: CommonCrawl ~59%, Código ~20%, Math ~7%, Técnico ~10.5%, Multilingue ~2%, Domain ~1.5%.

2. Fase 2 - Giro hacia razonamiento y código: más math y code para mejorar capacidades de razonamiento.

   • Data: Math ~35%, Code ~30%, CC-HQ ~12%, Synthetic ~9%, Technical ~10%, Multilingual ~3%.

3. Fase 3 - Mid-training inicial: más datos de alta calidad, cadenas de razonamiento largas y datos instructivos sintéticos.

   • Data balanceada: CommonCrawl-HQ, Math, Code, Long Chain-of-Thought, Language & Code Instructions, etc.

4. Fase 4 - Mid-training final: decay lineal del LR hacia cero y foco en datos de máxima calidad.

   • Data: CommonCrawl-HQ ~40%, Code ~20%, Math ~20%, instrucciones y CoT presentes.

5. Fase 5 - Long-context extension (LCE): extensión gradual del contexto de 4K hasta 512K.

   • Etapas: 32K, 128K y 512K. Para 512K (8B y 30B) la mezcla fue ~80% libros + 20% repositorios de código.
   • Después de cada LCE se hace un model merge para mantener el rendimiento en contextos cortos.

Objetivo: que el modelo atienda secuencias muy largas sin sacrificar las ventanas cortas.

Fine-tuning supervisado y LLM-as-Judge

El SFT se hizo sobre ~4.1M de muestras curadas. Para asegurar calidad aplicaron un juez automatizado (LLM-as-Judge) que evalúa solo las respuestas del asistente sobre múltiples dimensiones: seguimiento de la instrucción, corrección, completitud, concisión, naturalidad y calibración.

También implementaron reglas deterministas para normalización, validación de esquemas, detección de fugas y deduplicación global. El pipeline marca muestras como accept/borderline/reject, y usa hard-reject para defectos graves (alucinaciones, premisas falsas, cálculos incorrectos).

Configuración SFT (aplicable a los tres modelos):

• Compute: 16 nodos, 4x GB200 por nodo
• Epochs: 3
• LR: 5e-6 (warmup 3%, decay lineal ~25K steps)
• Secuencia: 16,384 tokens
• Samples totales: ~4.1M
• Batch efectivo: 256 samples/iter (~4.2M tokens/iter)

Reinforcement learning por etapas (técnico)

En lugar de una sola pasada de RL, Granite 4.1 aplica múltiples etapas enfocadas:

• Algoritmo: On-policy GRPO con DAPO loss (se desactiva el muestreo dinámico en entrenamiento por coste)
• Stack: SkyRL
• Samples por prompt: 16
• Train batch size: 1024
• Context length en RL: 8192

Etapas RL descritas:

1. Multi-domain RL: evita el forgetting entrenando sobre una mezcla diversa (math, ciencia, lógica, IF, Text2SQL, chat, etc.). LR eficaz: 5e-7, KL coef beta=0.05.
2. RLHF / chat multicultural: mejora ayuda y chat usando reward model multilingue; mejora Alpaca-Eval en ~18.9 puntos promedio.
3. Identity & Knowledge calibration: pocos pasos (p. ej. ~40) para mejorar autodescripción y calibración.
4. Math RL: recupera y supera la caída en benchmarks matemáticos causada por etapas anteriores.

Las tasas de aprendizaje y coeficientes KL se ajustan conservadoramente entre etapas para evitar deriva de política.

Rendimiento y benchmarks clave

Granite 4.1 muestra escalado predecible con tamaño, y el 8B denso obtiene resultados sorprendentes frente a la generación anterior MoE 32B-A9B.

Algunos resultados destacados (resumen):

• RULER long-context scores (ejemplo): 8B base 32K=83.6, 64K=79.1, 128K=73.0.
• MMLU 5-shot: 3B=66.47, 8B=73.60, 30B=78.44.
• GSM8K (math): 3B=72.93, 8B=73.54, 30B=83.78.
• HumanEval pass@1 (StarCoder eval): 3B=76.19, 8B=79.24, 30B=81.52.
• AlpacaEval 2.0 (alineamiento): 3B=38.57, 8B=50.08, 30B=56.16.

Conclusión práctica: el 8B denso compite con modelos mucho más grandes en muchas tareas de razonamiento, código y alineamiento.

Cuantización, despliegue y ejemplo rápido

Publicaron variantes cuantizadas en fp8 optimizadas para vLLM, reduciendo ~50% el footprint en disco y memoria GPU. La cuantización se aplica solo a pesos y activaciones de operadores lineales con LLM Compressor, manteniendo otras capas en precisión original.

Ejemplo mínimo para cargar el modelo instruct 30B (adaptado):

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

device = "cuda"
model_path = "ibm-granite/granite-4.1-30b"
tokenizer = AutoTokenizer.from_pretrained(model_path)
model = AutoModelForCausalLM.from_pretrained(model_path, device_map=device)
model.eval()

# ejemplo de definición de herramientas (tool-calling)
tools = [{
  "type": "function",
  "function": {
    "name": "get_current_weather",
    "description": "Get the current weather for a specified city.",
    "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]}
  }
}]

chat = [{"role": "user", "content": "What's the weather like in London right now?"}]
chat = tokenizer.apply_chat_template(chat, tokenize=False, tools=tools, add_generation_prompt=True)
input_tokens = tokenizer(chat, return_tensors="pt").to(device)
output = model.generate(**input_tokens, max_new_tokens=100)
print(tokenizer.batch_decode(output)[0])

Este flujo muestra cómo Granite 4.1 integra tool-calling de forma práctica para asistentes de producción.

Infraestructura y licencia

Entrenamiento en cluster NVIDIA GB200 NVL72 (CoreWeave), con dominios NVLink intra-rack y red NDR 400 Gb/s InfiniBand inter-rack. El entrenamiento a gran escala reclama banda y sincronía para manejar 15T+ tokens.

Granite 4.1 se publica bajo Apache 2.0, lo que facilita su adopción en investigación y empresas.

¿Cuándo usar Granite 4.1?

• Si necesitas un modelo open source eficaz para producción con restricciones de latencia y costo, el 8B denso es una opción poderosa.
• Si trabajas con documentos muy largos, la extensión de contexto hasta 512K es un punto diferenciador real.
• Si te preocupa la calidad de respuestas, el pipeline SFT + LLM-as-Judge y las etapas RL muestran un compromiso serio con la seguridad y la calibración.

Granite 4.1 no es magia: es ingeniería de datos, etapas de entrenamiento bien diseñadas y decisiones arquitectónicas pragmáticas. ¿Quieres un modelo que rinda en la práctica y sea fácil de desplegar? Este es un ejemplo claro de que la mezcla adecuada de datos y etapas puede ganar terreno frente a la pura escala de parámetros.