Olmo 3

1 Introduction

• Olmo 3 releases the full model flow—data, code, checkpoints, and dependencies—rather than only final weights, enabling intervention and study throughout development.The release covers every stage from initial conception through final models.Source: §1 · p. 3
• Olmo 3 Think 32B performs competitively with Qwen 3 32B while using six times fewer training tokens, and its reasoning chains can be traced to original training data.Olmo 3 Think generates intermediate thinking traces before final answers.Source: §1 · p. 3, Figure 1 · p. 3
• Olmo 3 Instruct 7B and 32B produce shorter responses for general chat and function calling while surpassing several comparable open-weight models and narrowing the gap to Qwen 3.The models avoid intermediate thinking outputs to reduce response latency.Source: §1 · p. 3
• The family includes RL-Zero 7B, trained directly from Olmo 3 Base to expose how base-model data affects reinforcement-learning performance.Its fully-open setup supports study of data effects on RL.Source: §1 · p. 4
• Olmo 3 introduces Dolma 3 and Dolci datasets spanning pretraining, midtraining, long-context extension, supervised finetuning, preference tuning, and reinforcement learning.These datasets target reasoning, coding, math, knowledge, instruction following, and long-context capabilities.Source: §1 · p. 4
• Olmo 3 adds OlmoBaseEval, OlmoRL, and a development framework combining distributed experimentation with centralized evaluation across the model pipeline.The stated goal is coordinated, capability-driven improvement across data processing, evaluation, pretraining, and reinforcement learning.Source: §1 · p. 4

2 Model Flow for Olmo 3

• Olmo 3 training divides into base-model training and post-training, with each major stage further split into sub-stages using distinct data-and-method recipes.Figure 2 presents this organization as the model flow.Source: §2 · p. 4, Figure 2 · p. 4

2.1 Base Model Training

• Olmo 3 Base uses up to 5.9T pretraining tokens, 100B midtraining tokens, and 50B or 100B long-context-extension tokens for 7B or 32B models.The stages are designed to strengthen capabilities needed during post-training, including math, code, reasoning, instruction following, and long-context understanding.Source: §2.1 · pp. 4–5
• OlmoBaseEval supports compute-efficient base-model decisions by aggregating related tasks, developing small-scale proxy metrics, and improving signal-to-noise through example selection.The suite addresses random-chance performance and small score differences that are difficult to distinguish from benchmark noise.Source: §2.1 · pp. 4–5
• Dolma 3 uses global deduplication, olmOCR science PDFs, token-constrained mixing, and quality-aware upsampling, while midtraining adds feedback loops, centralized integration tests, and instruction or thinking data.The data curriculum targets code, math, general knowledge, reasoning, and post-training readiness.Source: §2.1 · p. 5
• Long-context extension uses Dolma 3 Longmino Mix and large olmOCR science-PDF collections, enabling up to 65K context and competitive long-context performance against comparable models.The collection includes over 22.3M documents above 8K tokens and 4.5M above 32K tokens.Source: §2.1 · p. 5

2.2 Post-training

• Post-training develops Think through SFT, DPO, and RLVR, Instruct through concise-response and function-calling optimization, and RL-Zero through fully open, decontaminated RLVR setups.OlmoRL improvements enable longer, more stable runs and a reported 4x speedup in RL training.Source: §2.2 · pp. 5–6

2.3 Results

• Olmo 3 Think is reported as the strongest fully-open thinking model, outperforming several comparable models and narrowing the gap to Qwen 3 and Qwen 3 VL while using roughly six times fewer tokens.Table 1 provides a snapshot of the post-training evaluation suite.Source: §2.3 · p. 6, Table 1 · p. 7

2.4 Costs

• Training Olmo 3 Think 32B took approximately 56 days on 1,024 H100 GPUs, with about 47 days for pretraining stages and 9 days for post-training.Repeated checkpoint evaluations and post-training sweeps consume substantial resources beyond pretraining alone.Source: §2.4 · pp. 7–8

3.1 Main Results for Olmo 3 Base

• Olmo 3 Base is the best fully-open 32B model and achieves the strongest fully-open Math and Code performance at 7B, with competitive MCQA and GenQA results across scales.At 32B, it outperforms Stanford Marin 32B and Apertus 70B; at 7B, it leads fully-open models on Math and Code and trails only the strongest open-weight models on those composites.Source: §3.1 · p. 8

3.2 Modeling and Architecture

• Olmo 3 Base uses 8192-token pretraining and midtraining contexts plus sliding-window attention in three of every four layers, while retaining full attention in the final layer.The sliding window has size 4096, supporting scalable long-sequence training and manageable inference costs.Source: §3.2 · pp. 8–9

3.3.1 Clustering Tasks

• OlmoBaseEval clusters benchmarks by similar model rankings using 23K scores from 70 external models, then manually adjusts clusters to preserve task-format consistency.The resulting clusters are MCSTEM, MCNon-STEM, GenQA, Math, Code, and Code FIM.Source: §3.3.1 · pp. 11–12

3.3.2 Scaling analysis

• Scaling analysis shows that Base Easy provides signal at small data-ablation scales while Base Main remains unsaturated at large scale, preserving headroom for midtraining data experiments.The analysis uses 25 OLMo 2 scaling-law models and 70 open-weight models across low- and high-compute regimes.Source: §3.3.2 · p. 12

3.3.3 Signal-to-Noise Analysis

• Signal-to-noise analysis removes noisy benchmarks from macro-averages while preserving distinctive capabilities such as CruxEval’s code input/output prediction.The procedure expands from 1K subsets to full evaluation sets when available and can tune generation settings to improve aggregate reliability.Source: §3.3.3 · p. 13, Figure 7 · p. 13

3.3 Experimental Design and Evaluation

• OlmoBaseEval combines capability-based task clusters, small-scale proxy metrics, and signal-to-noise filtering to guide development decisions across model scales.The resulting evaluation framework contains 43 tasks, a Base Easy suite for small compute budgets, a Base Main suite for final pretraining and midtraining, and four held-out benchmarks.Source: §3.3 · pp. 10–11, §3.3.4 · p. 13

3.4 Stage 1: Pretraining

• Dolma 3 Mix introduces trillion-token-scale global deduplication tooling, token-constrained mixing, quality-aware upsampling, and olmOCR science-PDF data for pretraining.The final pretraining mix contains 6T tokens, while structured task data is reserved for later midtraining and long-context stages.Source: §3.4 · pp. 13–14

3.4.1 Preparing our Web Data Pool

• Heuristic filtering reduces the data pool by 84.6%, yielding 38.8B documents; a three-stage deduplication procedure then reduces 38.7B to 9.7B, a 75% reduction.Substring processing removes 14% of text bytes, yielding 9.7B documents totaling 36.5T bytes of uncompressed text.Source: §3.4.1 · pp. 15–16
• The web data pool contains 8T annotated tokens partitioned into 24 topics and 20 quality tiers for fine-grained control of the pretraining mixture.Documents are classified by topic and quality, producing 480 disjoint subsets before later filtering and topic reweighting.Source: §3.4.1 · p. 16

3.4.2 Preparing our olmOCR science PDFs Data Pool

• The olmOCR science-PDF pipeline crawls 238 million documents and filters them through extraction, deduplication, PII, and heuristic stages to produce 108 million topical documents.The intermediate corpus contains 160 million extracted PDFs, 156 million after deduplication, and 148 million after PII filtering.Source: §3.4.2 · pp. 16–17

3.4.3 Preparing Code, Math, and other sources

• Additional sources include programming data from Stack-Edu, LaTeX-preserving math data from Proof-Pile-2 and FineMath, and filtered English and Simple Wikipedia and Wikibooks.FineMath documents are retained when their quality score is at least 3 out of 4.Source: §3.4.3 · p. 17

3.4.4 Sampling and Mixing over Data Pools

• Conditional mixing treats an existing optimized mixture as a frozen virtual domain, enabling efficient adaptation when data domains change without recomputing the full swarm.The base procedure trains proxy models, fits per-task regressions, and optimizes mixture weights under token-availability constraints.Source: §3.4.4 · pp. 18–19
• Optimized data mixing improves web-text performance by 0.056 BPB on average and 0.209 BPB at maximum versus the natural distribution, with degradations on 13 of 54 tasks, none exceeding 0.035.The optimized mixture upweights STEM topics, while Stack-Edu mixing favors Python and improves all but two coding benchmarks.Source: Figure 9 · p. 18, §3.4.4 · p. 19

3.5 Stage 2: Midtraining

• Midtraining uses 100B high-quality tokens in Dolma 3 Dolmino Mix and combines distributed source-level feedback loops with centralized integration tests.The mix expands targeted curation across code, math, and general-knowledge QA while including instruction data and thinking traces for later post-training.Source: §3.5 · pp. 20–22

3.5.1 Methodological framework

• The midtraining framework evaluates candidate datasets with 5B-token microanneals against matched 10B-token web-only baselines, then validates promising combinations through 100B-token integration runs and SFT assessment.Five major integration rounds were conducted, with Rounds 1, 3, and 5 reported; Round 5 includes the new decontamination process.Source: §3.5.1 · p. 22

3.5.2 Capability Improvements for Final Data Mix

• The final midtraining mix targets improved math, coding, knowledge elicitation, instruction following, and reasoning while retaining higher-quality web and PDF data from pretraining.For math, 25 sources were evaluated across 80 microanneal runs, yielding five selected math-specific sources, four newly synthesized.Source: §3.5.2 · pp. 22–23
• The final mix targets math, code, QA, instruction, thinking, and knowledge through synthetic and curated datasets, including rewritten high-quality data and capability-specific sources.Examples include TinyMATH, CraneMath, CraneCode, Reddit-to-Flashcards, Wiki-to-RCQA, and meta-reasoning data.Source: §3.5.2 · pp. 23–25
• A quality-filtered stem-heavy crawl improves MCNon-STEM, MCSTEM, and Math by approximately 2 points each versus a web-only baseline.The filter threshold is 0.6, selecting the top 2.83% of crawled data.Source: §3.5.2 · p. 26

3.5.3 Decontamination

• Decon detects benchmark overlap with strided n-gram matching, expands matches into contaminated clusters, and removes documents exceeding a tuned threshold.The protocol was refined for question, answer, passage, and multiple-choice matching to improve precision and recall.Source: §3.5.3 · p. 26

3.5.4 Key findings

• Candidate midtraining mixes consistently improve base and subsequent SFT evaluations, with later gains likely underestimated because only Round 5 uses decontaminated data.Table 6 illustrates this development trajectory across representative candidate mixes.Source: §3.5.4 · p. 27, Table 6 · p. 27
• Domain-skewed mixes trade off capabilities: math-code-thinking boosts math and code but hurts QA, whereas Gen-QA preserves QA while substantially reducing math and code.The final mix balances these domains rather than maximizing any single group.Source: §3.5.4 · p. 27, Table 7 · p. 27
• Instruction and thinking data improve every base evaluation measure when added at fixed token count, showing aggregate benefits before post-training.Table 10 compares runs with and without these post-training-oriented subsets.Source: §3.5.4 · p. 28, Table 10 · p. 29
• Special chat tokens cause harmful base-model emissions: GSM8K falls from 49.43 to 0 and CruxEval from 32.89 to 18.91, so Olmo 3 uses newline formatting instead.Ordinary-text chat templates without special tokens cause smaller drops, implicating the tokens specifically.Source: §3.5.4 · p. 28
• Olmo 3 Base 32B model souping improves MCSTEM by nearly 1 point, GenQA by 0.4, Math by 2.9 and 1.6, MMLU by about 1, and GSM Symbolic by 5 and 2 points.The merged checkpoint is selected as the final midtrained 32B model; the 7B model does not show similar merging gains.Source: §3.5.4 · p. 30, §3.6 · p. 30

3.6 Stage 3: Long-context Extension

• Olmo 3 extends its context window from 8,192 to 65,536 tokens using Dolma 3 Longmino Mix, a dataset containing over 600 billion tokens of natural and synthetic long texts.The long-context stage targets processing long inputs and supporting test-time scaling through long intermediate sequences.Source: §3.6 · p. 30

3.6.1 Sourcing Long Context Data

• Gzip filtering outperforms LongPpl-based alternatives, so the final long-context data pipeline excludes the most and least compressible 20% of text.LongPpl evaluates key-token frequency and spread, but tested exclusion strategies do not beat gzip filtering.Source: §3.6.1 · pp. 31–32

3.6.2 Experiments with Synthetic Augmentation

• Synthetic augmentation injects aggregation tasks into long science-PDF documents by selecting salient noun phrases and snippets before prompting a language model.The tasks include Common Word Extraction and Rewriting EXpressions, generated for documents between 32,768 and 65,536 tokens.Source: §3.6.2 · pp. 32, 34

3.6.3 Choosing Data Mix and Token Budget

• A 34% long-context and 66% short-context mix reduces OlmoBaseEval degradation to 0.8 points versus 2.5 points for the reverse mix, while longer extensions improve long-context performance.The final extension uses 50B tokens for Olmo 3 7B and 100B tokens for Olmo 3 32B.Source: §3.6.3 · p. 34

3.6.4 Curating a Training Recipe for Extension

• The final recipe applies YaRN only to full-attention layers, uses best-fit document packing and intra-document masking, and merges the last three 32B extension checkpoints.Best-fit packing substantially improves long-context benchmarks, while intra-document masking prevents cross-document attention signals.Source: §3.6.4 · pp. 34–35

3.7 Base Model Results

• Olmo 3 improves science, math, and code metrics over OLMo 2 but slightly degrades on general-knowledge benchmarks, which the authors attribute to emphasizing and upsampling STEM data.Table 13 compares Olmo 3 across pretraining, midtraining, and long-context stages with other open base models.Source: §3.7 · p. 35, Table 13 · p. 36

4 Olmo 3 Think

• The post-training recipe uses curated Dolci Think SFT, DPO, and RL datasets spanning math, coding, instruction following, and general conversation, with gains observed across all three stages.Dolci Think includes long synthetic reasoning traces, capability-contrastive preference pairs, and challenging reinforcement-learning prompts.Source: §4 · p. 37, §4.4 · p. 44

4.1.2 Main Results

• Olmo 3 Think 32B is reported as the best fully-open 32B model, outperforming Gemma 2/3 27B and Qwen 2.5 32B-Instruct while narrowing the gap to Qwen 3 and Qwen 3VL using 6× fewer tokens.Olmo 3 Think-7B also outperforms several open-weight 7B thinking models but lags Qwen 3 on knowledge tasks.Source: §4.1.2 · p. 38, Table 14 · p. 38
• Extending OlmoRL training from 750 to 2300 steps improves AIME, ZebraLogic, IFEval, and IFBench, while AlpacaEval drops by 5 points and most other benchmarks remain largely unchanged.The extended run had not fully saturated when stopped because of compute limitations.Source: §4.1.2 · p. 38, §4.2 · p. 38

4.2.1 Dolci Think SFT: Data Curation

• Dolci Think SFT combines sourced prompts, regenerated reasoning traces, extensive license, quality, topic, and decontamination filtering, and category-level mixing experiments that inform the final dataset.The final mix retains at least part of each tested category because every dataset helps on at least one evaluation.Source: Step 1: sourcing prompts and… · p. 41

4.3 Preference Tuning with Delta Learning

• Dolci Think DPO treats preference tuning as capability-oriented contrastive learning, pairing Qwen 3 32B thinking completions with weaker Qwen 3 0.6B responses to create reasoning-quality deltas.Further supervised finetuning on Qwen3 32B thinking traces hurt SFT performance, whereas pairing those traces with worse responses provides a useful contrastive signal.Source: §4.3 · p. 42, §4.3.1 · p. 43

4.4 Reinforcement Learning with OlmoRL: The Cherry on Top

• OlmoRL extends GRPO with filtering, active sampling, token-level loss normalization, no KL loss, asymmetric clipping, and truncated importance sampling for longer, more stable RL across domains.Its RL stage combines verifiable and language-model-judge rewards and uses roughly 100K Dolci-Think-RL prompts across mathematics, coding, instruction following, and general chat.Source: §4.4 · p. 44, §4.4.1 · pp. 44–45

4.4.1 OlmoRL Algorithmic Details

• OlmoRL uses a token-level clipped objective with truncated importance sampling and group-relative advantages, omitting standard-deviation normalization to remove difficulty bias.The algorithm combines token-level loss, clip-higher, and truncated importance sampling; verifier rewards are computed per domain and advantages are based on relative group rewards.Source: §4.4.1 · p. 45

4.4.2 Dolci-Think-RL: Curating a State-of-the-art RLVR Dataset

• Dolci-Think-RL contains roughly 100K samples across mathematics, coding, instruction following, and general chat, with automatically checked verifiable or non-verifiable rewards.The dataset uses domain-specific sourcing and filtering, including test-case pairs for coding and offline difficulty filtering that removes samples with pass rates above 62.5%.Source: §4.4.2 · pp. 46–47

4.4.3 OlmoRL Infrastructure in Open Instruct

• The RL infrastructure uses fully asynchronous actor-learner execution and active sampling, supporting rollouts up to 32K tokens and averaging more than 10K for reasoner models.Inference used approximately 5x the training compute for the 32B reasoner model and approximately 14x for the 7B reasoner model.Source: §4.4.3 · p. 48

4.5 Key Findings

• DPO remains a better RL starting point than SFT, while mixed-domain training avoids domain-specific over-optimization and preserves broader downstream performance.DPO consistently outperforms SFT after RL, whereas single-domain training can improve its target evaluation while harming others; the final mixture achieves similar or better downstream performance despite lower training reward.Source: §4.5 · pp. 50–51
• RL rewards steadily increase across all domains, with differing rates, while DPO outperforms direct imitation by contrasting Qwen3-32B responses with weaker Qwen3-0.6B responses.Direct supervised finetuning on Qwen3-32B chosen responses hurts the initial SFT model, whereas DPO yields strong gains across math and code reasoning and expands the reasoning frontier beyond pass@1 conversion.Source: §4.5 · pp. 49–50, Table 21 · p. 50
• Continuous batching and inflight updates enable two times faster RL training on half as many GPUs, making long reasoning runs more tractable.Inflight weight updates provide up to 4x faster throughput with the same resources without hurting accuracy, while continuous batching prevents waste from variable-length generations.Source: §4.4.3 · pp. 48–49, §4.5 · p. 51, Table 23 · p. 51
• Continuous batching and inflight updates reduce one-epoch training from 14 days on 9 nodes to 7 days on 5 nodes.The benchmark setup generates 128 completions per training step from 64 prompts, with maximum output and input lengths of 32000 and 2048.Source: §4.5 · pp. 51–52
• Starting RLVR from DPO is overall preferable to starting from SFT, although the better initialization depends on the evaluation.The comparison spans AlpacaEval, Omega-500, and AIME 2025 during RLVR training.Source: Figure 19 · p. 52
• Mixed training data prevents overfitting by maintaining high AlpacaEval performance while achieving similar IFEval performance, and DPO with delta learning consistently improves pass@K over SFT.The pass@K improvement persists at higher K values for AIME 2024 and 2025.Source: Figure 20 · p. 52
• The final RL stage delivers the largest improvements in precise instruction following on both IFEval and unseen IFBench evaluations.These results cover Olmo 3 Think and Instruct models at 7B and 32B across post-training stages.Source: §4.5 · p. 52, Table 24 · p. 53
• Per-domain RL training yields higher training rewards than the overall data mix, but higher train reward does not necessarily improve downstream performance.The comparison considers general, instruction-following, and mathematics subsets against the overall mix.Source: Figure 20 · p. 52, Figure 21 · p. 53

5 Olmo 3 Instruct

• Olmo 3 Instruct targets common advice-seeking and information-recall interactions without inference-time reasoning, responding quickly and helpfully to user queries.Its training additionally targets tool use and efficient responses.Source: §5 · p. 53

5.1 Main Results for Olmo 3 Instruct

• 57.9 on AIME 2025 and 39.7 on IFBench show Olmo 3.1 Instruct 32B surpassing Qwen 3 32B (No Thinking) on AIME 2025 and Qwen 3 and Qwen 3 VL at 32B on IFBench.The model also outperforms most open models at similar scale, including Qwen 2.5 32B, Gemma 3 27B, and Apertus 70B.Source: §5.1 · p. 54, Table 25 · p. 54

5.2.1 Function-calling Training Data

• The function-calling data combines smaller real-interaction trajectories from MCP servers with scalable SimFC trajectories containing diverse multi-turn, multi-step, and refusal patterns.Real trajectories cover scholarly science QA and web-search QA, while SimFC uses tool sets and APIs from existing datasets and public MCP servers.Source: §5.2.1 · pp. 54–56
• A unified OpenAPI-based format with Pythonic code-block calls, XML delimiters, environment roles, and dedicated tokenizer tokens is used to stabilize tool-use behavior.Function calling is evaluated through intrinsic BFCLv3 accuracy and extrinsic task completion with ASC and Serper tools on LitQA2 and SimpleQA.Source: §5.2.1 · p. 56

5.3 Preference Tuning with Dolci Instruct DPO

• Dolci Instruct DPO adds GPT-judged contrastive pairs, synthetic multi-turn conversations, and length-control interventions to improve general alignment, conversational usability, and brevity.Chosen and rejected chat responses are filtered to differ by at most 100 tokens to mitigate preference-data length bias.Source: §5.3 · p. 57, §5.3.1 · p. 59

5.3.2 Prompt Mixing

• Hand-crafted preference prompt mixes outperform uniform random sampling, while code-domain upsampling can unexpectedly decrease code benchmark performance.The final mix is selected empirically from nine candidate mixtures after domain-subset ablations.Source: §5.3.2 · p. 59

5.2.2 Curating Dolci Instruct SFT

• Starting SFT from the Olmo 3 Think SFT checkpoint significantly improves Olmo 3 Instruct performance while preserving succinct answers without thinking traces.Dolci Instruct SFT builds on the OLMo 2 Instruct mixture with improvements for general chat, reasoning, and function calling.Source: §5.2 · p. 54, §5.2.2 · p. 57, §5.5 · p. 61

5.5 Key Findings

• High contrast between chosen and rejected responses is critical for DPO gains: delta-aware interventions that weaken rejected responses make GPT-judged pairs significantly outperform the OLMo 2 preference-data baseline.Simply improving the response generators and judge failed because synthetic completions lacked meaningful contrast.Source: §5.3.1 · pp. 58–59, §5.5 · p. 61
• Length control during DPO substantially shortens outputs and improves usability, despite lowering scores on length-sensitive evaluations such as AIME and MATH.Internal qualitative assessments almost uniformly preferred the shorter, more direct model.Source: §5.5 · p. 61
• At 7B scale, length-controlled DPO initialization produces more reliable RL progress and ultimately higher performance than an uncorrected, higher-scoring DPO checkpoint.The authors conjecture that shorter outputs use the fixed 8K RL context window more effectively, while uncorrected initialization shows earlier instability or degradation.Source: §5.5 · p. 61
• Preference-tuning performance peaks at task-dependent dataset sizes, so further optimization can hurt downstream performance.AlpacaEval and ZebraLogic peak around 75–100K samples, whereas AIME2024 has not saturated at that point; training therefore sweeps dataset size and learning rate.Source: §5.5 · p. 61, Figure 23 · p. 62
• Tool use significantly improves SimpleQA for all evaluated models, while Qwen models mostly rely on parametric knowledge for LitQA2 unlike Olmo 3 Instruct 7B.Two Qwen models lose LitQA2 performance when tools are provided.Source: §5.5 · p. 62, Table 31 · p. 62
• Combining delta-learning and GPT-judged preference pairs outperforms either source alone and yields the largest average gain.The combined preference data also greatly outperforms previous OLMo 2 preference data.Source: §5.5 · p. 61, Table 32 · p. 63

6 Olmo 3 RL-Zero

• Olmo 3 RL-Zero releases the Dolci RL-Zero dataset and OlmoRL code for decontaminated RLVR from Olmo 3 Base across math, code, instruction following, general chat, and mixed objectives.The setup is designed to isolate RLVR effects without pretraining or midtraining data leakage.Source: §6 · p. 63

6.1 Reinforcement Learning From Base with Dolci RL-Zero

• The math RL-Zero dataset contains 13.3K decontaminated prompts built by filtering, deduplicating, clustering, and removing questions already solved by the final base model.Code, instruction-following, and general-chat data are subsampled from Dolci Think RL.Source: §6.1 · p. 63
• RL-Zero uses domain-specific simple prompts, cleaned evaluation formatting, 16K-token training responses, and 32K-token evaluation responses at temperature 1.0.These choices accommodate long reasoning and encourage diversity for pass@k evaluation.Source: §6.1 · pp. 63–64

6.2 Key Findings

• Olmo 3 Base improves steadily on decontaminated AIME evaluations during math RL, including pass@32, with final 7B performance close to DAPO despite using a smaller model and fewer training steps.The authors describe this as a more efficient alternative to existing RLVR experiments.Source: §6.2 · p. 64, Figure 24 · p. 64
• Mixed-domain RL improves multiple domains, but each domain is under-optimized relative to its corresponding single-domain run, making the mix a challenging multi-objective RLVR benchmark.The setup supports future study of interactions between domains in multi-objective RLVR.Source: §6.2 · p. 64, Figure 24 · p. 64
• RL-Zero provides a testbed for midtraining ablations: insufficient reasoning data leaves response length stagnant and prevents behaviors such as backtracking and answer verification.This enables comparison of alternative midtraining approaches using downstream reasoning under RL.Source: §6.2 · pp. 64–65, Figure 25 · p. 65
• Active sampling maintains a consistently full batch of non-zero-advantage completions and greatly reduces training-loss variance in the math run.The method continuously resamples prompts after filtering for non-zero advantage.Source: §6.2 · p. 65, Figure 26 · p. 65
• Training with random binary rewards produces no benchmark gains, supporting the conclusion that the decontaminated evaluation setup removes significant overlap between training data and evaluation sets.The experiment tests whether spurious rewards can elicit memorized solutions.Source: §6.2 · p. 65, Figure 27 · p. 66

A.1 Base Model Additional Training Details

• Figure 28 tracks cross-entropy loss and total gradient norm during pretraining for both Olmo 3 Base 7B and 32B.Gradient-norm curves use an exponential moving average over 20 steps for readability.Source: §A.1 · p. 85, Figure 28 · p. 86
• Olmo 3 uses multi-head attention at 7B and grouped-query attention at 32B for increased efficiency.The architecture is summarized in Table 33.Source: Table 33 · p. 85
• Training configuration covers pretraining, midtraining, and long-context extension, with throughput measured on a cluster of 8× NVIDIA H100 80GB nodes.The configuration uses HSDP sharding and Llama3-style context parallelism.Source: §A.1 · p. 84, Table 34 · p. 85
• For 32B, training uses a cosine learning-rate schedule, doubled batch sizes, two midtraining runs with averaged checkpoints, and 100B rather than 50B long-context-extension tokens.These choices differ from the 7B training configuration.Source: Table 35 · p. 86

• 252.6B CommonCrawl documents from 104 dumps were processed into an initial pretraining pool spanning mid-2013 through late 2024.The dumps range from CC-MAIN-2013-20 through CC-MAIN-2024-51 and were linearized with Resiliparse.Source: §A.2.1 · p. 87
• 76% of the pool was removed by heuristic filters and another 2.5% by English filtering, leaving 38.7B documents with a 15.1% survival rate.The filters target spam, document length, symbols, repetition, boilerplate, language, and questionable sentences.Source: §A.2.1 · p. 87
• Because heuristic filters are commutative and English filtering is slowest, placing language filtering last can improve processing efficiency.Source: §A.2.1 · p. 87
• The filtering procedure removed 84.9% of the initial corpus and took approximately 1,030 hours on i4i.32xlarge EC2 instances.Table 36 summarizes the processing-step cost and removal breakdown.Source: Table 36 · p. 87, §A.2.1 · p. 87

• The three-stage pipeline combines global exact deduplication, 32-way MinHash deduplication with Jaccard verification, and 56-way fuzzy suffix-array deduplication.Source: §A.2.2 · p. 87
• The exact-deduplication stage uses two passes because per-dump processing is computationally more efficient before global deduplication.Duplodocus supports exact and MinHash deduplication, while bsade supports suffix-array deduplication.Source: §A.2.2 · p. 88
• Exact deduplication removes 66% of input documents, reducing the corpus to 12.7B documents before MinHash processing.It first deduplicates within each dump, then performs a global pass across the aggregated corpus.Source: §A.2.2 · p. 88
• MinHash deduplication removes 24% of its input and leaves 9.8B documents after true Jaccard-similarity verification.The procedure retains only the most recent version of each document according to crawl date.Source: §A.2.2 · p. 88
• Fuzzy suffix-array deduplication removes repeated spans when repeated 500-byte sequences bookend a span covering at least 80% of it.For spans lacking that bookended structure, individual repeated 500-byte sequences are removed.Source: §A.2.2 · p. 88
• After exact, MinHash, and suffix-array deduplication, the final corpus contains 9.7B documents.Source: §A.2.2 · p. 88

• The corpus is partitioned into 24 WebOrganizer topic categories using a FastText classifier instead of WebOrganizer’s 140M-parameter classifier.Source: §A.2.3 · p. 89
• The classifier is trained on Llama-labeled WebOrganizer data plus 506,746 examples labeled with gpt-4.1 and o4-mini.Source: §A.2.3 · p. 89
• Classifier performance is evaluated on the held-out 20,000-document sample used in the original WebOrganizer paper.Source: §A.2.3 · p. 89

• The procedure addresses a limitation of topic-level mixture prescriptions by controlling quality composition within each topic rather than merely filtering data as high- or low-quality.Source: §A.2.4 · p. 89
• Olmix searches for topic-specific upsampling ratios so selected token counts sum to the prescribed total while no quality bucket is upsampled more than M times.Source: §A.2.4 · p. 89
• The approach models upsampling with convex, monotonic functions defined on the normalized quality interval [0, 1].Source: §A.2.4 · p. 89
• Feasible functions must integrate to the requested token yield, satisfy λ ≥0, and obey maximum average upsampling constraints for each bucket.Source: §A.2.4 · p. 90
• The truncated power-exponential family provides a parameterized function that can filter out the lowest-quality buckets while controlling the mixture integral.Source: §A.2.4 · p. 90
• For each WebOrganizer topic, implementation sets maximum upsampling to M = 7, discards the bottom 40% of quality, and numerically solves for p, λ, and C.Source: §A.2.4 · p. 90

Validation setup

• Small-scale 1B experiments compare three validation settings for the proposed mixing and upsampling strategies using 100B-token runs.The validation program evaluates targeted mixing, quality-aware upsampling, and methods for combining them.Source: §A.2.5 · p. 90

Targeted mixing

• Targeted swarm optimization adapts data mixes toward QA, Math, or Code objectives, outperforming the natural distribution on the final multi-objective mix.Task-specific mixes achieve slightly better BPB than the final mix because the latter trades off multiple objectives.Source: §A.2.5 · p. 90, Table 38 · p. 91
• The final Olmo 3 mix substantially outperforms the natural distribution despite slightly worse BPB than task-specific mixes.This reflects necessary trade-offs across multiple objectives rather than optimization for one capability alone.Source: §A.2.5 · p. 90

Quality-aware upsampling

• Quality-aware upsampling consistently outperforms flat filtering across all repetition factors in simulated data-constrained training.The comparison uses 1B models trained on 100B tokens while matching repetition from a theoretical 4.51T-token pool.Source: §A.2.5 · p. 90, Table 39 · p. 91

Reconciling upsampling and mixing

• Mixing constrains topic proportions, whereas quality upsampling constrains quality proportions within sources.The two methods therefore impose row-wise and column-wise constraints on a topic-by-quality bucket matrix.Source: §A.2.5 · pp. 90–91
• Among combination techniques, truncated power-exponential forms perform best in the reported 1B-model experiments.Alternative approaches include arithmetic or geometric averaging of bucket targets and exponential-function families; results are reported in Table 40.Source: §A.2.5 · p. 91, Table 40 · p. 91

A.3 Base Model Additional Data Details: Midtraining

• The section provides further detail on curation processes for Dolma 3 Dolmino Mix.It also identifies the Dolma3 GitHub repository as a source of replication materials, including synthetic-data prompts.Source: §A.3 · p. 91
• Replication resources include prompts for synthetic data generation.Source: §A.3 · p. 91
• The Dolma3 GitHub repository contains additional materials for reproducing the curation process.Source: §A.3 · p. 91

TinyMATH

• TinyMATH is constructed by generating 100 problems per existing MATH problem, then producing Pythonic and natural-language solutions.The resulting PoT and MIND datasets contain 241M and 899M tokens, respectively, and are assessed with annealing runs.Source: §A.3.1 · p. 92

CraneMath

• CraneMath recreates SwallowMath-style rewrites with Qwen3 32B to provide a more permissively licensed, fully open dataset.The resulting dataset contains 5.62B tokens, compared with 9.6B in FineMATH4+ and 2.3B in SwallowMath.Source: §A.3.1 · pp. 91–92

MegaMatt

• MegaMatt recreates a recent subset of MegaMath-Web-Pro-Max because the original Llama-generated data carries a restrictive license and was judged lower quality than SwallowMath.The recreated pool contains 3.9B tokens and is evaluated against MegaMath-Web and MegaMath-Web-Pro-Max variants.Source: §A.3.1 · pp. 92–93

Key Findings and Results

• Math-data quality tiers anticorrelate with dataset size, with the highest-quality sources also being the smallest.The results normalize evaluation-score changes by training tokens and show diminishing returns as more tokens are added.Source: Table 41 · p. 92, §A.3.1 · p. 93
• Highly curated tinyMATH variants deliver the strongest math-evaluation improvement per token despite containing fewer than one billion tokens.Synthetic rewrites and naturally occurring sources improve math metrics too, but with weaker effect-per-token.Source: §A.3.1 · p. 93
• Math midtraining is generally neutral to negative on MMLU, becoming more negative as the data becomes more targeted to math evaluations.The authors describe this specialization trade-off as “overcooking.”Source: §A.3.1 · p. 93

A.3.2 Code Capabilities

• Midtraining adds 10B tokens of fill-in-the-middle data to improve Python and code-completion capabilities.The data comes from the same source as the pretraining code mixture, while pretraining relies on naturally occurring GitHub source code from stack-edu.Source: §A.3.2 · p. 93

CraneCode

• CraneCode recreates SwallowCode using Python files, compilation and linting filters, and two stages of Qwen-based rewriting.The stages generate style-guide-compliant code and optimized code using prompts from the original SwallowCode work.Source: §A.3.2 · p. 93
• SwallowCode provided the greatest lift among considered off-the-shelf synthetic code sources but used the less-permissive Llama license.CraneCode was created to provide a fully open alternative, with quality checked through annealing experiments.Source: §A.3.2 · p. 93

A.3.3 Thinking Capabilities

• Olmo 3 targets seven structured reasoning capabilities through annotated math and coding problems, with GPT-4.1 and o4-mini generating capability-specific training data.The capabilities include self-awareness, self-evaluation, goal management, hierarchical organization, backward chaining, backtracking, and conceptual reasoning.Source: §A.3.3 · p. 94

A.4 Base Model Additional Evaluation Details

• The expanded OlmoBaseEval suite covers 43 tasks spanning science, medical knowledge, mathematics, coding, multilingual execution, and fill-in-the-middle programming.Code evaluation supports Python, C++, Java, JavaScript, PHP, Rust, and Shell, with parallel execution infrastructure grading millions of generated samples during development.Source: §A.4 · p. 95

A.4.1 Base Evaluation suites

• Base evaluation uses Easy and Main suites for data decisions, with Main tracking six groups and generative math and code already evaluated during pre-training.The Easy suite provides small-scale signals, while the Main suite supports in-loop and mid-training decisions.Source: §A.4.1 · p. 96, Figure 30 · p. 97
• The Base Easy suite ranks small models consistently with the downstream Base Main suite, supporting small-scale evaluation for large-scale model decisions.This relationship is presented through rank correlation between Easy and Main suite performance.Source: §A.4.1 · p. 96, Figure 31 · p. 98

A.4.2 New Evaluation Benchmarks

• New benchmarks measure basic skills, reduce generative-QA false negatives with generated multiple-choice distractors, and mask chat-style tokens for data-selection perplexity.BasicSkills isolates arithmetic, string manipulation, coding, logical reasoning, common sense, and pattern recognition; Gen2MC covers DROP, Jeopardy, NaturalQs, SQuAD, and CoQA.Source: §A.4.2 · p. 98

A.5.1 Definitions and Preliminaries

• Decontamination treats training–evaluation overlap as approximate substring search, partitioning training/evaluation pairs into contaminated and pure documents.The method distinguishes direct derivation from noise and source material while assuming contamination is sparse within the training corpus.Source: §A.5.1 · p. 101

A.5.2 Example of Contamination

• Because evaluation formats differ, decon uses structural differences among knowledge, reasoning, and retrieval tasks to distinguish direct evaluation derivations from source material.Knowledge evaluations often have short answers, reasoning evaluations longer answers, and retrieval evaluations substantial passages.Source: §A.5.2 · pp. 101–102

A.5.3 Eval Normalization

• Decon normalizes evaluation instances into question, answer, and passage components, using questions for initial identification and answers or passages as supporting contamination evidence.Instances may have Q, QA, QP, or QAP composition; passages alone are weak indicators but can strengthen a contamination call.Source: §A.5.3 · p. 102

A.5.4 Decon Implementation

• The decontamination pipeline discovers candidate clusters through inverted-index n-gram traversal, expands matches across edits or gaps, and maps evaluation documents to unique matching shingles.Hot n-grams bypass cluster expansion through single-token traversal, while active documents are removed after 11 misses; IDF-weighted overlap and precomputed evaluation sums support efficient scoring without string-to-string comparison.Source: §A.5.4 · pp. 102, 104

A.5.5 Scoring System

• Contamination scores combine question, answer, and passage overlaps with adaptive component weights, penalize shorter matches, and redistribute weight from low-confidence questions toward longer, more informative components.Answer and passage checks additionally require proximity to the question cluster, with IDF-weighted overlap and configurable gap tolerance.Source: §A.5.5 · p. 104, Base scores · p. 105

A.6.1 Supervised Finetuning Details

• Supervised fine-tuning uses packed 32,768-token sequences for two epochs, with 1M-token batches for 7B models and 4M-token batches for 32B models.Olmo-core infrastructure provides an 8x faster training speed than open-instruct; training uses 1–8 8xH100 or 1–4 8xB200 nodes for 7B and 32 8xH100 nodes for 32B.Source: §A.6.1 · p. 105, Table 47 · p. 105

A.6.2 Preference Tuning Details

• Preference tuning optimizes a length-normalized DPO objective regularized by an implicit KL penalty, while sweeping learning rate and preference-data size until task-dependent optima beyond which performance declines.All other hyperparameters remain fixed during the sweep, with 2–4 8xH100 nodes for 7B and 8–16 for 32B models.Source: §A.6.2 · p. 105, Table 48 · p. 106

A.6.3 Reinforcement Learning Details

• RL training steadily improved reward, response length, IfEval, general-quality, and math-verifier metrics, while code-verifier rewards fluctuated moderately and KL divergence increased gradually.These trends indicate simultaneous gains in specialized skills and overall response quality during the final 7B reasoner run.Source: §A.6.3 · p. 106

A.6.4 RL-Zero Details

• Olmo 3 RL-Zero reached reasonable performance faster and with greater compute efficiency than DAPO, while RL-Zero 3.1 eventually surpassed RL-Zero 3.0 by using 16k completions and unmasked truncated sequences.The newer setup initially improved more slowly but later plateaued near 50% on AIME 2024 and 2025 pass@1; masking reduced stability and did not improve total training efficiency.Source: §A.6.4 · p. 106, Figure 38 · p. 107, Figure 39 · p. 107

A.7.1 Filtering for Dolci Think-SFT

• Filtering removes licensing, provenance, formatting, accuracy, unsafe-content, repetition, date-cutoff, and Chinese-language problems from reasoning data, typically eliminating 0–1% per filtering phase.The pipeline removes truncated or empty outputs, heavily repeated text, and responses containing at least 5% Chinese characters, while applying domain-specific accuracy and safety checks.Source: §A.7.1 · pp. 107–108, Table 50 · p. 110

A.7.2 Tool-use data

• Tool-use and coding data are synthesized with grounded environment outputs, quality filters, multi-step interaction requirements, rewritten coding problems, generated solutions, and generated test cases.Science QA uses GPT-5 query generation and GPT-4.1-mini tool trajectories; web-search data retains highly rated, verified trajectories; coding synthesis uses GPT-4.1 across diverse source datasets.Source: §A.7.2 · pp. 108–109

A.7.4 Dolci Instruct DPO Details

• All prompt domains improve DPO tuning, but optimal domain ratios are difficult to determine because prompt domains do not reliably predict performance domains.Wildchat is capped at 35% of the base mix, while other prompts are uniformly sampled.Source: Table 51 · p. 113

A.8.1 General Evaluation Settings

• Post-training evaluations generate completions until end-of-sequence or maximum length, with unified settings across thinker and instruct models.Evaluations use temperature 0.6 and top-p 0.95, strip thinking traces, average multiple samples on small benchmarks, and apply unified regexes for QA extraction; AlpacaEval 2 LC uses GPT-4.1 judging to improve reliability and reduce inference costs by approximately 90%.Source: §A.8.1 · p. 114

A.8.2 Safety Evaluations Overview

• Safety evaluation combines existing OLMo 2 and Tülu 3 development suites with four held-out benchmarks: Toxigen, StrongReject, WMDP, and BBQ.Development evaluations include HarmBench, DoAnythingNow, XSTest, WildGuard-Test, WildJailbreak-Test, and TrustLLM-JailbreakTrigger.Source: §A.8.2 · pp. 114–115
• Safety scores are normalized so higher values indicate better safety, aggregating refusal, accuracy, attack-success, and error-rate metrics according to each benchmark’s protocol.Safety evaluations use top-p 0.95 and temperature 0.7; reported benchmark results are means of three runs.Source: §A.8.2 · p. 115, Table 52 · p. 115, Table 53 · p. 115