gpt-oss 120B vs 20B (2026): Which One Should You Run?
The two gpt-oss checkpoints are not a small-and-large pair of the same purchase. gpt-oss 20B is a 16GB-card model, gpt-oss 120B is a 96GB-card model, and the gap between them is roughly a factor of five in memory and a factor of ten in price. This page maps each model to the hardware that actually holds it, using sizes read from the published config files, and names the one caveat almost every 20B guide leaves out: at its full 128K window the 20B no longer fits 16GB.
Bottom Line
- These are two different purchases, not two sizes of one. 20B targets a 16GB card. 120B targets a 96GB card or a 128GB unified box.
- gpt-oss 20B: 21B parameters, 3.6B active per token, weights 13.76 GB as displayed on Hugging Face (14GB Ollama tag), MXFP4.
- gpt-oss 120B: 117B parameters, 5.1B active per token, weights 61.48 GB on Hugging Face (65GB Ollama tag), MXFP4.
- The 20B does not fit 16GB at its full window. Weights 12.8 GiB plus a 3.0 GiB cache is 15.8 GiB on a 16 GiB card. Run it at short context, or buy 24GB.
- The 120B does not fit 64GB at all. The weights alone exceed it before you allocate any context.
- The active-parameter gap is small. 5.1B against 3.6B is 1.4x, not 5x. You are buying knowledge, not throughput.
- Neither model is cache-hungry. Both spend half their layers on a 128-token sliding window, which is why a 21B model here costs less cache than a dense 8B model does.
The Two Checkpoints, Side by Side
Every field below comes from the config.json and file listing published with openai/gpt-oss-20b and openai/gpt-oss-120b, read on 6 September 2026.
| Field | gpt-oss 20B | gpt-oss 120B |
|---|---|---|
| Total parameters | 21B | 117B |
| Active parameters per token | 3.6B | 5.1B |
num_hidden_layers | 24 | 36 |
layer_types | alternating sliding / full | alternating sliding / full |
| Full-attention layers | 12 | 18 |
sliding_window | 128 | 128 |
num_key_value_heads | 8 | 8 |
head_dim | 64 | 64 |
num_local_experts / num_experts_per_tok | 32 / 4 | 128 / 4 |
max_position_embeddings | 131,072 | 131,072 |
quant_method | mxfp4 | mxfp4 |
| Weights, Hugging Face shards | 13.76 GB (3 shards) | 61.48 GB (15 shards) |
| Weights, Ollama tag | 14GB | 65GB |
Two rows deserve attention. The expert count is where the parameters went: 32 experts against 128, at the same 4 experts per token. And the active parameters barely moved. That combination is the whole design. The 120B stores far more and computes only a little more.
The Memory Arithmetic
The KV cache holds one key and one value per key-value head, per layer, per token. Both models use 8 key-value heads and a head dimension of 64, so at fp16 the per-layer, per-token cost is identical:
2 (K and V) x 8 (kv heads) x 64 (head_dim) x 2 bytes = 2,048 bytes = 2 KiB
Only the full-attention layers grow with context. The sliding layers hold 128 tokens each, permanently.
| gpt-oss 20B | gpt-oss 120B | |
|---|---|---|
| Full layers x 2 KiB | 12 x 2 KiB = 24 KiB/token | 18 x 2 KiB = 36 KiB/token |
| Cache at 131,072 tokens | 3,221,225,472 B = 3.0 GiB | 4,831,838,208 B = 4.5 GiB |
| Sliding layers, total | 12 x 128 x 2,048 = 3.0 MiB | 18 x 128 x 2,048 = 4.5 MiB |
| Weights (GiB) | 12.8 GiB | 57.3 GiB |
| Full-window total | 15.8 GiB | 61.8 GiB |
Six times the parameters costs 1.5 GiB more cache. That is the sliding window doing its work, and it is why neither of these models is limited by context memory. They are limited by weights.
Where the 16GB Claim Breaks
OpenAI’s model card says gpt-oss 20B is designed to “run within 16GB of memory.” That is true, and it is the sentence every other guide repeats without qualification.
Here is the qualification. A 16GB card has 16 GiB. The weights take 12.8 GiB. That leaves about 3.2 GiB, and the full-window cache is 3.0 GiB. The two numbers nearly cancel, which means at 131,072 tokens you have roughly 200 MiB left for the compute buffer, the activations, the runtime and, on a desktop, the display output. In practice you will not get there.
So the 16GB claim is a short-context claim. For chat and for coding turns of a few thousand tokens, a 16GB card is genuinely enough and the model is comfortable. For an agent that fills its window — and local agents break in exactly this way — 16GB is not enough, and no cache-quantisation setting rescues it cheaply. Halving 3.0 GiB frees 1.5 GiB, which buys headroom but costs quality.
If you want gpt-oss 20B at its full window, buy 24GB. That is the real recommendation and almost nobody makes it.
What to Buy for Each Model
Prices below are as of August 2026 and move week to week under the ongoing memory shortage. Treat them as ranges, not quotes.
| Your intent | Model | Memory you need | Hardware |
|---|---|---|---|
| Chat and short coding turns | 20B | 16GB | RTX 5060 Ti 16GB |
| 20B at the full 128K window | 20B | 24GB | RTX 3090 24GB |
| 120B on one GPU, fastest | 120B | 96GB | RTX PRO 6000 Blackwell 96GB |
| 120B on a desk box, cheaper | 120B | 128GB unified | NVIDIA DGX Spark 128GB |
Two notes on that table.
The 24GB row is the one to think about, because it is the cheapest way to run gpt-oss at a full window with room to spare. A 24GB card holds the 20B weights, the full cache and the runtime with about 8 GiB free.
The 96GB and 128GB rows are the same model at different speeds, not different capability. A 96GB card runs the 120B faster because its memory bandwidth is far higher. A 128GB unified box runs the same model at lower tokens per second for a fraction of the price. Our DGX Spark verdict covers that tradeoff, including how much the software stack changes the result on the same hardware.
Which One Is Actually Better For You
Model choice here is not a quality ranking. It is a memory budget.
Choose the 20B if you own a 16GB or 24GB card, you want fast local answers, and your prompts are ordinary length. The 3.6B active parameters make it quick, and quick matters more than clever for most agent loops.
Choose the 120B if you already have 96GB of VRAM or a 128GB unified machine. Do not buy that hardware for this model alone. Buy it because it opens the whole 100B-plus tier, of which this is one member — see the best models for 96GB of VRAM and DeepSeek V4 Flash vs gpt-oss 120B for what else lands there.
The honest caveat: the jump from 3.6B to 5.1B active parameters is 1.4x, so do not expect the 120B to feel five times better. It knows more. It does not reason five times harder. If the 20B is failing your work, name the failure first, because the fix is often context configuration rather than a bigger checkpoint.
See Also
- MXFP4 vs Q4_K_M — why every gpt-oss quant is within 1.3% of the same size, so you should take the official MXFP4 build
- How Much VRAM Does gpt-oss 120B Need at Full 128K Context? — the full arithmetic for the larger model
- Best Local LLM for 96GB of VRAM — where the 120B sits among its peers
- Is 16GB of VRAM Still Enough in 2026? — the tier question behind the 20B
- Best Local LLM for the RTX 5060 Ti 16GB — the 16GB card in detail
- Best Local LLM for the RTX 3090 — the 24GB step up
- Is the DGX Spark Worth It? — the 128GB unified route to the 120B
- DGX Spark Price: Every GB10 Box Compared — the $4,699 list price, its February increase, and every OEM GB10 box beside it
- Context Window Traps for Local Agents — why the full-window case is not hypothetical
Sources
- openai/gpt-oss-20b config.json (Hugging Face) — 24 layers, alternating layer types,
sliding_window128, 8 KV heads,head_dim64, 32 experts, read 2026-09-06 - openai/gpt-oss-20b file listing (Hugging Face) — 3 safetensors shards totalling 13.76 GB as displayed, read 2026-09-06
- openai/gpt-oss-20b model card (Hugging Face) — “21B parameters with 3.6B active parameters”, “117B parameters with 5.1B active parameters”, “run within 16GB of memory”, “fit into a single 80GB GPU”, read 2026-09-06
- gpt-oss tags (Ollama library) — 14GB for
20b, 65GB for120b, 128K context on both, read 2026-09-06
Every memory figure on this page is arithmetic derived from published config fields, not a measured allocation. Runtimes add their own buffers, and a runtime that ignores the sliding window will reserve double the cache shown here. Check what your loader actually reserved.
Need OpenClaw fixed live?
Remote rescue sessions for gateway, auth, tunnel, VPS, and model access problems.
See Rescue Session