DP2、TP8 与 MoE EP：两节点部署为何不一定是两份独立模型

整理日期：2026-09-14（晚间增量）。依据当天新增问题、可见对话摘录与一手资料整理，不是完整逐字稿。教学推导与用户反馈分别注明，未执行服务器操作。

今天引用的配置

GLM-5.3-Flash 文档给出两台 Atlas 800 A2，每台一个 DP rank，节点内 TP8，并启用 --enable-expert-parallel。完整配置的含义不能仅由 DP2 两个字推断。GLM-5.3-Flash 部署文档

先用 Dense 模型建立直觉

TP8 是同一份计算在 8 个设备之间做张量切分；DP2 是两个数据并行组处理不同请求。在没有其他并行维度、每设备一个 worker 的简单配置中，DP2×TP8 对应 16 个设备 worker，不是 16 个 DP rank。

普通全模型副本式 DP 通常不能让本来单组放不下的模型因增加 DP 而自动放下。

MoE 改变了“副本”的范围

vLLM 可以对 Attention 使用 DP/TP，对 Expert 层使用跨 DP×TP 的 EP。在这种模式下，各 DP rank 处理不同请求，但专家计算需要协同和同步，不是两台可完全独立拔掉的服务。

上游文档明确说明 MoE 的 Expert 组可跨 DP×TP；启用 EP 后需要读实际专家组配置。vLLM Data Parallel 指南

因此两台机器“DP2、各自 TP8”并不必然意味着每台都保存完整的全部专家。跨节点通信不仅是路由请求，还可能包含专家 token dispatch/combine。

为什么需要看每一层

Attention 阶段：本 DP 组处理自己的请求与缓存。

MoE 阶段：hidden states 按 router 选择分发到专家所在设备，计算后返回并组合。

这里搬运的是中间张量，不是把完整历史 token 文本发送给专家。

不能混淆的两组字母

DP 是 Data Parallel；PD 是 Prefill/Decode 分离。前者描述并行组织，后者描述推理阶段部署，不能互换。

核对配置的顺序

记录 DP、TP、PP、EP 是否启用、每节点本地 DP 数、起始 rank、设备可见列表、专家分布和通信组。容量看每个 rank 的权重与缓存；性能看节点间实际通信。不要仅按总卡数相乘判断能力。

2026-09-16 增量：TP/DP 直觉如何延伸到 EPLB

今天 14:39 左右重新讨论 TP/DP，15:39 追问 EPLB。保留一个限定：全模型副本式 DP 的直觉适用于简单 Dense 部署；启用跨 DP 组的 MoE EP 后，应分别画出 Attention 组与 Expert 组，不能再说每个 DP rank 都独立保存完整模型。

EPLB 是 Expert Parallel Load Balancer。Router 决定 token 的逻辑专家选择，EPLB 调整逻辑专家到物理 rank/副本的映射，以缓解实际请求带来的专家热点。vLLM 官方文档提供专家重分布与冗余专家配置；冗余副本需要额外设备内存。上游 EPLB 指南（2026-09-16）

为什么平均分配专家还会负载不均

教学算例：四个 rank 各放两个专家，但一个专家接收大部分 token，则其所在 rank 可能成为同步步骤中的慢者。“专家数量均匀”不等于“计算量均匀”。复制热点专家可以分散请求，但同时增加权重空间、重分布成本与通信压力；副本总量不是免费资源。

实践先记录每专家 token 计数、各 rank 计算时长和通信等待，再比较启用前后的吞吐及尾延迟。只看平均 GPU 利用率不足以证明收益。热度更新窗口过短可能频繁搬权重，过长可能跟不上请求变化。

Ascend 有独立 EPLB 支持说明，参数、模型组合与重排实现须以配套版本为准；不能从上游有开关就推断你的 GLM 配置可用，也不能把所有实现都描述为必然全局停顿。Ascend EPLB

2026-09-18—19 增量：TP4究竟切什么，EP与TP哪里重叠

9月18日从启动脚本追问DP2×TP8和物理卡数，19日11:00追问“vLLM EP和TP是不是有一些功能重叠？”

教学推导：对Y=XW，将W按输出列分为W0…W3，各rank得到Yi=XWi，拼接得到Y；若按输入行切W并相应切X，则各rank计算部分和Yi=XiWi，再求和得到Y。TP4表示参与该张量运算的四个rank，不表示把四层各放一张卡。Attention投影、FFN和输出投影可采用不同切分和通信组合，embedding、归一化也不必照同一方式切。

可用TP数受头数、张量维度、量化布局及后端实现限制；GQA/MQA等结构还可能需要复制KV头，不能仅凭模型参数量推断任意TP都能运行。

EP按专家分配工作；TP按专家内部或其他线性层的张量分片。重叠在于都能分摊MoE计算与权重，但切分单位和通信不同。系统可以Attention走TP、专家走EP；不能据此认为开EP便不需要TP，也不能把DP×TP×EP再次相乘计算设备总数。

上游当前说明：启用EP的相应部署中，专家组大小为TP×DP，Attention按TP设置执行。vLLM EP官方说明（2026-09-20核查；Ascend具体组合仍依配套版本）

当天脚本解析为DP2×TP8、EP16、PP1、PCP1，16个逻辑device。只有实机确为每物理卡暴露两个对应逻辑设备时，才可推到8张卡；必须用npu-smi、设备映射和启动日志确认。配置文件写了P/D相同并行度，不等于已经证实运行中握手和KV分片传递正确。

2026-09-23 深化：Continuous Batching与DP先后关系

问题是“为什么把多个用户合成batch，DP又会拆吗？”推理每步将就绪请求的token组织成计算批次，提高权重读取复用与矩阵计算效率；完成请求退出，新请求进入，不必等待整批最长请求结束。不同请求保留独立位置、注意力边界与KV映射，绝不是把多人的文本当一条连续序列让其互相注意。

教学例：本步A/B在decode，C有长prompt；调度器可能给A/B各一个token并安排C的一段prefill。批次约束是token预算、序列数量和KV容量等，不只是“用户数”。更大batch可能提高吞吐，也可能增加等待或每步耗时。

简单副本式DP先分配请求给实例，各实例内部自己组batch；不能把训练式固定batch均分机械搬到所有在线推理。路由还要考虑前缀缓存局部性与队列负载。

特别纠正：此前23日回答“DP2×TP8就是两份完整独立模型”只适合特定副本部署；对跨DP组专家并行的MoE不成立。Attention调度独立不代表专家计算不通信。本文前面的EP条件继续有效。

来源：vLLM DP部署（2026-09-23）；具体调度器行为按安装版本核对。

2026-10-07 深化：AB切分为什么决定通信

来源：9月24日行/列切分及“7怎么均分”追问。本节为数学教学推导，不是某个启动参数的实际源码解释。

若A按M维分行，各rank计算C_i=A_i B，输出沿M拼接；若B按N维分列，各rank计算C_i=A B_i，输出沿N拼接。两者都不要求部分结果求和，但后续层是否需要AllGather取决于消费者布局。

若沿K切：A=[A_0,A_1]，B=[B_0;B_1]，AB=A_0B_0+A_1B_1，需要把部分和相加。这里是结合线性分配的矩阵恒等式，不是因为矩阵乘法可交换；一般AB≠BA。

教学边界：K=7切2份可为4+3，或pad到8再4+4并保证补零不影响结果。但后端通信、对齐、量化group、head切分可能只接受等长分片或整除维度；数学允许不等于框架支持。没有配置/源码证据就不能承诺任意TP。

跨层看布局：列切线性层得到局部输出，接行切线性层时可利用局部中间量再做归约。优化通信要跟踪完整算子链，不能只看某一个矩阵。

训练CP切序列位置而非同一矩阵的K归约维；推理PCP/DCP又有缓存与因果合并语义。详见从 CP 到预训练系统：并行切分、状态账本与可恢复训练；tile是在设备内复用数据，TP是在rank间分担，两者尺度不同：GEMM、Triton 与 TileLang：从分块代码到 Roofline 性能账本。