## Background

线上负载在许多方面具有多样性，例如：类型，SLO 需求，etc。不同的负载可能具有不同的并行模式亲和性，例如：对于长请求可能更适合 SP，batch size 大的可能更适合大 EP 等等。

因此我们想尝试的一件事是，在集群中使用多种不同的并行模式配置的实例，将线上负载分发给最合适的实例，从而实现最大的资源利用率。

## Challenges

- 需要证明线上负载确实需要不同的并行模式，而不是 one-size-fit-all
- 线上负载是否需要做 dynamic 的并行模式 reconfiguration，还是 static 的模式就行
	- 假如需要 dynamic 的 reconfiguration，如何高效实现？尤其是在需要考虑 EP size 的 reconfiguration 的情况下，是否存在新的挑战？
- 参考 DynamoLLM 的方法学（profile+线性规划），在更大的 design space 下（SPxPPxTPxEP）是否仍然 work，有可能需要新方法。

- 请求类型：长度/SLO/**online or batch**/kvcache hit or miss/PD/...
- 不同机器 H20 or A800，计算/带宽
- 大 design space（请求类型、机器、并行模式、模型）下如何自动搜索
- reconfiguration 的 overhead 和实时负载的最优 setup 的 trade off
- depends on context (current system status), How to define context?

## Roadmap

Prerequisite：处理并分析最新的 qwen-235b 上的 2h trace，用于后续测试。

Week1: 在 vLLM 上实现性能测试平台，实现能够支持 EP/TP/PP=1,2,4,8 的性能测试，衡量相同输入的情况下，平均每张卡的吞吐 / 请求的平均延迟等。
Week2: 分析总结不同的并行模式分别会对性能有什么影响，归纳线上负载是否对不同并行模式存在请求亲和性，以及尝试理论分析如果使用不同并行模式是否相比单一部署模式具有提升空间，理论最大的提升上界

## TBD

请求分类的方法学是什么？除了长度 / SLO 需求，还有什么维度，对于 online 的请求，大概率不会存在一个明确的 tag 标识不同的 SLO 需求，如何区分？


## 现状

https://docs.vllm.ai/en/latest/serving/expert_parallel_deployment.html

> While MoE models are typically trained so that each expert receives a similar number of tokens, in practice the distribution of tokens across experts can be highly skewed.


vLLM 已经开始支持 EPLB：
```
# Single node with EPLB load balancing
VLLM_ALL2ALL_BACKEND=pplx VLLM_USE_DEEP_GEMM=1 vllm serve deepseek-ai/DeepSeek-V3-0324 \
    --tensor-parallel-size 1 \     # Tensor parallelism
    --data-parallel-size 8 \        # Data parallelism  
    --enable-expert-parallel \      # Enable EP
    --enable-eplb \                 # Enable load balancer
    --eplb-log-balancedness \       # Log balancing metrics
    --eplb-window-size 1000 \       # Track last 1000 engine steps
    --eplb-step-interval 3000       # Rebalance every 3000 steps
```




## Reference

1. 【HPCA】[DynamoLLM: Designing LLM Inference Clusters for Performance and Energy Efficiency](https://arxiv.org/abs/2408.00741v1)

Such variations arise from:
(1) requests with varying input/output token lengths
(2) request load fluctuations
(3) distinct compute properties of different LLMs
(4) different SLOs required by the services using an LLM

input/output 长度分为 9 类，{S, M, L} * {S, M, L}
结合 profile，求解 MILP，最小化 energy 开销

![[projects/auto-tuner/Heterogenous Parallelism Cluster.figs/260410-105227.png]]

2. https://www.infracloud.io/blogs/inference-parallelism
3. [Arctic Inference with Shift Parallelism: Fast and Efficient Open Source Inference System for Enterprise AI](https://arxiv.org/abs/2507.11830v1)



---

可能进一步的探索方向：
当时的工作不涉及 EP，在 EP 下会有什么新的挑战？
reconfiguration 的 overhead 不可忽视，本工作主要是用了一些 well-known 的常规优化。那么在 EP 下，reconfiguration 会存在什么挑战？


> 鉴于视觉和语言任务之间存在MoE架构的性能差异

为什么存在差异？

小模型的结论能不能迁移到大模型


---

## Materials

https://www.perplexity.ai/hub/blog/lower-latency-and-higher-throughput-with-multi-node-deepseek-deployment



## Dev TBD

PP 与 DP 同时 enable 时 vllm 会异常退出，为什么？
看起来是 vllm 的 bug，切回 v0.10.0 的 release 分支仍能稳定触发

![[projects/auto-tuner/Heterogenous Parallelism Cluster.figs/260410-105227-1.png]]

单机/跨机内的 DP 是怎么通信的？看起来需要 tcp，ZMQ 如何 work 的？