📌 项目地址：karpathy/nanochat | ⭐ 54,356 颗星 | 🔧 Python | 📜 MIT
2019年OpenAI训练GPT-2（1.6B参数）用了168小时，账单43,000美元。现在你拿一个8×H100 GPU节点跑nanochat，最快1.65小时就能拿到比原版更高的DCLM CORE分数（0.2626 vs 0.2565）。按需实例成本约48美元，用抢占式实例能压到15美元。这不是说大模型训练白菜价，而是有一个项目，第一次让“从零开始训练一个GPT-2级别模型”这件事有了可复现、可对比、最小成本的标准化跑法。
这个项目是karpathy/nanochat，54356个star，MIT协议。
她不是框架，是一组可hack的脚本
nanochat的作者是Karpathy，看起来就是他一贯的风格：代码量少，不藏玄学，你直接改文件就能动训练循环、数据加载、对话接口。它覆盖tokenization、pretraining、finetuning、evaluation、inference全部流程，全部在单个GPU节点上跑。没有复杂的API层，没有配置文件生成器。你要改一点东西，打开train.py直接动手，跟改自己的作业一样。
这跟那些封装好的“训练框架”恰好相反——框架让你管的事情少了，但你想改底层逻辑就得学习它的抽象层。nanochat反过来：给你一个最小可运行的完整管线，想怎么改都行，代价是你要自己处理细节。
一个参数控制模型复杂度
训练命令就一条：
bash runs/speedrun.sh脚本会自动下载数据（默认用NVIDIA ClimbMix），开始训练，结束后自动拉起一个CLI让你跟模型聊天。所有超参数——transformer宽度、注意力头数、学习率、训练步数、权重衰减——都由--depth这一个参数自动算出。depth = 26对应GPT‑2级别的能力。如果你GPU少，调低depth，脚本重新算最优配置。不需要你手动调batch size、学习率schedule。
README里说这是“compute-optimal models”的做法。我觉得这种设计很有用：你只需要关心模型容量（层数），其他事情脚本用经验公式帮你搞定。当然，这个公式不是万能的，但至少给了你一个可重复的起点，而不是让你从一堆不相关的超参数开始乱碰。
Time-to-GPT-2排行榜：每个条目都可复现
项目目前的核心工作是优化预训练阶段。排行榜记录的是“从零训练到超过GPT‑2的DCLM CORE评分（0.256525）所需墙钟时间”。所有条目对应具体commit，你从仓库里能找到那次变更的代码。我列一下我看到的记录：
| # | 墙钟时间 | val_bpb | CORE | 变更说明 | 日期 | Commit |
|---|---|---|---|---|---|---|
| 0 | 168h | – | 0.2565 | OpenAI GPT-2原始检查点 | 2019 | – |
| 1 | 3.04h | 0.74833 | 0.2585 | depth=24基线，稍过训练 | 2026-01-29 | 348fbb3 |
| 2 | 2.91h | 0.74504 | 0.2578 | depth=26稍欠训练 +fp8 | 2026-02-02 | a67eba3 |
| 3 | 2.76h | 0.74645 | 0.2602 | 总batch size提升到1M tokens | 2026-02-05 | 2c062aa |
| 4 | 2.02h | 0.71854 | 0.2571 | 换数据集为NVIDIA ClimbMix | 2026-03-04 | 324e69c |
| 5 | 1.80h | 0.71808 | 0.2690 | autoresearch第1轮 | 2026-03-09 | 6ed7d1d |
| 6 | 1.65h | 0.71800 | 0.2626 | autoresearch第2轮 | 2026-03-14 | a825e63 |
有几个点我觉得很有意思：
- 数据集影响巨大：从#3换到#4，只改了数据集，时间从2.76h降到2.02h，降幅27%。而之前增大batch size（#2→#3）只降了5%。这说明当前瓶颈可能不在训练算法，而在数据质量或数据加载效率。换句话说，有时候你换组数据比调一周学习率管用。
- autoresearch的取舍：#5和#6都用了自动搜索，但目标优化的是墙钟时间，不是模型质量。所以#6的CORE分数（0.2626）反而不如#5（0.2690），但快了0.15小时。这很诚实：你想更快达标，就要牺牲一点最终质量。Commits 6ed7d1d和a825e63都具体标出了改了优化器调度和数据预处理节奏，你可以去读代码看他们怎么权衡的。
- 每个记录都能复现：我顺着a825e63看了下，改动是调整了数据预取和优化器步调。你可以自己跑一次验证。这种透明度在学术论文里很少见，但在这里是默认的。
三个提问渠道
如果你读代码有疑问，README给了三个地方：
- DeepWiki：由Devin/Cognition提供的基于仓库的智能问答。你可以问“为什么#2的fp8提升幅度不大”，它会引用对应commit的代码变更来回答。我试了下，回答质量还可以，至少能指向具体文件。
- GitHub Discussions：适合讨论设计思路、贡献新优化技巧。
- Discord #nanochat频道：实时交流，Karpathy本人也在里面。
这项目适合什么人
第一，做LLM训练实验的研究者或工程师。你想试新数据集、新架构、新技巧，跑一次speedrun.sh就能看到效果。不需要从零搭训练管线，结果也方便跟排行榜对比。
第二，给自己硬件定基线。在8×H100节点上跑一遍speedrun.sh，就能得到当前最优时间。以后有了更好的算法或硬件，重新跑一次，对比commit就知道进步了多少。
我不建议把nanochat当生产部署工具。它设计出来是让你实验的，不是让你跑服务的。但如果你只是想快速验证一个想法，它比从头写一堆脚本省事很多。
nanochat没跟你玩概念。它给你一个可跑的东西，一个可对比的排行榜，一个可hack的代码库。剩下的靠你自己。