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不是portabilityREADME 写得很明确当前记录是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.1cu128 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 我实际做了什么为了避免“没跑就写”我做了三层验证直接 clone 当前仓库读取 README、train_gpt.py、triton_kernels.py。在本地导入仓库里的triton_kernels.py看 fused kernel 能不能先过导入这一关。做一份诊断用的最小 probe保留仓库主干逻辑把数据缩小、步数缩短、跳过torch.compile只验证 warmup 是否能在单卡 3090 上启动。这第三步我要特别说明我不是在声称“我成功改好了 consumer 版”。这个 probe 的目的只是定位第一层硬阻塞不是追求最终 loss。我甚至故意关掉了torch.compile因为我不想让 7 分钟编译时间掩盖更底层的硬件兼容问题。换句话说这是一篇“实测定位边界”的文章不是“我已经给你交付一套 3090 最优配置”。3. 第一处硬阻塞不是显存而是sm90被写死在 fused CE kernel 里我先看的不是模型结构而是仓库里最容易决定“能不能起”的底层文件triton_kernels.py。这里有一段非常关键的代码ce_fwd_bwd_kerneltorch.cuda._compile_kernel(CE_KERNEL_DECLSCE_KERNEL_SOURCE,ce_fwd_bwd_kernel,compute_capability90,cuda_include_dirs[/usr/local/cuda/include/],nvcc_options[-lineinfo,--use_fast_math],) 这意味着什么-compute_capability90 指向的是 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_capability90那你在消费卡上遇到的第一个问题大概率不是 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_node1 更小 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 配置这些经验非常有价值但要注意两点它们更接近“社区适配路线”不是 current master 默认开箱即用的能力。仓库在继续追 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_capability90的 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 消费卡我更建议这样用它你的目标我建议的起点想理解 GPT 训练主流程先看llm.c或更朴素的NanoGPT想学习 speedrun 思路再回来看modded-nanogpt的 record、PR 和内核实现想本地真跑起来做实验先做 consumer-friendly fallback再谈追当前 master想直接复刻 README 成绩默认按 H100/Hopper 项目看待不要按 3090 教学项目看待我最后给出三条可以直接带走的判断当前 master 在 consumer GPU 上最先撞上的通常不是显存而是 Hopper-only kernel 假设。如果你的目标是学习训练工程先让它“能跑”比先让它“跑得像 record 一样快”更重要。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-nanogptREADMEcurrent record / 8xH100 / compile 延迟说明https://github.com/KellerJordan/modded-nanogpt/blob/master/README.mdtriton_kernels.py中 fused CE kernel 的compute_capability90https://github.com/KellerJordan/modded-nanogpt/blob/master/triton_kernels.pytrain_gpt.py中flash-attention-3路径https://github.com/KellerJordan/modded-nanogpt/blob/master/train_gpt.pyIssue #29consumer GPU / 4090 复现讨论https://github.com/KellerJordan/modded-nanogpt/issues/29PR #38面向 RTX 4090/3090 的适配讨论https://github.com/KellerJordan/modded-nanogpt/pull/38Issue #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而不是消费卡开箱即用。