[Model][Core] Add DeepSeek-V3 and Mixtral-8x7B MoE configs + disaggregated P/D scheduler

[buddywhitman]

Adds two new capabilities:

1. MoE model support (related to Issue Support simulation of MoE model and Expert Parallelism #75):

   • BaseMoEModelConfig extending BaseModelConfig with num_experts, num_active_experts, expert_intermediate_dim, kv_lora_rank, etc.
   • DeepSeekV3ModelConfig: 256 experts, top-8 routing, MLA attention (kv_lora_rank=512, q_lora_rank=1536), auto-discovered by name
   • MixtralModelConfig: 8 experts, top-2 routing
   • MoELayerExecutionTimePredictor: RF predictor extended with load- imbalance features (λ^0.72 correction, closed-form multinomial approx)

2. Disaggregated prefill/decode scheduler:

   • DisaggregatedScheduler: discrete-event simulation of separate prefill and decode worker fleets (Dynamo-style P/D disaggregation)
   • KV transfer latency: 2 × layers × kv_heads × head_dim × seq_len × 2B
   • Configurable interconnect bandwidth (NVLink 600, IB 400, PCIe 64 GB/s)
   • Returns p50/p90/p99 E2E latency, TTFT, KV transfer stats, utilization

FIX #75

Summary

1. MoE model configs

BaseMoEModelConfig extending BaseModelConfig with num_experts, num_active_experts, expert_intermediate_dim, kv_lora_rank, q_lora_rank, expert_parallel_degree.

Two concrete configs auto-discovered via the existing get_all_subclasses mechanism:

• DeepSeekV3ModelConfig (deepseek-ai/DeepSeek-V3): 256 experts, top-8, MLA attention
• MixtralModelConfig (mistralai/Mixtral-8x7B-v0.1): 8 experts, top-2

MoELayerExecutionTimePredictor extends the RF predictor with load-imbalance features (closed-form multinomial approximation, λ^0.72 latency correction).

2. Disaggregated prefill/decode scheduler

• DisaggregatedScheduler simulates separate prefill and decode worker fleets.
• KV transfer latency: 2 × layers × kv_heads × head_dim × seq_len × 2B (fp16).
• Sweepable over prefill:decode ratio and interconnect bandwidth (NVLink/IB/PCIe).
• Returns p50/p90/p99 E2E latency, TTFT, KV transfer stats, and fleet utilization.

Tests

  make format          # black + isort clean
  pytest tests/test_moe_model_config.py -v  # 12 passed

Documentation

• New docs/disaggregated_scheduling.md: motivation, architecture diagram, KV transfer latency derivation with a worked DeepSeek-V3 example (NVLink ~0.13ms, IB ~0.20ms, PCIe ~1.25ms at seq_len=1024), usage example, and a P/D ratio sweep example.
• README.md "Supported Models" table updated with the two new MoE entries.

Testing / Code quality

• Ran make format (isort --profile black + black on the full vidur/ tree).
• New configs are picked up automatically by the existing model-discovery mechanism — verified via python -m vidur.main -h listing the new model names.
• Verified python -m vidur.main --replica_config_model_name deepseek-ai/DeepSeek-V3 --replica_config_device a100 --cluster_config_num_replicas 1 --replica_config_tensor_parallel_size 8 runs end-to-end.

No breaking changes to existing models or configs — both new model configs and the disaggregated scheduler are additive and opt-in.

---

PR Checklist (Click to Expand)

Thank you for your contribution to Vidur! Before submitting the pull request, please ensure the PR meets the following criteria. This helps Vidur maintain the code quality and improve the efficiency of the review process.

PR Title and Classification

Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

• [Bugfix] for bug fixes.
• [CI/Build] for build or continuous integration improvements.
• [Doc] for documentation fixes and improvements.
• [Model] for adding a new model or improving an existing model. Model name should appear in the title.
• [Profiling] For changes on the profiling module.
• [Core] for changes in the core simulator logic
• [Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.

Code Quality

The PR need to meet the following code quality standards:

• Pass all linter checks. Please use make format to format your code.
• The code need to be well-documented to ensure future contributors can easily understand the code.
• Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of Vidur. It helps user understand and utilize the new features or changes.

Notes for Large Changes

Please keep the changes as concise as possible. For major architectural changes (>500 LOC), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.

Thank You

Finally, thank you for taking the time to read these guidelines and for your interest in contributing to Vidur. Your contributions make Vidur a great tool for everyone!

[buddywhitman]

@microsoft-github-policy-service agree