Follow-ups for restoring fp32 masters without optimizer state
Maintainers usually reply within 3 days
@tjruwase is already working on this.
Since Oct 22, 2026.
Assessment
This issue has not been assessed yet.
Description
A fresh-optimizer resume (load_optimizer_states=False) can restore the saved fp32 master weights through DeepSpeedEngine.load_checkpoint(..., load_fp32_weights=None). None inherits zero_optimization.load_from_fp32_weights (default True). load_module_only=True still rebuilds the masters from the loaded bf16/fp16 weights.
Two cases are unsupported when that flag stays True, because the masters live in the per-rank *_optim_states.pt shards alongside Adam's moments:
- A
parameter_alignmentchange, which is usually also a data-parallel size change. The saved partitions do not match the new buffers. - A checkpoint that has no
*_optim_states.ptfiles.
Those resumes should keep failing. load_from_fp32_weights=False is the supported way to skip the shard and rebuild the masters. The alignment RuntimeError still tells the caller to disable optimizer-state loading, which is not sufficient: load_optimizer_states=False with the default config still opens the shard.
The items below do not fail current unit tests and can land separately.
ZeRO-3 serial checkpoint load can hang
zero_optimization.pipeline_loading_checkpoint receives the serial token in _load_zero_checkpoint before the data-parallel world-size check (deepspeed/runtime/engine.py, the dist.recv on every local rank except 0). A non-MoE resume that then returns early, because the saved fp32 partitions cannot be resized, never reaches the dist.send in stage3.py load_state_dict. Rank 0 returns and the next local rank waits.
tests/unit/checkpoint/test_zero_optimizer.py::test_pipeline_checkpoint_loading does not hit this. It reloads at the same world size with load_module_only=True.
ZeRO-3 MoE is not this case. A data-parallel size change with optimizer states off still loads the shard, because the expert weights live there.
Master-only tests accept a stale initial master
Several assertions only check that the masters sit on the bf16 grid and differ from the saved fp32 values. A master left at its initial ones passes both checks. Compare the loaded master to the bf16 rounding of the saved master.
Missing coverage
- ZeRO-3 rigid and universal
refresh_fp32_paramswhenload_fp32_weights=False. - The dedicated
BF16_Optimizerpath (ZeRO stage 1, bf16 parameters, fp32 gradient accumulation). - fp16.
load_optimizer_states=Truetogether withload_fp32_weights=False: moments load, masters are rebuilt.- A data-parallel size change that still requests optimizer states raises
ZeRORuntimeException.
ZeRO-3 NVMe load_module_only=True refreshes an empty fp32 buffer
load_module_only=True calls refresh_fp32_params() inside _load_checkpoint before the NVMe branch in load_checkpoint. A swapped ZeRO-3 subgroup stores its fp32 partition as torch.empty(0). _restore_from_bit16_weights copies the fp16 partition into that empty tensor and raises, so the fp32 swap file is never copied.
A data-parallel size check on the NVMe branch does not cover this. The refresh throws first. A same-size NVMe load with load_module_only=False and load_optimizer_states=False still copies the fp32 swap file.
- Dominant language
- Python
- Stars
- 43.3k
- Forks
- 5.1k
- Avg merge
- 4d 21h
- Merged PRs (30d)
- 66
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from deepspeedai/DeepSpeed
-
[BUG] Universal checkpoint resume puts CPU `step` into fused/capturable optimizer statePossibly taken @ArjunPakhan claimed this 3 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
deepspeedai/DeepSpeed#8884 · 1 comment ·
Maintainers usually reply within 3 days
-
init_inference rejects dtype=torch.int8 on every acceleratorMay be free again A pull request for this issue was closed without being merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
deepspeedai/DeepSpeed#8577 ·
Maintainers usually reply within 3 days
-
[BUG] AutoTP checkpoint load raises AttributeError on a model containing nn.InstanceNorm1dPossibly taken @vineethsaivs claimed this 41 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
deepspeedai/DeepSpeed#8514 ·
Maintainers usually reply within 3 days
-
[BUG] Python checkpoint writers fail to reload full ZeRO-3 state with default torch.loadPossibly taken @ai-yang claimed this 43 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
deepspeedai/DeepSpeed#8500 ·
Maintainers usually reply within 3 days
-
[BUG] set_norm_for_param_grad_in_gpu's grad_accum fallback is dead in both accumulation modesPossibly taken @LOGO127 claimed this 52 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
deepspeedai/DeepSpeed#8371 ·
Maintainers usually reply within 3 days
All issues in deepspeedai/DeepSpeed
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
NVIDIA/flare-local-inference#90 ·
Maintainers usually reply within 1 day
-
area/streaming comp/gateway P2 platform/telegram type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
NousResearch/hermes-agent#144897 ·
Maintainers usually reply within 1 day
-
request-theme
Difficulty 1/5 Under an hour Newbie friendliness 66/100
LizardByte/ThemerrDB#9575 ·
Maintainers usually reply within 1 day
-
author-page correction
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
acl-org/acl-anthology#10599 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
zilliztech/memsearch#818 ·
Maintainers usually reply within 1 day