Granite 4.1: arquitectura, entrenamiento y benchmarks | Keryc
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.
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).
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.
