-
Notifications
You must be signed in to change notification settings - Fork 505
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MoE #639
base: main
Are you sure you want to change the base?
MoE #639
Changes from 130 commits
e725eb9
db24750
18450de
4ab7f77
dba42fd
6c5f8a3
6a8e089
1a9a317
ddf6fd4
ab55e07
7aeefd4
3eab45c
6d736da
d07c638
cdb592f
1399841
a13b5b8
935167e
b96972d
0079490
8b1c441
e2c7286
d39a37c
3acfc04
4432261
cef7707
2a6df33
7421890
021974e
d5a0626
fce086f
daa7c91
3a40b7f
2676d03
2fb4c96
448a9a8
e361918
9377aa5
bad3a34
3dbd156
a6496d6
5dd6135
195c77d
4ea9f0a
44fa5ae
b7658eb
16edece
f8e061f
c8a51cf
b95a05f
20103ec
459ef27
84f21db
08d3253
4b07140
cf6fa33
d95f978
3c15abf
4163e70
aae0e0b
76e6e6d
31e387b
f631d8e
142720b
412a55e
669bba5
7d90908
3c97519
6e08b09
1a6a2e2
103e450
48b6c14
8a387fa
3203724
5309137
bf66e68
63c12e1
1c4aa8d
6a94263
b58c316
3bbfaed
364659f
15f5503
6c516d8
8a0758e
c23b048
285ff10
99aec31
a43eae8
aaefc58
270271f
c084d34
6789ee2
f084fa0
14ee7e4
f831adf
26eb3f3
0a3b076
d6ccbf0
6a2c17e
9ccb2f1
f5291ec
ed571a8
71d2d2a
8b72521
fc822a0
1ccaf9a
c157441
06b8010
cf31e53
a750fde
c853a43
bea80ec
dfdcfc5
4606598
f6c707d
76f0376
9631c80
2fa2acb
c517703
b4eb33f
ae6f16a
02781be
a62a1ee
0ecd4b8
d8452a0
8a28ced
91f5553
61ac104
f4faf8a
fdc1021
ed82181
b0cc754
ca9b41f
215c0f5
43baf74
775e514
cd0004b
acb23dd
a143469
1a4bdae
410064a
671bc8e
04a2da5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -19,6 +19,7 @@ | |
|
||
import numpy as np | ||
import torch | ||
import torch.nn.functional as F | ||
from omegaconf import DictConfig, ListConfig | ||
from omegaconf import OmegaConf as om | ||
from omegaconf.errors import OmegaConfBaseException | ||
|
@@ -198,6 +199,11 @@ class BlockType(StrEnum): | |
implementations of operations like attention to imitate the behavior of Llama. | ||
""" | ||
|
||
moe = "moe" | ||
""" | ||
A block for OLMoE-style Mixture-of-Experts models. | ||
""" | ||
|
||
|
||
class InitFnType(StrEnum): | ||
mitchell = "mitchell" | ||
|
@@ -457,6 +463,61 @@ class ModelConfig(BaseConfig): | |
See :data:`TrainConfig.precision` instead. | ||
""" | ||
|
||
moe_num_experts: Optional[int] = 8 | ||
""" | ||
The number of experts to use in the MoE block. | ||
""" | ||
|
||
moe_top_k: Optional[int] = 2 | ||
""" | ||
The number of experts to select for each token. | ||
""" | ||
|
||
moe_mlp_impl: Optional[str] = "sparse" | ||
""" | ||
Choose "grouped" for grouped GEMM installable via `pip install git+https://[email protected]/tgale96/grouped_gemm.git@66c7195e35e8c4f22fa6a014037ef511bfa397cb`. | ||
""" | ||
|
||
moe_log_expert_assignment: Optional[bool] = True | ||
""" | ||
Whether to log the expert assignment. | ||
""" | ||
|
||
moe_shared_expert: Optional[bool] = False | ||
""" | ||
Whether to have an always-used expert like in [DeepSeekMoE](https://arxiv.org/abs/2401.06066). | ||
""" | ||
|
||
moe_lbl_in_fp32: Optional[bool] = False | ||
""" | ||
Whether to perform load balancing in FP32. | ||
""" | ||
|
||
moe_interleave: Optional[bool] = False | ||
""" | ||
Interleave sequential with MoE blocks starting with sequential. | ||
""" | ||
Muennighoff marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
moe_loss_weight: Optional[float] = 0.1 | ||
""" | ||
The weight to use for the MoE load balancing loss. | ||
""" | ||
|
||
moe_zloss_weight: Optional[float] = None | ||
""" | ||
Weight for MoE router z-loss where None means no router z-loss. 0.001 is a common value. | ||
""" | ||
|
||
moe_dropless: Optional[bool] = True | ||
""" | ||
Whether to use [dMoE](https://arxiv.org/abs/2211.15841). | ||
""" | ||
|
||
moe_capacity_factor: Optional[float] = 1.25 | ||
""" | ||
The capacity factor to use in the MoE block. Only applies if not using dMoE. | ||
""" | ||
|
||
scale_emb_init: bool = False | ||
""" | ||
If ``True``, embeddings are scaled up by ``sqrt(d_model)`` during initialization. | ||
|
@@ -1266,3 +1327,41 @@ def update_legacy_settings(cls, config: D) -> D: | |
new_config.optimizer = OptimizerConfig.update_legacy_settings(new_config.optimizer) | ||
|
||
return new_config | ||
|
||
|
||
def config_to_moe_args(config: ModelConfig) -> Dict[str, Any]: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it would be better to have this as an instance method of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the moe args may include things outside of the ModelConfig in the future. Currently, I put some things that may be considered as TrainingConfig params like moe_zloss_weight in the ModelConfig but in case we move them in the future to TrainingConfig then it would not only use the ModelConfig anymore. |
||
from .model import Activation | ||
from megablocks.layers.arguments import Arguments as MoEArgs | ||
|
||
hidden_size = ( | ||
config.mlp_hidden_size if config.mlp_hidden_size is not None else config.mlp_ratio * config.d_model | ||
) | ||
act = Activation.build(config) | ||
num_layers = config.n_layers // 2 if config.moe_interleave else config.n_layers | ||
kwargs = { | ||
"activation_fn": F.silu if "swiglu" in config.activation_type.lower() else Activation.build(config), | ||
"mlp_type": "glu" if "glu" in config.activation_type.lower() else "mlp", | ||
"mlp_impl": config.moe_mlp_impl, | ||
"hidden_size": config.d_model, | ||
"ffn_hidden_size": int(act.output_multiplier * hidden_size), | ||
"moe_num_experts": config.moe_num_experts, | ||
"num_layers": num_layers, | ||
# Handled by FSDP (https://github.com/databricks/megablocks/issues/57#issuecomment-1854594483) | ||
"moe_weight_parallelism": False, | ||
"moe_expert_model_parallelism": False, | ||
"moe_top_k": config.moe_top_k, | ||
"moe_capacity_factor": config.moe_capacity_factor, | ||
"moe_loss_weight": config.moe_loss_weight, | ||
"device": config.init_device, | ||
# Handled by FSDP | ||
"bf16": False, | ||
"fp16": False, | ||
"bias": config.include_bias, | ||
"return_bias": False, | ||
"shared_expert": config.moe_shared_expert, | ||
"moe_lbl_in_fp32": config.moe_lbl_in_fp32, | ||
} | ||
if config.moe_zloss_weight: | ||
kwargs["moe_zloss_weight"] = config.moe_zloss_weight | ||
|
||
return MoEArgs(**kwargs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If these are
Optional
, what does it mean when it'sNone
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They're optional when no MoE is used, otherwise required. Is this not an acceptable usage of
Optional[int]
? Can change itThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my opinion, when we have a config setting that is not always required we should either 1) always make it optional type, set it to None by default, and set it in every config when it is needed; or 2) don't make it optional type unless
None
is needed. I prefer 1 since it makes our config more readable (less irrelevant settings) and slightly more backwards compatible.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can change it to option 1) if others agree? Note that there's other params not following this:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you actually rely on the defaults you put in here anywhere? If not, let's go with Shane's version, and default these to
None
. I assume something somewhere will fail if they are not set and you need them.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes quite a lot, e.g. the loss weights; the use of dropless MoEs (moe_dropless); leaving moe_interleave,moe_lbl_in_fp32,moe_shared_expert as False
Actually, I don't think setting them all to None is a good idea, as it means that everytime we add a new MoE-specific configuration parameter all MoE configs become outdated since every MoE-specific configuration parameter is Optional in that dense.
I can also remove the
Optional
from it as they have defaults anyways but then as seen in the examples I pasted above, we do haveOptional
config params with default values in the codebase anyways.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it doesn't break everything, I'd prefer to have a special config object for MoE, which is
Optional
, but none of the items inside of that object areOptional
. This may break backwards compatibility with the model we already released though?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it would break compat with the configs we released but can pin a commit to our released repo if people want to reuse our configs to reproduce things exactly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, that's unfortunate, but I think I prefer the
MoEConfigObject
. It reduces the impact on old-school dense model training.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it would make the name ModelConfig a bit inaccurate though; maybe it should inherit from ModelConfig or sth