INTELLECT-3: Technical Report

🍞 Top Bread (Hook): Imagine training a soccer team. If you only ever practice passing drills (supervised learning), you’ll get tidy passes—but you might still lose the match because you never practiced game-time choices (reinforcement learning).

🥬 Filling (The Actual Concept): Reinforcement Learning (RL) is how models learn by trying things, getting feedback (rewards), and getting better at long, multi-step tasks.

• What it is: A training style where the model explores actions and learns from reward signals instead of just copying answers.
• How it works:
  1. Give the model a goal (solve a problem, fix code, find info).
  2. Let it try actions (think, call tools, write code, click links).
  3. Score the result with a reward (right/wrong, better/worse, faster/slower).
  4. Adjust the model to make rewarded choices more likely.
• Why it matters: Without RL, models can chat nicely but struggle with long, tool-using, multi-step reasoning.

🍞 Bottom Bread (Anchor): When a model learns to debug code by actually running tests and seeing pass/fail, that’s RL in action.

🍞 Top Bread (Hook): You know how big projects have many specialists—like a designer, a coder, and a tester—so each part is done by the best person for the job?

🥬 Filling (The Actual Concept): Mixture-of-Experts (MoE) models split the brain into many mini-experts and pick the best few for each token.

• What it is: A model with many expert layers where a gate routes each token to a small subset of experts.
• How it works:
  1. A gate looks at the current token and context.
  2. It selects a few experts (like 2 out of dozens) to process it.
  3. Their outputs are combined into the next representation.
• Why it matters: You get the power of a huge model with the speed of a smaller one, because only a few experts are active at a time.

🍞 Bottom Bread (Anchor): INTELLECT-3 is 106B total parameters but only about 12B are active at once, so it’s both strong and efficient.

🍞 Top Bread (Hook): Imagine trying to organize a whole school play by yourself—writing, acting, and managing lights. It’s easier if roles are clear and connected.

🥬 Filling (The Actual Concept): End-to-end training means all the parts—data generation, scoring, training, and evaluating—fit together in one smooth pipeline.

• What it is: A single, connected process from inputs to trained outputs with consistent tools and formats.
• How it works:
  1. Generate attempts (rollouts) from the model.
  2. Score them reliably with verifiers (automatic checkers).
  3. Update the model based on rewards.
  4. Evaluate in the same environments for honesty and reproducibility.
• Why it matters: Without end-to-end alignment, you get brittle systems, mismatched formats, and results that are hard to trust or reproduce.

🍞 Bottom Bread (Anchor): The same verifiers used during training also run evaluations, so scores mean the same thing across experiments.

🍞 Top Bread (Hook): Think of a busy kitchen: one cook chops veggies while another stir-fries—no one stands around waiting.

🥬 Filling (The Actual Concept): Asynchronous off-policy training lets inference (generating attempts) and training (updating weights) run at the same time, even if the data was produced by slightly older weights.

• What it is: A way to overlap work so GPUs stay busy and learning doesn’t stall.
• How it works:
  1. Inference servers keep generating rollouts using recent weights.
  2. Trainers update weights in parallel.
  3. Careful safeguards limit how old the policy can be (off-policyness).
• Why it matters: Without this, long generations would cause expensive idle time and slow learning.

🍞 Bottom Bread (Anchor): While one batch of math problems is being generated, the trainer is already learning from the previous batch.

🍞 Top Bread (Hook): Picture a conveyor belt that never stops—finished items slide off while new ones hop on.

🥬 Filling (The Actual Concept): Continuous batching means we don’t wait for the slowest rollout; we keep adding new ones to maintain maximum throughput.

• What it is: A rolling queue of requests that keeps inference fully utilized.
• How it works:
  1. Start many rollouts at once.
  2. As any finish, refill their slots immediately.
  3. Always keep the pool saturated so GPUs never idle.
• Why it matters: Without it, the slowest item would delay everything and waste compute.

🍞 Bottom Bread (Anchor): If one coding task takes longer, the system doesn’t pause—new tasks start right away.

🍞 Top Bread (Hook): Adjusting a bike’s seat while riding is tricky—but a little tweak can help you go faster immediately.

🥬 Filling (The Actual Concept): In-flight weight updates send new weights to inference servers mid-generation to use the freshest model.

• What it is: Updating the policy on running servers without a full stop.
• How it works:
  1. Trainer finishes an update.
  2. Orchestrator pushes new weights to inference nodes.
  3. Generation resumes, possibly with different policies within one long trajectory (safeguarded by limits).
• Why it matters: Without it, the model keeps using stale skills and learning lags.

🍞 Bottom Bread (Anchor): A research agent searching the web can switch to a sharper policy halfway through a long session.

🍞 Top Bread (Hook): A fair teacher gives you problems that are not too easy or too hard—just right to help you grow.

🥬 Filling (The Actual Concept): Online data filtering keeps the challenge level appropriate during training.

• What it is: Real-time selection of tasks by observed difficulty.
• How it works:
  1. Track solve rates to label problems as easy/normal/hard.
  2. Sample more from the zones that teach best.
  3. Drop items that are always solved or always failed.
• Why it matters: Without it, the model wastes time and learns less from each step.

🍞 Bottom Bread (Anchor): If the model aces certain math problems, those stop being served so it can focus on trickier ones.

🍞 Top Bread (Hook): When a novel is super long, friends can split chapters to finish faster.

🥬 Filling (The Actual Concept): Context parallelism splits very long sequences across GPUs so memory fits and training continues.

• What it is: Partitioning attention computation over devices.
• How it works:
  1. Slice the sequence or attention among GPUs.
  2. Communicate partial results (e.g., ring attention) to get the full effect.
  3. Reassemble outputs for the next layers.
• Why it matters: Without it, memory runs out at long context lengths.

🍞 Bottom Bread (Anchor): This helped experiments reach up to 256k context in trials (though the production setting preferred other tradeoffs).

🍞 Top Bread (Hook): If your backpack is too heavy, you can store some books in a locker and grab them when needed.

🥬 Filling (The Actual Concept): Activation offloading moves saved layer outputs to CPU RAM so GPUs don’t run out of memory.

• What it is: Parking activations off-GPU with minimal slowdown.
• How it works:
  1. Use activation checkpointing to save only key points.
  2. Offload activations to CPU.
  3. Recompute or fetch them during backpropagation.
• Why it matters: Without it, long contexts (48k–72k+) would exceed GPU memory.

🍞 Bottom Bread (Anchor): This enabled 72k-token training on the same GPUs with negligible performance loss.

🍞 Top Bread (Hook): A science fair needs reliable judges to score projects fairly and consistently.

🥬 Filling (The Actual Concept): Verifiers are standardized environments that generate tasks, orchestrate tool calls, and score answers.

• What it is: A library and interface to build, share, and run RL tasks and evaluations.
• How it works:
  1. Each environment defines prompts, tools, and a rubric (scoring).
  2. Rollouts run asynchronously at scale.
  3. Rewards and logs plug directly into training.
• Why it matters: Without consistent scoring, RL signals get noisy and results aren’t reproducible.

🍞 Bottom Bread (Anchor): The same AIME, LiveCodeBench, and GPQA environments used in training are used for final scoring.

🍞 Top Bread (Hook): Running mystery code from the internet safely is like handling chemicals in a fume hood—strong protection is a must.

🥬 Filling (The Actual Concept): Prime Sandboxes are high-throughput, secure containers for executing untrusted code at scale.

• What it is: A fast, isolated execution layer optimized for RL workloads.
• How it works:
  1. A Rust gateway talks directly to pods (bypassing API bottlenecks).
  2. A sidecar agent injects commands quickly and safely.
  3. Image streaming and warm pools make startups instant.
• Why it matters: Without safe, fast code execution, coding RL would be too slow or risky.

🍞 Bottom Bread (Anchor): Thousands of Python solutions are tested in parallel in milliseconds, with failures safely contained.

The world before: Open-source RL for language models existed, but the end-to-end pipeline was fragmented, slow, and hard to extend. Frameworks were monolithic; evaluations weren’t standardized; long-context training stalled; and naive container orchestration made code execution seconds-slow instead of millisecond-fast. The problem: unlock high-throughput, stable RL for reasoning and agentic tool use, then prove it by training a model that competes with much bigger closed systems. Failed attempts included synchronous on-policy loops that underutilized GPUs, Kubernetes API–bound sandboxes with control-plane bottlenecks, and long-context setups that ran out of memory. The gap: a modular, scalable, open stack that keeps the whole system busy, scores fairly, runs code safely, and supports MoE efficiently. Real stakes: better math help, safer code fixes, smarter web research, and more reliable AI assistants—achieved not by just making models bigger, but by training them better.

🍞 Top Bread (Hook): Imagine a relay race where runners hand off the baton smoothly without anyone stopping, and judges on the sidelines call out fair scores in real time.

🥬 Filling (The Actual Concept): The aha! insight is to make the entire RL pipeline asynchronous, standardized, and always-on: keep inference and training overlapping, update weights mid-flight, and use shared, verified environments so learning signals are clean and constant.

• What it is: A tightly integrated, open system (prime-rl + verifiers + Prime Sandboxes) that maximizes throughput and stability while scaling MoE models.
• How it works:
  1. Disaggregate trainer and inference so both run in parallel across many GPUs.
  2. Use continuous batching and in-flight weight updates to avoid stalls.
  3. Standardize tasks and rewards via verifiers and the Environments Hub.
  4. Execute untrusted code safely at scale with Prime Sandboxes.
  5. Make long contexts possible with activation offloading and careful parallelism.
• Why it matters: Without seamless overlap and clean rewards, RL becomes slow, unstable, and irreproducible—limiting real reasoning gains.

🍞 Bottom Bread (Anchor): This is how INTELLECT-3, only 12B active parameters per token, beats or matches models 3–6× larger on AIME and LiveCodeBench.

Three analogies for the same idea:

• Factory line: Parts move continuously; inspectors check quality right on the belt; the machine gets micro-adjustments while it runs.
• Sports team: Offense and defense practice at the same time; coaches tweak plays mid-scrimmage; scorekeepers track stats consistently.
• Airport: Multiple runways operate in parallel; mid-route updates adjust flight paths; a single standard tower coordinates everything.

Before vs After:

• Before: Synchronous loops made GPUs wait; custom eval scripts made scores hard to compare; code execution was slow; long sequences crashed memory; MoE plumbing didn’t always match inference frameworks.
• After: Inference and training overlap continuously; shared environments guarantee consistent rewards; sandboxes run code fast and safely; long contexts are feasible; MoE state transforms keep trainer and inference aligned.

Why it works (intuition):

• Overlap converts wait time into learning time, raising effective sample throughput.
• Clean, verifiable rewards reduce noise in updates, stabilizing RL.
• Curriculum via online filtering keeps gradient signal high-value.
• MoE gives capacity where needed without paying full compute every token.
• Long-context techniques prevent memory from capping problem difficulty.

Building blocks (each is introduced once using the Sandwich pattern):

• Asynchronous Off-Policy Training: Keeps hardware busy; limits policy staleness.
• Continuous Batching and In-Flight Updates: Avoids stragglers; keeps policies fresh.
• Verifiers and Environments Hub: Reusable, versioned tasks and rubrics.
• Prime Sandboxes: Millisecond code execution at massive scale, safely.
• Activation Offloading and (when useful) Context Parallelism: Scale to 65k–72k+ tokens.
• Efficient MoE Support and State-Transform: Trainer uses TorchTitan kernels; inference uses HF/vLLM; a bridge keeps weights consistent.

🍞 Anchor: With this design, the team scaled RL to 512 H200 GPUs, kept training stable for weeks, and achieved 90.8% (AIME 2024), 88.0% (AIME 2025), and 69.3% (LiveCodeBench v6).

High-level pipeline: Input (tasks from Environments Hub) → Inference rollouts (vLLM servers) → Orchestrator (continuous batching + scoring) → Trainer (FSDP2 + distributed Muon) → In-flight weight updates to inference → Output (steadily improving INTELLECT-3 + online evaluations).

Step-by-step, like a recipe:

1. Set up standardized environments (verifiers) 🍞 Hook: You know how board games come with clear rules so anyone can play fairly? 🥬 Concept: Verifiers define tasks, tools, and rubrics so training and evaluation match exactly.

• What happens: Each environment packages prompts, rollout logic (single or multi-turn), optional tool APIs, and a scoring rubric. They run asynchronously, thousands at a time.
• Why it exists: Without consistent rules, rewards get noisy and progress looks random.
• Example: AIME environments parse the final boxed answer and check it with math-verify. 🍞 Anchor: The same environment can be run locally for tests or on the cluster for RL.

1. Disaggregate trainer and inference 🍞 Hook: Like separating cooking (hot work) from dishwashing (continuous), both happen in parallel so the kitchen never stops. 🥬 Concept: The trainer (FSDP2) updates weights; inference (vLLM) generates rollouts; the orchestrator connects them.

• What happens: Orchestrator collects rollouts, packs batches, computes rewards, and ships data to the trainer; it also pushes new weights to inference on-the-fly.
• Why it exists: Avoids stalls; keeps GPUs busy; makes scaling linear with more nodes.
• Example: A multi-client orchestrator talks to many vLLM servers independently for better throughput. 🍞 Anchor: Adding more inference nodes linearly raised tokens/sec thanks to round-robin routing.

1. Asynchronous off-policy training 🍞 Hook: Two crews pave different parts of a road at once; progress leaps ahead. 🥬 Concept: Inference can keep sampling with slightly older weights while the trainer updates.

• What happens: The system tags each rollout with the weight version; limits and masks control off-policyness.
• Why it exists: Long rollouts would otherwise force idle time.
• Example: With async-8, the system discards rollouts too far from current weights to prevent drift. 🍞 Anchor: Overlap cut step time more than 2× vs a stop-and-go loop.

1. Continuous batching and in-flight weight updates 🍞 Hook: A never-ending escalator keeps people flowing; maintenance tweaks happen without shutting it down. 🥬 Concept: Refill finished slots immediately; apply new weights mid-generation.

• What happens: The orchestrator refills the rollout pool instantly; inference briefly pauses to load new weights; trajectories may span policies with guardrails.
• Why it exists: Squeezes out dead time and keeps the freshest skills in use.
• Example: Coding tasks of uneven lengths no longer bottlenecked the whole batch. 🍞 Anchor: This was critical to keep 65k-token reasoning rollouts efficient.

1. Robust, long-context training 🍞 Hook: For a long hike, pack smart and offload weight when possible. 🥬 Concept: Activation checkpointing + offloading; selectively consider context parallelism.

• What happens: Store fewer activations; offload to CPU; recompute as needed; use FA3 kernels. Explore context parallelism where it helps.
• Why it exists: Prevent out-of-memory at 48k–72k+ tokens.
• Example: 72k sequences trained with negligible MFU loss using synchronous offloading. 🍞 Anchor: This kept reasoning chains intact over very long conversations.

1. Efficient MoE and state compatibility 🍞 Hook: Two tools, one blueprint—use an adapter to fit them together. 🥬 Concept: Use TorchTitan grouped GEMM kernels for training; transform state dicts for HF/vLLM inference.

• What happens: Avoid expert-parallel overhead in regimes where kernels are saturated; monitor load balance; convert weights trainer↔inference.
• Why it exists: Keep training fast and inference compatible without rewrites.
• Example: Up to 128 experts still saturated kernels at long sequence lengths, so expert-parallelism wasn’t needed. 🍞 Anchor: This let the team train quickly and serve with standard OpenAI-style APIs.

1. Stable optimization with distributed Muon 🍞 Hook: If one student carries the whole group project, it’s inefficient—better to split tasks fairly. 🥬 Concept: Muon works on full matrices, so the team used all-to-all schemes to distribute its computation under FSDP.

• What happens: Gradient shards are reshuffled for Newton–Schulz updates efficiently; avoids IB congestion.
• Why it exists: Keeps post-training stable when the base model was pretrained with Muon.
• Example: Dion’s open implementation guided the final design. 🍞 Anchor: This improved stability vs naive gather/scatter approaches.

1. Prime Sandboxes for code execution 🍞 Hook: A racetrack with green lights and guardrails lets cars go fast safely. 🥬 Concept: A Rust gateway, headless services, sidecar execution, image streaming, warm pools, and gVisor runtime.

• What happens: Sub-second cold starts; millisecond exec; 256 sandboxes per node with burstable CPU; direct webhooks for readiness.
• Why it exists: Coding and SWE environments need fast, safe, massive parallel runs.
• Example: 4,000+ concurrent Python test runs without overloading Kubernetes control planes. 🍞 Anchor: This enabled LiveCodeBench-style RL at scale.

1. Online difficulty filtering and curriculum 🍞 Hook: Level up in a video game only when you’ve mastered the previous level. 🥬 Concept: Pools (easy/normal/hard) update by observed solve rates; trivial data is dropped.

• What happens: Maintain a moving window of challenging-but-learnable tasks across domains.
• Why it exists: Maximizes learning per token; avoids wasted steps.
• Example: Math and science problems were rebalanced as the model improved. 🍞 Anchor: Rewards and benchmark scores trended up without plateauing.

1. Online evaluations 🍞 Hook: A scoreboard updates during the match, not just after it ends. 🥬 Concept: Evaluations interleave with training via the same infrastructure to hide overhead and keep feedback tight.

• What happens: AIME, GPQA, LiveCodeBench, HLE, MMLU-Pro run periodically; results guide the data mix.
• Why it exists: Timely signals help steer training before issues compound.
• Example: INTELLECT-3’s AIME/LCB curves kept improving at 15-step checkpoints. 🍞 Anchor: The team confidently saw no performance plateau by the end of the reported run.

Secret sauce:

• The trio of asynchronous overlap (inference↔training), continuous batching with in-flight updates, and standardized verifiers turns previously idle time and messy rewards into clean, high-throughput learning. That, plus Prime Sandboxes and long-context memory tricks, lets a right-sized MoE compete with much larger models by learning better, not just being bigger.

The test: Measure real reasoning and agentic performance across diverse, tough benchmarks.

• AIME 2024/2025 (30 math problems each): Average of pass@1 over 32 generations per question for robustness.
• LiveCodeBench v6: Recent coding tasks; pass@1 with 2 rollouts per problem.
• GPQA Diamond: Very hard STEM multiple choice; pass@1 over 4 generations.
• HLE: Broad knowledge exam; average accuracy.
• MMLU-Pro: Tough general STEM; average accuracy.

The competition: Compare to strong baselines in similar or larger parameter classes.

• GLM-4.5-Air (post-trained base), GLM-4.5, GLM-4.6 (3× larger), DeepSeek R1 and v3.2, GPT-OSS 120B.
• All models evaluated via official or equivalent APIs, same environments and rubrics for apples-to-apples results.

The scoreboard (with context):

• INTELLECT-3: AIME 2024 = 90.8% and AIME 2025 = 88.0%. That’s like getting an A+ on a famously tricky math contest, matching or beating models much larger.
• LiveCodeBench v6 = 69.3%. That’s an 8% jump over GLM-4.5-Air post-train, a significant margin on fresh coding problems.
• GPQA Diamond ≈ 74.4% (avg@4). Competes with larger models on high-difficulty STEM questions.
• HLE ≈ 14.6% (avg@1). Edges out comparable models; still a very challenging exam.
• MMLU-Pro ≈ 81.9%. Strong performance on a difficult, more robust general benchmark.

Why these numbers matter:

• AIME gains show deep reasoning improvements, not just pattern matching.
• LCB gains show tool use plus code execution RL improved practical coding reliability.
• GPQA and MMLU-Pro reflect generalization on hard STEM multiple-choice questions.

Surprising findings:

• Scaling infrastructure and training method mattered as much as (or more than) raw size. The 106B MoE with ~12B active outperformed larger dense or frontier models in several key tasks.
• Training stability benefited strongly from double-sided masking on importance ratios to reduce trainer-inference mismatch, preventing late-crash failures reported in other setups.
• Even at the end of the reported run, online curves on AIME/LCB/GPQA were trending up with no plateau, suggesting more compute would likely yield more gains.
• Expert parallelism hurt throughput in this regime (long sequences and large hidden dims) because the grouped GEMM kernels were already saturated; turning it off was faster.
• Distributed Muon with all-to-all outperformed naive round-robin gradient gathers at multi-node scale due to reduced IB congestion.

Takeaway: By removing bottlenecks (compute idle time, slow code execution, inconsistent rewards, long-context OOMs), INTELLECT-3’s RL could focus on learning signal and deliver outsized gains for its active parameter budget.

Limitations:

• Compute hungry: While efficient for its class, training still used up to 512 H200 GPUs and weeks of runtime; not everyone can replicate at that exact scale.
• Environment sensitivity: Performance depends on the quality/diversity of RL environments and rubrics; poor or biased rewards may mis-train behaviors.
• Long-horizon memory: Even with long contexts, true task persistence across hundreds of turns is still a frontier challenge (“context rot”); external memory and context management tools are early-stage.
• MoE trade-offs: MoE increases engineering complexity (routing, balance, state transforms) and can reduce throughput if not tuned for the regime.

Required resources:

• Multi-node cluster with fast interconnect (e.g., 400 Gbps IB) for reliable FSDP2 and all-to-all collectives.
• Robust storage and logging; container orchestration for sandboxes with image streaming and warm pools.
• Monitoring/observability to catch stragglers, Xid errors, and thermal slowdowns early.

When not to use:

• Tiny-scale projects needing quick wins without code execution or long-context reasoning—simpler SFT might suffice.
• Strictly single-turn, short-answer tasks where RL’s overhead offers limited gains.
• Environments lacking trustworthy verifiers—bad rewards can degrade the model.

Open questions:

• How far can gains scale with more agentic RL compute before diminishing returns?
• What’s the best recipe for long-horizon memory: tool-learned context management, structured external memory, or hybrid approaches?
• Can we automate curriculum design beyond current online filtering for even steadier gains?
• How to generalize distributed Muon and MoE choices across different base models and hardware without heavy hand-tuning?
• What new verifier designs best capture real-world correctness (e.g., partial credit, robustness, safety constraints) without adding reward hacking avenues?

Three-sentence summary: INTELLECT-3 shows that smarter training pipelines can beat brute-force size—using asynchronous RL, standardized verifiers, and safe, fast sandboxes to learn complex reasoning and tool use. The 106B-parameter MoE (about 12B active) achieves state-of-the-art results for its class, topping bigger models on AIME and LiveCodeBench. All ingredients—the model, framework, environments, and recipes—are open-sourced to help the community reproduce and extend the approach.

Main achievement: Turning an end-to-end, open, asynchronous RL stack into real, measurable gains on tough reasoning and coding benchmarks—proving infrastructure design can unlock capability leaps.

Future directions:

• Keep training on richer agentic environments (deep research, SWE) since metrics were still rising.
• Strengthen long-horizon behavior via learned context management and external memory tools.
• Scale the Environments Hub so the community contributes more verified, domain-specific tasks and rubrics.

Why remember this: INTELLECT-3 is a landmark that shows how to convert compute into reasoning skill efficiently—by overlapping work, standardizing rewards, running code safely at scale, and stretching context length—pushing open models closer to frontier capabilities without simply making them bigger.