IBM Granite 4.2 Reasoning Models: How They Were Trained

Authors: Granite Team, IBM

Overview

Granite 4.2 is IBM's first family of dense, decoder-only reasoning LLMs, released in three sizes: 3B, 8B, and 30B. These models are post-trained from Granite-4.1 base models. The Granite-4.1 base models were pre-trained from scratch on roughly 15T tokens with a five-phase strategy that extends the context window to 512K tokens. They were then supervised fine-tuned on chain-of-thought, reasoning, and agentic-trajectory data, and post-trained with a multi-stage reinforcement learning pipeline. That pipeline includes agentic RL, where the 8B and 30B models learn to act with tools inside real sandboxed environments. Every model has a thinking / non-thinking switch, a low-effort thinking mode that spends a short reasoning budget on easy questions, and native tool calling. All Granite 4.2 models are released under the Apache 2.0 license.

Granite 4.2 is the reasoning-focused release of the Granite language-model family. Earlier Granite releases were strong instruction-following assistants; Granite 4.2 adds explicit reasoning. Every model can produce a chain of thought before its answer and can run in thinking or non-thinking mode depending on how much deliberation a task needs. A low-effort mode falls between the two, spending a short reasoning budget on easy questions.

The three sizes (3B, 8B, and 30B) share the same architectural design and follow the same training pipeline (base model, SFT, then multi-stage RL), each at its own scale. All three are strong reasoners and instruction followers. The clearest capability split shows up in post-training. The 8B and 30B models additionally go through an agentic RL block that teaches 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 (for example, with vLLM), it emits tool calls in the OpenAI function-calling format and plugs into agentic harnesses without extra glue. Granite 4.2 is also supported in SGLang; see the SGLang cookbook for a ready-to-serve recipe.

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

1 / 6 Granite 4.2 LLMs: How — Hugging Face

Architecture

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

Spec	Value
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

The per-size configuration is as follows:

3B Dense: embedding size 2560; 40 layers; attention head size 64; 40 attention heads; 8 KV heads; MLP hidden size 8192; SwiGLU activation; sequence length 131072; RoPE position embedding.
8B Dense: embedding size 4096; 40 layers; attention head size 128; 32 attention heads; 8 KV heads; MLP hidden size 12800; SwiGLU activation; sequence length 131072; RoPE position embedding.
30B Dense: embedding size 4096; 64 layers; attention head size 128; 32 attention heads; 8 KV heads; MLP hidden size 32768; SwiGLU activation; sequence length 131072; RoPE position embedding.

Pre-training

Granite 4.2 models are post-trained from Granite-4.1 base models. Those base models were trained from scratch on approximately 15 trillion tokens using a five-phase training strategy. Phases 1–2 focus on foundational pre-training, phases 3–4 perform mid-training with progressively higher-quality data annealing, and 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.

Supervised Fine-Tuning

Supervised fine-tuning (SFT) 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 IBM's own 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%).

Quality control and deduplication

Multiple stages of quality control are applied before a sample enters the final SFT mixture:

Normalization: Data from different sources is normalized and reformatted into a consistent OpenAI Chat format, making the conversation structure and tool interactions uniform across datasets and scaffolds.
LLM-based judging: GPT-OSS-120B and Gemma 4 are used 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.
Deduplication: Local and global deduplication are both performed. 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.

Shuffling and sharding

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 tokenized using the model's tokenizer and chat template and prepared for large-scale distributed training.

Training configuration

Before launching the final large-scale runs, hyperparameters were tuned 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:

Spec	Value
Compute	32–128 nodes (by model size), 4× Grace/GB200 per node
Sequence length (packed)	131,072 (128K)
Global batch size	128
Learning rate	1.0e-5, constant after warm-up; 3.0e-6 for Phase 2
LR warm-up	2.5% of `train_iters`
Training duration	~2 epochs
Parallelism	TP=2, PP=1, CP=4 or CP=2

Second SFT phase for the 30B model

For the 30B model, a second phase of SFT focuses 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.

Multi-Stage Reinforcement Learning

After SFT, the team applies a multi-stage, multi-environment reinforcement learning pipeline. Rather than a single RL pass, it runs 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.

Asynchronous GRPO

Every stage trains with asynchronous GRPO, 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. Once the buffer holds a full step's worth, the trainer pulls that batch, takes an optimizer step, and streams the updated parameters back to the generator workers without pausing them.

A refresh can land partway through a rollout, leaving a single trajectory stitched together from two adjacent policy versions. The team allows this instead of paying to prevent it: the workers reuse their existing KV cache rather than rebuilding it after each refresh, and the one guardrail is a limit that keeps them from drifting more than a single update behind the trainer, which bounds how off-policy any sample can get. Whatever mismatch survives that limit is handled in the objective by truncated importance sampling, which clamps the train-versus-generation log-probability ratio to a fixed ceiling so a handful of stale tokens cannot dominate an update.

Advantages are group-relative with a leave-one-out baseline: each response is judged against the mean reward of the other samples drawn for the same prompt, which removes the need for a separate value network. To make this concrete, take RLVR, the first and longest-running stage: each step pairs 256 prompts with 16 sampled responses apiece for a 4,096-example batch, which the trainer consumes in a single optimizer step before the next rollout begins. Later stages keep this machinery unchanged and adjust only the per-stage shape.

Shared settings

The pipeline keeps a common backbone of hyperparameters across every stage, which makes the curriculum easier to run and compare:

Spec	Value
Algorithm	GRPO (no value network; group-relative advantages)
Training stack	NeMo-RL (Megatron-Core + vLLM) with NeMo-Gym environments
Ratio clip (min / max)	0.2 / 0.28
Micro-batch size	1
Parallelism	tensor-parallel 2–4; no pipeline- or context-parallelism

Per-stage shape (30B chain)

What changes from stage to stage is the shape of each run: how many prompts and generations per step, how long the context is, whether the agent loop runs, and how hard the run pulls back toward the reference policy. The exact settings for the 30B chain, stage by stage, are:

RLVR (×3): 256 prompts/step; 16 generations/prompt; max sequence length 64K; 1 rollout turn; KL 0; LR 5e-7
IF booster: 256 prompts/step; 16 generations/prompt; max sequence length 64K; 1 rollout turn; KL 0; LR 5e-7
Code booster: 64 prompts/step; 16 generations/prompt; max sequence length 64K; 1 rollout turn; KL 0.05; LR 5e-7
SWE 1: 64 prompts/step; 16 generations/prompt; max sequence length 128K; 1 rollout turn; KL 0.01; LR 5e-7
SWE 2: 32 prompts/step; 16 generations/prompt; max sequence length 128K; 128 rollout turns; KL 0; LR 5e-7
Terminal: 8 prompts/step; 32 generations/prompt; max sequence length 64K; 64 rollout turns; KL 0.01; LR 1e-6
Search: 32 prompts/step; 16 generations/prompt; max sequence length 128K; 64 rollout turns; KL 0.01; LR 5e-7
RLHF: 128 prompts/step; 16 generations/prompt; max sequence length 48K; 1 rollout turn; KL 0.05; LR 5e-7

Takeaways

Start from a strong base: Granite 4.2 is post-trained from Granite-4.1 base models, with SFT on a mix of agentic and non-agentic data before RL.
**Use group-rel