July 2, 2026 中 #LLM Training #Distributed Training #Pipeline Parallelism

Tangram：为异构GPU集群隐藏硬件差异的高效LLM并行化系统

笔记日期： 2026-07-02 笔记作者： Zhongzhu Zhou 论文标题： Tangram: Hiding GPU Heterogeneity for Efficient LLM Parallelization 作者： Yanda Tao, Ana Klimovic arXiv： 2606.16907 状态/发表： arXiv 预印本，2026年6月（苏黎世联邦理工学院，cs.DC）

一句话总结

Tangram 的核心思想是：把”如何在异构 GPU 集群上找最优并行化方案”这个指数级搜索问题，拆解成”若干个同构子问题 + 一次动态规划组合”——让现有同构并行化器只看到各自的”GPU 岛”（一组性能相近的 GPU），规划出局部计划；再由 Tangram 的 DP 层把局部计划拼成一条全局负载均衡的流水线——在不修改任何现有工具的前提下，在异构集群上实现同等甚至更高的训练吞吐量。

前置知识

理解 Tangram 需要掌握以下五个基础概念。下面会逐一讲清楚，不假设有分布式训练系统经验。

1. LLM 训练的内存需求：为什么一块GPU装不下

训练一个大语言模型，每次参数更新需要在内存中同时保存：

模型参数（Parameters）：例如 70B 参数 × 2 bytes（BF16）= 140 GB
优化器状态（Optimizer states）：Adam 优化器存一阶矩 $m$ 和二阶矩 $v$ ，均为 FP32。所以占用 70B × 4 bytes × 2 = 560 GB
梯度（Gradients）：与参数同形，FP32 约 280 GB
激活值（Activations）：前向传播时各层的中间结果，用于反向传播。大小与批大小和序列长度成正比，通常 80–200 GB

总计：约 1 TB——而单块 H100 GPU 只有 80 GB HBM。因此，模型必须分布到多块 GPU 上才能训练。

这个内存分解可以写成：

M_{\text{device}} = M_{\text{params}} + M_{\text{optimizer}} + M_{\text{grad}} + M_{\text{activations}} \tag{1}

内存压力的数量级感受：单块 A100 80 GB HBM，如果什么优化都不做，连一个 7B 模型的 Adam 优化器状态都放不下（7B × 4 bytes × 2 = 56 GB，加上参数本身 14 GB 共 70 GB，恰好在临界线）。对于 70B 模型，没有分布式并行根本无法启动训练。

2. 五种并行策略：切模型还是切数据

现代分布式 LLM 训练将以下五种策略组合使用：

（1）数据并行（Data Parallelism, DP）

每块 GPU 保存一份完整的模型副本，但处理不同的数据。训练结束时所有副本的梯度做 AllReduce 同步。内存没有节省（每块 GPU 都存完整参数），但计算被分散了。

（2）张量并行（Tensor Parallelism, TP）

把单个权重矩阵切开，分到多块 GPU 上。例如，一个 $d \times d$ 的 attention 权重矩阵，按列切成 TP=4 份，每块 GPU 存 $d \times (d/4)$ 。计算时各 GPU 各算各的部分，再做 AllReduce 合并结果。每一层都需要通信，因此必须用高带宽互联（NVLink），不适合跨节点使用。

（3）流水线并行（Pipeline Parallelism, PP）

把模型的层按顺序切成若干 stage，每个 stage 分配给一批 GPU。数据像工厂流水线一样从 stage 0 流到 stage $K-1$ ，相邻 stage 之间只需要传递激活值（点对点通信，数据量远小于 TP 的 AllReduce）。代价是产生流水线气泡（bubble）：stage 填充和排空时有 GPU 处于空闲状态。

（4）上下文并行（Context Parallelism, CP）

把输入序列的长度维度切分到多块 GPU 上。例如 4096 个 token 切成 4 份，每块 GPU 处理 1024 个。Attention 计算时需要跨 GPU 汇聚信息（ring AllReduce）。专为长序列训练设计。

（5）专家并行（Expert Parallelism, EP）

专门用于混合专家（MoE）模型。把不同的专家（expert）分配到不同 GPU 上，token 根据路由器的决策被发送到对应 GPU 的专家处理（AlltoAll 通信）。可以在不增加单步计算量的情况下大幅扩大模型参数量。

3. 内存节省技术：更多工具箱

在并行策略之外，还有四种内存节省技术可以与并行策略叠加使用：

梯度累积（Gradient Accumulation, GA）：把一个大批次拆成多个 micro-batch 顺序处理，梯度累加后一次性更新参数。等效于增大批次而不增加瞬时内存峰值。

激活重计算（Activation Recomputation, RC）：前向传播时不保存中间激活值，反向传播时现算现用。代价是多跑一次前向传播（约 33% 额外算力），但内存节省极为显著。Aceso 支持逐算子 RC（只对内存占用最大的算子做重计算，兼顾内存和速度）。

激活卸载（Activation Offloading, OF）：把激活值在 CPU 内存和 GPU HBM 之间来回搬运，用 PCIe 带宽换 GPU HBM 空间。

ZeRO 冗余消除（ZeRO / FSDP）：把优化器状态（ZeRO Stage 1）、梯度（Stage 2）、参数（Stage 3 = FSDP）都切分到所有数据并行的 GPU 上，每块 GPU 只保存 $1/N_{\text{DP}}$ 份，大幅降低每块 GPU 的内存占用，代价是参数更新时需要额外的 AllGather 通信。

4. 自动并行化器：为什么需要它

给定一个模型架构和集群规格，手工设计最优的并行化方案极为复杂：

TP 度 × PP 度 × DP 度 × EP 度 × ZeRO stage × RC 策略 × GA 度 = 多维搜索空间
不同选择的组合对内存和通信的影响互相耦合
对 512 GPU 集群，可能的方案数量超过百亿

因此学界开发了自动并行化器，代表性系统：

系统	年份	搜索策略	支持特性
Alpa	2022	ILP + 动态规划	TP/PP/DP
Galvatron	2022	决策树	TP/PP/DP/CP/ZeRO
Aceso	2024	迭代瓶颈消除	TP/PP/DP/逐算子RC
Mist	2025	MILP + 枚举	TP/PP/DP/GA/RC/OF/ZeRO
HyperTron	2025	模拟退火	TP/PP/DP/CP/EP

这些系统都假设集群同构（所有 GPU 性能完全一致）。同构假设带来巨大的搜索空间对称性：任意旋转相同 GPU 上的分配方式结果相同，因此很多方案是等价的，可以大量剪枝。

5. 异构集群：现实世界中无处不在的挑战

每当组织购买新一代 GPU（H200）时，旧 GPU（A100、H100）并不会全部退役——它们已经摊销了成本，仍有可观的算力。于是集群逐渐积累成混杂了多个 GPU 世代的异构集群。

典型的异构集群组成示例：

graph TD
    subgraph 典型异构训练集群
    A["A100-80GB 节点 (128块)\n峰值算力: 312 TFLOP/s BF16\nHBM: 80 GB\n互联: IB HDR 200 Gb/s"]
    B["H100-SXM-80GB 节点 (64块)\n峰值算力: 989 TFLOP/s BF16\nHBM: 80 GB\n节点内互联: NVLink 900 GB/s"]
    C["H200-141GB 节点 (32块)\n峰值算力: 1979 TFLOP/s BF16\nHBM: 141 GB\n节点内互联: NVLink 900 GB/s"]
    end
    A -- IB 200 Gb/s --> B
    B -- IB 200 Gb/s --> C

图1：典型异构 GPU 集群。 A100 算力约为 H100 的 1/3，H200 约为 H100 的 2 倍，三者 HBM 容量也各不相同，节点间互联带宽差异更大（节点内 NVLink vs. 节点间 IB）。

异构集群带来三个核心挑战：

挑战1：分区不对称。 同构 PP 可以给每个 stage 分配相同数量的层（因为 GPU 算力相同）。异构 PP 必须给算力更强的 GPU 分配更多层，否则快 GPU 闲置等慢 GPU——但”分多少合适”取决于具体的并行度选择，形成循环依赖。

挑战2：Placement 敏感性。 TP 要求节点内高带宽互联（NVLink），如果跨节点做 TP，通信带宽从 NVLink 的 900 GB/s 降到 IB 的 25 GB/s（200 Gb/s÷8），AllReduce 开销增加 36 倍。因此 placement（哪块 GPU 做 TP）必须与并行度决策共同优化。

挑战3：搜索空间爆炸。 对 $N$ 块 GPU 和 $K$ 种不同 GPU 类型，placement 的数量是多项式系数 $\binom{N}{N_1, N_2, \ldots, N_K}$ 。对 512 GPU 集群、3 种 GPU：搜索空间乘以 $\sim 10^{10}$ ，直接无法暴力搜索。

现有异构并行化器的应对策略：砍特性（去掉 EP、ZeRO、CP 等），缩小搜索空间。结果是，一个忽视异构性但保留全特性的同构器（Aceso），在异构集群上比专门处理异构性但砍掉 RC 的异构器（Metis）吞吐量高出 2.3 倍——因为特性完整性比异构感知更重要。这就是 Tangram 要解决的根本矛盾。

Tangram 的核心设计：解耦规划与异构性

flowchart TD
    A[异构GPU集群\nA100 + H100 + H200] --> B[GPU岛构建\n按性能特征聚类+贪心合并]
    B --> C1[岛0：64× H100 SXM\n同构，NVLink互联]
    B --> C2[岛1：128× A100 80GB\n同构，IB互联]
    B --> C3[岛2：32× H200 141GB\n同构，NVLink互联]
    C1 --> D[模型切片×GPU岛枚举\n+ 四轮剪枝 减少26×]
    C2 --> D
    C3 --> D
    D --> E1[调用同构并行化器\n切片0:20 on 岛0\n→PartialPlan{TP=4,ZeRO=2,RC=sel}]
    D --> E2[调用同构并行化器\n切片20:60 on 岛1\n→PartialPlan{TP=8,ZeRO=3,RC=full}]
    D --> E3[调用同构并行化器\n切片60:80 on 岛2\n→PartialPlan{TP=4,EP=8,ZeRO=2}]
    E1 --> F[动态规划组合\n最大化全局流水线吞吐量]
    E2 --> F
    E3 --> F
    F --> G[全局计划：3-stage负载均衡流水线\nBubble ratio < 5%]

图2：Tangram 整体架构。 五步流程：(1) GPU 岛构建，(2) 模型切片枚举，(3) 调用同构并行化器生成局部计划，(4) 四轮剪枝缩小搜索空间，(5) DP 组合生成全局计划。同构并行化器对异构性完全无感知。

组件详解

组件1：GPU 岛构建算法

目标：识别出哪些 GPU “足够相似”，可以作为同构组交给现有并行化器。

两组度量指标：

节点内指标（每个节点独立衡量）：

峰值算力 $C_g$ （TFLOP/s BF16）
HBM 容量 $M_g$ （GB）
HBM 带宽 $B_{\text{mem},g}$ （GB/s）
节点内 NVLink 带宽 $B_{\text{NVL},g}$ （GB/s）

节点间指标：

网络互联带宽 $B_{\text{net},g,g'}$ （Gb/s）：IB/RoCE/Ethernet

完整算法：

算法1：GPU 岛构建（两阶段：初始聚类 + 贪心合并）
-------------------------------------------------
输入：
  G = 所有 GPU 节点
  各节点指标 C[g], M[g], B_mem[g], B_NVL[g], B_net[g,g']
  相似度阈值 τ_C, τ_M, τ_B（建议值: 0.2 = 20%相对偏差）
  合并阈值 t_merge（合并后吞吐下降可容忍的最大幅度）

阶段1：初始聚类（按性能指标建图，提取连通分量）
  对每对节点 (g_i, g_j)：
    若 |C[g_i]-C[g_j]|/max(C) ≤ τ_C
    AND |M[g_i]-M[g_j]|/max(M) ≤ τ_M
    AND |B_mem[g_i]-B_mem[g_j]|/max(B_mem) ≤ τ_B：
      连边 (g_i, g_j)
  初始岛 = 相似度图的连通分量

阶段2：贪心合并（减少岛数，降低后续搜索复杂度）
  建立优先队列 PQ，存储所有岛对 (I_a, I_b)，按合并代价排序
  while PQ 非空：
    (I_a, I_b) = PQ 中代价最小的一对
    bottleneck = 估算合并后 I_a∪I_b 的吞吐瓶颈
    若 bottleneck ≤ t_merge * 当前最优吞吐：
      合并为 I_new = I_a ∪ I_b
      I_new 的有效 HBM = min{M[g] : g ∈ I_new}  // 保守取最小值
      更新 PQ 中涉及 I_new 的合并候选

输出：最终岛集合 I = {I_1, ..., I_K}

算法的关键设计选择及其理由：

为什么有效 HBM 取最小值而非平均值？ 因为并行化器会根据有效 HBM 分配参数，若取平均值（例如 87 GB），在实际跑 80 GB 节点时会触发 OOM（Out of Memory）。保守取最小值是安全但稍微浪费的选择。
为什么贪心合并而非精确最优合并？ 最优合并是 NP 难问题（等价于图划分问题）。贪心按”代价最小”排序足够实用——在实验中岛数通常只有 2–4 个，精确最优和贪心结果一致。

graph LR
    subgraph 合并前
    A1[H100 SXM 80GB\n989 TFLOP/s\n节点A]
    A2[H100 NVL 94GB\n989 TFLOP/s\n节点B]
    end
    subgraph 合并后 - 两者算力相同
    B1[H100 岛\n节点A + 节点B\n有效HBM = 80GB\n有效算力 = 989 TFLOP/s]
    end
    A1 -- "算力相同\nHBM差15%≤20%\n→ 满足合并条件" --> B1
    A2 --> B1

图3：GPU 岛贪心合并示例。 H100 SXM 和 H100 NVL 算力完全相同，HBM 差距 15% 在阈值内，合并为一个岛（保守取 80 GB HBM）。减少岛数可降低后续 (切片, 岛) 对的枚举量。

组件2：模型切片接口

模型切片 $S_{a:b}$ = 完整 L 层 Transformer 的第 $a$ 到第 $b-1$ 层打包成的子模型。

它与完整模型的接口完全一致：

输入：激活张量 $\mathbf{A}_{\text{in}} \in \mathbb{R}^{B \times T \times d}$
参数：第 $a$ 到 $b-1$ 层的所有权重矩阵
输出：激活张量 $\mathbf{A}_{\text{out}} \in \mathbb{R}^{B \times T \times d}$

对同构并行化器，调用接口为：

# Tangram 对同构并行化器的统一调用接口
partial_plan = parallelizer.plan(
    model_slice = S_{a:b},   # Transformer 第 a 到 b-1 层
    gpu_island  = I_k         # 同构 GPU 集合（并行化器只看到这个）
)
# 返回：
#   parallelism: {'TP': 4, 'DP': 16, 'EP': 8, 'ZeRO': 2, 'RC': 'selective'}
#   latency_per_microbatch: τ(p) 秒
#   memory_per_gpu: μ(p) GB
#   activation_output_shape: (B/DP, T/CP, d)  # 供接口兼容性检查

这个接口设计的关键优势：同构并行化器完全无需修改，它看到的是一个”普通的小模型”和”一批同构 GPU”——完全感知不到其外部存在异构集群。因此它的全部特性（EP、ZeRO-3、逐算子 RC 等）都可以无障碍启用。

为什么 Decoder-only 模型天然适合切片？ 因为 Transformer Decoder 所有层的输入输出形状完全相同（ $\mathbb{R}^{B \times T \times d}$ ），所以任意相邻层组合都能构成合法切片。对于 Encoder-Decoder 架构（如 T5）存在 cross-attention 层，cross-attention 需要 encoder 侧的 key/value，切片边界会破坏这个依赖——Tangram 目前不支持此类架构。

组件3：四轮剪枝——将搜索空间缩小26倍

不加剪枝时，枚举所有 (模型切片, GPU 岛) 对的数量是 $O\!\left(\binom{L}{K-1}\right)$ 。对 $L=80, K=3$ ： $\binom{79}{2} = 3081$ 种切法，每种切法对应 $K! = 6$ 种岛分配顺序，合计约 1.8 万对。每次调用 Aceso 需要约 30 秒–5 分钟，不加剪枝会需要数十小时。

规则1：去重（冗余切片去重）

标准 Transformer Decoder 所有层结构相同（同样的 d_model、同样的注意力头、同样的 MLP 结构），因此对同一个 GPU 岛 $I_k$ ：

\text{PartialPlan}(S_{a:b}, I_k) = \text{PartialPlan}(S_{a':b'}, I_k) \quad \text{当} b-a = b'-a' \tag{2}

“任意 20 连续层”在同构岛上的最优计划完全相同，与具体是哪 20 层无关。因此只需对每个岛测试”1层、2层、…、L层”这 $L$ 种切片，而非所有可能的 $(a, b)$ 对。

效果：枚举量从 $O(L^2/2)$ 降到 $O(L)$ ，对 $L=80$ 约减少 40 倍（仅这一条规则）。

规则2：失衡切片剪枝（Unbalanced Pruning）

流水线吞吐量由最慢 stage 决定。如果岛 $I_k$ 的总算力为 $C_k = \sum_{g \in I_k} C_g$ ，则均衡分配应给它 $|S_k|^* = L \cdot C_k / \sum_j C_j$ 层。若提案切片 $S_{a:b}$ 的层数满足：

\frac{b-a}{|S_k|^*} > \beta \quad \text{或} \quad \frac{b-a}{|S_k|^*} < \frac{1}{\beta} \tag{3}

（论文取 $\beta = 2$ ），则该 stage 要么严重超载（慢 GPU 层太多），要么严重欠载（快 GPU 层太少），必然产生极大的流水线气泡。直接丢弃，不调用并行化器。

规则3：内存不可行性剪枝

若切片 $S_{a:b}$ 超过 GPU 岛在最大内存节省下能容纳的上限，则该对物理上不可能成立：

\frac{(b-a) \cdot M_{\text{layer}}}{|I_k| \cdot M_k \cdot (1 - \epsilon)} > \frac{1}{Z_{\max}} \tag{4}

其中 $M_{\text{layer}}$ 是单层参数内存（BF16）， $M_k$ 是每块 GPU 的 HBM， $\epsilon = 0.1$ 为安全余量， $Z_{\max}$ 是最大 ZeRO 分片数（ZeRO-3 时等于 DP 度）。

规则4：接口不兼容性剪枝

相邻两个 stage 之间需要传递激活张量。若上游 stage 用 TP=4（激活被切成 4 份），下游 stage 需要 TP=8（期望 8 份输入），则边界需要插入 AllGather + ReScatter——这个通信代价会被计入吞吐估计。若代价超过阈值则丢弃。

flowchart LR
    A["全部组合\n约1.8万对"] --> B["规则1：去重\n→ 约240对\n(减少75×)"]
    B --> C["规则2：均衡检查\n→ 过滤失衡方案"]
    C --> D["规则3：内存检查\n→ 过滤不可行方案"]
    D --> E["规则4：接口兼容检查\n→ 过滤高代价转换"]
    E --> F["剩余约 1/26\n调用并行化器"]

图4：四轮剪枝流程。 规则1（去重）效果最显著，后三条规则进一步精简。四轮合计 26× 加速，且通过消融验证不遗漏最优方案。

组件4：动态规划组合最优计划

剪枝并调用并行化器后，得到一批局部计划 $\{p_{a:b,k}\}$ ，每个计划描述”切片 $S_{a:b}$ 在 GPU 岛 $I_k$ 上的最优并行化方案及其延迟 $\tau(p)$ ”。

现在需要选出一组”不重叠且拼完整模型”的计划，最大化全局流水线吞吐量。

流水线吞吐量的完整数学推导

记共有 $K$ 个 stage，每个 stage 的单次 micro-batch 计算时延为 $\tau_k$ ，全局批次被拆成 $n_{\text{micro}}$ 个 micro-batch。

一个 micro-batch 在流水线中”前进”一步需要 $\tau_k$ 秒（等待最慢的 stage）。完整的流水线周期时间为：

T_{\text{cycle}} = \underbrace{(n_{\text{micro}} - 1) \cdot \tau_{\max}}_{\text{稳定态：每}\tau_{\max}\text{秒出一个微批次}} + \underbrace{\sum_{k=0}^{K-1} \tau_k}_{\text{填充+排空阶段}} \tag{5}

全局吞吐量（tokens/秒）为：

\text{Throughput} = \frac{B_{\text{global}}}{T_{\text{cycle}}} \tag{6}

气泡比例推导：

理想情况（无气泡）下， $n_{\text{micro}}$ 个微批次各用 $\bar{\tau} = \frac{1}{K}\sum_k \tau_k$ 秒，总时间 $= n_{\text{micro}} \cdot \bar{\tau}$ 。

实际时间 $= T_{\text{cycle}}$ 。气泡比例为：

\text{BubbleRatio} = \frac{T_{\text{cycle}} - n_{\text{micro}} \cdot \bar{\tau}}{T_{\text{cycle}}} = 1 - \frac{n_{\text{micro}} \cdot \bar{\tau}}{(n_{\text{micro}} - 1) \cdot \tau_{\max} + \sum_k \tau_k} \tag{7}

当所有 stage 完全均衡（ $\tau_k = \bar{\tau}$ 对所有 $k$ ）时， $\tau_{\max} = \bar{\tau}$ ，BubbleRatio $\rightarrow 0$ （ $n_{\text{micro}} \rightarrow \infty$ ）。气泡来源于 $\tau_{\max} > \bar{\tau}$ （某个 stage 比平均慢），以及 $n_{\text{micro}}$ 不够大（流水线填充/排空代价占比过高）。

DP 递推公式

设 $f[l][k]$ = “把层 $0 \ldots l$ 分配给前 $k$ 个 GPU 岛”所能达到的最大吞吐量：

f[l][k] = \max_{0 \leq l' < l,\; p_{l':l,k} \text{ 存在}} \; \text{UpdateThroughput}\bigl(f[l'][k-1],\; \tau(p_{l':l,k})\bigr) \tag{8}

边界条件： $f[0][0] = +\infty$ （无层无时间）。

算法2：流水线组合动态规划
--------------------------
输入：
  partial_plans[a:b][k]：每个 (切片, 岛) 对的最优局部计划（含延迟 τ）
  L：总层数，K：岛数量，n_micro：micro-batch 数

初始化：
  f[l][k] = -∞      对所有 (l,k)
  f[0][0] = +∞
  τ_max[0][0] = 0
  τ_sum[0][0] = 0

主循环：
  for k in 1..K:
    for l in 1..L:
      for l' in 0..l-1:
        若 partial_plans[l':l][k] 可行：
          τ_new = partial_plans[l':l][k].latency
          new_τ_max = max(τ_max[l'][k-1], τ_new)
          new_τ_sum = τ_sum[l'][k-1] + τ_new
          # 代入公式 (5)(6) 计算更新后的吞吐量
          new_tp = B_global / ((n_micro-1)*new_τ_max + new_τ_sum)
          若 new_tp > f[l][k]：
            f[l][k] = new_tp
            τ_max[l][k] = new_τ_max
            τ_sum[l][k] = new_τ_sum
            parent[l][k] = (l', k-1)

回溯 parent[L][K] 还原最优切片分配
返回 f[L][K]（全局最大吞吐量）

算法复杂度： $O(L^2 K)$ 时间， $O(LK)$ 空间。对 $L=80, K=3$ ： $80^2 \times 3 = 19200$ 次操作——运行时间远小于 1 秒。

为什么选流水线并行而非张量并行作为跨岛连接手段？

这是 Tangram 整个设计中最重要的取舍决策，值得细讲。

考虑两种跨岛通信方案的数量级对比：

跨岛 TP（每层 AllReduce）：一层 attention 的 AllReduce 数据量 $= 2 \times d \times \text{TP} \times B \times T$ bytes。对 $d=8192, \text{TP}=8, B=1, T=4096$ ： $= 2 \times 8192 \times 8 \times 4096 \times 2\,\text{bytes} = 537\,\text{MB}$ 。在 200 Gb/s（= 25 GB/s）IB 上单次延迟约 537/25000 ≈ 21 ms。80 层 × 21 ms = 1.7 秒/step 纯通信——完全不可接受。
跨岛 PP（每 stage 边界传激活）：激活大小 $= B/DP \times T/CP \times d \times 2\,\text{bytes}$ 。对 $B/DP=1, T/CP=4096, d=8192$ ： $= 4096 \times 8192 \times 2 = 67\,\text{MB}$ 。在 25 GB/s IB 上：67/25000 ≈ 2.7 ms 每 micro-batch——通常可被计算隐藏。

flowchart LR
    subgraph Island 0 H100×64
    S0["Layers 0-19\nTP=4 EP=8 ZeRO-2\n节点内 NVLink 高速互联"]
    end
    subgraph Island 1 A100×128
    S1["Layers 20-59\nTP=8 ZeRO-3 RC=full\n节点内 NVLink/IB互联"]
    end
    subgraph Island 2 H200×32
    S2["Layers 60-79\nTP=4 EP=4 ZeRO-2\n节点内 NVLink 高速互联"]
    end
    S0 -- "PP stage 边界\n67 MB激活值\nIB 200 Gb/s\n延迟 2.7 ms" --> S1
    S1 -- "PP stage 边界\n67 MB激活值\nIB 200 Gb/s\n延迟 2.7 ms" --> S2

图5：跨岛流水线并行通信示意。 每个 GPU 岛内部使用高带宽 NVLink 做 TP 通信，跨岛仅在 PP stage 边界传输一次激活值（67 MB），通信量与 stage 内 TP AllReduce 相比小 3 个数量级。

MoE 模型的支持

对混合专家（MoE）模型，Tangram 集成 Galvatron 的 LAER-MoE 运行时，在每个 GPU 岛内部支持专家并行（EP）。

sequenceDiagram
    participant 用户
    participant Tangram
    participant 并行化器
    participant 运行时
    用户->>Tangram: plan(Mixtral-8x22B, {A100集群+H100集群})
    Tangram->>Tangram: 构建岛 → [Island_A100(128块), Island_H100(64块)]
    Tangram->>并行化器: plan(层0-39, Island_H100)
    Note over 并行化器: 看到的是64块同构H100\n可以用 EP=8 分配8个专家
    并行化器-->>Tangram: PartialPlan{TP=4, EP=8, ZeRO=2, RC=sel}
    Tangram->>并行化器: plan(层40-79, Island_A100)
    Note over 并行化器: 看到的是128块同构A100\n可以用 ZeRO-3 + RC=full
    并行化器-->>Tangram: PartialPlan{TP=8, ZeRO=3, RC=full}
    Tangram->>Tangram: DP 组合 → 全局计划
    Tangram-->>用户: GlobalPlan（2-stage 流水线）
    用户->>运行时: train(Mixtral, GlobalPlan)

图6：Tangram 为 MoE 模型生成计划的交互序列。 专家间的 AlltoAll 路由通信发生在岛内（可使用高带宽互联），跨岛只有 PP 边界的激活传输，通信量不因 MoE 而增加。

为什么 MoE 支持如此重要？ 现有异构并行化器 Metis 和 Sailor 不支持 EP——它们不得不把所有专家复制到每块 GPU（参数冗余 $8\times$ 或更多），严重浪费内存，并降低有效批大小。Tangram 通过在岛内使用 EP，将专家分散存储，对 Mixtral-8x22B 实测吞吐比 Metis 高出 1.8×。

实验结果分析

实验设置

项目	详情
测试模型	LLaMA 70B（密集型），Mixtral-8x22B（MoE），Qwen3-MoE
真实硬件	A100 80GB + H100 SXM 80GB（苏黎世联邦理工 CSCS 集群）
仿真规模	512 GPU 异构/同构集群
基线（同构）	Alpa（2022），Aceso（2024）
基线（异构）	Metis（2024），Sailor（2025）
评测指标	训练吞吐量（tokens/sec），计划生成时间（分钟）

主要结果：异构集群

xychart-beta
    title "70B 模型在 512-GPU 异构集群上的相对吞吐量（以 Aceso=1.0 归一）"
    x-axis ["Alpa", "Aceso", "Metis", "Sailor", "Tangram"]
    y-axis "相对训练吞吐量" 0 --> 2.5
    bar [0.95, 1.0, 0.43, 0.52, 2.3]

图7：70B 模型异构集群吞吐量对比。 Tangram 是 Metis 的 5.3 倍（2.3/0.43），是 Sailor 的 4.4 倍（2.3/0.52），是 Aceso 的 2.3 倍（2.3/1.0）。

最重要的反直觉现象：Aceso（无视异构性）比 Metis（专门处理异构性）快 2.3 倍。

原因分析：

Metis 为了处理异构性，砍掉了激活重计算（RC）——搜索空间立刻缩小，但计划质量退步
Aceso 支持逐算子 RC，可以把最占内存的算子做重计算，释放内存给更大批次 → 更高吞吐
批次大小增加 2× 可以让吞吐提升 1.5–2×，这个收益完全压倒了 Metis 的 placement 优化

这个结果给出了一个重要的系统设计教训：在并行化器设计中，特性完整性（支持全套优化工具）比精确的异构性建模更重要。Tangram 是第一个同时做到两点的系统。

同构集群上的结果

在完全同构集群上，Tangram 与最优同构基线（Aceso）吞吐量持平，同时比 Metis/Sailor 高出最多 3.1×。

这说明 Metis/Sailor 的”能力缺口”（不支持 RC 和 ZeRO）即便在同构集群上也会拖累性能，与异构性无关。

剪枝消融实验

应用的剪枝规则	计划生成时间（相对值）	最终吞吐量
无剪枝	26×	最优（基准）
仅规则1（去重）	8×	最优
规则1+2（均衡）	3×	最优
规则1+2+3（内存）	1.5×	最优
全部四条规则	1×（基线）	最优

四条规则全部启用后，计划生成时间缩短 26 倍，且找到的计划与不剪枝完全相同——证明剪枝规则只过滤掉”保证不最优”的方案。

MoE 模型结果

系统	Mixtral-8x22B 吞吐量（相对值）	EP 支持
Metis	1.0（基线）	不支持（专家复制）
Sailor	1.1	不支持（专家复制）
Tangram	1.8	岛内支持 EP

Tangram 在 MoE 模型上的优势来自两个方面：(1) EP 减少每块 GPU 的专家内存占用，允许更大有效批次；(2) DP 组合按算力比例分配层数，减少流水线气泡。

批判性分析：不足与可改进之处

方法与实验的具体弱点

1. 无容错机制，生产可用性存疑

Tangram 是纯静态规划器：在训练开始前生成一次计划，之后固定不变。然而，在数百块 GPU 上跑数周的大规模训练中，GPU 故障、节点替换、网络波动是常见事件。一块 GPU 故障即导致整个训练作业崩溃，需要重新规划（可能需要数小时）并从检查点恢复。论文 §6 明确将容错列为”超出范围”，但这是生产部署最大的实际障碍。

2. 吞吐量模型忽略计算-通信重叠

公式 (5) 将每个 stage 的延迟视为不可分割的原子操作。而 Megatron 的标准 1F1B 调度方案实际上会让 stage $k$ 在计算当前微批次时，同时把上一个微批次的激活值通过 InfiniBand 发出去（双缓冲异步流水）。这种重叠在网络带宽充足时可以完全隐藏通信延迟，使实际吞吐量高于 Tangram 的预测值。结果是：Tangram 的 DP 在选择计划时可能过度惩罚了高带宽配置，不一定找到真正最优方案。

3. 缺失 2026 年新异构基线对比

论文 Table 1 列出了 HARP、HetAuto、HexiScale 三个 2026 年发表的异构并行化器，但实验部分（§6.2）仅对比了 2024-2025 年的 Metis 和 Sailor。HARP 同样支持 EP 且也用 XLA 后端，是最直接的竞争对手。缺少这一对比使论文”第一个全特性异构并行化器”的定位缺乏有力支撑。

4. 岛内异构性被静默吸收

贪心合并最多允许 20% 算力差异的 GPU 进入同一个岛。同构并行化器按最弱 GPU 的参数规划，岛内最快 GPU 的算力被低估 20%——每个 stage 的实际吞吐可能比预测低 20%。论文没有量化这一误差，也没有对 $\tau_C$ 阈值做敏感性分析。

作者淡化的隐含假设

层均匀性假设：所有 Transformer 层必须有相同的输入/输出形状。对于 d_model 随深度变化的”宽度渐变”架构，或 cross-attention（T5）架构，切片接口失效。论文只测试了标准 Decoder-only LLM，但没有明确说明这一限制。
跨岛数据并行的处理：DP 组合假设不同岛上的 DP 组是独立的。但如果不同岛的 DP 副本需要做跨岛梯度同步（AllReduce），这会引入额外的跨岛通信——论文没有说明如何处理。
micro-batch 数量固定：DP 优化时把 $n_{\text{micro}}$ 当作固定参数，而非联合优化变量。最优 $n_{\text{micro}}$ 取决于 stage 延迟分布——对高度不均衡的流水线，更多微批次可以有效稀释气泡，但也增加激活内存占用。

具体改进建议

A. 增加动态重规划能力

在初始规划阶段缓存所有局部计划（parallelizer 的输出）。当 GPU 发生故障时，仅重新规划受影响的 (切片, 岛) 对（可能只有 1–2 次 parallelizer 调用），然后重新跑 DP 组合（< 1 秒）。结合检查点机制可把故障恢复时间从小时级降到分钟级。

B. 引入计算-通信重叠的精确建模

将公式 (5) 替换为 1F1B schedule 的重叠模型：

T_{\text{cycle}}^{\text{overlap}} = (n_{\text{micro}} - 1) \cdot \tau_{\max} + \sum_k \max\!\left(\tau_k^{\text{compute}},\; \tau_k^{\text{comm}}\right) \tag{9}

这对网络带宽充足（如 H100→H200 间使用 400 Gb/s IB）的配置尤为重要，可以使 DP 在此类场景找到更优计划。

C. 联合优化 $n_{\text{micro}}$

在 DP 的每个候选计划上，额外计算最优 micro-batch 数：

n_{\text{micro}}^* = \arg\max_{n \geq 1} \frac{B_{\text{global}}}{(n-1)\tau_{\max} + \sum_k \tau_k} \tag{10}

这是单变量优化， $O(1)$ 可以求解（对 $n$ 求导置零），不增加实质开销。

D. 扩充实验基线和测试覆盖

加入 HARP、HetAuto、HexiScale 作为基线；测试 5× 算力差异的极端异构场景（A10 vs. H100）；验证对 T5 或混合架构的支持范围。

E. 岛构建阈值敏感性分析

提供一幅” $\tau_C$ 从 0.05 到 0.4”下最终吞吐量的变化曲线图，让用户知道如何根据自己的集群特征设置阈值，而不是依赖经验猜测。

与相关工作的关系

Tangram 处于三条研究线的交叉点：

自动并行化器（Alpa、Aceso、Galvatron）：Tangram 是这些系统的”外层封装”，而非竞争者。同构并行化器的任何改进（更好的搜索算法、新的并行策略支持）都直接使 Tangram 受益——这是一个非常好的可组合性设计。

异构集群管理（Metis、Sailor、HetAuto）：这些系统采用”联合优化并行策略与 placement”的思路，代价是搜索空间爆炸、特性缩水。Tangram 采用”因式分解问题”的思路：把指数搜索变成”多项式子问题 × DP 组合”，以”只能用 PP 连接岛间”的限制换取搜索空间的可控性。

流水线并行调度（GPipe、PipeDream、Megatron 1F1B）：Tangram 的 DP 组合在结构上类似 GPipe 的流水线调度优化，但作用于异构 stage（不同岛有不同计算特性）。Tangram 继承了这一成熟技术栈的所有优化成果。

未来研究方向

Tangram 的工作为几个有趣的后续方向打开了大门：

方向1：在线重规划与检查点结合

将 Tangram 的规划层扩展为带运行时监控的动态系统：检测到 GPU 降速或故障时触发增量重规划。DP 组合本身运行 < 1 秒，瓶颈在于对受影响的 (切片, 岛) 对重新调用并行化器。若能用学习型延迟预测器（如 PrimeTuner、Habitat 等）替换硬件 profiling，每次调用可从数十秒降到毫秒级，使重规划几乎无感知。

方向2：多目标优化

Tangram 目前只最大化训练吞吐量（在内存约束下）。可扩展为多目标优化：

最小化能耗（功率 × 时间），对数据中心运营商意义重大
最小化货币成本（不同 GPU 竞价实例价格不同）
同时满足训练截止时间 SLO 和成本约束

DP 框架天然支持 Pareto 前沿追踪，扩展并不困难。

方向3：迁移到推理服务场景

GPU 岛抽象同样适用于异构集群上的多模型推理服务。一个服务系统可以用类似 Tangram 的组合方式，把模型的不同层分配到不同类型的 GPU 上，用 PP 将请求流水线化。这把 DistServe、Llumnix 等”前缀/解码分离”工作自然推广到了异构硬件场景——未来的分布式推理系统可能会从 Tangram 的设计中受益。

方向4：与 MoE 路由的共同优化

在支持 EP 的 MoE 模型中，token 被路由到不同的专家（不同 GPU）处理。当前 Tangram 把专家路由当作岛内问题处理（岛内 AlltoAll）。理论上，如果允许跨岛专家路由，可以更灵活地利用算力强的岛处理”热门专家”（被更多 token 访问的专家）。这需要把 Tangram 的静态层切片扩展为动态专家切片，是一个尚未解决的开放问题。

可复现性说明

代码：摘要承诺在 [匿名 GitHub] 公开，截至 arXiv 提交时尚未开放。预计随论文去匿名化后发布。
测试模型：LLaMA 70B（架构见 §6.1）、Mixtral-8x22B（HuggingFace 可下载）、Qwen3-MoE（HuggingFace 可下载）。
硬件：苏黎世联邦理工 CSCS 的真实 A100+H100 集群；大规模结果用仿真补充（仿真参数已对真实硬件验证）。
基线代码：Alpa（alpa-projects/alpa）、Aceso（PKU-DAIR/Hetu）、Metis（uiuc-kang-lab）、Sailor（ETH-DISCO/sailor）均已开源。
可复现性评估：中等。核心算法（岛构建 + DP 组合）描述清晰，可以独立实现验证。完整复现需要异构 GPU 集群硬件，大规模仿真复现等代码开放后可行。

主要并行化器能力对比

为直观展示 Tangram 相比现有系统的特性完整性，下表列出了各系统对常见特性的支持情况：

系统	类型	TP	PP	DP	CP	EP	GA	RC	OF	ZeRO	GPU Placement
Alpa (2022)	同构	✓	✓	✓	✗	✓	✗	✗	✗	✗	不需要
Galvatron (2022)	同构	✓	✓	✓	✓	✗	✗	✓	✗	✓	不需要
Aceso (2024)	同构	✓	✓	✓	✗	✗	✗	逐算子	✗	✗	不需要
Metis (2024)	异构	✓	✓	✓	✗	✗	✗	✗	✗	✗	PP+DP
Sailor (2025)	异构	✓	✓	✓	✗	✗	✗	✗	✗	✗	PP+DP*
Tangram (2026)	异构	✓	✓	✓	✓	✓	✓	✓	✓	✓	PP（跨岛）

Tangram 通过”封装同构并行化器”的方式，继承了被封装器的所有特性。表中 Tangram 的特性范围取决于选择哪个同构并行化器作为内层：

封装 Galvatron → 获得 CP + ZeRO + MoE EP 支持
封装 Aceso → 获得逐算子 RC 支持
封装 Mist → 获得 OF + GA + ZeRO 支持

这种可组合性使 Tangram 不只是一个”今天的最优系统”，而是一个会随着同构并行化器的进步而自动升级的架构框架。

NVIDIA GPU 世代参数参考

GPU	架构	BF16 算力	HBM 容量	NVLink 带宽	发布时间
A100 SXM	Ampere	312 TFLOP/s	80 GB	600 GB/s	2020
H100 SXM	Hopper	989 TFLOP/s	80 GB	900 GB/s	2022
H100 NVL	Hopper	989 TFLOP/s	94 GB	900 GB/s	2023
H200 SXM	Hopper+HBM3e	1979 TFLOP/s	141 GB	900 GB/s	2024
B200 SXM	Blackwell	~4500 TFLOP/s	192 GB	1800 GB/s	2025

H100 SXM 与 H100 NVL 算力完全相同，仅 HBM 差 15%——Tangram 贪心合并后会作为一个岛（有效 HBM = 80 GB）。A100 vs. H100 算力差 3.2×，A100 vs. H200 算力差 6.3×。对极端异构情形（A100 + H200），均衡分配给 A100 的层数约占 14%，stage 过薄，实际收益有限。

总结

Tangram 解决的是一个在 ML 基础设施领域越来越真实的问题：异构 GPU 集群无处不在，但现有最好的自动并行化器要么无视异构性（导致次优 placement），要么处理异构性但砍掉关键特性（导致更差的计划）。

论文的核心贡献是一个干净的抽象：把”在异构集群上找最优并行化方案”的指数级问题，拆成”若干同构子问题 + 一次 $O(L^2 K)$ 的 DP 组合”。这使得 ZeRO-3、专家并行、逐算子激活重计算等关键特性可以在异构集群上继续发挥作用，而不是被迫砍掉。

2.3× 的吞吐量提升和 26× 的规划加速是令人信服的实验结果。MoE 模型上 1.8× 的提升展示了一个尤为重要的实用价值：随着 MoE 架构日益流行，能在异构集群上有效使用 EP 将是真实竞争优势。

主要不足在于容错性（生产环境的实际需求）、通信重叠建模精度（影响最优性），以及与 2026 年最新同类工作的直接对比（影响定位的可信度）。但作为一个把同构并行化器升级为”异构集群可用”的通用封装层，Tangram 为分布式 LLM 训练系统栈填补了一个重要的空白。

论文标题 “Hiding GPU Heterogeneity”（隐藏 GPU 异构性）精确地表达了设计哲学：不是把 GPU 异构性暴露为一个与并行化联合求解的复杂问题，而是把它隐藏起来——内层并行化器永远看不到异构性，外层 DP 通过流水线组合干净地处理异构性，用户看到的是一个在混代集群上直接可用的系统。“在抽象背后隐藏复杂性”是优秀系统设计的核心原则，Tangram 在这方面做得相当漂亮。这种可组合性设计也意味着，未来每一个同构并行化器的改进（更好的搜索算法、新的并行维度支持）都会自动惠及 Tangram 用户，无需修改 Tangram 本身。

深入理解：端到端规划示例

为了让算法更具体，下面逐步追踪 Tangram 为 70B LLaMA 模型在一个”64 块 H100 SXM + 128 块 A100”异构集群上生成计划的全流程。

第一步：GPU 岛构建

算力差异： $|989 - 312| / 989 = 68\%$ ，超过阈值 $\tau_C = 20\%$ 。
结果：两个岛， $I_0$ = {64 块 H100 SXM}， $I_1$ = {128 块 A100}。算力差异过大，无法贪心合并。

第二步：均衡层数估计

$I_0$ 总算力： $64 \times 989 = 63,296$ TFLOP/s
$I_1$ 总算力： $128 \times 312 = 39,936$ TFLOP/s
$I_0$ 的算力占比： $63296 / (63296 + 39936) = 61.3\%$
均衡层数： $|S_0|^* = 80 \times 0.613 = 49.0$ 层； $|S_1|^* = 31.0$ 层
允许偏差（ $\beta=2$ ）： $I_0$ 接受 25-80 层， $I_1$ 接受 16-62 层

第三步：剪枝后枚举

规则1（去重）后，唯一层数共 80 个。规则2（均衡检查）要求： $|S_0| + |S_1| = 80$ ，且 $|S_0| \in [25, 64]$ （否则 $|S_1| = 80 - |S_0|$ 不在 $[16, 62]$ 内），有效对数为 40 个。经规则3、4进一步过滤，约剩 35 个有效对（相比不剪枝的 $80^2/2 = 3200$ 对，减少约 91 倍）。

第四步：DP 组合

对 35 个有效 (切片, 岛) 对，并行化器返回各自的延迟估计 $\tau(p)$ 。DP 找到最小化 $|\tau_0 - \tau_1|$ 的分割点：约在 $I_0$ 分 48 层、 $I_1$ 分 32 层处——非常接近均衡估计（49/31）。

最终结果：两阶段流水线，气泡比例约 5%，每个 stage 内部完整支持 TP + ZeRO + RC，在该集群上比 Aceso 吞吐量高约 2.1 倍。

为什么异构集群问题会越来越重要

值得从更宏观的视角理解 Tangram 解决的问题为何在未来会变得更加普遍，而非更罕见。

资本支出摊销：2022 年以每块 $10,000 购入的 A100 节点，在大规模集群中代表数亿美元的投资。在 5-7 年的使用寿命到期前就彻底退役，在财务上无法接受。这意味着组织将在相当长的时间内同时运行 A100/H100/H200 的混合集群。

GPU 供应约束：在 2025-2026 年，H200 和 Blackwell GPU 的需求远超供应量。需要扩展算力的组织无法简单替换整个集群，只能在现有设施上加装新节点，形成异构集群。

竞价实例市场：云服务商（AWS、GCP、Azure）的竞价实例以显著折扣提供 GPU，但不同实例类型的可用性差异很大。能够利用多种 GPU 类型的训练作业拥有更大的可用算力池，可以降低成本和等待时间。

学术集群的历史积累：大学 HPC 集群往往通过多年的项目资助和捐赠分阶段建设，天然形成异构配置。在这类集群上训练大模型的研究团队别无选择，必须与现有硬件协作。

这些趋势表明，Tangram 解决的不是一个即将消失的边缘案例，而是随着 LLM 训练规模增长而日益重要的工程问题。

实现注意事项

跨岛数据并行的梯度同步

Tangram 的组合流水线中，每个 stage 可以独立选择 DP 度（数据并行副本数）。但为了确保每个 DP 副本包含完整的模型（而非只有一部分层），所有 stage 的 DP 度必须一致。即若 $K$ 个 stage 总共使用 $G_{\text{total}}$ 块 GPU，且每个 stage 用 $g_k$ 块 GPU，则 DP 度 = $\text{gcd}$ 或最小公倍数约束下的统一值。这是标准流水线并行的要求，不引入额外复杂性。

激活重计算与流水线深度的交互

在 Megatron 的 1F1B 调度中，一个 stage 需要同时保留”所有当前在流水线中未完成的微批次”的激活值。对 $n_{\text{stages}}$ 个 stage，每个 stage 同时保留最多 $n_{\text{stages}}$ 个微批次的激活。Tangram 的内存可行性检查（规则3，公式 4）使用简化模型，未考虑这一对流水线深度 $K$ 的依赖。对较浅的流水线（ $K=2$ 或 $K=3$ ，论文的实验设置），误差很小；对较深流水线（ $K \geq 5$ ），实际激活内存可能超过预测值，在运行时触发 OOM。

缓存局部计划以加速重规划

初始规划后，所有 (切片, 岛) 对的局部计划可以缓存到磁盘。当集群拓扑不变但需要重新规划时（例如更换了模型），大部分局部计划可以直接复用。只有涉及新模型层结构的切片需要重新调用并行化器。DP 组合本身运行时间 < 1 秒，整个重规划可以在几分钟内完成，而非数小时。这是 Tangram 在生产环境中的一个重要操作优势，但论文没有充分强调。

Tangram 失效场景分析

理解 Tangram 在哪些情况下会失效，与理解它在哪里成功同样重要。以下四个具体失效场景：

场景1：极端算力差异（如 A10 + H100）

A10 GPU 约 125 TFLOP/s BF16，H100 约 989 TFLOP/s——差距约 7.9 倍。Tangram 构建两个岛后，均衡层数分配会给 Island_A10 分配约 11% 的层（80 层模型中约 9 层）。9 层的模型切片几乎没有有效的并行化空间，而且整个流水线的吞吐量受 A10 stage 严重拖累。在此极端情况下，直接排除 A10 集群、只用 H100 集群可能比使用 Tangram 更高效——Tangram 对极端异构比没有明显帮助。

场景2：模型架构层间不一致

若模型的 embedding 层维度（如 16,384）与 Transformer 层维度（如 4,096）不同，则 embedding 层和 Transformer 层的激活形状不同，无法统一切片。Tangram 当前实现要求所有可切片层的输入/输出形状完全一致，对于”宽窄结构”或编码器-解码器架构存在根本限制。

场景3：模型相对集群过小

对 7B 模型和 512 GPU，模型参数量小，主导策略是数据并行（大批次）而非模型并行。流水线并行此时气泡比例高（micro-batch 数量不足以摊销填充排空开销）。Tangram 的 DP 会退化为 $K=1$ （整个集群作为一个 stage），等价于普通的同构规划。若训练只跑几百步（微调），规划开销（数十分钟到数小时）本身可能超过训练时间，使用 Tangram 得不偿失。

场景4：岛内 GPU 热节流（Thermal Throttling）

同批次 GPU 因散热条件不同，实际运行频率可能相差 5-10%（GPU Boost Clock）。Tangram 用最弱 GPU 的参数规划整个岛，若最强 GPU 比最弱快 10%，实际吞吐可能比预测低 10%，且不同运行时刻结果不稳定。这不会导致崩溃，但会使吞吐量与预测出现系统性偏差。

关键公式汇总

公式编号	含义	表达式
(1)	单 GPU 内存需求	$M_{\text{device}} = M_{\text{params}} + M_{\text{optimizer}} + M_{\text{grad}} + M_{\text{activations}}$
(2)	层切片接口一致性	$\text{Plan}(S_{a:b}, I_k) = \text{Plan}(S_{a':b'}, I_k)$ 当 $b-a = b'-a'$
(3)	均衡层数估计	$
(4)	内存可行性约束	$(b-a) \cdot M_{\text{layer}} / (
(5)	流水线周期时间	$T_{\text{cycle}} = (n_{\text{micro}}-1) \cdot \tau_{\max} + \sum_k \tau_k$
(6)	训练吞吐量	$\text{Throughput} = B_{\text{global}} / T_{\text{cycle}}$
(7)	气泡比例	$\text{BubbleRatio} = 1 - n_{\text{micro}} \cdot \bar{\tau} / T_{\text{cycle}}$
(8)	DP 递推	$f[l][k] = \max_{l'} \text{UpdateThroughput}(f[l'][k-1], \tau(p_{l':l,k}))$
(9)	通信重叠修正（改进建议）	$T^{\text{overlap}} = (n-1)\tau_{\max} + \sum_k \max(\tau_k^{\text{compute}}, \tau_k^{\text{comm}})$
(10)	最优微批次数（改进建议）	$n^* = \arg\max_n B_{\text{global}} / [(n-1)\tau_{\max} + \sum_k \tau_k]$

笔记作者总结评价

Tangram 的贡献可以用三个词概括：隔离（Island 让异构性局部化）、复用（内层同构并行化器零修改接入）、高效（四条剪枝规则 + O(L²K) DP 保持可扩展性）。

从工程角度看，它最大的优点是可维护性——未来并行化器的改进不需要 Tangram 更新，用户只需换内层实现即可。这类”稳定接口后的可替换实现”设计在大型分布式系统中极为宝贵。

最大的开放问题是容错性：在异构集群中，某类 GPU 故障率可能不同，容错策略（checkpoint 频率、部分重启、弹性扩缩容）需要和 Island 分配协同设计，而当前 Tangram 框架尚未覆盖这一点。对于真实生产环境的工程师，这是部署前必须单独解决的问题。

若读者希望深入研究，建议从三条线索切入：① 阅读 Alpa（PPoPP’22）理解 inter/intra-op 并行搜索基础；② 阅读 Aceso（EuroSys’24）理解通信感知的异步并行化；③ 阅读本文（arXiv:2606.16907）理解如何在二者之上加 Island + DP 层处理异构性。三篇合起来构成 2022–2026 年自动 LLM 并行化器演化的完整脉络。

笔记作者：Zhongzhu Zhou — 2026-07-02