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

当大多数模型公司还在围绕“是否开放权重”争论时，一个总参数达到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