文章目录
-
- 一、对比
- [二、DP8+EP 通常情况下更容易获得高吞吐，主要有三个原因：](#二、DP8+EP 通常情况下更容易获得高吞吐，主要有三个原因：)
-
- [2.1 第一，Attention 不再需要 TP 通信。](#2.1 第一，Attention 不再需要 TP 通信。)
- [2.2 第二，专家矩阵保持完整，可能更适合高效计算。](#2.2 第二，专家矩阵保持完整，可能更适合高效计算。)
- [2.3 第三，对DS系列模型，DP Attention 有明显的 KV Cache 优势。](#2.3 第三，对DS系列模型，DP Attention 有明显的 KV Cache 优势。)
- 三、举例说明：
- 四、部署配置
- 五、实验结果对比及总结
一、对比
MoE的Transformer层执行路径如下：
上图是以DP8+EP部署模型的执行流程。一个token进入本地Attention层（完整att）计算后通过路由发送给激活专家所在卡（注意，未必在本地了）做GEMM，最后专家模块返回结果合并输出进入下一层。
如果改为TP8部署，一个token进入本地Attention层（1/8att）计算后做AllReduce然后发送给每张卡中的激活专家部分（每张卡都会发送，但不是发送给卡上的所有专家）做GEMM，然后AllReduce进入下一层。
| DP8+EP | TP8 | |
|---|---|---|
| Attention | 无需 AllReduce，计算量更大，KV 负担更大 | 需要 AllReduce，计算量小，KV 负担更小 |
| Dispatch | All-to-All | Scatter |
| Expert GEMM | 计算量更大 | 计算量更小 |
| Combine | All-to-All | AllReduce |
二、DP8+EP 通常情况下更容易获得高吞吐，主要有三个原因：
2.1 第一，Attention 不再需要 TP 通信。
每张卡独立完成自己那部分请求的 Attention，省掉这一部分的跨卡归约。当每步计算很短、通信启动开销占比较高时，这个收益可能很明显。但专家层仍然需要通信，所以不能进一步推导成DP8+EP的总通信一定更少。还要比较 token 分发、回收的代价。
2.2 第二，专家矩阵保持完整，可能更适合高效计算。
- TP8 会把相应维度切到1/8，每张卡处理很多专家的小切片。
- EP8 保留完整的专家模块，每张卡处理更少的完整专家。
对于某些模型和算子实现，TP 切分后的矩阵太窄，计算效率会下降；EP 的完整专家矩阵可能更适合 Grouped GEMM。
需要额外注意的是，固定全局 token 数B后，EP 不会凭空让每个专家收到的 token 数增加 8 倍。若专家数是E、每个 token 激活K个专家、路由均匀，则两种方案中每个专家平均处理的 token 数都约为：BK/E。区别在于这个专家的计算由 8 卡切分完成，还是由它所在的卡完整完成。平均计算量可以接近，实际效率却不同。
2.3 第三，对DS系列模型，DP Attention 有明显的 KV Cache 优势。
这是 DeepSeek 场景下很可能被重点考察的一点，需要深入了解DS系列模型（尤其是3以后）的架构。
无论是V3还是V4，均使用所有Query头共享单个 KV 头。
- 服务来了8个请求
- 每个请求在某一层transformer中的KV cache显存占用量是1B
- 负载绝对均衡
- 不存在热点专家现象
对于DP8+EP部署方式来说，每张卡上的KV cache显存占用量是1B（假设负载均衡了，所以每个DP分的一个请求）；但对于TP8部署方式来说，每张卡上的KV cache显存占用量是8B，因为每个请求都要经过每张卡上的attention做计算。vLLM 官方将这一点明确列为 DeepSeek 采用 DP+EP 的动机。
三、举例说明：
假设存在一个并发度为1的场景，每次集群都只服务一条请求。那DP8+EP的第三条优势将荡然无存，并且在第一条上，还会输给TP8。
一般来说all-to-all通信量是要小于AllReduce（这个要分析也是一篇硬核文章了），但如果出现专家路由明显不均衡，哪怕整体通信量小，也会表现成局部的通信瓶颈。而TP8是显然没有路由不均衡这一现象的。（在这里面试官将会高频发问，如何解决专家路由不均衡的问题，也是一篇硬核文章）
还有，如果出现负载不均衡的情况呢？假设一共来了80个请求，vllm原生引擎天然给每个DP分配10个请求。但是每个请求的token数却未必是一样的。请求粒度的负载均衡未必就代表token粒度的均衡。这进而会拖慢整个EP通信域。
四、部署配置
- 单台服务器，910B3*8(单卡64GB)
- vllm 0.25.1
- 压测工具 evalscope
- 输入8k 输出1k 定长
五、实验结果对比及总结
| 并发 | 成功/请求 | DP1 + TP8 + EP (tok/s) | DP8 + TP1 + EP (tok/s) | DP8 相对变化 |
|---|---|---|---|---|
| 1 | 8/8 | 30.85 | 22.75 | -26.25% |
| 8 | 40/40 | 164.22 | 135.81 | -17.30% |
| 16 | 32/32 | 263.72 | 213.37 | -19.09% |
| 32 | 64/64 | 380.69 | 355.51 | -6.62% |
| 64 | 128/128 | 479.40 | 606.65 | +26.54% |
| 128 | 256/256 | 659.60 | 853.26 | +29.4% |
以下延迟表中，每格均为 DP1 → DP8。TTFT 和 E2E 单位秒，TPOT 单位毫秒。
| 并发 | 平均 TTFT | 平均 TPOT | 平均 E2E | P95 TTFT | P95 E2E |
|---|---|---|---|---|---|
| 1 | 1.10 → 2.55 | 31.37 → 41.51 | 33.19 → 45.01 | 1.16 → 2.77 | 33.28 → 45.36 |
| 8 | 5.68 → 6.10 | 43.19 → 52.98 | 49.86 → 60.29 | 11.77 → 12.69 | 56.63 → 67.79 |
| 16 | 7.50 → 9.80 | 53.26 → 65.35 | 61.99 → 76.65 | 22.94 → 21.10 | 77.10 → 84.16 |
| 32 | 11.28 → 13.62 | 72.80 → 76.60 | 85.76 → 91.99 | 32.56 → 24.40 | 114.60 → 106.55 |
| 64 | 21.71 → 18.76 | 111.70 → 87.07 | 135.98 → 107.83 | 80.88 → 39.91 | 201.44 → 139.79 |
| 128 | 35.50 → 28.59 | 157.81 → 121.74 | 196.94 → 153.14 | 119.64 → 73.5 | 304.56 →217.3 |
- 总结
1）若关注本次同类负载的低并发延迟：DP1+TP8 结果更好
2）若关注并发 64/128 的整体吞吐和请求平均延迟，DP8+TP1 结果更好。