跳转到内容
NextTransformer

协议总览

NextTransformer 只问一个问题：在训练预算固定时，语言模型应该如何分配它的计算？ 每个方法都在同一条数据流上训练、使用相同数量的输入 token、相同的每 token 理论训练 FLOPs，并在相同的检查点上评测。本节就是这份契约。机器可读的取值在 nexttransformer/protocol/spec.py 中，每个配置和运行记录都携带协议指纹。

一个方法的生命周期

Section titled “一个方法的生命周期”
 实现                  校准                  准入                训练                   评测                  审计               发布
 插件或内置方法  ──▶  将算力控制在     ──▶  配置           ──▶  46,875 次更新    ──▶  189 次验证 BPB   ──▶  累计算力       ──▶  运行记录
                      SSSL 锚点的 1%        （成本证明          49.152B tokens       6 次 CORE-22         与锚点相差         + 审计
                      以内                  与源码一致）        seed 42, --formal    最终 BPB             ≤ 2%               上线网站
  1. 实现：在共享外壳中实现方法（模型外壳）。
  2. 校准：调整结构，使经过审计的每输入 token 训练 FLOPs 与 SSSL 锚点相差不超过 1%（算力核算、校准与准入）。
  3. 准入配置：成本证明必须与它运行的代码以及审计所用的 PyTorch 构建一致。
  4. 训练：使用固定的数据、批量、调度和随机种子（训练）。
  5. 评测：在固定的时间点评测（数据与评测）。
  6. 审计完成的运行：所有事件齐全，累计算力相差不超过 2%（验证与续训）。
  7. 发布运行记录及其审计（结果）。

受控变量

Section titled “受控变量”
控制项 取值
数据 锁定版本的 ClimbMix；文件、内容和顺序完全相同；一个固定的验证分片
分词器 一套预先准备的 32,768-token 词表和字节表，由 SHA-256 锁定
上下文 2,048 tokens，带 BOS 的 best-fit 打包
预算 49,152,000,000 个输入 token，包含 warmup、burn-in 和每个训练阶段
批量与更新次数 每次更新 1,048,576 tokens（512 × 2,048-token 行），46,875 次更新
随机性 单一随机种子 42
算力 每输入 token 4.67239832544785 GFLOPs（SSSL 锚点）；准入时 ≤ 1%，累计 ≤ 2%
优化器 块内矩阵用 Muon，嵌入、输出头和标量用 AdamW；共用一套调度
评测 验证 BPB：第 0 步、每 250 次更新以及最后一次更新（189 次）；完整 CORE-22：8K、16K、24K、32K、40K 和 46,875（6 次）

参数量、显存、吞吐和 GPU 小时都是结果，而不是控制项。稀疏模型不必拥有更多参数，也不假设它在 2K 上下文下一定更快。

两个角色不同的基线

Section titled “两个角色不同的基线”
  • SSSL 是历史上的 dense 模型：24 个块，18 个短窗口层和 6 个全局层。它定义了冻结的算力锚点；其配置 ID、检查点键和历史分数都保持不变。
  • Dense（dense_full）在每一层都使用完整的因果多头注意力，独立校准、训练和审计。它是唯一的质量基线：排行榜上的每个 Δ 都是在同一检查点上相对它测得的。SSSL 的分数永远不会被当作 Dense 的分数。

研究模式与正式模式

Section titled “研究模式与正式模式”

python -m nexttransformer.train 默认运行在研究模式：你可以修改代码或使用别的 PyTorch 构建照常训练；训练器会记录过期或超出预算的成本证据，这样的运行永远不能发布。 排行榜运行需要传入 --formal：配置的成本证明必须与审计时的源码和 PyTorch 构建一致，并且每个训练分段都必须是正式的。

接下来

Section titled “接下来”