一个模型的参数到底放在几张卡：从显存下界到混合并行

1. 放置问题由三张图共同决定

第一张是模型图：层、attention、MoE 专家和张量形状；第二张是资源图：每张 GPU 的 HBM、节点内 NVLink/NVSwitch、节点间 NIC；第三张是流量图：输入/输出长度、并发和 SLO。放置就是把模型图映射到资源图，使流量图的瓶颈可控。

2. 前置：权重、激活、KV 和 workspace 是四类不同内存

权重随模型固定并在副本内长期驻留；KV 随会话和 token 线性或稀疏增长；激活主要随本轮 scheduled tokens 增长；workspace 与 kernel、collective、CUDA Graph capture 形状有关。训练还要加入梯度、优化器状态和保存的反向激活，因此训练卡数不能从推理卡数直接推导。

3. 卡数下界怎样算，为什么一定偏小

设参数量为 P，存储位宽为 b，单卡物理 HBM 为 H，理论权重下界是：

例如 285B 参数若全部按 4 bit 存储，裸权重约 142.5 GB，已经略高于 H200 标称 141 GB；还没有算 scale、非量化层、KV 和 workspace，因此“单卡可装”不成立。DeepSeek‑V4 的 2026 SGLang 官方测试将 285B Flash 放在 H200 TP4，将 1.6T Pro 放在 B200 TP8，这些是实测配置，不等于所有吞吐/SLO 下的唯一最优配置。

4. 五种并行分别切什么

5. DP：最简单，但复制全部权重

DP 的每个 replica 有完整模型，router 把不同请求发给不同副本。它几乎不引入逐层通信，因而容易获得接近线性的吞吐扩展；代价是每个 replica 都复制权重，且 prefix/KV locality 被分散。若请求粘在某个副本以复用 prefix，热点会造成负载不均；若随负载迁移，请求又要传 KV 或重算。

MoE runtime 中的 data parallel rank 常与 EP rank 组合：attention 可能按 DP 独立计算，专家在更大 EP group 共享。不要把配置文件里的 dp=8理解成有 8 份完整 MoE 权重，具体是否复制 expert 取决于 DP/EP mesh。

6. TP：逐层协作，卡数越多不一定越快

以列并行 MLP 为例，第一矩阵按输出维切到各 GPU，本地算部分 hidden；第二矩阵按输入维切，本地结果再 reduce-sum。attention 也可按 query/KV head 切。单卡计算随 TP 度下降，但每层多一次或多次 collective，decode 小 batch 时通信启动和同步尤其显眼。

TP 通常应留在同一 NVLink/NVSwitch 域。跨节点 TP 只有在 NIC/RDMA 足够快且张量足够大时才合理；TP 度过高还可能让单卡 GEMM 太小，降低 Tensor Core 利用率。

7. PP：通信少，却要处理流水气泡与 stage 不平衡

PP 把第 1…k 层放在 stage 0、后续层放在其他 stage，token microbatch 依次通过。stage 间只传激活，通信量通常小于逐层 TP collective；但在线服务的 batch 与长度不断变化，慢 stage 决定全流水速度，首 token 还要经过所有 stage。

OSDI 2026 的“Revisiting Pipeline Parallelism”指出固定 chunk 会在在线负载下制造 stage imbalance，提出 greedy/predictive 动态 chunk 和 delayed scheduling；在 4 张 A100 40GB 上，Qwen2.5‑32B/14B 的 PP 在其条件下可以超过 TP。结论是 PP 不应被旧式固定 microbatch 实现一票否决，但也不是普遍胜过 TP。

8. EP：MoE 权重分得开，token 必须搬来搬去

router 为每个 token 选择 top‑k experts，runtime 按目标 rank 打包 token，all-to-all dispatch 到专家 GPU，本地 GEMM 后再 all-to-all combine。通信量取决于 token 数和 hidden size，不取决于专家参数量；热点专家会让某些 rank 收到更多 token，形成 straggler。

DeepEP 的 2026 V2 官方仓库支持最高 EP 2048、FP8 dispatch/BF16 combine，并把典型 V3-like 通信 SM 用量从 24 降到 4–6；其 SM100 NVLink EP8 benchmark 报告最大 dispatch/combine 726/740 GB/s，24 SM 条件下 643/675 GB/s。微基准带宽不能直接等同端到端模型吞吐，但说明通信库已把 SM 占用本身当成需要控制的资源。

9. CP 与 SP：都切序列维，但服务目标不同

CP 把极长序列及其 KV 分到多卡，attention 通过 ring 或 all-gather 类协议获得所需 K/V；它降低单卡 KV 压力，但每层引入随上下文增长的通信。SP 常见于训练，把序列维激活分片以降低激活内存，并与 TP/反向传播配合。两者名字相近，不能混作同一机制。

对短 decode、低并发请求，CP collective 可能比本地 attention 更贵；对 1M token context，单卡根本容纳不了 KV，此时 CP 是可行性条件。放置器应按 context bucket 选择 CP 度，而非全流量固定一个最大值。

10. 混合并行：把不同流量放到不同通信域

大型 MoE 常见 mesh 是：节点内 TP 切 attention，跨 GPU 的 EP 分 expert，多个 replica 再形成 DP；层数过多时加入 PP；超长上下文才开启 CP。每个维度都对应不同 collective，mesh 维度的物理映射直接决定性能。

同一 GPU 可能同时属于多个 process group。初始化顺序、rank mapping 和 collective 并发若不一致，轻则拖慢执行，重则直接死锁。

11. 从模型到拓扑的放置步骤

1. 先算每种精度下权重和 KV 的可行内存，不把全部 HBM 当可用。
2. 确定最小 TP/EP/PP 度，使单 shard 能装下，并为目标并发保留 KV。
3. 把通信最频繁、延迟最敏感的 TP 放进最强 scale-up 域。
4. 用专家 trace 估计 EP all-to-all 与热点，而不是假设均匀 top-k。
5. 估计 PP 每 stage 的真实 kernel 时间，按计算量而非层数均分。
6. 用 DP 扩吞吐时加入 prefix locality、故障域和副本冷启动成本。
7. 在真实到达 trace 下扫 mesh，不只做单 batch 峰值 benchmark。

12. 2026 新趋势一：并行度成为运行时控制变量

过去常在部署时固定 TP；2026 的 Nitsum 把动态 TP 与 P/D split、调度联合优化，通过 TP-aware 权重复用和 KV migration 改变并行度，论文报告最高 5.3× SLO goodput。Flying Serving 则提供在线 DP↔TP 切换，使用零拷贝 weight shard view、KV adaptor、communicator pool 和无死锁切换协议，报告高负载最高 4.79×、低负载最高 3.47×。

动态切换并非免费：新 communicator 建立、KV 重排、CUDA Graph 失效和请求一致性都会产生切换成本。因此控制器需要 hysteresis：收益必须连续超过成本一段时间才切，避免负载抖动时来回变形。

13. 2026 新趋势二：专家放置必须看真实激活

2026 的 MoE activation pattern 研究分析 Llama 4 Maverick、DeepSeek‑V3 671B、Qwen3 230B‑A22B 的 10 万条 expert trace，指出 expert 负载不均、领域切换和 prefill/decode 间存在可利用相关性。Director（INFOCOM 2026 预印本）用预测器或低比特 replica 预测专家激活，在计算期间在线迁移，报告端到端延迟降低 11%–55%。

另一条路线是改变切分边界。AFD 将 attention 与 MoE FFN 放到不同 GPU 池，在 DeepSeek‑V3.2 的严格 SLO 设置下报告约 4K system tokens/s，而非 AFD 方案不可行。它说明“按层切”之外，还能按子层算子族构造硬件池，但代价是每层都跨池传 hidden state。

14. 训练并行与推理并行不能照搬

训练需要反向传播和优化器同步，DP 会产生梯度 all-reduce，PP 要安排 1F1B 等 schedule，SP/CP 用来压激活，ZeRO/FSDP 还会切参数、梯度和优化器。推理没有梯度，却有长寿命 KV、连续到达和严格 TBT。训练最优 mesh 往往追求高 MFU；推理最优 mesh 追求 SLO goodput、cache locality 和快速伸缩。

DeepSeek‑V4 2026 报告中的 285B 训练示例使用 32 张 GB300 做 DAPO，并组合 TP/SP/EP/PP；rollout 使用 FP8、训练使用 BF16。这个配置只能证明官方栈支持该组合，不能直接推导生产 serving 卡数。

15. 具体例子：给 70B dense 与 671B MoE 选卡

70B dense，FP8 权重

裸权重约 70 GB。单张 H100 80GB 看似可装，但若要服务长上下文和并发，剩余空间不足；可选 TP2，把权重降到每卡约 35GB，并保留 KV。若两卡有 NVLink，TP2 延迟可能可接受；若只能跨普通以太网，PP2 或两个更小上下文副本可能更合理，需实测。

671B MoE，FP8 权重

裸权重约 671 GB，必须分片。即使每 token 只激活约几十 B 参数，未 offload 的全部专家仍要常驻。典型设计先用 EP 分专家，再给 attention/共享层设置 TP；如果 EP 跨节点，必须验证 all-to-all。这里不能仅用“active parameters”除以显存。

16. 实现与部署检查表

• 保存完整 rank map：global rank、node、GPU、NVLink clique、NIC、TP/PP/EP/DP/CP group。
• 为各 collective 单独测 message-size 曲线、P50/P99 与并发干扰，不只记峰值 GB/s。
• 权重加载后核对每卡实际 allocated/reserved HBM；量化 scale 与非量化层也计入。
• 对 PP 记录每 stage kernel timeline；对 EP 记录每 rank token count、dispatch/combine bytes。
• 容灾按 replica/PP stage/EP group 定义：任一 rank 丢失是否使整个副本不可用。
• 动态并行切换先 drain 或使用有证明的一致性协议，禁止临时重建 communicator 阻塞在线流量。

17. 局限与判断陷阱

18. 最小可复现的 placement sweep

固定模型 checkpoint、精度和三种负载桶，在可行 mesh 上枚举 TP/PP/EP/DP。每个点先做空载权重与 HBM 审计，再逐级加并发直到 SLO goodput 峰值。

每个 mesh 报告：
per-GPU weight/KV/workspace HBM
prefill TFLOP/s, decode token/s/user, aggregate token/s
TTFT/TBT goodput, max context, OOM/reject rate
collective P50/P99, link bytes, EP imbalance, PP stage idle
replica startup and failure recovery time

实验结果应给出 Pareto front，列清同一 SLO 下哪些 mesh 分别使用最少 GPU、取得最高 goodput 或消耗最低能耗。单看峰值 tokens/s 无法回答实际部署的取舍。

19. 一手来源与年份边界