导读：

BigMac 是一种专为原生多模态场景设计的流水并行训练新范式。它精准瞄准了多模态大模型训练中长期存在的核心难题：计算效率与显存占用之间的矛盾，如同鱼与熊掌，往往难以兼得。BigMac 的解决方案是提出“依赖安全的嵌套流水线”。简单来说，它以成熟的 LLM 流水线作为主干，在不打乱其原有执行顺序的前提下，巧妙地“嵌入”编码器和生成器的计算任务。这样既能保证 LLM 流水线的空泡不增加，又能使激活显存保持有界，同时高效地实现了多模态的流水训练。相比传统的流水并行实现，BigMac 在工程层面也做了更彻底的解耦，将全局调度与运行时执行分开，并设计了一套接口和工具链，降低了模型接入和系统调优的门槛。实验数据令人振奋：训练速度比基线提升了 1.08 到 1.9 倍，而且当全局 batch size 增大时，显存占用依然非常稳定。目前，BigMac 已成为 dots 多模态模型训练的核心组件之一，并已在生产环境中稳定运行。

开源地址：

https://github.com/Dots-Infra/BigMac/

多模态大语言模型（MLLM）正逐步成为新一代 AI 系统的核心基础设施。与仅处理文本的 LLM 不同，多模态模型需要将语言、图像、音频等多种类型的信息集成到同一个模型中进行理解与生成。虽然能力边界大大拓展，但训练系统的复杂度也随之直线上升。

难点在于，MLLM 通常并非一整块同构的 Transformer，而是由多个形态差异显著的模块拼接而成。一个典型的多模态模型通常包含三个部分：模态编码器、LLM 主干以及模态生成器。编码器负责将图像或音频的原始输入转换成 embedding；LLM 对得到的多模态 token 序列进行推理；生成器则将 LLM 的输出映射回目标模态，例如利用图像扩散模型生成像素。

图 1：一个典型的 MLLM 架构，包含模态编码器、LLM 主干和模态生成器。

这种模块化架构带来了强大的表达能力，但也让训练系统面临普通 LLM 流水线很少遇到的复杂局面。现有的 MLLM 训练系统通常会在两种设计之间二选一，每种设计都有其合理性，但当规模扩大后，各自的瓶颈就会暴露出来。

第一种设计是计算高效的。它将编码器和生成器的计算从 LLM pipeline 中分离出来，例如 LongCat-Flash-Omni 中用于应对大规模多模态训练异构性的 modality-decoupled parallelism。系统可能会先对所有 microbatch 运行 encoder forward，保留这些 activation，然后再启动 LLM pipeline。这样，LLM pipeline 不会因为模态模块的耗时波动而被打乱：编码器和生成器慢一点，并不会直接在 LLM pipeline 内部产生 bubble。

然而，由于编码器的 activation 必须一直保留到对应的梯度返回，activation 显存会随着 microbatch 数量增长而增加。如果模型还包含生成器，情况会更糟糕：LLM activation 也可能需要一直保留到生成器计算结束。在生产规模的模型中，这尤其昂贵，因为 LLM activation 往往远大于 encoder activation。

图 2：计算高效的 pipeline。该设计将模态计算从 LLM pipeline 中分离出来，减少 bubble，但会保留大量 activation。

第二种设计是显存高效的。它把编码器和生成器直接整合进同一条 pipeline，将它们视为围绕 LLM 的首尾阶段。例如，Megatron Core 的多模态训练示例中，vision-language 模型作为独立的 pipeline stage，被加入到了 LLM 的流水线中。这样能缩短 activation 的生命周期，因此显存占用更低。但代价是，所有模块现在都被 pipeline 依赖耦合在一起。如果某个 encoder 或 generator microbatch 运行慢了，LLM pipeline 就得等待。如果生成器运行时间变化较大，pipeline 尾部就会产生 bubble。换句话说，系统是在用计算效率来换取显存。

图 3：显存高效的 pipeline。该设计将所有模块整合到一条 pipeline 中，减少显存占用，但会产生跨模块 bubble。

这正是 BigMac 想要突破的帕累托前沿。计算高效的系统速度快但显存开销大；显存高效的系统节省显存但容易产生 bubble。对于小规模训练任务，这种二选一或许还能接受，但对于大规模多模态训练，尤其是包含模态生成器的训练，这个两难问题就会成为瓶颈。

BigMac 的思路其实很直接：调度的主干仍然应该是 LLM pipeline。大规模 LLM 已经依赖 1F1B 或 interleaved 1F1B 等精心优化过的 pipeline schedule，这些 schedule 成熟、高效，并且与生产级 LLM 训练栈深度绑定。BigMac 不试图替换它们，而是把 LLM schedule 作为基础时间线。

BigMac 的想法是，先稳住最重要的 LLM pipeline，然后把编码器和生成器的计算插入到合适的位置。这里的“合适”指的是：输入已经准备好，并且插入这些计算不会打乱原本的 LLM 执行顺序。这样一来，LLM pipeline 可以持续推进，编码器和生成器的激活也能更早释放。我们称这种设计为依赖安全的嵌套流水线 (nested pipeline)。

图 4：BigMac 保留原始 LLM pipeline schedule，并把 encoder/generator 工作嵌入到依赖安全的位置。

这个设计为 BigMac 带来了两个重要特性。

第一，它保留了计算效率。由于编码器和生成器不再被强行塞进 LLM 流水线作为独立的 pipeline stage 逐级推进，它们的耗时波动也不会沿着 LLM 流水线一路传递。LLM 仍然按照它本该遵循的 schedule 运行。

第二，它限制了模态 activation 的显存占用。BigMac 会在梯度就绪后尽快运行 encoder backward 和 generator backward。编码器不需要一直为所有 microbatch 保留 activation，直到 LLM pipeline 结束。生成器也不需要保留很长的 activation 尾部。从算法层面看，BigMac 将编码器和生成器的 activation 显存降低到了 O(1)，同时保持 LLM activation 行为不变。

这就是整个流水线的核心所在：BigMac 不是在显存和 bubble 之间做交易，也不是用 bubble 换显存。它改变了 schedule 结构，让这两个目标不再必须相互冲突。

在实际的多模态大模型训练中，pipeline parallelism 的难点往往不只是“如何排 microbatch”，框架还必须解决一系列系统集成、接口定义、性能排查等工程问题。

BigMac 关注的正是这些从“能设计 schedule”到“能真正训起来”的系统环节。它提供了三个关键能力：把 schedule 变成可见、可检查、可执行的全局计划；流水线无感的接口，让模型开发者仍然以模块化方式编写模型代码；schedule-aware 工具链，把 profiling、simulation 和可视化接入到性能诊断闭环中。下面我们分别展开这三点。

1. 把全局 schedule 摆到明面上

先看系统集成层。BigMac 运行时的核心组件是 Scheduler 和 Executor。Scheduler 会生成一张全局 operator 表，覆盖所有 pipeline rank、microbatch 和模块类型。这张表包含 LLM forward/backward operator、encoder forward/backward operator、generator forward/backward operator，以及模块边界上所需的通信。Executor 随后解释每个 rank 上的本地 operator 序列，并把每个 operator 分发给对应后端：LLM pipeline operator 交给 Megatron Core，模态 operator 交给 encoder 或 generator runtime，数据搬运交给通信后端。

这种拆分给 BigMac 带来了两个实际优势。第一，调度策略变得可见、可检查。我们可以直接看到 encoder、LLM 和 generator 如何在所有 rank 上交错执行，而不需要从一段很长的 rank-local runtime 函数中反推出全局行为。第二，执行仍然对后端友好。LLM operator 可以继续复用 Megatron Core 等优化过的 pipeline runtime，而模态模块可以保留自己的 data-parallel、FSDP 或 optimizer 实现。Schedule 也可以在不重写模型 runtime 的情况下加入通信 operator、进行死锁检查。

更多细节建议通过 BigMac 官方的可视化工具查看。

2. 让模型代码自然接入 PP

在多模态训练里，算法工程师会不断调整 encoder、LLM、generator 的连接方式、loss 设计和数据形态。问题在于，传统 PP 系统一旦扩展到多模态，这条协作边界很容易变得模糊：一次模型结构改动可能要求重写 stage 划分和 send/recv 逻辑，系统侧的优化也可能反过来侵入模型代码。如果算法工程师每次 scale up 都要理解 PP runtime，那 BigMac 仍然不是一个好用的训练系统。BigMac 的第二个关键能力，就是对算法工程师无感的流水并行接口。

图 5：BigMac 的 pipeline-parallelism-transparent 接口示意。算法工程师描述模块边界，BigMac 在底层处理 schedule、handoff 和通信。

在这个接口下，算法工程师只需要说明每个模块生产什么、消费什么；BigMac 负责把这些模块接入全局 schedule，并在底层处理 pipeline stage、activation handoff、gradient handoff 和跨设备通信。换句话说，BigMac 让一个已经在单卡或 data-parallel 环境中验证过的多模态实验，可以更自然地扩展到 pipeline-parallel training。

3. 用 schedule-aware 工具链定位瓶颈

BigMac 的最后一个关键能力，是一套理解 schedule 结构的 profiler、simulator 和可视化工具链。对于大规模多模态流水并行训练来说，性能问题很少能只靠 iteration time 或几行日志定位：bubble 可能来自某个慢 microbatch，可能来自 encoder/generator 的运行时间波动，也可能来自一次 activation handoff、gradient handoff 或跨 rank 通信等待。工程同学真正需要的是把一次训练 iteration 拆回 operator 级别，看清楚每个 rank 在每个时间点到底在执行什么、哪里空转、哪个依赖正在阻塞后续计算。

图 6：传统性能排查通常需要下载并手动关联多个 rank 的重型 trace；BigMac PP profiler 将这些信息整理成 schedule-aware 的 pipeline 诊断流程。

BigMac executor 会记录每个 operator 的执行时间，并导出 per-rank timeline / trace，如图 7 所示。通过这个 trace，工程同学可以直接观察 encoder forward/backward、LLM forward/backward、generator forward/backward 和通信操作在不同 rank 上如何交错执行，从而判断 pipeline bubble 是由 compute imbalance、communication wait、模块 handoff，还是不合适的 microbatch grouping 引起的。

图 7：由 per-operator 执行时间生成的 pipeline trace 示例。

我们也提供了一个可交互查看的 PP Profiler trace example（https://github.com/Dots-Infra/BigMac/blob/main/assets/pp_profiler_example.json）。下载后可以直接在 Perfetto UI（https://ui.perfetto.dev/）中打开，观察不同 rank、不同 operator 之间的时间线和依赖关系。

在 profiler 之外，BigMac 还提供 simulator 来支持更快的并行策略迭代。Profiler 告诉我们当前训练为什么慢；simulator 则让我们在启动下一次昂贵训练任务之前，先尝试不同的 PP/VPP 配置、microbatch 数量、模块放置和 scheduling policy，预估它们对 bubble 和吞吐的影响。这样，并行策略优化就不再完全依赖大规模训练试错，而可以先在 schedule 层面完成快速探索。

我们在两个代表性多模训练负载（MLLM-Understanding 和 MLLM-Generation）上评估了 BigMac。

MLLM-Understanding 代表多模态理解训练，这个负载使用 Qwen3-30B-A3B 作为 LLM backbone，并使用一个 1.3B 参数的 ViT encoder。相比计算高效 baseline Optimus，BigMac 实现了 1.08x-1.1x 的训练加速；相比显存高效 baseline Megatron-DistTrain，实现了 1.6x-1.9x 的训练加速。相比 Megatron-DistTrain 的加速来自消除跨模块 pipeline 干扰。相比 Optimus 的优势更微妙：BigMac 避免了 activation 显存压力，而这种压力会随着 global batch size 增大让计算高效设计越来越昂贵。

图 8：MLLM-Understanding 训练负载上的整体性能。

显存趋势和速度提升同样重要。随着 per-GPU batch size 增加，BigMac 的 peak memory 保持稳定，类似显存高效 baseline。相比之下，Optimus 会在 LLM pipeline 期间保留 encoder activation；它的显存使用快速增长，并最终在更大的 batch size 下 OOM。

MLLM-Generation 代表同时包含理解和生成路径的训练，我们使用相同的 LLM 和 encoder，但增加了一个 20B 参数的 MMDiT generator。在这个负载上，差异变得更加明显。Generator 会让计算高效设计更难扩展，因为 LLM activation 可能需要一直保留到 generator computation 完成。在论文实验中，Optimus 在 MLLM-Generation 负载的所有测试 batch size 上都会 OOM。BigMac 通过及时运行 generator backward 并快速释放 generator 侧 activation 避免了这个问题。

图 9：MLLM-Generation 训练负载上的整体性能。

相比 Megatron-DistTrain，BigMac 在 MLLM-Generation 负载上实现了 1.5x-1.9x 的训练加速，同时保持稳定显存使用。这正是 nested pipeline 最有价值的场景：系统必须同时处理 encoder 和 generator 依赖，但又不能承受大量 activation retention 或严重 pipeline bubble。

多模态大模型训练的难点，并不只是模型更大或数据更复杂，而是不同模态模块把流水线训练限制在了一个尴尬的帕累托前沿内。BigMac 的核心是打破这个前沿。它保留 LLM pipeline 作为稳定主干，只在依赖满足且不打乱 LLM 执行顺序的位置嵌入 encoder 和 generator 计算。这样，系统既能维持 LLM 流水的计算效率，又能尽早释放模态模块的 activation。更重要的是，BigMac 不只给出一个 schedule，还把 schedule 变成可见、可检查、可执行的全局计划，并配套 PP-transparent 接口和 schedule-aware 工具链，让这一设计真正进入可开发、可调试、可部署的训练系统。

论文：

BigMac: Breaking the Pareto Frontier of Compute and Memory in Multimodal LLM Training（https://arxiv.org/abs/2605.25451）