OpenAI’s gpt-oss models make the headline hardware choice look simple: the 20B model targets systems with 16 GB of memory, while the 120B model fits on a single 80 GB GPU. Those are useful deployment floors, but context length, concurrency, runtime overhead, and KV cache growth still decide whether a real workload fits.
The short answer
gpt-oss-20b: 20.91B total parameters, 3.61B active parameters, a 12.8 GiB checkpoint, and 24 layers. OpenAI says it can run on systems with as little as 16 GB of memory.
gpt-oss-120b: 116.83B total parameters, 5.13B active parameters, a 60.8 GiB checkpoint, and 36 layers. OpenAI says it fits on a single 80 GB GPU.
The active-parameter number describes the approximate compute used per token. It does not replace the full checkpoint size when you estimate storage or memory residency.
Why active parameters do not set VRAM
Both models use mixture-of-experts layers and MXFP4 quantization for their expert weights. Only a subset of experts is active for each token, which reduces compute. The complete model artifact still has to be stored and made available to the runtime, so hardware planning should start with the published checkpoint size rather than multiplying active parameters by four bits.
The 128K context boundary
Both configurations specify eight key-value heads, a head dimension of 64, and a maximum context length of 131,072 tokens. A conservative full-cache allowance is roughly 6 GiB for gpt-oss-20b and 9 GiB for gpt-oss-120b at the full context window. Actual runtimes may use sliding-window attention, paged caches, or other optimizations, so measured usage can be lower.
That difference matters. A short 4K request can fit comfortably where a full-context workload does not, even before you add parallel users or runtime workspace.
Four numbers to check before choosing hardware
Checkpoint size: use 12.8 GiB for 20B or 60.8 GiB for 120B as the published artifact baseline.
Context length: choose the longest prompt-plus-generation workload you actually intend to serve.
Concurrent requests: KV cache and runtime allocations grow as more sequences run together.
Reserve: leave headroom for the runtime, allocator fragmentation, kernels, and operating system.
Four practical planning scenarios
20B at 4K: about 14.3 GiB after checkpoint, conservative KV cache, and 10% reserve. One 16 GB device is a reasonable floor.
120B at 4K: about 67.2 GiB with the same assumptions. One 80 GB device has useful headroom.
20B at 128K: about 22.6 GiB with 20% reserve. A 24 GB device can be too tight once usable-memory limits are applied.
120B at 128K: about 83.8 GiB with 20% reserve. Plan beyond a single 80 GB card for this conservative full-context case.
The interactive worksheet exposes every assumption, including checkpoint size, context, concurrency, precision, reserve, accelerator count, and usable-memory percentage.
