Modular Moe Config Ownership
Keep modular fused-MoE kernels tied to their layer's parallel configuration.
We create two otherwise similar FusedMoE layers with different data-parallel and expert-parallel (DP+EP) configurations. When their modular kernels are built and profiled, a kernel can behave as though it belongs to the other layer or to an older process-wide configuration. Please fix configuration ownership so each modular factory and affected backend uses the MoE configuration of the layer it is working on.
A layer's kernels and downstream consumers must behave correctly even when another layer or the process-wide configuration has conflicting DP/EP settings, or when that process-wide configuration changes after kernel construction or is absent. Constructing a kernel without a layer configuration should continue to work as non-DP+EP without requiring global state. Non-modular functional backends should not acquire a dependency on generic process-wide parallel configuration, and the existing single-rank Triton MoE numerical behavior must stay unchanged. Work in /workspace/vllm; the choice of internal interfaces and storage is up to you.
During DP+EP profiling, keep the backend's worst-case workspace reservation even when the local routing batch is small. Preserve the existing default routing chunk bound of 16,384 tokens. Conversely, a layer without DP+EP should keep its ordinary workspace requirements even if the process-wide configuration belongs to a DP+EP layer.