引言：当一条链路断了，整个 All-to-All 就停了
想象一下这个场景。你在一个 4x4x4 的 TPUv4 Pod 上跑着 MoE 训练，1024 个 TPU 芯片通过 3D Torus 互联在一起。All-to-All 正在执行——每个芯片向其他所有芯片分发 token 的 hidden state，同时从其他所有芯片接收计算结果。这一个操作占了端到端训练时间的 41.5% 到 95.7%——它本身就是训练流水线上最长的那根钉子。
然后一条链路断了。
不是芯片坏了，只是一根连接两个相邻芯片的物理链路出了问题。可能是光电路交换机（OCS）上某个端口老化，可能是散热不均匀导致的热胀冷缩让连接器松了，也可能什么都不为——在包含 48 个 OCS、数万条内部链路的 TPUv4 集群上，海量定律决定了故障不是例外而是常态。Google 的 TPUv4 运维经验表明，集群需要配备专门的 healthd 守护进程持续监控链路状态，Borg 集群管理系统在收到故障通知后触发从上一个 checkpoint 的重启，并将受影响芯片的 ICI 路由表从无故障模式切换到容错模式。而这一切都是在训练过程中发生的——没有硬件替换，没有人工干预。
问题是：即使路由切换了，原来的 All-to-All 算法还能工作吗？
答案是：能工作，但会严重降级。因为在 All-to-All 中，每个节点都向所有其他节点发送数据，且通过多跳传输（multi-hop）到达目的地。一条链路的故障不只影响直接相连的两个节点——它影响所有需要经过这条链路进行多跳转发的节点对。如果 Ring 算法（最常用的 Torus 单维 All-to-All 算法）中某个方向的数据传输路径被截断，整个环上的通信都会失常。
更糟糕的是，如果你不做特殊处理，只靠 TPUv4 的 wild-first routing（WFR，容错路由方案）来绕过故障区域，那也只是保住了基本连通性——性能上会引入新的拥塞热点和不均衡。Google 自己的评估显示，WFR 在故障场景下的 All-to-All 带宽勉强维持——与无故障性能相差无几只是因为混合基数 Torus 的瓶颈维度本身就不在故障维度上，而不是因为 WFR 设计得好。
一句话：在 Torus 上做 All-to-All，链路故障是必然事件。如何在故障发生后、不改变拓扑的前提下，保持 All-to-All 的通信效率？这就是 MICRO 2025 上由港科广和华为联合发表的这篇论文要解决的问题。
系统剖析：HalfRing、DimRotation、FoldedRing、MATE
要理解这篇论文的方案，需要先理解 All-to-All 在 Torus 上的通信分解方式。
在 N 维 Torus 网络上，All-to-All 被分解为 N 个阶段（phase），每个阶段沿一个维度进行单维 All-to-All 通信。例如在 3D Torus 上，数据先在 X 维度上交换，然后在 Y 维度上交换，最后在 Z 维度上交换。每个维度内的通信通过单维算法（如 Ring 或本文提出的 HalfRing）完成。因此优化空间有两个维度：单维算法（每个 phase 内部怎么传）和跨维调度（各个 phase 之间怎么组织）。
HalfRing：带宽-延迟双最优的单维算法
先看最精简的情况：一个环（ring）上的 All-to-All。经典的 Ring 算法是这样工作的：
数据被分成 (N-1) 个阶段，每个阶段对应不同的跳跃距离（hop distance）。在双向带宽网络中，每个节点同时沿顺时针和逆时针方向发送数据。以 4 节点环为例，共有 3 个 stage：1-hop、2-hop、3-hop。在 3-hop stage 中，节点 1 到节点 4 的数据顺时针方向需经过节点 2、节点 3 才能到达节点 4（3 跳），而逆时针方向 1 跳就到。
这就是 Ring 算法的核心问题：非最短路径转发消耗了额外的链路带宽。顺时针数据要传 3 跳，逆时针只需 1 跳——两个方向的工作量不对称，但都占满了对应方向的链路。在 stage 3 这个时间窗口中，顺时针方向的三条链路都在忙，但逆时针方向只有一条链路在忙。浪费了 2/3 的可用链路时间。
HalfRing 用一个简单但聪明的改动解决了这个问题：每个 stage 只沿最短路径方向传输，让相反方向的链路被另一个 stage 对等使用。
具体怎么操作？在 HalfRing 中，数据按跳数配对：(1-hop, (N-1)-hop) 配成一组，(2-hop, (N-2)-hop) 配成一组，以此类推。因为 (N-1)-hop 在环上等于 1-hop 的相反方向——比如从节点 1 到节点 4，顺时针 3-hop 等于逆时针 1-hop。HalfRing 就让它走逆时针，与真正的 1-hop 通信（走顺时针）同时进行。两个 stage 各用一个方向，互不冲突，完全并行。
以 4 节点环为例。Ring 需要 6 个子阶段（sub-stage）：3 个 stage，每个 1 到 3 跳。HalfRing 只需要 4 个子阶段：stage 1（1-hop 和 3-hop 配成一对，两个方向同时传），2 个子阶段完成；stage 2（2-hop），2 个子阶段完成。总 sub-stage 数从 6 减到 4，延时直接缩短 33%。
对于奇数节点的环（N=2k+1），HalfRing 将 2k 个 stage 配成 k 对，每对并行执行。对于偶数节点的环（N=2k），有 2k-1 个 stage，多出一个不成对的 stage——HalfRing 将这一 stage 的数据均匀分到两个方向传输，充分用满双向带宽。
论文用线性开销模型给出了精确的分析。定义 S 为每个节点的数据量，N 为环节点数，B 为单向带宽，alpha 为每跳传播延迟：
Ring 算法的传输时间：alpha x (N-1)/2 x S/(2B)。总共有 N(N-1)/2 个单向单跳传输，每个传输数据量为 S/N，除以双向带宽 2B。
对于偶数 N，HalfRing 的传输时间：alpha x N/8 x S/B。对于奇数 N：alpha x (N^2-1)/(8N) x S/B。
带宽加速比（相比 Ring）：偶数 N 为 2x，奇数 N 为 1.5x-2x。 加上延迟加速比（因为 sub-stage 数减少），整体的速度提升在论文的实验中体现为平均 1.56x。
为什么 HalfRing 能保证无死锁、无活锁、无网络争用？因为它和 Ring 一样，把所有多跳传输分解为邻居间的单跳传输，通过显式的 hop-by-hop store-and-forward 调度来精确控制每个时刻每条链路的使用。没有多跳传输（无死锁条件），没有绕路（无活锁条件），没有链路共享（无网络争用条件）。
DimRotation：消泡调度，3D 下 2.28x 的密码
单维算法优化完了，轮到跨维调度。在 3D Torus 上，All-to-All 有三个 phase：X 维、Y 维、Z 维，顺序执行。如果数据不分块，三个 phase 串行，每个 phase 只利用了该维度的链路，其他两个维度的链路空闲——整体链路利用率只有 1/3。
Pipeline 调度（Themis, ISCA’22 的方案）把数据切成多个 chunk，让不同 chunk 在不同维度上同时通信。在 X 维 phase 完成 chunk 1 后，chunk 1 进入 Y 维，同时 chunk 2 开始 X 维——形成流水线。Pipeline 的困境在哪里？看一个 3D Torus 的例子，所有 chunk 都按 X-Y-Z 顺序执行：
Chunk 1: X 开始 -> Y 开始 -> Z 开始 Chunk 2: 等待 X -> X 开始 -> Y 开始 -> Z 开始 Chunk 3: 等待 X -> 等待 X -> X 开始 -> Y 开始 -> Z 开始
在时间线的开头和结尾，必然会出现”气泡”——某些维度的链路在等待但无数据可传。更麻烦的是 chunk 大小的选择：chunk 太大，流水线不够深，重叠不充分；chunk 太小，chunk 数量激增，调度开销和通信初始化延迟成为新的瓶颈。
DimRotation 的洞察直接而优雅：不要让所有 chunk 走同样的维度顺序。 对于一个 N 维 Torus，数据被均匀分成 N 个 chunk，第 i 个 chunk 的遍历顺序是：从维度 i 开始，依次遍历到维度 i+（N-1）。可以理解为一个”旋转”的维度编号。在 3D 情况下：
- Chunk 1: X -> Y -> Z
- Chunk 2: Y -> Z -> X
- Chunk 3: Z -> X -> Y
在任意时刻，三个 chunk 分别在不同维度上通信。没有气泡——因为每个 chunk 从各自的第一个维度开始后，就一直在”滚动”，没有空闲的维度等着下一个 chunk 进场。DimRotation 的 chunk 数量就是维度数量 N，而不是 Pipeline 中需要权衡的任意数字——这是最小可行的 chunk 数，调度开销最低。
实验结果验证了理论的优雅：DimRotation 单独带来 1.45x 加速比（相比 Ring+Pipeline 基线）。与 HalfRing 组合后，平均加速比 2.28x——这种乘法效应是因为 HalfRing 在单维上缩短了通信时间，DimRotation 在多维上实现了完美的带宽重叠。
FoldedRing：当一条链路断了，环折叠起来
现在进入容错部分。单维环上的一条链路故障意味着什么？
以 4 节点环为例，假设节点 1 和节点 4 之间的链路断了。原本 Ring 算法在逆时针方向可以通过这条链路进行 1-hop 传输（节点 4 到节点 1）。现在这条路没了——节点 4 的逆时针方向上第一个邻居就是空的。
FoldedRing 的解法非常简单——从拓扑上看甚至有点粗暴：用所有剩余的逆时针链路拼出一条从节点 4 到节点 1 的逻辑路径。 具体来说，原本从节点 4 到节点 1 是直接的 1-hop 逆时针链路。现在链路段了，就改为：节点 4 -> 节点 3 -> 节点 2 -> 节点 1，走 3-hop 的顺时针路径（或等价地说，用三条物理上的”反方向链路”拼出一个逻辑直连）。
更精确地描述：故障链路切断后，剩下的顺时针链路（没有经过故障点的那些）和”借用”的逆时针链路一起，构成了一条逻辑上的折叠环（folded ring）。在这个折叠环上，节点 4 到节点 1 的逻辑连接需要经过节点 3 和节点 2——原本的 1-hop 现在变成了 3-hop 的 store-and-forward 传输。
性能代价是精确可预测的。在 FoldedRing 中，原本阶段内只需要一次单跳完成的数据传输，现在需要 N-1 跳（因为绕过了故障链路，走了整个环的”背面”）。传输时间翻倍到大约 Ring 算法的一半带宽。论文中的分析表格给出了精确的公式：FoldedRing 的传输时间是 (N-1) x (N-1)/(2B) x S，而 Ring 是 alpha x (N-1)/2 x S/(2B)——FoldedRing 的带宽约为 Ring 的 0.5 倍。
但关键是——通信继续进行。 没有 check-pointing 回滚，没有硬件替换，没有训练中断。链路故障没有导致 All-to-All 彻底失败，只是让速度变慢。这是一个可操作的、可预测的性能降级，而不是一个灾难性的失败。
实验数据也证实了这一点：FoldedRing + Pipeline 的平均性能是 Ring + Pipeline（无故障）基线的 0.55 倍，FoldedRing + DimRotation 是 0.67 倍。降级确实存在，但通信没有中断。
值得一提的是，FoldedRing 是一个通用的容错 ring 算法——不仅适用于 All-to-All，也适用于 All-Reduce、Reduce-Scatter、All-Gather 等在 ring 上的集体通信。论文在评估中为确保 All-Reduce 在故障条件下的可靠执行，采用了 FoldedRing + MATEe 方案。
MATE：借其他维度的链路，比没有故障时还快
FoldedRing 解决了”能不能传”的问题，但留下了”传得慢”的问题。在 DimRotation 调度中，慢传输的故障环会拖慢整个 TimeLine——其他维度的通信必须等待故障环上的数据完成，因为 All-to-All 的各个 phase 之间有数据依赖。
MATE（Multi-dimensional Acceleration for Torus with Error）的洞察有违直觉——也许违背了所有关于故障的朴素信念：在故障的情况下，性能可以比无故障的 Ring 基线更好。
如何做到？MATE 的核心思想是”跨界借力”。在 N 维 Torus 中，每个维度都有多个并行的环。例如在 3D Torus 中，Z 维度有 X×Y 个并行的环。当 X 维度的某个环出现链路故障时（记为 faulty ring），同一维度的其他 fault-free ring 仍然在正常工作。MATE 利用 Y 维（或其他维度）的链路，将故障环上的节点连接到健康环上，然后将故障环上的一部分数据传输卸载到健康环上并行执行。
具体来说，以 2D Torus 上一行节点 (0,1)-(1,1)-(2,1) 之间的链路故障为例。正常 phase 中，故障环上的数据传输使用 FoldedRing 慢速进行。然后 MATE 引入一个加速 phase（acceleration phase）：利用 Y 维的链路，将故障环上的节点 (0,1) 连接到健康环 (0,2)-(1,2)-(2,2) 和 (0,0)-(1,0)-(2,0) 上的对应节点。例如，(0,1)-(0,2)-(1,2)-(1,1) 形成一条从 (0,1) 到 (1,1) 的逻辑连接——完全由 Y 维和健康 X 维环的链路组成。同理构建反向连接。
在这些逻辑连接上，剩余的数据可以用高效的 HalfRing 算法进行传输——因为这些逻辑连接本身是 contention-free 的（Torus 正交性保证了不同平面上的链路互不干扰）。对于 N 维 Torus，MATE 可以利用 N-1 个健康平面为故障环构建加速路径。加速 phase 结束后，数据已经到达目的地，所有维度恢复正常。
MATEe（MATE enhanced） 进一步优化了加速 phase 的数据量。MATE 在正常 phase 中完全不在故障环上传输数据——所有故障环的数据都在加速 phase 中完成。但问题是：故障环本身还有一些可用的链路（partial ring 只丢了一条链路），完全浪费它们是一种浪费。MATEe 在正常 phase 中通过 FoldedRing 在故障环上传输一部分数据（基于 HalfRing 和 FoldedRing 的性能比例静态分配），减少加速 phase 的通信量，让整体调度更均衡。
实验结果印证了这个”反直觉”的论断。在单链路故障场景下，MATE 平均加速比 1.36x，MATEe 平均加速比 1.37x——两者都超过了无故障的 Ring+Pipeline 基线。这意味着在故障条件下，MATE 方案不仅保住了通信，而且让通信比无故障的 baseline 还快。
为什么？因为 baseline 是 Ring 算法，本身就性能一般。MATE 通过多维度加速，利用了比单一 ring 更多的链路资源——这就是横向借力的威力。当网络维度越高，可借用的链路越多，加速效果越显著。
关键技术决策：容错 All-to-All 中的设计取舍
决策一：单维故障单维处理 vs 全局重路由
工程上面对链路故障的第一直觉往往是：让路由层自己处理——切换路由表，绕开故障链路，继续通信。这就是 Google TPUv4 的 Wild-First Routing（WFR）做的：在故障维度前先走一跳其他维度（如 yXYZ 绕开 X 维故障），再按正常顺序路由。
但论文选择了另一条路：不改变拓扑路由，而是改变通信算法和调度。 这样做有几个理由。
第一，硬件路由是面向通用点对点通信的，不感知集体通信的模式。在 All-to-All 中，每个节点向所有其他节点发送数据——这是一种特殊的流量模式，而不是随机的一对一传输。通用路由在局部最优（某条链路在某一时刻不拥塞）但全局不一定好——整个 All-to-All 的耗取决于最慢的那一跳。WFR 在绕过故障区域时，会在故障点附近的某些维度引入额外的流量集中，形成新的热点，这就是论文实验 WFR 性能在不同故障维度上差异很大的原因。
第二，集体通信有严格的同步要求。所有参与节点必须在同一个逻辑步骤上对齐——某些节点到达快、某些节点到达慢没问题，但必须等所有人完成后才能进入下一阶段。通用路由无法利用这个同步结构做全局优化——它只能逐个包做局部决策。而论文的 hop-by-hop store-and-forward 调度精确控制每个时刻每条链路的分配，可以在 All-to-All 的全局范围内消竞争。
第三，也是最重要的：可以做得比无故障时更好。 如果只是绕开故障点，最好的结果就是性能不打折——恢复无故障水平。但 MATE 的思路是：故障是一个信号，告诉我们这条 ring 上的链路不够用了。既然不够用，那我们借用其他维度的链路来补充——最终结果是通过多维度的链路聚合超过了无故障的基线。这不是容错，而是”故障触发的优化”。WFR 做不到这一点，因为它只是换了路由路径，没有增加总可用带宽。
决策二：静态分配 vs 动态负载均衡
MATEe 采用了基于 HalfRing 和 FoldedRing 算法性能比的静态数据分配——故障环在正常 phase 中传输的比例是固定的（fraction 参数）。论文中明确承认，这种静态分配”不能保证故障维和其他维之间的完美同步”，因此在正常 phase 中会有临时的利用率下降。
为什么不使用动态分配？论文没有直接回答这个问题，但从系统设计可以推断出几个原因。第一，All-to-All 是确定性的集体通信——通信量和模式在训练启动时就已知。动态调整需要在运行时重新分配数据块，引入额外的控制面和同步开销。第二，在 Hop-by-hop store-and-forward 调度中，所有节点的发送-转发-接收序列是预先计算的（offline precomputed）。动态调整意味着在线重新生成调度表——这在数千节点的集群上是不小的 CPU 开销。第三，实验表明静态分配的性能已经很接近最优——MATEe 相对 MATE 在大数据量下获益更多（因为传输时间远大于启动延迟），在小数据量下 MATE 更好（因为 MATEe 的故障环在正常 phase 中的慢速 FoldedRing 通信引入了更多的同步开销）。
这是一个务实的工程选择：一个接近最优的静态方案，远好于一个理论上最优但运行时开销巨大的动态方案。
决策三：加速 phase 的数量与分配
MATE 为每个正常 phase 后增加一个加速 phase（在 N 维 Torus 上共 2N 个 phase，而不是 N 个）。这是调度复杂度的代价——从 N 个 phase 翻倍到 2N 个 phase。加速 phase 把故障环的数据通过健康平面的 HalfRing 传输出去。这里有一个隐含的假设：加速 phase 使用健康平面的一部分链路，但不影响这些健康平面上正常的 All-to-All 数据流。
这是如何保证的？因为加速 phase 和正常 phase 是交替执行的，不是同时执行。在正常 phase 中，健康平面执行各自的 HalfRing 通信——故障环上的 FoldedRing 是其中的一个慢速成员。在加速 phase 中，健康平面的通信暂停，故障环借用它们的链路来加速传输。两者不共享时间窗口，因此没有链路冲突。
但如果多个环同时出故障呢？论文在 Type 1（同一环上两个故障）、Type 2（不同环、同一维度）、Type 3（不同维度各一个故障）三种场景下做了评估。Type 1 最简单——FoldRing 无法处理同一环上的两个故障，但 MATE 直接通过加速 phase 完全绕过了故障环，平均加速比 1.43x 比 WFR。Type 2 和 Type 3 需要多个加速 phase 或并发加速 phase——如果故障在同一个维度但不共享平面，可以同时加速；如果在不同维度，MATE 为每个故障分配单独的加速 phase。在 OCS 故障场景（图 4b 中由单个 OCS 故障导致的两条链路同时失效），MATE 的时间开销与单链路故障一致——因为 OCS 故障导致的链路故障在拓扑上是”对齐的”，加速 phase 可以并行覆盖。
决策四：FoldedRing 的泛化能力
FoldedRing 是一个基础构件（primitive），而非专用于 All-to-All。论文明确指出它在 All-Reduce、Reduce-Scatter、All-Gather 上也适用。这个设计选择的深度在于：容错不是 All-to-All 独有的需求。 在训练中，All-Reduce（权重梯度同步）和 All-Gather（数据分发）同样会遭遇链路故障。如果每个 collective 都需要独立设计容错方案，维护和验证的成本会随算法种类线性增长。提供一个通用的 ring 容错构件，然后在不同的 collective 中组合使用——这是更可扩展的工程路径。
实验中的 All-Reduce 就采用了 FoldedRing + MATEe 方案。论文没有展开 All-Reduce 的详细容错设计，但指出这种”通用故障算法 primitive + 专用调度”的分层方法是可行的。
横向对比：NVSwitch 方式 vs TPU 默认路由 vs 本方案
Google TPUv4 的默认方案
TPUv4 集群的 ICI（Inter-Chip Interconnect）在无故障时使用 XYZ 维度序路由（Dimension-Order Routing, DOR）：数据先沿 X 维走，再沿 Y 维走，再沿 Z 维走。DOR 保证了无死锁且路径短，但在 All-to-All 中存在两个固有问题。
第一，维度间负载不均衡。在 X-Y-Z 的固定顺序下，X 维链路在 All-to-All 起始阶段被高频使用（所有数据都先走 X 维），而 Z 维链路在最后阶段才被密集使用。在起始阶段，X 维满负荷而 Y 维和 Z 维空闲——整体链路利用率受限。
第二，多跳传输的竞争。DOR 依赖硬件路由来执行每个多跳的端到端传输。当多个传输共享同一段路径时，硬件路由只能在包级别（或 flit 级别）做 local arbitration——它不知道整个 collective 的全貌，只知道”当前这一拍有多少请求在争这一条链路”。这在高负载下产生背压和排队延迟。
在故障场景下，TPUv4 切换到 Wild-First Routing（WFR）。WFR 在到达故障维度之前先走一跳”野路由”（wild hop）到相邻维度，绕过故障区域。例如 X 维故障时，使用 yXYZ——先 Y 维一跳，再按 X-Y-Z 顺序。论文的实现结果耐人寻味：WFR 在单 pod（4x4x4）中，不同故障维度下的性能有显著差异。这是 sandwich law 的副作用——prefix 跳在哪个维度取决于故障在哪一维，而不同维度作为 prefix 的链路争用程度不同。
论文的实验数据：在 4x4x4 TPUv4 Pod 上，HalfRing + DimRotation 在无故障条件下相比 DOR 平均加速 1.57x。在故障条件下，MATE 和 MATEe 相比 WFR 平均加速 1.26x 和 1.24x，在高带宽饱和区分别达到 1.46x 和 1.61x。
在双 Pod（8x4x4）混合基数 Torus 上，瓶颈维度（拥有 8 个节点的 X 维）主导了整体 All-to-All 时间。这种情况下，单一链路故障（如果不在瓶颈维度）对整体性能的影响被瓶颈掩盖——WFR 的性能在故障条件下达到了无故障的 98.8%。但论文的 HalfRing + DimRotation 在无故障时仍有 1.57x 加速比，MATE 和 MATEe 在故障条件下分别带来 1.18x 和 1.19x 加速比（相比 WFR-F1），饱和加速比分别是 1.25x 和 1.42x。
NVSwitch 世界的对比
NVSwitch（以及类似的 switch-based 拓扑，如 InfiniBand 的 Fat-Tree）和 Torus 在 All-to-All 这个问题上的差异，是理解论文价值的另一个维度。
NVSwitch 是全对全交换（Full Crossbar），任意两个 GPU 之间只有一跳——路由就是”从源端口走到目标端口”，没有任何中间节点。All-to-All 在这种拓扑上的瓶颈不在路径选择而在端口带宽分配——多少个 GPU 同时向同一个目标 GPU 发送数据时会有 incast 冲突。路由算法（如 Bruck 算法）主要负责均衡发送-接收的匹配顺序，不需要考虑中间链路的使用。
Torus 完全不同。两个不相邻的节点通信需要多跳——经过中间节点转发。路径选择本身就是优化目标：不同的路径分配会造成不同链路不同程度的争用。在 Torus 上没有”直连所有节点”的奢侈——你必须在链路使用的约束下设计数据流动的全网规划。
这就是为什么论文的 hop-by-hop store-and-forward 方法如此重要：它把”哪个包在哪一拍走哪条路”精确到了每一跳——而 NVSwitch 世界不需要这一层精度，因为总共只有一跳。
论文的结论在 switch-based 世界是翻译不过去的——Torus 网特有的问题需要 Torus 特化的解法。但这不意味着论文的工作影响面窄：TPUv4（Google）、Fugaku（RIKEN）、Trainium（Amazon）、IPU-POD（Graphcore）、AI Pod（Enflame）都采用了 Torus 或 Mesh 互联——这覆盖了相当大一部分 AI 训练基础设施。
总结与清单：容错 All-to-All 的关键认知
核心认知提炼：
-
All-to-All 是 blocker，不是 overlay。 在 MoE/DLRM 训练中，All-to-All 占据 41.5%-95.7% 的通信时间。它是阻塞操作（blocking），不能被计算隐藏。任何对 All-to-All 的优化都是对整体训练时间的等比例压缩。
-
链路故障在 Torus 上是常态。 大规模集群的热胀冷缩、OCS 老化、端口故障——概率随规模累积。需要的是通信级别的容错，而非每次故障都回滚 checkpoint。
-
HalfRing 是正确答案。 在 Torus 单维环上做 All-to-All，最短路径 + 双向带宽同时用满 = 带宽和延迟的双重最优。简单算法，确定性强，无死锁/活锁/争用。
-
DimRotation 消灭气泡。 让每个 chunk 从不同维度开始，N 个 chunk 完美覆盖 N 个维度——没有 Pipeline 调 chunk 大小的烦恼，调度开销最低。
-
FoldedRing 是保底，MATE 是超车。 故障条件下，先不让通信中断（FoldedRing），再借力打力让性能反倒超过无故障基线（MATE）。MATE 的 1.37x vs 无故障 Ring 基线是最直接的数字证明。
-
Paper 的实验结论：HalfRing + DimRotation = 2.28x（无故障），MATEe = 1.37x（单链路故障 vs 无故障 Ring），vs Google DOR = 1.57x（无故障）/ 1.61x（故障）。
自查清单（如果你在做 Torus 上的 All-to-All 通信）：
- 你当前的基线是 Ring + Pipeline 吗？如果是，HalfRing + DimRotation 可以直接给你 2.28x。
- 你的系统能感知链路故障吗（如 healthd）？如果不能，故障检测是容错的前置条件。
- 你的 All-to-All 调度是中央定制的还是依赖硬件路由的？依赖硬件路由意味着 DOR/WFR 的性能天花板。
- 故障发生后，你是回滚 checkpoint 重建拓扑，还是在线切换算法和调度？前者中断训练数分钟到数小时，后者不停训练。
- 你的 Torus 是固定基数还是混合基数（如 8x4x4）？瓶颈维度决定整体性能上界，确定容错的优化重点。
- 你的网络中有多个可能的故障类型吗（单链路、OCS 导致的周期链路故障、同维度多故障）？MATE 对多重故障有明确的扩展路径，但需要评估加速 phase 的并发容量。
