大模型NLP基础模型模型评测模型量化【免费下载链接】GLM-130BGLM-130B: An Open Bilingual Pre-Trained Model (ICLR 2023)项目地址https://gitcode.com/gh_mirrors/gl/GLM-130B点击查看免费下载本文以 GLM-130B 开源仓库中保存的训练日志 logs/main-log-en.md 为主线完整梳理 GLM-130BICLR 2023从架构设计、环境搭建、吞吐测试到 250 天实际训练过程中遇到的节点故障、多任务指令预训练不稳定、损失爆炸与梯度尖峰等真实工程问题以及团队对应的排查思路与超参调整方案。读完本文你将掌握 130B 级模型超大规模训练的关键配置要素、断点恢复策略以及大规模预训练稳定性调优的一手实战经验。一、模型基础信息130B 双语模型的硬件结构画像训练日志开篇给出了 GLM-130B 最核心的架构参数快照这是理解后续所有训练调优的基础配置项数值参数量130B层数layers70隐藏层维度hidden size12288FFN 隐藏维度ffn hidden size32768词表大小vocab size150000模型并行MP4流水线并行PP8全局批大小global batch size4224并行策略采用 MP 4、PP 8 的组合即 4 路张量并行叠加 8 级流水线并行共 32 个 GPU 参与模型切分。这一配置也与仓库中发布的推理配置相呼应——configs/model_glm_130b.sh 中默认MP_SIZE8说明训练与推理阶段使用了不同的并行切分权重需要在阶段间进行张量并行维度转换仓库提供 tools/convert_tp.py 完成该转换。架构组合GLMGeneral Language Model自回归空白填充 Rotary Positional EmbeddingRoPE 旋转位置编码 GeGLU门控线性单元 DeepNorm深层残差归一化。数值稳定性设计使用 FP32 softmax 并带 QKV scaling不启用 PB-Relax保证注意力权重计算在混合精度训练下的精度。Embedding 梯度收缩Shrink embedding gradient初始 alpha 0.1即 embedding 层梯度被收缩到原来的 10%用于缓解 embedding 层在大词表 大模型场景下的更新过猛问题。全局批大小 4224由后续速度测试可知这对应 96 个节点、每节点 batch size 176 的组合176 × 24 4224。对应地仓库中 configs/model_glm_130b.sh 给出了推理侧同一模型的完整参数化表达MODEL_TYPEglm-130b CHECKPOINT_PATHyour checkpoint path MP_SIZE8 MODEL_ARGS--model-parallel-size ${MP_SIZE} \ --num-layers 70 \ --hidden-size 12288 \ --inner-hidden-size 32768 \ --vocab-size 150528 \ --num-attention-heads 96 \ --max-sequence-length 2048 \ --tokenizer-type icetk-glM-130B \ --layernorm-order post \ --load ${CHECKPOINT_PATH} \ --skip-init \ --fp16可以看到训练日志中的 70 层、12288 隐藏维度、32768 FFN 维度与配置脚本完全一致词表 150000日志与 150528配置icetk 实际补齐为 8 的倍数的细微差异正好体现了词表在对齐到张量并行维度时的 padding 过程。二、训练环境与软件栈训练日志记录了 130B 模型实际训练所用的软件环境PyTorch 1.11/CUDA 11.3LargeScale400893da37bb5cbe22c29e41c02a052369cc72ce自研大规模训练框架GLM-130B 官方训练基于 SAT/SwissArmyTransformer 体系的 LargeScale 代码库日志中固化了该 commit 版本号保证训练可复现性。DeepSpeed 0.6.1用于优化器状态分片、混合精度与分布式训练支撑。apexmaster提供 Fused Adam 等融合算子。与之对照当前仓库面向推理/评测的推荐环境见 README.md为 Python 3.9 / CUDA 11 / PyTorch 1.10 / DeepSpeed 0.6且需要安装带 CUDA 与 C 扩展的 Apexrequirements.txt 则列出SwissArmyTransformer0.2.12,0.3、icetk、apex、scipy、dataclass_wizard、cpm_kernels。训练与推理共用同一 GLM 模型家族initialize.py 中from SwissArmyTransformer.model import GLM130B环境要求整体一致。三、吞吐测试不同 Batch Size 下的训练性能基准在正式训练启动前团队先在 96 节点规模上做了两轮吞吐测试以确定可行的批大小与训练吞吐节点数Batch Size计算吞吐每迭代耗时样本吞吐96 nodesBSZ 176 × 24 4224134 TFLOPS88.5 s/iter48 samples/s96 nodesBSZ 256 × 24 6144141 TFLOPS122.5 s/iter50 samples/s对应检查点glm-130B-2022.05.05-19:34:16与glm-130B-2022.05.05-19:43:13。两个数据点清晰展示了超大规模训练的经典权衡增大批大小可以把单步计算效率从 134 TFLOPS 提升到 141 TFLOPS计算吞吐更优但每迭代耗时从 88.5s 增长到 122.5s样本吞吐仅从 48 提升到 50 samples/s边际收益明显递减。最终团队选择了 4224 的全局批大小作为正式训练配置对应 176×24。仓库中的 benchmark.py 提供了这一基准思路的推理侧延续——对 512/1024/2048 三种序列长度分别计时打印编码耗时毫秒适合在自有硬件上快速验证模型前向性能。四、训练时间线复盘从启动到完成的真实工程战役正式训练于2022-05-06 04:00启动检查点glm-130B-2022.05.05-19:53:15。接下来的两个多月里团队经历并逐一解决了下述一系列工程与算法问题。这些记录来自真实训练过程对任何进行千亿级模型训练的团队都有直接的参考价值。4.1 节点故障与断点恢复把保存间隔从 500 步缩短到 100 步超大规模训练的第一个主题是故障是常态2022-05-07节点 n30041、n30157 宕机。原保存间隔为 500 步间隔过长改为100 步从第 4000 步恢复训练检查点glm-130B-2022.05.07-13:44:59。2022-05-11节点 n30115 宕机从第 7300 步恢复glm-130B-2022.05.11-05:55:32。2022-05-20节点 n30066 宕机先从 15400 步恢复glm-130B-2022.05.19-19:56:19随后切换到另一个节点池从 15600 步恢复glm-130B-2022.05.20-01:58:57。2022-05-22节点 n30126 断连从 16700 步附近恢复glm-130B-2022.05.22-14:15:41。2022-05-26节点 n30039 报告 GPU 缺失从 17800 步附近恢复glm-130B-2022.05.25-22:23:12。2022-05-30 14:00同时出现节点故障与Lustre 文件系统故障——无法读取 2.3T 文本语料且工程师无法恢复数据只能从备份盘将数据重新拷回文件系统耗时数天。检查点从 global_step23200 恢复glm-130B-2022.05.31-02:18:24。注意此处暴露了大规模训练对共享存储可用性的强依赖检查点完整性与数据冗余备份同等重要。2022-06-02节点 n30145 CPU 错误从 25000 步恢复glm-130B-2022.06.02-04:35:05。2022-06-06节点集群例行维护升级时间较长期间意外收获是文件系统读取速度显著提升——加载检查点从原来的耗时降到仅需 1 分钟。2022-06-08节点故障从 27600 步附近恢复glm-130B-2022.06.08-00:00:37。2022-06-09训练意外终止怀疑网络通信问题从 23100 步恢复注意这里回退步数较多说明存在数据顺序与检查点对齐问题glm-130B-2022.06.09-05:27:54。2022-06-19节点 n30085 宕机从 39600 步恢复glm-130B-2022.06.18-17:49:53。2022-06-26出现意外的NVLink Error重启训练glm-130B-2022.06.26-13:13:51。经验总结130B 规模训练中节点级故障以周为单位出现断点保存间隔是恢复成本的关键杠杆500 步 → 100 步每次恢复都需记录从哪个 global step 续跑且检查点命名glm-130B-YYYY.MM.DD-HH:MM:SS是追踪每次重启的天然索引。4.2 Embedding 梯度收缩alpha的动态调整0.1 → warmup 到 1 → 1.0 → 0.5 → 0.1这是日志中贯穿始终的一条调优主线也最能体现训练团队的系统辨识式诊断风格初始设定alpha 0.1即把 embedding 梯度收缩 10 倍。2022-05-10团队判断 0.1 太小决定将 alpha 从第 6000 步起、用 500 步线性 warmup 到 1.0命令参数为--shrink-embedding-gradient-steps 6000 500对应检查点glm-130B-2022.05.09-16:02:04。2022-05-30发现此前的 warmup 步数实现存在 bug——实际生效的是 26850 步而非期望的 6000 步。改为按绝对样本数实现 warmup从 global_step23200 重新启动。2022-06-12第 33700 步损失爆炸将 shrink 从 1.0 降到0.5从 33600 步恢复glm-130B-2022.06.12-02:20:49。2022-06-14第 35250 步再次损失爆炸行为与 33700 步几乎一致、毫无征兆地崩溃将 shrink 从 0.5 进一步降到0.1从 35200 步恢复glm-130B-2022.06.14-02:28:21。机制解读embedding 层梯度收缩本质是给词向量更新加阻尼。alpha 太小会让 embedding 学习过慢初期选择 0.1但训练中后期、尤其是多任务数据加入后embedding 更新过猛又直接诱发损失爆炸1.0 时连续两次爆炸最终回到 0.1。日志中--shrink-embedding-gradient-steps这一参数形态起止步数 warmup 区间也在警告我们梯度收缩类超参不仅要有目标值还必须定义生效的时间窗与过渡方式。4.3 多任务指令预训练MIP的引入与三次反复数据分布突变是最大的不稳定源GLM-130B 的一个独有特点是加入 Multi-task Instruction Pre-trainingMIP数据但这条路线走得极为曲折日志完整记录了三次尝试—发散—回退2022-05-28 11:50将 MIP 数据更换为正确的英文 中文数据从 22800 步恢复glm-130B-2022.05.28-03:52:26原检查点与events.out.tfevents.1653709957...abolished废弃。2022-05-28 16:50新 MIP 数据英文 中文在第 22900 步直接导致NaN loss。诊断结论中文多任务数据中噪声过多于是切换为vanilla T0 训练数据集glm-130B-2022.05.28-09:18:12。2022-05-28 20:50Vanilla T0 数据集仍然导致发散disconvergence。团队推测是任务比例改变引入的不稳定等价于突然加入新任务因此加入参数--warmup-samples-after-loading 2112000即从 22800 步起用 2112000 个样本约 500 步 × 4224 全局批大小做 warmupglm-130B-2022.05.28-12:57:24。2022-05-29 01:30warmup 结束后再次发散。推测分布变化仍然过大决定只用自监督预训练 数据重排从 22800 步重新加载glm-130B-2022.05.28-18:05:33global_step23200_text检查点。2022-05-29自监督预训练看起来稳定于是尝试用逐步升温的正确 T0 数据比例来平滑分布迁移glm-130B-2022.05.29-05:17:06。2022-05-29 22:40仍然发散新增判断——这个过程中学习率也需要 warmup。最终方案从 22800 步重启同时 warmup 正确 MIP 数据比例和学习率2000 步并用 6000 步把 embedding 梯度收缩 alpha 从 0.2 warmup 到 1glm-130B-2022.05.29-17:35:45。2022.05.03 20:00 之后注意日志此处日期笔误为 2022.05.03按其上下文应为 05-31 之后的续接记录保持原有 warmup 流程把DeepStruct 数据加入 MIP 部分从 23500 步恢复。2022-06-01 22:22发现 T0qqp与 DeepStruct 各有一条带噪声的 prompt分别移除后从 24500 步恢复glm-130B-2022.06.01-14:24:33。2022-06-02 12:00warmup 流程已结束移除之。经验总结MIP 的三次失败都指向同一个根因——新增数据的分布迁移distribution shift过大直接硬切必发散。正确解法是一套组合拳数据比例 warmup 学习率 warmup embedding 梯度收缩 warmup三者同步渐进过渡。这也解释了为何最终训练配置里需要--warmup-samples-after-loading这类按样本数而非按步数计量的 warmup 参数——在大批量场景下步数与样本数的时间粒度差异显著。4.4 损失爆炸Loss Explosion与梯度尖峰Gradient Spike的诊断训练中后期出现了两类经典的数值不稳定事件日志给出了非常完整的第一手观测第一次损失爆炸2022-06-12第 33700 步观测序列loss-scale 在 33710 步附近急剧下降 → 33740 步损失爆炸。这本质上是混合精度训练中典型的动态 loss-scale 反馈链梯度溢出 → loss-scale 骤降 → 若此时模型状态已劣化则表现为损失爆炸。处置从 33600 步恢复shrink 从 1.0 → 0.5见 4.2。第二次损失爆炸2022-06-14第 35250 步与 33700 步几乎相同的行为毫无征兆地崩溃。处置从 35200 步恢复shrink 从 0.5 → 0.1见 4.2。第三次损失爆炸2022-06-20 09:10约第 40800 步处置方式升级为跳步跳过噪声数据段--skip-train-iteration-range 40701-40900从 40700 步恢复跳过 40701–40900 步间的噪声数据glm-130B-2022.06.20-03:36:13。梯度尖峰事件2022-06-22第一次10:40gradient norm 出现尖峰看似能自动恢复但训练损失经历剧烈变化。处置从 42400 步恢复并用--skip-train-iteration-range 42401-42600跳过对应数据段glm-130B-2022.06.22-02:38:20。第二次21:00gradient norm 再次出现尖峰但这次loss-scale 保持稳定团队判断可能自动恢复。同时基于近日反复出现的尖峰提出系统性推测——预训练后期学习率衰减过慢于是把最小学习率从 8e-6 降到 4e-6--min-lr 4e-6从 42700 步恢复glm-130B-2022.06.22-13:03:53。经验总结损失爆炸的处置有清晰递进层次①降低 embedding 梯度收缩系数 → ②用--skip-train-iteration-range直接跳过噪声数据段 → ③下调--min-lr加速后期学习率衰减。其中跳过数据段这一手段非常实用说明在大规模预训练中个别 batch 的噪声数据就足以在后期引发连锁崩溃而 loss-scale 的稳定性是判断是否自动恢复的关键观测指标。4.5 位置编码一致性修复统一 [MASK] 与 [gMASK] 的 position_id 实现2022-06-29 00:00从 48100 步恢复训练采用一个更一致的位置编码实现——原实现对[MASK]与[gMASK]两种掩码 token 使用了不同的 position_id 计算方式glm-130B-2022.06.29-13:53:21。这一点在仓库 README 中可以得到印证GLM-130B 在推理时确实区分[MASK]短空白填充与[gMASK]自左向右长文本生成两种掩码 token见 README.md 的 Left-To-Right Generation / Blank Filling 一节。训练中后期统一二者 position_id 的底层实现既消除了潜在的一致性偏差也使得推理时的位置编码行为更加确定。五、训练日志中的观测工具loss-scale、gradient norm 与损失曲线复盘整个日志团队的实际观测手段集中在三类信号上这也是 130B 级训练必备的仪表盘动态 loss-scale混合精度训练的缩放因子loss-scale 骤降是梯度溢出的第一信号33700 步爆炸前 30 步的 loss-scale 变化就是典型预警。gradient norm梯度范数尖峰检测的直读指标但需结合 loss-scale 是否同步波动来判断严重性6-22 的两次尖峰对比即是例证。分项损失打印2022-06-02 09:30 起从 25800 步打印 multitask loss2022-06-02 15:00 起打印 gpt/bert loss并据此判断——loss 下降缓慢可能归因于学习率过大于是从 26000 步把学习率减半glm-130B-2022.06.03-07:26:16。分项损失多任务损失 vs 自监督 gpt/bert 损失的独立监控是定位是哪个数据源出问题的关键手段。日志中出现的events.out.tfevents.*文件即为 TensorBoard 事件文件对应每次重启的曲线记录如glm-130B-33700、glm-130B-35250、glm-130B-40800用于跨重启对比损失走势——这是判断当前策略是否有效的重要工具。六、参数速查表与可复用的训练经验将日志中出现过的全部训练参数汇总如下供超大规模预训练配置直接参考参数日志中的取值作用global batch size422496 节点 × 176全局批量大小与吞吐测试结论绑定--shrink-embedding-gradient-steps6000 500从 6000 步起用 500 步将 embedding 梯度收缩 alpha warmup 到 1--warmup-samples-after-loading2112000数据加载后按绝对样本数 warmup约 500 步 × 4224--skip-train-iteration-range40701-40900、42401-42600跳过指定步数区间的噪声数据段--min-lr8e-6 → 4e-6预训练后期最小学习率降低以抑制梯度尖峰lr26000 步起减半针对 loss 下降缓慢的修正工程经验清单全部来自日志事实可直接迁移到同类大规模训练断点保存间隔500 步对 130B 训练过长100 步级别可显著降低故障恢复的成本与回退步数。数据即风险MIP 数据换新、任务比例调整、单条噪声 prompt都可能在后期触发发散或爆炸硬切数据分布几乎必失败必须用数据比例 学习率 梯度收缩的多重 warmup 平滑过渡。爆炸处置优先级降 embedding shrink → 跳数据段--skip-train-iteration-range→ 降--min-lr逐级递进。观测先行loss-scale、gradient norm、分项损失multitask / gpt / bert三件套是诊断数值崩溃的标配且每次重启都要留存 TensorBoard 事件文件便于跨段对比。基础设施不可忽视文件系统故障Lustre 读不了 2.3T 语料与 NVLink 错误同样是训练中断的大户检查点加载速度后期优化到 1 分钟直接影响恢复效率。七、结语从训练日志到开源仓库logs/main-log-en.md是一份极为罕见的透明化千亿模型训练记录它没有美化训练过程而是如实呈现了节点宕机、数据污染、损失爆炸、参数反复回退等真实细节。结合仓库中 configs/model_glm_130b.sh推理配置、initialize.py模型初始化与量化加载、docs/quantization.md推理量化等资源读者既可以按本文的时间线复盘 GLM-130B 的训练决策也可以直接上手其开源推理/评测链路。对任何计划训练 10B 以上规模模型的团队而言这份日志中的失败与回退远比成功曲线更有参考价值。赞分享大模型NLP基础模型模型评测模型量化【免费下载链接】GLM-130BGLM-130B: An Open Bilingual Pre-Trained Model (ICLR 2023)项目地址https://gitcode.com/gh_mirrors/gl/GLM-130B点击查看免费下载相关推荐GLM-130B引领未来的中英双语预训练模型GLM 130B引领未来的中英双语预训练模型 项目介绍 GLM 130B 是一款开源的中英双语预训练模型拥有惊人的 1300 亿个参数。该模型基于通用语言模大模型NLP基础模型模型评测模型量化如何快速上手GLM-130B开源双语预训练模型的完整指南如何快速上手GLM 130B开源双语预训练模型的完整指南 GLM 130B是一个强大的开源双语预训练模型支持中文和英文处理适用于自然语言理解、文本生成等多大模型NLP基础模型模型评测模型量化提升Redux性能reduce-reducers高级用法与最佳实践指南提升Redux性能reduce reducers高级用法与最佳实践指南 在Redux应用开发中随着项目复杂度的提升状态管理往往变得难以维护。 reduce上一篇ijkplayer OpenGL ES 2.0渲染引擎移动端高性能视频渲染终极指南下一篇Dolphin 服务菜单扩展指南3 个步骤打造自己的右键菜单功能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 GLM-130B 训练全记录：130B 双语预训练模型的架构、调参与工程复盘
大模型NLP基础模型模型评测模型量化【免费下载链接】GLM-130BGLM-130B: An Open Bilingual Pre-Trained Model (ICLR 2023)项目地址https://gitcode.com/gh_mirrors/gl/GLM-130B点击查看免费下载本文以 GLM-130B 开源仓库中保存的训练日志 logs/main-log-en.md 为主线完整梳理 GLM-130BICLR 2023从架构设计、环境搭建、吞吐测试到 250 天实际训练过程中遇到的节点故障、多任务指令预训练不稳定、损失爆炸与梯度尖峰等真实工程问题以及团队对应的排查思路与超参调整方案。读完本文你将掌握 130B 级模型超大规模训练的关键配置要素、断点恢复策略以及大规模预训练稳定性调优的一手实战经验。一、模型基础信息130B 双语模型的硬件结构画像训练日志开篇给出了 GLM-130B 最核心的架构参数快照这是理解后续所有训练调优的基础配置项数值参数量130B层数layers70隐藏层维度hidden size12288FFN 隐藏维度ffn hidden size32768词表大小vocab size150000模型并行MP4流水线并行PP8全局批大小global batch size4224并行策略采用 MP 4、PP 8 的组合即 4 路张量并行叠加 8 级流水线并行共 32 个 GPU 参与模型切分。这一配置也与仓库中发布的推理配置相呼应——configs/model_glm_130b.sh 中默认MP_SIZE8说明训练与推理阶段使用了不同的并行切分权重需要在阶段间进行张量并行维度转换仓库提供 tools/convert_tp.py 完成该转换。架构组合GLMGeneral Language Model自回归空白填充 Rotary Positional EmbeddingRoPE 旋转位置编码 GeGLU门控线性单元 DeepNorm深层残差归一化。数值稳定性设计使用 FP32 softmax 并带 QKV scaling不启用 PB-Relax保证注意力权重计算在混合精度训练下的精度。Embedding 梯度收缩Shrink embedding gradient初始 alpha 0.1即 embedding 层梯度被收缩到原来的 10%用于缓解 embedding 层在大词表 大模型场景下的更新过猛问题。全局批大小 4224由后续速度测试可知这对应 96 个节点、每节点 batch size 176 的组合176 × 24 4224。对应地仓库中 configs/model_glm_130b.sh 给出了推理侧同一模型的完整参数化表达MODEL_TYPEglm-130b CHECKPOINT_PATHyour checkpoint path MP_SIZE8 MODEL_ARGS--model-parallel-size ${MP_SIZE} \ --num-layers 70 \ --hidden-size 12288 \ --inner-hidden-size 32768 \ --vocab-size 150528 \ --num-attention-heads 96 \ --max-sequence-length 2048 \ --tokenizer-type icetk-glM-130B \ --layernorm-order post \ --load ${CHECKPOINT_PATH} \ --skip-init \ --fp16可以看到训练日志中的 70 层、12288 隐藏维度、32768 FFN 维度与配置脚本完全一致词表 150000日志与 150528配置icetk 实际补齐为 8 的倍数的细微差异正好体现了词表在对齐到张量并行维度时的 padding 过程。二、训练环境与软件栈训练日志记录了 130B 模型实际训练所用的软件环境PyTorch 1.11/CUDA 11.3LargeScale400893da37bb5cbe22c29e41c02a052369cc72ce自研大规模训练框架GLM-130B 官方训练基于 SAT/SwissArmyTransformer 体系的 LargeScale 代码库日志中固化了该 commit 版本号保证训练可复现性。DeepSpeed 0.6.1用于优化器状态分片、混合精度与分布式训练支撑。apexmaster提供 Fused Adam 等融合算子。与之对照当前仓库面向推理/评测的推荐环境见 README.md为 Python 3.9 / CUDA 11 / PyTorch 1.10 / DeepSpeed 0.6且需要安装带 CUDA 与 C 扩展的 Apexrequirements.txt 则列出SwissArmyTransformer0.2.12,0.3、icetk、apex、scipy、dataclass_wizard、cpm_kernels。训练与推理共用同一 GLM 模型家族initialize.py 中from SwissArmyTransformer.model import GLM130B环境要求整体一致。三、吞吐测试不同 Batch Size 下的训练性能基准在正式训练启动前团队先在 96 节点规模上做了两轮吞吐测试以确定可行的批大小与训练吞吐节点数Batch Size计算吞吐每迭代耗时样本吞吐96 nodesBSZ 176 × 24 4224134 TFLOPS88.5 s/iter48 samples/s96 nodesBSZ 256 × 24 6144141 TFLOPS122.5 s/iter50 samples/s对应检查点glm-130B-2022.05.05-19:34:16与glm-130B-2022.05.05-19:43:13。两个数据点清晰展示了超大规模训练的经典权衡增大批大小可以把单步计算效率从 134 TFLOPS 提升到 141 TFLOPS计算吞吐更优但每迭代耗时从 88.5s 增长到 122.5s样本吞吐仅从 48 提升到 50 samples/s边际收益明显递减。最终团队选择了 4224 的全局批大小作为正式训练配置对应 176×24。仓库中的 benchmark.py 提供了这一基准思路的推理侧延续——对 512/1024/2048 三种序列长度分别计时打印编码耗时毫秒适合在自有硬件上快速验证模型前向性能。四、训练时间线复盘从启动到完成的真实工程战役正式训练于2022-05-06 04:00启动检查点glm-130B-2022.05.05-19:53:15。接下来的两个多月里团队经历并逐一解决了下述一系列工程与算法问题。这些记录来自真实训练过程对任何进行千亿级模型训练的团队都有直接的参考价值。4.1 节点故障与断点恢复把保存间隔从 500 步缩短到 100 步超大规模训练的第一个主题是故障是常态2022-05-07节点 n30041、n30157 宕机。原保存间隔为 500 步间隔过长改为100 步从第 4000 步恢复训练检查点glm-130B-2022.05.07-13:44:59。2022-05-11节点 n30115 宕机从第 7300 步恢复glm-130B-2022.05.11-05:55:32。2022-05-20节点 n30066 宕机先从 15400 步恢复glm-130B-2022.05.19-19:56:19随后切换到另一个节点池从 15600 步恢复glm-130B-2022.05.20-01:58:57。2022-05-22节点 n30126 断连从 16700 步附近恢复glm-130B-2022.05.22-14:15:41。2022-05-26节点 n30039 报告 GPU 缺失从 17800 步附近恢复glm-130B-2022.05.25-22:23:12。2022-05-30 14:00同时出现节点故障与Lustre 文件系统故障——无法读取 2.3T 文本语料且工程师无法恢复数据只能从备份盘将数据重新拷回文件系统耗时数天。检查点从 global_step23200 恢复glm-130B-2022.05.31-02:18:24。注意此处暴露了大规模训练对共享存储可用性的强依赖检查点完整性与数据冗余备份同等重要。2022-06-02节点 n30145 CPU 错误从 25000 步恢复glm-130B-2022.06.02-04:35:05。2022-06-06节点集群例行维护升级时间较长期间意外收获是文件系统读取速度显著提升——加载检查点从原来的耗时降到仅需 1 分钟。2022-06-08节点故障从 27600 步附近恢复glm-130B-2022.06.08-00:00:37。2022-06-09训练意外终止怀疑网络通信问题从 23100 步恢复注意这里回退步数较多说明存在数据顺序与检查点对齐问题glm-130B-2022.06.09-05:27:54。2022-06-19节点 n30085 宕机从 39600 步恢复glm-130B-2022.06.18-17:49:53。2022-06-26出现意外的NVLink Error重启训练glm-130B-2022.06.26-13:13:51。经验总结130B 规模训练中节点级故障以周为单位出现断点保存间隔是恢复成本的关键杠杆500 步 → 100 步每次恢复都需记录从哪个 global step 续跑且检查点命名glm-130B-YYYY.MM.DD-HH:MM:SS是追踪每次重启的天然索引。4.2 Embedding 梯度收缩alpha的动态调整0.1 → warmup 到 1 → 1.0 → 0.5 → 0.1这是日志中贯穿始终的一条调优主线也最能体现训练团队的系统辨识式诊断风格初始设定alpha 0.1即把 embedding 梯度收缩 10 倍。2022-05-10团队判断 0.1 太小决定将 alpha 从第 6000 步起、用 500 步线性 warmup 到 1.0命令参数为--shrink-embedding-gradient-steps 6000 500对应检查点glm-130B-2022.05.09-16:02:04。2022-05-30发现此前的 warmup 步数实现存在 bug——实际生效的是 26850 步而非期望的 6000 步。改为按绝对样本数实现 warmup从 global_step23200 重新启动。2022-06-12第 33700 步损失爆炸将 shrink 从 1.0 降到0.5从 33600 步恢复glm-130B-2022.06.12-02:20:49。2022-06-14第 35250 步再次损失爆炸行为与 33700 步几乎一致、毫无征兆地崩溃将 shrink 从 0.5 进一步降到0.1从 35200 步恢复glm-130B-2022.06.14-02:28:21。机制解读embedding 层梯度收缩本质是给词向量更新加阻尼。alpha 太小会让 embedding 学习过慢初期选择 0.1但训练中后期、尤其是多任务数据加入后embedding 更新过猛又直接诱发损失爆炸1.0 时连续两次爆炸最终回到 0.1。日志中--shrink-embedding-gradient-steps这一参数形态起止步数 warmup 区间也在警告我们梯度收缩类超参不仅要有目标值还必须定义生效的时间窗与过渡方式。4.3 多任务指令预训练MIP的引入与三次反复数据分布突变是最大的不稳定源GLM-130B 的一个独有特点是加入 Multi-task Instruction Pre-trainingMIP数据但这条路线走得极为曲折日志完整记录了三次尝试—发散—回退2022-05-28 11:50将 MIP 数据更换为正确的英文 中文数据从 22800 步恢复glm-130B-2022.05.28-03:52:26原检查点与events.out.tfevents.1653709957...abolished废弃。2022-05-28 16:50新 MIP 数据英文 中文在第 22900 步直接导致NaN loss。诊断结论中文多任务数据中噪声过多于是切换为vanilla T0 训练数据集glm-130B-2022.05.28-09:18:12。2022-05-28 20:50Vanilla T0 数据集仍然导致发散disconvergence。团队推测是任务比例改变引入的不稳定等价于突然加入新任务因此加入参数--warmup-samples-after-loading 2112000即从 22800 步起用 2112000 个样本约 500 步 × 4224 全局批大小做 warmupglm-130B-2022.05.28-12:57:24。2022-05-29 01:30warmup 结束后再次发散。推测分布变化仍然过大决定只用自监督预训练 数据重排从 22800 步重新加载glm-130B-2022.05.28-18:05:33global_step23200_text检查点。2022-05-29自监督预训练看起来稳定于是尝试用逐步升温的正确 T0 数据比例来平滑分布迁移glm-130B-2022.05.29-05:17:06。2022-05-29 22:40仍然发散新增判断——这个过程中学习率也需要 warmup。最终方案从 22800 步重启同时 warmup 正确 MIP 数据比例和学习率2000 步并用 6000 步把 embedding 梯度收缩 alpha 从 0.2 warmup 到 1glm-130B-2022.05.29-17:35:45。2022.05.03 20:00 之后注意日志此处日期笔误为 2022.05.03按其上下文应为 05-31 之后的续接记录保持原有 warmup 流程把DeepStruct 数据加入 MIP 部分从 23500 步恢复。2022-06-01 22:22发现 T0qqp与 DeepStruct 各有一条带噪声的 prompt分别移除后从 24500 步恢复glm-130B-2022.06.01-14:24:33。2022-06-02 12:00warmup 流程已结束移除之。经验总结MIP 的三次失败都指向同一个根因——新增数据的分布迁移distribution shift过大直接硬切必发散。正确解法是一套组合拳数据比例 warmup 学习率 warmup embedding 梯度收缩 warmup三者同步渐进过渡。这也解释了为何最终训练配置里需要--warmup-samples-after-loading这类按样本数而非按步数计量的 warmup 参数——在大批量场景下步数与样本数的时间粒度差异显著。4.4 损失爆炸Loss Explosion与梯度尖峰Gradient Spike的诊断训练中后期出现了两类经典的数值不稳定事件日志给出了非常完整的第一手观测第一次损失爆炸2022-06-12第 33700 步观测序列loss-scale 在 33710 步附近急剧下降 → 33740 步损失爆炸。这本质上是混合精度训练中典型的动态 loss-scale 反馈链梯度溢出 → loss-scale 骤降 → 若此时模型状态已劣化则表现为损失爆炸。处置从 33600 步恢复shrink 从 1.0 → 0.5见 4.2。第二次损失爆炸2022-06-14第 35250 步与 33700 步几乎相同的行为毫无征兆地崩溃。处置从 35200 步恢复shrink 从 0.5 → 0.1见 4.2。第三次损失爆炸2022-06-20 09:10约第 40800 步处置方式升级为跳步跳过噪声数据段--skip-train-iteration-range 40701-40900从 40700 步恢复跳过 40701–40900 步间的噪声数据glm-130B-2022.06.20-03:36:13。梯度尖峰事件2022-06-22第一次10:40gradient norm 出现尖峰看似能自动恢复但训练损失经历剧烈变化。处置从 42400 步恢复并用--skip-train-iteration-range 42401-42600跳过对应数据段glm-130B-2022.06.22-02:38:20。第二次21:00gradient norm 再次出现尖峰但这次loss-scale 保持稳定团队判断可能自动恢复。同时基于近日反复出现的尖峰提出系统性推测——预训练后期学习率衰减过慢于是把最小学习率从 8e-6 降到 4e-6--min-lr 4e-6从 42700 步恢复glm-130B-2022.06.22-13:03:53。经验总结损失爆炸的处置有清晰递进层次①降低 embedding 梯度收缩系数 → ②用--skip-train-iteration-range直接跳过噪声数据段 → ③下调--min-lr加速后期学习率衰减。其中跳过数据段这一手段非常实用说明在大规模预训练中个别 batch 的噪声数据就足以在后期引发连锁崩溃而 loss-scale 的稳定性是判断是否自动恢复的关键观测指标。4.5 位置编码一致性修复统一 [MASK] 与 [gMASK] 的 position_id 实现2022-06-29 00:00从 48100 步恢复训练采用一个更一致的位置编码实现——原实现对[MASK]与[gMASK]两种掩码 token 使用了不同的 position_id 计算方式glm-130B-2022.06.29-13:53:21。这一点在仓库 README 中可以得到印证GLM-130B 在推理时确实区分[MASK]短空白填充与[gMASK]自左向右长文本生成两种掩码 token见 README.md 的 Left-To-Right Generation / Blank Filling 一节。训练中后期统一二者 position_id 的底层实现既消除了潜在的一致性偏差也使得推理时的位置编码行为更加确定。五、训练日志中的观测工具loss-scale、gradient norm 与损失曲线复盘整个日志团队的实际观测手段集中在三类信号上这也是 130B 级训练必备的仪表盘动态 loss-scale混合精度训练的缩放因子loss-scale 骤降是梯度溢出的第一信号33700 步爆炸前 30 步的 loss-scale 变化就是典型预警。gradient norm梯度范数尖峰检测的直读指标但需结合 loss-scale 是否同步波动来判断严重性6-22 的两次尖峰对比即是例证。分项损失打印2022-06-02 09:30 起从 25800 步打印 multitask loss2022-06-02 15:00 起打印 gpt/bert loss并据此判断——loss 下降缓慢可能归因于学习率过大于是从 26000 步把学习率减半glm-130B-2022.06.03-07:26:16。分项损失多任务损失 vs 自监督 gpt/bert 损失的独立监控是定位是哪个数据源出问题的关键手段。日志中出现的events.out.tfevents.*文件即为 TensorBoard 事件文件对应每次重启的曲线记录如glm-130B-33700、glm-130B-35250、glm-130B-40800用于跨重启对比损失走势——这是判断当前策略是否有效的重要工具。六、参数速查表与可复用的训练经验将日志中出现过的全部训练参数汇总如下供超大规模预训练配置直接参考参数日志中的取值作用global batch size422496 节点 × 176全局批量大小与吞吐测试结论绑定--shrink-embedding-gradient-steps6000 500从 6000 步起用 500 步将 embedding 梯度收缩 alpha warmup 到 1--warmup-samples-after-loading2112000数据加载后按绝对样本数 warmup约 500 步 × 4224--skip-train-iteration-range40701-40900、42401-42600跳过指定步数区间的噪声数据段--min-lr8e-6 → 4e-6预训练后期最小学习率降低以抑制梯度尖峰lr26000 步起减半针对 loss 下降缓慢的修正工程经验清单全部来自日志事实可直接迁移到同类大规模训练断点保存间隔500 步对 130B 训练过长100 步级别可显著降低故障恢复的成本与回退步数。数据即风险MIP 数据换新、任务比例调整、单条噪声 prompt都可能在后期触发发散或爆炸硬切数据分布几乎必失败必须用数据比例 学习率 梯度收缩的多重 warmup 平滑过渡。爆炸处置优先级降 embedding shrink → 跳数据段--skip-train-iteration-range→ 降--min-lr逐级递进。观测先行loss-scale、gradient norm、分项损失multitask / gpt / bert三件套是诊断数值崩溃的标配且每次重启都要留存 TensorBoard 事件文件便于跨段对比。基础设施不可忽视文件系统故障Lustre 读不了 2.3T 语料与 NVLink 错误同样是训练中断的大户检查点加载速度后期优化到 1 分钟直接影响恢复效率。七、结语从训练日志到开源仓库logs/main-log-en.md是一份极为罕见的透明化千亿模型训练记录它没有美化训练过程而是如实呈现了节点宕机、数据污染、损失爆炸、参数反复回退等真实细节。结合仓库中 configs/model_glm_130b.sh推理配置、initialize.py模型初始化与量化加载、docs/quantization.md推理量化等资源读者既可以按本文的时间线复盘 GLM-130B 的训练决策也可以直接上手其开源推理/评测链路。对任何计划训练 10B 以上规模模型的团队而言这份日志中的失败与回退远比成功曲线更有参考价值。赞分享大模型NLP基础模型模型评测模型量化【免费下载链接】GLM-130BGLM-130B: An Open Bilingual Pre-Trained Model (ICLR 2023)项目地址https://gitcode.com/gh_mirrors/gl/GLM-130B点击查看免费下载相关推荐GLM-130B引领未来的中英双语预训练模型GLM 130B引领未来的中英双语预训练模型 项目介绍 GLM 130B 是一款开源的中英双语预训练模型拥有惊人的 1300 亿个参数。该模型基于通用语言模大模型NLP基础模型模型评测模型量化如何快速上手GLM-130B开源双语预训练模型的完整指南如何快速上手GLM 130B开源双语预训练模型的完整指南 GLM 130B是一个强大的开源双语预训练模型支持中文和英文处理适用于自然语言理解、文本生成等多大模型NLP基础模型模型评测模型量化提升Redux性能reduce-reducers高级用法与最佳实践指南提升Redux性能reduce reducers高级用法与最佳实践指南 在Redux应用开发中随着项目复杂度的提升状态管理往往变得难以维护。 reduce上一篇ijkplayer OpenGL ES 2.0渲染引擎移动端高性能视频渲染终极指南下一篇Dolphin 服务菜单扩展指南3 个步骤打造自己的右键菜单功能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考