Support CUDA Graph for MoE models

[buptzyb]

Description

Different from non-MoE models like llama2, MoE models have dynamic shaped activations in FFN layers, so one cudagraph can only capture a part of one transformer layer, instead of covering the whole layer. We call this a "breaking-layer" cudagraph mode. This PR adds breaking-layer cudagraph supports for MoE models on the TE side, and fixes several related bugs in TE.

Fixes # (issue)

Type of change

• Documentation change (change only to the documentation, either a fix or a new content)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Infra/Build change
• Code refractor

Changes

Please list the changes introduced in this PR:

• Add is_initialized() method in CudaRNGStatesTracker to align with what is already done in MCore.
• Fix wrong per_callable_module_params order bug in _make_graphed_callables when _order is given.
• Fix warmup argument mismatch bug in _make_graphed_callables when _order is given.
• Fix fp8 accuracy issue by adding fp8_group argument to make_graphed_callables() and modifing is_first_microbatch, skip_fp8_weight_update and fp8_meta code.
• Support MoE models cudagraph by filtering graphed TE modules and model weights during warmup.

Checklist:

• I have read and followed the contributing guidelines
• The functionality is complete
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[timmoon10]

Technically this seems mostly reasonable, although I have questions and stylistic suggestions. Have you tested that it works with Mcore?

@ptrendx @ksivaman @sbhavani What is our priority for this feature? The custom Mcore logic in make_graphed_callables is already messy and fragile, and this PR does exacerbate those problems.

[timmoon10]

This change seems correct to me, but it's odd if the Mcore integration was working before. @ksivaman Have we run this with Mcore, or did we run with num_microbatches=1?

This changes the interpretation of per_callable_module_params from (num_chunks, layers_per_chunk, num_microbatches) to (num_chunks, num_microbatches, layers_per_chunk). This matches the interpretation of per_callable_* lists when capturing graphs:

TransformerEngine/transformer_engine/pytorch/graph.py

Lines 237 to 239 in 3b89c36

	per_callable_fwd_idx = (m_chunk * num_microbatches * num_layers) + (
	fwd_idx[m_chunk] * num_layers + l_no
	)

[timmoon10]

TE modules don't set or read the is_first_microbatch attr. It's a kwarg in the forward function. Also, this assumes callables contains torch.nn.Modules.

Suggested change

	for module in func.modules():
	if hasattr(module, "is_first_microbatch"):
	module.is_first_microbatch = True

[yifeis-nv]

Thank you for the reminder. I also believe that modifications are needed here. The change we originally intended to address is the issue where the fp8 weight caching behavior in MoE leads to different behaviors for the first microbatch compared to other microbatches. If we do not include this piece of code, the warmup process will update is_first_microbatch to False, causing all captured graphs to exhibit non-first microbatch behavior, which does not align with our requirements. Therefore, we chose to reset this parameter after warmup.

In summary, our requirement is either to prevent is_first_microbatch from being updated during warmup or to reset is_first_microbatch after warmup. Choosing the former may require adding a flag to inform MoE that it is currently in the warmup phase, while choosing the latter might necessitate making this code a bit more general. Do you have any input on the modification plan that could serve as a reference for us?

[timmoon10]

I see, so this is Mcore-specific logic. It's uncomfortable that it's made its way into TE, but it's a tricky problem and I can't think of a better solution either, at least without significant changes in Mcore.

We should document what this is doing, especially for TE developers with no knowledge of Mcore.

[timmoon10]

Why are we skipping the FP8 scale update logic for this case?

Suggested change

	if (
	not fp8_recipe.fp8_mha
	and not fp8_recipe.fp8_dpa
	and hasattr(m, "attention_dropout")
	and m.deterministic
	):
	continue

[yifeis-nv]

This is for a deterministic test with FP8. Even without CUDA graphs, we find that FP8_DPA leads to random output, even when set to deterministic mode. With CUDA graphs, we not only need to set DPA to BF16, but also skip the FP8_meta update for DPA. After that, we will finally obtain a stable output under the deterministic test.

[timmoon10]

It seems like we're covering up a correctness bug. This may also affect convergence since we are no longer doing amax reductions within MHA (e.g. for the FP8 cast before qkv and proj).

[yifeis-nv]

It makes sense, and I think we should 'continue' without fp8_mha and fp8_dpa, regardless of whether the test is deterministic or not.

[timmoon10]

Actually, this change will cause correctness issues. We do a max all-reduce on the amaxes so that FP8 scaling factors are synchronized over the TP group. If we skip the amax reduction, then the MHA's TP communication will be wrong. In particular, we'll all-gather FP8 inputs to the qkv GEMM, but the scaling factors will be different for each TP rank. In pseudocode:

def mha_qkv(x_local, w_local, x_fp8_scale):
    x_local_fp8, x_amax = cast_to_fp8(x, x_fp8_scale)
    x_fp8 = all_gather(x_local_fp8)
    y_local = gemm(x_fp8, w_local, x_fp8_scale)
    max_all_reduce(x_amax)  # Without this, x_fp8_scale is different between ranks
    update_fp8_scale(x_fp8_scale, x_amax)
    return y_local

Turns out this isn't relevant, since MultiheadAttention is not a TransformerEngineBaseModule.

[timmoon10]

As far as I can tell, this logic is specific to DotProductAttention. We could make intent much more obvious with:

Suggested change

	if (
	not fp8_recipe.fp8_mha
	and not fp8_recipe.fp8_dpa
	and hasattr(m, "attention_dropout")
	and m.deterministic
	):
	continue
	if (
	isinstance(m, DotProductAttention)
	and not fp8_recipe.fp8_mha
	and not fp8_recipe.fp8_dpa
	):
	# Don't need to update FP8 meta for non-FP8 DPA
	continue

[timmoon10]

/te-ci pytorch

[yaox12]

/te-ci pytorch

[buptzyb]

Have you tested that it works with Mcore?

Yes, we also made some changes in Mcore, together with TE changes in this PR, to enable MoE cudagraph. You can refer to issue 193 in our Megatron-LM repo.

[yaox12]

/te-ci pytorch