Granite 4.1: así se diseñaron y entrenaron los nuevos LLMs

Introducción

Granite 4.1 es una familia de modelos de lenguaje densos y decoder‑only disponible en tamaños de 3B, 8B y 30B parámetros. Entrenados desde cero con aproximadamente 15 billones (15T) de tokens, estos modelos combinan un pipeline de preentrenamiento en cinco fases, un ajuste supervisado curado y una etapa de aprendizaje por refuerzo on‑policy para afinar comportamiento en tareas de razonamiento, programación, instrucciones y chat. Todos los modelos se publicaron bajo licencia Apache 2.0.

Para equipos y tomadores de decisión en América Latina, Granite 4.1 muestra que la calidad de los datos y la estrategia de entrenamiento pueden permitir que un modelo denso relativamente pequeño (por ejemplo, 8B) iguale o supere a arquitecturas más grandes y complejas basadas en MoE, lo que tiene implicaciones para costo, despliegue y cumplimiento local.

Arquitectura y diseño

Los modelos Granite 4.1 emplean una arquitectura transformer decoder‑only densa con decisiones de diseño enfocadas en eficiencia y capacidad de razonamiento. Las técnicas clave incluyen:

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

Aunque comparten el mismo pipeline de entrenamiento y estrategia de datos, las tres variantes difieren en las dimensiones internas:

• Granite 4.1‑3B: embedding size 2560, 40 capas, 40 attention heads, attention head size 64, 8 KV heads, MLP hidden size 8192.
• Granite 4.1‑8B: embedding size 4096, 40 capas, 32 attention heads, attention head size 128, 8 KV heads, MLP hidden size 12800.
• Granite 4.1‑30B: embedding size 4096, 64 capas, 32 attention heads, attention head size 128, 8 KV heads, MLP hidden size 32768.

Estas configuraciones muestran un equilibrio entre profundidad y ancho según el tamaño del modelo, manteniendo una base arquitectónica uniforme para beneficiarse del mismo pipeline de datos y ajuste.

Preentrenamiento en cinco fases

El preentrenamiento se diseñó como un proceso escalonado, priorizando la calidad de los datos con una mezcla que evoluciona a lo largo de cinco fases y con distintos esquemas de tasa de aprendizaje.

Fase 1 — Preentrenamiento general (≈10T tokens)

• Objetivo: establecer comprensión amplia del lenguaje.
• Composición de datos aproximada: CommonCrawl ~59%, Code ~20%, Math ~7%, Technical ~10.5%, Multilingual ~2%, Domain ~1.5%.
• Aprendizaje con schedule tipo power y warmup.

Fase 2 — Preentrenamiento enfocado en math/code (≈2T tokens)

• Objetivo: reforzar razonamiento matemático y capacidades de programación.
• Composición (ejemplos): Math ~35% (5× respecto a fase 1), Code ~30% (1.5×), CommonCrawl‑HQ ~12%, Synthetic ~9%, Technical ~10%, Multilingual ~3%, Domain ~1%.

Fase 3 — Mid‑training con annealing de datos de alta calidad (≈2T tokens)

• Introduce mezclas más equilibradas y datos de cadena de pensamiento (long chain‑of‑thought) y datos sintéticos de instrucciones.
• Composición aproximada: CommonCrawl‑HQ ~16.7%, Math ~16.7%, Code ~16.7%, Synthetic ~8.5%, Technical ~12.5%, Multilingual ~4.5%, Long Chain‑of‑Thought ~12.5%, Language Instructions ~7.5%, Code Instructions ~4.5%.

Fase 4 — Refinamiento de alta calidad (≈0.5T tokens)

• Objetivo: concentrarse en los datos de mayor calidad con decay lineal de la tasa de aprendizaje.
• Composición: CommonCrawl‑HQ ~40%, Code ~20%, Math ~20%, Long Chain‑of‑Thought ~6%, Code Instructions ~5%, Language Instructions ~9%.

Fase 5 — Long Context Training (LCE)

• Extiende la ventana de contexto hasta 512K tokens mediante una progresión por etapas: primero 32K, luego 128K y finalmente 512K (esta última etapa aplicada a los modelos 8B y 30B).
• Las etapas 32K y 128K usan la mezcla de la fase 4; la etapa 512K utiliza aproximadamente 80% libros y 20% repositorios de código (solo 8B y 30B).
• Se aplican schedules exponenciales de tasa de aprendizaje y se realizan fusiones de modelo tras cada etapa para preservar el rendimiento en contextos cortos.

Rendimiento en contexto largo

Los modelos base fueron evaluados en el benchmark RULER para ventanas largas. Resultados reportados (porcentajes de referencia):

• granite‑4.1‑3b‑base: 32K = 75.0, 64K = 66.6, 128K = 58.0
• granite‑4.1‑8b‑base: 32K = 83.6, 64K = 79.1, 128K = 73.0
• granite‑4.1‑30b‑base: 32K = 85.2, 64K = 84.6, 128K = 76.7

Estos números muestran cómo el rendimiento en tareas de contexto largo mejora con el tamaño del modelo y con la etapa específica de LCE.

Ajuste supervisado y control de calidad (SFT)

Para convertir el modelo base en asistentes que sigan instrucciones confiables, Granite 4.1 empleó un SFT riguroso. Se utilizaron alrededor de 4.1 millones de muestras curadas de alta calidad. La curación combinó:

• Un framework “LLM‑as‑Judge” para evaluar automáticamente muestras según criterios estructurales, semánticos y de comportamiento.
• Filtrado basado en reglas para eliminar o corregir ejemplos erróneos o con potencial de inducir alucinaciones.

La inversión en calidad de datos durante SFT busca reducir riesgos: incluso unas pocas muestras problemáticas pueden inducir comportamientos indeseados en el modelo.

Aprendizaje por refuerzo (RL)

Tras el SFT, Granite 4.1 se sometió a una fase de RL on‑policy usando GRPO con la pérdida DAPO (Yu et al., 2025). Este pipeline multi‑etapa de RL se diseñó para reforzar capacidades en:

• Matemáticas y razonamiento
• Programación y generación de código
• Seguimiento de instrucciones
• Conversación general y seguridad del diálogo

El uso de RL on‑policy busca optimizar comportamientos más alineados con objetivos humanos y métricas específicas de utilidad.

Prioridad en datos vs. escala

Uno de los hallazgos prácticos de Granite 4.1 es que una estrategia de datos cuidadosamente curada y un pipeline de entrenamiento bien diseñado pueden permitir a un modelo denso de 8B igualar o superar versiones previas más grandes y complejas (por ejemplo, Granite 4.0‑H‑Small, una MoE con 32B y rutas A9B). Esto subraya que, para muchas aplicaciones, la inversión en calidad de datos y afinamiento puede ser más eficiente que simplemente aumentar parámetros.

Implicaciones para América Latina

Para organizaciones en la región, Granite 4.1 ofrece algunas lecciones relevantes:

• Modelos densos de menor tamaño bien entrenados pueden reducir costos de despliegue y requisitos de infraestructura.
• La extensión nativa a contextos muy largos (hasta 512K) abre casos de uso para análisis de documentos extensos, legal o de cumplimiento regulatorio.
• La publicación bajo Apache 2.0 facilita integración comercial y adaptación local, siempre considerando regulaciones de datos y privacidad.

Conclusión

Granite 4.1 demuestra un enfoque integral donde la arquitectura, la estrategia de datos (cinco fases) y etapas cuidadosas de SFT y RL se combinan para generar modelos competentes en razonamiento, código, instrucciones y diálogo, incluyendo soporte para contextos extremadamente largos. Para equipos con restricciones de recursos —una realidad común en la región— esta familia de modelos muestra una alternativa viable a la única vía de escalar parámetros: optimizar datos y procesos de entrenamiento.