These two models are natively MXFP4, so the usual GGUF quant ladder barely moves the file size. The real decision is not F16 vs Q8 vs Q4. It is just 20B or 120B, and it is decided by the task and by what fits in your memory.
Every format for both models. Notice the bars inside each column are almost the same length: quantizing gpt-oss changes the total size by a rounding error, because roughly 90 percent of the weights are experts frozen at MXFP4 in every row.
| Format | gpt-oss-20B | gpt-oss-120B | |||
|---|---|---|---|---|---|
| MXFP4 native release (safetensors) | 13.76 GB | 65.25 GB | as shipped | ||
| GGUF F16 “original precision” | 13.79 GB | 65.37 GB | skip | ||
| GGUF Q8_0 | 12.11 GB | 63.39 GB | |||
| GGUF Q4_K_M smallest of the four | 11.62 GB | 62.77 GB | leanest | ||
The one rule that saves you a download: skip F16 GGUF. A genuine full upcast would be about 43 GB (20B) and 241 GB (120B). The F16 GGUF is only 13.8 and 65.4 because llama.cpp keeps the experts in MXFP4 and upcasts only the small attention and embedding tensors. You pay ~2 GB extra for precision that was never in the weights to begin with.
A naive F16 conversion would triple the file for zero quality gain. What actually ships stays small because the expert weights are locked at 4.25-bit MXFP4 no matter the label. Each pair below is on its own scale.
Practical read: for gpt-oss there is no meaningful size-vs-quality dial inside a model. Take native MXFP4 (or equivalently the MXFP4 / Q8_0 GGUF), or Q4_K_M if you want the last half-gig. Unsloth measured even a 2-bit build performing "nearly the same" as F16, because only the tiny non-expert slice is affected. The quant question is basically solved. The model-size question is the whole game.
Official scores, high reasoning effort, sorted by the size of 120B's lead. The advantage is concentrated in health, agentic tool use, and graduate-level knowledge. On saturated contest math and on SWE-bench, the small model is right there with it.
Before you reach for the bigger model, know that gpt-oss has a low / medium / high effort dial, and it swings scores harder than the 20B-to-120B jump does. Here is 120B on AIME 2025, no tools. Many chat apps default to low.
Since quant is a non-decision, the crossover is purely 20B vs 120B, governed by the task and by memory. Here is the split, then how it lands on your actual machine.
The bars show each model's weight footprint against what your hardware can hold. The 20B lives on the GPU. The 120B only works because your GPU absorbs ~16 GB of it, leaving ~47 GB for system RAM instead of the full 63.
Verdict for your machine: run 20B MXFP4 as the fast daily driver, and keep 120B Q4_K_M for the hard health, knowledge, and tool-use questions where +13 to +19 points is worth dropping to a slower speed. Take Q4_K_M for the 120B specifically, because its 0.6 GB saving over Q8_0 is free headroom for your KV cache on a 64 GB box. If you find yourself living in the 120B, the upgrade that matters is more system RAM, not a bigger GPU.
Sources and caveats. Sizes: exact bytes from HuggingFace repos openai/, ggml-org/, and unsloth/ gpt-oss GGUF, verified against the HF API blobs endpoint. Benchmarks: OpenAI gpt-oss model card (arXiv 2508.10925), high reasoning effort, pass@1, no-tools variant where a model reports both. Param counts are HuggingFace's exact safetensors totals (21.5B / 120.4B); OpenAI's marketing rounds these to 21B / 117B. The naive-upcast figures (~43 / ~241 GB) are total-params × 2 bytes, a stated hypothetical, not a real download. The 2-bit quality note is from Unsloth and is community-sourced.