02 · 并行策略与 PP 切分GLM5.3 CyberSec W4A16权重地址部署仓库地址本篇讲并行策略怎么选：MLA 模型上TP换不来 KV 容量、PP提升容量、PP_LAYER_PARTITION=41,37层切分的来源，以及DP/EP/DCP/PCP不使用的原因。文章目录02 · 并行策略与 PP 切分0. 结论1. 硬件与显存占用计算2. TP 对 KV 容量贡献是 03. PP：按层切分，容量 ≈ ×PP3.1 机制3.2 基于VLLM v0.30定制镜像4. `41,37`：PP 显存均衡的那笔账4.1 `39,39` 下卡 0-3 只用 70.7 GiB4.2 四档切分对照4.3 实测结果（`41,37` 优于预测）5. PP=2 的正确性缺陷与「方案 B」5.1 机制：DSA 的跨层索引共享被切分边界打断5.2 实测退化（同口径 `p5_identity`，sane 采样 `temp=0.8 / top_p=0.9`）5.3 修复（方案 B）5.4 修复后 PP=2 全面优于 PP=15.5 层切分与 gate 的耦合（必须 preflight）6. `deploy.sh` 里的 PP 缺省与门禁7. 其余维度：不使用原因8. PP 层间通信与 NCCL9. 部署配置选择10. 复现命令0. 结论MLA 的 KV 在 TP rank 间完全复制，--tensor-parallel-size对 KV 容量的贡献是0，相关容量占用必须按单卡算。PP是唯一的扩容手段：TP=8/PP=1338,688 →TP=4/PP=2791,744（×2.34）→TP=2/PP=41,193,600（×3.52）；v0.30 定稿形态PP=1386,943 →PP=2 + 41,37729,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%）：主 attention 层:79层（78 主干 +1MTP）×656B（fp8_ds_mla）=51,824B DSA indexer cache:21层（indexer_types=="full"） ×132B=2,772B 每 token/rank=54,596Bblock_size=64⇒ 每 block/rank3,494,144 B（3.332 MiB）338,688token ×54,596B=17.222GiB ≤17.26GiB ✅1 GiB 显存 ≈ 19,668 token 的 KVDSA 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：按层切分，容量 ≈ ×PP3.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 sizemax_model_len单流（内容受控中位）conc16TP=8/PP=1+ MTP k=3 +fp8_ds_mla（单流形态）386,943352,000~68245.8TP=4/PP=2+41,37+ MTP k=3 +fp8_ds_mla（缺省）729,280524,28871.3297~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,744vs PP=2 + MTP623,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.139,39下卡 0-3 只用 70.7 GiB实测（TP=4/PP=2 + MTP k=3 +gmu 0.95；单位 GiB）：权重 + 非 torch峰值 activationCUDAGraph可用 KV实际分配 KV合计nvidia-smiPP0 卡 0-350.982.360.7621.9515.5669.6672,430 MiBPP1 卡 4-756.533.201.4915.56← 瓶颈15.5676.7880,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"：切分瓶颈可用 KVKV 池预测单流算力（层当量，MTP×3）gate 翻层39,39（旧缺省）15.56 GiB597,760（实测）39 vs42rank1: 39,40,4140,3816.86 GiB≈647,700 (+8.4%)40 vs 41rank1: 40,4141,37★18.16 GiB≈697,600 (+16.7%)41 vs 40rank1: 4142,3618.05 GiB≈693,300 (+16.0%)42 vs 39无（零依赖 gate）★ = 同时"KV 最大"且"算力最均衡"。末级每步要替 MTP 跑3 次前向，所以现状39 vs 42末级本来就是流水线的 straggler，挪走两层同时缓解了容量与算力两件事。4.3 实测结果（41,37优于预测）项39,3941,37变化GPU KV cache size597,760729,280+22.0%（优于预测的 +16.7%）524,288 单请求并发1.14×1.39×+22%step_ms（与内容无关）34.1533.70−1.3%单流内容受控中位71.271.3相等（噪声内）agent 档退化0/400/40（后加测 0/200）保持质量探针 / Responses / 工具往返12/1212/12 / 10/10 / 20/20—nvidia-smi（卡 0-3 / 卡 4-7）72,430 / 80,118 MiB79,441 / 79,343 MiB最紧余量 1,802 →2,479 MiB（+38%）安全前置scripts/v030_pp_rebalance.sh preflightPASS：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 + MTP0/40 = 0%✅PP=1+ MRV2 + MTP0/120 = 0%✅PP=2+ MRV2 + MTP21/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_identity0/100，完整验收0/200。5.4 修复后 PP=2 全面优于 PP=1指标旧定稿TP=8/PP=1TP=4/PP=2+ 方案 BGPU KV cache size386,943597,760（×1.55）max_model_len（单请求上限）352,000524,288（×1.49）单流纯解码71~81 tok/s85.6 tok/sconc4 / conc8 / conc16 聚合168.1 / 144.8 / 245.8179.3 / 190.7 / 312.3（+27%）p5_identity退化0/1200/1005 prompt 轮转退化（N=200）0/2000/200长上下文寻针300K 3/3500K 3/3就绪654~670 s540 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_SIZE4--tensor-parallel-size张量并行度PP_SIZE2--pipeline-parallel-size（仅 PP≠1 时加）流水线并行度PP_LAYER_PARTITION41,37VLLM_PP_LAYER_PARTITION各 stage 层数DISABLE_CUSTOM_ALL_REDUCE0--disable-custom-all-reduceTP=2（含 PP=4）时必须开，否则 graph profiling 阶段custom_all_reduce.cuh:164 'invalid argument'崩掉 EngineCoreALLOW_UNVERIFIED_PP0—PP>2 的逃生舱FORCE_V2_RUNNER空（按场景自动）VLLM_USE_V2_MODEL_RUNNERPP>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 的补丁链。详见05PCP（prefill context parallel）--prefill-context-parallel-size0官方注释就写明"不增加 KV 分片数"（config/parallel.py:126-127）；还要额外占 GPU（本机 8 卡没余量），并被MTP + full CUDA graph 双重阻断（pcp_manager.py:125-162），而且只支持 MRV2DP / 两个 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 层间通信与 NCCLPP 的通信是相邻 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 + fp8729,28071.3297~310512K✅ 0/200 · 12/12 · 工具往返 100/100单流优先（旧缺省）TP=8/PP=1+ MTP k=3 + fp8386,943~68245.8352K✅ 0/120（旧口径）吞吐优先（可选档）TP=4/PP=2+41,37+bf16KV458,56069.2363256K⚠️ 未做退化验收超长单请求（1M）TP=2/PP=4+20,20,20,181,199,872（无投机）64.0214.41M🔴 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. 复现命令# ① 缺省（= TP=4/PP=2 + 41,37 + 512K + fp8 + MTP k=3）与缺省自证./deploy.sh start ./deploy.shwait./deploy.sh cmd# 只看要拼出的命令行，不启动./deploy.sh defaultcheck# argv 逐项 + env 全部比对；有漂移 exit 2# ② 回退/对照PP_LAYER_PARTITION=39,39./deploy.sh start# 旧切分（KV 597,760）TP_SIZE=8PP_SIZE=1MAX_MODEL_LEN=352000./deploy.sh start# 单流形态（KV 386,943）KV_CACHE_DTYPE=bfloat16MAX_MODEL_LEN=262144./deploy.sh start# 吞吐档（conc16 ≈363）# ③ 层切分的 gate 安全性与完整 A/B（preflight 不动服务）scripts/v030_pp_rebalance.sh preflight scripts/v030_pp_rebalance.sh control# 在当前切分上采基线scripts/v030_pp_rebalance.sh boot41,37# stop + 换切分启动 + 启动门禁scripts/v030_pp_rebalance.sh verify# smoke / needle / degen / speed / qualityscripts/v030_pp_rebalance.sh verdict# 两支的显存·池·速度·退化对比表# ④ PP>2：默认被硬拦；确认拦截与"逃生舱"行为PP_SIZE=4TP_SIZE=2./deploy.sh start# 期望 exit 1（check_pp_dsa_gate）ALLOW_UNVERIFIED_PP=1TP_SIZE=2PP_SIZE=4PP_LAYER_PARTITION=20,20,20,18\MAX_MODEL_LEN=1048576DISABLE_CUSTOM_ALL_REDUCE=1./deploy.sh start# 研究用途，警告放行# ⑤ 正确性判据（PP 切分的真正验收线，不是容量）./deploy.sh degen# agent 档退化（有退化 exit 2）AGENT_PROBE_TRIALS=200./deploy.sh degen# 收窄上界# ⑥ 根因诊断开关（不是推荐配置）：关掉 DSA 跨层索引共享，indexer 计算量 ×4HF_OVERRIDES='{"index_topk_freq":1}'./deploy.sh start
02 · 并行策略与 PP 切分GLM5.3 CyberSec W4A16权重地址部署仓库地址本篇讲并行策略怎么选：MLA 模型上TP换不来 KV 容量、PP提升容量、PP_LAYER_PARTITION=41,37层切分的来源，以及DP/EP/DCP/PCP不使用的原因。文章目录02 · 并行策略与 PP 切分0. 结论1. 硬件与显存占用计算2. TP 对 KV 容量贡献是 03. PP：按层切分，容量 ≈ ×PP3.1 机制3.2 基于VLLM v0.30定制镜像4. `41,37`：PP 显存均衡的那笔账4.1 `39,39` 下卡 0-3 只用 70.7 GiB4.2 四档切分对照4.3 实测结果（`41,37` 优于预测）5. PP=2 的正确性缺陷与「方案 B」5.1 机制：DSA 的跨层索引共享被切分边界打断5.2 实测退化（同口径 `p5_identity`，sane 采样 `temp=0.8 / top_p=0.9`）5.3 修复（方案 B）5.4 修复后 PP=2 全面优于 PP=15.5 层切分与 gate 的耦合（必须 preflight）6. `deploy.sh` 里的 PP 缺省与门禁7. 其余维度：不使用原因8. PP 层间通信与 NCCL9. 部署配置选择10. 复现命令0. 结论MLA 的 KV 在 TP rank 间完全复制，--tensor-parallel-size对 KV 容量的贡献是0，相关容量占用必须按单卡算。PP是唯一的扩容手段：TP=8/PP=1338,688 →TP=4/PP=2791,744（×2.34）→TP=2/PP=41,193,600（×3.52）；v0.30 定稿形态PP=1386,943 →PP=2 + 41,37729,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%）：主 attention 层:79层（78 主干 +1MTP）×656B（fp8_ds_mla）=51,824B DSA indexer cache:21层（indexer_types=="full"） ×132B=2,772B 每 token/rank=54,596Bblock_size=64⇒ 每 block/rank3,494,144 B（3.332 MiB）338,688token ×54,596B=17.222GiB ≤17.26GiB ✅1 GiB 显存 ≈ 19,668 token 的 KVDSA 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：按层切分，容量 ≈ ×PP3.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 sizemax_model_len单流（内容受控中位）conc16TP=8/PP=1+ MTP k=3 +fp8_ds_mla（单流形态）386,943352,000~68245.8TP=4/PP=2+41,37+ MTP k=3 +fp8_ds_mla（缺省）729,280524,28871.3297~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,744vs PP=2 + MTP623,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.139,39下卡 0-3 只用 70.7 GiB实测（TP=4/PP=2 + MTP k=3 +gmu 0.95；单位 GiB）：权重 + 非 torch峰值 activationCUDAGraph可用 KV实际分配 KV合计nvidia-smiPP0 卡 0-350.982.360.7621.9515.5669.6672,430 MiBPP1 卡 4-756.533.201.4915.56← 瓶颈15.5676.7880,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"：切分瓶颈可用 KVKV 池预测单流算力（层当量，MTP×3）gate 翻层39,39（旧缺省）15.56 GiB597,760（实测）39 vs42rank1: 39,40,4140,3816.86 GiB≈647,700 (+8.4%)40 vs 41rank1: 40,4141,37★18.16 GiB≈697,600 (+16.7%)41 vs 40rank1: 4142,3618.05 GiB≈693,300 (+16.0%)42 vs 39无（零依赖 gate）★ = 同时"KV 最大"且"算力最均衡"。末级每步要替 MTP 跑3 次前向，所以现状39 vs 42末级本来就是流水线的 straggler，挪走两层同时缓解了容量与算力两件事。4.3 实测结果（41,37优于预测）项39,3941,37变化GPU KV cache size597,760729,280+22.0%（优于预测的 +16.7%）524,288 单请求并发1.14×1.39×+22%step_ms（与内容无关）34.1533.70−1.3%单流内容受控中位71.271.3相等（噪声内）agent 档退化0/400/40（后加测 0/200）保持质量探针 / Responses / 工具往返12/1212/12 / 10/10 / 20/20—nvidia-smi（卡 0-3 / 卡 4-7）72,430 / 80,118 MiB79,441 / 79,343 MiB最紧余量 1,802 →2,479 MiB（+38%）安全前置scripts/v030_pp_rebalance.sh preflightPASS：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 + MTP0/40 = 0%✅PP=1+ MRV2 + MTP0/120 = 0%✅PP=2+ MRV2 + MTP21/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_identity0/100，完整验收0/200。5.4 修复后 PP=2 全面优于 PP=1指标旧定稿TP=8/PP=1TP=4/PP=2+ 方案 BGPU KV cache size386,943597,760（×1.55）max_model_len（单请求上限）352,000524,288（×1.49）单流纯解码71~81 tok/s85.6 tok/sconc4 / conc8 / conc16 聚合168.1 / 144.8 / 245.8179.3 / 190.7 / 312.3（+27%）p5_identity退化0/1200/1005 prompt 轮转退化（N=200）0/2000/200长上下文寻针300K 3/3500K 3/3就绪654~670 s540 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_SIZE4--tensor-parallel-size张量并行度PP_SIZE2--pipeline-parallel-size（仅 PP≠1 时加）流水线并行度PP_LAYER_PARTITION41,37VLLM_PP_LAYER_PARTITION各 stage 层数DISABLE_CUSTOM_ALL_REDUCE0--disable-custom-all-reduceTP=2（含 PP=4）时必须开，否则 graph profiling 阶段custom_all_reduce.cuh:164 'invalid argument'崩掉 EngineCoreALLOW_UNVERIFIED_PP0—PP>2 的逃生舱FORCE_V2_RUNNER空（按场景自动）VLLM_USE_V2_MODEL_RUNNERPP>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 的补丁链。详见05PCP（prefill context parallel）--prefill-context-parallel-size0官方注释就写明"不增加 KV 分片数"（config/parallel.py:126-127）；还要额外占 GPU（本机 8 卡没余量），并被MTP + full CUDA graph 双重阻断（pcp_manager.py:125-162），而且只支持 MRV2DP / 两个 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 层间通信与 NCCLPP 的通信是相邻 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 + fp8729,28071.3297~310512K✅ 0/200 · 12/12 · 工具往返 100/100单流优先（旧缺省）TP=8/PP=1+ MTP k=3 + fp8386,943~68245.8352K✅ 0/120（旧口径）吞吐优先（可选档）TP=4/PP=2+41,37+bf16KV458,56069.2363256K⚠️ 未做退化验收超长单请求（1M）TP=2/PP=4+20,20,20,181,199,872（无投机）64.0214.41M🔴 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. 复现命令# ① 缺省（= TP=4/PP=2 + 41,37 + 512K + fp8 + MTP k=3）与缺省自证./deploy.sh start ./deploy.shwait./deploy.sh cmd# 只看要拼出的命令行，不启动./deploy.sh defaultcheck# argv 逐项 + env 全部比对；有漂移 exit 2# ② 回退/对照PP_LAYER_PARTITION=39,39./deploy.sh start# 旧切分（KV 597,760）TP_SIZE=8PP_SIZE=1MAX_MODEL_LEN=352000./deploy.sh start# 单流形态（KV 386,943）KV_CACHE_DTYPE=bfloat16MAX_MODEL_LEN=262144./deploy.sh start# 吞吐档（conc16 ≈363）# ③ 层切分的 gate 安全性与完整 A/B（preflight 不动服务）scripts/v030_pp_rebalance.sh preflight scripts/v030_pp_rebalance.sh control# 在当前切分上采基线scripts/v030_pp_rebalance.sh boot41,37# stop + 换切分启动 + 启动门禁scripts/v030_pp_rebalance.sh verify# smoke / needle / degen / speed / qualityscripts/v030_pp_rebalance.sh verdict# 两支的显存·池·速度·退化对比表# ④ PP>2：默认被硬拦；确认拦截与"逃生舱"行为PP_SIZE=4TP_SIZE=2./deploy.sh start# 期望 exit 1（check_pp_dsa_gate）ALLOW_UNVERIFIED_PP=1TP_SIZE=2PP_SIZE=4PP_LAYER_PARTITION=20,20,20,18\MAX_MODEL_LEN=1048576DISABLE_CUSTOM_ALL_REDUCE=1./deploy.sh start# 研究用途，警告放行# ⑤ 正确性判据（PP 切分的真正验收线，不是容量）./deploy.sh degen# agent 档退化（有退化 exit 2）AGENT_PROBE_TRIALS=200./deploy.sh degen# 收窄上界# ⑥ 根因诊断开关（不是推荐配置）：关掉 DSA 跨层索引共享，indexer 计算量 ×4HF_OVERRIDES='{"index_topk_freq":1}'./deploy.sh start