Short answer: OpenAI’s official Transformers guide lists approximately 16GB of VRAM for gpt-oss-20b in MXFP4 and at least 60GB for gpt-oss-120b in MXFP4, or a multi-GPU setup. It also gives approximately 48GB for gpt-oss-20b when loaded in bfloat16. These are runtime- and format-specific starting points, not universal guarantees: KV cache, context, concurrent sequences, buffers, other GPU users and hardware support still affect the complete requirement.
Do not size from the active-parameter number. OpenAI describes gpt-oss-20b as 21B total/3.6B active and gpt-oss-120b as 117B total/5.1B active. The active count describes per-token MoE routing; it does not make either model occupy the memory of a dense 3.6B or 5.1B model.
gpt-oss-20b vs gpt-oss-120b VRAM at a glance
| Official model | Total / active parameters | Official memory guidance | Practical implication |
|---|---|---|---|
| gpt-oss-20b, MXFP4 | 21B / 3.6B active | ~16GB VRAM | Targets a supported 16GB-class stack, but complete-workload headroom must be checked |
| gpt-oss-20b, bfloat16 | 21B / 3.6B active | ~48GB | 48GB is a tight documented loading figure, not spare capacity for every context and concurrency |
| gpt-oss-120b, MXFP4 | 117B / 5.1B active | ≥60GB or multi-GPU | 64GB is the first common label above the published floor; H100-class 80GB is the official single-GPU example |
Can gpt-oss-20b run on 16GB?
OpenAI lists approximately 16GB of VRAM for gpt-oss-20b when using MXFP4, so 16GB is an official target—not a generic guarantee. A capacity label alone does not establish compatibility. OpenAI’s guide says the cited MXFP4 path is supported on Hopper or later architectures, including H100/GB200 and RTX 50-series cards. Other runtimes or converted formats may have different support and memory behavior.
When the model allocation approaches the full label, the desktop, display, KV cache, runtime workspaces and longer requests can still create an out-of-memory condition. Verify the runtime’s estimate and measure peak device memory with the actual context and workload.
What changes with gpt-oss-20b in bfloat16?
OpenAI gives approximately 48GB for the 20B model in bfloat16. That is three times the approximate MXFP4 guidance and illustrates why a model name alone is not a memory specification. A 48GB accelerator should not be described as having abundant headroom if the documented model load itself is around 48GB; cache and runtime allocations still need space or deliberate placement elsewhere.
Can gpt-oss-120b run on one GPU?
Yes, on a suitable accelerator and supported stack. OpenAI states that gpt-oss-120b requires at least 60GB of VRAM or a multi-GPU setup and says the MXFP4 model fits on a single H100. The model page describes 117B total parameters with 5.1B active parameters and a 131,072-token context window.
“Fits on H100” should not be generalized to every 80GB device or every maximum-context workload. GPU architecture, kernels, cache precision, prompt length, output length, batching and neighboring allocations matter. A 64GB label is above the published floor, but compatibility and usable headroom still require evidence.
What about multiple GPUs?
OpenAI documents tensor parallelism and expert parallelism for gpt-oss-120b with Transformers, Accelerate or torchrun. That is deliberate distributed placement—not automatic VRAM pooling. Each device needs sufficient per-device headroom, and communication topology can affect measured speed. Confirm the runtime’s placement plan rather than adding capacity labels and assuming one shared pool.
Capacity tiers for gpt-oss
| Available memory | Reasonable first question | Do not assume |
|---|---|---|
| 16GB | Does the exact gpt-oss-20b MXFP4 runtime support this GPU and leave enough working room? | That every 16GB GPU supports the cited path |
| 24–32GB | Can gpt-oss-20b keep weights, cache and buffers on one GPU with the intended context? | That more capacity automatically makes the runtime fast |
| 48GB | Is MXFP4 headroom or the approximate bfloat16 load the actual target? | That the bfloat16 figure leaves room for every workload |
| 64GB | Does the supported gpt-oss-120b MXFP4 deployment remain below the complete-workload peak? | That clearing the ≥60GB floor proves compatibility |
| 80GB+ | Which accelerator, context, concurrency and runtime match the official H100-class path? | That capacity alone establishes throughput or value |
A reproducible validation checklist
- Choose gpt-oss-20b or gpt-oss-120b and record the exact model revision.
- Record the weight format—MXFP4, bfloat16 or another runtime-specific conversion.
- Confirm GPU architecture, driver, framework, kernel and harmony-format support.
- Set the intended prompt length, maximum output, cache precision and concurrency.
- Measure peak device memory during the longest representative request.
- Record throughput separately; capacity is not a speed benchmark.
- For multi-GPU, record the parallelism method and each device’s peak allocation.
Sources and limits
- Official OpenAI gpt-oss-20b model page
- Official OpenAI gpt-oss-120b model page
- Official OpenAI Transformers guide
- Official OpenAI implementation-verification guide
- HighVRAM methodology
Reviewed October 25, 2026. Memory figures are OpenAI’s published guidance for the cited formats and software paths. HighVRAM has not independently benchmarked every configuration. Capacity does not establish speed, output quality or value.
Choosing hardware for the smaller model? Use the gpt-oss-20b GPU buyer guide to compare supported 16GB MXFP4, 24GB/32GB headroom and the documented 48GB bfloat16 class.
Choosing a complete deployment? Use the gpt-oss-120b hardware buyer guide to compare bounded 64GB, H100 80GB, RTX PRO 6000 96GB, DGX Spark, Mac and deliberate multi-GPU paths.