Skip to content

[Pytorch] MOE Sequential Block - #3350

Open
vthumbe1503 wants to merge 97 commits into
NVIDIA:mainfrom
vthumbe1503:dispatch_combine_op
Open

[Pytorch] MOE Sequential Block#3350
vthumbe1503 wants to merge 97 commits into
NVIDIA:mainfrom
vthumbe1503:dispatch_combine_op

Conversation

@vthumbe1503

Copy link
Copy Markdown
Collaborator

Description

Please include a brief summary of the changes, relevant motivation and context.

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 refactoring

Changes

Please list the changes introduced in this PR:

  • Change A
  • Change B

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

vthumbe1503 and others added 30 commits July 28, 2026 23:05
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
…/TransformerEngine into enable_extra_out_consumption
# Make sure inputs are in correct dtype
# Prepare the activation input in the compute dtype.
input_ = maybe_dequantize(input_, dtype)
scales = maybe_dequantize(extra_input, dtype)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks suspicious to me, but I think it's fine.

I see that the TE scaled activation kernel can handle different dtypes for input, scales, and output:

TRANSFORMER_ENGINE_TYPE_SWITCH_NON_FP8ONLY(input->data.dtype, InputT, {
TRANSFORMER_ENGINE_TYPE_SWITCH_NON_FP8ONLY(act_scales->data.dtype, ScaleT, {
TRANSFORMER_ENGINE_TYPE_SWITCH_NON_FP8ONLY(output->data.dtype, OutputT, {

I suppose there is some weirdness since we could be ignoring the dtype from torch.autocast. However, this is treated as an auxilliary tensor that behaves more like the MoE splits than like a real data tensor.

Comment thread transformer_engine/pytorch/ops/basic/dispatch.py
raise TypeError(
"NCCL EP Dispatch supports MXFP8Quantizer only, got "
f"{type(input_quantizer).__name__}."
)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We want basic ops to be a safe fallback, so they should handle any quantizer. If we get a non-MXFP8 quantizer, then the correct behavior is to dequantize and perform the communication in high precision.

@vthumbe1503 vthumbe1503 Aug 28, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Handling fallback via BF16 comms

Comment thread transformer_engine/pytorch/ops/basic/dispatch.py
Comment thread transformer_engine/pytorch/ops/basic/dispatch.py Outdated
Comment thread transformer_engine/pytorch/ops/basic/dispatch.py Outdated
Comment thread transformer_engine/pytorch/ops/basic/combine.py Outdated
Comment thread transformer_engine/pytorch/ops/basic/dispatch.py Outdated
Comment thread transformer_engine/pytorch/ops/fused/moe_ep.py Outdated
Comment thread transformer_engine/pytorch/ops/fused/moe_ep.py Outdated
@vthumbe1503

Copy link
Copy Markdown
Collaborator Author

/te-ci L1 pytorch

Comment on lines +5 to +8
"""Pure PyTorch semantic reference for a SwiGLU MoE with expert parallelism.

The implementation deliberately favors readable semantics over performance. It
supports a one-rank execution path and a variable-size ``all_to_all_single`` EP

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need this ref impl btw?

Comment on lines +143 to +144
# Only BF16 dispatch is supported for now.
input_ = maybe_dequantize(input_, torch.bfloat16)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we error out instead of falling back to dequantize?

Comment on lines +115 to +122
device=device,
)
else:
grad_out = validate_buffer(
"MXFP8 grad_out storage",
grad_out,
device=device,
contiguous=True,

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't we need the grad_out to be contiguous when not MXFP8?

expert_out = input_
if zero_copy:
expert_out = _alloc_io(tuple(input_.shape), torch.bfloat16, input_.device, True)
expert_out.copy_(input_)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need this .copy_(input_)? Is it a deep or shallow copy?

zero_copy = buffer.zero_copy
expert_out = input_
if zero_copy:
expert_out = _alloc_io(tuple(input_.shape), torch.bfloat16, input_.device, True)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should only allocate this when callers do not provide grad_expert_out.
Besides, it seems not to handle allocation for grad_expert_out_scales when using MXFP8 right now.

@vthumbe1503

Copy link
Copy Markdown
Collaborator Author

/te-ci L1 pytorch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants