perf(checkpoint): bound GPT-OSS MXFP4 loading - #3623
Draft
yuhezhang-ai wants to merge 1 commit into
Draft
Conversation
Signed-off-by: Yuhe Zhang <yuhez@nvidia.com>
Contributor
Author
|
/ok to test |
@yuhezhang-ai, there was an error processing your request: See the following link for more information: https://docs.gha-runners.nvidia.com/cpr/e/1/ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this changes
GPT-OSS MXFP4 checkpoints currently take the full-CPU fallback on one GPU:
This PR removes that fallback for the maintained GPT-OSS adapter on one GPU:
_extra_stateentries remain initialized because they are not stored in Hugging Face checkpoints.The result is 25 load parts: one part for ordinary tensors and one part for each of the 24 decoder layers. The largest
compressed temporary allocation is 0.39 GB. Final expert weights may be BF16 or FP32.
This uses the bounded-load interface added by the parent PR (#3619). It does not add another checkpoint framework or
change distributed GPT-OSS loading. Partial decoders, distributed expert tensors, and unsupported model dtypes keep
their existing path.
Why
gpt_oss_20b_single_gpu_peft.yamlis an active one-GPU recipe targeting DGX Spark. Loading a complete BF16 CPU modelbefore filling the GPU model is especially expensive on a system where CPU and GPU allocations share physical memory.
It is also slow because MXFP4 conversion runs on CPU.
Real GPT-OSS 20B result
Slurm job
16311724loaded the officialopenai/gpt-oss-20b13.76 GB MXFP4 checkpoint on one H100. Branch, parent,and branch ran as fresh processes in the same non-exclusive one-GPU allocation. The checkpoint was already present in
a local snapshot and the harness used offline mode, so downloads are not included.
Using the more conservative first branch run, checkpoint loading is 4.7x faster. Peak process RSS falls by
46.65 GiB (93%), and simultaneous process RSS plus CUDA allocation falls by 43.44 GiB (49%).
CUDA allocation rises by 3.78 GiB during loading because one layer's compressed tensors and conversion workspace now
live on GPU. That is much smaller than the removed CPU model copy, so the combined footprint is still roughly halved.
The parent spent 28.56 seconds converting MXFP4 on CPU. This PR completed all GPU-side conversion in 0.36 seconds;
the remaining 6.76 seconds in the first run were DCP storage reads.
All three runs reported the same parameter L2 norm (
256972.9989) and completed a finite one-token forward pass.Scoped recipe CI
The active
gpt_oss_20b_single_gpu_peftrelease recipe passed all 50 training steps on one GB10/DGX Spark GPU injob 407428835. It loaded the checkpoint in 25
parts with a largest compressed temporary allocation of 0.39 GB, reported the same parameter norm
(
256972.9989), and kept finite loss and gradients throughout training. Reported training memory stayed near 45 GiB.Checkpoint loading took 401.90 seconds in this CI run, of which 387.50 seconds was reading from the S3-mounted CI
cache. This run is correctness and memory-safety evidence; the local-snapshot H100 A/B above is the speed comparison.
Validation
ruff format --checkandruff checkon the changed files_extra_state, partial-decoder, unsupported-dtype, and distributed-fallback tests16311724