IBM revela cómo construyó Granite 4.1: 15 billones de tokens, contexto de 512K y apuesta por calidad

El 29 de abril de 2026, IBM publicó un análisis detallado en el blog de Hugging Face sobre cómo se creó la familia Granite 4.1. La empresa reveló no solo la arquitectura de los modelos, sino todo el pipeline: desde la composición de los conjuntos de datos y contexto largo hasta el filtrado de datos SFT y el aprendizaje por refuerzo multietapa.

Cómo se Estructura la Serie Granite 4.1

Granite 4.1 es una familia de modelos densos solo-decoder con 3B, 8B y 30B parámetros. En los tres variantes, IBM utiliza la misma lógica básica: Grouped Query Attention, Rotary Position Embeddings, SwiGLU, RMSNorm e incrustaciones compartidas de entrada y salida.

La principal diferencia es la escala — número de capas, tamaño del estado oculto y parámetros MLP. Este enfoque permite comparar modelos dentro de la misma línea sin descuentos por filosofía arquitectónica diferente. La tesis principal de IBM es que la calidad de un modelo pequeño se determina no solo por el presupuesto computacional, sino también por la disciplina en el trabajo con datos.

Por lo tanto, Granite 4.1 se construyó como modelos densos en lugar de MoE, y se apostó por cambios cuidadosos en las mezclas de datos durante el entrenamiento. Todos los modelos se lanzan bajo licencia Apache 2.

0, y las versiones instruct soportan 12 idiomas, incluyendo inglés, alemán, español, japonés, árabe, chino y portugués.

Cinco Etapas de Entrenamiento

El preentrenamiento de Granite 4.1 comenzó desde cero y cubrió aproximadamente 15 billones de tokens. IBM dividió el proceso en cinco fases: primero el modelo construye una base de lenguaje amplia en datos web, luego fortalece matemáticas y código, después de lo cual gradualmente transita a muestras de mayor calidad y especializadas. En fases posteriores, se añaden trayectorias de razonamiento largo, datos sintéticos y conjuntos de instrucciones a la mezcla, y finalmente se realiza entrenamiento separado para manejar contexto muy largo.

• Fase 1: 10 billones de tokens de preentrenamiento general, donde aproximadamente el 59% de la mezcla proviene de CommonCrawl.
• Fase 2: otros 2 billones de tokens con aumento abrupto en la proporción de matemáticas y código — hasta 35% y 30% respectivamente.
• Fase 3: 2 billones de tokens de recocido de alta calidad, donde aparecen chain-of-thought, datos sintéticos y de instrucciones.
• Fase 4: otros 0,5 billones de tokens con énfasis en la mezcla de mayor calidad y reducción de la tasa de aprendizaje a cero.
• Fase 5: extensión de contexto largo, que expande la ventana de 4K a 32K, 128K y luego a 512K.

Para evitar que el contexto largo quiebre el rendimiento en consultas cortas, IBM fusiona el modelo después de cada etapa LCE. Para la expansión final a 512K en las versiones 8B y 30B, se utilizó una mezcla de libros y repositorios de código. En modelos base esto produjo resultados notables en RULER: la variante 8B mantiene métricas altas incluso a 128K, y 30B va aún más alto. Esta es una señal importante para equipos que necesitan no solo respuestas de chat, sino también trabajar con documentos largos, logs y grandes fragmentos de código.

Ajuste Fino y Calidad

Después del preentrenamiento, IBM ejecutó el conjunto de datos SFT a través de un riguroso bucle de control de calidad. Alrededor de 4,1 millones de ejemplos llegaron a la selección final, pero antes cada respuesta fue verificada a través de un esquema LLM-as-Judge y un conjunto de reglas determinísticas. El modelo evaluador examinó el seguimiento de instrucciones, corrección, completitud, brevedad, naturalidad y calibración, mientras que las razones estrictas para rechazar incluían alucinaciones, premisas falsas y errores computacionales.

Además, se aplicaron normalización, validación de esquema, filtros de longitud y deduplicación global. En la etapa RL, IBM no se limitó a una sola pasada. La empresa utilizó GRPO on-policy con DAPO loss y recopiló cuatro etapas secuenciales: RL multidominio, RLHF para utilidad general y diálogo, RL de identidad y calibración de conocimiento, y luego RL de matemáticas separado, que restaura y mejora habilidades matemáticas después de RLHF.

Según IBM, RLHF por sí solo añadió un promedio de aproximadamente 18,9 puntos en AlpacaEval relativo a puntos de control SFT. El resultado más notable es que el modelo instruct Granite 4.1 8B se compara consistentemente con Granite 4.

0-H-Small 32B-A9B y lo supera en varios benchmarks. En paralelo, IBM lanzó variantes FP8, que reducen aproximadamente a la mitad los requisitos de memoria y espacio en disco.

Qué Significa Esto

IBM demostró que competir en LLMs de código abierto es posible no solo a través del tamaño del modelo, sino a través de la calidad de la receta de entrenamiento. Para empresas, esto hace que Granite 4.1 sea un candidato práctico: latencia predecible sin trazas de razonamiento largo, contexto largo, licencia abierta y costos de ejecución más bajos en comparación con sistemas más pesados.