Granite 4.2 LLMs: How They’re Built

Disclosure: Some links in this article are affiliate links. AI Maestro may earn a commission if you make a purchase, at no…

By Vane August 25, 2026 5 min read
Granite 4.2 LLMs: How They’re Built


Granite 4.2 LLMs: How They’re Built

Authors: Granite Team, IBM

Granite 4.2 is the first dense, decoder-only reasoning family from IBM, available in 3B, 8B, and 30B variants. Each model starts from scratch on roughly 15 trillion tokens using a five-phase strategy that pushes the context window to 512K. The team then applies supervised fine-tuning on chain-of-thought and agentic-trajectory data before running a multi-stage reinforcement learning pipeline. This includes agentic RL where the 8B and 30B models learn to act with tools inside sandboxed environments. Every model features a thinking or non-thinking switch, a low-effort mode for simple queries, and native tool calling. The release operates under the Apache 2.0 license.

Overview

Granite 4.2 targets reasoning, building on earlier releases that focused on instruction following. Every model can generate a chain of thought before answering and switches between thinking and non-thinking modes based on task needs. A low-effort mode sits between the two, spending a short reasoning budget on easy questions.

The three sizes share the same architectural design and training pipeline, scaled to their respective capacities. The clearest capability split appears in post-training. The 8B and 30B models undergo an additional agentic RL block to teach them to operate as agents: calling tools, editing and running code, driving a terminal, and searching the web inside real environments. Every model supports native tool calling. Served through an OpenAI-compatible endpoint, such as with vLLM, the system emits tool calls in the OpenAI function-calling format and plugs into agentic harnesses without extra code. Granite 4.2 is also supported in SGLang, with a ready-to-serve recipe in the cookbook.

The rest of this post walks through the build: architecture, pre-training, supervised fine-tuning, the multi-stage RL pipeline, and results.

Model Architecture

Granite 4.2 models use a decoder-only dense transformer architecture with the following core components:

  • Attention: Grouped Query Attention (GQA) with 40 attention heads and 8 KV heads
  • Position Embedding: Rotary Position Embedding (RoPE) with θ = 10,000,000
  • Feed-Forward: MLP with SwiGLU activation
  • Normalization: RMSNorm (ε = 1e-5)
  • Embeddings: Separate input/output embeddings (not tied)
  • Precision: bfloat16
Component3B Dense8B Dense30B Dense
Embedding size256040964096
Number of layers404064
Attention head size64128128
Number of attention heads403232
Number of KV heads888
MLP hidden size81921280032768
MLP activationSwiGLUSwiGLUSwiGLU
Sequence length131072131072131072
Position embeddingRoPERoPERoPE
# Parameters3B8B30B

Pre-Training

Granite 4.2 trains from scratch on approximately 15 trillion tokens using a five-phase strategy. Phases 1 and 2 focus on foundational pre-training. Phases 3 and 4 perform mid-training with progressively higher-quality data annealing. Phase 5 introduces long-context training, extending the context window to 512K tokens. Each phase uses a distinct data mixture and learning-rate schedule, gradually shifting from broad web-scale data toward more curated, high-quality sources.

The pre-training recipe closely follows the previous generation. For a detailed treatment of the data blend, phase schedule, and long-context extension, see the Granite 4.1 blog.

SFT: Data Preparation & Quality Control

Supervised fine-tuning turns the base model into a reliable instruction-following, reasoning, and tool-using assistant. The SFT data mixture combines agentic (31.6%) and non-agentic (68.4%) data, totaling approximately 7.2 million samples, or roughly 100B tokens, of which about 65B are trainable.

The agentic corpus covers a broad range of domains, including software engineering (SWE, 69%), tool calling (12.1%), terminal use (8.0%), math (3.5%), search (0.8%), and action (0.2%). These samples and trajectories are generated using a diverse set of agent scaffolds and harnesses, including OpenHands, OpenCode, Terminus-2, SWE-agent, OpenResearcher, MiniSWE, OpenSeeker, EnvScaler, Gemini CLI, Hermes, Codex, and Goose. The agentic data combines samples from both open-source datasets and synthetically generated RL environments, spanning a variety of agent–harness combinations.

The non-agentic corpus consists of several major categories: instruction following (18.8%), coding (18.8%), math (14.6%), multilingual (7.0%), science (5.4%), reasoning (3.0%), and safety (0.8%).

Data Quality Control

We apply multiple stages of quality control before a sample enters the final SFT mixture. First, data from different sources is normalised and reformatted into a consistent OpenAI Chat format, making the conversation structure and tool interactions uniform across datasets and scaffolds.

We then use GPT-OSS-120B and Gemma 4 as LLM-based judges to assess sample quality. Low-scoring samples are removed, as are samples containing hallucinated or fabricated information, invalid tool interactions, or tool calls to functions that are not defined in the corresponding tool list. Several targeted, dataset-specific heuristic rules are also applied where appropriate to further improve quality and remove known sources of noise.

Finally, we perform both local and global deduplication. Deduplication is based on SHA-256 hashes computed over the combination of the

tools

and

messages

fields, removing duplicate samples both within individual data sources and across the overall SFT mixture.

SFT Training Details

The complete corpus is first globally shuffled to reduce ordering effects and ensure that samples from different domains are well mixed during training. The shuffled corpus is then partitioned into equally sized

.parquet

shards, which are tokenised using the model’s tokenizer and chat template and prepared for large-scale distributed training.

Before launching the final large-scale runs, we tune hyperparameters on representative configurations, sweeping learning-rate schedules, initial learning rates, and warm-up ratios to find settings that train stably across model sizes. The final training configuration is summarised below:

ParameterValue
Compute32–128 nodes (by model size), 4× Grace/GB200 per node
Sequence length (packed)131,072 (128K)
Global batch size128
Learning rate1.0e-5, constant after warm-up; 3.0e-6 for Phase 2
LR warm-up2.5% of

train_iters
Training duration~2 epochs
ParallelismTP=2, PP=1, CP=4 or CP=2

Phase 2 SFT for the 30B Model

For the 30B model, we additionally perform a second phase of SFT focused specifically on agentic coding. In this phase, agentic, SWE, and coding data are upsampled to increase their effective contribution to the training distribution, while approximately 16% of the mixture is retained as replay data from the original SFT corpus.

The 30B model is then fine-tuned for roughly one additional epoch at a lower learning rate of 3.0e-6. This targeted second phase increases the model’s exposure to agentic coding trajectories without discarding the capabilities acquired during the initial SFT phase.

Reinforcement Learning: A Multi-Stage, Multi-Environment Pipeline

After SFT, we apply a multi-stage, multi-environment reinforcement learning pipeline. Rather than a single RL pass, we run a chain of focused stages spanning many environments: math, code, science, instruction following, tool use, and structured output, then software engineering, terminal use, and web search. Each stage is an independent RL run that targets one capability and warm-starts from the previous stage’s checkpoint.

Figure 1. The staged RL curriculum. Foundational RL (verifiable rewards + skill boosters) runs for all sizes; the agentic RL block (SWE → Terminal → Search) runs for 8B and 30B only. Every model finishes with RLHF. Each stage is a separate GRPO run that warm-starts from the previous checkpoint.

Training Methodology

Every stage trains with asynchronous GRPO (Group Relative Policy Optimization), so the generator and trainer halves of the loop never block on each other. A pool of generation workers keeps sampling responses and dropping the finished trajectories into a shared buffer

Scroll to Top