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:
-
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%.
-
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%.
-
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.
-
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.
-
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:
- 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.
- RLHF / chat multicultural: mejora ayuda y chat usando reward model multilingue; mejora Alpaca-Eval en ~18.9 puntos promedio.
- Identity & Knowledge calibration: pocos pasos (p. ej. ~40) para mejorar autodescripción y calibración.
- 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.