小红书开源BigMac：如何打破多模态训练显存与速度的帕累托陷阱？
在多模态大语言模型（MLLM）迅速成为人工智能基础设施核心的当下，训练系统的瓶颈正从算法层面逐渐向系统工程层面转移。长期以来，业界在构建多模态训练流水线时，始终被困在一个经典的“帕累托前沿”困境中：追求极致的计算效率往往意味着显存占用的失控，而为了节省显存进行的激进优化，又会导致严重的计算空泡和吞吐量下降。小红书 Dots Infra 团队近期开源的 BigMac 项目，正是为了解决这一长期存在的系统性难题。它通过一种全新的“准依赖安全嵌套流水线”范式，试图在显存效率与计算速度之间找到新的平衡点，为原生多模态场景的训练提供了极具参考价值的工程解法。
多模态训练的结构性矛盾
要理解 BigMac 的价值，首先需要剖析多模态模型在训练架构上的先天复杂性。与传统的纯文本 Transformer 不同，一个典型的多模态大语言模型是由三个形态迥异的模块拼接而成的：负责将图像、音频等非结构化数据转化为嵌入向量（Embedding）的模态编码器，负责核心逻辑推理的 LLM 主干，以及负责将 LLM 输出映射回图像或语音等目标模态的生成器。
这种异构性给传统的流水线并行（Pipeline Parallelism, PP）带来了巨大挑战。业界此前主要采取两种极端策略。第一种是“计算高效”策略，即将编码器和生成器从 LLM 的主流水线中剥离出来单独运行。这种做法的优势在于，模态模块的耗时波动不会在 LLM 流水线中制造“空泡”，保证了 LLM 部分的连续计算。然而，其代价是激活显存会随着 Microbatch 数量的增加而线性膨胀，特别是在大规模生产环境中，这种显存开销往往难以承受。
第二种是“显存高效”策略，即将所有模块强行塞进同一条流水线，采用首尾阶段对齐的方式。虽然这缩短了激活的生命周期，降低了显存峰值，但一旦编码器或生成器出现任何延迟，整条 LLM 流水线就必须等待，导致严重的尾部空泡。随着模型规模的扩大，这两种设计的瓶颈都会暴露无遗：要么显存爆炸，要么算力浪费。
BigMac 的核心创新：嵌套流水线范式
BigMac 的设计哲学朴素而深刻：调度的主干，必须且只能是那条已经高度优化的 LLM 流水线。在大规模 LLM 训练中，1F1B（1 Forward, N Backward）或 Interleaved 1F1B 等调度策略已经与生产级训练栈深度绑定，替换它们成本极高且风险巨大。
BigMac 并没有试图替换 LLM 的底层调度器，而是将其视为一个固定的“底层时间线”。在此基础上，它通过一种名为“准依赖安全嵌套流水线”的技术，将编码器和生成器的计算任务，智能地插入到输入已就绪且不会打乱 LLM 执行顺序的缝隙中。这种设计带来了两个关键性质：
首先，编码器与生成器的耗时波动被隔离在 LLM 流水线之外，不再沿流水线传导。LLM 依然按照其原本优化的节奏推进，避免了因模态模块延迟导致的整体停滞。
其次，也是更为关键的一点，模态激活显存被算法层面压到了 O(1) 级别。在传统方案中，编码器必须为所有 Microbatch 保留激活直到流水线结束，生成器也拖着长长的激活尾巴。BigMac 通过精细的调度，使得编码器不必保留所有激活，生成器也能及时释放资源。这意味着，BigMac 不是在显存和空泡之间做简单的交换，而是通过改写 Schedule 的结构，从根本上解耦了这两个相互制约的目标。
工程化落地：从理论到生产
从理论上的 Schedule 设计到真正在生产环境中稳定运行，中间隔着系统集成、接口定义和性能排查等一系列工程关卡。BigMac 团队显然意识到了这一点，因此它不仅提供了一套算法，更提供了一整套工程化解决方案。
第一，BigMac 将全局 Schedule 显式化。运行时的 Scheduler 会生成一张覆盖所有 Pipeline Rank、Microbatch 和模块类型的全局 Operator 表。Executor 随后将其拆解为每个 Rank 上的本地序列，并分发给 Megatron Core 等 LLM 后端、模态 Runtime 以及通信后端。这种设计使得调度策略变得可见、可检查，且对后端高度友好。
第二，它提供了对算法工程师透明的流水并行接口。工程师只需描述每个模块的生产与消费关系，剩下的 Stage 划分、激活与梯度交接、跨设备通信等复杂细节均由 BigMac 在底层自动处理。这使得一个在单卡上验证过的多模态实验，能够更自然地扩展到流水并行环境，极大地降低了多模态训练的工程门槛。
第三，BigMac 配套了一套完整的性能剖析工具链，包括 Profiler、Simulator 和可视化工具。这套工具能够将一次训练迭代拆解回 Operator 级别，让工程师清晰地看到每个 Rank 在每个时间点究竟在计算什么、在哪里空转、哪条依赖卡住了后续流程。更重要的是，Simulator 允许工程师在启动昂贵的实际训练之前，先模拟不同的 PP 配置和 Microbatch 组合，预估其对空泡和吞吐量的影响，从而在实验前进行优化。
性能验证与生产实践
在两类具有代表性的负载上，BigMac 的性能优势得到了充分验证。在 MLLM-Understanding 任务中，使用 Qwen3-30B-A3B 作为主干，搭配 1.3B 的 ViT 编码器，BigMac 相比计算高效基线 Optimus 提速 1.08 到 1.1 倍，相比显存高效基线 Megatron-DistTrain 提速 1.6 到 1.9 倍。更关键的是显存表现：随着 Per-GPU Batch Size 的增大，BigMac 的峰值显存保持平稳，而 Optimus 因需保留编码器激活，显存一路飙升，最终在更大 Batch 下直接导致 OOM（显存溢出）。
在更复杂的 MLLM-Generation 任务中，加入了 20B 的 MMDiT 生成器，差异被进一步放大。Optimus 在所有测试 Batch Size 上均发生 OOM，而 BigMac 则依靠及时运行 Generator Backward 并快速释放生成器侧激活，成功避开了这一陷阱。相比 Megatron-DistTrain，BigMac 仍取得了 1.5 到 1.9 倍的加速，且显存依旧稳定。这正是嵌套流水线最具价值的场景：系统必须同时伺候编码器和生成器的依赖，又无法承受大量激活驻留或严重空泡。
目前，BigMac 已经作为 Dots 多模态模型训练的核心组件之一，运行在小红书的生产环境中。相关论文《BigMac: Breaking the Pareto Frontier of Compute and Memory in Multimodal LLM Training》已发布在 arXiv 上，团队也同步放出了交互式 PP Profiler 的 Trace 示例。
对于正在被多模态训练显存与速度两头夹击的研究者和工程师而言，BigMac 的开源不仅提供了一套经过生产验证的技术方案，更展示了一种通过重构调度逻辑来突破系统瓶颈的新思路。它证明了，在复杂的异构计算场景中，通过精细的依赖管理和调度优化，我们完全有可能打破传统的性能权衡，实现效率与资源的双重突破。随着多模态应用的进一步普及，这类底层基础设施的创新，将成为推动 AI 技术落地的关键力量。