GLM5.3 CyberSec w4A16本地部署[2]：并行策略与 PP 切分

02 · 并行策略与 PP 切分

本篇讲并行策略怎么选：MLA 模型上 TP 换不来 KV 容量、PP 提升容量、PP_LAYER_PARTITION=41,37 层切分的来源，以及 DP/EP/DCP/PCP 不使用的原因。

文章目录

[02 · 并行策略与 PP 切分](#02 · 并行策略与 PP 切分)
- [0. 结论](#0. 结论)
- [1. 硬件与显存占用计算](#1. 硬件与显存占用计算)
- [2. TP 对 KV 容量贡献是 0](#2. TP 对 KV 容量贡献是 0)
- [3. PP：按层切分，容量 ≈ ×PP](#3. PP：按层切分，容量 ≈ ×PP)
- - [3.1 机制](#3.1 机制)
  - [3.2 基于VLLM v0.30定制镜像](#3.2 基于VLLM v0.30定制镜像)
- [4. `41,37`：PP 显存均衡的那笔账](#4. 41,37：PP 显存均衡的那笔账)
- - [4.1 `39,39` 下卡 0-3 只用 70.7 GiB](#4.1 39,39 下卡 0-3 只用 70.7 GiB)
  - [4.2 四档切分对照](#4.2 四档切分对照)
  - [4.3 实测结果（`41,37` 优于预测）](#4.3 实测结果（41,37 优于预测）)
- [5. PP=2 的正确性缺陷与「方案 B」](#5. PP=2 的正确性缺陷与「方案 B」)
- - [5.1 机制：DSA 的跨层索引共享被切分边界打断](#5.1 机制：DSA 的跨层索引共享被切分边界打断)
  - [5.2 实测退化（同口径 `p5_identity`，sane 采样 `temp=0.8 / top_p=0.9`）](#5.2 实测退化（同口径 p5_identity，sane 采样 temp=0.8 / top_p=0.9）)
  - [5.3 修复（方案 B）](#5.3 修复（方案 B）)
  - [5.4 修复后 PP=2 全面优于 PP=1](#5.4 修复后 PP=2 全面优于 PP=1)
  - [5.5 层切分与 gate 的耦合（必须 preflight）](#5.5 层切分与 gate 的耦合（必须 preflight）)
- [6. `deploy.sh` 里的 PP 缺省与门禁](#6. deploy.sh 里的 PP 缺省与门禁)
- [7. 其余维度：不使用原因](#7. 其余维度：不使用原因)
- [8. PP 层间通信与 NCCL](#8. PP 层间通信与 NCCL)
- [9. 部署配置选择](#9. 部署配置选择)
- [10. 复现命令](#10. 复现命令)

0. 结论

MLA 的 KV 在 TP rank 间完全复制 ， --tensor-parallel-size 对 KV 容量的贡献是 0，相关容量占用必须按单卡算。
PP 是唯一的扩容手段 ：TP=8/PP=1 338,688 → TP=4/PP=2 791,744（×2.34）→ TP=2/PP=4 1,193,600（×3.52）；v0.30 定稿形态 PP=1 386,943 → PP=2 + 41,37 729,280。
41,37 是把末级闲置显存换成 KV ：池 597,760 → 729,280（+22.0%） ，最紧余量 1,802 → 2,479 MiB（+38%）（§4）。
PP=2 有一个真实的缺陷 ：DSA 跨层 top-k 索引共享在切分边界错位 ⇒ 19~21% 退化 （PP=1 为 0/120）；「方案 B」修复后 0/200。
PP>2 被 check_pp_dsa_gate() 硬拦 ：PP=4 关掉投机仍有 20% 退化（开 MTP k=3 为 45% ）⇒ 1M 上下文今天不可用。
其余并行维度都不采纳 ：DCP 启动即断言失败、PCP 被 MTP + full CUDA graph 阻断、DP 要 16 卡、EP −1.5% 、--block-size 容量中性。

1. 硬件与显存占用计算

nvidia-smi topo -m 实测4 对 NVLink （0↔1、2↔3、4↔5、6↔7，NV8）+ 跨对 PCIe/SYS ，GPU 0-3 在 NUMA0、4-7 在 NUMA1。所以本机不是"PCIe-only"，但跨对 all-reduce 很贵 。kernel profile 给出的量级（TP=8 时代）：NCCL all-reduce 占 39.1% 的窗口时间（AllReduce 36.4% + AllGather 2.4%），每步 156 次 all-reduce × 191 µs （78 层 × 2）；其余是 DSA 注意力 23.1%、Marlin MoE 18.6%、bf16 GEMM 12.0%。这张表是后面所有并行取舍的地基：通信量由"哪些维度要跨卡同步"决定。

显存侧的三个基础事实：

每卡权重的口径是 390.58 GiB / (TP × PP) （Checkpoint size: 390.58 GiB，启动日志 weight_utils.py:858）。TP×PP 恒为 8 时每卡 ≈ 48.8 GiB ，所以 PP 换来的是纯 KV 收益，不是"省权重"。
每 rank 的显存预算 = gmu × 79.25 GiB ，gmu 0.95 ⇒ 75.29 GiB，所有 rank 相同。
TP×PP 必须 ≥ 8：否则每卡权重 > 80 GiB 装不下（TP=4/PP=1 是 97.5 GiB/卡）。8 卡上就只剩 (8,1)、(4,2)、(2,4) 三种分法。
KV 的每 token 记账（fp8_ds_mla、TP=8/PP=1、block_size=64，实测反推、误差 0.22%）：

bash 复制代码

主 attention 层   : 79 层（78 主干 + 1 MTP）× 656 B（fp8_ds_mla） = 51,824 B
DSA indexer cache : 21 层（indexer_types=="full"）    × 132 B      =  2,772 B
                                                      每 token/rank = 54,596 B
block_size=64 ⇒ 每 block/rank 3,494,144 B（3.332 MiB）
338,688 token × 54,596 B = 17.222 GiB ≤ 17.26 GiB ✅

1 GiB 显存 ≈ 19,668 token 的 KV
DSA indexer cache 与主 KV 在同一个池里

2. TP 对 KV 容量贡献是 0

这是整套并行策略的起点，值得把机制写清楚：

MLA 只有 1 个 KV 头 （num_kv_heads=1，mla_attention.py:1160-1169），页大小公式是 (head_size + head_size_v) × dtype_size 或 state_content_bytes，里面没有任何 tensor_parallel_size 项。
池子大小按"本 rank 的层数"算 ：num_blocks = int(available_memory // page_size // num_layers)，除的是 num_layers 而不是 TP。
DSA indexer 的 k_cache 同样复制 ：deepseek_v2.py:656 的注释就是 # no tensor parallel, just replicated。

⇒ 每个 TP rank 都分配一份同样大的完整 MLA KV 池 。启动日志里那句 Maximum concurrency for 327,680 tokens per request: 1.04x 就是这么来的。 343,232 / (327,680/64) ≈ 1.047。所以"加卡"对上下文长度一点贡献都没有 ；想扩 KV 只能换维度：层维（PP）或序列维（DCP）。DP 也不行，每个 DP rank 各自一份完整模型与 KV 池，单卡容量不变。

3. PP：按层切分，容量 ≈ ×PP

3.1 机制

PP 把 78 层主干切成 PP 段，每 rank 只建自己那段。KV spec 只从本 rank 的 static_forward_context 取。于是 num_blocks 公式里的 num_layers 变成 L/PP，而每请求 block 数不变 ⇒ max_concurrency = num_blocks / blocks_per_req ≈ ×PP。
细节：所有 rank 的 block 数取最小值对齐 （"Change the num_blocks of each rank to the smallest among all ranks"）。这既解释了"为什么最紧的 stage 决定一切"，也解释了 78 不能被 4 整除（19.5）时为什么要用 VLLM_PP_LAYER_PARTITION 手动分。

3.2 基于VLLM v0.30定制镜像

形态	`GPU KV cache size`	`max_model_len`	单流（内容受控中位）	conc16
`TP=8/PP=1` + MTP k=3 + `fp8_ds_mla`（单流形态）	386,943	352,000	~68	245.8
`TP=4/PP=2` + `41,37` + MTP k=3 + `fp8_ds_mla`（缺省）	729,280	524,288	71.3	297~310

按两列相除是 ≈1.88× （386,943 → 729,280），比 v0.28 时代的 2.34× 低，是因为这一档同时带着 MTP ------ 末 rank 多一个 MTP 层，而它的 DSA indexer cache 也在这个 KV 池里（v0.28 上同镜像 A/B 测过：PP=2 无投机 791,744 vs PP=2 + MTP 623,168 ，MTP 吃掉约 21% 的容量收益）。这是"容量换单流"的取舍，不是配置失误。
PP 解决的是"每 token 占多少显存"里的层数因子 ，另一个因子是每层每 token 的字节数：fp8_ds_mla（656 B）相对 bf16（1152 B）的容量是 ×1.71 （343,232 / 200,704，低于格式上限 ×1.756，差额被两种配置下同样大的 DSA indexer cache 摊薄），而 bf16 的硬上限是 236,224 token。

4. `41,37`：PP 显存均衡的那笔账

4.1 `39,39` 下卡 0-3 只用 70.7 GiB

实测（TP=4/PP=2 + MTP k=3 + gmu 0.95；单位 GiB）：

	权重 + 非 torch	峰值 activation	CUDAGraph	可用 KV	实际分配 KV	合计	nvidia-smi
PP0 卡 0-3	50.98	2.36	0.76	21.95	15.56	69.66	72,430 MiB
PP1 卡 4-7	56.53	3.20	1.49	15.56 ← 瓶颈	15.56	76.78	80,118 MiB

预算 0.95 × 79.25 = 75.29 GiB 两 rank 相同，加上 0.93 GiB CUDA context 后与 nvidia-smi 逐项闭合到 ~0.2 GiB。根因链条：

PP0 = 层 0--38（含 3 个 dense 层）；PP1 = 层 39--77 + MTP 层 + lm_head + final norm ，外加 MTP 带来的更大 CUDA graph pool（0.76 → 1.49 GiB）与更大峰值 activation。
权重体积按 checkpoint 头实测：MoE 层 5,177.8 MiB/层 （MTP 层 5,339.7），TP=4 ⇒ ≈1.30 GiB/卡/层 。反推 PP0 = 36×1,332.6 + 3×191 + 454 = 49,000 MiB，与启动日志的 47.85 GiB 吻合。
num_blocks = min_r(可用KV_r / page_r) ⇒ 池子被 PP1 的 15.56 GiB 卡死。卡 0-3 的 6.4 GiB（vLLM 口径）/ 8.7 GiB（nvidia-smi 口径）在 39,39 下无法变成上下文。

4.2 四档切分对照

把 MoE 层从 PP1 挪到 PP0，就是在"把前一段的闲置显存换成瓶颈段的可用 KV"：

切分	瓶颈可用 KV	KV 池预测	单流算力（层当量，MTP×3）	gate 翻层
`39,39`（旧缺省）	15.56 GiB	597,760（实测）	39 vs 42	rank1: 39,40,41
`40,38`	16.86 GiB	≈647,700 (+8.4%)	40 vs 41	rank1: 40,41
`41,37` ★	18.16 GiB	≈697,600 (+16.7%)	41 vs 40	rank1: 41
`42,36`	18.05 GiB	≈693,300 (+16.0%)	42 vs 39	无（零依赖 gate）

★ = 同时"KV 最大"且"算力最均衡"。末级每步要替 MTP 跑 3 次 前向，所以现状 39 vs 42 末级本来就是流水线的 straggler，挪走两层同时缓解了容量与算力两件事。

4.3 实测结果（`41,37` 优于预测）

项	`39,39`	`41,37`	变化
`GPU KV cache size`	597,760	729,280	+22.0%（优于预测的 +16.7%）
524,288 单请求并发	1.14×	1.39×	+22%
`step_ms`（与内容无关）	34.15	33.70	−1.3%
单流内容受控中位	71.2	71.3	相等（噪声内）
agent 档退化	0/40	0/40（后加测 0/200）	保持
质量探针 / Responses / 工具往返	12/12	12/12 / 10/10 / 20/20	---
`nvidia-smi`（卡 0-3 / 卡 4-7）	72,430 / 80,118 MiB	79,441 / 79,343 MiB	最紧余量 1,802 → 2,479 MiB（+38%）

安全前置 scripts/v030_pp_rebalance.sh preflight PASS ：rank1 区间 [41,78)、自算层 [42,46,...,74]、gate 需翻层 =[41]、新 gate 残余不安全 = 0 ；反例 45,33 上旧式区间法漏判 1 层、新 get_pp_indices() 为 0 ⇒ 反例成立、不是恒真断言。

5. PP=2 的正确性缺陷与「方案 B」

5.1 机制：DSA 的跨层索引共享被切分边界打断

本模型 DSA 配置 index_topk_freq=4 + index_skip_topk_offset=3 ⇒ 只有层 2, 6, 10, ..., 38, 42, ..., 74 自己计算 top-k 索引 ，其余层复用最近一次自算的共享缓冲。PP=2 按 39,39 切：rank0 = 层 0--38，rank1 = 层 39--77，而 rank1 的第一个自算层是 42 ⇒ rank1 上的 39/40/41 三层复用了本 rank 从未写入过的缓冲（首轮未初始化，之后是上一轮遗留的陈旧索引）⇒ 3/39 层注意力错误。PP=1 免疫，因为共享链在同一个 rank 内是完整的。
诊断性的根因验证开关：HF_OVERRIDES='{"index_topk_freq":1}' 把跨层共享整个关掉（每层自算），代价是 indexer 计算量 ×4。

5.2 实测退化（同口径 `p5_identity`，sane 采样 `temp=0.8 / top_p=0.9`）

栈	退化率
`PP=1` + MRV1 + MTP	0/40 = 0% ✅
`PP=1` + MRV2 + MTP	0/120 = 0% ✅
`PP=2` + MRV2 + MTP	21/100 = 21% ❌
`PP=2` + `SPEC_METHOD=none`（完全不投机）	19/100 = 19% ❌

失败形态很好认：先答对再循环、从不发出 EOS ，一路打满 3000 token；连正常样本的 token 中位都比 PP=1 长 2.3×（84 vs 37）。
统计上 Fisher 单尾 p = 7.4e-09 。⇒ 缺陷是 PP>1 本身，与投机解码、与 MRV2 都无关。

5.3 修复（方案 B）

patches/sm80_v030/pp_index_share_fix.pyfrag：用 get_pp_indices() 取真实层区间 ，强制"本 rank 内没有索引可复用的那一层"自算；PP=1 时判定恒为 False ⇒ 逐位兼容。修后 p5_identity 0/100 ，完整验收 0/200。

5.4 修复后 PP=2 全面优于 PP=1

指标	旧定稿 `TP=8/PP=1`	`TP=4/PP=2` + 方案 B
`GPU KV cache size`	386,943	597,760（×1.55）
`max_model_len`（单请求上限）	352,000	524,288（×1.49）
单流纯解码	71~81 tok/s	85.6 tok/s
conc4 / conc8 / conc16 聚合	168.1 / 144.8 / 245.8	179.3 / 190.7 / 312.3（+27%）
`p5_identity` 退化	0/120	0/100
5 prompt 轮转退化（N=200）	0/200	0/200
长上下文寻针	300K 3/3	500K 3/3
就绪	654~670 s	540 s

能全面超过的原因有两条，缺一不可：上游 v0.30 在 MRV2 上真正实现了 PP + 投机解码 （PPHandler.broadcast_drafts，上游 #50514 / #46994 / #55745），以及方案 B 把 19~21% 的退化消掉。前者让 PP 不再牺牲单流，后者让 PP 的输出能用。

5.5 层切分与 gate 的耦合（必须 preflight）

rank0 永远不需要翻层 （层 0,1,2 本身就是自算层）；错位只发生在 rank1 的开头。
旧的手写 rank*n//w 区间式在 39/40/41/42 这四档上恰好也安全 （边界都落在两个自算层 38与42 之间），但它是脆的：45,33 这类跨过自算层的切分会让层 45 去复用卡在 PP0 上的层 42 的索引 ⇒ 静默读未写入缓冲 ⇒ 退化复发。
所以方案 B 改用 get_pp_indices()。42,36 是唯一的"零依赖 gate"档 （rank1 首层 42 本身就是自算层），代价是算力 42 vs 39，不如 41,37 的 41 vs 40 均衡。

6. `deploy.sh` 里的 PP 缺省与门禁

脚本自己的变量是PP_LAYER_PARTITION / PP_SIZE / TP_SIZE，其中层切分最终以 VLLM_PP_LAYER_PARTITION 注入容器。

变量	缺省	形式	作用
`TP_SIZE`	4	`--tensor-parallel-size`	张量并行度
`PP_SIZE`	2	`--pipeline-parallel-size`（仅 PP≠1 时加）	流水线并行度
`PP_LAYER_PARTITION`	`41,37`	`VLLM_PP_LAYER_PARTITION`	各 stage 层数
`DISABLE_CUSTOM_ALL_REDUCE`	0	`--disable-custom-all-reduce`	TP=2（含 PP=4）时必须开，否则 graph profiling 阶段 `custom_all_reduce.cuh:164 'invalid argument'` 崩掉 EngineCore
`ALLOW_UNVERIFIED_PP`	0	---	PP>2 的逃生舱
`FORCE_V2_RUNNER`	空（按场景自动）	`VLLM_USE_V2_MODEL_RUNNER`	PP>1 自动 =1

门禁（都在启动前跑，./deploy.sh cmd 预览时也会跑）：

check_pp_dsa_gate() ：PP_SIZE > 2 直接 die，打印"关掉投机仍 20%、开 MTP 45%"与三条替代路径；研究用途可 ALLOW_UNVERIFIED_PP=1 放行（放行时再警告一次，并提示用完跑 ./deploy.sh degen）。三条路径都已验证：缺省 exit 0 / PP=4 exit 1 / 逃生舱 exit 0 且带警告（不是恒真断言）。
check_pp_layer_partition() ：段数必须 == PP_SIZE、各段之和必须 == 78 （num_hidden_layers）、只接受非负整数，否则 die；PP_SIZE <= 1 时只 warn（vLLM 会忽略它）。
check_pp_mtp_compat() / check_pp_ngram_compat() ：按镜像版本判定（vllm_supports_pp_spec() 只在 0.30 为真）。0.30 上 PP>1 + MTP 走 MRV2；SPEC_METHOD=ngram 不在 MRV2 支持列表 ⇒ 直接 die。
resolve_defaults() ：自动选出的 mtp 在"PP>1 且镜像不支持 PP+spec"时降级为 none；PP>1 时自动钉 VLLM_USE_V2_MODEL_RUNNER=1 ，因为 MRV2 对不支持的方法只会静默回退 MRV1，而 MRV1 的 PP+投机正是坏路径。

缺省自证：./deploy.sh defaultcheck 逐项比对 argv（含顺序）与脚本会注入的每一个 -e KEY=VALUE，有漂移即 exit 2。

7. 其余维度：不使用原因

维度	flag	容量乘数	不采纳的原因
DCP（decode context parallel）	`--decode-context-parallel-size`	配置层 ×DCP	本后端启动即断言失败（`TritonMLASparseImpl.can_return_lse_for_decode = False`，`v1/worker/cp_utils.py:47-54`）；即便跳过断言，`mla_attention.py:953-976` 的 `assert lse is not None` 也过不去（overlay 的 `forward_mqa` 显式 `return attn_out, None`）；index 本地化函数 `triton_filter_and_convert_dcp_index` 存在但本后端没调用过（DCP 下会静默读错 KV）；indexer 的 DCP 合并只有 CuteDSL 版、注释写明首发面向 Blackwell/Hopper。尽调结论是 15~25 人日，且它与 fp8 补丁改同一个文件 `triton_mla_sparse_kernel.py`（同一容器路径只能挂一次）⇒ 必须并进 fp8 的补丁链。详见 `05`
PCP（prefill context parallel）	`--prefill-context-parallel-size`	0	官方注释就写明"不增加 KV 分片数 "（`config/parallel.py:126-127`）；还要额外占 GPU（本机 8 卡没余量），并被 MTP + full CUDA graph 双重阻断（`pcp_manager.py:125-162`），而且只支持 MRV2
DP / 两个 TP=4 实例	`--data-parallel-size`	单卡容量不变、只乘总吞吐	需要 16 卡（8 卡做不到）；TP=4 时每卡权重 97.5 GiB > 80 GiB 装不下
EP（专家并行）	`--enable-expert-parallel`	与容量无关	实测 −1.5% （无收益）；且必须同时选对 `--all2all-backend`（默认 `allgather_reducescatter` 不是真 all-to-all），镜像里 pplx 未装
`--block-size` 加大	---	≈0（分子分母抵消）	只影响尾部浪费/对齐；且必须是 64 的倍数
`--num-gpu-blocks-override`	---	不凭空造显存	填大了 OOM、填小了更少
`--kv-cache-memory-bytes`	---	只是"钉住 KV 字节数"	仍受物理显存上限

DCP 与 PP 理论上正交 （一个切序列、一个切层，乘数会相乘），配置校验层也能过，但在拿到 LSE 补丁前不要尝试。

8. PP 层间通信与 NCCL

PP 的通信是相邻 stage 之间的激活张量传递 ，再加一条容易出事的小路径：末 rank 把采样结果广播回其它 stage （_pp_broadcast_prev_sampled_token_ids()）------ v0.28 上 PP>1 + MTP 的第三层崩溃正是它：该广播只在 async 下走、且只支持无投机的形状 [num_reqs, 1]，而带 MTP 时是 [num_reqs, num_spec+1] ⇒ 直接断言失败。

本项目测量过的通信大头是 TP 的 all-reduce ：39.1%（AllReduce 36.4% + AllGather 2.4%）的窗口时间、每步 156 次 × 191 µs ------ 这些都是 TP=8/PP=1 形态的数字。改成 TP=4/PP=2 后，all-reduce 的通信域缩到 stage 内的 4 卡、每 rank 层数减半，同时 stage 之间多出一条点对点路径 ；这两笔账的净量级我们没有单独 profile （--disable-custom-all-reduce 退回 NCCL 的性能代价也未单独测量）。

唯一确定的是：NCCL 的三个旋钮（NCCL_ALGO=allreduce:tree / NCCL_PROTO=LL128 / NCCL_MIN/MAX_NCHANNELS=1）在 TP=8 形态上全部负收益 ，默认 RING_LL 已是最优。

9. 部署配置选择

约束	布局	KV 池	单流（内容受控中位）	conc16	上下文	正确性
综合最优 ← 缺省	`TP=4/PP=2` + `41,37` + MTP k=3 + fp8	729,280	71.3	297~310	512K	✅ 0/200 · 12/12 · 工具往返 100/100
单流优先（旧缺省）	`TP=8/PP=1` + MTP k=3 + fp8	386,943	~68	245.8	352K	✅ 0/120（旧口径）
吞吐优先（可选档）	`TP=4/PP=2` + `41,37` + bf16 KV	458,560	69.2	363	256K	⚠️ 未做退化验收
超长单请求（1M）	`TP=2/PP=4` + `20,20,20,18`	1,199,872（无投机）	64.0	214.4	1M	🔴 20%（无投机）/ 45%（+MTP）退化，已被硬拦

128K 并发的容量账 ：池 729,280 ÷ (131,072 + 256) = 5.55 ⇒ KV 允许 5 条常驻（实测 5/5、6/6 都被收下）。但"能收下 ≠ 更快"：长 prefill 会被调度串行化，墙钟 ≈ 条数 × 50 s，prefill 聚合吞吐恒定 ≈2,600 tok/s。
一句话：PP 是"换容量"的重量手段；在 v0.30 上它恰好不再牺牲单流，因为 MTP 在 PP 下也能工作了。

10. 复现命令