小红书开源 BigMac，挑战多模态训练中的权衡难题

小红书开源 BigMac，并提出了一个引人注目的主张：其新型训练流水线运行多模态工作负载的速度比测试基线快 1.08 到 1.9 倍，同时不会让激活内存随批次大小增长。该系统针对的是多模态模型训练中一个长期存在的矛盾。团队通常需要通过保留更多中间数据来提升速度，或者为了节省内存而接受更多 GPU 空闲时间和通信开销。

BigMac 并未引入新的基础模型。它改变的是现有多模态模型各组件在加速器集群上的调度方式。小红书的研究人员将编码器和生成器操作嵌入语言模型流水线，同时保留它们之间的依赖关系。他们将由此形成的系统称为依赖安全的嵌套式流水线。

这一区别非常重要，因为此前的系统分别解决了这个问题的不同方面。Optimus 专注于填补语言模型流水线中的空闲时段。DistTrain 将异构组件分离，使每个组件都能采用更合适的并行配置。BigMac 试图兼顾高利用率与有界激活内存，让真正的较量落在计算高效调度与内存高效调度之间。

结果令人期待，但目前仍是作者自行报告的数据。BigMac 的论文是一篇预印本，其最广泛的生产环境主张尚未得到独立的大规模集群复现。因此，它的重要性取决于两个问题：外部团队能否复现这些收益，以及他们能否在不重建训练技术栈的情况下集成该调度器？

小红书为一种不同的瓶颈开源 BigMac

BigMac 首先将多模态训练视为调度问题，其次才将其视为硬件问题。

多模态大语言模型将语言模型与特定模态的组件相结合。例如，视觉编码器会将图像转换为语言模型能够处理的表示。生成器则可以将语言模型的输出转换成图像、视频、音频或其他非文本格式。

这些组件很少以相同方式消耗计算资源。语言模型可能由大量相对统一的 transformer 层构成。视觉编码器可能具有不同的参数量、序列结构和最佳并行方案。基于扩散的生成器还会引入另一种计算模式和另一组依赖关系。

最终形成的模型就像一条各工位以不同速度运转的生产线。分配给某个组件的 GPU 可能会提前完成任务，然后等待另一个组件。这些空闲时段通常称为流水线气泡，即加速器因所需数据尚未到达而无法执行有效操作的时期。

BigMac 的研究人员认为，现有解决方案往往以一种稀缺资源换取另一种稀缺资源。调度器可以让更多任务处于运行状态并减少气泡，但保留这些任务会增加激活内存。激活值是在前向传播期间保存的中间值，因为之后的反向传播需要使用它们。

另一种做法是让系统更早释放激活值，或更激进地拆分模型组件。这种方式能够降低内存压力，但可能增加通信、同步或空闲时间。论文将这些选择描述为一条 Pareto 前沿，即提升计算效率往往会牺牲内存效率。

BigMac 的核心做法是保留原有的语言模型流水线作为调度骨架。随后，仅在依赖关系允许执行时，才将编码器和生成器操作嵌套进该骨架。调度器不会为了寻找空闲 GPU 周期而随意调整数学运算的顺序。

研究团队在 2026 年 5 月 25 日发布的 BigMac 预印本中介绍了这一结构。论文署有 11 位作者，并对多模态理解与生成工作负载进行了评估。之后，小红书通过其技术刊物将该系统作为 dots 模型团队使用的开源组件进行了介绍。

报告的性能范围需要结合背景来理解。根据对结果的详细分析，在测试设置中，BigMac 的速度比 Optimus 快 1.08 到 1.1 倍。与更注重内存的 Megatron-DistTrain 基线相比，报告的优势范围为 1.5 到 1.9 倍。

这些比较并不意味着每个训练任务都能提速 90%。较大的数字来自特定基线与工作负载的组合。硬件拓扑、模型架构、批次构成、流水线深度和通信带宽都可能改变结果。

但这一变化仍然意义重大。小红书发布了一项同时面向理解模型和包含生成组件模型的系统技术。小红书还表示，BigMac 已经超越实验室测试阶段，进入其 dots 多模态模型的生产训练流程。

多模态训练为何迫使 GPU 做出不利选择

压力来自模型异构性，而不仅仅是模型规模变大。

扩展纯文本 transformer 已经要求团队协调数据并行、张量并行、流水线并行和内存管理。多模态训练又增加了无法在统一策略下顺利拆分的组件。

流水线并行会将连续的模型层组分配给不同设备。微批次像工厂流水线上的物品一样经过这些阶段。它可以高效分布大型模型，但必须谨慎地填充和排空流水线。

视觉编码器可能在相关语言模型阶段能够使用结果之前，就完成自己的部分。生成器则必须等到语言模型产生合适的输出。在反向传播期间，梯度还必须以正确顺序返回并经过这些组件。

简单的调度器可以提前执行编码器并存储其激活值。这样能让输入为语言模型做好准备，但随着更多微批次进入流水线，存储的激活值会不断累积。增加全局批次大小便会提高峰值内存用量。

这种模式形成了一道实际的上限。团队可能拥有足以处理更大批次的算术计算能力，却没有足够的内存保留每个中间状态。缩小批次或对更多激活值执行检查点操作可以恢复可行性，但这两种选择都可能降低有效吞吐量。

Optimus 直接针对空闲时间展开攻关。其研究人员发现，编码器内核可以占用语言模型调度中的气泡。已发表的 Optimus 系统报告称，在 3,072 个 GPU 上运行 ViT-22B 与 GPT-175B 组合时，训练速度提升了 20.5% 到 21.3%。

这种方法确立了一项重要原则：异构组件并不总是需要各自独立、依次执行的时间窗口。有用的编码器工作可以插入原本空闲的时段。

然而，填补气泡并不能自动控制激活值的存活时长。如果编码器的运行远远领先于对应的反向操作，系统就会保留更多中间数据。计算利用率得到提升，内存压力却随之上升。

DistTrain 通过解耦来处理异构性。它为模型组件提供独立的资源和并行化方案，然后重新组织数据，以减少不同模态之间的不均衡。其 DistTrain 研究报告称，在 1,172 个 GPU 上运行一个 720 亿参数的多模态模型时，模型 FLOPs 利用率达到 54.7%。

同一项研究还报告称，在其评估设置中，吞吐量最高可达 Megatron-LM 的 2.2 倍。然而，解耦可能引入通信和编排成本。一个能够保护内存并适配不同组件的系统，仍可能未能充分发挥性能。

BigMac 对这两条路线都构成了挑战，因为它声称团队不再需要在二者之间做出选择。它直接对抗的不是某家公司或某个框架，而是这样一种假设：计算高效的多模态调度必然会消耗不断增长的激活内存。

这种压力也延伸到基于通用训练框架构建系统的平台团队。NVIDIA 的 Megatron Core为大型 transformer 和多模态工作负载提供分布式训练组件。使用这类基础设施的团队仍然需要能够反映其特定架构依赖关系的调度方案。

对于大型 AI 实验室而言，调度改进带来的影响不只是基准测试速度。更高的吞吐量可以缩短两次实验之间的时间。有界内存则可以让团队在现有集群上采用更大的批次、更长的序列、更重的编码器或更大的生成器。

对于只调用模型 API 的应用开发者来说，其价值没有那么直接。尽管如此，训练效率仍会影响哪些多模态能力能够投入生产。它可能决定模型团队能否承担另一次数据训练、架构测试或更高分辨率的训练阶段。

BigMac 嵌套工作，同时避免激活值不断堆积

该机制依赖于控制操作何时具备执行条件，而不仅仅是将更多内核塞入空闲时段。

BigMac 以交错式语言模型流水线为基础。交错会将多个虚拟模型分段分配给一个物理流水线阶段，使前向和反向操作能够更紧密地交替执行。语言模型既有的调度仍然是主要节拍。

调度器将编码器工作负载拆解为与语言模型输入相关联的单元。随后，它会在这些单元被使用之前，提前放置数量有限的编码器前向单元。论文分析的调度采用固定的前瞻范围，而不是允许编码器提前运行完整个批次。

这种有界领先是其内存主张的核心。编码器激活值只需保留到语言模型使用其输出，并且反向传播返回对应梯度为止。一旦满足该依赖关系，BigMac 就会立即调度编码器的反向操作。

在论文描述的交错式调度下，同时保持活跃的编码器单元数量仅为常数。研究人员将编码器的激活内存复杂度描述为 O(1)。通俗来说，相关内存不会随微批次数量成比例增长。

O(1) 并不意味着零内存。它意味着在所述调度下，同时保留的编码器激活单元数量维持在固定范围内。实际内存用量仍然取决于编码器大小、图像分辨率、序列长度、精度和实现细节。

生成器采用了类似的模式。当语言模型产生所需输出时，其前向计算便会开始。BigMac 将生成器的反向工作紧接在必要的前向依赖之后，从而防止生成器激活值在大量微批次中不断累积。

这种调度选择对于多模态生成尤其重要。大型 diffusion transformer 或类似生成器可能消耗大量内存。在执行反向传播之前连续运行多个生成器前向操作，即使语言模型本身能够装入内存，也可能耗尽加速器内存。

依赖安全机制提供了保障。每个嵌套操作都必须遵循模型的前向和反向计算图。如果填补某个看似理想的空档会使用尚未就绪的数据，或覆盖之后仍需使用的信息，调度器就不能这样做。

研究人员还声称，嵌套工作不会给原始语言模型调度增加气泡。这是该论点在计算方面的依据。BigMac 旨在保持一种假设调度的效率——该调度拥有足够内存来保留每个激活值——同时避免其不断增长的内存占用。

其报告的测试采用了一套理解任务配置，该配置围绕 Qwen3-30B-A3B 语言模型和一个拥有 13 亿参数的视觉 transformer 构建。生成工作负载还加入了一个拥有 200 亿参数的多模态扩散 transformer 生成器。

在这些评估的工作负载中，据报告，BigMac 实现了最低的迭代时间。随着批量大小增加，它仍能维持稳定的峰值内存，而以计算为重点的基线内存占用持续上升，并最终在某些生成设置中触发内存不足故障。

论文还研究了上下文并行，这种方法会将长序列拆分到多个设备上。不同的多模态组件可能适合不同的上下文并行组大小。据报告，BigMac 的解耦配置速度最高可达同构配置的 1.45 倍。

另一项实验改变了完全分片数据并行的通信方式。完全分片数据并行会将参数、梯度和优化器状态分布到各个工作节点，从而降低每台设备的内存占用。BigMac 用单边拉取机制替代了标准的集合式聚集模式，据报告，性能最高提升至 1.03 倍。

这些次要收益小于最受关注的增幅区间，但它们揭示了这项设计的雄心。BigMac 不只是在空闲时隙中插入编码器内核。它试图在一个依赖关系模型下统一协调流水线调度、组件专属并行策略和参数移动。

团队还报告了覆盖 128 次迭代的数值检查。根据论文结果，在其对比中，平均绝对损失差异保持在 0.001 以下。这项测试支持语义一致性，但无法证明其在不同模型或软件环境中都具备普遍可复现性。

生产规模的主张强于公开证据

BigMac 最重要的成果在于其生产规模，而这恰恰也是外部人士最难验证的成果。

Xiaohongshu 表示，BigMac 已在 1,536 块 NVIDIA Hopper GPU 上训练了一个拥有 3,450 亿参数的多模态模型。据报告，该训练运行持续超过 18,000 次迭代，期间损失不断下降，梯度范数保持在有限范围内。

这次部署使该项目超越了模拟器或小型实验室集群的范畴。调度系统在大规模环境中可能呈现不同的表现，因为网络争用、硬件故障、数据不平衡和集合通信会变得更难掩盖。

然而，生产证据仍由作者掌控。预印本提供了测量结果和实现细节，但尚无外部团队公开复现这次 3,450 亿参数规模的训练。已训练的生产模型及其完整运行环境并不等同于可移植的基准测试。

开源调度器也不会消除集成工作。训练栈包含自定义数据加载器、检查点格式、并行组管理、混合精度逻辑、故障恢复和监控。依赖安全的调度必须与所有这些部分正确协作。

当前设计还依赖合适的交错式流水线结构。论文中的恒定编码器前瞻量依赖与虚拟流水线并行相关的调度特性。采用不同流水线调度的团队如果不做适配，可能无法获得相同的内存上界。

工作负载平衡带来了另一项不确定性。多模态批次中的图像、视频、音频片段或文本长度很少完全一致。在受控形状下看似紧凑的调度，面对计算需求不同的真实样本时可能出现空隙。

数据感知打包可能有所帮助，但打包本身也会引入限制。样本必须被高效分组，同时不能改变优化语义或产生过多填充。论文将更广泛的调度支持和数据感知打包列为未来方向。

BigMac 优化的是系统效率，而不是模型质量。更快的迭代并不保证更好的推理、视觉理解、图像生成或对齐能力。它能为研究人员提供更多可用算力，但最终模型仍取决于数据、目标、架构和评估方式。

与 Optimus 的比较也需要同样谨慎。BigMac 相对于计算高效基线的 1.08 到 1.1 倍优势具有价值，但远小于最受关注的 1.9 倍数字。读者不应把相对于不同基线的结果混为一个普遍适用的加速主张。

相对于 Megatron-DistTrain 的 1.5 到 1.9 倍区间体现了另一种权衡。该基线通过解耦执行强调稳定的内存占用。BigMac 更大的优势表明，至少在测试条件下，嵌套调度能够挽回因保守编排而损失的性能。

此外还存在命名混淆的风险。另一个无关的 AI 项目也使用 BigMac 这一名称，指代一种通信高效的混合专家架构。Xiaohongshu 的 BigMac 是多模态训练流水线，并非该 MoE 模型结构。评估此次发布的团队应确认文档和代码仓库指向的是 2026 年的流水线论文。

因此，独立复现不应只测量原始迭代时间。可信的评估还应报告峰值内存、加速器利用率、通信量、收敛情况、故障恢复能力，以及集成所需的工程改动。

评估还应在训练语义相同的条件下进行比较。批次构成、激活检查点、数值精度和有效 token 数量必须保持一致。否则，一个看似更快的调度可能只是执行了更少的工作或保留了更少的信息。

开源发布使这些测试成为可能，但并不预先决定测试结果。对 BigMac 最有力的解读是：它是一项由公司支持、拥有异常大规模生产证据的系统成果。最保守的解读则是：它是一种专用调度方案，一旦脱离 Xiaohongshu 的技术栈，收益就会缩小。

真正的答案很可能介于这两个极端之间。其机制具体明确，也直接解决了一个已知的系统冲突。剩下的问题是，该实现能在多大范围内迁移到不同架构、集群和训练框架中。

三个信号将表明 BigMac 是否会改变多模态训练

下一阶段的重点是采用与复现，而不是另一个吸引眼球的基准测试。

第一个信号是针对 Optimus 和 DistTrain 风格配置的独立基准测试。可信的复现应至少使用一个理解任务工作负载，以及一个包含大型生成器的工作负载。测试应公开批量大小逐步增加时的迭代时间和峰值内存。

如果该测试能维持 BigMac 稳定的内存曲线和大部分速度优势，论文的核心论断将得到更有力的支持。如果在对齐软件版本和并行设置后增益消失，那么结果看起来会更依赖特定环境。

第二个信号是对更多语言模型流水线调度的支持。许多组织无法仅仅为了采用一项多模态优化而替换已经建立的调度方案。兼容非交错配置、不同的虚拟流水线大小和动态工作负载，将扩大其潜在用户群。

更广泛的调度支持将表明，依赖安全的嵌套是一种通用抽象，而不是精心调优的生产方案。即使 Xiaohongshu 继续在内部使用它，如果始终受限于单一流水线模式，也会削弱这种解读。

第三个信号是外部训练框架或模型项目中的可见采用情况。持续维护的集成、可复现的配置和公开的问题记录，将揭示该系统的实际运维难度。仅有下载量或代码仓库关注度说明不了多少问题。

成功的集成应展示用户能否在不重写调度器的情况下指定编码器、语言模型和生成器之间的依赖关系。它还应展示 BigMac 如何处理检查点恢复、不均衡批次和硬件故障。

这些信号之所以重要，是因为多模态训练在结构上正变得越来越复杂。模型日益结合视觉编码器、语言主干、扩散生成器、音频模块和路由机制。增加硬件无法消除这些部分之间的依赖关系。

Xiaohongshu 开源 BigMac 之际，效率优化正从孤立的内核转向全系统编排。更快的矩阵乘法仍然重要，但空闲的加速器和长时间存活的激活值可能会浪费内核层面的性能收益。

对于 AI 基础设施团队，眼下的行动很明确：将 BigMac 视为一个值得进行基准测试的调度设计，而不是有保证的性能倍增器。首先复现其内存曲线，然后在对组织真正重要的架构和数据分布下测量速度。

对于模型构建者，应关注输入发生变化时调度器能否保持稳定。高分辨率图像、长视频以及混合理解与生成任务的批次，将比形状统一的微基准测试更严苛地检验其假设。

对其他所有人而言，更重要的启示是，未来多模态能力的提升不会只来自更大的模型。它还将来自对每个组件何时运行、中间状态存放在何处，以及这些状态能够多快释放的精确安排。

独立团队会复现 BigMac 所宣称的平衡，还是会发现其最佳结果依赖 Xiaohongshu 的生产技术栈？这个答案将决定此次发布会成为一种可复用的训练模式，还是一项令人印象深刻但高度专用的系统成果。