企业官网建设流程全解析

多模态大语言模型训练这个方向，最近一年让我越来越头疼。模型本身的效果确实越来越强，但训练过程对底层基础设施的"恶意"也在成倍增加。如果你也跑过图文混合或者视频理解类的训练任务，一定见过那种让人血压飙升的GPU利用率曲线：同一批卡里，有的长期顶着99%不放，有的只有30%，偶尔还有几块卡因为收到超长视频样本，直接把显存顶到警戒线。

我一度以为是数据加载管道写得有问题，后来才发现事情没有那么简单——多模态大语言模型训练的工作负载本身就在剧烈波动。传统的静态资源分配方式，本质上是按峰值需求给每个任务圈地，圈完之后就再也不管了。这种模式在单模态LLM训练里还能凑合，落到多模态场景时，算力浪费已经到了无法忽视的程度。

EuroSys'26上有一篇论文叫MegaScale-Omni，定位就是解决这个问题的：面向生产环境中多模态大语言模型训练的超大规模工作负载弹性系统。我读完之后最大的感受是，它没有去卷什么新鲜的并行策略，而是老老实实把"资源弹性"这件事从系统层面做到了生产可用的程度。这篇文章我想结合自己搭建训练平台时的实际经验，把这套系统的核心思路拆开讲清楚：多模态训练为什么这么难调度、双层资源池是怎么设计的、弹性迁移为什么能基本无感、以及落地过程中最容易被忽略的坑。

1. 为什么多模态训练让集群变得"忽饥忽饱"：问题本质拆解

1.1 三种动态性：数据形状、模态计算比、显存水位全部在漂移

先说说多模态训练和纯文本训练在底层行为上的区别。纯文本训练里，一个batch就是一批token序列，只要做了长度分桶和采样排序，每个step的计算量可以控制得相当稳定。多模态训练完全不是这么回事。

一个batch里可能同时混着纯文本样本、单张图片的样本、多图交错样本、还有几秒钟的视频片段。视频样本进入视觉编码器之后，要按帧拆成patch再抽特征，计算量和一张低分辨率图片相比，可能相差几十倍。这些样本被数据并行分成多份交给不同GPU时，每个rank拿到的实际计算负载天然就不平衡。

我把这种差异总结成三种动态性：

• 数据形状动态性：文本看token长度，图像看patch数量，视频看帧数和分辨率，它们的量纲完全不同。一个step里如果某个DP rank恰好分到几个超长视频，它这一轮的计算时间就是别人的好几倍，所有其他rank都必须等它。这种"水桶效应"在纯文本训练里靠排序几乎能消除，在多模态里则频繁出现。
• 模态计算比漂移：图文比不是恒定的。数据采样器在训练过程中会动态改变图像样本的比例，导致视觉编码阶段和语言解码阶段的计算占比来回摆。如果流水线并行把vision tower单独放在某几张卡上，那这几张卡会时而成为瓶颈，时而完全闲置。
• 显存水位震荡：长视频和极端高分辨率图像会在前向过程中产生巨大的中间激活值，KV cache也会跟着涨。优化器状态是固定的，但激活值和KV cache让显存占用出现脉冲式波动。静态分配显存时只能按最坏情况预留，于是平时就有大量显存空着。

1.2 静态放置方案让集群实际利用率低到可怕

传统训练平台的做法，是在任务启动时根据模型大小、并行度、预估样本形状，分配一个固定数量的GPU，之后这个数字就不再变化。

问题在于，任务的真实资源需求是随时间流动的。我见过太多案例：一个任务在数据里视频样本密集的阶段需要200张卡才能跑得动，在纯文本阶段150张卡就绰绰有余。如果你静态分配200张卡，那视频阶段的资源刚好够，但一旦进入文本密集阶段，几十张卡就处于半闲置状态。

用一组简单数据估算一下：假设两个训练任务，A任务需要120到200卡之间波动，B任务需要80到120卡之间波动。按峰值分配，集群要为它们预留320卡。但很多时候两个任务的实际需求加起来只有180到240卡，平均利用率可能连70%都不到。如果还要为突发流量预留buffer，实际利用率会更难看。换句话说，集群里明明堆满了卡，训练就是快不起来，根源不是卡不够，而是卡被静态地分给了错误的时刻。

1.3 为什么不能直接套用单模态LLM的弹性方案

看到这里你可能会想，LLM训练不是早就有一套故障恢复与节点替换的方案了吗？直接拿来用不行吗？

差得很远。现有的大规模LLM训练弹性方案，核心是状态感知的故障处理：某个节点掉线了，检测到之后重新拉起一个节点，从checkpoint恢复训练。它解决的"突发问题"是节点死掉、训练中断这类确定性事件，调度的依据是节点状态是健康还是不健康。

多模态场景需要的是负载感知的弹性迁移：节点都是健康的，训练也没有中断，但不同GPU之间的负载偏差已经大到拖垮整体吞吐。这时候要做的是把高负载任务的某些弹性单元迁走，或者把闲置资源补充给有瓶颈的任务，让训练过程在运行中平滑变形。前者是故障域里的"救援机制"，后者是资源域里的"再平衡机制"，两者解决的问题完全不同。MegaScale-Omni做的正是后者。

顺带说一句，这篇论文可以看作是此前MegaScale系列工作在方向上的延续。如果MegaScale解决的是单模态LLM在超大规模集群上"训练性能可预测"的问题，那MegaScale-Omni就是把目标从"规模化训练的确定性"升级成了"多模态负载下的自适应弹性"，从"扛住一万卡不出错"进化到"一万卡随时动态调整而不颤抖"。

2. 资源池怎么分：虚拟机主池与物理机池的双层设计

2.1 为什么不能只靠虚拟化，也不能只靠物理机

做弹性系统，第一反应肯定是上虚拟化，因为虚拟机可以热迁移。但多模态训练这种场景，纯虚拟化有一个致命问题：GPU虚拟化会在IO路径上引入额外的开销。

训练任务里频繁发生的是数据并行的allreduce、流水线并行的点对点通信，这些操作对网络和GPU之间的数据搬运极为敏感。虚拟化层哪怕只带来5%到10%的性能抖动，在万卡规模下都会被放大成可观的训练吞吐损失。反过来，如果完全用物理机，性能倒是确定了，但物理机的资源是无法被切碎和腾挪的，没法做到细粒度的弹性分配。

MegaScale-Omni的处理方式很直接：不搞二选一，而是两层都留。它把集群分成虚拟机主池和物理机池，各自承担不同角色。虚拟机主池里的资源可以被弹性调度、热迁移、重新组合，用来承接负载波动带来的变化量。物理机池里的资源则被分配给训练任务中那些对延迟和确定性要求最高的核心进程，保证整体训练吞吐不因虚拟化而失血。

这个设计用生活化的类比理解就是：物理机池是家里的主力灶台，性能稳定、火力全开；虚拟机池是一排可以随时搬动的小灶，饭点忙碌的时候支起来帮忙，闲下来就收走。训练的"主干道"留在物理机池，弹性的"缓冲带"由虚拟机池来承担。

2.2 弹性单元：调度系统操作的最小资源粒度

弹性系统不能拿整个任务做迁移单位，那代价太大了。MegaScale-Omni引入了"弹性单元"的概念，这是调度器操作资源的最小单位。

粒度选多少是个关键决策。粒度太细，比如单张卡，调度非常灵活，但会导致资源碎片化问题加剧，每个卡片的通信拓扑都可能不一样，训练框架难以组织高效的集合通信。粒度太粗，比如一次迁移一个完整的流水线并行组，迁移开销就太大了，而且可迁移的机会窗口也很少。

合理的选择通常是一个NVLink域内的几块卡，或者是能够支撑一个数据并行副本的最小卡数。为什么与数据并行副本对齐很重要？因为数据并行的每个副本在每一步结束时都要做梯度allreduce，如果把弹性单元定义成一个DP副本，那么迁移的本质上就是"把一个数据并行副本从物理位置A挪到物理位置B"，训练框架的并行结构不需要做大的调整。

单张卡本身往往不构成一个完整的DP副本（除非模型小到可以单卡塞下），所以弹性单元的粒度天然会和DP副本的概念咬合在一起。

2.3 全局调度器的多目标决策逻辑

有了弹性单元，调度器要回答的问题就变成了：什么时候迁、迁哪些单元、迁到什么位置、什么时候不迁。

这几个问题放在一块儿，本质上是一个多目标在线决策问题。既要最大化集群整体的有效吞吐，又要控制迁移对训练任务自身吞吐的干扰，还要避免资源拓扑被反复打散。

MegaScale-Omni的调度策略更接近于"触发式启发式加周期性均衡"的混合方案。触发式部分负责处理显著的负载偏差：当某个任务的实际资源使用和分配资源之间的偏差超过预设阈值时，调度器尝试从空闲池里找资源补偿，或者把冗余资源收回。周期性部分负责解决碎片化：每隔一段时间扫描一遍全局，用量低的任务把资源让出来，量高的任务把资源吃进去，消除那些靠局部触发永远发现不了的隐性浪费。

这和我自己在平台里调调度器的经验是一致的。纯实时触发容易让系统变得急躁，纯周期均衡又反应太慢，混合方式才是生产系统里能稳定工作的形态。

3. 弹性迁移如何做到基本无感：核心机制的技术路径

3.1 为什么迁移动的是数据并行维度，而不是流水线或张量并行维度

这是整个系统设计里我认为最关键的洞察。

流水线并行（PP）是把模型的层切开放在不同卡上，每一层都依赖前一层的输出，任何一张卡的迁移都意味着整条流水线的气泡率重组，牵一发而动全身。张量并行（TP）是对单个算子做切分，卡与卡之间的通信粒度极细，对物理拓扑极其敏感，把TP组里的卡迁到不同网络域，训练性能会立刻崩掉。

数据并行（DP）不一样。DP的每个rank持有完整的模型副本（或者一份完整的状态分片），处理的是不同的数据，彼此之间只在梯度allreduce时发生同步。这意味着调整DP维度的数量，不需要搬运模型层状态，不需要重建算子切分，只需要把新rank的模型状态初始化好，然后重建梯度同步的allreduce组合适。所以MegaScale-Omni的弹性迁移，核心作用对象是DP维度，而不是PP或TP维度。

3.2 数据并行再切分的完整过程

把DP维度从N路调整到N+1路或者N-1路，听起来简单，实际上包含一堆脏活。迁移一个DP rank时，需要把以下状态完整搬走或重建：

• 模型参数和优化器状态。如果用了优化器状态分片（业界常见的ZeRO式优化），那分片边界需要重新计算，部分状态要从旧rank搬到新rank。这个过程如果做同步拷贝，延迟会很高，所以需要异步预取。
• 数据加载器的迭代位置和随机种子。DP rank的每个副本都消费数据集的一个分片，迁移后必须保证新的数据分片位置正确，否则会重复消费或漏掉样本。
• 学习率调度器的step计数。这玩意儿一旦错位，训练曲线马上就能看出来。

整个再切分过程有个很实用的技巧：新DP rank的模型参数可以通过旧rank的checkpoint异步加载，也可以通过从其他rank拷贝内存来初始化。论文里的弹性系统更倾向于后者，因为从checkpoint重建要重新读一遍磁盘，而内存拷贝快得多。

3.3 迁移后的通信拓扑补偿

哪怕只动了DP维度，物理位置变了，网络的通信拓扑还是受到影响。一个DP group里的rank，如果有的在物理机池、有的在虚拟机池，分布在不同网络域里，allreduce的带宽就会下降。

论文的应对思路是层级化通信补偿。先利用物理拓扑信息，把allreduce拆成两段：先在各自域内完成局部归约，再在域间做一次轻量级归约。这样跨域通信的流量被压到了最小。如果条件允许，还可以临时把梯度累积步数调大，降低通信频率，给新拓扑一个适应窗口。

这一块我们自己在做跨拓扑通信时也踩过类似坑。如果不做层级归约，全量跨域allreduce的带宽损耗通常会导致通信时间翻倍，整体训练吞吐下降好几个百分点。做了分组归约之后，这种损耗基本能压到可接受范围。

3.4 与checkpoint和故障恢复的配合

弹性迁移不是盲目的。迁移前，系统会在旧节点上做一个轻量级checkpoint，记录的并不是完整的模型状态，而是迁移所需的"最小恢复点"：模型参数、优化器状态、数据位置和随机状态。

关键设计在于双缓冲机制。迁移过程中，旧节点并不会立刻销毁，而是继续保持接收新数据。如果新节点初始化失败，旧节点还能继续跑，不回退到完整checkpoint重建。这相当于是给迁移过程上了个保险：就算迁移失败，训练也只是暂缓，而不是从头恢复。

这一点和容错重启有本质区别。容错重启是任务级的中断恢复，往往要回到最近的checkpoint，丢掉的训练进度按小时计算。弹性迁移是执行级的平滑变形，失败最多少了几分钟的进度，而且还有旧节点托底。

3.5 通信遮蔽：让迁移看起来是减速而不是停顿

用户或者算法工程师对"停顿"的容忍度很低，但对"减速"的容忍度相对高。MegaScale-Omni在迁移过程中的通信遮蔽策略，就是把停顿伪装成减速。

受影响的节点在迁移过程中继续处理本地数据微批次，其他节点也照常推进训练。等到新节点就绪，训练联调同步机制重新收敛。也就是说，迁移不是一个"stop the world"的全局事件，而是一个异步的、局部的资源再分配过程。这背后依赖的是对训练框架数据流的精细控制能力，也是"弹性"和"重启"之间最根本的分野。

4. 实测数据里的门道：吞吐收益从哪来，迁移开销有多高

4.1 收益拆解：省下的不是算力，而是"不动性"

读论文时我特别关注它实验部分的数据来源。MegaScale-Omni的评估用的是生产环境的真实训练任务，不是简单的benchmark合成负载。这在一众系统论文里是比较加分的做法。

论文展示的收益主要有三个维度：GPU资源利用率提升、集群可同时并发的训练任务数量增加、训练任务的整体完成时间下降。

这里要拆开看收益到底从哪里来。弹性系统的收益并不是凭空产生算力，而是把原本静态分配中的闲置资源释放出来，让它们在被浪费的时间窗口里服务其他任务。本质上省下的是"任务的不可动性"——传统系统里资源一旦分配给任务，就算任务暂时用不满，这块资源也不会吐出来；MegaScale-Omni让资源分配曲线贴近真实负载曲线，而不是永远钉在峰值线上。

4.2 迁移开销的量化判断

弹性迁移当然有成本。迁移一个弹性单元的时间通常在分钟级别，期间训练有吞吐损耗。

但账要算整体。一次负载波动窗口往往持续十几分钟甚至更长，而迁移造成的影响只有几分钟，而且是渐变的、部分遮蔽的，不是完全停摆。用个简化模型：假设迁移成本C约2分钟，释放出的资源能让其他任务在一个60分钟的窗口里多获得30%的算力，如果集群存在排队等待资源的任务，那这笔账怎么算都是划算的。

作者在论文中报告的迁移开销占比整体训练时间的比例相当低，而且通过异步初始化和通信遮蔽，实际训练吞吐的下降幅度远小于理论值。核心结论就是：弹性迁移的成本不是零，但相比静态分配带来的长期闲置浪费，那点开销是可以忽略的。

4.3 两类典型工作负载的表现差异

论文实验里覆盖了两类用途：图文交错的SFT数据和视频理解预训练数据。这两类负载的动态性来源差别很大，我把关键差异整理成一张表：

视频预训练是弹性收益最明显的场景，因为长视频样本本身是稀疏出现的，静态分配要为最坏情况预留资源，而弹性系统可以在没有长视频样本的时间窗口里把资源吐出去。

4.4 生产环境验证和纯benchmark的差别

读这类系统论文时要特别留意一个点：生产环境和benchmark的负载特征完全不同。benchmark里的负载是人工生成的，形状相对干净；生产环境的负载是真实用户喂进去的，充满了长尾分布、突发峰值和不可控因素。

MegaScale-Omni的实验里包含了对真实负载trace的分析，这让我们能判断它在"脏数据"环境下的表现。我的经验是，一个系统如果在干净benchmark里表现优异但没跑过生产trace，落地时大概率翻车。这一点上MegaScale-Omni的验证思路是值得学习的。

5. 落地踩坑与边界：照着论文复现需要绕开哪些雷

论文读起来总是清爽的，落地时全是泥。我在自己搭建类似弹性训练平台的过程中，遇到过不少论文里轻描淡写、实际却足以让项目返工的坑，分享几个印象最深的。

5.1 显存测量噪声会让弹性决策失真

第一个也是最隐蔽的坑：显存度量的依据。很多团队做资源感知调度时，直接从GPU驱动读取显存占用，但深度学习框架的显存缓存分配器会保留已经释放的空闲块，导致你看到的显存占用数据比实际真实占用要高得多。

如果调度器基于这个数据判断某个弹性单元是否过载，它会认为显存长期不够用，频繁触发没必要迁移；反过来，如果你以为显存还有很多，把新的副本塞进去，结果真正的显存压力突然爆发，直接OOM。

解决方向有两个：一是从训练框架内部拿真实的分配统计，而不是读nvidia-smi；二是给显存缓存设置上限，让空闲块及时还回去。这两件事不做，弹性决策的所有依据都是假的。

5.2 "弹性振荡"：调度器自己把自己抖散架

负载波动是连续的，如果迁移触发阈值设计得不好，调度器会在"迁出-迁入"之间来回抖动。每次迁移都有成本，抖几次之后，系统时间全耗在迁移上了，训练反而更慢。

业界的通用做法是引入迟滞区间：触发迁移的阈值要明显高于解除迁移的阈值，而且给每次迁移加一个冷却时间。比如负载超过90%才触发迁入，低于70%才触发迁出，中间这20%的区间是缓冲带。再加上全局周期性均衡，就可以避免调度器对瞬时波动反应过度。

我在早期调这种参数时，发现阈值设得太敏感是最常见的错误。宁可让负载偏差保持一段时间再触发迁移，也好过看到一点风吹草动就动手。

5.3 弹性单元与训练框架并行维度的映射关系不能错位

这是最容易被低估的一环。弹性单元在物理层面调整了资源，但训练框架内部的并行组是静态的。如果你只改了容器资源却没有同步修改框架的数据并行维度配置，训练进程之间的allreduce group会错乱，轻则通信异常，重则直接死锁。

正确的做法是，调度器和训练框架之间要有明确的控制接口。框架要能感知资源变化，动态重建allreduce group，而不是在启动时生成一次并行布局之后再也不动。这个改造比调度器本身复杂得多，也是我在实际项目里花时间最多的地方。框架侧的弹性感知能力，是决定整个弹性系统能不能落地的最大前置条件。

5.4 数据加载管道是弹性迁移里最容易被遗忘的环节

迁移一个DP rank时，大家的目光都集中在模型参数和优化器状态上，但数据加载器的状态同样关键。每个rank消费数据集的一个分片，迁移后新rank的数据分片起点怎么算？之前的epoch进度怎么延续？随机种子是否要对齐？

我见过一次事故：迁移后新rank因为数据分片位置错误，连续好几个step都在读重复数据，模型训练曲线直接扭曲。要避免这个问题，数据加载器状态必须作为checkpoint的一部分被保存和恢复，包括shuffle的随机数状态、当前epoch计数、当前样本偏移量，一个都不能少。

5.5 可观测性是弹性决策的地基，也是大多数团队最薄弱的环节

最后是监控指标的完整性问题。要做负载感知的弹性调度，你至少需要同时看见以下几类指标：GPU算力利用率、SM占用率、显存带宽、网络通信量、allreduce等待时间、流水线气泡比例、数据加载延迟。

只看GPU利用率一个指标，会犯一类经典错误：把"算力跑满了"当成"任务健康"，其实任务可能正卡在数据加载上，GPU的空转占用率虚高。只有把这些指标联合起来，才能判断一个任务当前的瓶颈到底在算力、显存、网络还是数据管道。没有这个地基，弹性调度就是空中楼阁。

这五个坑并不是论文里没提示，而是论文不会用"踩坑者视角"告诉你它们有多致命。真正落地时每一个都会咬你一口。

6. 看完这篇系统论文，最有价值的其实是三个工程启示

6.1 控制面与数据面分离

MegaScale-Omni给我最深的一个工程启发，是把调度决策和训练执行彻底解耦。调度器负责观察负载、做迁移决策；但真正的迁移动作由独立的数据面服务执行，不会阻塞训练的正常数据流。

我在自建平台时吃过控制面和数据面耦合的亏：调度器在训练进程内部跑，一旦调度逻辑发生阻塞，训练直接被拖停。后来把调度职责全部移到独立的控制面进程，用异步通知的方式给训练框架下发指令，稳定性立刻上了一个台阶。

6.2 调度核心从"资源感知"升级到"负载感知"

传统调度器关心的问题是：哪个节点有空闲GPU，把任务放到哪里最合适。MegaScale-Omni的启发是，调度器还要关心另一个问题：任务当前真正的资源瓶颈在哪里，它是否正在浪费资源。

这种从资源视角到负载视角的转变，带来的直接收益是可以发现并利用任务的互补性。一个任务在白天是计算瓶颈，另一个任务在深夜是显存瓶颈，传统调度器看不到这种时间上的互补，但负载感知的调度器可以动态错峰。

6.3 训练框架必须为弹性预留接口

前面提到过，框架侧的弹性感知改造是整个系统的最大前置条件。如果训练框架仍然沿用启动时一次性创建并行布局的静态模型，那无论上层调度多聪明，都无法实现真正的弹性。

训练框架需要提供至少三类接口：动态调整DP副本数的接口、运行时重建allreduce group的能力、以及把状态迁移交给外部管理器的能力。这三件事做完了，后续引入任何调度策略都会事半功倍。

以我个人的实际体会来说，如果现在让我重新搭建一个训练平台，我不会一开始就把弹性调度系统做得很重。我会先保证三件事做到位：多维度的训练可观测性、训练框架预留出弹性改造的接口、以及一条轻量级的状态迁移通道。MegaScale-Omni的价值不是某一个炫技的调度算法，而是把这三件事完整地串成了一个可运维的系统。先把地基打好，再谈弹性，才不会在落地时被那些隐形的坑拖进泥潭。