535B大模型“直播”训练三个月：代码、数据、Loss全公开，吴恩达公开力挺

本文来自微信公众号： AI前线 ，作者：冬梅

当大多数模型公司还在围绕“是否开放权重”争论时，一个总参数达到5350亿的大模型，选择在训练尚未完成、甚至仍可能中途失败的时候，把训练曲线、数据配方、模型配置和技术讨论直接放到了网上。

近日，斯坦福大学计算机科学副教授、基础模型研究中心（CRFM）主任Percy Liang在x上发帖宣布，开放基础模型项目Marin已于上周启动Marin 535B-A23B的训练。

按照目前公布的计划，Marin 535B-A23B将处理18.75万亿Token，其中约80%用于预训练，20%用于中期训练；训练运行在11套NVIDIA GB200 NVL72系统上，预计持续约3个月，总计算量约为2.7×1024 FLOPs，之后还将进入后训练阶段。

据Marin项目发起公告，项目最早诞生于斯坦福大学基础模型研究中心CRFM，于2025年5月正式对外公布。发起公告的作者包括David Hall、Percy Liang，以及来自斯坦福、Open Athena和开放社区的多位研究人员。

Percy Liang曾就职于对话式AI公司Semantic Machines，担任首席科学家。该公司于2018年被微软收购，相关团队后来参与微软对话系统及语音助手技术建设。

此外，他也是大模型推理云和开源AI公司Together AI的联合创始人之一。Together AI的业务包括模型训练、推理基础设施和开放模型服务。

之所以要做Marin这个项目，是因为他们想探索AI领域的一个核心问题：在算力高度集中、训练配方越来越封闭的情况下，基础模型还能不能像开源软件一样被公开研究和共同建设？

此前，市面上的一些主要开放权重，比如Llama、Gemma等模型虽然也是开源的，但用于生成这些模型的代码和数据，也就是俗称的“配方”并未公开。BLOOM、Pythia、OLMo、LLM 360等项目则进一步开放了数据、代码、日志或中间检查点。Marin承认这些项目的先行贡献，但认为，开放模型仍然缺少一套类似软件开源的协作机制。

软件开发者可以在GitHub上查看Issue、提交代码、进行Review和复现Bug，但基础模型实验通常在封闭集群中运行。

外界看到的往往是训练完成后的模型权重和技术报告，看不到研究者为什么做出某个决定，也看不到失败实验。

所以Marin提出一种“开放实验室”机制：每个实验都通过GitHub Issue提前声明目标和假设，具体配置以代码和Pull Request提交，外部研究者可以参与Review，实验启动后，W&B训练指标公开。更重要的是，在这个过程中所有成功、失败和中途修改痕迹都被记录，数据、代码、配方及最终模型继续开放。

截至目前，Marin已经训练过8B和32B模型，并开始将实验规模扩大到535B-A23B MoE模型。

Percy Liang的这条贴子在x上的浏览量突破80万，消息很快获得吴恩达转发。

吴恩达将Marin称为当前捍卫AI开放性的一次“珍贵示范”，强调该项目不仅开放模型代码，还公开数据、训练配方和实验过程。

他继续写道：“公开发布AI研究成果曾几何时是行业常态；我很感激@percyliang所坚持的开放实验室理念。”

不过，Marin目前还不是一个已经完成并可供比较的新模型。

这场实验真正引发关注的原因，不是5350亿参数本身，而是它把通常被模型公司严密保护的训练过程，变成了一个可以实时观察和审查的公开研究对象。

535B并不意味着每次都要运行535B参数

从命名上看，Marin 535B-A23B是一款混合专家模型，也就是MoE模型。

“535B”代表模型拥有约5350亿总参数，“A23B”则意味着，每处理一个Token，实际参与计算的参数约为230亿。它不是让全部5350亿参数同时工作，而是先由路由模块判断输入内容，再把Token分配给一部分专家网络。

这也是MoE近年来重新成为大模型主流技术路线的重要原因：模型可以继续扩大总容量，但单个Token的计算成本不必与总参数量同步增长。

不过，“230亿激活参数”也不能简单等同于一款23B稠密模型。

MoE除了被路由选中的专家，还包括注意力层、嵌入层、共享专家和路由模块等始终或部分参与计算的结构。不同团队对“激活参数”的统计口径也可能不同，因此比较两款MoE模型时，不能只看“A23B”，还要同时比较训练Token数、专家数量、路由方式、共享专家比例以及实际FLOPs。

Marin公开的技术说明显示，这款模型采用了共享专家与路由专家并存的设计：每层保留2个共享专家，同时激活8个路由专家；两类专家均采用半宽结构。由于路由专家还使用了2倍压缩，团队将其等效描述为：共享专家提供约一个隐藏层宽度的神经元，路由专家提供约两个隐藏层宽度的神经元。

换句话说，大约三分之一的专家计算来自始终工作的共享专家。这样设计不是为了让模型参数数字更好看，而是为了降低MoE训练中“Token丢弃”带来的风险。

训练MoE，难点不只是把模型切到更多GPU上

MoE模型的优势是计算稀疏，工程代价则是通信复杂。

当一个训练批次进入模型后，不同Token可能被路由到不同专家，而这些专家往往分散在不同GPU甚至不同机架上。系统需要先进行一次All-to-All通信，把Token发送到对应专家；专家完成计算后，还要再次把结果送回原来的计算路径。

因此，MoE训练的瓶颈不一定是GPU算力，也可能是跨卡通信、专家负载不均以及内存访问。

如果某几个专家收到的Token过多，而其他专家相对空闲，系统就会出现“热点专家”。为了避免个别GPU溢出，训练框架通常会为专家设定容量上限；超过容量的Token可能被直接丢弃，这就是Token Dropping。

Token Dropping比例过高意味着部分Token没有完整经过被选中的专家网络，可能削弱训练效果。提高专家容量可以减少丢弃，却会带来更多显存开销、计算冗余和通信等待。这是一个典型的系统与模型效果之间的权衡。

Marin团队披露，之前的实验中，当上下文长度从4K扩展到65K时，Token Dropping比例曾从约7%上升至约40%。

原因之一是：在总Token批量相对固定时，上下文越长，一个批次中包含的独立序列越少，Token分布更容易不均衡，专家之间也更难实现负载平衡。

因此，Marin 535B没有一开始就追求超长上下文，而是退回4K上下文启动预训练。

与8K相比，同样规模的Token批次可以容纳约两倍的独立序列，有助于让不同专家获得更均匀的输入。

团队测试的新型pooled/wave专家并行方案，在4K上下文下将Token Dropping降至约3%。但Marin也明确承认，这套实现仍具有实验性质，延长到65K后，丢弃比例可能再次变得过高。

这也是这场公开训练值得观察的技术问题之一：Marin不仅在训练一个大模型，也在测试一套大规模MoE通信系统能否持续稳定运行约100天。

专门为JAX手写了一套专家并行实现

Marin的训练栈主要建立在JAX、XLA和Levanter之上。

JAX负责数值计算和自动微分，XLA负责将计算图编译到底层加速器，Levanter则是Marin使用的大模型训练框架。此前，Marin 8B和32B主要运行在Google TPU上；此次535B模型转向NVIDIA GB200 NVL72，意味着团队需要重新处理GPU集群上的专家并行和通信效率问题。

Marin在公开记录中表示，由于没有找到在JAX/XLA GPU环境中性能足够好的现成专家并行方案，团队自行实现了EP，也就是Expert Parallelism。

专家并行会把不同专家放置在不同设备上。如果每张GPU只保存部分专家，模型总参数可以横跨整个集群，但每个Token必须根据路由结果在设备之间移动。其性能高度依赖All-to-All通信能否与专家计算有效重叠。

GB200 NVL72将72颗Blackwell GPU和36颗Grace CPU组织在一个机架级NVLink域中，适合运行需要大量跨卡通信的MoE模型。

从公开材料看，Marin并没有把硬件配置视作训练必然成功的保证

。项目专门预留了针对硬件故障、模型计算利用率下降和进度延误的应对方案：如果问题出现在前25%的Token预算内，团队可能缩短最终Token训练量，并重新调整线性学习率衰减和数据配比，而不是机械地维持原计划。

在535B正式开跑前，先搭一架“缩放梯”

Marin没有直接把全部算力投入535B模型，而是先训练了一组规模递增的小型MoE模型，形成一套四级Scaling Ladder，即“缩放梯”。

按照Percy Liang披露的信息，这些模型覆盖：

• 1.6B总参数、61M激活参数；

  
  

• 逐级扩大的中间模型；

  
  

• 最高27.7B总参数、约1.2B激活参数。

  
  

缩放梯的作用不是提前证明535B模型的能力，而是用较低成本检查训练配方能否随模型规模稳定扩展，并拟合损失、计算量和模型规模之间的关系。

Marin表示，这套缩放实验只占最终计算量的约1%，但能够承担几项关键任务。

首先，它可以预测535B模型在不同训练阶段应达到的损失水平。如果主训练曲线明显偏离预测值，团队就能较早判断数据、路由或优化器是否出现问题，而不必等到几万亿Token之后才发现训练失效。

其次，它可以提前暴露训练稳定性问题。Marin此前通过缩放实验发现，随着Token训练周期拉长，梯度范数一度增长到4以上。后续消融实验显示，在高Batch Size等条件下，如果不处理这个问题，训练可能在中途完全发散。

团队最终加入了logit z-loss。它通过惩罚过大的logit归一化项，限制模型输出分布的数值幅度，从而降低Softmax和路由训练过程中的数值不稳定风险。

第三，缩放梯可以帮助区分“正常波动”和“失控前兆”。Marin曾观察到，一些小模型的梯度范数会在前40%训练阶段持续上升，随后随着学习率下降而回落。如果535B模型呈现相似轨迹，团队不必立即中断训练；但如果它明显偏离小模型规律，就需要提前介入。

这相当于在大模型正式远航前，先用几艘不同尺寸的船走一遍相似航线。Scaling Law在这里不只是预测最终能力的公式，更是训练过程中的故障检测系统。

但也需要看到，缩放律只能降低不确定性，无法消除不确定性。MoE规模扩大后，网络通信、专家负载和数值稳定性可能出现小模型中不存在的新问题；从27.7B外推到535B，仍然存在接近20倍的总参数跨度。

它不是第一个直播训练的大模型

尽管Marin的开放程度很高，但这并不是“全球首个直播大模型训练过程的项目”。

2022年，由Hugging Face牵头的BigScience就在训练1760亿参数模型BLOOM期间公开了TensorBoard日志，并持续披露训练进展、系统故障和解决过程。BLOOM最终还开放了模型代码、中间检查点及ROOTS多语言数据集的相关资料。

此后的Pythia、LLM360和Ai2的OLMo系列，也进一步开放训练数据、代码、日志和中间检查点。OLMo的论文明确将Pythia和BLOOM列为此前开放程度最高的模型项目，并表示OLMo进一步发布了从数据处理到训练、评估的完整框架。

Marin官方同样没有宣称自己是第一个。

其发起公告直接列出了EleutherAI、AI2、Hugging Face、BigScience、BigCode、LLM360等先行项目，并称Marin希望“再向前一步”。

它真正不同的地方，是把开放从一次模型发布行为，扩展成实验室的默认工作方式：不是等模型训练完成后再开放整理过的材料，而是从提出假设、提交代码到训练失败都尽量实时公开。

所以这件事真正让人关注的点是：Marin不是第一个公开模型权重、训练数据和日志的项目，也不是第一个直播大模型训练曲线的实验室；但它正在进行的，可能是目前模型规模和研发透明度结合得最激进的开放训练实验之一。

现在谈“前沿性能”还太早

5350亿总参数、18.75万亿Token和2.7×1024 FLOPs，说明Marin 535B已经进入非常大规模的训练区间，但这些数字不能直接证明它会成为前沿模型。

为啥这么说？

首先，MoE的535B不能直接与535B稠密模型等价。它每个Token激活约23B参数，计算成本和模型表达能力取决于专家是否真正形成有效分工。

其次，预训练损失只说明模型对数据分布的拟合程度。代码、数学、工具调用、长上下文和Agent能力，还会受到数据质量、中期训练及后训练方法的显著影响。

再次，项目仍处于训练早期。

公开本身不能代替最终评测，也不能保证训练不会因系统或数据问题调整路线。GitHub上的项目标题目前写作“535B-A23B on 18T tokens”，而Percy Liang的对外公告使用18.75T Token口径，也说明训练计划、运行配置和传播口径仍需在后续持续对齐。

这场实验现阶段最重要的产出，可能还不是三个月后的模型权重，而是它沿途留下的训练记录。

对于无法承担同等算力成本的研究团队来说，复现整个535B模型并不现实；但专家如何路由、Token Dropping如何变化、梯度何时异常、长上下文如何扩展以及JAX如何在GB200上实现专家并行，这些经验可以被其他规模的模型复用。

过去几年，开放模型解决了“谁可以使用模型”的问题。Marin试图继续追问的是：谁有权知道模型究竟是怎样被训练出来的。

如果它最终成功，开放社区将获得一套少见的大规模MoE训练样本，当然了，如果它中途遇到问题，公开的故障路径同样具有研究价值。

参考链接：

https://github.com/marin-community/marin/issues

https://marin.community/blog/2025/05/19/announcement/