副标题大模型单卡放不下不是新闻但多卡不等于快。TP 拆矩阵、PP 拆层、EP 拆 expert——三种分布式思路对应三种通信模式看懂通信代价才能选对并行方案。一、先做一道算术题一张 H100 80GB够大了吧Llama 3 405BFP16 精度模型权重: 405B × 2 bytes 810 GB 需要 810 / 80 10.125 张 H100 才能装下 即使量化到 INT4: 405B × 0.5 bytes 202.5 GB 也需要 202.5 / 80 ≈ 3 张 H100DeepSeek-V3 更夸张——671B 总参数FP16 要 1.3TB。你必须要用多卡。但多卡不能各自为政。GPU 0 上搁着第 1 层GPU 1 上搁着第 30 层——token 从 GPU 0 算到 GPU 29必须能把中间结果传给 GPU 1。这就是分布式推理要解决的核心问题怎么把一个大模型拆到多张 GPU 上让它们协同工作拆法有三种。它们的区别不在于拆成几块而在于在哪个层面拆、拆完怎么拼回来、拼回来要多少通信代价。二、Tensor Parallelism拆矩阵2.1 直觉把一次大矩阵乘法拆成多次小矩阵乘法Transformer 里最重的计算是线性层output input × weight。当weight是一张几千乘几千的大矩阵一张 GPU 算不动——那就切成两块两张 GPU 各算一块再合并结果。一次线性变换: y xW ┌───┐ ┌──────────┤ W ├──────────┐ │ └───┘ │ ▼ ▼ ┌──────┐ ┌──────┐ │ GPU 0│ │ GPU 1│ │ xW₀ │ │ xW₁ │ └───┬──┘ └───┬──┘ └──────────┬───────────┘ ▼ y [xW₀ | xW₁] ← 拼接不需要通信但上面是最简单的 case。Transformer 里的线性层有两种拆法2.2 按列拆Column-wise直接分不用等原始: y xW, W 尺寸 [d_in, d_out] 拆法: W [W₀ | W₁] ← 按列切成两块 ↑ ↑ d_out/2 d_out/2 GPU 0 算: y₀ xW₀ ← 不需要知道 W₁ GPU 1 算: y₁ xW₁ ← 不需要知道 W₀ 然后: y [y₀ | y₁] ← 拼接不需要通信按列拆时每张 GPU 独立计算零通信。2.3 按行拆Row-wise算完要合并原始: y xW, W 尺寸 [d_in, d_out] 拆法: W [W₀]ᵀ ← 按行切成两块 [W₁]ᵀ GPU 0 算: y₀ x₀W₀ ← 需要把 x 切成两份 GPU 1 算: y₁ x₁W₁ 然后: y y₀ y₁ ← 需要一次 all-reduce按行拆之后两个 GPU 的中间结果要相加才能得到最终结果——这就引入了通信。2.4 Transformer 里 TP 怎么工作Transformer 的一层里线性变换的顺序是按列 → 激活函数 → 按行。Attention 层: QKV x × W_qkv ← 按列拆三组独立计算零通信 Attention 计算 ← 每张 GPU 独立算自己那部分的 attention output attn × W_o ← 按行拆需要一次 all-reduce FFN 层: gate x × W_gate ← 按列拆 up x × W_up ← 按列拆 down gate × up × W_down ← 按行拆需要一次 all-reduce所以 TP 的通信代价是每层 1-2 次 all-reduce。每次 all-reduce 的通信量约等于 hidden_dim × 2 bytesFP16 下的全量同步。2.5 TP 的通信公式算清楚什么时候值得拆All-reduce 是 TP 的核心通信原语。它的时间由数据量、带宽、跳数决定Ring All-Reduce 的时间公式: T_ar 2 × (n-1)/n × D / B n × L 其中: n TP 组内的 GPU 数 D 每次通信的数据量bytes hidden_dim × 2FP16 B 单条链路的有效带宽bytes/s L 每跳延迟s用两个互联方案代入具体数字模型: Llama 3 70B, hidden_dim 8192, TP8, 每层 2 次 all-reduce NVLink (H100 DGX): B ≈ 50 GB/s单条双向链路 L ≈ 1μs T_ar 2 × 7/8 × 16KB / 50GB/s 8 × 1μs 0.56μs 8μs ≈ 8.6μs → 每层 2 次 17.2μs ← 延迟主导带宽充裕 PCIe 4.0 ×16: B ≈ 32 GB/s实际单条链路带宽 L ≈ 10μs T_ar 2 × 7/8 × 16KB / 32GB/s 8 × 10μs 0.88μs 80μs ≈ 81μs → 每层 2 次 162μs ← 比 NVLink 慢 9 倍光是 all-reduce 的延迟差PCIe 就比 NVLink 慢了近 10 倍。但关键在于和计算时间比一层 FFN 的计算时间H100 上: Qwen3-8B 的一层: ~20 TFLOPs 的计算量 在 H100 (989 TFLOPS FP16) 上 ≈ 0.02ms 20μs NVLink 下: T_ar 8.6μs T_compute 20μs ← 通信比计算快TP 纯赚 PCIe 4.0 下: T_ar 81μs T_compute 20μs ← 通信比计算还慢TP 亏了 结论: TP8 在 PCIe 上反而比单卡慢推导出 TP 的有效条件TP 帮助的前提: T_ar T_compute / n T_compute 一层的前向计算时间单卡 T_ar all-reduce 通信时间 如果 T_ar ≈ T_compute / n: 通信代价吃掉全部计算加速 如果 T_ar T_compute / n: TP 比不做 TP 更慢TP 不是多卡就一定快。它只有在卡间通信远快于计算时才有效——这就是 TP 必须依赖 NVLink、不能跨节点的根本原因。三、Pipeline Parallelism拆层3.1 直觉像工厂流水线TP 是把一层的计算拆到多卡。PP 的思路完全不同不同层放在不同 GPU一层算完传给下一层。Llama 3 70B 有 80 层 Transformer, 4 张 GPU: GPU 0: Layer 0-19 ← 处理 token 的前 20 层 ↓ 传给 GPU 1 GPU 1: Layer 20-39 ← 继续处理 20 层 ↓ 传给 GPU 2 GPU 2: Layer 40-59 ↓ 传给 GPU 3 GPU 3: Layer 60-79 ← 输出最终结果 通信: 只在 GPU 之间传一次 hidden state 每批数据只传 3 次4 个 stage 之间传 3 次 通信量 hidden_dim × 2 bytesPP 的通信量比 TP 小得多——不受层数影响只传每层的输出结果。3.2 朴素的 PP 有一个大问题气泡如果你真的GPU 0 算完 20 层才传给 GPU 1那么时间线: GPU 0: ████████████···················· ← 算完 20 层后空等 GPU 1: ·········███···················· ← 等 GPU 0 算完才能开始 GPU 2: ················███············· GPU 3: ····················███········· ↑ 大部分 GPU 大部分时间都在空等这个空等时间叫pipeline bubble流水线气泡。如果一次只处理一个请求气泡率 (p-1)/pp4 时气泡率 75%——四张卡只有一张在工作。3.3 微批量解决气泡的核心方案不一次处理一个请求而是把请求拆成微批量micro-batch。一个 batch 有 16 个 prompt拆成 4 组微批量每组 4 个 prompt 时间线GPipe 方案: Step 1: GPU 0 处理 micro_batch_0 的 layer 0-19 Step 2: GPU 0 处理 micro_batch_1 的 layer 0-19 GPU 1 处理 micro_batch_0 的 layer 20-39 Step 3: GPU 0 → micro_batch_2 GPU 1 → micro_batch_1 GPU 2 → micro_batch_0 Step 4: 所有 GPU 都开始干活有了微批量后气泡率有了明确公式PP 气泡的完整公式: 总时间从第一个微批量进入 pipeline 到最后一个微批量离开: T_total (m p - 1) × T_stage 其中: m 微批数 p pipeline stage 数 T_stage 一个 stage 处理一个微批的时间 有效计算时间 m × T_stage 气泡时间 T_total - 有效时间 (p - 1) × T_stage 气泡率 (p - 1) × T_stage / (m p - 1) × T_stage (p - 1) / (m p - 1) ≈ (p - 1) / m 当 m p 时代入具体数字看气泡率的实际影响p4, 单微批计算时间 T_stage 10ms m4: T_total (44-1)×10 70ms, 气泡率 3/7 ≈ 43% m16: T_total (164-1)×10 190ms, 气泡率 3/19 ≈ 16% m64: T_total (644-1)×10 670ms, 气泡率 3/67 ≈ 4.5% 有效吞吐每秒处理多少微批: 理想吞吐无气泡: m / (m × T_stage) 1 / T_stage 100 batch/s m4: m / T_total 4 / 0.07 57 batch/s ← 损失 43% m16: 16 / 0.19 84 batch/s ← 损失 16% m64: 64 / 0.67 95.5 batch/s ← 损失 4.5%微批量 m 越大气泡率越低有效吞吐越接近理想值。但 m 受两个因素限制显存每个微批都需要独立的前向中间状态m 越大显存占用越大延迟m64 时单批处理时间 670ms交互式场景不可接受工程上的常用权衡推荐配置: p4 → m 取 16-32气泡率 16%-9% p8 → m 取 32-64气泡率 18%-10% p16 → m 取 64-128气泡率 19%-10% 规则: m ≈ 4p 到 8p 之间 → 4p 时气泡率约 20%8p 时气泡率约 10% → 再增大 m 收益递减显存压力反而增加PP 的代价不是通信通信很小而是气泡。要在气泡率、显存、延迟三个维度上找平衡点。3.4 1F1B 调度进一步压气泡GPipe 的先全部前向再全部后向方案在训练场景下气泡仍然不小。一个改进是 1F1BOne-Forward-One-Backward调度前向几步后立即开始反向传播交错执行气泡率更低。不过推理场景通常只有前向传播所以推理中的 PP 气泡率天然比训练低一半。3.5 PP 的适用场景PP 的优势: - 通信量小每 stage 只传一次 hidden state - 对卡间互联要求低PCIe 也够用 - 模型层数越多越好分摊气泡代价 PP 的劣势: - 气泡导致 GPU 利用率不够高 - 需要大 batch 来压气泡不适合低延迟场景 - 层数不够多时 PP 没意义8 层拆到 4 张卡每卡才 2 层四、Expert Parallelism拆 Expert4.1 直觉只适用于 MoEEP 是 MoE 模型特有的并行方式。在 #20 已经详细讨论过这里只回顾核心逻辑。MoE 模型的每个 FFN 层有 N 个 expert如 128 个。每个 expert 放在一张 GPU 上token 通过 router 分配到对应的 GPU 计算。128 个 expert, 4 张 GPU: GPU 0: expert 0-31 ← 驻留 32 个 expert 的权重 GPU 1: expert 32-63 GPU 2: expert 64-95 GPU 3: expert 96-127 每个 token 被 router 分配到 top-8 expert: token₀ → expert 3, 15, 22, 41, 58, 73, 99, 105 → 需要把 token₀ 的 hidden state 发给 GPU 0/1/2/3 通信: All-to-All每张卡向其他所有卡发送/接收4.2 All-to-All 通信公式EP 的通信模式和 TP、PP 都不同TP: all-reduce所有 GPU 同步一份数据 PP: point-to-point相邻 GPU 之间传 EP: all-to-all每张卡向所有其他卡发送不同数据All-to-All 的通信量公式T_alltoall n_tokens × hidden_dim × 2 × (n_gpu - 1) / B_nvlink L × n_gpu 通信量取决于: - 每个 token 的 hidden state 大小 (hidden_dim × 2) - 每张卡要向其他 n_gpu - 1 张卡各发一次 - 每个 token 可能被路由到多张卡top-K routing 具体数字: DeepSeek-V3, hidden_dim4096, FP16: 每个 token 的 hidden state 4096 × 2 8 KB top-8 routing, 每张卡固定接收 8/n_gpu 比例的 token Batch128, seq_len1decode: n_tokens 128 每层: 128 × 8 KB × (n_gpu - 1)/n_gpu × 8 ~8 MB 48 层: 48 × 8 MB ~384 MB ← 一次 decode 的总通信量 Batch128, seq_len128prefill: n_tokens 16384 每层: 16384 × 8 KB × (n_gpu - 1)/n_gpu × 8 ~1 GB 48 层: 48 GB ← prefill 阶段 EP 的通信量巨大对比三种并行模式EP 的通信量高一个数量级一个 batch128, hidden_dim4096 的 decode 步骤: TP all-reduce: ~16 KB × 每层 2 次 1.5 MB 总通信量 PP point-to-point: ~8 KB × 每 batch 1 次 × (p-1) ~24 KB EP all-to-all: ~384 MB 总通信量同样是 4 张卡 → EP 的通信量是 TP 的 ~250 倍PP 的 ~16000 倍EP 的独特之处在于它的通信量随 batch 和序列长度线性增长——TP 和 PP 都不随 batch 变TP 只跟 hidden_dim 有关PP 跟 stage 数有关。这导致了一个反直觉的结论EP 不适合大 batch 长序列的场景prefill 阶段 EP 在 decode 小 batch 时相对友好batch1 时 all-to-all 只有 ~24 KB 所以工程实践中常见: 小 batch decode 做 EP通信量小 大 batch prefill 尽量让 expert 集中减少 all-to-all 频次五、三种并行能组合吗实际部署中你不会只选一种——大型模型通常是三种并行一起用。5.1 Megatron-LM 的三维并行NVIDIA Megatron 框架定义了经典的组合方式单节点8 张 H100NVLink 互联: TP 8 ← 8 张卡做 Tensor Parallel把一层拆到 8 卡 NVLink 速度快all-reduce 开销可接受 跨节点多个节点InfiniBand 互联: PP 4 ← 4 个节点做 Pipeline Parallel 节点间通信带宽低PP 的传输量正好最小 数据并行多路复制: DP 64 ← 64 路数据并行处理不同请求 每个 DP 副本内部是 TP8 PP4 总 GPU 数: 8 × 4 × 64 2048 张 GPU这个TP 在节点内、PP 跨节点的原则已经成为业界默认的最佳实践。5.2 为什么 TP 不跨节点场景 A: TP8 跨 2 个节点每个节点 4 张卡 → attention 层的一次 forward 需要 1 次 all-reduce → all-reduce 的 8 张卡分属不同节点 → 需要跨节点同步通信延迟从 ~2μs 跳到 ~100μs → 每层都有这个开销80 层就是 8ms → 比计算本身还慢 场景 B: TP4 在单节点内PP2 跨 2 个节点 → 节点内部 all-reduce 只要 ~2μs → 节点之间只传一次 hidden state每 batch 一次 → 总通信开销远小于场景 ATP 是带宽敏感、频次高的通信模式。PP 是带宽宽松、频次低的通信模式。总是用 TP 压短距离、用 PP 接长距离。5.3 EP 的摆放位置MoE 模型DeepSeek-V3、Mixtral的 EP 通常在 PP 之上、TP 之下的位置摆放单节点内: TP EP TP 处理 attention 层的矩阵拆分 EP 把 expert 分布到节点内不同的 GPU 跨节点: PP 不同节点之间用 PP 串起来 为什么 EP 要在节点内 因为 EP 的 all-to-all 通信量太大了 跨节点做 EP 会导致节点间通信成为瓶颈5.4 一个具体例子DeepSeek-V3 的部署DeepSeek-V3 (671B 总参, 37B 激活, 256 experts, top-8): 部署配置根据论文推测: 单节点: 8 × H800 (NVLink) TP 8节点内做 Tensor Parallel 跨节点: 通过 InfiniBand 互联 EP 覆盖多个节点256 experts 分布在 64 节点上 注意: DeepSeek 的 MLA DeepSeekMoE 架构 → attention 层可以共享节省显存 → expert 分得更细更多 expert更稀疏 → all-to-all 通信压力更大六、三个典型模型的推演把前面的公式汇总用三个真实模型走一遍选型过程。注意这里的数字是估算量级不是精确 benchmark——但量级已经足以判断该用哪种并行。6.1 Llama 3 70B单节点内 TP 就够了模型特征: hidden_dim 8192, 80 层, FFN intermediate_dim 28672 单层计算量 ≈ 2 × (8192 × 28672 × 2 4 × 8192²) ≈ 1.5B FLOPs 单层 H100 计算时间 ≈ 1.5B / 989 TFLOPS ≈ 1.5μs 显存需求: FP16: 70B × 2 140 GB → 一张 H100 放不下 INT4: 70B × 0.5 35 GB → 一张 H100 刚好装下 决策路径: Step 1 — 需要分布式吗 量化到 INT4 后一张 H100 能装下 → 不需要分布式 但单卡推理太慢 → 用多卡分摊计算 → 需要 TP Step 2 — TP 划算吗 TP8, hidden_dim8192: T_ar 2 × 7/8 × 16KB / 50GB/s 8 × 1μs 8.6μs T_compute_layer ~1.5μs TP 加速: 1.5μs → 1.5μs / 8 8.6μs 0.19 8.6 8.8μs 啊TP8 反而比单卡慢 6 倍 问题出在计算量太小了。70B 的每层计算量对 H100 来说一眨眼就算完了 而 all-reduce 的延迟8μs主导了总时间。 Step 3 — 减速了那怎么办 两种解法: a) 不拆 TP用 PP把 80 层分到多张卡每张卡算自己的层 PP 通信不随 hidden_dim 变只有 ~0.1μs → 吞吐瓶颈从通信延迟变成气泡率 b) 降 TP 规模TP2 或 TP4 TP2: T_ar 2 × 1/2 × 16KB / 50GB/s 2 × 1μs 2.3μs TP2 每卡算一半: 1.5/2 2.3 3.0μs ← 慢于单卡 TP2 仍然不划算 c) 用更慢的互联PCIe→ 想都别想 结论: 70B 模型在 H100 上单卡推理已经很快了。 用分布式不是为了加速是为了: - 跑 FP16不量化 - 同时服务多个用户高并发 - 长上下文大 KV Cache TP 只在每层计算量远大于 all-reduce 延迟时才真正加速。 70B 的每层计算量在 H100 上刚好处于临界区——TP 加不了速甚至还拖后腿。这个结论反直觉小模型相对硬件来说不适合 TP。但业界还在用 TP 部署 70B——那是因为他们不关心单用户延迟关心的是总吞吐。多卡分摊计算后虽然每步变慢了但可以同时处理更多请求。6.2 Llama 3 405BTP PP 混合跨节点模型特征: hidden_dim 16384, 126 层, FFN intermediate_dim 53248 单层计算量 ≈ 2 × (16384 × 53248 × 2 4 × 16384²) ≈ 5.6B FLOPs 单层 H100 计算时间 ≈ 5.6B / 989 TFLOPS ≈ 5.7μs 显存需求: FP16: 405B × 2 810 GB → 至少 11 张 H100 INT4: 405B × 0.5 202.5 GB → 至少 3 张 H100 决策路径: Step 1 — 需要分布式吗 肯定要。一张卡放不下甚至 INT4 都放不下。 Step 2 — 显存优先还是计算优先 显存优先FP16→ 11 张卡才能装下 → 必须用 PP 分 11 个 stage 计算优先INT4→ 3 张卡装下 → 可以 TPPP 混合 Step 3 — TP 划算吗INT4 场景 hidden_dim16384, 通信量是 70B 的 2 倍: TP8: T_ar 2 × 7/8 × 32KB / 50GB/s 8 × 1μs 9.1μs T_compute_layer ~5.7μs TP 后: 5.7μs / 8 9.1μs 0.71 9.1 9.8μs 还是慢但比 70B 的情况好一点计算占比稍微大了。 TP4: T_ar 2 × 3/4 × 32KB / 50GB/s 4 × 1μs 4.9μs TP 后: 5.7μs / 4 4.9μs 1.4 4.9 6.3μs 比单卡 5.7μs 慢 10%——基本持平。 TP2: T_ar 2 × 1/2 × 32KB / 50GB/s 2 × 1μs 2.6μs TP 后: 5.7μs / 2 2.6μs 2.85 2.6 5.45μs 比单卡快 5%——开始受益了 Step 4 — 整体方案 推荐: TP2 PP24 张 H100 单层时间: 5.45μsTP2 加速 126 层分摊到 2 个 stage: 每 stage 63 层 微批量 m16 时气泡率: (2-1)/16 6.25% 有效吞吐: 接近 2 倍单卡 更强: TP4 PP416 张 H100 跨 2 个节点 节点内 TP4NVLink: 每层 6.3μs 节点间 PP4InfiniBand: 跨节点通信每 batch 一次 微批量 m32 时气泡率: (4-1)/32 9.4% → 16 张卡协同工作是真实部署的典型配置405B 在 H100 上的跨节点部署核心原则就是 TP 不开太大2-4 即可因为 all-reduce 的数据量随 hidden_dim 增大而增大TP 的边际收益递减很快。把省下来的 GPU 给 PP 做更多 stage 来压气泡。6.3 DeepSeek-V3EP 主导MoE 专用方案模型特征: 671B 总参, 37B 激活, 256 experts, top-8 routing hidden_dim 7168, 61 层 MoE FFN 每层: 8 个 expert 激活共 256 个 显存需求: FP16: 671B × 2 1.34 TB → 17 张 H100 才装得下总参数 实际不需要全部在显存——只驻留 expert 权重不激活的可以 offload 但 EP 要求所有 expert 的权重常驻否则要等 IO 决策路径: Step 1 — 能不能不用 EP 不能。671B 参数中大部分是 expert 权重256 × 每个 expert ~2B 参数 如果不做 EP每张卡都要存所有 expert——256 个 expert 一张卡存不下 Step 2 — EP 通信量估算 decode (batch32): 32 个 token × hidden_dim7168 × FP16 32 × 14KB 448 KB top-8 routing, 每张卡需要接收约 8/16 × 32 16 个 token 每层 all-to-all 通信量: ~448 KB × (16-1)/16 × 8 ≈ 3.4 MB 61 层: 61 × 3.4 MB ≈ 207 MB 总通信量 → NVLink 上 ~0.23ms prefill (batch8, seq4096): 8 × 4096 32768 个 token 每层: 32768 × 14KB 448 MB 61 层: 27 GB 总通信量 → prefill 阶段 EP 通信压力很大 Step 3 — EP 需要什么互联 从通信量看EP 在 decode 阶段的通信~207 MB可以接受 但 prefill 阶段的 27 GB 远超 PCIe 的承载能力。 DeepSeek-V3 实际部署时用了 8×H800 节点NVLink 900GB/s 且 prefill 和 decode 做了分离——prefill 阶段减少 expert 参与度 decode 阶段做全量 EP。 决策结论: EP 是 DeepSeek-V3 的必选项但不能无脑用 - 节点内 EP用 NVLink 做 all-to-all - Prefill 和 Decode 分离prefill 压 EP 通信量decode 放量 - 结合 TPattention 用 TPexpert 用 EP - 不做 PPexpert 分摊已经拆开了再加 PP 会放大气泡6.4 三条铁律从推演中提炼1. TP 的加速前提是单层计算 all-reduce 延迟 → hidden_dim 大16384或模型在弱卡上推理才适合 TP → H100 上推理 70B 以下模型TP 大概率是减速的 2. PP 的适用条件是层数足够多 → 每 stage 至少 10 层以上才值得拆 → 微批量 m 至少是 stage 数 p 的 4-8 倍 → 多节点部署时 PP 是默认选项通信量最小 3. EP 是 MoE 的强行绑定——不是选不选的问题 → 用 MoE 就要接受 all-to-all 通信 → 通信量随 batch 增长prefill 阶段压力最大 → NVLink 是 EP 可行的硬前提七、选择哪个——一张决策表TPPPEP拆什么一层内的权重矩阵不同层不同 expertMoE 专用通信模式All-reduce环形或树形Point-to-pointAll-to-all通信频率每层 1-2 次每 batch 每 stage 1 次每层 1 次单次通信量~hidden_dim × 2~hidden_dim × batch × 2~hidden_dim × batch × 2通信总量O(layers × hidden_dim)O(stages × hidden_dim × batch)O(layers × hidden_dim × batch)对互联的要求高需要 NVLink低PCIe 可以高最好 NVLink适用设备单节点内多卡跨节点多卡单节点或多节点 MoEGPU 利用率瓶颈通信延迟气泡率路由不均通信带宽典型应用每个大模型的节点内Llama 3 405B 跨节点DeepSeek-V3, Mixtral还有一个常被忽略的因素这三种并行不是互斥的但实现复杂度是叠加的。TPPP 的实现已经相当复杂再加 EP 就进入了只有几个框架vLLM、SGLang、DeepSpeed能稳定运行的领域。八、总结回到开头的算术题一张 H100 装不下 Llama 3 405B你只能拆。但怎么拆决定了你会遇到什么新问题。TP: 拆矩阵 → 通信成为瓶颈all-reduce 每层一次 解法: NVLink 或者别跨节点 PP: 拆层 → 气泡成为瓶颈GPU 空等 解法: 微批量 1F1B 调度 EP: 拆 expert → All-to-All 带宽成为瓶颈 解法: 节点内 EP 路由均衡分布式推理的核心矛盾不是怎么拆而是拆完怎么合**。三种并行方式的本质差异在于合的代价——TP 合的频繁每层都要PP 合得少但有空等代价EP 合的数据量大all-to-all。**没有一种并行是免费的午餐。TP 最快但受限于 NVLinkPP 对互联最宽容但有气泡EP 专属于 MoE 但通信量最大。理解它们各自的代价才能为你的模型和硬件选择合适的组合。附录进一步阅读Narayanan et al. (2021):Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM— TP PP 的经典论文Shoeybi et al. (2019):Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism— TP 的原始实现DeepSeek-V3 (2024): Technical Report — EP MLA 的工业级实践TP 的 Ring All-Reduce 原理: NVIDIA 的 NCCL 文档vLLM 的分布式推理文档: docs.vllm.ai这个专栏专注于 LLM 推理与部署的底层技术——从算子开发、显存管理、调度策略到生成优化用可运行的代码和可复现的实验把论文里的黑科技变成可以理解、可以动手验证的知识。如果你对GPU 到底在干什么和推理框架做了什么优化这类问题感兴趣欢迎来主页翻翻其他文章。