1. 项目概述在当今大规模AI训练集群中资源调度正面临一个日益严峻的挑战如何将形态各异的分布式机器学习作业高效、无冲突地“塞进”一个固定的硬件拓扑里。这听起来像是一个高级版的“俄罗斯方块”游戏但赌注是数百万美元的计算资源和宝贵的研究时间。传统的调度策略无论是追求空间连续性的“首次适应”算法还是追求高利用率的“尽力而为”分散放置都像是在走钢丝——要么牺牲利用率导致资源闲置要么引入网络争用拖慢所有作业。问题的根源在于一个根本性的错配作业的“形状”是刚性的而集群的“容器”是静态的。一个需要4x8x2张量处理单元XPU的作业在一个16x16x16的静态环面集群中可能因为找不到一个连续的、符合该形状的空闲区域而无法启动尽管总的空闲XPU数量是足够的。这种因形状约束导致的“资源碎片化”在大规模、多租户场景下尤为致命。近期卡内基梅隆大学和哈佛大学的研究团队提出了一种名为RFold的协同适配方案。它不再将作业形状和集群拓扑视为不可调和的矛盾双方而是通过两项关键技术让双方都“动起来”以寻求最优匹配一是作业形状折叠即在不影响作业通信语义的前提下寻找其拓扑同构的其他形状二是拓扑动态重构利用光路交换技术在运行时改变集群的物理连接方式。初步评估显示RFold能将绝对集群利用率提升57%并将作业完成时间缩短高达11倍。这项工作的核心价值在于它跳出了传统调度器在“放置”策略上的修修补补从系统设计的源头——作业需求与硬件供给的协同适配——入手为下一代高效能AI计算基础设施的调度器设计提供了全新的思路。对于集群运维工程师、系统架构师以及任何关心大规模计算资源效率的从业者而言理解RFold的原理与实践意味着掌握了在有限硬件上榨取更多算力的关键钥匙。2. 核心问题拆解为什么传统调度在环面拓扑中失效要理解RFold的巧妙之处首先得看清它要解决什么问题。这需要我们从机器学习作业的特性、环面拓扑的约束以及现有调度策略的局限性三个层面来剖析。2.1 机器学习作业的“形状”约束分布式机器学习训练特别是大模型训练普遍采用三维并行策略来拆分模型和数据数据并行将训练数据批次拆分到多个XPU上每个XPU持有完整的模型副本定期同步梯度。张量并行将单个模型层拆分成多个部分分布到不同XPU上需要频繁进行层内激活值和梯度的同步。流水线并行将模型的不同层放置在不同的XPU上形成一个处理流水线。一个作业的资源配置需求通常用一个三维元组(DP, TP, PP)来表示这就是作业的“形状”。例如一个(4, 6, 1)的形状表示需要4路数据并行、6路张量并行和1路流水线并行总共需要4*6*124个XPU。更重要的是这个形状定义了作业内部XPU之间的通信模式数据并行的XPU之间需要组成一个环进行All-Reduce操作张量并行的XPU之间也需要组成另一个维度的环。关键点这个“形状”不是随意的一组XPU集合它必须映射为一个在物理拓扑上连续或近似连续的几何体如长方体以确保环内通信的跳数和带宽可预测。如果分配给作业的XPU在物理上分散通信数据包就需要穿越其他作业占用的XPU和链路造成不可预测的网络拥塞和性能抖动。2.2 环面拓扑的机遇与挑战为了匹配ML作业这种邻居密集通信的模式许多现代AI集群如Google TPU v4 AWS Trainium/Inferentia2采用了环面拓扑。在一个3D环面中每个XPU直接与六个邻居前后、左右、上下相连形成一个立体的网格。这种结构的优势在于扩展成本低、布线简单并且天然支持环状通信。然而环面拓扑给资源调度带来了两个核心挑战形状兼容性问题静态环面在每个维度上的大小是固定的例如16x16x16。如果一个作业的形状在某个维度上超过了集群该维度的最大值例如需要一个1x1x32的长条那么无论集群总体有多少空闲资源这个作业都永远无法被放置因为物理上不存在那么长的连续XPU行。非邻居通信开销在环面中只有直接相邻的XPU才能以全线速、无阻塞的带宽通信。如果两个需要频繁通信的XPU被非直接邻居的链路隔开数据就必须通过中间节点“绕路”占用公共链路的带宽。当多个作业的通信路径交叉时就会产生严重的网络争用。2.3 现有调度策略的两难困境面对这些挑战现有的调度策略陷入了两难首次适应及其变体在环面中寻找第一个能容纳作业形状的连续空闲区域。这种方法能保证作业性能无争用但代价是极低的资源利用率。不同形状的作业在集群中会留下各种奇形怪状的“空洞”这些空洞无法被后续形状不同的作业利用导致严重的碎片化。就像拼图剩下的碎片形状太怪新的拼图块永远对不上。尽力而为放置放宽连续性要求只要凑够所需数量的XPU即可哪怕它们分散在集群各处。这种方法能提高XPU利用率但将通信性能的噩梦带入了现实。分散的XPU使得作业内部的通信链路过长且相互交叉网络争用会显著拖慢每个作业的训练速度有时甚至比排队等待连续资源的延迟还要高。这两种策略分别优化了利用率或性能但都无法同时兼顾。RFold的出发点正是要打破这个僵局我们能否既保证作业获得无争用的通信性能又让集群的每一个XPU都尽可能忙碌起来3. RFold 技术原理让作业与拓扑共同“舞蹈”RFold的核心思想是动态协同适配。它不再将作业形状视为不可更改的圣旨也不将集群拓扑看作一成不变的牢笼而是通过“折叠”与“重构”两种手段让双方灵活变通找到最佳结合点。3.1 基石可重构环面拓扑RFold发挥作用的前提是集群硬件支持一定程度的动态重构。这主要依靠光路交换器来实现。以Google TPU v4集群的设计为例一个大规模的4096-XPU集群并非直接连接成一个巨大的16x16x16静态环面。而是先由64个硬连线的4x4x4 XPU立方体构成。每个立方体在六个面的对应位置都有端口连接到一组OCS。OCS可以在微秒级时间内动态地将一个立方体表面的一排端口连接到另一个立方体的对应表面端口或者连接回自身形成环回链路。这样通过配置OCS多个4x4x4的小立方体可以在逻辑上“拼接”成更大的长方体或环面例如4x8x4 8x8x8从而在运行时改变集群的逻辑拓扑。这为容纳不同形状的作业提供了物理基础。3.2 第一支舞作业形状折叠“折叠”的精髓在于在保持作业通信语义不变的前提下寻找其原始形状的拓扑同构体。简单来说就是给作业“换一身衣服”让它能更合身地放进当前集群的空闲“衣柜”里。3.2.1 一维作业折叠对于纯数据并行的作业其形状为A x 1 x 1通信模式是一个包含A个XPU的环。传统调度会试图在一维度上找A个连续的XPU。但如果A不是4的倍数基础立方体维度就无法利用立方体内的环回链路性能受损。折叠则放宽了“必须在同一直线上”的限制。它的目标是在当前的可用XPU分布图中找到一个长度为A的简单环。这个环可以在三维空间中蜿蜒曲折只要最终能首尾相连形成一个通信环即可。如图2左侧的绿色作业所示一个需要18个XPU的1D作业可以被折叠放入两个4x4x4立方体拼接成的空间中尽管没有任何一个维度能提供18个连续XPU。3.2.2 二维与三维作业折叠对于形状为A x B x 1的2D作业例如DPTP折叠可能将其映射为一个3D形状。如图2中间的蓝色作业原始形状1x6x4难以放置Y维度6不是4的倍数无环回链路。通过折叠可以将其映射为同构的4x2x3形状橙色作业。原来在Z维度的通信被映射到新形状的X维度原来在Y维度的通信则通过巧妙的路径规划在新形状的Y‘维度上形成一个虚拟的环。3D作业的折叠更为复杂但原理相通。它通过重新映射通信维度有时可以将一个需要跨多个立方体的作业“压缩”进单个立方体内。如图2右侧的红色作业原始4x8x2形状需要两个立方体折叠后的4x4x4形状只需一个立方体并通过层内和层间特殊的通信映射实现了等效的通信模式。实操心得理解“同构”是关键折叠不是随意改变形状。它依赖于严格的图同构验证。调度器将作业的通信模式抽象为图节点是XPU边是通信链路然后搜索当前可用资源图中是否存在一个子图该子图与作业通信图同构。这保证了折叠后的形状能完全支持原作业的所有通信集合操作性能无损。3.3 第二支舞拓扑动态重构当折叠 alone 仍无法找到合适放置时RFold会启动拓扑重构。调度器会评估如果将几个空闲的立方体通过OCS连接起来形成一个临时的、更大或形状不同的逻辑拓扑是否能容纳当前作业这个过程类似于动态分配“房间”。调度器会尝试多种将大作业拆分成小块与基础立方体匹配的方案然后在各个立方体中寻找匹配小块形状的空闲区域。最后通过OCS将这些分散的块“焊接”起来形成一个逻辑上连续的资源区域。3.3.1 重构的代价与启发式策略OCS连接是宝贵的资源其端口数量有限且重构本身有微小的延迟。因此RFold采用一个核心启发式规则最优放置方案应消耗最少数量的可重构立方体和OCS链路。这意味着调度器会优先尝试将作业放置到单个立方体内或尽可能少的立方体内并优先使用立方体内部已有的硬连线链路而非通过OCS建立的外部连接。3.4 协同工作流RFold调度算法RFold的调度决策是一个搜索与排序的过程形状变体生成当作业到达时调度器首先基于图同构枚举出该作业所有可能的、性能无损的形状变体折叠。虚拟重构与放置尝试针对每一个形状变体调度器在当前的集群资源状态图上虚拟地尝试各种拓扑重构方案寻找可行的放置位置。方案评分与选择对所有找到的可行放置方案根据“消耗的可重构立方体/OCS链路数量”等启发式规则进行评分。提交与执行选择最优方案提交资源分配指令并驱动OCS进行实际的物理拓扑重构最后启动作业。这个流程将折叠改变软件需求与重构改变硬件供给紧密结合极大地扩展了调度器的解空间从而更有可能找到同时满足高利用率和无争用性能的分配方案。4. 实现考量与部署挑战将RFold从论文构想变为生产级系统需要跨越工程上的诸多障碍。这部分结合常见的系统部署经验探讨其实现细节和潜在挑战。4.1 调度器架构设计一个生产可用的RFold调度器需要包含以下核心模块资源状态管理器维护一个全局的、细粒度的集群资源图。不仅要记录每个XPU的空闲/占用状态还要跟踪每个OCS端口和链路的连接状态。这个状态必须保持强一致性通常需要一个分布式协调服务如etcd来保证。同构形状生成器实现高效的图同构算法用于生成作业的形状变体。由于作业形状维度通常不超过3且规模有限可以使用成熟的图算法库如NetworkX并在搜索中施加约束如各维度大小乘积等于所需XPU数以控制计算开销。放置策略求解器这是性能瓶颈所在。需要在巨大的搜索空间形状变体 × 重构方式 × 放置位置中快速找到可行解。可以采用启发式搜索如优先尝试消耗资源少的方案、约束求解器或基于强化学习的方法来加速。OCS控制器驱动需要一个低延迟、高可靠的驱动层将调度器输出的逻辑连接图转换为对物理OCS设备的配置命令序列。这涉及到与特定厂商OCS的API集成。4.2 性能与开销权衡RFold引入了额外的调度延迟和系统复杂度必须仔细权衡调度延迟枚举形状变体、搜索放置方案都是计算密集型操作。对于需要快速响应的短期作业这个延迟可能无法接受。一个可行的优化是分级调度对超大规模作业或长期运行作业使用完整的RFold算法对小型作业或对延迟敏感的作业回退到快速的首次适应或最佳适应算法。重构开销OCS切换链路通常需要毫秒到微秒级的时间。频繁重构拓扑可能带来不可忽视的开销并可能对正在进行的作业通信造成瞬时扰动。因此调度器需要具有“粘性”倾向于将作业放置在现有拓扑上而不是动辄重构。可以设置一个重构频率阈值或成本模型只有当预期收益如减少排队时间、容纳关键作业远超重构开销时才触发重构。容错与恢复当某个OCS节点或链路故障时RFold需要能感知并重新规划。这要求资源状态管理器能快速检测故障并将受影响作业的拓扑进行重新折叠与放置这可能涉及作业的检查点重启。4.3 与现有生态的集成现有的ML集群通常运行在Kubernetes、Slurm或YARN等资源管理系统之上。RFold调度器可以作为这些系统的一个定制调度插件来集成。在Kubernetes中可以实现一个自定义调度器或者开发一个调度器扩展器。当默认调度器无法为Pod作业找到节点时RFold插件介入尝试进行折叠和重构的放置决策。在Slurm中可以通过开发一个新的拓扑感知插件来集成。Slurm本身支持3D环面拓扑感知RFold可以扩展其功能在slurmctld进行资源分配决策时提供更智能的放置建议。关键是要设计清晰的API和资源模型向上向编排系统汇报“逻辑拓扑”资源向下驱动OCS和作业启动。5. 评估结果与性能分析研究团队通过一个定制的作业级离散事件模拟器对RFold进行了初步评估。模拟环境构建了一个4096个XPU的集群并对比了静环面和不同粒度8x8x8 4x4x4 2x2x2立方体的可重构环面。作业Trace基于微软Philly集群的作业到达间隔和持续时间但根据学术集群的观察重写了作业大小和形状分布小作业多为1D/2D大作业多为2D/3D。5.1 核心性能指标对比评估聚焦于三个关键指标作业完成率、作业完成时间和集群利用率。5.1.1 作业完成率JCR衡量的是调度器成功安排作业执行的比例直接反映了其处理异构形状作业的能力。调度策略 (立方体大小)平均作业完成率FirstFit (静态 16x16x16)10.4%仅折叠 (静态 16x16x16)44.1%仅重构 (8x8x8 立方体)31.5%RFold (8x8x8 立方体)73.4%仅重构 (4x4x4 立方体)100%RFold (4x4x4 立方体)100%结果解读FirstFit在静态环面上表现极差仅有10.4%的作业能被成功调度。这强力印证了形状约束是导致作业排队和资源浪费的主要原因。仅折叠策略将JCR提升至44.1%这完全是“软件灵活性”带来的增益它让更多作业能在静态硬件上找到容身之所。仅重构策略随着立方体粒度变细从8x8x8到4x4x4JCR从31.5%提升至100%。这说明“硬件灵活性”是解决形状兼容性问题的根本手段。RFold在中等粒度8x8x8下实现了73.4%的JCR显著高于单独的折叠或重构策略。这证明了协同适配的威力当硬件灵活性不足时8x8x8立方体仍较大通过软件折叠来补偿能大幅提升调度成功率。当硬件足够灵活4x4x4时两者都能达到100%。5.1.2 作业完成时间JCT衡量的是作业从提交到结束的实际运行时间包含了计算时间和通信时间直接关系到用户体感和资源周转效率。(注此处应用图表展示p50 p90 p99分位的JCT对比例如RFold (4) vs Reconfig (4) 在p50有11倍提升)关键发现在4x4x4立方体的可重构环面上RFold相比仅重构策略在中位数p50作业完成时间上实现了11倍的加速在尾部p90 p99也有6倍和2倍的提升。即使将立方体缩小到更灵活的2x2x2仅重构策略的性能有所改善但RFold依然能保持最高1.3倍的性能优势。这揭示了折叠的核心价值它不仅提高了调度成功率更重要的是它通过寻找更优的形状映射减少了作业对跨立方体OCS链路的依赖。更多的通信被限制在立方体内部的高速硬连线链路上从而显著降低了通信延迟和争用风险直接转化为更短的作业完成时间。5.1.3 集群利用率集群利用率衡量的是XPU忙碌时间的百分比是数据中心运营成本效益的核心指标。(注此处应用CDF图展示不同策略下集群利用率的分布)结果分析FirstFit和仅折叠策略在静态环面上集群利用率很难超过40%根源在于低下的JCR导致大量XPU闲置。仅重构策略凭借高JCR将利用率提升到了高位。RFold在仅重构的基础上进一步将利用率提升了约20个百分点。这额外的增益来自于折叠技术更好地“填塞”了资源碎片。即使硬件重构提供了空间折叠也能以更紧凑、浪费更少的形状将作业放置进去从而挤出更多的可用资源给后续作业。5.2 对系统设计的启示评估结果给出了几条清晰的指导原则硬件重构是基础没有OCS提供的拓扑灵活性面对多样化的ML作业形状调度器将束手无策。4x4x4的立方体粒度在本研究中显示出良好的平衡性。软件折叠是增效器在硬件重构的基础上折叠技术能以零额外硬件成本进一步大幅提升性能和利用率。它是解锁硬件潜力的关键软件优化。协同设计是未来RFold的成功表明在AI基础设施栈中编译器决定作业形状、调度器决定资源映射和网络硬件提供拓扑灵活性必须进行跨层协同设计与优化。未来ML框架或许能提出多种性能等效的并行策略供调度器选择而交换机则能提供更细粒度的重构能力。6. 延伸思考与未来方向RFold为大规模ML集群调度打开了一扇新的大门但其本身也引出了许多值得深入探索的问题。6.1 连续放置 vs. 尽力而为放置的再思考RFold坚持“无争用”的连续放置原则。但在实际生产中是否可以考虑一种混合策略例如当一个作业的预期排队时间很长时调度器可以评估如果立即以“尽力而为”的分散方式启动它其因网络争用导致的性能下降是否仍然优于漫长的排队等待这需要调度器具备精准的性能建模能力能够预测不同放置方案下的作业完成时间。这或许能进一步降低平均作业周转时间。6.2 重构粒度的权衡本研究聚焦于4x4x4的立方体。但重构的最佳粒度是什么更大的立方体如8x8x8意味着更少的OCS端口消耗能支持构建更大规模的集群但灵活性下降。更小的立方体如2x2x2甚至1x1x1提供了极致的灵活性能几乎消除形状约束但会急剧增加OCS的端口数量和成本以及调度算法的复杂度。未来的系统可能需要支持异构的立方体粒度或者动态调整重构单元的大小。6.3 超越3D环面与3维作业当前工作局限于3D环面拓扑和最多3维的作业形状。但ML模型和硬件都在演进。例如更高维并行专家并行、序列并行等新的并行维度可能出现作业形状可能变为4维或更高。更复杂的拓扑除了环面是否有其他拓扑如超立方体、胖树与环面混合更能适应未来的通信模式异构计算单元集群中可能包含不同代际或类型的XPU如GPU、TPU、专用AI芯片RFold如何结合异构性进行调度将折叠与重构的思想推广到这些更一般的场景是一个充满潜力的研究方向。6.4 生产部署的实践挑战在实际部署中还会遇到一些论文中未深入探讨的挑战多租户与安全隔离当通过OCS将不同用户的作业连接在同一个逻辑拓扑中时如何保证网络层的安全隔离例如通过切片或VPN故障域的管理一个OCS的故障会影响多个逻辑连接。调度器需要感知故障域避免将同一个作业的关键路径放在同一个脆弱的OCS下。能源效率更密集的资源利用意味着更高的功率密度。调度决策是否需要考虑机架功耗和冷却能力动态重构的功耗开销是多少从我过去部署大规模计算系统的经验来看任何新调度策略的落地其可观测性和可调试性都至关重要。RFold调度器需要输出详尽的决策日志为什么选择这个形状变体为什么选择这个放置位置预计的性能收益是多少当出现性能不符预期时这些日志是排查问题的唯一依据。同时需要一个可视化工具能够动态展示集群的物理拓扑、逻辑拓扑以及作业的放置情况让运维人员对系统状态一目了然。