GitHub 热门项目 `modded-nanogpt` 实测：把“90 秒训练 124M”搬到 RTX 3090 后，先炸的不是显存，而是 Hopper 专用内核

GitHub 热门项目modded-nanogpt实测：把“90 秒训练 124M”搬到 RTX 3090 后，先炸的不是显存，而是 Hopper 专用内核

很多人看到modded-nanogptREADME 里的“124M 模型 90 秒训练”会本能地想：先 clone 下来，看看自己手头的 24GB 消费卡能不能学一遍。
我这次就是这么做的。但把它搬到本地 RTX 3090 后，最先挡住我的不是显存，也不是学习率，而是两个更底层的问题：一个 fused cross entropy 内核把compute_capability写死成了90，另一个注意力路径直接走向了 Flash Attention 3 的 Hopper/TMA 实现。
结论先说：modded-nanogpt当前 master 分支更像一份为 8xH100 speedrun 服务的竞速代码，而不是一份“消费级 GPU 拿来就能学”的通用训练起点。你当然可以把它改到更通用，但第一步绝不是抄 README 命令，而是先确认哪些地方是 Hopper 专用假设。

1. 先别被“90 秒”带跑：这个项目的目标本来就不是通用复现

modded-nanogpt最近很火并不奇怪。它把“124M 语言模型训练到指定验证损失”的速度一路压到8xH100下的 90 秒以内，这种结果天然会吸走训练工程师和研究型读者的注意力。

但你只要把 README 多看两眼，就会发现它的叙事重点是speedrun，不是portability：

• README 写得很明确，当前记录是8xH100。
• • 同一份 README 还提醒：第一次torch.compile会额外带来大约 7 分钟延迟。
• • 整个仓库从记录表、PR、内核到 warmup 设计，核心目标都是压榨 H100 上的训练吞吐。
    这不是缺点，但它决定了一个很关键的工程判断：

这类仓库最适合学习“哪些训练和系统技巧在顶配硬件上真的有效”，不适合默认当成“我本地 3090/4090 应该直接复现”的教学基线。
如果你忽略了这一点，就很容易把时间浪费在错误方向上：先调 batch size、先改学习率、先担心显存，结果真正的拦路虎其实在更底层。

2. 我的验证目标不是刷到 3.28，而是回答一个更实际的问题

这次我没有试图在 RTX 3090 上复刻 README 的最终速度，也没有去追 3.28 验证损失。我想先回答一个更接地气的问题：

截至 2026-04-30，这个仓库的 current master 在一张 RTX 3090 上，最小 warmup/训练路径到底能不能起得来？如果起不来，第一处阻塞在哪里？

2.1 本地环境

GPU: NVIDIA GeForce RTX 3090 24GB Driver: 590.44.01 PyTorch: 2.9.1+cu128 CUDA (torch 编译版本): 12.8 Triton: 3.5.1 Device capability: (8, 6)

这里有两个细节很重要：

• device capability = (8, 6)，也就是 Ampere，不是 Hopper。
• • 我本地确认bf16_supported = True，所以问题不能简单归结为“3090 连 bf16 都不行”。

2.2 我实际做了什么

为了避免“没跑就写”，我做了三层验证：

1. 直接 clone 当前仓库，读取 README、train_gpt.py、triton_kernels.py。
2. 2. 在本地导入仓库里的triton_kernels.py，看 fused kernel 能不能先过导入这一关。
3. 3. 做一份诊断用的最小 probe：保留仓库主干逻辑，把数据缩小、步数缩短、跳过torch.compile，只验证 warmup 是否能在单卡 3090 上启动。
      这第三步我要特别说明：

• 我不是在声称“我成功改好了 consumer 版”。
• • 这个 probe 的目的只是定位第一层硬阻塞，不是追求最终 loss。
• • 我甚至故意关掉了torch.compile，因为我不想让 7 分钟编译时间掩盖更底层的硬件兼容问题。
    换句话说，这是一篇“实测定位边界”的文章，不是“我已经给你交付一套 3090 最优配置”。

3. 第一处硬阻塞，不是显存，而是sm90被写死在 fused CE kernel 里

我先看的不是模型结构，而是仓库里最容易决定“能不能起”的底层文件：triton_kernels.py。

这里有一段非常关键的代码：

ce_fwd_bwd_kernel=torch.cuda._compile_kernel(CE_KERNEL_DECLS+CE_KERNEL_SOURCE,"ce_fwd_bwd_kernel",compute_capability="90",cuda_include_dirs=["/usr/local/cuda/include/"],nvcc_options=["-lineinfo","--use_fast_math"],)``` 这意味着什么？-`compute_capability="90"` 指向的是 Hopper 代际。--我的本地3090是 `(8,6)`。--也就是说，这个 fused cross entropy 内核在源码层面就已经把目标架构锁到了 `sm90`。 我直接在本地导入仓库里的 `triton_kernels.py`，得到的不是普通 Python 报错，而是 CUDA 侧的 PTX JIT 编译失败： ```text RuntimeError:CUDA error:a PTX JIT compilation failed

这一步其实已经足够说明一个现实：

如果你照着当前 master 直接上 3090，很多时候连“开始训练”都谈不上，因为有些关键 kernel 的目标硬件就不是 Ampere。

这里我想给出第一条作者判断：

如果一个热门训练仓库在核心 fused kernel 上直接写死compute_capability="90"，那你在消费卡上遇到的第一个问题大概率不是 OOM，而是“根本没有对应的可执行 kernel image”。
这也是为什么我不建议读者一上来就调 batch size。方向错了，调得再细也只是原地打转。

4. 我把 CE 先降级成普通实现后，第二处硬阻塞才真正露出来：Flash Attention 3 还是 Hopper 路线

为了确认“是不是只有 fused CE 卡住”，我做了一个诊断性修改：

• 把 fused cross entropy 换成更通用的 fallback 实现，只为了让流程继续往后走。
• • 保留其余主体训练路径。
• • 同时关闭torch.compile，避免把编译延迟和主问题混在一起。
    结果很有意思：cross entropy 那一关过去以后，训练 warmup 仍然在注意力路径上挂掉了。

报错核心信息如下：

Error: Failed to initialize the TMA descriptor 801 CUDA error (.../flash-attention/hopper/flash_fwd_launch_template.h:192): no kernel image is available for execution on the device

这段错误比“显存爆了”更值得重视，因为它揭示了第二个硬约束：

• 当前train_gpt.py的注意力路径直接绑定flash-attention-3。
• • 报错栈明确指向 Hopper 目录下的flash_fwd_launch_template.h。
• • TMA本身就是 Hopper 非常标志性的能力点。
    换句话说，我把最先炸掉的 fused CE 暂时垫过去之后，项目还是会在Hopper-only attention path上再次卡死。

所以第二条作者判断也很明确：

对消费级 GPU 来说，modded-nanogpt当前 master 的真正门槛不是“训练参数还没调好”，而是“关键 kernel 选择本身已经默认你在 Hopper 上”。
这一点和很多普通教程完全不同。普通教程会告诉你：

• 先减 batch size
• • 先减 sequence length
• • 先关 compile
• • 先少跑几步
    这些动作当然有意义，但它们只在kernel 兼容的前提下才有意义。现在的问题是，前提本身就不成立。

5. 社区早就提过 4090/3090 诉求，但“有人讨论过”不等于“当前 master 直接能跑”

如果你去翻仓库的 Issues 和 PR，会发现消费级 GPU 复现这件事并不是没人提。

5.1 Issue #29：社区很早就在问 4090/3090 变体

在 Issue #29 里，社区很早就有人明确问：能不能给 4090 这种消费卡做一版 speedrun 变体？

后续讨论里出现了几个很有价值的判断：

• 单卡 consumer GPU 的瓶颈不仅是算力，更是 24GB 显存和内核支持边界。
• • 如果想保持和 8xH100 接近的 token budget，需要同时调整 batch size 与 sequence length，而不是只改其中一个。
• • 有人给出过 “nproc_per_node=1+ 更小 sequence length + 更大 batch size” 的经验路径。
    这说明什么？

说明consumer GPU 适配不是空想，但它也绝对不是当前 README 那条命令天然就支持的东西。

5.2 PR #38：旧讨论里的 consumer 经验，更像“实验分支”，不是 current master 的默认能力

在 PR #38 及相关评论里，有人曾给出过比较具体的 consumer GPU 调整思路，例如：

• 单卡运行
• • 通过缩短 sequence length、调整 batch size 去维持等价 token 预算
• • 用面向 consumer GPU 的 kernel 配置
    这些经验非常有价值，但要注意两点：

1. 它们更接近“社区适配路线”，不是 current master 默认开箱即用的能力。
2. 2. 仓库在继续追 record 的过程中，关键 kernel 和注意力路径又朝 H100/Hopper 更深地优化了。
      也就是说，你不能简单地把旧讨论当成“今天 master 还会自然支持 3090”。

5.3 Issue #176：连 H100 用户都踩过“README 命令不够稳”的坑

另外，Issue #176 也很值得看。里面有人按 README 跑 current record 时，就遇到了 kernel 变体和环境路径问题。

这给我的第三条作者判断提供了证据：

modded-nanogpt当前仓库更像一个高速迭代的 benchmark codebase，而不是一个“任何 GPU、任何环境都尽量兼容”的课程项目模板。
这不是批评，而是定位问题。你要用对它。

6. 如果你只有消费级 GPU，我建议按这个顺序改，而不是先碰学习率

这部分是整篇文章最实用的地方。

如果你真的想把modded-nanogpt当成学习材料带到 3090/4090 上，我建议按下面这个顺序处理：

6.1 第一步：先清掉 Hopper-only kernel 假设

优先排查两类东西：

• 写死sm90/compute_capability="90"的 fused kernel
• • 明显依赖 Hopper/TMA 的 Flash Attention 3 路径
    在这一步之前，不要把主要精力花在学习率和 warmup 上。

6.2 第二步：给注意力和 loss 各自准备一条“慢但通用”的 fallback

如果你的目标是学习，而不是冲排行榜，我建议先接受一点性能损失，换来可运行性：

• 注意力先退回更通用的 PyTorch SDPA、FlexAttention 或 consumer-friendly FA 路径
• • loss 先退回普通cross_entropy
    只要能稳定起跑，你后面才有资格谈优化。

6.3 第三步：再去调整 sequence length / global batch / grad accumulation

当 kernel 兼容问题被排掉之后，才轮到经典的消费卡适配三件套：

• 降 sequence length
• • 重算全局 token budget
• • 用 grad accumulation 把训练动态尽量拉回原始设定
    也就是说，batch size 和 seq length 是第三顺位问题，不是第一顺位问题。

6.4 第四步：最后再决定torch.compile值不值得开

README 已经提醒了第一次torch.compile的延迟可能要 7 分钟左右。对单卡本地实验来说，这件事要看你的目标：

• 如果你是做诊断、改代码、看 loss 走向，先关掉更省时间。
• • 如果你已经完成 kernel 兼容改造，准备做长时间 benchmark，再考虑把 compile 打开。
    很多人会把 compile 当成“先手优化”，但在本地消费卡调试阶段，它往往更适合做“后手优化”。

7. 这项目到底值不值得学？我的结论是：值得，但别把 current master 当成通用起点

如果你问我，modded-nanogpt还值不值得看？答案当然是值得。

它至少有三层学习价值：

• 你可以看到现代 LLM 小模型训练里，哪些结构和优化思路真的被拿来换速度了。
• • 你可以看到 benchmark codebase 和教学 codebase 的设计目标到底有多不一样。
• • 你可以顺着 record、PR、issue 去理解：训练工程里“快”这件事，从来不只是调参，而是内核、注意力、通信、调度、损失、初始化一起动。
    但如果你只有一张 24GB 消费卡，我更建议这样用它：

我最后给出三条可以直接带走的判断：

1. 当前 master 在 consumer GPU 上最先撞上的，通常不是显存，而是 Hopper-only kernel 假设。
2. 2. 如果你的目标是学习训练工程，先让它“能跑”比先让它“跑得像 record 一样快”更重要。
3. 3. modded-nanogpt最值得学的不是那条 90 秒命令，而是它为什么敢为 8xH100 写出这么多硬件定制路径。

8. 如果你也要复现，按这份最小检查清单先走

在你下一次git clone之前，我建议先把下面 6 件事看一遍：

[ ] 先看 README，确认它写的是 8xH100 speedrun，而不是通用教程 [ ] 先查设备 capability，区分 Ampere / Ada / Hopper [ ] 先 grep 仓库里有没有写死的 sm90 / Hopper kernel [ ] 先确认注意力实现是不是直接绑了 FA3/TMA 路径 [ ] 先做 no-compile 的最小 warmup 诊断，不要一开始就追 full run [ ] 先决定你要的是“学习训练工程”还是“追 record”

如果这 6 步里前 4 步都没做，你很可能会在错误方向上消耗一整天。

参考与延伸阅读

• modded-nanogpt仓库主页：https://github.com/KellerJordan/modded-nanogpt
• • README（current record / 8xH100 / compile 延迟说明）：https://github.com/KellerJordan/modded-nanogpt/blob/master/README.md
• • triton_kernels.py中 fused CE kernel 的compute_capability="90"：https://github.com/KellerJordan/modded-nanogpt/blob/master/triton_kernels.py
• • train_gpt.py中flash-attention-3路径：https://github.com/KellerJordan/modded-nanogpt/blob/master/train_gpt.py
• • Issue #29：consumer GPU / 4090 复现讨论：https://github.com/KellerJordan/modded-nanogpt/issues/29
• • PR #38：面向 RTX 4090/3090 的适配讨论：https://github.com/KellerJordan/modded-nanogpt/pull/38
• • Issue #176：按 README 运行 current record 时的环境/内核问题：https://github.com/KellerJordan/modded-nanogpt/issues/176

本文所有结论都基于 2026-04-30 对 current master 的源码阅读、Issue/PR 调研，以及本地 RTX 3090 的最小复现实验。文中没有宣称“3090 绝对跑不了这个项目的所有变体”，而是明确指出：current master 的默认关键路径，已经明显偏向 Hopper speedrun，而不是消费卡开箱即用。