把 GPT-2 的训练租金估算从 4.3 万美元压到 40 美元：nanochat「time-to-GPT-2」排行榜背后的成本算术与工程堆栈 - 技术文章

2019 年初，OpenAI 训练 GPT-2 最大的那个 checkpoint（约 15 亿参数）是一笔正经的基建开销：32 块 TPU v3 跑上整整一周。时间锚点先钉清：OpenAI 在 2019 年 2 月 14 日公布 GPT-2（当时未放出最大模型），最大的 1.5B checkpoint 到 2019 年 11 月 5 日才公开发布；训练发生在公布之前。

Karpathy 在 nanochat 仓库的讨论帖里给这笔账做了还原：按当年每小时 8 美元的 TPU v3 租用价，总账单约 43,000 美元。注意口径：这是按历史租价还原的估算，只含加速器租金，不是实际付款账单，也不含数据、人力与失败实验。

2026 年 1 月 29 日，同一座「能力里程碑」被 nanochat 用一台 8×H100 节点在 3.04 小时内越过；按 README 的同一时价口径（约每 GPU 每小时 3 美元、节点约每小时 24 美元）折算约合 73 美元——同样是「仅加速器租金」的估算。

这里的能力里程碑有明确定义：DCLM 论文评测体系中的 CORE 聚合分，GPT-2 的得分是 0.256525。先打预防针：越过这条线只代表这组基准达标，不代表全面复现 GPT-2（后文边界一节还会展开）。

到 2026 年 3 月 14 日，nanochat 仓库 README 维护的「time-to-GPT-2」排行榜纪录已经是 1.65 小时，约合 40 美元（同一租金口径折算）。计时对象也要先说清：排行榜的时间是「在一台 8×H100 节点上越过 CORE 线的纯训练迭代时间」（dev/LEADERBOARD.md 口径：排除评测与日志），168 小时是 2019 年的训练时长，两者是各自口径下「达到同一能力所需的时间」，并非严格同边界测量。

七年，接近三个数量级的成本压缩。

这篇文章要做的事情不是复述「AI 进步好快」，而是把这 600 到 1000 倍拆开。

哪一部分来自硬件代差，哪一部分来自软件与算法，哪一部分来自数据，哪一部分来自「用一个 AI 代理自动迭代训练配方」，每一层我们都要落到具体数字上。

所有数字都给出来源，能复算的我们都当场复算一遍。

先给结论的速览。

硬件（TPU v3 到 H100）贡献了接近一个数量级的单卡算力跃升（TPU v3 单 chip 峰值 123 TFLOPS bf16，Google 官方文档口径；H100 为 989 TFLOPS bf16 稠密，约 8 倍）。

软件栈（FlashAttention 3 注意力内核、torch.compile 编译优化、fp8 低精度训练）把有效利用率顶了上去。

优化器与架构（Muon 矩阵优化器、现代归一化）减少了达到同一 loss 所需的步数。

而排行榜后半程最大的单项收益来自数据：把训练集从 FineWeb-Edu 换成 NVIDIA 的 ClimbMix，一次砍掉约 27% 的墙钟时间。

最后两轮提速甚至不是人做的：一个 autoresearch 自动实验代理在特性分支上自动试错、自动合并有效改动。

一个 43,000 美元的锚点：先把 2019 年的账算实

任何「成本下降 N 倍」的说法，都得先钉死比值的两端：本文统一用「历史成本 ÷ 现代成本」。

被除数（历史端）是 GPT-2 当年的训练账单。

Karpathy 在 2026 年 2 月 1 日的讨论帖《Beating GPT-2 for <<$100: the nanochat journey》里给出的还原如下：

硬件：32 块 TPU v3 芯片（帖原文写作「256 TPU v3 cores, 8 cores per chip」；Google 官方架构文档的核数口径与此不一致，本文按被引帖转述）；
时长：「一周多一点」，按 168 小时计；
单价：2019 年 TPU v3 云端租用价每小时 8 美元；
出处：帖子里注明参考了 2019 年的 Reddit 讨论串与 HuggingFace 模型卡。

于是总账是一笔三因子乘法（单位：块 × 小时 × 美元每小时）：

C_{2019} = 32 \times 168 \times 8 = 43{,}008

即约 43,000 美元。

这个数字就是 nanochat 排行榜第 0 行的锚：2019 年 OpenAI 原始 checkpoint，墙钟 168 小时，CORE 得分 0.2565。

注意它只算了加速器租金，不含数据、人力与实验损耗。

本文后面所有的「成本」都沿用这个口径（只算加速器租金），并在边界一节讨论这个口径的局限。

除数（现代端）这边，nanochat 的时价口径写在 README 里：约每 GPU 每小时 3 美元的市场价（README 口径，本文 2026-10-16 抓取），一台 8×H100 节点约每小时 24 美元。

于是 2026 年 1 月 29 日的基线纪录 3.04 小时对应（单位：小时 × 美元每小时）：

C_{2026\text{-}01} = 3.04 \times 24 = 72.96 \approx 73

即约 73 美元——与 Karpathy 帖中直接给出的 73 美元一致（帖口径；本文复算 3.04×24=72.96 吻合）。

锚点与纪录都钉死后，「600 倍」就不是修辞，而是除法：

\frac{C_{2019}}{C_{2026\text{-}01}} = \frac{43{,}008}{72.96} \approx 589 \approx 600\times

到 2026 年 3 月 14 日的纪录 1.65 小时，成本是 1.65 × 24 = 39.6 美元，同一口径下：

\frac{C_{2019}}{C_{2026\text{-}03}} = \frac{43{,}008}{39.6} \approx 1086\times

如果把这个下降当成一条指数曲线来拟合，从 2019 年 2 月到 2026 年 1 月约 7 年，年均衰减因子是：

f = \left(\frac{72.96}{43{,}008}\right)^{1/7} \approx 0.40

也就是「达到 GPT-2 能力的成本每年降到上一年的约 40%」，等价于每年便宜约 2.5 倍。

这与 Karpathy 本人在讨论帖里给出的口径一致：他写的是「每年降到约 40%」，并补了一句「我认为这很可能仍是低估」。

要注意这条曲线只有首尾两个实测锚点，中间不是连续观测。

它是一阶近似，不是预测模型。

符号与约定

下文要用到的符号和术语集中在这里，后文直接使用不再逐个展开：

符号 / 术语	含义	取值或出处
$N$	模型参数量	单位：个
$D$	训练消耗的 token 总量	单位：token
$F$	训练总计算量	单位：FLOPs
$C$	训练租金估算（仅加速器租金）	单位：美元
$P_{node}$	8×H100 节点的 BF16 稠密峰值算力	7.912×10^15 FLOP/s（自算）
$T$	墙钟时间	单位：秒
$f$	年均成本衰减因子	约 0.40（自算）
CORE	DCLM 评测体系中的聚合分（越高越好）；nanochat 采用其中 22 项高质量基准的聚合（DCLM 全套含 53 项下游评测）	GPT-2 = 0.256525
val_bpb	验证集 bits per byte，与词表大小无关的 loss 单位	nanochat 排行榜列
MFU	Model FLOPs Utilization；本文口径：训练 FLOPs 估算值 ÷（墙钟 × BF16 稠密峰值算力），是估算比值，不是硬件监控利用率	本文自行推导
ratio	目标数据参数比；nanochat 口径乘的是「非嵌入 scaling 参数」（transformer_matrices + lm_head），与 Chinchilla 的全参数口径不同	speedrun.sh 注释称计算最优 10.5、当前脚本取 8
TPU v3	Google 的云端 TPU，GPT-2 的训练硬件	2019 年租价每小时 8 美元
H100	NVIDIA Hopper 数据中心 GPU，BF16 张量核峰值 989 TFLOPS（稠密；NVIDIA 官网另列稀疏口径 1,979 TFLOPS）	8 卡节点约每小时 24 美元
fp8	8 位浮点训练精度，H100 张量核原生支持	排行榜第 2 行
Muon	矩阵参数用的正交化动量优化器，nanochat 与 modded-nanogpt 的核心组件之一	详见文末来源
speedrun	nanochat 的「GPT-2 速通」：从空节点到能对话的 GPT-2 级模型的最小全流程	runs/speedrun.sh
miniseries	nanochat 用单一 depth 旋钮扫出来的计算最优模型家族	runs/miniseries.sh
bpb	bits per byte；train/val bpb 分别指训练集/验证集上的值，越低越好	nanochat 排行榜列 val_bpb
depth	单一复杂度旋钮：Transformer 层数；d12/d24/d26/d32 即 12/24/26/32 层	runs/speedrun.sh
BF16	bfloat16，16 位脑浮点精度；FLOPs 是计算量（次），FLOP/s 是速率（次/秒）	H100 张量核原生

nanochat 是什么：一个旋钮控制整个模型家族

nanochat 是 Karpathy 的单机 LLM 实验台，仓库创建于 2025-10-13（GitHub API 口径），同日他发布了原始介绍帖（仓库 discussions #1，README 指南列表口径）。

GitHub API 显示仓库创建于该日；截至本文核验时（2026-10-16）约 5.86 万 star，最近一次提交在 2026 年 9 月 7 日。

它的自我定位是「最简单的 LLM 训练实验线」：在一台 GPU 节点上覆盖分词、预训练、微调、评测、推理全部阶段，代码刻意保持极小、无配置怪物。

README 的原话是：没有巨型配置对象、没有模型工厂、没有 if-else 怪兽，就是一个内聚的、可读的、可 fork 的强基线。

它最有意思的设计是单一复杂度旋钮。

整个模型家族只由一个整数决定：Transformer 层数 --depth。

宽度、头数、学习率、训练时长、权重衰减，全部由内置的缩放规则自动算出。

目标是让每个深度都落在「计算最优」点上。

GPT-2 能力恰好落在大约 d24 到 d26 的深度区间（README 口径）。

用户不需要思考任何超参数，只是在要一个「更大或更小的模型」时转动这一个旋钮。

这个「自动计算最优」背后是一个标定好的数据参数比。

runs/speedrun.sh 里当前的预训练命令是（注意：这是 2026-10-16 所核当前 master 的脚本，含 fp8 与 ratio 8，不是 2026-01-29 基线那次实验的历史命令）：

torchrun --standalone --nproc_per_node=8 -m scripts.base_train -- \
    --depth=24 --target-param-data-ratio=8 --device-batch-size=16 --fp8 --run=$WANDB_RUN

两个细节值得停下来看。

第一，作者声明的计算最优比是 10.5（speedrun.sh 注释：「decrease data:params ratio from compute optimal 10.5 (default) to 8」；dev/LEADERBOARD.md 同口径）。注意当前 base_train.py 的参数默认值实为 12（help 注明 Chinchilla=20），两处官方文本略有出入，本文以 speedrun.sh 与 LEADERBOARD 声明的 10.5 为「作者口径的计算最优比」。

而 speedrun 故意降到 8，也就是故意欠训练。

原因很直接：排行榜比的是「最短时间越过 CORE 线」，不是「把每一分算力榨干」。

欠训练意味着用更少的 token、更短的时间压线达标，这正是 speedrun 语义下的理性选择。要限定一句：这是针对「特定模型规模 + 压线达标目标」的配方选择，不是说欠训练天然更高效——要榨干算力时，10.5 的默认比才是答案。

第二，10.5 这个最优比本身只有 Chinchilla 文献口径的一半左右（还要注意两边参数口径不同：Chinchilla 按全部参数计，nanochat 的 ratio 只乘非嵌入 scaling 参数）。

Chinchilla（Hoffmann 等，论文 2022-03-29 首投）用 400 个 70M 到 16B 的模型标定出「token 数应与参数量等比放缩」，对应约 20 token 每参数。

这不是矛盾：最优比依赖架构、数据质量与优化器。

nanochat 用自己的 runs/scaling_laws.sh 在自家堆栈上重新标定过。

这本身就是一个信号：Muon 加现代配方改变了「算力该怎么花」的答案。

此句为本文基于两份来源的解读，非任何一方的原文结论。

speedrun 全流程：一条命令背后发生了什么

下面这张图说明了 speedrun 一条命令背后实际发生的全部阶段（据 runs/speedrun.sh 逐步整理）：

flowchart TD
    A["下载 8 个数据分片<br/>每片约 2.5 亿字符"] --> B["训练 BPE 分词器<br/>词表 2 的 15 次方 = 32768"]
    A2["后台并行下载到 170 片"] --> C
    B --> C["预训练 base_train<br/>d24 · fp8 · Muon · ratio 8"]
    C --> D["base_eval：CORE 分数 + bpb"]
    D --> E["chat_sft：对话格式与工具调用"]
    E --> F["chat_eval：SFT 后评测"]
    F --> G["chat_cli：命令行对话"]

逐个阶段看，脚本里的安排颇有工程味道。

第一步是数据：先下载 8 个分片，每片约 2.5 亿字符，压缩后每片约 100MB，共约 800MB 落盘。

与此同时，脚本立刻在后台继续下载到 170 片（注释：GPT-2 级预训练约需 150 片，加 20 片余量；dev/LEADERBOARD.md §Run 4 的复现要求也是「至少 150 片」），下载与分词器训练并行，不浪费墙钟。

第二步是分词器：GPT-4 风格的 BPE（见 nanochat/tokenizer.py 与 scripts/tok_train.py）在约 20 亿字符上训练，词表大小 2 的 15 次方，即 32,768。

随后立刻跑 tok_eval 报告压缩率——分词器质量直接决定同样文本折算成多少 token，也就是决定训练账单的大小。

第三步是预训练本体：等数据下载完成后启动 d24 训练，开 fp8，ratio 8。

第四步是评测：base_eval 算出 CORE 分数与 train/val 的 bpb，并抽样本看生成质量。

第五步是 SFT：chat_sft 教模型对话格式的特殊 token、工具调用与选择题作答。

第六步是 SFT 后评测，最后可以用 chat_cli 直接和模型对话。

README 还给了一个诚实的预期管理：speedrun 模型的对话水平「像幼儿园小孩」。

它会把瑞利散射解释成「空气中的蓝色小粒子折射阳光」，写的诗会陷入自我重复。

这恰恰是这个里程碑的正确定位：它越过的是一组学术基准的聚合线，不是产品可用性的线。

数据量也值得一个数。

每个分片约 2.5 亿字符，170 片即约（单位：字符）：

170 \times 2.5 \times 10^{8} = 4.25 \times 10^{10}

即 425 亿字符。

按英文网页文本约每 token 4 字符估算（本文自行推导的粗口径），约合 100 亿 token 的下载量。注意这里有三个同量纲但指称不同的概念，必须就地分开。

一是本次下载量（刚才这个约百亿 token 的粗估）；二是本次训练实际消耗的 token 量（当前脚本 ratio=8，后文按官方配置估算为约 58.4 亿）。

三是上游语料库的全量规模：ClimbMix 4000 亿 token、FineWeb-Edu 1.3 万亿 token，都远大于单次训练读入的量。

语料库是「货架」，单次训练吃掉的是「购物车里的一小部分」。

还要交代计量口径：数据集标称 token 与本文按字符粗估的 token 未必用同一分词器统计。

所以这里的比较只看规模量级，不是统一分词后的精确比值。

FLOPs 账：4×10^19 是什么概念

README 里有一句很容易被略过的话：speedrun 产出的是「a 4e19 FLOPs capability model」。更精确的官方记录在 dev/LEADERBOARD.md §Run 1：total_training_flops = 4.330784131228946×10^19、total_training_time = 10,949.46713 秒、core_metric = 0.25851、step 16704。这就是 2026-01-29 基线行的原始记录。

模型规模的官方数字同样在一手材料里：discussions/481 的「The Jan 29 Model: Architecture Deep Dive」给出 d24 = 24 层 / 1536 通道 / 12 头，总参数 1,384,124,976（约 13.8 亿）。

稠密 Transformer 预训练的经典近似是 6ND 模型：每个 token 前向加反向约消耗 $6N$ 次浮点运算。nanochat 的 ratio 乘的正是这类「非嵌入 scaling 参数」（dev/LEADERBOARD.md 口径的非嵌入参数：transformer_matrices 679,481,856 加 lm_head 50,331,648，合计 729,813,504，本文按 481 帖公布的分项相加）。

于是总计算量：

F \approx 6 \cdot N \cdot D

Run 1（2026-01-29 基线行）的启动命令用 ratio 12（dev/LEADERBOARD.md §Run 1），于是训练 token 量：

D = 12 \times 729{,}813{,}504 \approx 8.76 \times 10^{9}

官方记录的总 FLOPs 是 4.330784131228946×10^19（§Run 1 的 wandb 摘要），于是每 token 计算量（本文自行推导）：

\frac{4.3308 \times 10^{19}}{8.76 \times 10^{9}} \approx 4.95 \times 10^{9}

单位是 FLOPs 每 token。

即每 token 约 4.95×10^9 FLOPs，约为 scaling 参数的 6.8 倍——比 6N 近似的 6 倍略高，多出的部分来自注意力项与嵌入相关计算（本文自行推导）。

合计校验：4.95×10^9 × 8.76×10^9 ≈ 4.33×10^19，与官方记录吻合。

约 87.6 亿 token 的训练消耗与上一节「170 片约百亿 token 下载量」在量级上自洽（下载略多于消耗，留有余量）。

作为对照，GPT-2 最大 checkpoint 约 15 亿参数。

nanochat d24 的总参数约 13.8 亿，与 GPT-2 的约 15 亿属同一量级——越过同一条 CORE 线靠的不是缩小模型，而是数据质量与配方进步。

当然，CORE 线本身只测一组聚合基准，不等价于全面对标，这一点边界一节还会展开。

接下来是利用率。

8 张 H100 的 BF16 稠密峰值算力合计（NVIDIA 官网口径：单卡 989 TFLOPS；单位：FLOP/s）：

P_{node} = 8 \times 989 \times 10^{12} = 7.912 \times 10^{15}

以排行榜第 1 行（2026-01-29，3.04 小时）为基线。

排行榜的 total_training_time 官方定义为「仅训练迭代、排除评测与日志」（dev/LEADERBOARD.md），Run 1 记录为 10,949.467 秒。基线 MFU（本文估算口径：官方记录 FLOPs ÷（纯训练时间 × BF16 稠密峰值））：

\text{MFU} = \frac{F}{T \cdot P_{node}} = \frac{4.3308 \times 10^{19}}{10949.467 \times 7.912 \times 10^{15}} \approx 50\%

50% 是一个相当健康但不夸张的数字。

单节点 8 卡、十余亿参数的模型，一半左右的 MFU 落在典型工程区间（此区间判断为本文工程经验口径）。

再看纪录行（2026-03-14，1.65 小时，即 5,940 秒）。

dev/LEADERBOARD.md §Run 6 写明：启动命令与 Run 4 完全相同、仅 ratio 改为 8，于是训练 token 量约为：

D = 8 \times 729{,}813{,}504 \approx 5.84 \times 10^{9}

按 Run 1 的每 token 计算量线性折算（忽略 autoresearch 两轮架构改动——如 smear 的 early fusion——带来的额外计算，故为下限估算；本文自行推导）：

F_{Run6} \approx 4.95 \times 10^{9} \times 5.84 \times 10^{9} \approx 2.9 \times 10^{19}

\text{MFU}_{Run6} \approx \frac{2.9 \times 10^{19}}{5940 \times 7.912 \times 10^{15}} \approx 61\%

也就是说，从基线到纪录，越过 CORE 线所需 FLOPs 从 4.33×10^19 降到约 2.9×10^19（降约三分之一）。

MFU 同时从约 50% 升到约 61%（均为本文按官方口径的估算）。

后期的提速因而是双轮驱动：「算得更少」（FLOPs 约减三分之一）的贡献大于「算得更快」（MFU 相对提升约 22%）。

更好的数据让每个 token 更有营养，更好的配方让每一步走得更远——这正是下一节逐行拆排行榜时要反复看到的模式。

排行榜逐行拆解：每一行是什么优化

nanochat README 维护的 time-to-GPT-2 排行榜（核验于 2026-10-16 的 master 分支）目前共 7 行。

这张图说明了从 168 小时到 1.65 小时的演进路径与每步的来源：

flowchart LR
    R0["0 · 2019<br/>168 小时<br/>OpenAI 原始 GPT-2"] --> R1["1 · 2026-01-29<br/>3.04 小时<br/>d24 基线"]
    R1 --> R2["2 · 2026-02-02<br/>2.91 小时<br/>开启 fp8"]
    R2 --> R3["3 · 2026-02-05<br/>2.76 小时<br/>总批量提到 100 万 token"]
    R3 --> R4["4 · 2026-03-04<br/>2.02 小时<br/>数据集换 ClimbMix"]
    R4 --> R5["5 · 2026-03-09<br/>1.80 小时<br/>autoresearch 第 1 轮"]
    R5 --> R6["6 · 2026-03-14<br/>1.65 小时<br/>autoresearch 第 2 轮"]

逐行看，百分比降幅为本文按排行榜数字自行计算。

第 1 行到第 2 行，引入 fp8：3.04 降到 2.91 小时，降约 4.3%（4.3% 是作者在 dev/LEADERBOARD.md §Run 2 的自己计算；注意同行还做了 d24→d26 与 ratio 12→8.5 的调整，不能全部归因于 fp8）。

H100 的 FP8 张量核峰值（NVIDIA 官网稀疏口径 3,958 TFLOPS；注意这与前文 BF16 的 989 TFLOPS 稠密口径不同，稀疏值不能直接当同比基准，同口径稠密 FP8 约为 BF16 的两倍）账面算力翻倍，但小规模训练的瓶颈往往不在纯矩阵乘。

所以实际收益远小于 2 倍，4.3% 是诚实的工程数字。

该行启动配置为 d26 + ratio 8.5 + fp8（dev/LEADERBOARD.md §Run 2）；Karpathy 在 X 上也单独报过这个 4.3%（X 帖约在 2026-02-02 同期，经聚合页转引）。

第 2 行到第 3 行，总批量从 50 万提到 100 万 token（ratio 同时从 8.5 微调到 8.25）：2.91 降到 2.76 小时，降约 5.2%。

更大的批量提高数据并行效率与硬件占满率。

代价是泛化间隙的微调空间变小，需要配合学习率规则一起调。

第 3 行到第 4 行，换数据集：2.76 降到 2.02 小时，降约 27%（主变量是数据，但同行深度从 d26 调回 d24、ratio 从 8.25 调到 9.5，27% 不能单独归因于数据）。

这是现代 nanochat 相邻配置间最大的单项跳变（不含第 0 行到第 1 行的跨代变化），来自把 FineWeb-Edu 换成 NVIDIA 的 Nemotron-ClimbMix。

ClimbMix 出自论文 arXiv:2504.13161（2025-04-17 首投）。

它的做法是用语义嵌入把大规模网页语料聚类，再用小代理模型加预测器迭代搜索最优混合比例。

最终蒸馏出 4000 亿 token 的精选集。

论文报告在等量 token 预算下，其 1B 模型超过 Llama-3.2-1B 两个百分点（论文摘要口径；具体为哪组评测的聚合见其正文）。

nanochat 的这次替换等于在另一套训练栈上观察到了同方向的数据收益（外部应用证据）：同样的小模型与配方，仅换数据，墙钟砍掉四分之一强。注意区分三个主体：论文作者的 1B 对比实验、nanochat 维护者的达标实验、本文的整理，三者不是同一次「复现」。

值得一并记录的是 Karpathy 的谨慎。

这一点现在有一手出处：dev/LEADERBOARD.md §Run 4 原文写道，Karpathy 此前多次尝试替换数据集（FineWeb、DCLM、Olmo），每次都是负收益，只有 ClimbMix 带来明确且即时的收益（其中「Olmo」是 Ai2 的模型家族名，其配套语料另有 Dolma 等具体名字，该文件未指明测试的是哪份语料，本文按原文转述）。

他自己也提到要警惕 Goodhart 效应，即指标被针对性优化，但检查论文后认为结果可信。

这段「别的数据集反而更差」是排行榜数字之外的重要信息。

它说明数据的收益是配方相关的，不能脱离训练堆栈谈语料排名。

第 4 行到第 5 行、第 5 行到第 6 行，autoresearch 两轮：2.02 降到 1.80 再降到 1.65 小时，分别降约 10.9% 与 8.3%，两轮合计约 18%。

这两行的提交者是 Karpathy，但改动的产出方式变了。

dev/LEADERBOARD.md §Run 5 写明：该 commit 的全部改进来自 autoresearch（私有版本）在 d12 模型上的全自主研究，并附 Karpathy 的 X 帖链接（2026-03 上旬；帖首句自述「三天前我让 autoresearch 在 d12 模型上连续调了约两天」，该 URL 经本文来源校验工具打开并读到标题）。

关于这轮迭代的强度有两个并存的转引口径：X 帖标题自述「调了约两天」，而 blockchain.news 2026-03-05 的报道则写「约 12 小时内做了 110 个改动」——两个数字均未能一手核验，本文并列呈现不断言。

代理把 d12 实验模型的验证 bpb 从 0.862415 压到 0.858039，有效改动再合并回主线。

也就是说，排行榜的最后两格是「AI 优化 AI 训练」的直接产物。

人定义目标函数（val_bpb 与 time-to-GPT-2）与合并纪律，代理负责高通量试错。

把 7 行合在一起看，模式很清楚。

现代相邻配置中，第 1→2、2→3 行是个位百分比的工程优化，第 3→4 行的数据替换是现代配置内最大单步收益（约 27%），第 4→5、5→6 两轮来自自动化实验代理。

如果要用一句话概括这座排行榜的方法论，那就是：把「达到 GPT-2 能力」定义成一个可复现、可计时、可公开提交的单指标竞赛，然后让全栈每一层都来攻这一个指标。

这套玩法直接继承自 Keller Jordan 的 modded-nanogpt。

那是 nanoGPT 的 speedrun 化改造：其纪录史里，2024 年 10 月 4 日引入 Muon 一步就把时间从 31.4 分钟砍到 24.9 分钟。

nanochat 把它从「纯预训练」扩展到了「完整可对话模型」。

对照表：2019 与 2026 的三张快照

下表把三个时点并排。

成本口径：仅加速器租金。

参数与 token 量级中标「自算」的单元格为本文推导值：

维度	2019-02 OpenAI GPT-2	2026-01-29 nanochat 基线	2026-03-14 nanochat 纪录
硬件	32 块 TPU v3（256 核）	单节点 8×H100	单节点 8×H100
墙钟	约 168 小时	3.04 小时	1.65 小时
租金成本	约 43,008 美元	约 73 美元	约 40 美元
相对 2019	1×	约 589×	约 1,086×
参数量级	约 15 亿（README 写作 1.6B，同一 checkpoint）	约 13.8 亿（官方公布的 d24 总参数）	同左（纪录行与基线行同为 d24 配置）
训练数据	未公开（WebText）	FineWeb-Edu 语料（全量 1.3 万亿 token；本次训练消耗约 87.6 亿 token，ratio 12）	ClimbMix 语料（全量 4000 亿 token；本次约 58.4 亿 token，ratio 8、自算）+ autoresearch 配方
关键软件	TF1 时代栈	FA3 / torch.compile / Muon（2026-01-29 基线行为 bf16；fp8 是 2026-02-02 第 2 行才引入）	同左并加入 fp8、ClimbMix 数据与代理自动调参
能力锚	CORE 0.256525	CORE 0.2585	CORE 0.2626

注意最后一行的读法要克制。

纪录行的 CORE（0.2626）比基线行（0.2585）高 0.0041，但官方明确 CORE 有一点噪声：dev/LEADERBOARD.md §Run 4 记录同一配置跑 7 次，CORE 从 0.25119 到 0.26765，极差 0.01646；且纪录行是 5 次平均、基线行是单次记录。

所以这个差值不足以支撑「分数更好」的结论；官方要求同时报告 val_bpb（纪录行 0.71800，在 ClimbMix 同系内低于 Run 4 的 0.71854），这才是更平滑的对照。

工程含义：这份账单对开发者意味着什么

第一，GPT-2 级能力已经彻底商品化为一次下午实验。

一台 8×H100 节点约一个半小时即可跑完全流程（2026-10-16 所核 speedrun.sh 注释的当前全程口径，含下载、分词与 SFT；这与排行榜纪录的计时对象不完全相同——排行榜第 6 行 1.65 小时是 2026-03-14 的「越过 CORE 线时间」，脚本注释的约 1.5 小时是另一版本的全流程口径，两者不是同一次测量），按时价不到 50 美元。

用 spot 实例可低至约 15 美元（README 口径）。

具备一台 80GB 显存级 8 卡节点与相应数据条件的团队，都能在自己的数据上复现整条流水线。

这意味着「从零训一个小模型」的决策门槛，从「要不要立项」降到了「要不要开个 screen 会话」。

第二，评估锚点的选择比想象中重要。

整个排行榜挂在 CORE 这一个聚合分上。

好处是可复现、防口径漂移。

代价是它只覆盖一组学术基准的聚合（nanochat 取 22 项）。

排行榜比的是「越过学术基准线的时间」，不是「产品可用性」。

第三，就这组配置、这段排行榜而言，数据是杠杆率最高的一层。

在这次拆解里，换数据集一步的降幅（约 27%）约为 fp8 与批量调整两步降幅之和（约 9.4%）的 2.8 倍（本文按排行榜数字自算）。

DCLM 论文（arXiv:2406.11794，2024-06-17 首投）在更大尺度上给出过同方向的证据。

其 7B 基线靠数据筛选，在 2.6 万亿 token 内把 5-shot MMLU 做到 64%，比前代开放数据 SOTA 少用 40% 算力还高 6.6 个百分点。

两个独立尺度的证据指向同一方向的结论：在这两套设定里，「喂什么」比「怎么算」更值得先优化（是否为普遍规律，本文不下断言）。

第四，autoresearch 是这份排行榜里最有前瞻性的信号。

Karpathy 把一个明确的标量目标（val_bpb、time-to-GPT-2）、一个沙盒化的实验尺度（d12，约五分钟一趟预训练）和一套合并纪律交给代理。

代理在约两天里完成了人类团队可能要排期数周的 110 次试错。

对任何有「可快速评估的实验回路」的团队，这都是可直接借鉴的范式：把单次实验的单价打到足够低，然后把试错委托给代理。

边界与未解

这份账单有几条明确的边界，引用时应当一并引用。

成本口径只含加速器租金。43,008 美元与 40 美元都排除了数据准备、人力、失败实验与电费。2019 年的真实研发总成本远高于此，2026 年的也一样——autoresearch 代理本身烧的算力就没有计入排行榜时间。
CORE 线不等于全面的 GPT-2 等价。CORE 是 22 项基准的聚合分，越过它不代表在所有维度上复现 GPT-2，更不代表复现 GPT-2 当年引发讨论的开放生成能力。nanochat 自己也提醒：speedrun 模型的对话水平像幼儿园小孩。
MFU 与 FLOPs 的拆账是本文估算。Run 1 的 FLOPs 与时间为官方记录值（dev/LEADERBOARD.md），Run 6 的 FLOPs 未公布、本文按 Run 1 的每 token 计算量线性折算（忽略 Run 5/6 架构改动带来的额外计算，故 61% 为下限估算）；MFU 归一化用 BF16 稠密峰值，换归一化口径数字会变。
数据收益是配方相关的。ClimbMix 在 nanochat 堆栈上收益巨大，但 Karpathy 实测 Olmo、FineWeb、DCLM 在其设定下回退（dev/LEADERBOARD.md §Run 4 一手口径，具体语料版本未指明）。不能把「ClimbMix 好」直接外推到任意训练栈。
排行榜是单节点单配置的竞赛。8×H100、特定软件版本、特定 CORE 阈值。换成 A100（README 说可以跑、更慢）或更大集群，数字不可比。
autoresearch 的细节未经完整一手核验。约两天、110 个改动、bpb 从 0.862415 到 0.858039 这组数字来自 Karpathy 的 X 帖；其中「约两天」由本文来源校验工具实际打开 X 帖标题确认，其余细节经聚合报道转引，读者可按链接自行核验。

未解的问题同样明确。

这条年化 40% 的成本曲线还能持续多久？Karpathy 自己判断仍被低估。

time-to-GPT-2 之后社区会不会转向更高的能力锚？Karpathy 曾在 X 上提到 d32、即 1000 美元档模型的训练（经聚合页转引，发言日期未确认，为当时进行时）。

以及 autoresearch 的改动有多大比例能跨深度泛化？

nanochat 的纪律是「任何改动必须在所有 depth 设定上都成立」，这正是代理产出能否沉淀为主线的试金石。

小结

把这笔账压缩成五句话。

第一，2019 年 GPT-2 的训练账单是 32 块 TPU v3 乘以 168 小时乘以每小时 8 美元，约 43,000 美元。

第二，2026 年 1 月 nanochat 用 3.04 小时（约 73 美元）越过同一条 CORE 线，3 月纪录 1.65 小时（约 40 美元），成本压缩约 1,086 倍（租金口径、本文自算）。

第三，年化 40% 是用 2019 年初到 2026 年 1 月两端估算的拟合（与 1,086 倍不共享计算区间）；这 600 到 1000 倍本身不是单一因素的奇迹，而是硬件代差、fp8 与编译器、Muon 系优化器、数据工程（单步约 27%）与 autoresearch 代理（两轮再砍约 18%）的乘积。

第四，最有杠杆的一层是数据（本组配置内），最有前瞻性的变化是「AI 代理开始自动优化 AI 训练」；而 FLOPs 拆账给出正面证据：达到同一能力所需的计算量本身在缩小（约减三分之一，本文估算），同时算得更快（MFU 约 50% 到 61%）。

第五，对开发者的现实含义是：GPT-2 级能力的全流程训练已经是一次不到 50 美元的下午实验，评估锚点与数据选型比算力本身更值得投入。

📋 来源与核验记录

以下一手来源均为本文写作当轮（2026-10-16）实际打开并核对的页面。

nanochat 仓库 README（排行榜、成本口径、4e19 FLOPs、d24–d26 区间、10.5 默认比、spot 约 15 美元）：https://github.com/karpathy/nanochat （当轮抓取 raw README 全文）
runs/speedrun.sh（当前 speedrun 配置：d24、ratio 8、fp8、分片 8+170、词表 32768、全程约 1.5 小时）：https://github.com/karpathy/nanochat/blob/master/runs/speedrun.sh （当轮抓取脚本全文）
Karpathy 讨论帖《Beating GPT-2 for <<$100: the nanochat journey》（2026-02-01，GPT-2 账单还原：32×168×8=43,000 美元、年降约 40% 口径、CORE 22 项聚合、73 美元折算原文；含「The Jan 29 Model: Architecture Deep Dive」：24 层 / 1536 通道 / 12 头、总参数 1,384,124,976）：https://github.com/karpathy/nanochat/discussions/481 （当轮抓取并解析正文）
nanochat 仓库元数据（创建日 2025-10-13、star 数、最近提交 2026-09-07）：GitHub API https://api.github.com/repos/karpathy/nanochat （当轮查询）
DCLM 论文摘要（240T token 语料、53 项评测、7B 基线 64% MMLU 5-shot / 2.6T token）：https://arxiv.org/abs/2406.11794 （当轮打开）
Nemotron-CLIMB 论文摘要（ClimbMix 4000 亿 token、聚类加代理模型迭代搜配比、1B 超 Llama-3.2-1B 两个百分点）：https://arxiv.org/abs/2504.13161 （当轮打开）
modded-nanogpt 仓库 README（speedrun 玩法来源；2024-10-04 引入 Muon 后纪录 31.4→24.9 分钟等）：https://github.com/KellerJordan/modded-nanogpt （当轮抓取 raw README）
NVIDIA H100 官方产品页（BF16 张量核 989 TFLOPS 稠密 / 1,979 稀疏、FP8 3,958 稀疏）：https://www.nvidia.com/en-us/data-center/h100/ （当轮打开）
FineWeb-Edu 数据集页（1.3 万亿 token，论文 arXiv:2406.17557）：https://huggingface.co/datasets/HuggingFaceFW/fineweb-edu （当轮打开）
Chinchilla 论文摘要（400 个模型、70M–16B、token 与参数等比放缩）：https://arxiv.org/abs/2203.15556 （当轮打开）
Karpathy 的 X 帖（autoresearch 第 1 轮原帖，README 排行榜第 5 行附链接；本文来源校验工具实际打开，标题自述「let autoresearch tuning nanochat for ~2 days on depth=12 model」）：https://x.com/karpathy/status/2031135152349524125
dev/LEADERBOARD.md（排行榜官方口径：计时定义排除评测与日志；Run 1 记录值 4.330784131228946×10^19 FLOPs / 10,949.46713 秒 / CORE 0.25851 / step 16704；各行启动命令（Run 1 ratio 12、Run 2 d26+8.5+fp8、Run 3 批量 1M+8.25、Run 4 d24+9.5+ClimbMix、Run 6 同 Run 4 仅 ratio 8）；Run 2 的 4.3% 作者计算；Run 4 的 CORE 噪声 7 次记录（极差 0.01646）与数据集替换史；Run 5/6 的 autoresearch 说明）：https://github.com/karpathy/nanochat/blob/master/dev/LEADERBOARD.md （当轮抓取 raw 全文）
OpenAI 官方博客《Better Language Models and Their Implications》（2019-02-14，GPT-2 公布、当时未放出最大模型；审者B 提供线索。openai.com 对自动抓取返回 403，不给裸 URL，读者可按篇名+日期检索）
OpenAI 官方博客《GPT-2: 1.5B Release》（2019-11-05，最大 checkpoint 公开发布；审者B 提供线索。同上，openai.com 对自动抓取返回 403）
Google Cloud TPU v3 官方文档（Peak compute per chip = 123 teraflops bf16）：https://cloud.google.com/tpu/docs/v3 （当轮打开）
nanochat 当前 base_train.py（—target-param-data-ratio 默认值 12、help 注明 Chinchilla=20；commit 92d63d4）：https://github.com/karpathy/nanochat/blob/92d63d4e8bb4df75c3b71618f31ddde2378b2bcd/scripts/base_train.py （当轮抓取）

固定版本说明：README 与 speedrun.sh 有随 master 漂移的风险，本次核验对应 master commit 92d63d4（GitHub API 当轮查询），固定链接：https://github.com/karpathy/nanochat/blob/92d63d4e8bb4df75c3b71618f31ddde2378b2bcd/README.md

转引与未能一手核验的项：① d32（1000 美元档）与 2026-01-31 前后基线公告出自 Karpathy 的 X 帖，经 ifeed.cc 聚合页转引（https://www.ifeed.cc/articles/1be30487-8608-48d4-8609-64a6a1756f4f ，页面标注日期 2026-01-31）；② autoresearch 迭代强度有两个并存口径：X 帖标题自述「调了约两天」（该 URL 经来源校验工具打开并读到标题），blockchain.news 2026-03-05 报道写「约 12 小时内 110 个改动、bpb 0.862415→0.858039」（https://blockchain.news/ainews/karpathy-s-nanochat-hits-2-hour-gpt-2-training-on-8x-h100-fp8-tuning-and-nvidia-climbmix-breakthrough ），均未做语义级一手核验。ClimbMix 替换史与 4.3% 提速已升级为 dev/LEADERBOARD.md 一手出处。排行榜数字本身以 README 与 dev/LEADERBOARD.md 为一手来源。

本文自行推导（与官方数字分列）：600 倍与 1,086 倍成本比、年均 40% 衰减因子、scaling 参数 729,813,504（按 481 帖公布分项相加）、D≈87.6 亿 token（Run 1，ratio 12）与 ≈58.4 亿（Run 6，ratio 8）、每 token 约 4.95×10^9 FLOPs、Run 6 FLOPs≈2.9×10^19 与「所需 FLOPs 降约三分之一」、50% 基线 MFU 与 61% 纪录行 MFU（下限估算）、硬件跃升约 8 倍、170 分片约合百亿 token 的粗估、排行榜逐行百分比降幅（4.3% / 5.2% / 27% / 10.9% / 8.3% / 两轮合计约 18%）、「数据一步降幅（约 27%）约为 fp8 与批量调整两步降幅之和（约 9.4%）的 2.8 倍」、MFU 相对提升约 22%、40% 到 50% 的合理 MFU 区间判断（工程经验口径）、「10.5 与 Chinchilla 20 的差异解读」。

内容透明度声明：本文由 AI 辅助生成，基于上述公开资料整理与复算，MagicNetWorld 尚未在自有硬件上独立复现 speedrun。