This week’s practical question: when does gpt-oss move from a 16GB consumer-GPU problem to a 48GB workstation or 80GB-class accelerator problem? OpenAI’s published guidance makes the boundary unusually clear, but only when format, GPU generation and complete-workload headroom remain attached to the numbers.
One model family, three hardware decisions
| Workload | Published boundary | Practical decision |
|---|---|---|
| gpt-oss-20b MXFP4 | OpenAI: approximately 16GB; cited path supports Hopper or later, including RTX 50-series | Tight supported 16GB, 24GB/32GB headroom, or 48GB when the workload justifies it |
| gpt-oss-20b bfloat16 | OpenAI: approximately 48GB | Treat 48GB as a loading class, not guaranteed room for cache, buffers and concurrency |
| gpt-oss-120b MXFP4 | OpenAI: at least 60GB or multi-GPU; fits on one H100 | Bounded 64GB, H100 80GB, 96GB, compatible unified memory or deliberate multi-GPU |
Why “16GB” is not the whole 20b answer
The approximately 16GB figure belongs to a specific MXFP4 Transformers path. OpenAI states that the cited path requires Hopper-or-later hardware, including RTX 50-series consumer cards. A nominal 16GB capacity on an older architecture does not prove equivalent format or kernel support.
Even on a supported card, the label is a tight boundary. Display memory, runtime workspaces, KV cache, prompt length, output length and concurrency still consume memory. The 16GB comparison therefore starts with software support and measured workload behavior rather than gaming tier.
Why active parameters do not set the memory floor
OpenAI describes gpt-oss-20b as 21B total with 3.6B active parameters and gpt-oss-120b as 117B total with 5.1B active parameters. Active parameters describe MoE routing per token; the inactive experts do not vanish from stored-weight memory. Size from the published runtime requirement or exact artifact, then add the complete workload.
The new contribution path
The benchmark submission builder now includes separate gpt-oss-20b and gpt-oss-120b workload starters. Each fills only the model identity and MXFP4 format prompt. It leaves hardware, revision, runtime, Harmony handling, context, concurrency, timing, repetitions and every measured value blank. Nothing is saved or submitted unless the visitor explicitly uses those controls.
- Load the matching starter in the benchmark builder.
- Record exact hardware, device count, exposed memory and topology.
- Record model revision, runtime/version, format and Harmony handling.
- Fix prompt, output target, context, cache, batch and concurrency.
- Report warm-ups, repetitions, timing boundary and peak memory.
- Keep prompt processing, time to first token and decode throughput separate.
The benchmark database remains a fixed snapshot of 43 metric observations from seven sources. It preserves source-specific definitions and does not yet establish a universal gpt-oss hardware winner.
Turn the boundaries into a buying decision
- Use the VRAM calculator as an explainable planning range, then validate in the intended runtime.
- Compare RTX 5090 32GB with the 48GB deployment paths when 20b headroom, bfloat16 or other workloads drive the purchase.
- Use the GPU comparison directory for exact hardware pairs.
- Stage a private browser watchlist for either 20b RTX 50-series or 120b single-device paths; presets do not save until explicitly requested.
Published October 25, 2026. The ~16GB, ~48GB, ≥60GB, architecture and single-H100 statements are OpenAI guidance for the cited Transformers path. HighVRAM has not independently benchmarked every configuration. Capacity does not establish speed, output quality or value.
Delivery note: this is a web and RSS edition. Email signup and delivery remain inactive. Follow the main RSS feed or browse the digest archive.