[prototype] Expert Parallel #714
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
[ghstack-poisoned]
tianyu-l
added a commit
that referenced
this pull request
Dec 3, 2024
ghstack-source-id: b4d3f46f9519f4a478fca22b5665bf72bfe01409 Pull Request resolved: #714
facebook-github-bot
added
the
CLA Signed
The expert-choice MoE implementation is mostly from torchtune: pytorch/torchtune#1902 The PR requires (ad hoc) changes to pytorch: pytorch/pytorch#141937 Issue tracking: - [ ] [dp2ep] how to apply FSDP only to the non-MoE modules? - [ ] [dp2ep] `shard_dim_alltoall` not robust (especially during backward with more than 1D) - [ ] [tp2ep] backward efficiency may not optimized (e.g. right now `aten.scatter.src` only supports [replicate](https://github.com/pytorch/pytorch/blob/main/torch/distributed/tensor/_ops/_tensor_ops.py#L368) sharding prop) - [ ] [tp2ep] using DTensor (e.g. in "tp2ep"), the backward `aten.scatter.src` requires `_allow_implicit_replication` (maybe because in backward some tensor is not generated as DTensor) - [ ] some other issues tracked in pytorch/pytorch#141937 - [ ] `torch.compile` fails on `torch.topk` Haven't worked on - softmax scoring instead of sigmoid (can be done similarly, would incur extra communications) - part of DP (e.g. CP) to EP Not considering - shared expert overlapping - token-choice MoE [ghstack-poisoned]
tianyu-l
added a commit
that referenced
this pull request
Dec 3, 2024
ghstack-source-id: d03719eb6b659c319631bed9b276d6bac6e7df8d Pull Request resolved: #714
lessw2020
reviewed
Dec 4, 2024
| if self.use_sigmoid: | ||
| scores = torch.sigmoid(scores.to(torch.float32)).to(x.dtype) | ||
| else: | ||
| scores = F.softmax(scores.to(torch.float32), dim=0).to(x.dtype) |
There was a problem hiding this comment.
one comment here - it's not clear imo if the optimal order is softmax and then topk, or topk and then softmax.
It does not change the routing, but it changes the weights.
In my nanogpt MoE it has the option to toggle the ordering.
|
somehow I lost access to this ghstack, moving to #725 instead |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Stack from ghstack (oldest at bottom):
The expert-choice MoE implementation is mostly from torchtune: pytorch/torchtune#1902
The PR requires (ad hoc) changes to pytorch: pytorch/pytorch#141937
Issue tracking:
fully_shard)shard_dim_alltoallnot robust (especially during backward with more than 1D)aten.scatter.srconly supports replicate sharding prop)aten.scatter.srcrequires_allow_implicit_replication(maybe because in backward some tensor is not generated as DTensor)torch.compilefails ontorch.topkHaven't worked on
Not considering