从 TPOT 188ms 到 22ms：大模型多机分布式部署的并行策略实测

先说结论：普通网络上 PP 赢，开了 eRDMA 之后 TP 赢，而且赢很多。 下面是三轮压测的完整过程和踩坑记录。

为什么多机在所难免

今年上半年我们接到的模型规格越来越夸张：Qwen3.8-2.4T-A95B 的模型文件有 4.9TB，Kimi K3 有 1.56TB。作为参照，单机 8 卡 141G 显存的机型满打满算约 1.1TB，连权重都放不下，更别提 KV cache。我们这边负责计算巢模型市场的模型上架，要给这类超大参数模型提供「一键可用」的默认部署配置，多机分布式部署对我们来说不是可选项，是必答题。

多机就绕不开两个选择：模型怎么切（「TP」张量并行还是「PP」流水线并行），机间走什么网络（普通 TCP 还是 RDMA / eRDMA）。这两个选择排列组合下来性能差多少，文档里很少有直接可比的数字，于是我们自己压了三组：qwen3-32B 探路、DeepSeek V4 Pro 验网络、GLM-5.2-FP8 做终局对比。

实验一：普通网络上，PP+TP 赢全 TP

先把两个概念摆清楚。「TP」把每一层的计算切到多张卡上，代价是每一层都要做一次跨机 allreduce，通信次数跟着层数走，好处是每张卡计算均匀、没有流水线气泡；「PP」按层把模型切成段，双机情况下 stage 之间一个 microbatch 只传一次激活，通信次数少，代价是流水线气泡和切分不均。

直觉上 TP 的 GPU 利用率更高，应该更快。但跨机通信量才是决定胜负的变量。第一组用小一点的 qwen3-32B 探路，双机部署，3 并发，输入 3K、输出 1K：

图：qwen3-32B 双机，PP+TP，3 并发，输入 3K / 输出 1K

图：qwen3-32B 双机，跨机全 TP，3 并发，输入 3K / 输出 1K

全 TP 的 TPOT 平均慢了约 64%（p99 从 32.6ms 到 54.3ms，+67%），TTFT 也几乎翻倍。每一层一次的跨机 allreduce 全花在了普通 TCP 网络上，GPU 大部分时间在等通信。这组数据给了我们第一个默认配置：没有高性能网络时，跨机不要跑全 TP，PP+TP 是更稳的选择。

实验二：eRDMA 把 TPOT 砍掉 44%

通信是瓶颈，那就有必要看看换网络能换回多少。ACS 支持 RDMA，ECS / ACK 环境支持 eRDMA（介绍见官方文档 RDMA 与 eRDMA）。第二组用 DeepSeek V4 Pro，双机 H20×8，vLLM 部署，1 并发，输入 3K、输出 1K，同样的配置只切换网络：

图：DeepSeek V4 Pro 双机 H20×8，未开 eRDMA（普通网络），1 并发，输入 3K / 输出 1K

图：DeepSeek V4 Pro 双机 H20×8，开启 eRDMA，1 并发，输入 3K / 输出 1K

TPOT 从 95.1ms 降到 52.9ms，-44%，端到端时延 -43%。有意思的是 TTFT 只小幅改善（-15%）——prefill 阶段是计算密集，跨机通信占比小；decode 阶段每一步都要跨机同步，是通信密集，eRDMA 正好打在后者上。这个特征也预示了下一组实验的走向。

实验三：开了 eRDMA，TP 全面反超 PP

网络不再是瓶颈之后，TP 的通信代价还成立吗？第三组用 GLM-5.2-FP8，双机 H20×8，SGLang 部署，3 并发，输入 8K、输出 2K，同样开启 eRDMA，对比纯 TP16 和 PP2+TP8：

图：GLM-5.2-FP8 双机 H20×8，TP16 + eRDMA，3 并发，输入 8K / 输出 2K

图：GLM-5.2-FP8 双机 H20×8，PP2+TP8 + eRDMA，3 并发，输入 8K / 输出 2K

PP 的 TTFT 优势还在（1.4s 对 4.4s），但 decode 阶段 TP 的 TPOT 只有 PP 的 12% 左右，端到端时延是 PP 的 1/7.7。标题里的 188ms → 22ms 就来自这一组。

为什么开了 eRDMA PP 的 TTFT 仍然更低？两个阶段的通信量纲不一样：prefill 的跨机通信量随序列长度走（8K 输入下单次激活传输就是百 MB 级），TP 每层要付两次跨机 allreduce，78 层累计的跨机流量比 PP 在 stage 边界传一次激活高两个数量级；decode 每步通信只有 batch × hidden 几十 KB，是延迟主导，eRDMA 微秒级延迟下 TP 逐层付的代价变得可以忽略，反而拿到 PP 没有的优势——权重切 16 份后每卡每 token 读的权重少一半（decode 是显存带宽瓶颈）、没有流水线气泡、投机解码跑得起来。一句话：TTFT 是通信体积主导所以 PP 赢，TPOT 是显存带宽主导所以 TP 赢。这个机理也同时解释了实验一——普通网络上 PP 的 TTFT 同样更低。

还有一个出乎意料的数字：「投机解码」接受率从 TP 的 69.2% 掉到 PP 的 0.7%。EAGLE 的 draft-verify 循环在 PP 的 stage 切分下基本跑不起来，decode 退化成了近乎裸跑，这解释了为什么 PP 的 Decoded Tok/Iter 只有 1.01。

这里要诚实交代一个边界：两组配置不只是并行策略的差异。TP 版本开满了 dsa attention、fp8 KV cache、hierarchical cache、chunked prefill 和 EAGLE 投机解码；PP 版本因为兼容性问题只能用 flashinfer + bf16 KV，并且关掉了 overlap schedule、cuda graph 等一系列优化。也就是说，差距的一部分来自「PP 这条路开不了这些优化」——这本身就是选型信息：在 SGLang 当前版本下，PP 不仅通信模式吃亏，还拿不到生态里最新的优化特性。

三组实验合起来的选型结论：

模板要点：LeaderWorkerSet + eRDMA

多机编排我们用「LeaderWorkerSet」：size: 2 组织双机，node-rank 和 leader 地址分别由 LWS_WORKER_INDEX（downward API 取 label）和 LWS_LEADER_ADDRESS 注入，pod 挂了整组重建（RecreateGroupOnPodRestart）。完整模板较长，这里只摘三块关键配置（敏感标识已替换为占位符）：

apiVersion: leaderworkerset.x-k8s.io/v1
kind: LeaderWorkerSet
metadata:
  name: glm-sgl
  namespace: <NAMESPACE>              # 服务实例所在 namespace
spec:
  leaderWorkerTemplate:
    size: 2                           # 双机
    restartPolicy: RecreateGroupOnPodRestart
    leaderTemplate:
      spec:
        containers:
          - name: sglang-leader
            env:
              - name: LWS_WORKER_INDEX
                valueFrom:
                  fieldRef:
                    fieldPath: "metadata.labels['leaderworkerset.sigs.k8s.io/worker-index']"
              # ===== eRDMA / NCCL 关键环境变量 =====
              - name: NCCL_SOCKET_IFNAME
                value: "eth0"
              - name: NCCL_IB_HCA
                value: "erdma"        # 指定走 eRDMA 设备
              - name: NCCL_IB_DISABLE
                value: "0"
              - name: NCCL_IB_GID_INDEX
                value: "1"
            resources:
              limits:
                nvidia.com/gpu: '8'
                aliyun/erdma: '1'     # 关键：申请 eRDMA 网卡资源
            volumeMounts:
              - mountPath: /dev/shm
                name: dshm            # 机内共享内存，200Gi Memory 型 emptyDir

两种策略的启动参数差异集中在这几行：

# TP 版：跨机全 TP，优化开满
python3 -m sglang.launch_server \
  --tp-size 16 --nnodes 2 --node-rank $LWS_WORKER_INDEX \
  --dist-init-addr $(LWS_LEADER_ADDRESS):5000 \
  --attention-backend dsa --kv-cache-dtype fp8_e4m3 \
  --chunked-prefill-size 16384 --max-prefill-tokens 65536 \
  --enable-hierarchical-cache --hicache-size 100 \
  --speculative-algorithm EAGLE --speculative-num-steps 3

# PP 版：stage 内 TP8，兼容优先
python3 -m sglang.launch_server \
  --tp-size 8 --pp-size 2 --nnodes 2 --node-rank $LWS_WORKER_INDEX \
  --dist-init-addr $(LWS_LEADER_ADDRESS):5000 \
  --attention-backend flashinfer --kv-cache-dtype bf16 \
  --disable-overlap-schedule --disable-cuda-graph --disable-custom-all-reduce

模型权重走 OSS Connector 直挂（LD_PRELOAD=libossc_preload.so），避免先把 TB 级文件拷进 emptyDir 再加载。

边界与反思

这三轮压测都限定在双机 16 卡、低并发（1~3）、固定输入输出长度。更高并发下 TP 的 allreduce 开销会不会重新抬头、4 机 / 8 机规模下 PP 的通信优势会不会回来，我们还没有数据，结论外推要谨慎。

另外两组结论都强依赖网络条件：在没有 eRDMA / RDMA 的集群上，实验三的结论不成立，应该回到实验一的 PP 默认。这也是我们模型市场模板里把「是否具备高性能网络」作为策略选择前置条件的原因。

最后，TP 与 PP 的对比里混进了优化开关的差异（见实验三的交代）。更严格的对照实验是两边都关掉全部优化再比一次；我们这里呈现的是「两种策略在真实部署中能拿到的最佳配置」，因为它更贴近上架时要做的决策——用户拿到的就是这些默认配置，不是实验室对照组。

总结

三条可以直接用的结论：普通网络选 PP+TP；有 eRDMA 选全 TP；只关心 TTFT 的短输出场景单独评估 PP。

这些配置已经固化进计算巢模型市场的多机部署模板，GLM-5.2-FP8、DeepSeek V4 Pro 等超大参数模型可以直接一键部署，不需要自己从头调这些参数。