Fine-tuning gpt-oss-120b on H200 NVL or NVIDIA RTX PRO 6000 Blackwell Server Edition

Fine-tuning gpt-oss-120b: which hardware for which method

gpt-oss-120b can be fine-tuned with QLoRA on a single 96 GB or 141 GB card, with LoRA on a BF16 base across four cards, and with full fine-tuning only on an eight-card server that keeps the optimiser in host memory. The reason is that training frameworks dequantise the model's MXFP4 experts to BF16 first, which turns a checkpoint of about 65 GB into 233.7 GB of weights. For a BF16 LoRA we recommend four NVIDIA H200 NVL on a 4-way NVLink bridge; four NVIDIA RTX PRO 6000 Blackwell Server Edition cards hold the same run over PCIe at a lower step rate.

This article covers what is specific to gpt-oss-120b as a mixture-of-experts model. The per-parameter rules for dense models from 8B to 70B are in our guide to GPU memory for fine-tuning, and serving the model, users per card and the KV cache are in our page on gpt-oss-120b hardware requirements.

QLoRA figure from Unsloth's gpt-oss fine-tuning tutorial, read on 24 October 2026; other rows our arithmetic from the 116.83 billion parameters in OpenAI's model card (arXiv 2508.10925): 2 bytes per frozen BF16 weight, 16 bytes per parameter for a full fine-tune with 32-bit Adam and about 10 with 8-bit Adam, by the ZeRO paper's count. Activations come on top.

Why the MXFP4 checkpoint grows to 234 GB for training

OpenAI's model card gives gpt-oss-120b 116.83 billion parameters, 5.13 billion of them active per token, and a checkpoint of 60.8 GiB. The small size comes from the expert weights, which make up more than 90 per cent of the parameters and are stored in MXFP4 at 4.25 bits per parameter; attention, router, embeddings and output layer stay in BF16, as the model's config.json lists. That format is made for serving. Unsloth's tutorial states plainly: "No, currently no framework supports fp4 or MXFP4 training."

So the recipes upcast first. OpenAI's cookbook for gpt-oss-20b, dated 5 August 2025, loads the model with Mxfp4Config(dequantize=True) in BF16 and runs on "a single H100 GPU with 80GB of memory". The Databricks tutorial for gpt-oss-120b does the same and trains on eight H100 with FSDP. NVIDIA's blog on quantization-aware training of 29 August 2025 gives the reason: MXFP4 "hasn't yet proven stable accuracy" for fine-tuning, so the model is upcast to BF16 "to ensure stable gradient accumulation".

By our arithmetic 116.83 billion parameters at 2 bytes are 233.7 GB, or 217.6 GiB. Unsloth's BF16 conversion of the model on Hugging Face is a 234 GB repository, which matches. Unsloth's tutorial lists 210 GB of VRAM for a BF16 LoRA, less than the weights alone by our count; we plan on the larger figure.

QLoRA on one card

QLoRA stores the frozen base in 4 bits and trains a small adapter on top. Unsloth's tutorial gives "gpt-oss-120b = 65GB VRAM" for QLoRA, and our DGX Spark article quotes its figure of about 68 GB on that platform. Measured against the listed capacity of the cards, that leaves about 76 GB on an H200 NVL and about 31 GB on an RTX PRO 6000 Server Edition for longer sequences and larger batches.

This is the cheapest way to adapt gpt-oss-120b, and it needs no traffic between cards: a four-card server runs four such experiments side by side, one per card. Two points to plan for. The 4-bit base of a QLoRA run is a separate quantisation of the weights, not the MXFP4 of the original checkpoint, and the run trains a reasoning model, so the training examples should follow the harmony format the model is served with, with its analysis and final channels, as described on our gpt-oss-120b page. Unsloth's tutorial also documents merging the adapter and saving a 16-bit model, and exporting QLoRA models to GGUF.

We supply the H200 NVL and the RTX PRO 6000 Server Edition as cards or in servers built to order; send us your dataset size and the method you plan, and our team replies with the card count and the memory left per card.

LoRA on a BF16 base: four cards

When the team wants to train on the full-precision base, the 233.7 GB of frozen weights have to be split. The Databricks recipe shows the set-up: FSDP with full sharding, activation checkpointing, a micro-batch of one sequence of 2,048 tokens, rank 32 on all linear layers and rank 8 on the expert weights. PEFT reaches the experts through target_parameters, because gpt-oss stores each layer's experts as one parameter tensor rather than as separate linear layers; OpenAI's cookbook targets the experts of three layers this way.

The adapters themselves are small. A rank-16 adapter on the four attention projections of gpt-oss-120b has about 11.9 million weights across 36 layers, by our arithmetic from the hidden size of 2,880, 64 query heads and 8 KV heads of dimension 64; adapters on the experts add more, and the frozen base still accounts for nearly all of the memory.

Our arithmetic: 233.7 GB of BF16 weights divided by the cards, against the listed capacity of 141 GB per H200 NVL and 96 GB per RTX PRO 6000 Server Edition. What is left holds adapters, their optimiser states, activations, the CUDA context and buffers.

Two H200 NVL hold the run on paper, but 24 GB per card is too little to plan on for activations and the gathered layer. Four cards of either kind are the practical minimum.

What sharding an MoE model costs over PCIe and NVLink

Here gpt-oss-120b behaves differently from a dense 70B model. FSDP gathers each layer's full parameters before the forward pass and again before the backward pass, and for gpt-oss a layer's parameters include all 128 experts, although each token uses only four of them. The compute per token follows the 5.13 billion active parameters; the traffic follows all 116.83 billion.

By our arithmetic, on four cards each card holds a quarter of the 233.7 GB base and receives the other three quarters twice per forward and backward pass, about 350 GB. At 64 GB/s per direction on PCIe Gen5 that takes at least 5.5 seconds; over a 4-way NVLink bridge at 450 GB/s per direction, at least 0.8 seconds. On eight cards each receives about 409 GB per pass. The compute for a 2,048-token micro-batch is far smaller: about 4 × 5.13 billion × 2,048, or 42 TFLOP, for the forward pass and the backward pass through frozen weights, somewhat more with attention and activation checkpointing, a fraction of a second at the peak dense BF16 rates NVIDIA publishes, 835.5 TFLOPS for the H200 NVL and 503.8 for the RTX PRO 6000 Workstation Edition (NVIDIA publishes no dense rate for the Server Edition).

So a sharded gpt-oss-120b LoRA is limited by the link between cards, and the H200 NVL's NVLink is the better platform for it. Two rules follow for either card. The traffic is the same for every micro-batch whatever its size, so put as many tokens into each micro-batch as the memory allows, with packed or longer sequences. And keep the run inside one NVLink domain of four H200 NVL; on an eight-card server, run a second job on the other four cards. Our guide to the H200 NVL NVLink bridge shows how to check the domains with nvidia-smi topo -m.

On RTX PRO 6000 Server Edition cards the run works, at a lower step rate. NVIDIA's NCCL documentation states that "CUDA and the NVIDIA driver stack do not support IOMMU-enabled PCIe peer-to-peer memory transfer", so peer-to-peer settings belong in the acceptance test, as our RTX PRO 6000 P2P guide explains. We found no published step-time measurement of a gpt-oss-120b LoRA on either card, so these are lower bounds from link rates, not benchmarks.

Full fine-tuning: only with the optimiser in host memory

A full fine-tune trains every weight. At 16 bytes per parameter with 32-bit Adam that is 1,869 GB of model states, and about 1,168 GB with 8-bit Adam, by our arithmetic. Both exceed the 1,128 GB of eight H200 NVL before a single activation. OpenAI's model card says gpt-oss-120b "can be fine-tuned on a single H100 node", without naming the method.

On one node the route is DeepSpeed ZeRO stage 3 with optimiser offload. The ZeRO-Offload paper keeps the 16-bit parameters on the GPU and the 32-bit states and 16-bit gradients in host memory, 14 bytes per parameter. For gpt-oss-120b that is about 1,636 GB of host memory, and the 233.7 GB of BF16 parameters spread over eight cards come to 29.2 GB per card. Our eight-card training configuration with 2.3 TB of DDR5 holds that; a four-card server with 768 GB or 1,152 GB does not. The processors perform the parameter update, which makes each step slower than on the GPUs. The sizing of host memory and NVMe for such runs is set out in our article on the fine-tuning server with 2, 4 or 8 GPUs.

For most company use cases a LoRA is the better trade. A full fine-tune of gpt-oss-120b also writes resumable checkpoints of about 1.6 TB each at 14 bytes per parameter, by our estimate.

Back to MXFP4 for serving on one card

After a BF16 LoRA the merged model is a 233.7 GB BF16 checkpoint. It no longer fits one card: it needs two H200 NVL or four RTX PRO 6000 Server Edition cards to serve. To return to the MXFP4 format of about 65 GB that runs on one card, NVIDIA's blog and its TensorRT Model Optimizer example describe five steps: upcast to BF16, run the supervised fine-tune, insert quantisers with Model Optimizer, run quantization-aware training at a small learning rate (the example uses 1e-5), and convert the BF16-trained checkpoint to MXFP4 with the script convert_oai_mxfp4_weight_only.py.

NVIDIA reports that skipping the BF16 fine-tune and going straight to QAT gives lower accuracy, and that the MXFP4 checkpoints from this recipe have been tested with SGLang, TensorRT-LLM and vLLM. For gpt-oss-20b, its example raised a multilingual reasoning pass rate from 16 to 98 per cent. LMSYS's write-up of the same workflow notes that "After QAT, the model is still in the adapted BF16 weights" until the conversion runs. Plan the QAT pass on the same hardware as the fine-tune, since it trains the BF16 model again.

The served model then sizes like the original: one H200 NVL or one RTX PRO 6000 Server Edition holds it, with the users per card from our gpt-oss-120b page.

Which configuration to choose

Adapting style, format or domain vocabulary. QLoRA on one card. A server with two or four RTX PRO 6000 Server Edition cards runs several experiments at once and serves the result afterwards; our page to buy a 4× RTX PRO 6000 Server Edition server lists the build.

LoRA on the full-precision base, repeated regularly. Four H200 NVL on a 4-way bridge, with 1,152 GB of host memory; see our page to buy a 4× H200 NVL server. Its wall power is about 3.4 kW at 600 W per card with two AMD EPYC 9355, and about 2.7 kW at a 450 W cap, by our estimate (cards plus processors plus 15 per cent); a measurement on the delivered system confirms the figure.

Full fine-tuning, or LoRA plus a second job. Eight H200 NVL with two 4-way bridges, 2.3 TB of host memory and 400G, about 6.3 kW at the wall by the same estimate; our page to buy an 8× H200 NVL server has the details. Which card suits other models and methods is in our comparison of the best GPU for fine-tuning in 2026.

gpt-oss-120b is published under the Apache 2.0 licence, with a usage policy under which users agree to comply with all applicable law; whether the terms fit your use is for your legal department.

Ordering from us

You can buy this system from us: our team sizes the configuration to your workload and budget and replies within one business day. The server is assembled and tested before delivery, delivered in the EU on one contract and invoice, with manufacturer warranty on every component; operating system, drivers, CUDA and a container runtime are installed on request. Setting up the training pipeline and serving the tuned model is part of our Private AI/ML service with our engineering partner Vixen.UNO. Quantities and lead time are confirmed in writing with the quote. Describe your fine-tuning plan in the form below: the method, the dataset size, the sequence length and how the model will be served.

FAQ