当大多数模型公司还在围绕“是否开放权重”争论时，一个总参数达到 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 和开放社区的多位研究人员。

David Hall

Percy Liang

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/