[Pytorch] MOE Sequential Block - #3350
Conversation
Signed-off-by: Varun Thumbe <[email protected]>
…h error handling tests 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]>
for more information, see https://pre-commit.ci
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
for more information, see https://pre-commit.ci
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
for more information, see https://pre-commit.ci
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]>
for more information, see https://pre-commit.ci
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
for more information, see https://pre-commit.ci
Signed-off-by: Varun Thumbe <[email protected]>
Signed-off-by: Varun Thumbe <[email protected]>
…/TransformerEngine into enable_extra_out_consumption
Signed-off-by: Varun Thumbe <[email protected]>
for more information, see https://pre-commit.ci
| # 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) |
There was a problem hiding this comment.
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:
TransformerEngine/transformer_engine/common/activation/scaled_activation.cu
Lines 403 to 405 in d7340a4
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.
| raise TypeError( | ||
| "NCCL EP Dispatch supports MXFP8Quantizer only, got " | ||
| f"{type(input_quantizer).__name__}." | ||
| ) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Handling fallback via BF16 comms
Signed-off-by: Varun Thumbe <[email protected]>
for more information, see https://pre-commit.ci
…ffer) and allow mxfp8 combine through env variable Signed-off-by: Varun Thumbe <[email protected]>
for more information, see https://pre-commit.ci
Signed-off-by: Varun Thumbe <[email protected]>
…merEngine into dispatch_combine_op
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]>
…merEngine into dispatch_combine_op
Signed-off-by: Varun Thumbe <[email protected]>
|
/te-ci L1 pytorch |
| """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 |
There was a problem hiding this comment.
Why do we need this ref impl btw?
| # Only BF16 dispatch is supported for now. | ||
| input_ = maybe_dequantize(input_, torch.bfloat16) |
There was a problem hiding this comment.
Can we error out instead of falling back to dequantize?
| device=device, | ||
| ) | ||
| else: | ||
| grad_out = validate_buffer( | ||
| "MXFP8 grad_out storage", | ||
| grad_out, | ||
| device=device, | ||
| contiguous=True, |
There was a problem hiding this comment.
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_) |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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.
Signed-off-by: Varun Thumbe <[email protected]>
for more information, see https://pre-commit.ci
Signed-off-by: Varun Thumbe <[email protected]>
|
/te-ci L1 pytorch |
Description
Please include a brief summary of the changes, relevant motivation and context.
Fixes # (issue)
Type of change
Changes
Please list the changes introduced in this PR:
Checklist: