企业官网建设流程全解析

• 人工智能
• 大模型
• 预训练
• 分布式训练
• 模型优化
• 深度学习

本指南以 baseline_pr299 统计文档 为核心，讲解 modded-nanogpt Track 1 速度冲刺中"从最佳出发递归验证（Recursive from-best）"的基线复现方法：如何在完全相同的 8× H100 硬件上重跑上一代世界纪录 #83，并通过 10 次运行的 val_loss 与 train_time 统计数据，用单边单样本 t 检验判定方案是否在统计意义上达成目标（p(mean<3.28) = 0.0047）。读完本文，你将掌握该仓库记录验证体系的完整数据口径、检验公式与 Verifier 输出解读方法，并能据此复现或检验一次速度冲刺提交。

实验背景：为什么速度记录必须"同硬件重跑"

modded-nanogpt 的 Track 1 速度冲刺（short track）目标是在极短墙钟时间内把 124M 参数的 GPT 训练到目标验证损失。跨硬件、跨环境的训练耗时与收敛结果天然不可直接比较——上一代世界纪录 #83（"Sign Trick on Bigram Embed"）是在特定硬件上取得的，新提交若要证明"更快"，就必须先在同一套硬件上重跑 #83 作为公平基线。

这正是 2026-06-11_RecursiveFromBest 目录 所描述的 "Recursive from-best" 实验设计：将 World Record #83 在相同的 8× NVIDIA H100 80GB Modal 集群上重跑（baseline_pr299，10 次），再与新的提交方案（this_pr，13 次）对照。整个对照关系如下表（来源：README.md）：

值得注意的是，#83 官方成绩仅记录了 79.7s 的训练耗时，而 val_loss 与统计显著性在官方记录中缺失——这正是baseline_pr299的价值所在：在同一硬件上补全基线的高质量统计画像，使后续提交具备严格的可比基准。

基线重跑数据全览：10 次运行完整清单

baseline_pr299/statistics.md记录了 10 次完整运行，全部在相同的 8× H100 硬件上执行到 step 1385/1385。每次运行对应仓库中一份 UUID 命名的自包含训练日志（如 0527c136-3141-4b73-a460-167696b3e227.txt）：

可以看到 10 次运行的 val_loss 波动极小（3.2762 ~ 3.2805），训练耗时同样高度稳定（80341 ~ 81143ms），这为统计检验提供了非常干净的样本。该文档随后给出汇总统计：

单边单样本 t 检验：p(mean<3.28) = 0.0047 是怎么算出来的

基线统计文档的核心结论是一行：

p(val_loss < 3.28) = 0.0047

其检验方法在文档中明确给出——单边（one-sided）单样本 t 检验：

scipy.stats.ttest_1samp(accs, 3.28, alternative="less").pvalue

这里accs是 10 次运行的 val_loss 序列，原假设为mean(val_loss) >= 3.28，备择假设为mean(val_loss) < 3.28。检验统计量为标准的单样本 t 统计量：

t = (x̄ - μ₀) / (s / √n) = (3.27850 - 3.28) / (0.00144 / √10) ≈ -3.29

即观测到的均值（3.27850）比目标阈值 3.28 低了约 1.5 个千分点，而标准误（standard error）只有约 0.00046，二者比值（t 值约 -3.287）远超单侧 5% 临界值；自由度 df = n - 1 = 9 时，对应的单边 p 值约为 0.0047。换句话说：在 5% 显著性水平下，可以拒绝"真实均值不低于 3.28"的原假设，即该配置在统计意义上达成了目标验证损失，且这一结论并非由单次运行的运气驱动。

Verifier 输出逐字段解读

统计文档末尾给出了验证器（Verifier）的标准输出格式：

n=10 val_loss=3.2785±0.0014 t=-3.287 p(mean<3.28)=0.00471 time=80.61±0.22s

各字段含义如下：

这一格式在仓库的其他统计文档中保持一致，例如 this_pr 统计文档 输出为n=13 val_loss=3.2789±0.0014 t=-2.815 p(mean<3.28)=0.007803 time=77.34±0.20s，便于跨提交直接比对。

复现路径：日志自包含脚本与 8 卡运行

基线与提交的每次运行日志（baseline_pr299/*.txt、this_pr/*.txt）都是自包含的完整训练脚本：文件开头即通过open(sys.argv[0])与open(triton_kernels.py)把训练代码与 Triton 内核源码完整打印进日志，因此任意一次运行都可以从日志本身逐行还原，无需额外配置。

在仓库根目录的 run.sh 中定义了标准的 8 卡启动方式：

torchrun --standalone --nproc_per_node=8 train_gpt.py

对照训练脚本（见 78e1d055-ea56-48ee-ac24-e082795490dd.txt）中的调度配置，可以确认几个关键统计口径：

• 步数来源：num_scheduled_iterations=1387+num_extension_iterations=11= 1398 步（对应 this_pr 统计文档的 step 1398/1398；基线为 1385/1385）。
• 验证集口径：val_tokens=10485760（固定验证 token 数，保证跨运行、跨提交一致可比）。
• 计时口径：脚本先执行约 7 分钟的"warmup kernels"编译预热阶段，随后load_state_dict重置到初始状态再开始计时——测量出的 train_time 已排除编译开销，是纯粹的稳态训练耗时。
• 数据流：Train/Val 均为 FineWeb token 流，且不使用额外的torch._inductor.config或 compile 标志，保证实验变量单一。

与提交方案 this_pr 的对照：更快还是更好？

将基线（80.61s ± 0.22s）与新提交（77.34s ± 0.20s）对照，可以看到本次 "Recursive from-best" 提交的定位：在 val_loss 统计显著性几乎持平的前提下（3.27850 vs 3.27893，p 值 0.00471 vs 0.0078，均显著低于 3.28），训练耗时降低了约 3.3 秒——这是一个典型的"速度冲刺"型改进，而非单纯追求更低损失。

该提交的主要改动（据 README.md）包括：

• 训练前向中 QKV 与 O 注意力投影使用FP8（torch._scaled_mm+ 自定义nanogpt::mm_t算子，权重以转置布局存储以加速梯度累加）；
• NorMuon 优化器中引入退火的行 RMS 缩放 Langevin/SGLD 探索噪声，在 cooldown 阶段归零，让最终迭代稳定落入（期望更平坦的）盆底；
• bigram 与 value-embedding 参数池改用C-Optim / cautious Adam（符号一致掩码 + 归一化），其实现对应训练脚本中的_adam_update_step_coptim；
• 更精简的fused ReLU² MLP Triton 内核：前向存储post = relu(pre)²，反向由sqrt(post)重建pre，减少中间量；
• 调度/架构微调：更少的 paired-head 层、全程 tied embedding、步数与窗口调整。

实验纪律：让统计结论可信的四个前提

总结baseline_pr299统计文档体现出的验证纪律，也是复现该类统计时必须遵循的前提：

1. 同硬件对照：基线必须在与提交完全相同的硬件环境（本实验为 Modal 8× NVIDIA H100 80GB、PyTorch 2.10.0+cu128、Triton 3.6.0）上重跑，杜绝跨机器比较。
2. 多次运行：单次运行的 val_loss 有随机性（10 次观测 std 约 0.0014），必须用 n≥10 的重复运行 + 统计检验取代单次抽签。
3. 固定验证口径：固定val_tokens与验证流程，使每次运行的损失数值直接可比。
4. 排除编译开销：预热后重置再计时，train_time 反映稳态训练速度而非编译时间；同时不引入额外 compile 标志，避免不公平加速。

这套"从最佳出发、同硬件重跑、多 run 统计、单边 t 检验判定"的闭环，正是 modded-nanogpt 速度冲刺记录能够持续迭代且结论可信的核心方法论。

• 人工智能
• 大模型
• 预训练
• 分布式训练
• 模型优化
• 深度学习