TP、PP、DP、EP 如何组合：八张卡，怎样淘汰不合适的配置

八张 GPU 已经到位，模型在四张卡上能启动。接下来，是把八张卡合成一个大副本，还是拆成两组四卡服务？

只看启动日志，两种方案都可能成立。把单请求延迟跑出来，也还不能决定：更快的大副本可能接不住业务高峰；吞吐更高的两个小副本，又可能在其中一个退出后没有余量。

张量切分、流水线、请求副本和专家放置各自解决不同约束。组合时，问题变成了同一批硬件要满足哪些约束，以及哪个候选最先违反约束。下面用一个明确虚构的八卡场景，把配置从“参数乘积等于八”收敛到值得实测的少数方案。所有容量与性能数字都是作者假设，不是特定模型或 GPU 的部署结论。

四张卡能启动，不等于一个副本够用

假设有两个节点，每节点四张 GPU；单卡显存按 48 GiB 计算。节点内互联较快，节点间链路较慢。待部署的是 Dense 模型，指定精度下的权重合计 120 GiB；业务有短问答，也有长输入的流式回答。模型和引擎均假设支持后文列出的切分方式。

先算一个很粗的下界：如果权重完全均分，四卡每卡 30 GiB，两卡每卡 60 GiB。因此两卡候选连权重都放不下；四卡只是越过了这一道下界，尚未证明能接住请求。

上线时，每张卡还要容纳本地 KV Cache、激活、通信工作区和运行时开销。这里的显存不能当成一个任意分配的大池子：某个 rank 的首尾模块、不能切分的张量或临时峰值超限，其他卡空着也救不了它。120÷4 只能用于剪枝，不能替代逐卡检查。

继续作一个预算假设：四卡候选在目标负载下，每卡除权重外需要 12 GiB，并预留 4 GiB，合计 46 GiB。这让它成为可测候选。若长请求使其中一张卡的非权重需求升到 16 GiB，该卡就需要 50 GiB，候选必须被淘汰或改变服务边界。两个副本即使总计还有空闲显存，也无法直接拼给这个已经接收的请求。

这里改变服务边界，可以是降低允许的上下文或接纳量，也可以是换经过质量验证的精度方案。它们都会改变比较条件，不能悄悄改完后再宣称原配置优胜。KV 的实际分片与复制还依赖模型结构，不能把所有状态都按 TP 数机械相除。

vLLM 的并行部署文档给出了一种实用检查：启动后读取 KV 容量以及指定请求长度下的最大并发估计。这些日志能暴露容量约束，但并不测量排队时间，也不保证混合长短请求的在线延迟。官方部署说明

所以，“最小并行度”指容纳目标工作负载的最小候选。它的作用是保留基线，不能在没有比较结果时直接当成最终配置。

同样用八张卡，通信和副本边界完全不同

通过容量筛选后，只保留三个问题明确的候选。下表仍是这个虚构 Dense 场景，按每个模型执行 rank 使用一张 GPU、无额外执行组来计数。

三者的模型执行 GPU 数都等于 TP×PP×DP=8，但这个等式只数资源，没有表达通信路径。

A 的请求只进入一个节点内的副本；B 的同一层计算涉及两个节点；C 把跨节点边界放在阶段之间。C 不能据此被判定更快：它减少某类跨节点通信的机会，也引入了阶段等待，实际收益取决于切分、请求形态和调度。vLLM 官方把节点内 TP、节点间 PP 列为多节点部署起点；这是可比较的基线，不是性能保证。并行与扩展文档

实测前应把 rank 列表落实到节点、GPU 和链路。参数写成 TP=4，并不自动说明四张卡处于期望的互联域。若部署器把一组卡跨节点放置，比较的就不是表中的 A。

这种放置差异也改变故障边界。按本例不具备运行中透明重构的假设，一个节点退出时，A 尚有一个完整副本；B 和 C 都失去完整执行组，不能继续按原配置服务。这不表示 A 已经高可用：入口切换、在途请求、缓存变冷和剩余容量仍需要验证。这里只能排除“八张卡总数一样，所以故障余量一样”的判断。

单请求更快，为什么仍会输掉集群选择

比较之前先定义什么算完成业务。假设目标是每秒到达 12 个请求，其中至少 95% 成功且同时满足首 Token 时间不超过 1 秒、每请求平均输出 Token 间隔不超过 50 毫秒。也就是每秒至少完成 11.4 个满足这些条件的请求。

每请求平均 Token 间隔只度量该请求的平均生成速度，不能保证流式过程中没有长停顿。若产品还限制最大停顿，应另外记录 Token 间隔，不能用平均 TPOT 代替。

为简化下面的手算，进一步假设长期测试得到如下虚构结果：在同一请求混合、至少 95% 达标且队列不持续增长的条件下，A 的每个副本可持续承接 7 请求/秒，B 的唯一副本为 11 请求/秒，C 为 9 请求/秒。这里的 7、11、9 是满足条件时的到达率上限，不是 Goodput，也不是从 TP 大小算出来的性能。

A 在两个副本负载均分、没有共享瓶颈的理想假设下，总承接上限约为 14 请求/秒，达标完成率下界为 14×95%=13.3 请求/秒。业务实际只送入 12 请求/秒时，不能宣称它完成了 13.3；能否保持至少 11.4 的达标完成率，必须在这次真实混合负载下检查。B 和 C 的已知可持续范围均未覆盖 12，不能凭单请求跑分快就批准上线。

这个例子说明单副本结果与整机结果为什么会反转，也说明相加只是估算。两个副本会共享入口、CPU、网络或存储，请求长度可能偏斜，缓存状态也可能不同。正式结果必须从实际集群入口测得，而不是把两个独立跑分相加。

常见的“单副本延迟不达标，增加 DP 无用”判断还需要补上条件：如果延迟主要花在等待空位，多一个副本可能缩短排队；如果低负载下单请求的执行时间已经超标，复制同样的副本通常不会让这个请求本身执行更快。先拆开排队与执行，才能决定该扩副本还是继续调整模型并行。

怎么避免把过载测成稳定？在固定请求集合与到达时间的比较中，保留失败、超时和未完成请求。不要因为某个配置处理得慢，就让客户端自动少发请求，再仅比较成功样本的平均延迟。vLLM 的基准工具分别提供请求到达率和最大并发控制，官方明确说明并发限制可能让实际发送率低于设定到达率；也提供按 TTFT、TPOT、E2EL 阈值统计 Goodput 的选项。基准参数说明

复现实验时应记录模型与引擎版本、精度、请求 ID、输入与输出长度、到达时间、完成状态和延迟。先固定缓存策略、采样设置与请求流，给每个候选相同预热条件，再逐级增加到达率。单独增加长请求比例做第二轮，并明确这是新的工作负载；不要同时更换量化、缓存策略和并行配置，否则无法判断变化来自哪里。

把故障余量和 MoE 放回同一张决策表

继续检查 A。若一个节点退出，只剩一个承接上限为 7 请求/秒的副本。即使正常状态下两副本足够，也不能在保持原 12 请求/秒业务目标的前提下声称具有 N-1 容量。

如果仍沿用每副本 7 的假设，且要求失去任意一个副本后承接 12，请求容量的必要条件是：

(R - 1) × 7 ≥ 12
R ≥ 3

每副本四卡，至少需要十二张卡，且这三个副本必须按所要求的故障域分开放置。它只是必要条件：冷缓存、切流损失、重试放大和共享入口瓶颈可能要求更多余量。如果故障单位是一整个节点，节点上放了多个副本，就必须一次扣掉该节点全部副本，不能仍只减一。

在现有八卡预算内，合理结论可能是保留 A、明确故障时限流降级；也可能是换更小的模型，重新验证质量和容量；还可能是扩容。不能为了选出一个“最佳配置”，把原来的故障目标从表里删掉。

当模型改成 MoE，表格还必须重新解释。这里最危险的误读，是看到 DP=2 就继续套用 Dense 的两个完整副本假设。以当前 vLLM 官方 EP 文档为例，专家组大小按 TP×DP 计算；Attention 在各 DP 组内部采用相应 TP，而专家层可以跨这些组分布。因此 EP 不是再乘一次的独立 GPU 倍数，Attention 的 DP 分组也不自动构成完整模型的故障隔离边界。官方 EP 分层说明

本篇不把上述 Dense 的 7 请求/秒或十二卡下界移植到 MoE。需要重新画出专家组、Attention 组和物理节点的对应关系，确认一个故障影响哪些请求路径，再从真实部署测试持续承接能力。若还组合 PP，更要核对锁定版本的支持与组划分，不能仅凭几个参数的乘积推导它可用。

最终留下的决策表可以很短：A 的正常负载是否达标、单节点故障后要削减多少流量；B 的跨节点 TP 是否获得足够的延迟收益；C 的阶段边界是否改善了真实请求结果。每一格都填写测量或明确的未知项，候选被淘汰时写清违反的是容量、SLO、拓扑限制还是故障目标。

这样得到的配置选择才可以回溯：容量负责排除不可能运行的方案，放置解释候选在比较什么，固定工作负载检验服务结果，故障目标决定是否有资格上线。现有硬件无法同时满足要求，也是一次有效的选型结论。

---

来源核对日期：2026-09-08。官方来源用于并行组关系与基准口径；八卡拓扑、显存预算、SLO、吞吐数字及扩容推导均为作者假设或手算，未进行 GPU 或生产环境验证。