Granite 4.1: como a IBM treinou a família de LLMs densos de 3B, 8B e 30B

A IBM soltou o walkthrough técnico completo do Granite 4.1, família de LLMs densos decoder-only em três tamanhos (3B, 8B e 30B), treinada do zero em aproximadamente 15 trilhões de tokens. Tudo sob licença Apache 2.0, disponível na coleção Granite 4.1 no Hugging Face.

O ponto que mais chama atenção: o modelo 8B denso bate ou supera o Granite 4.0-H-Small da geração anterior, que era um MoE (Mixture of Experts) de 32B com 9B parâmetros ativos. Arquitetura mais simples, menos parâmetros, mesmo resultado.

Arquitetura

Decoder-only dense transformer, com escolhas de design padrão da geração atual: GQA (Grouped Query Attention), RoPE (Rotary Position Embeddings), ativação SwiGLU, RMSNorm e embeddings de input/output compartilhados.

Dimensões dos três modelos:

Os três tamanhos compartilham o mesmo pipeline de treino e estratégia de dados. Só mudam as dimensões.

Pré-treino em cinco fases

A IBM dividiu o pré-treino em cinco etapas, com mistura de dados e schedule de learning rate distintos em cada uma. A ideia é ir do volume bruto pro curado, e fechar com extensão de contexto longo.

Fase 1: pré-treino geral (10T tokens) com mix dominado por web (~59% CommonCrawl), 20% código, 10,5% técnico, 7% matemática, 2% multilíngue e 1,5% domínio específico.

Fase 2: pré-treino math/code (2T tokens). Aqui matemática salta pra ~35% (5x da fase 1) e código pra ~30% (1,5x). Foco em capacidade de raciocínio.

Fase 3: annealing de dados de alta qualidade (2T tokens). Mix mais balanceado, learning rate em decay exponencial. É onde entram chain-of-thought longo (~12,5%) e dados de instrução.

Fase 4: refinamento (0,5T tokens). Decay linear a zero, foco nos dados de qualidade mais alta: 40% CommonCrawl-HQ, 20% código, 20% matemática.

Fase 5: long context extension (LCE). Estende a janela de 4K pra 512K em três etapas (32K → 128K → 512K). A última usa 80% livros + 20% repos de código (só 8B e 30B). Pra não derrubar performance em contexto curto, fazem model merge depois de cada etapa.

No benchmark RULER, o 30B-base mantém 76,7 em 128K e 85,2 em 32K. O 8B-base sai de 83,6 em 32K pra 73,0 em 128K.

Vale o filtro: 512K de contexto nominal não significa 512K útil. RULER em 128K já mostra queda de ~10 pontos no 8B. Quem tá pensando em RAG (Retrieval-Augmented Generation) com janela cheia, roda benchmark do seu caso antes.

SFT: LLM-as-Judge filtrando 4,1M amostras

O supervised fine-tuning rodou em ~4,1M amostras curadas. O pipeline combina LLM-as-Judge (modelo julgando outras respostas) com filtros baseados em regra.

O juiz avalia só a resposta do assistant, tratando system prompt, input do usuário, documentos retrieved e output de tools como contexto. Cada resposta pontua em seis dimensões: instruction following, correctness, completeness, conciseness, naturalness e calibration. Hard-reject pra alucinação, premissa falsa ou cálculo errado, independente da nota.

Pra cenários RAG, resposta sem grounding no contexto retrieved é flagada como alucinação. Pra tool-calling, valida contra schema das tools permitidas.

Configuração de treino do SFT:

• 16 nós, 4x GB200 por nó
• 3 epochs
• Learning rate 5e-6 (warmup linear 3%, decay linear ~25K steps)
• Sequência de 16.384 tokens
• Batch efetivo: 256 amostras/iter (~4,2M tokens/iter)

RL multi-estágio: quatro pipelines em sequência

Em vez de um RL único, a IBM rodou quatro etapas sequenciais. O algoritmo é On-policy GRPO com DAPO loss (Yu et al., 2025), usando o stack SkyRL. Dynamic sampling do DAPO foi desligado por custo computacional.

As quatro etapas:

1. Multi-domain RL com 45.504 prompts cobrindo math, science, lógica, instruction following, structured output, Text2SQL, raciocínio temporal, chat geral e in-context learning. Learning rate 5e-7, KL coef 0,05.
2. RLHF em prompts de chat genérico com reward model multilíngue. Ganho médio de ~18,9 pontos em Alpaca-Eval vs checkpoint SFT. Learning rate mais conservador (3e-7), KL coef 0,09.
3. Identity & Knowledge-Calibration RL, ~40 steps em 1.728 prompts. Melhora autoidentificação do modelo.
4. Math RL pra recuperar a queda em benchmarks de matemática causada pelo RLHF. Recupera ~3,8 pontos em GSM8K e ~23,48 em DeepMind-Math.

A ordem importa: a IBM diz que essa sequência minimiza catastrophic forgetting enquanto maximiza performance multi-domínio.

Resultados

Principais números do instruct model:

Línguas suportadas: inglês, alemão, espanhol, francês, japonês, português, árabe, tcheco, italiano, coreano, holandês e chinês.

Quantização FP8 e infra

Variantes FP8 também foram liberadas, otimizadas pra inferência com vLLM. Reduz disk e GPU memory em ~50%, quantizando só weights e activations dos operadores lineares dentro dos blocos transformer (via LLM Compressor). Demais camadas mantém precisão original.

O treino rodou em cluster NVIDIA GB200 NVL72 hospedado na CoreWeave: NVLink intra-rack de 72 GPUs, InfiniBand NDR 400 Gb/s full Fat-Tree non-blocking entre racks, milhares de GPUs no total.

Por que importa

O Granite 4.1 não é modelo de fronteira competindo com GPT-5 ou Claude Opus. É a aposta da IBM no segmento enterprise: previsibilidade de latência, custo operacional baixo, sem chain-of-thought longo inflando token usage, e licença Apache 2.0 sem string anexada.

O ponto técnico mais interessante é o 8B denso batendo o MoE 32B-A9B da geração anterior. Pra quem opera inferência self-hosted, denso é bem mais simples de servir que MoE: menos overhead de routing, sharding mais previsível, vLLM e SGLang lidam melhor. Se a IBM segurar essa qualidade, MoE pequeno vira escolha duvidosa pro segmento enterprise.

Links:

• Coleção Granite 4.1 no Hugging Face
• GitHub ibm-granite/granite-4.1-language-models
• Documentação Granite