nemo_automodel.components.moe.fsdp_mixin
nemo_automodel.components.moe.fsdp_mixin
Module Contents
Classes
Functions
Data
API
Mixin for managing FSDP synchronization state during MoE model training.
Controls gradient sync and resharding for FSDP-wrapped modules to optimize performance during gradient accumulation steps.
Usage differs based on parallelism strategy:
- Without pipeline parallelism (PP): prepare_for_grad_accumulation() defers sync and resharding at the start of gradient accumulation. prepare_for_final_backward() enables sync and resharding before the last backward pass. FSDP’s autograd hooks automatically handle post-backward synchronization and resharding.
- With pipeline parallelism (PP): FSDP state management is handled by patching
_PipelineStageBase.backward_maybe_with_nosync (see patched_backward_maybe_with_nosync
below). By default (
distributed.defer_fsdp_grad_sync: true) the patch disables sync/resharding for all backwards except the last one before the optimizer step, where it manually triggers post-backward hooks and resharding. Withdefer_fsdp_grad_sync: falseevery micro-batch reduce-scatters its own gradients (after its full or weight backward); the input backward of a split schedule never reduces or reshards, and resharding/finalization is deferred to the last backward so that pending split weight backwards still find the unsharded parameters.
Enable gradient sync and resharding for the final backward pass.
Parameters:
Whether pipeline parallelism is enabled.
When PP is enabled, FSDP state management is handled by the patched _PipelineStageBase.backward_maybe_with_nosync method. This method only applies optimizations for non-PP cases.
Prepare FSDP states before starting gradient accumulation.
Parameters:
Whether pipeline parallelism is enabled.
When PP is enabled, FSDP state management is handled by the patched _PipelineStageBase.backward_maybe_with_nosync method. This method only applies optimizations for non-PP cases.
Yield every FSDP unit whose backward state this mixin must drive, deduplicated.
A unit that is not yielded here never receives set_is_last_backward /
set_reshard_after_backward / set_requires_gradient_sync, so it drops
out of the gradient-accumulation state machine and, under pipeline
parallelism, out of patched_backward_maybe_with_nosync.
Let FSDP’s hooks reduce-scatter this micro-batch’s gradients; reshard and finalize only on the last backward.
Used for a full backward under distributed.defer_fsdp_grad_sync: false. A split
weight backward for an earlier micro-batch may still be pending (mixed schedules such
as F0 I0 F1 B1 W0) and looks the parameters up by their unsharded objects, so the
parameters must stay unsharded until the actual last backward.
Run FSDP’s post-backward (reduce-scatter) manually for every FSDP unit of a MoE module.
With last_backward (the default) the units are also resharded and the root final
callback finalizes the step; otherwise the parameters stay unsharded for the backwards
still to come and only the gradients are reduced.
Run post-backward for every FSDP state and return the root final callback.
Both the per-state post_backward() calls and the returned callback
tolerate FSDP modules that never ran forward in this step. With
FusedLinearCrossEntropy under pipeline parallelism the lm_head
weight is consumed inside the loss function, so its FSDP module never
runs forward and its FSDPCommContext is never lazily initialized;
post_backward() then raises AttributeError ('FSDPCommContext' object has no attribute 'post_forward_order'). A never-forwarded group
has no gradients to reduce, so it is safe to skip.
Whether using PP with FSDP or DDP, there are some runtime differences between the last backward step and the other steps. Namely, we need to accumulate gradients on previous steps and reduce them on the last step, but there are additional state-variables and performance considerations depending on the data parallelism used. This helper should adapt any pipeline parallel schedule to work with common/supported data parallel libraries.