Marin 深度解析：斯坦福如何把5350亿大模型训练全程直播

Marin 深度解析：斯坦福如何把5350亿大模型训练全程直播

看完你会发现，你之前对『开源大模型』的理解可能要全部更新。

当大多数模型公司还在围绕"是否开放权重"争论时，斯坦福 CRFM（基础模型研究中心）主任 Percy Liang 做了一件更极端的事：把一个 5350 亿参数的 MoE 大模型，在训练还没完成、甚至可能中途失败的时候，把训练曲线、数据配方、模型配置、技术讨论、失败实验——全部直接放到了网上。

11 套 NVIDIA GB200 NVL72 连续跑 3 个月，总计算量约 5e24 FLOPs。这是人类有史以来最昂贵的一次"公开炼丹直播"。Percy Liang 在 X 上的宣布帖浏览量突破 80 万，吴恩达转发并称之为"当前捍卫 AI 开放性的一次珍贵示范"。

这背后的开源框架，就是本文的主角：Marin。

本文提纲

  1. 开放开发：Marin 重新定义了"开源 AI"的含义
  2. 核心架构：数据 → Tokenize → 预训练 → 后训练 → 评估的全流程闭环
  3. Levanter + JAX：为什么选择 PyTorch 之外的路
  4. Executor 依赖图：像写 Makefile 一样编排大模型实验
  5. Delphi Scaling Suite：从 3e18 到 1e23 FLOPs 的可预测缩放
  6. 正在训练：Marin 535B-A23B MoE 的硬件配置与开放细节
  7. 8B / 32B 回顾：Marin 已经训练出来的模型表现如何
  8. MoE 负载均衡：Quantile Balancing 在 32B-A5B 规模的验证
  9. Iris 集群调度：异构集群上的算力编排
  10. 与 OLMo / Pythia / LLM360 的横向对比：Marin 到底多开放了什么

1. 开放开发：Marin 重新定义了"开源 AI"的含义

Marin 项目诞生于斯坦福 CRFM，2024 年 3 月创建仓库，2025 年 5 月正式对外公布，发起作者包括 David Hall、Percy Liang 以及来自斯坦福、Open Athena 和开放社区的多位研究者。截至今天，GitHub 2879 Stars、239 Forks、574 Open Issues、10216 Commits，Apache-2.0 协议，主语言 Python。

Percy Liang 在 GTC 2026 的演讲中提出了一个尖锐的类比："AI 在 2026 年的位置，相当于软件在 1999 年的位置。"开源软件从 80 年代的封闭（Unix、微软）走到 2000 年之后的全面胜利，经历了 Richard Stallman 和 Linus Torvalds 整整一代人的推动。而 AI 正在经历同样的轨迹：从 2010 年代全面开放（Transformer 等论文全部公开），到 2020 年代能力变强后开放性急剧下降。

但"开源模型"这个词本身被严重滥用了。Marin 团队将开放程度拆成了几个递进的层次：

MERMAID_BLOCK_0

  • Closed：GPT-4、Claude —— 你只能看到输入输出
  • Open Weights：Llama、Gemma —— 权重可下载，但"配方"（数据、代码、超参选择理由）不公开
  • Open Data + Code：BLOOM、OLMo —— 数据和代码公开，但实验在封闭集群运行
  • Open Logs：Pythia、LLM360 —— 中间检查点、训练日志公开
  • Open Development：Marin 想达到的层次 —— 类似 GitHub 上的软件协作

Marin 的核心主张是：开放模型至今缺少一套类似开源软件的协作机制。软件开发者可以在 GitHub 上看 Issue、提交 PR、做 Code Review、复现 Bug，但基础模型实验通常在封闭集群中运行，外界看到的往往是训练完成后的权重和技术报告，看不到研究者"为什么"做出某个决定，也看不到失败了什么。

他们解决这个问题的方式叫 "开放实验室"（Open Lab），机制如下：

  1. 每个实验提前通过 GitHub Issue 声明目标和假设
  2. 具体配置以 代码 + Pull Request 的形式提交
  3. 外部研究者可以通过 PR Review 参与讨论
  4. 实验启动后，W&B 训练指标公开，任何人实时可见
  5. 所有成功、失败、中途修改的痕迹都被保留
  6. 最终数据、代码、配方、模型权重继续开放

Issue #1337 记录了 Delphi 缩放套件的完整过程，从假设到实验到结论，整个线程长达数百条评论，是公开科学记录的一次生动实践。

2. 核心架构：大模型训练的全流程闭环

Marin 覆盖了大模型训练的完整生命周期。从原始数据到最终评估，每个阶段都有对应的模块和可验证的输出：

MERMAID_BLOCK_1

Marin 的主要关注点包括：

  • 数据策展（Data Curation）：决定哪些数据进入训练集，哪些剔除
  • 转换（Transformation）：不同格式（HTML、PDF、代码、多语言文本）的归一化
  • 过滤（Filtering）：质量打分、去重、去毒、版权敏感内容剔除
  • Tokenization：Tokenize 后的数据集分片（shard）管理
  • 预训练（Pretraining）：从零开始的大模型训练
  • 后训练（Posttraining）：中期训练、SFT、RLHF 准备
  • 评估（Evaluation）：基准测试 + 自定义评估

除了 LLM，Marin 还被用于训练音频-文本模型（Issue #1699）、DNA 序列模型（Open-Athena/marin-dna）和蛋白质折叠模型（Open-Athena/MarinFold）。社区鼓励通过 marin/experiments 目录将 Marin 作为库复用。

3. Levanter + JAX：为什么选择 PyTorch 之外的路

Marin 的训练引擎没有用 PyTorch，而是选择了 JAX + Levanter。这是 Stanford CRFM 自研的一套可复现训练框架，专门为 TPU 和大规模分布式训练优化设计。

选择 JAX 而非 PyTorch，核心权衡在于：

JAX 的优势：
- 可复现性优先：纯函数 + XLA 编译，同一份代码在多次运行中可以做到训练曲线级别的可复现（不仅仅是权重级）
- TPU 原生支持：Google TPU Research Cloud（TRC）是 Marin 的重要算力来源，JAX 对 TPU 的支持比 PyTorch XLA 成熟
- 编译期优化：XLA 融合操作可以在某些 Transformer 前向中获得 1.3~1.8x 的吞吐提升
- pjit / shard_map：原生的数据/模型/流水线混合并行注解，不需要手工组合 DDP + FSDP + TP

代价：
- 生态比 PyTorch 小，第三方 CUDA Kernel（FlashAttention、FlashInfer）需要额外适配
- JAX 2.0 之后编译模型需要 jax.jit 的显式控制，调试成本比 eager 模式的 PyTorch 高
- 国内 TPU 资源基本不可用，GPU 上 JAX 的优势不如 TPU 明显

Levanter 在 JAX 基础上提供了 Transformer 模型定义（Llama、Gemma、MoE 结构）、优化器（Adam、Sophia、Muon）、并行策略管理、Checkpoint 序列化和 WandB 集成。Marin 的所有训练脚本，包括 8B、32B 和正在进行的 535B，全部基于 Levanter 编写。

4. Executor 依赖图：像写 Makefile 一样编排实验

Marin 对"实验可复现性"的处理非常有特色：所有实验步骤（Step）以函数声明，它们之间的依赖作为参数引用传递，最后由 Executor 按拓扑序执行。这和 Bazel、Makefile 的构建思路高度一致。

官方 README 给出的 TinyStories 微型示例完整展示了这个模式：

from fray.cluster import ResourceConfig
from levanter.optim import AdamConfig
from marin.execution.lazy import lower
from marin.execution.step_runner import StepRunner
from marin.experiment.data import tokenized
from marin.experiment.train import train_lm

from experiments.llama import llama_nano
from experiments.marin_tokenizer import marin_tokenizer

# Step 1：声明一个 tokenized 数据集——此时不下载
tinystories_tokenized = tokenized(
    name="tokenized/tinystories",
    source="roneneldan/TinyStories",
    tokenizer=marin_tokenizer,
    sample_count=1000,  # 每 shard 最多 1000 条，教程级提速
)

# Step 2：声明一个训练步骤——自动依赖上一个步骤
nano_tinystories_model = train_lm(
    name="checkpoints/marin-nano-tinystories",
    version="v1",
    model=llama_nano,
    optimizer=AdamConfig(learning_rate=6e-4, weight_decay=0.1),
    datasets={tinystories_tokenized: 1.0},  # 建立依赖关系
    batch_size=4,
    seq_len=2048,
    num_train_steps=100,
    resources=ResourceConfig.with_cpu(),
)

if __name__ == "__main__":
    # StepRunner 自动按拓扑序 lower 并执行
    StepRunner().run([lower(nano_tinystories_model)])

几个关键点：

  1. 惰性求值（Lazy）：tokenized() 和 train_lm() 返回的是 handle，不是执行结果。真正的执行在 lower() 和 StepRunner.run() 阶段触发。
  2. 依赖推断：train_lm 的 datasets 参数引用了 tinystories_tokenized，Executor 自动识别出依赖并保证 tokenization 先运行。
  3. 缓存语义：成功完成的 Step 默认不重跑。只有上游输入或 Step 定义改变时才重新执行。对于动辄百万 GPU 小时的实验来说，这是省钱的关键。
  4. 资源声明：每个 Step 通过 ResourceConfig 声明需要 CPU/GPU/TPU，配合下面要讲的 Iris 调度器实现异构集群的算力分配。

运行 CPU 版的入门命令：

uv run python experiments/tutorials/train_tiny_model_cpu.py \
  --prefix local_store --force_run_failed true

GPU 版本只需要替换脚本和资源配置即可：

uv run python experiments/tutorials/train_tiny_model_gpu.py \
  --prefix local_store

5. Delphi Scaling Suite：从 3e18 到 1e23 FLOPs 的可预测缩放

Marin 在 2025 年 H2 发布了最重要的研究成果之一：Delphi 缩放套件，灵感来源于 EleutherAI 的 Pythia 项目。Delphi 的目标是，用一系列从小规模到大模型的系统性实验，推导出一条可以"外推 300 倍"的 Scaling Law，用以预测大模型训练的最终表现。

三个组成部分

1. 缩放配方（Scaling Recipe）
一个名为 CompletedAdamHParams 的 Python 类，封装了从计算预算（FLOPs）到模型配置（层数、维度、头数、Batch Size、学习率、训练步数）的映射。代码直接放在 Marin 仓库中可 fork。

2. 缩放套件训练（Scaling Suite）
覆盖 3e18 到 1e23 FLOPs（相差约 5 个数量级）的完整模型矩阵，在 Google TPU Research Cloud 上全部训练完毕。每一次运行的 checkpoint 都发布在 Hugging Face marin-community/delphi collection 中。

3. 缩放定律（Scaling Law）
使用 Delphi 的小模型系列训练曲线，拟合出一条能外推 300 倍的 Loss 预测曲线。Open Athena 博客 Scaling Laws That Extrapolate 300× Past the Fit 详细展示了结果和方法。

公开了什么（全部可下载、可复现）

输出物 位置 说明
Checkpoints Hugging Face marin-community/delphi 每个大小模型的完整训练过程 checkpoint
训练混合流水线 Marin repo experiments/pretraining_datasets/nemotron.py 从 Nemotron-CC、StarCoderData、ProofPile 2 确定性还原的代码
Recipe 代码 Marin repo CompletedAdamHParams 可 fork 的超参类
方法论文档 Marin repo docs/recipes/add_scaling_heuristic.md add_scaling_heuristic Agent Skill，描述如何添加新的缩放启发式
绘图数据 Hugging Face marin-community/delphi-blog-data 每行一个 wandb_url，可直接复现 Delphi 论文中的图

这一整套东西的意义在于：其他团队训练大模型时，不再需要盲目地试超参数，可以直接用 Delphi 拟合出来的公式预测某个规模下的 Loss，在分配算力前就知道大致能达到什么水平。

6. 正在训练：Marin 535B-A23B MoE 的硬件配置与开放细节

Marin 目前的核心目标是从头预训练并完成后训练一款 MoE 模型：Marin 535B-A23B。名字的含义是：

  • 535B：总参数 5350 亿（所有专家网络累加）
  • A23B：每处理一个 Token，实际激活（参与计算）的参数约 230 亿

这不是让 5350 亿参数同时工作，而是先由 Router 判断输入内容，再把 Token 分配给一部分专家网络。这也是 MoE 近年来重新成为前沿路线的核心原因：总容量可以继续扩大，但单 Token 计算成本不必同比增长。

关键数字

  • 总计算量：约 5e24 FLOPs（5000 亿亿次）
  • 训练 Token：18.75 万亿 Token，其中 ~80% 预训练，~20% 中期训练
  • 硬件：11 套 NVIDIA GB200 NVL72 系统
  • 预计时长：约 3 个月（从 2026 年 8 月中旬启动）
  • 后续：训练完预训练阶段后还将进入后训练阶段

公开了什么

这可能是人类第一次把 frontier 级别的大模型训练做到如此透明：

  • 训练 Loss 曲线：W&B 实时公开，任何人可以看收敛是否正常、是否出现 spike
  • 数据混合配方：来自 Nemotron-CC + StarCoderData + ProofPile 2 的确定性混合代码，任何人可以用同样种子生成同样训练数据
  • 模型架构细节：层数、专家数、共享专家比例、激活函数、RoPE 配置等全部在 Issue 和代码中可查
  • 决策讨论：遇到的路由负载失衡问题、专家 quantile balancing 选择、学习率 schedule 调整——都在公开 Issue/PR 线程里讨论
  • 失败记录：如果训练中途出问题（Loss 发散、硬件故障导致 checkpoint 损坏），这些记录也会保留在公开历史中

Percy Liang 自己也承认这是一次高风险实验："训练可能失败，也可能达不到预期效果。但如果成功了，大家不仅能看到结果，也能完整看到成功是怎么一步步来的。"

7. 8B / 32B 回顾：Marin 已经训练出来的模型表现

在冲击 535B 之前，Marin 团队已经用同一套框架训练过两款稠密模型，作为技术验证：

Marin 8B

训练脚本在 experiments/tootsie/exp600_tootsie.py。官方 retrospective 报告中，Marin 8B 在他们的 base-model benchmark suite 上超过了 Llama 3.1 8B。

训练后报告（docs/reports/marin-8b-retro.md）详细记录了：
- 数据混合各来源的比例和贡献分析
- 训练过程中发现的 3 个问题（Tokenize 质量、LR schedule、代码数据比例）以及对应的修复
- 与 Llama 3.1 8B 在 12+ 个基准上的逐项对比
- 哪些实验成功了，哪些失败了，以及为什么

Marin 32B

更大规模的验证模型，回顾报告在 docs/reports/marin-32b-retro.md。这个模型是 Delphi 缩放定律验证的重要一环——Delphi 的预测结果和 32B 真实训练结果吻合度很高，给团队继续冲 535B 提供了信心。

有意思的是，retro 文件中不仅有"成功经验"，也详细列了"踩过的坑"。比如某次 run 使用了不恰当的 tokenizer vocab，跑了 1/3 才发现损失异常高，只能舍弃重来。这些"浪费钱"的记录，恰恰是 Marin 最珍贵的内容——其他闭源项目绝不会公开这种信息。

8. MoE 负载均衡：Quantile Balancing 在 32B-A5B 规模的验证

训练 MoE 最大的工程挑战之一，是专家负载均衡。如果 Router 总是把 Token 路由到少数几个专家，其他专家空闲，就会出现：
- 部分专家过拟合，其余欠拟合
- 最终模型效果和用一个更小的稠密模型差不多
- 每次前向的延迟波动大，部分专家显存成为瓶颈

常见的专家负载均衡方案（auxiliary loss、capacity factor、sinkhorn balancing）在小模型上有效，但到了 >1e22 FLOPs 规模会出问题。Marin 团队提出并验证了一种叫 Quantile Balancing 的方法，在 32B-A5B MoE（1e22 FLOPs）规模上通过了生产级验证。

核心思路是：不再让 Router 直接输出 softmax 后选 top-k，而是对每个专家的路由得分做分位数归一化——使得每个专家收到的 Token 数在分布上趋于一致，而不是用辅助 loss 的惩罚项间接引导。

实际运行结果：32B-A5B 上专家负载标准差从传统方法的 20%+ 降到 3% 以内，同时最终 benchmark 分数提升 ~1.5 个百分点。完整的数学推导、消融实验和 W&B 数据发布在 Open Athena 博客 Mixture of Experts Quantile Balancing。

这个方法如今直接用在正在训练的 535B-A23B 上。这也体现了 Marin 的开放开发流程：先在较小的 32B MoE 上以 GitHub Issue 公开讨论 → 实验 → 公开 W&B 数据 → 社区 review → 复现验证 → 代码合入主分支 → 再在更大的 535B 上使用。

9. Iris 集群调度：异构集群上的算力编排

训练 Marin 535B-A23B 需要的 11 套 GB200 NVL72 系统，并不是放在同一个完美同构的集群里。实际的训练集群通常由不同时期采购的硬件组成：一部分是 NVIDIA GB200、一部分是 H100、还有 TPU 资源穿插使用。如何在这样的异构环境上编排训练 Job，是另一个开源的重要部分。

Marin 团队开发了名为 Iris 的集群调度器，专门解决以下问题：

  • Job 依赖调度：tokenize → pretrain → eval → posttrain 各阶段之间的依赖（和 Marin StepRunner 的依赖图对应）
  • 异构资源匹配：某个 Job 声明需要"4 节点 GB200，互联 NVLink"，另一个声明"8 节点 H100，普通 Infiniband 即可"，Iris 在可用资源池中自动匹配
  • 抢占与再调度：高优先级的训练 Job 可以抢占低优先级的 eval Job，被抢占的 Job 从最近的 checkpoint 自动恢复
  • 故障自愈：某个节点出问题，Iris 自动检测并重新提交受影响的 Step

详细设计发布在 Open Athena 博客 Cluster Scheduling with Iris。这篇文章包含了调度算法伪代码、实际 Job 队列快照、以及一次真实故障（一台 GB200 节点掉卡）的完整处理日志，对于任何需要管理多节点训练集群的团队都是一手资料。

10. 与 OLMo / Pythia / LLM360 的横向对比：Marin 到底多开放了什么

市面上并非没有开放训练的大模型。下表把 Marin 和几个最具代表性的开放项目做了对比：

维度 Llama 3 Pythia OLMo 3 LLM360 Marin
权重开放 ✅ ✅ ✅ ✅ ✅
训练代码开放 ❌ ✅ ✅ ✅ ✅
训练数据公开 ❌ 部分 ✅ ✅ ✅ 可复现
中间 Checkpoints ❌ ✅ ✅ ✅ ✅
训练日志实时公开 ❌ 事后 部分 事后 ✅ W&B 实时
失败实验记录 ❌ ❌ ❌ ❌ ✅ GitHub Issue
决策过程公开 ❌ ❌ 部分 ❌ ✅ PR Review
社区贡献机制 ❌ 有限 有限 有限 ✅ Issue+PR
Scaling Law 完整公开 ❌ 部分 有 部分 ✅ Delphi 全套
Agent Skill 辅助开发 N/A N/A N/A N/A ✅ .agents/skills/

最关键的差别在最后几行：Marin 不仅公开产物，也公开过程——包括"决策为什么这么做"、"哪些选择被证明是错误的"、"社区如何参与 Review"。这是开源软件协作模式第一次系统性地迁移到大模型训练领域。

Marin 仓库本身就是最好的证据：根目录下有 .agents/skills/ 和 .claude/skills/，里面包含可加载的 Agent Skill（比如 add-dataset/ 用于添加数据集，add_scaling_heuristic 用于添加缩放启发式）。即使是"训练大模型"这种看起来高度依赖人类专家经验的工作，Marin 也在尝试把它模块化、自动化、开放化到 AI Agent 可以直接参与的程度。

Percy Liang 在 GTC 演讲的结尾引用了 HBS 的一项研究：开源软件迄今为全球经济节约了 8.8 万亿美元。他想证明的是：AI 也可以、也必须走出同样一条路，否则最终所有好处都会集中在少数几家算力和数据都集中的公司手里。

Marin 目前还不是一个"可以拿来和 GPT-4o 跑分比较"的成熟模型。它最有价值的产出，不是某个 checkpoint 的 MMLU 分数，而是证明了即使是前沿规模的大模型训练，也可以像 Linux Kernel 一样，通过 Issue、PR、Review、公开日志、社区贡献的方式推进。如果这条路被证明可行，那么下一次再出现一个 1000B 参数的模型时，我们讨论的就不会是"它要不要开放权重"，而是"每一个训练步骤、每一个决策、每一次失败，都理所当然应该公开"。

参考文档与链接

你怎么看这种"全程直播式"的大模型训练？觉得这是未来的方向，还是不切实际的理想主义？评论区聊聊你的判断。

作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

本文首发于 AI人工智能时代，转载请注明出处。

posted @ 2026-09-01 08:14  iTech  阅读(26)  评论(0)    收藏  举报