Summary:
ModelRunner.__init__ unconditionally raises for any SDAR-MoE model type, regardless of whether data parallelism is actually involved. This blocks tensor-parallel inference for SDAR-30B-A3B-Chat entirely (including plain tensor_parallel_size=1), even though DistributedManager already computes dp_size and the guard's own error message implies it's meant to target the dp+tp hybrid case specifically, not TP-only usage
Repro:
from jetengine import LLM
llm = LLM(
"/local/path/to/SDAR-30B-A3B-Chat", # or auto-downloaded from HF Hub
mask_token_id=151669,
block_length=4,
tensor_parallel_size=1, # fails even with TP=1, no DP anywhere
)
Error:
[KVCache] Estimating 8,192 blocks (192.00 GiB) for up to 512 active sequences of length 4,096 tokens.
Traceback (most recent call last):
...
File ".../jetengine/engine/model_runner.py", line 71, in init
raise ValueError(f"MoE not supported for dp tp hybrid yet")
ValueError: MoE not supported for dp tp hybrid yet
This raises error for every SDAR-MoE model regardless of dist_manager.dp_size, so MoE checkpoints can never be loaded through ModelRunner at all, not even at tensor_parallel_size=1 with no DP.
Is TP-only (dp_size=1) inference for SDAR-MoE actually known to work end-to-end (e.g. is the dist.all_reduce in sdar_moe.py's MoE forward verified correct under TP>1), or was this guard written broadly because TP itself is untested/known-broken for the MoE path and not just the dp+tp combination? I'm profiling SDAR-30B-A3B-Chat under TP=1 vs TP=2 on 2x H100 (no DP),
If I change the code to the below:
if "sdar" in hf_config.model_type and "moe" in hf_config.model_type:
if self.dist_manager.dp_size > 1:
raise ValueError("MoE not supported for dp+tp hybrid yet")
self.ModelClass = SDARMoeForCausalLM
I wonder if I can trust the correctness of TP=2 outputs after changing it to the version above, or whether there's a different recommended path for MoE+TP that I'm missing.
Summary:
ModelRunner.__init__unconditionally raises for any SDAR-MoE model type, regardless of whether data parallelism is actually involved. This blocks tensor-parallel inference for SDAR-30B-A3B-Chat entirely (including plain tensor_parallel_size=1), even though DistributedManager already computes dp_size and the guard's own error message implies it's meant to target the dp+tp hybrid case specifically, not TP-only usageRepro:
Error:
[KVCache] Estimating 8,192 blocks (192.00 GiB) for up to 512 active sequences of length 4,096 tokens.
Traceback (most recent call last):
...
File ".../jetengine/engine/model_runner.py", line 71, in init
raise ValueError(f"MoE not supported for dp tp hybrid yet")
ValueError: MoE not supported for dp tp hybrid yet
This raises error for every SDAR-MoE model regardless of dist_manager.dp_size, so MoE checkpoints can never be loaded through ModelRunner at all, not even at tensor_parallel_size=1 with no DP.
Is TP-only (dp_size=1) inference for SDAR-MoE actually known to work end-to-end (e.g. is the dist.all_reduce in sdar_moe.py's MoE forward verified correct under TP>1), or was this guard written broadly because TP itself is untested/known-broken for the MoE path and not just the dp+tp combination? I'm profiling SDAR-30B-A3B-Chat under TP=1 vs TP=2 on 2x H100 (no DP),
If I change the code to the below:
I wonder if I can trust the correctness of TP=2 outputs after changing it to the version above, or whether there's a different recommended path for MoE+TP that I'm missing.