这一篇是部署服务化篇的收官主题是大多数工程师在 70B 模型部署时都会被问到的问题并行怎么切这是一个看似简单实则复杂的问题。前面几篇我们已经多次提到 TP、PP、EP、CP但都是浅尝辄止。今天我们把它们一次性讲透。如果你做过相关工作下面这些问题应该不陌生8 卡 H100 部署 Llama-3-70B用 TP8 还是 TP4PP2跨机部署一定要 PP 吗跨机能不能用 TPDeepSeek-V3 671B 怎么切专家并行EP是什么1M 上下文场景下CPContext Parallel怎么和 TP 配合集群用 InfiniBand 200Gbps 够不够同样是 8 卡为什么 TP8 比 TP4 慢读完本文你将能区分 5 大并行策略的本质差异和适用场景设计混合并行配置3D / 4D 并行根据硬件 模型规模选对最优策略在 vLLM / SGLang 上实战配置各种并行排查通信瓶颈我们开始。一、为什么需要分布式1.1 单卡装不下的硬上限回顾前面我们算过的数字模型FP16 显存INT8 显存INT4 显存Llama-3-8B16 GB8 GB4 GBLlama-3-70B140 GB70 GB35 GBLlama-3-405B810 GB405 GB203 GBDeepSeek-V3 671B1342 GB671 GB336 GB单卡 H100/H200 上限是 80-141GB。所以8B / 14B单卡跑得动32B单卡极限INT470B必须多卡405B / 671B必须跨机1.2 不仅是「装下」分布式推理不只解决装下问题还要解决吞吐多卡分担同一请求 → 单请求快并发多副本独立处理 → 总吞吐高长上下文单卡 KV Cache 不够 → 跨卡分担MoE 专家稀疏激活 → 专家分布跨机网络高带宽互联 vs 低带宽 → 不同策略不同需求对应不同的并行策略。1.3 五大并行策略速览DP - Data Parallel ── 数据并行 ── 切请求 TP - Tensor Parallel ── 张量并行 ── 切层内算子 PP - Pipeline Parallel ── 流水并行 ── 切层 EP - Expert Parallel ── 专家并行 ── 切 MoE 专家 CP - Context Parallel ── 上下文并行 ── 切序列下面逐个深入。二、五大并行策略深度拆解2.1 Data Parallel (DP)最朴素的并行做法把同一个完整模型在多张卡上各放一份每张卡处理不同的请求。卡 0完整模型 请求 A 卡 1完整模型 请求 B 卡 2完整模型 请求 C 卡 3完整模型 请求 D优点实现极简无跨卡通信线性扩展吞吐缺点不省显存——每张卡都要装完整模型70B 模型每张卡都要 140GBFP16 → 单卡 H100 装不下根本不能用 DP适用场景模型小 单卡显存业务高并发多副本部署业务层路由与训练 DP 的区别训练 DP 需要梯度同步AllReduce推理 DP 完全独立。2.2 Tensor Parallel (TP)层内切分核心思想把每一层的算子attention、MLP切到多张卡上并行计算。2.2.1 Attention 切分Multi-Head Attention 天然适合切原始64 个 attention head 在 1 张卡 TP88 个 head / 卡共 8 张卡每张卡算自己那 8 个 head结果通过 AllReduce 合并。2.2.2 MLP 切分FFN 的W1: [d, 4d]和W2: [4d, d]用行列分割W1 切列每张卡持有 [d, 4d/N] W2 切行每张卡持有 [4d/N, d]计算流程x → W1 (列切) → activation → W2 (行切) → AllReduce → output中间结果不需要同步只在最后做一次 AllReduce。2.2.3 TP 的通信代价每层 Transformer Block 通信约2 次 AllReduceattention 后的 AllReduceFFN 后的 AllReduce对 Llama-3-70B80 层每次 forward160 次 AllReduce每次 AllReduce 通信量~ d × batch × seq × 2 bytes这就是为什么 TP 要求高速互联——通信跑不快TP 直接变成性能杀手。2.2.4 通信带宽要求互联类型带宽是否能跑 TPNVLinkH100900 GB/s✅ 完美NVLinkA100600 GB/s✅ 好PCIe 5.064 GB/s△ 勉强PCIe 4.032 GB/s❌ 慢InfiniBand 400G50 GB/s❌ 跨机太慢以太网 100G12.5 GB/s❌ 完全不能核心规则TP 必须用 NVLink 级别的互联跨机做 TP 是灾难。2.2.5 TP 的实际收益理想TP8 → 8× 加速现实TP8 → 5-6× 加速通信开销吃掉一部分随着 TP 数增大通信开销不成比例上升TP 数实际加速通信占比11×0%21.8×10%43.3×17%85.5×31%167×56% ⚠️生产建议TP 通常 ≤ 8单节点内 NVLink跨机要换 PP。2.3 Pipeline Parallel (PP)层间切分核心思想把模型的不同层放到不同卡上。卡 0layers [0-19] 卡 1layers [20-39] 卡 2layers [40-59] 卡 3layers [60-79]请求像在流水线上流过:时刻 1请求 A 在卡 0 时刻 2请求 A 在卡 1请求 B 在卡 0 时刻 3A 在卡 2B 在卡 1C 在卡 0 ...2.3.1 PP 的 bubble 问题最朴素的 PP 有起始 结束的 bubble——前几个 step 后面的卡闲着最后几个 step 前面的卡闲着时刻 1 2 3 4 5 6 7 8 卡 0: A B C D - - - - ← 后期闲 卡 1: - A B C D - - - 卡 2: - - A B C D - - 卡 3: - - - A B C D - ← 前期闲 ^^^^^^^^^^^^ 只有这里满载Bubble 占比约(PP - 1) / 总 step 数。如果总 step 数远大于 PPbubble 影响小。优化1F1B、Interleaved 1F1B通过更精细的调度把不同 micro-batch 交错执行bubble 显著降低传统 PP bubble ~ 40% 1F1B bubble ~ 20% Interleavedbubble ~ 5% DualPipeDeepSeek V3bubble ~ 0%2.3.2 PP 的通信代价PP 通信量比 TP 小得多——只在「层边界」传递激活值每层间一次 send/recv通信量batch × seq × d × 2 bytes适合跨机部署——InfiniBand 完全够用。2.3.3 TP vs PP 决策因素TPPP通信频率高每层 2 次低层间 1 次通信量大小适合互联NVLinkInfiniBand / 跨机实现难度中中等Bubble无有可优化推理友好⭐⭐⭐⭐⭐⭐⭐⭐训练友好⭐⭐⭐⭐⭐⭐⭐⭐⭐推理首选 TP——除非跨机或单层太大。2.4 Expert Parallel (EP)MoE 专属背景DeepSeek-V3 / Mixtral 等 MoE 模型有大量专家256如果按 TP 切每张卡都要装所有专家——显存爆。EP 的做法256 个专家 → 切到 8 张卡每张卡 32 个专家 每个 token 选 8 个专家 → 通过 All-to-All 路由到对应卡通信特点All-to-All每张卡都要和其他卡互发数据通信量 batch × seq × d × 2 bytes不大但全连通2.4.1 EP 的工程挑战1. 专家负载不均某些专家被频繁激活某些几乎不用。对策训练时引入 auxiliary loss-free 负载均衡DeepSeek V3 创新推理时实时监控动态调整2. 跨卡 All-to-All 慢跨节点 All-to-All 是分布式系统中最慢的通信模式。对策同节点内尽量做完通信节点内 EPDeepEP 等专用 All-to-All 库2.4.2 EP 的实际效果DeepSeek V3671B / 37B 激活部署部署配置单卡显存吞吐纯 TPTP1680 GB慢TPEPTP4, EP8 (32 卡)80 GB⭐ 最优纯 EPEP3280 GB中等2.5 Context Parallel (CP)序列切分场景1M 上下文单卡 KV Cache 几百 GB 装不下。做法把序列切到多卡每张卡持有一部分 K/V用 Ring Attention 累积。1M 序列 / 8 卡 每卡 125K 卡 0: token [0, 125K) 卡 1: token [125K, 250K) ... 卡 7: token [875K, 1M)通信特点Ring 通信环形传递 K/V通信和计算 overlap。第 15 篇我们详细讲过这里不再展开。CP 的适用场景上下文 100K模型不大 100B—— 否则 TP 已经把卡用完了高速互联NVLink IB三、混合策略3D 并行 / 4D 并行3.1 单一并行不够用实际生产中单一并行策略往往不够仅 TP跨机变慢仅 PP单卡装不下大层仅 EPMoE 才有效所以工业部署都是混合小模型 (8B-32B) TP 即可 大模型 (70B-405B) TP PP 超大 MoE TP PP EP 长上下文 TP PP CP 全场景 TP PP EP CP (4D)3.2 3D 并行最常见Llama-3-405B 跨机部署16 卡 H1002 节点节点 18 × H100 节点 28 × H100 TP8 in node TP8 in node ↘ ↙ PP2 across nodes总并行度TP8 × PP2 16 GPU为什么这么切TP8 在单节点内 NVLink 通信PP2 跨节点IB 通信量小模型权重均匀分布3.3 4D 并行MoE 超大规模DeepSeek-V3 671B 部署32 卡 H1004 节点TP4 × EP4 × PP2 32 GPU ↓ 节点内TP4 节点间PP2 EP4配置思路TP4单节点 4 卡切层内每卡装 1/4 共享权重EP4跨节点 4 路切专家每节点 64 个专家PP2横跨多组节点3.4 计算公式总卡数 TP × PP × EP × CP × DP举例8 卡部署 70B 模型 TP8, PP1, EP1, CP1, DP1 → 1 个副本 16 卡部署 70B 模型 TP8, PP1, EP1, CP1, DP2 → 2 个副本高并发 16 卡部署 70B 模型 长上下文 TP8, PP1, EP1, CP2, DP1 → 单副本 1M 上下文 32 卡部署 405B 模型 TP8, PP4, EP1, CP1, DP1 → 1 个副本 32 卡部署 671B MoE TP4, PP2, EP4, CP1, DP1 → 1 个副本四、实战配置4.1 vLLM 单机 TP最常用# 8 卡 H100 部署 Llama-3-70B vllm serve meta-llama/Llama-3-70B-Instruct \ --tensor-parallel-size 8 \ --dtype bfloat16 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --port 8000注意事项TP 数必须是num_attention_heads的因子Llama-3-70B 是 64 → TP 可以是 1/2/4/8/16/32/64单节点 NVLink 才合理 TP4.2 vLLM 多机 TP PP# 2 节点 × 8 卡部署 405B # Master 节点 ray start --head --port6379 # Worker 节点 ray start --addressmaster_ip:6379 # 在 Master 上启动 vLLM vllm serve meta-llama/Llama-3-405B-Instruct \ --tensor-parallel-size 8 \ --pipeline-parallel-size 2 \ --distributed-executor-backend ray \ --dtype bfloat16 \ --max-model-len 16384 \ --port 8000关键点必须用 Ray 作为分布式执行器所有节点同样的 vLLM 版本同样的模型权重路径NFS / 分布式存储4.3 vLLM 长上下文 CP# 16 卡部署 70B 1M 上下文 vllm serve meta-llama/Llama-3-70B-Instruct \ --tensor-parallel-size 4 \ --context-parallel-size 4 \ --max-model-len 1048576 \ --kv-cache-dtype fp8 \ --rope-scaling {type:yarn,factor:8.0} \ --enable-chunked-prefill \ --port 8000TP4 CP4 16 卡TP 切模型权重CP 切序列长度4.4 SGLang EP 部署 MoE# 32 卡部署 DeepSeek-V3 python -m sglang.launch_server \ --model-path deepseek-ai/DeepSeek-V3 \ --tp 4 \ --ep 4 \ --pp 2 \ --dist-init-addr master:50000 \ --nnodes 4 \ --node-rank 0 \ --enable-flashinfer \ --port 30000注意SGLang 对 MoE 优化做得更好EP 部署推荐用它。4.5 配置选择决策树模型规模 │ ├─ 30B → 单卡 (DP 多副本) │ ├─ 30-70B → TP 单机 │ └─ 上下文 128K → CP │ ├─ 70-200B (Dense) → TP 单机 / TPPP 双机 │ ├─ 200B-1T (MoE) → TP EP PP 多机 │ └─ 1T → 4D 并行 大型集群五、网络拓扑与硬件要求5.1 通信带宽对应表互联带宽适合NVLink 4(H100)900 GB/sTP 任意NVLink 3(A100)600 GB/sTP ≤ 8NVSwitch900 GB/s整机内 TPInfiniBand HDR(200G)25 GB/sPP / EPInfiniBand NDR(400G)50 GB/sPP / EP / 跨机PCIe Gen564 GB/s仅 DPEthernet RoCE 100G12.5 GB/sDP / 低强度 PPEthernet RoCE 400G50 GB/sPP / EP / 适度 TP5.2 推荐架构单机 8 卡训练 / 推理8 × H100 SXM5NVLink NVSwitch1.8 TB/s 二分带宽完美做 TP88 卡服务器 集群节点内H100 SXM NVLink节点间InfiniBand NDR 400G × 8 网卡适合 TP8 in node PP/EP across nodes经济型方案8 × RTX 4090PCIe 互联适合 DP 多副本不适合 TP不能跨机5.3 通信瓶颈识别部署后看 GPU 利用率nvidia-smi dmon -s u # 实时 utilization nvtop # 多卡可视化异常模式GPU 利用率 50-60% 周期波动 →TP 通信瓶颈GPU 利用率梯子状前面满后面空→PP bubble整体利用率 30% → 通信完全卡死排查工具# NVIDIA Insight / Nsight Systems 跑 trace nsys profile --outputtrace python my_inference.py # 看 NCCL 日志 NCCL_DEBUGINFO vllm serve ...六、生产常见问题6.1 TP 反而变慢症状TP8 比 TP4 还慢。原因通信开销超过算力收益。对策检查 NVLink 是否启用nvidia-smi nvlink -s降 TP 数往往 TP4 已经够提高 batch size增大 compute / communication 比例6.2 PP bubble 严重症状GPU 利用率呈梯子状。对策启用 1F1B 调度vLLM 默认增加 micro-batch 数量减少 PP 数PP2 通常足够6.3 MoE 专家不均衡症状某些卡显存满某些卡空。对策监控专家激活分布训练阶段加 load balance loss推理时启用 Expert Affinity部分框架支持6.4 跨机延迟超预期症状跨机 PP 比预期慢 2-3 倍。对策检查 InfiniBand 拓扑ibstat确认 NCCL 用了 IBNCCL_IB_DISABLE0 NCCL_NETIB测试通信带宽nccl-tests/all_reduce_perf6.5 显存不均衡症状某些卡 OOM某些卡空闲。对策TP 数选择不当不是 head 数的因子PP 切分不均用--pipeline-parallel-balanceKV Cache 量化 offloading七、扩展话题与下一篇预告7.1 Disaggregated Prefill/Decode新趋势2025 年的新方向——把 prefill 和 decode 部署到不同集群Prefill 集群compute-bound高算力 GPU、少量 KV 存储 Decode 集群memory-bound大显存 GPU、强带宽 请求流 用户 → Prefill 集群生成 KV → 传到 Decode 集群生成 token优势两类负载用不同硬件优化资源利用率从 60% 提升到 90%DeepSeek V3 / Llama 4 已经在用7.2 异构硬件混部未来推理集群可能不是同质化的高端 GPU 跑 prefill低端 GPU 跑 decodeCPU 处理 embeddingNPU / TPU 跑特定任务7.3 下一篇预告部署服务化篇 5 篇圆满收官下一阶段进入工程实践篇第 21-25 篇第 21 篇GPU 选型指南 - A100/H100/4090/910B 性价比分析—— 从硬件视角看大模型部署什么场景买什么卡租 vs 买国产卡现状之后是集群运维22 篇、权重管理23 篇、显存优化24 篇、成本测算25 篇。工程实践篇 5 篇收官后我们就接近系列后半段——RAG / Agent / 前沿话题。八、结语分布式推理是大模型工程的内功读完本文你应该明白5 大并行策略DP / TP / PP / EP / CP 各有适用场景TP 用 NVLinkPP 用 IB——通信带宽决定策略混合并行实际生产 70B 模型都是 TPPP超大 MoE 是 4D 并行通信开销随并行度非线性增长——TP16 不一定比 TP8 快Disaggregated Prefill/Decode是下一代架构趋势参考文献分布式推理TP / PP / EP / CP 并行策略详解