Every section so far built one piece. This one takes a real, recent model and shows where each piece went. OLMo 3 (Allen Institute for AI (artificial intelligence), released in late 2025) is a family of 7B and 32B models (7 and 32 billion parameters) whose authors published everything needed to rebuild them: the data, the training code (OLMo-core), the exact configuration scripts, the intermediate checkpoints and a 118-page report. Every number on this page comes from the report (Olmo Team, 2025), the official training scripts in OLMo-core, or the released model configuration on Hugging Face. Where a number is the result of a calculation of ours, the page says so.
This page covers the base model (pre-training, mid-training, long-context extension); the post-training of OLMo 3 into its Instruct and Think models belongs to section 12. Each part has a short example, and the exercises rebuild the numbers: the parameter count from the configuration, the attention pattern, one OLMo 3 block at toy size, the z-loss and its gradient, and the arithmetic of the training run.
The recipe in three stages
A base model is not trained in one go on one kind of data. It goes through three stages, each on different data, each with its own goal.
| Stage | 7B | 32B | Context |
|---|---|---|---|
| 1. Pre-training | 5.93T | 5.5T | 8,192 |
| 2. Mid-training | 100B | 100B ×2 | 8,192 |
| 3. Long context | 50B | 100B | 65,536 |
(Tokens per stage: T is trillions, B is billions. The context is the number of tokens the model reads at once. The data mixes are called Dolma 3 Mix, Dolma 3 Dolmino Mix and Dolma 3 Longmino Mix.)
- Pre-training is one pass (one epoch) over the mix: the official 32B script sets
max_duration=Duration.epochs(1). The 32B run follows the same cosine schedule as a full epoch but stops early, at 5.5T tokens. - Mid-training continues from that checkpoint on 100B tokens selected to boost math, code and question answering, and includes instruction data and reasoning traces to prepare for post-training. For the 32B it was run twice with different data orders, and the two resulting models were averaged weight by weight: the new model's weight is the mean of the two models' weights, matrix entry by entry.
- Long context teaches the model to use 65K-token contexts.
Example. Averaging two models weight by weight: if one model has the weight at some position of some matrix and the other has , the averaged model has there, and the same is done for every weight. The result has the size of one model, not two.
Adding up the three stages of the 7B gives tokens (our sum).
The data
Dolma 3 Mix is built from a 9.31-trillion-token pool of cleaned, deduplicated text (a document that appears many times is kept once). The mix is the part of the pool actually used:
| Source | Share of the 5.93T mix |
|---|---|
| Common Crawl web pages | 76.1% |
| olmOCR science PDFs (Portable Document Format files of academic papers, turned into text) | 13.6% |
| Stack-Edu code from GitHub | 6.89% |
| FineMath math web pages | 2.56% |
| arXiv papers | 0.86% |
| Wikipedia & Wikibooks | 0.04% |
"One epoch" over the mix does not mean every document is seen once. The mix itself upsamples some sources: code is 137B tokens in the pool and 409B in the mix, so it is repeated about three times, while most of the web pool is left out.
Example. The web share of the mix is tokens (our product). Code: , so each token of the code pool appears about 3 times in the mix.
Tokenizer
The tokenizer is the one of OLMo 2, derived from OpenAI's cl100k byte-level BPE (byte-pair encoding, section 6): 100,278 tokens in the released model, padded to a multiple of 128 during training so that the embedding matrix has dimensions that suit a GPU (graphics processing unit).
Example. Rounding 100,278 up to the next multiple of 128 gives : 74 extra rows in the embedding matrix that no token uses (our arithmetic).
The architecture
OLMo 3 is a decoder-only transformer (a stack of blocks like that of section 7, with causal attention), with the same block for every layer:
| 7B | 32B | |
|---|---|---|
| Layers | 32 | 64 |
| Model dimension | 4096 | 5120 |
| Query heads | 32 | 40 |
| Key/value heads | 32 | 8 |
| Feed-forward hidden size | 11,008 | 27,648 |
| Parameters | 7,298,011,136 | 32,233,522,176 |
The parameter counts are those of the released checkpoints; one exercise derives them from the table. With 32 key/value heads for 32 query heads, the 7B has multi-head attention (MHA); with 8 for 40, the 32B has grouped-query attention (GQA), both from section 7. The feed-forward part of each block is an MLP (multilayer perceptron). Each head has numbers, for both sizes. Inside each block, in the order the data flows, there are seven ingredients. We go through them one at a time.
1. Projections without biases
Queries, keys and values come from linear layers with no bias terms: only the weight matrix. The 32B uses grouped-query attention with 8 key/value heads for 40 query heads, so each key/value head serves query heads (section 7).
2. QK-norm
QK-norm is an RMSNorm (root mean square layer normalization, section 4) on the projected queries and on the projected keys, before attention. It keeps the attention logits from becoming too large, which can make the training loss diverge (Dehghani et al., 2023).
Example. Suppose a query vector grew to and the key to the same. Their dot product is , and after the softmax all the attention goes to one token. After RMSNorm, , and so the key, and their dot product is . Whatever the size of the projection, the score stays bounded.
3. Rotary embeddings with
RoPE (rotary position embedding, section 7) with instead of the original 10,000: OLMo 2 raised it to increase the resolution of the positional encoding. A larger base makes the slower pairs of numbers turn even more slowly.
Example. Head size means 64 pairs. The slowest pair turns by radians per position: with that is , a full turn every positions; with it is , a full turn every million positions (our arithmetic). Positions much farther apart than 54,000 tokens would otherwise look alike to the slowest pair.
The released code pairs dimension with (the "rotate half" layout), which is equivalent to the adjacent-pair layout of section 7 up to a permutation of the weights.
4. Sliding-window attention
In three layers out of four, tokens attend only to the previous 4,096 tokens (Beltagy et al., 2020): this is sliding-window attention. Every fourth layer, and always the last, uses full attention. This keeps the cost and the KV (key-value) cache of long contexts manageable (the cache is the memory of the keys and values of all previous tokens, section 11).
Example. In a model of 8 layers the types are: sliding, sliding, sliding, full, sliding, sliding, sliding, full. With a window of 3, the token at position 4 sees positions 2, 3 and 4 in a sliding layer, and positions 0 to 4 in a full layer.
For a sequence of 65,536 tokens, a sliding layer keeps 4,096 keys instead of 65,536: . In the 32-layer model, 24 layers are sliding and 8 are full, so the cache is of what it would be with full attention everywhere. The 64-layer model has the same ratio (our arithmetic).
5. A SwiGLU MLP
The MLP of each block is the SwiGLU (Swish-gated linear unit) of section 7: three matrices, the second branch gating the first.
6. Reordered norm
RMSNorm is applied to the output of attention and of the MLP, before the residual addition, instead of to their input as in the LLaMA (Large Language Model Meta AI) block of section 7 (introduced for OLMo 2, following Liu et al., 2022):
where is the stream entering the block, the stream after attention and the output of the block.
Example. Suppose attention outputs . With the norm on the output, what is added to the stream is times the learned gain: the correction of each sub-layer has a controlled size, whatever the attention produced.
7. Embeddings, output layer and long-context scaling
The input embedding and the output layer are separate matrices (not tied), and a final RMSNorm precedes the output layer. For the long-context stage, RoPE on the full-attention layers is rescaled with YaRN (Peng et al., 2023), from the 8,192 positions seen in training to 65,536.
Counting the parameters
With these ingredients one can count every parameter from the configuration. A tiny example (toy sizes, our own): tokens, , 2 layers, 2 query heads and 1 key/value head of size , MLP size .
Example. Per layer:
- attention: is , and are each, is : total ;
- QK-norm gains: ;
- MLP: three matrices of : ;
- two RMSNorms of size 8: .
That is per layer, for two. Add the two embedding matrices and the final norm : parameters.
The same count for the 7B (32 layers of parameters each, two embedding matrices of , and the final norm of ) gives exactly , the number of the released checkpoint.
The loss
The training loss is the next-token cross-entropy of section 2, plus a small z-loss:
where is the cross-entropy, is the log-sum-exp of each position's logits, and the bar is the mean over positions. Softmax does not change if every logit is shifted by a constant, so nothing stops the logits from drifting to huge values; the z-loss pulls towards 0 and keeps them bounded. PaLM (Pathways Language Model) introduced it with weight (Chowdhery et al., 2022); OLMo 3 uses .
Example. Logits , right class 0: and . The z-loss term is .
Now add 100 to every logit: the softmax and the cross-entropy are unchanged (), but , and the z-loss term becomes : a penalty against the drift.
Optimizer and schedule (32B pre-training)
From the official OLMo-3-1025-32B-pretrain.py script and the report's Table 35:
- AdamW (Adam with decoupled weight decay, section 3) with and weight decay 0.1, except on the embeddings, which get no weight decay.
- Learning rate: linear warmup over 2,000 steps to a peak of , then cosine decay towards (truncated at 5.5T tokens). The 7B uses a peak of .
- Batch: 1,024 sequences of 8,192 tokens, 8,388,608 tokens per step: about 656,000 steps for 5.5T tokens. The 7B uses half that batch.
- Gradient clipping at a global norm of 1.0 (section 3).
- Skipped steps: the optimizer (
SkipStepAdamW) skips an update when the loss or the gradient norm is more than 6 standard deviations above its mean over the last 128 steps, a guard against single bad batches. - Precision: BF16 (brain floating point) weights for computation, gradients reduced in FP32 (32-bit floating point) (section 8).
Example. The batch: tokens. Steps: , rounded up to steps: the "about 656,000" above.
The skip rule: if the loss over the last 128 steps had a mean of and a standard deviation of , a step whose loss is above would be skipped.
Hardware, parallelism and cost
The 32B was trained on a cluster of NVIDIA H100 GPUs (80 GB (gigabytes) each), 8 per node, with the OLMo-core library on PyTorch, torch.compile, FlashAttention kernels (Dao, 2024) and asynchronous checkpointing.
- Parallelism: HSDP (hybrid sharded data parallelism), the variant of FSDP (Fully Sharded Data Parallel) of section 9: the model states are sharded across groups of 64 GPUs, and 16 such groups are replicas, 1,024 GPUs in total. Activation checkpointing is limited to a memory budget of 50%. The long-context stage adds context parallelism, which splits each 65K-token sequence across 8 GPUs.
- Throughput: 1,960 tokens per second per GPU for the 32B and 7,700 for the 7B, which the report puts at about 41% and 43% MFU (model FLOPs utilization, section 8).
- Time: pre-training took about 9.5 days on 512 GPUs and then 35 days on 1,024 GPUs, crashes and restarts included; with mid-training and the long-context stage, about 47 days. From the start of training to the evaluated 32B Think model, about 56 days on 1,024 GPUs, which at $2 per H100-hour the report prices at $2.75M.
Example. The numbers check each other (our arithmetic).
- At 1,960 tokens per second per GPU on 1,024 GPUs the cluster processes million tokens per second, so 5.5T tokens would take days if nothing ever went wrong. The real run took days, with half the GPUs at the start, plus crashes and restarts.
- The pre-training used GPU days.
- The cost: 56 days times 1,024 GPUs times 24 hours times $2 is $2,752,512, about $2.75M: the figure of the report.
References
- Olmo Team, Olmo 3, arXiv, 2025. Sections 2.4 (costs) and 3.2 (architecture and training), Tables 4 (data), 33 (architecture), 34 (parallelism and throughput) and 35 (hyperparameters).
- Olmo Team, 2 OLMo 2 Furious, arXiv, 2024 (COLM 2025). Section 2.1: RMSNorm, reordered norm, QK-norm, z-loss and RoPE , inherited by OLMo 3.
- Allen Institute for AI, OLMo-core: the training library and the official scripts in
src/scripts/official/OLMo3/. - Released configurations: Olmo-3-1025-7B and Olmo-3-1125-32B; the reference implementation in Hugging Face Transformers,
modeling_olmo3.py. - M. Dehghani et al., Scaling Vision Transformers to 22 Billion Parameters, ICML, 2023. QK-norm.
- Z. Liu et al., Swin Transformer V2: Scaling Up Capacity and Resolution, CVPR, 2022. Normalizing the output of each sub-layer.
- I. Beltagy, M. E. Peters, A. Cohan, Longformer: The Long-Document Transformer, arXiv, 2020. Sliding-window attention.
- B. Peng, J. Quesnelle, H. Fan, E. Shippole, YaRN: Efficient Context Window Extension of Large Language Models, arXiv, 2023.
- A. Chowdhery et al., PaLM: Scaling Language Modeling with Pathways, arXiv, 2022. Section 5: the z-loss.
- T. Dao, FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning, ICLR, 2024.