IBM revela como construiu Granite 4.1: 15 trilhões de tokens, contexto de 512K e foco na qualidade

Em 29 de abril de 2026, IBM publicou um detalhamento aprofundado no blog do Hugging Face sobre como a família Granite 4.1 foi criada. A empresa revelou não apenas a arquitetura dos modelos, mas também todo o pipeline: desde a composição dos conjuntos de dados e contexto longo até a filtragem de dados SFT e aprendizado por reforço em múltiplos estágios.

Como a Série Granite 4.1 é Estruturada

Granite 4.1 é uma família de modelos dense decoder-only com 3B, 8B e 30B parâmetros. Nos três variantes, IBM usa a mesma lógica básica: Grouped Query Attention, Rotary Position Embeddings, SwiGLU, RMSNorm e embeddings compartilhados de entrada e saída.

A principal diferença é a escala — número de camadas, tamanho do estado oculto e parâmetros MLP. Essa abordagem permite comparar modelos dentro da mesma família sem descontos por filosofia arquitetônica diferente. A tese principal da IBM é que a qualidade de um modelo pequeno é determinada não apenas pelo orçamento computacional, mas também pela disciplina no trabalho com dados.

Portanto, Granite 4.1 foi construído como modelos densos e não MoE, e a aposta foi colocada em mudanças cuidadosas nas misturas de dados durante o treinamento. Todos os modelos são lançados sob licença Apache 2.

0, e versões instruct suportam 12 idiomas, incluindo inglês, alemão, espanhol, japonês, árabe, chinês e português.

Cinco Estágios de Treinamento

O pré-treinamento de Granite 4.1 começou do zero e cobriu aproximadamente 15 trilhões de tokens. IBM dividiu o processo em cinco fases: primeiro o modelo constrói uma base de linguagem ampla em dados da web, depois fortalece matemática e código, após o qual gradualmente faz transição para amostras de maior qualidade e especializadas. Nas fases posteriores, trajetórias de raciocínio longo, dados sintéticos e conjuntos de instrução são adicionados à mistura, e finalmente treinamento separado ocorre para lidar com contexto muito longo.

• Fase 1: 10 trilhões de tokens de pré-treinamento geral, onde cerca de 59% da mistura vem de CommonCrawl.
• Fase 2: outros 2 trilhões de tokens com aumento acentuado na proporção de matemática e código — até 35% e 30% respectivamente.
• Fase 3: 2 trilhões de tokens de annealing de alta qualidade, onde aparecem chain-of-thought, dados sintéticos e de instrução.
• Fase 4: outros 0,5 trilhões de tokens com ênfase na mistura de mais alta qualidade e redução da taxa de aprendizado a zero.
• Fase 5: extensão de contexto longo, que expande a janela de 4K para 32K, 128K e depois para 512K.

Para evitar que contexto longo quebre o desempenho em consultas curtas, IBM mescla o modelo após cada estágio LCE. Para expansão final para 512K nas versões 8B e 30B, foi usada uma mistura de livros e repositórios de código. Em modelos base isso deu resultados notáveis no RULER: a variante 8B mantém métricas altas até 128K, e 30B vai ainda mais alto. Este é um sinal importante para equipes que precisam não apenas de respostas de chat, mas também de trabalho com documentos longos, logs e grandes fragmentos de código.

Ajuste Fine-tuning e Qualidade

Após pré-treinamento, IBM executou o conjunto de dados SFT através de um rigoroso loop de controle de qualidade. Cerca de 4,1 milhões de exemplos chegaram à seleção final, mas antes cada resposta foi verificada através de um esquema LLM-as-Judge e um conjunto de regras determinísticas. O modelo avaliador analisou seguimento de instruções, correção, completude, brevidade, naturalidade e calibração, enquanto razões estritas de rejeição incluíram alucinações, premissas falsas e erros computacionais.

Adicionalmente, normalização, validação de schema, filtros de comprimento e desduplicação global foram aplicados. No estágio RL, IBM não se limitou a um único passe. A empresa usou GRPO on-policy com DAPO loss e coletou quatro estágios sequenciais: RL multi-domínio, RLHF para utilidade geral e diálogo, RL de identidade e calibração de conhecimento, e então RL de matemática separado, que restaura e melhora habilidades matemáticas após RLHF.

De acordo com IBM, RLHF sozinho adicionou uma média de cerca de 18,9 pontos no AlpacaEval relativo aos checkpoints SFT. O resultado mais notável é que o modelo instruct Granite 4.1 8B se compara consistentemente a Granite 4.

0-H-Small 32B-A9B e o supera em vários benchmarks. Em paralelo, IBM lançou variantes FP8, que reduzem aproximadamente pela metade os requisitos de memória e espaço em disco.

O Que Isso Significa

IBM demonstrou que competir em LLMs de código aberto é possível não apenas através do tamanho do modelo, mas através da qualidade da receita de treinamento. Para empresas, isso torna Granite 4.1 um candidato prático: latência previsível sem traços de raciocínio longo, contexto longo, licença aberta e custos de execução mais baixos em comparação com sistemas mais pesados.