尧图网页设计 
人工智能大模型预训练分布式训练模型优化深度学习【免费下载链接】modded-nanogptNanoGPT (124M) in 90 seconds项目地址https://gitcode.com/GitHub_Trending/mo/modded-nanogpt点击查看免费下载modded-nanogpt 的 track 2medium赛道上有一类看似零成本的调优不引入新算子、不改模型结构只调整学习率调度曲线。本文以 2025-03-06 的记录 LongerCooldown 为核心完整还原一次把学习率冷却cooldown阶段从总时长的 40% 拉长到 60%、同时把训练步数从 7050 减到 6950的实验并结合配套训练脚本与当前仓库的调度源码讲清冷却阶段的数学含义、实现方式与统计验证方法。读完本文你将掌握 modded-nanogpt 风格学习率调度的核心参数并能够复现这类同预算下降低验证损失的超参实验。一次只改调度的记录背景与动机track 2 的目标是什么modded-nanogpt 仓库中 track 2medium赛道最初的任务是匹配 Karpathy 用 llm.c 在 30B tokens 上训练 350M 参数模型所达到的性能。根据 2024-12-31_Target350M 记录首条记录在 8×H100 上约 26 分钟达到约 2.95 的验证损失。此后该赛道上每一份记录都在同一评估协议固定验证 token 数、固定算力预算下通过调整优化器、调度与架构细节逐点压低验证损失。本记录的两处改动LongerCooldown 记录 的 Changelog 只有两行将学习率冷却阶段时长从总训练时长的40% 增加到 60%将训练步数从7050 减少到 6950。记录作者为 YouJiacheng。这两处改动是配套的步数减少意味着同样训练时长内多出约 100 步的预算余量在本记录的实际日志中总耗时约 1631 秒步均约 234.7ms100 步约对应 23 秒而更长的冷却阶段则把这段省下来的预算全部投入到学习率衰减最剧烈的收尾阶段让模型在最后阶段更充分地收敛。为什么冷却阶段值得单独调在超大规模 token 预算训练中学习率往往遵循先稳定stable后衰减decay的两段式策略训练前半程保持接近峰值的学习率快速推进后半程线性或按曲线衰减到接近 0从而在有限的预算内把参数打磨到更低的损失。冷却阶段占全程的比例本记录中记为cooldown_frac直接决定了平稳期与打磨期的分界线比例太小模型大部分时间在高学习率下震荡损失在末端来不及充分下降比例太大则平稳期过短模型可能尚未充分探索就被迫降速。因此cooldown_frac是一个几乎零额外计算成本、但对最终验证损失有显著影响的调度超参。冷却阶段的实现从记录脚本到当前仓库源码记录脚本中的 get_lr配套的完整训练脚本 779c041a-2a37-45d2-a18b-ec0f223c2bb7.txt 中与本次改动直接相关的有两处num_iterations 6950 # number of iterations to run cooldown_frac 0.6 # fraction of training spent cooling down the learning rate - increased by YouJiacheng以及学习率函数def get_lr(step: int): x step / args.num_iterations # progress in training assert 0 x 1 if x 1 - args.cooldown_frac: return 1.0 else: return (1 - x) / args.cooldown_frac注意该函数返回的是相对倍率相对各优化器参数组的initial_lr训练循环中再乘回去for opt in optimizers: for group in opt.param_groups: group[lr] group[initial_lr] * get_lr(step)从公式可以看出当训练进度x 1 - cooldown_frac时学习率保持为峰值乘数 1.0进入冷却段后学习率从 1.0 线性衰减在x 1时精确降为 0。cooldown_frac 0.6意味着最后 60% 的训练步数都处于线性衰减中衰减斜率即(1 - x) / cooldown_frac的斜率比 0.4 时更平缓。当前仓库中的同源实现这一调度思想在仓库当前代码中被进一步参数化集中在 track_1_short/schedule.py 的TrainingSchedule.get_lr中def get_lr(self, step: int) - float: # learning rate schedule: tied to batch size schedule, with cooldown at the end stage, _ self.lookup(step) lr stage.lr_mul cd_start int(self.scheduled_iterations * (1 - self.cooldown_frac)) if step cd_start: t min(1.0, (step - cd_start) / (self.scheduled_iterations - cd_start)) lr lr * (1 - t) LR_FLOOR * t return lr对比可见两处关键差异冷却起始点相同cd_start scheduled_iterations * (1 - cooldown_frac)与本记录中x 1 - cooldown_frac的判断完全对应衰减终点不同当前实现不再把学习率衰减到 0而是线性衰减到LR_FLOOR这个绝对乘数schedule.py 顶部注释表明这是记录 #360 的代码README 中写的数值为 0.20代码中取LR_FLOOR 0.30同时冷却比例进一步拉长——track_1_short/config.py 中的LR_COOLDOWN_FRAC 0.80表明后续记录已将冷却阶段扩展到主阶段时长的 80%。这说明延长冷却阶段并非一次性技巧而是被后续记录持续复用的调度设计主线从 40% → 60% → 80%衰减终点也从 0 改为非零 floor配合批大小调度batch 8 → 16 → 24 → 20 收尾共同工作。实验结果36 次运行的统计验证原始数据README 给出了 36 次独立运行的最终验证损失列表[2.9199, 2.9185, 2.9195, 2.9194, 2.9206, 2.9209, 2.9188, 2.9193, 2.9207, 2.9181, 2.9186, 2.9196, 2.9202, 2.9174, 2.9185, 2.9197, 2.9179, 2.9204, 2.9184, 2.9186, 2.9178, 2.9192, 2.9194, 2.9194, 2.9189, 2.9193, 2.9212, 2.9181, 2.9192, 2.9203, 2.9198, 2.9192, 2.919, 2.9196, 2.9182, 2.9186]对这 36 个数据点可以直接计算的统计量均值约2.9192最小值 2.9174最大值 2.9212整体分布在 ±0.002 的窄带内方差极小。记录作者给出的结论是P(2.92) 99.9%即这批运行的最终验证损失几乎必然落在 2.92 之下。单次运行日志佐证同目录记录文件的日志末尾约第 7703 行给出了这次改动的实际运行结果step:6950/6950 val_loss:2.9184 train_time:1631354ms step_avg:234.73ms peak memory allocated: 59737 MiB reserved: 70818 MiB最终验证损失2.9184与 36 次运行的均值高度一致总训练耗时约1631.35 秒约 27.2 分钟8×H100步均约 234.73ms峰值显存约 59.7 GiB保留 70.8 GiB。需要说明的是这份日志记录于 2025-03-08运行环境为 PyTorch 2.7.0.dev CUDA 12.6、8×H100 80GB日志中的验证损失是固定验证 token 数val_tokens 10485760下多次前向的平均步均耗时包含每 125 步一次的验证开销。如何在自己的环境复现与验证准备数据按 data/fineweb10B 的格式准备好 FineWeb 10B 的 train/val.bin分片脚本中默认的train_files与val_filesglob 分别指向data/fineweb10B/fineweb_train_*.bin与fineweb_val_*.bin修改超参将记录脚本中Hyperparameters.num_iterations设为 6950、cooldown_frac设为 0.6或直接以 0.4 为对照跑一组 A/B 实验以torchrun在 8 卡环境启动脚本内assert world_size 8代码面向 8×H100 设计参考仓库根目录的 run.sh 的启动方式观察日志每 125 步输出一次val_loss最终步的验证损失即为报告口径统计口径上建议像本记录一样多次重复运行36 次并报告分布而不是依赖单次结果。若只需验证调度逻辑本身也可以直接阅读并单测 track_1_short/schedule.py 中的TrainingSchedule.get_lr构造不同cooldown_frac对比冷却曲线形状。小结与启示本记录给出一条非常经济的调优路径保持模型与优化器不变仅把学习率冷却阶段从 40% 延长到 60%、同步减少 100 步就在 36 次重复运行中稳定把验证损失压到 2.92 以下均值约 2.9192。其机制可以归纳为两点一是更长的冷却段让衰减斜率更平缓、末端收敛更充分二是削减步数释放的预算被更陡峭的打磨期吸收整体收益大于损失。这一思路在当前仓库的调度实现中已演化为更完整的形态——cooldown_frac被提升到 0.80 并配合LR_FLOOR非零衰减终点见 track_1_short/config.py 与 track_1_short/schedule.py。对于任何预算受限的大模型训练实验学习率冷却比例都是一个值得优先扫描的调度超参它不改变前向/反向计算却能在统计意义上显著改善最终验证损失。赞分享人工智能大模型预训练分布式训练模型优化深度学习【免费下载链接】modded-nanogptNanoGPT (124M) in 90 seconds项目地址https://gitcode.com/GitHub_Trending/mo/modded-nanogpt点击查看免费下载相关推荐modded-nanogpt 实验记录将 Token Value Embeddings 扩展至 5 个以更少步数取得更低验证损失modded nanogpt 实验记录将 Token Value Embeddings 扩展至 5 个以更少步数取得更低验证损失 本篇技术指南以 modde人工智能大模型预训练分布式训练模型优化深度学习modded-nanogpt 记录复盘BOS 对齐数据加载与学习率冷却再调优2025-07-12 BosAlignmodded nanogpt 记录复盘BOS 对齐数据加载与学习率冷却再调优2025 07 12 BosAlign 本篇以 modded nanogpt人工智能大模型预训练分布式训练模型优化深度学习Modded-NanoGPT 中的 SOAP 优化器实战3.15B Tokens 达成 3.28 验证损失的样本效率记录Modded NanoGPT 中的 SOAP 优化器实战3.15B Tokens 达成 3.28 验证损失的样本效率记录 本文基于 Modded NanoGP人工智能大模型预训练分布式训练模型优化深度学习上一篇Gutenberg ESLint 规则实战用 components-no-unsafe-button-disabled 保证禁用按钮的可访问性下一篇终极指南如何实现Lore机器学习模型的持续集成与持续部署创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 modded-nanogpt 学习率冷却阶段延长至 60%：以更少步数换更低验证损失的实战记录
人工智能大模型预训练分布式训练模型优化深度学习【免费下载链接】modded-nanogptNanoGPT (124M) in 90 seconds项目地址https://gitcode.com/GitHub_Trending/mo/modded-nanogpt点击查看免费下载modded-nanogpt 的 track 2medium赛道上有一类看似零成本的调优不引入新算子、不改模型结构只调整学习率调度曲线。本文以 2025-03-06 的记录 LongerCooldown 为核心完整还原一次把学习率冷却cooldown阶段从总时长的 40% 拉长到 60%、同时把训练步数从 7050 减到 6950的实验并结合配套训练脚本与当前仓库的调度源码讲清冷却阶段的数学含义、实现方式与统计验证方法。读完本文你将掌握 modded-nanogpt 风格学习率调度的核心参数并能够复现这类同预算下降低验证损失的超参实验。一次只改调度的记录背景与动机track 2 的目标是什么modded-nanogpt 仓库中 track 2medium赛道最初的任务是匹配 Karpathy 用 llm.c 在 30B tokens 上训练 350M 参数模型所达到的性能。根据 2024-12-31_Target350M 记录首条记录在 8×H100 上约 26 分钟达到约 2.95 的验证损失。此后该赛道上每一份记录都在同一评估协议固定验证 token 数、固定算力预算下通过调整优化器、调度与架构细节逐点压低验证损失。本记录的两处改动LongerCooldown 记录 的 Changelog 只有两行将学习率冷却阶段时长从总训练时长的40% 增加到 60%将训练步数从7050 减少到 6950。记录作者为 YouJiacheng。这两处改动是配套的步数减少意味着同样训练时长内多出约 100 步的预算余量在本记录的实际日志中总耗时约 1631 秒步均约 234.7ms100 步约对应 23 秒而更长的冷却阶段则把这段省下来的预算全部投入到学习率衰减最剧烈的收尾阶段让模型在最后阶段更充分地收敛。为什么冷却阶段值得单独调在超大规模 token 预算训练中学习率往往遵循先稳定stable后衰减decay的两段式策略训练前半程保持接近峰值的学习率快速推进后半程线性或按曲线衰减到接近 0从而在有限的预算内把参数打磨到更低的损失。冷却阶段占全程的比例本记录中记为cooldown_frac直接决定了平稳期与打磨期的分界线比例太小模型大部分时间在高学习率下震荡损失在末端来不及充分下降比例太大则平稳期过短模型可能尚未充分探索就被迫降速。因此cooldown_frac是一个几乎零额外计算成本、但对最终验证损失有显著影响的调度超参。冷却阶段的实现从记录脚本到当前仓库源码记录脚本中的 get_lr配套的完整训练脚本 779c041a-2a37-45d2-a18b-ec0f223c2bb7.txt 中与本次改动直接相关的有两处num_iterations 6950 # number of iterations to run cooldown_frac 0.6 # fraction of training spent cooling down the learning rate - increased by YouJiacheng以及学习率函数def get_lr(step: int): x step / args.num_iterations # progress in training assert 0 x 1 if x 1 - args.cooldown_frac: return 1.0 else: return (1 - x) / args.cooldown_frac注意该函数返回的是相对倍率相对各优化器参数组的initial_lr训练循环中再乘回去for opt in optimizers: for group in opt.param_groups: group[lr] group[initial_lr] * get_lr(step)从公式可以看出当训练进度x 1 - cooldown_frac时学习率保持为峰值乘数 1.0进入冷却段后学习率从 1.0 线性衰减在x 1时精确降为 0。cooldown_frac 0.6意味着最后 60% 的训练步数都处于线性衰减中衰减斜率即(1 - x) / cooldown_frac的斜率比 0.4 时更平缓。当前仓库中的同源实现这一调度思想在仓库当前代码中被进一步参数化集中在 track_1_short/schedule.py 的TrainingSchedule.get_lr中def get_lr(self, step: int) - float: # learning rate schedule: tied to batch size schedule, with cooldown at the end stage, _ self.lookup(step) lr stage.lr_mul cd_start int(self.scheduled_iterations * (1 - self.cooldown_frac)) if step cd_start: t min(1.0, (step - cd_start) / (self.scheduled_iterations - cd_start)) lr lr * (1 - t) LR_FLOOR * t return lr对比可见两处关键差异冷却起始点相同cd_start scheduled_iterations * (1 - cooldown_frac)与本记录中x 1 - cooldown_frac的判断完全对应衰减终点不同当前实现不再把学习率衰减到 0而是线性衰减到LR_FLOOR这个绝对乘数schedule.py 顶部注释表明这是记录 #360 的代码README 中写的数值为 0.20代码中取LR_FLOOR 0.30同时冷却比例进一步拉长——track_1_short/config.py 中的LR_COOLDOWN_FRAC 0.80表明后续记录已将冷却阶段扩展到主阶段时长的 80%。这说明延长冷却阶段并非一次性技巧而是被后续记录持续复用的调度设计主线从 40% → 60% → 80%衰减终点也从 0 改为非零 floor配合批大小调度batch 8 → 16 → 24 → 20 收尾共同工作。实验结果36 次运行的统计验证原始数据README 给出了 36 次独立运行的最终验证损失列表[2.9199, 2.9185, 2.9195, 2.9194, 2.9206, 2.9209, 2.9188, 2.9193, 2.9207, 2.9181, 2.9186, 2.9196, 2.9202, 2.9174, 2.9185, 2.9197, 2.9179, 2.9204, 2.9184, 2.9186, 2.9178, 2.9192, 2.9194, 2.9194, 2.9189, 2.9193, 2.9212, 2.9181, 2.9192, 2.9203, 2.9198, 2.9192, 2.919, 2.9196, 2.9182, 2.9186]对这 36 个数据点可以直接计算的统计量均值约2.9192最小值 2.9174最大值 2.9212整体分布在 ±0.002 的窄带内方差极小。记录作者给出的结论是P(2.92) 99.9%即这批运行的最终验证损失几乎必然落在 2.92 之下。单次运行日志佐证同目录记录文件的日志末尾约第 7703 行给出了这次改动的实际运行结果step:6950/6950 val_loss:2.9184 train_time:1631354ms step_avg:234.73ms peak memory allocated: 59737 MiB reserved: 70818 MiB最终验证损失2.9184与 36 次运行的均值高度一致总训练耗时约1631.35 秒约 27.2 分钟8×H100步均约 234.73ms峰值显存约 59.7 GiB保留 70.8 GiB。需要说明的是这份日志记录于 2025-03-08运行环境为 PyTorch 2.7.0.dev CUDA 12.6、8×H100 80GB日志中的验证损失是固定验证 token 数val_tokens 10485760下多次前向的平均步均耗时包含每 125 步一次的验证开销。如何在自己的环境复现与验证准备数据按 data/fineweb10B 的格式准备好 FineWeb 10B 的 train/val.bin分片脚本中默认的train_files与val_filesglob 分别指向data/fineweb10B/fineweb_train_*.bin与fineweb_val_*.bin修改超参将记录脚本中Hyperparameters.num_iterations设为 6950、cooldown_frac设为 0.6或直接以 0.4 为对照跑一组 A/B 实验以torchrun在 8 卡环境启动脚本内assert world_size 8代码面向 8×H100 设计参考仓库根目录的 run.sh 的启动方式观察日志每 125 步输出一次val_loss最终步的验证损失即为报告口径统计口径上建议像本记录一样多次重复运行36 次并报告分布而不是依赖单次结果。若只需验证调度逻辑本身也可以直接阅读并单测 track_1_short/schedule.py 中的TrainingSchedule.get_lr构造不同cooldown_frac对比冷却曲线形状。小结与启示本记录给出一条非常经济的调优路径保持模型与优化器不变仅把学习率冷却阶段从 40% 延长到 60%、同步减少 100 步就在 36 次重复运行中稳定把验证损失压到 2.92 以下均值约 2.9192。其机制可以归纳为两点一是更长的冷却段让衰减斜率更平缓、末端收敛更充分二是削减步数释放的预算被更陡峭的打磨期吸收整体收益大于损失。这一思路在当前仓库的调度实现中已演化为更完整的形态——cooldown_frac被提升到 0.80 并配合LR_FLOOR非零衰减终点见 track_1_short/config.py 与 track_1_short/schedule.py。对于任何预算受限的大模型训练实验学习率冷却比例都是一个值得优先扫描的调度超参它不改变前向/反向计算却能在统计意义上显著改善最终验证损失。赞分享人工智能大模型预训练分布式训练模型优化深度学习【免费下载链接】modded-nanogptNanoGPT (124M) in 90 seconds项目地址https://gitcode.com/GitHub_Trending/mo/modded-nanogpt点击查看免费下载相关推荐modded-nanogpt 实验记录将 Token Value Embeddings 扩展至 5 个以更少步数取得更低验证损失modded nanogpt 实验记录将 Token Value Embeddings 扩展至 5 个以更少步数取得更低验证损失 本篇技术指南以 modde人工智能大模型预训练分布式训练模型优化深度学习modded-nanogpt 记录复盘BOS 对齐数据加载与学习率冷却再调优2025-07-12 BosAlignmodded nanogpt 记录复盘BOS 对齐数据加载与学习率冷却再调优2025 07 12 BosAlign 本篇以 modded nanogpt人工智能大模型预训练分布式训练模型优化深度学习Modded-NanoGPT 中的 SOAP 优化器实战3.15B Tokens 达成 3.28 验证损失的样本效率记录Modded NanoGPT 中的 SOAP 优化器实战3.15B Tokens 达成 3.28 验证损失的样本效率记录 本文基于 Modded NanoGP人工智能大模型预训练分布式训练模型优化深度学习上一篇Gutenberg ESLint 规则实战用 components-no-unsafe-button-disabled 保证禁用按钮的可访问性下一篇终极指南如何实现Lore机器学习模型的持续集成与持续部署创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考