Best Hardware for gpt-oss-120b: 64GB, 80GB, 96GB and Multi-GPU Paths

Short answer: for OpenAI’s gpt-oss-120b in the cited MXFP4 Transformers path, plan around at least 60GB of accelerator memory or a deliberate multi-GPU deployment. OpenAI says the model fits on one H100, making a qualified 80GB H100 the clearest first-party single-GPU reference. A supported 64GB system is only a bounded floor; 96GB Blackwell or 128GB-class unified-memory systems may add capacity, but software, architecture, context and runtime evidence still decide fit. Smaller GPUs are not one automatic shared pool.

Best gpt-oss-120b hardware paths

Path	Why evaluate it	Main safeguard
H100 80GB	OpenAI’s official single-GPU MXFP4 example	Identify PCIe, SXM or NVL; host, cooling and price differ
RTX PRO 6000 Blackwell 96GB	One current-generation CUDA pool with more nominal room	Verify MXFP4 kernels, workload peak and 600W-class system needs
DGX Spark / GB10 128GB unified	Large shared pool in a compact Blackwell system	Memory is shared with the Arm host; software and bandwidth differ from H100
Large-memory Mac	Unified capacity can hold compatible converted artifacts	The cited CUDA/Transformers path is not the Apple path
Multi-GPU	Documented tensor or expert parallelism can distribute the model	Topology, placement and per-device peaks matter
CPU/system-memory offload	Can make execution possible without one ≥60GB accelerator	It is a different performance path and must be measured

The official memory boundary

OpenAI’s official Transformers guide lists at least 60GB of VRAM for gpt-oss-120b in MXFP4, or a multi-GPU setup, and says the model fits on a single H100. The model page lists a 131,072-token context capability. Neither statement guarantees that every 64GB device, every H100 variant or every maximum-context request fits the same way.

• 64GB: only 4GB of nominal margin above the published floor; treat it as bounded.
• 80GB: the official H100-class reference tier; still specify context and concurrency.
• 94GB–96GB: more nominal room, subject to architecture and kernel support.
• 128GB+: useful for unified or distributed systems, but memory type, host sharing and software path differ.

Read the gpt-oss requirements guide and 48GB-through-96GB capacity guide.

Single-device decision paths

Most direct first-party path: H100 80GB

Start with the H100 deployment guide when reproducing the official class matters. PCIe 80GB, SXM 80GB and H100 NVL 94GB differ in form factor, power, cooling, interconnect and host needs. A bare SXM module is not a PCIe card.

Large workstation pool: RTX PRO 6000 Blackwell 96GB

Evaluate RTX PRO 6000 Blackwell when one 96GB dedicated pool and a workstation form factor are valuable. Do not infer gpt-oss throughput from capacity or peak AI specifications; confirm framework, kernel, driver, context and cooling.

Compact unified-memory path: DGX Spark / GB10

Evaluate DGX Spark and GB10 systems when an Arm-based Blackwell system and 128GB shared memory fit the deployment. The OS, CPU and GPU share that memory; verify Arm64 dependencies, runtime support and measured speed.

Large unified-memory Mac path

A large-memory Mac may hold a compatible converted artifact, but it does not run the cited CUDA/Hopper path. Treat MLX, Metal or llama.cpp support, format and measured throughput as separate evidence.

When multi-GPU is the right answer

OpenAI documents tensor and expert parallelism. That can make multiple GPUs valid, but 24GB + 24GB + 24GB is not automatically one 72GB pool. The runtime must place weights and experts while retaining per-device cache/workspace room. PCIe or NVLink/NVSwitch topology, CPU lanes and host RAM can affect performance.

Use the multi-GPU guide and record parallelism mode, tensor split, device count, per-device peak and interconnect.

Context and concurrency can erase headroom

• Context: 131,072 tokens is a capability, not proof the maximum fits a ≥60GB configuration.
• Cache precision and concurrency: both change memory pressure.
• Harmony/runtime support: the stack must implement the expected prompt and reasoning format.
• Architecture support: the cited MXFP4 path is kernel-specific; capacity cannot substitute for support.
• Offload: moving experts or tensors to host memory changes performance.

A purchase test for 120B-class hardware

1. Record the official model revision, weight format and runtime/container.
2. Identify accelerator, exposed memory, host architecture, driver and kernel path.
3. Fix prompt allocation, output target, cache precision, concurrency and reasoning settings.
4. For multi-GPU, record parallelism, placement, topology and every device’s peak memory.
5. Measure peak memory, time to first token and decode throughput.
6. Evaluate output quality and correct Harmony behavior.
7. Compare delivered price, power, cooling, noise, warranty and complexity.

Use the workload template, inspect the benchmark database, or submit a controlled gpt-oss-120b record.

Sources and limits

• Official OpenAI gpt-oss-120b model page
• Official OpenAI Transformers guide
• Official implementation-verification guide
• Official model repository
• HighVRAM methodology

Reviewed October 25, 2026. The ≥60GB and single-H100 statements are OpenAI guidance for the cited MXFP4 path. HighVRAM has not independently benchmarked every system. Inclusion is not endorsement or ranking.