nanochat：低成本跑通大模型训练全流程

花几十美元，从分词、预训练、微调一路跑到能在命令行聊天，nanochat 想把这件事做成程序员能读懂、能修改的实验。Karpathy 给出的参照是：在 8XH100 节点上，用约 1.5～2 小时训练出达到 GPT-2 基准水平的模型。

它值得看的地方不只是便宜，而是把模型大小、训练预算和评测串成了一条完整路径。但「达到 GPT-2 水平」有明确的指标边界，也不能把这笔 GPU 费用理解成训练实用编程助手的全部成本。

几十美元买到的「GPT-2 水平」怎么算

nanochat 当前最关注的是预训练，因为这一阶段消耗最多算力。它把优化目标定为「time to GPT-2」：在 8XH100 节点上，训练模型所需的实际经过时间，以超过 GPT-2（1.6B）的 DCLM CORE 分数为终点。

门槛是 0.256525。这里衡量的是一组基准任务上的成绩，不是模型参数量，也不是所有对话能力都与 GPT-2 相同。

原文给出的价格推算很直接：按约 $3/GPU/hr 计算，8XH100 节点约 $24/hr，运行两小时就是 $48；使用 spot 实例，费用可能接近 $15。作者拿它与 2019 年 GPT-2 约 $43,000 的训练成本比较，强调七年间整个技术栈的进步。

不过，这份材料存在不同更新时期的口径。开头按约两小时估价，运行说明和结尾写约 1.5 小时，结尾还提到从三小时缩短而来。目录注释保留着「约 $100、d20」的旧描述，正文则把 GPT-2 能力对应到 d24～d26，开头约写为 depth 26。它们不宜拼成一张精确报价单，原文指定的参考入口是 runs/speedrun.sh。

这里最有价值的是可复现的达标过程，而不是一个脱离硬件和脚本版本的低价数字。

能力边界也很直观。作者给出的聊天样例里，模型能提到 Rayleigh Scattering，却把解释继续写成了错误的粒子描述。作者将这个约 4e19 FLOPs 的模型比作幼儿园小朋友，已经提醒了读者：能聊天与回答可靠，是两回事。

为什么只调一个 --depth 就能做实验

nanochat 把主要的规模选择收敛到 Transformer 层数，也就是 --depth。模型宽度、注意力头数、学习率调整、训练时长和权重衰减等参数，由代码按模型规模自动计算。

大白话解释：用户先选模型做多大，项目替你配好一组相关训练参数。作者希望不同规模都能合理使用算力，形成一系列计算最优模型，而不是每换一个规模就重新手工找配置。

这也约束了代码改进的评价方式。一个改动如果只对某个深度有效，还不足以说明它适合进入项目；作者要求候选改动能适用于不同 depth。相关实验入口是 runs/scaling_laws.sh 和 runs/miniseries.sh，原文还引用了 Jan 7 miniseries v1 的说明。

为了缩短反馈周期，作者常用 12 层、GPT-1 大小的模型，做约五分钟的预训练实验：

OMP_NUM_THREADS=1 torchrun --standalone --nproc_per_node=8 -m scripts.base_train -- \
    --depth=12 \
    --run="d12" \
    --model-tag="d12" \
    --core-metric-every=999999 \
    --sample-every=-1 \
    --save-every=-1 \

要看的是最后三项：这套配置只在最后一步运行 CORE 评测，不生成中间样例，也不保存中间检查点。它服务于快速比较代码改动，不适合直接照搬成需要恢复训练的长期任务配置。

作者通过 wandb 观察三类信号：val_bpb 衡量验证集上每字节需要多少比特，减少词表大小对损失比较的影响；core_metric 对应 DCLM CORE 能力成绩；显存占用、train/mfu 和 train/tok_per_sec 则反映硬件利用率与吞吐。验证损失还会分别对照 step、total_training_time 和 total_training_flops。

这套比较方法很实用。同样训练步数下表现更好，不代表同样时间或算力预算下也更好。

能跑完整流程，不等于所有机器都能轻松跑

nanochat 与只覆盖预训练的 nanoGPT 不同，它还包含分词器训练、微调、评测和推理。scripts/chat_sft.py 负责监督微调，scripts/chat_rl.py 负责强化学习，nanochat/engine.py 提供带 KV Cache 的推理实现，最终可以通过 scripts/chat_cli.py 对话。

依赖由 uv 管理。CUDA 环境使用 uv sync --extra gpu，CPU 或 MPS 使用 uv sync --extra cpu，随后执行 source .venv/bin/activate。开发依赖通过 uv sync --extra gpu --group dev 安装。

完整复现 GPT-2 能力模型的入口很短：

bash runs/speedrun.sh

这一行背后是按 8XH100 设计的整条流水线；完成后，需要在已激活的环境里运行 python -m scripts.chat_cli 才能聊天。

硬件门槛没有因为命令短而消失。作者称 8XA100 也能运行，但速度更慢；省略 torchrun 后可以用单 GPU，代码会自动采用梯度累积，结果近似一致，等待时间则约增加到八倍。

显存低于 80GB 时，需要调整 --device-batch-size，从默认 32 逐步降到 16、8、4、2 或 1，避免 OOM。runs/runcpu.sh 会大幅缩小模型，让 CPU 或 Apple Silicon 在几十分钟内完成训练，作者明确表示这种配置不会得到很强的结果。其他 xpu、mps 路径也没有全部经过作者亲自验证。

精度控制同样有明确边界。项目不用 torch.amp.autocast，而是通过 nanochat/common.py 中的全局 COMPUTE_DTYPE 管理精度。权重保留 fp32，自定义 Linear 在前向计算时转换精度，Embedding 直接使用计算精度存储。

用户可以通过 NANOCHAT_DTYPE 覆盖默认值，例如 NANOCHAT_DTYPE=float32 python -m scripts.chat_cli -p "hello"，或 NANOCHAT_DTYPE=bfloat16 torchrun --nproc_per_node=8 -m scripts.base_train。float16 预训练会自动启用 GradScaler，SFT 也支持，RL 当前不支持；fp16 推理则可以使用。训练阶段不同，精度支持不能一概而论。

我的判断

我更愿意把 nanochat 看作学习和研究小模型的完整基线。它的目标是让用户在低于 $1000 的预算内，端到端改进微型模型，同时控制阅读代码和理解配置的难度。

这条路线有道理。与大量配置对象、模型工厂和条件分支相比，一套连贯的小代码库更容易追踪数据怎样进入模型、损失怎样计算、权重怎样更新。代价是适用范围更集中；原文也没有给出它与通用训练框架在维护成本、扩展速度上的对照数据，这部分属于作者的设计判断。

「计算最优」也有前提：自动参数规则服务于项目当前的模型、数据和训练方法。原文没有证明，换成特定中文语料或其他训练目标后仍然最优。原样复现可以先接受默认值，改变任务后仍要重新评测。

对于前端和全栈程序员，最容易误判的是把它当成便宜的 AI 编程助手方案。原文没有给出足以支持这一结论的代码能力评测。若目标是接入现有应用，调用成熟模型 API 或部署现成模型通常更直接；若目标是理解模型如何训练、验证一个训练改动，nanochat 的价值才更突出。

能拿来做什么

• 想理解完整训练链路，可以沿 runs/speedrun.sh 追踪分词、预训练、微调和评测，再对照 CLI 推理入口阅读代码；只有 CPU 或 Apple Silicon 时，先用 runs/runcpu.sh 熟悉流程，并接受其能力限制。
• 想修改训练代码，可以参考作者的 d12 小实验，先记录 val_bpb、CORE、训练时间和吞吐，再扩大到 d16 等规模，检查收益是否依然成立。
• 想租 GPU 复现，可以先核对显存、节点时价和脚本配置，把 $48 当作特定条件下的估算；出现显存不足时，优先检查 --device-batch-size。
• 日常用 AI 辅助修改这个仓库时，应遵守它的披露要求：提交 PR 要说明哪些部分有大量 LLM 贡献，尤其是自己没有编写或尚未充分理解的代码。