论文笔记《Critical Batch Size Revisited: A Simple Empirical Approach to Large-Batch Language......》

论文题目:Critical Batch Size Revisited: A Simple Empirical Approach to Large-Batch Language Model Training.
作者机构:Allen Institute for AI (William Merrill et al.)
一句话总结:论文提出了一种通过“分支训练”直接测量临界Batch Size (CBS) 的经验方法,发现现有的“梯度噪声尺度”方法在LLM训练中不可靠,并提出“Batch Size Warmup”策略,在不损失性能的前提下减少了43%的梯度步数。

1. 背景和动机

1.1 大模型训练的痛点与Batch Size权衡

  • 背景:LLM训练极其昂贵,提高吞吐量是核心诉求。
  • 手段:数据并行是主要手段,即增大Batch Size (BS)。
  • 权衡(Trade-off):
    • BS过小:训练慢,无法充分利用硬件并行能力。
    • BS过大:边际效应递减(Diminishing Returns)。虽然每步处理了更多数据,但模型收敛所需的Token总量变多了(样本效率下降)。
  • 核心概念:Critical Batch Size (CBS, B*) —— 超过这个阈值,增加BS会导致计算效率下降。

1.2 既有方法及其局限性

  • 主流理论:McCandlish et al. (2018) 提出的基于梯度噪声尺度 (Gradient Noise Scale) 的估算方法。
    • 该理论认为: CBS=梯度的方差与梯度范数之比。
    • GPT-3 等著名工作都参考了这一理论。
  • 本文的质疑:McCandlish的方法依赖两个强假设:
    1. SGD假设:假设优化器是SGD(但LLM主要用Adam)。
    2. 良态假设:假设Hessian矩阵是单位矩阵的倍数(实际并不成立)。
  • 结论:在Adam优化器和LLM场景下,噪声尺度(Noise Scale)可能不是CBS的有效代理。

2. 实验方法

2.1 本文提出的方法:分支训练

  • 核心思想:不依赖理论假设,直接用实验“测量”CBS。
  • 操作步骤:
    1. 取一个训练中的检查点。
    2. 以当前BS为基准,开启多个“分支”训练任务。
    3. 每个分支使用不同的 BS 倍数,并相应调整学习率(Adam用平方根缩放)。
    4. 训练一个小窗口步数Δ\DeltaΔ(文中取2B tokens)。
    5. 判定标准:如果大BS分支的Loss在 Δ\DeltaΔ 步后能恢复到与小BS分支相近(误差 ϵ\epsilonϵ 内),则认为该BS是“安全”的。

2.2 关键假设:局部恢复

  • 假设:如果在 Δ\DeltaΔ tokens 的短时间训练后,大BS的Loss能追平小BS,那么在之后的训练中它也能保持住。
  • 优势:相比于McCandlish对优化器和Loss地形的强假设,这个“局部恢复”假设在工程上更弱、更易验证。
  • 参数细节:
    • 窗口 Δ\DeltaΔ = 2B tokens。
    • 容忍度 ϵ\epsilonϵ = 0.01。
    • Loss经过了平滑处理。

2.3 实验设置 (OLMo Models)

  • 模型:OLMo 1B 和 OLMo 7B。
  • 数据:Dolma 数据集。
  • 基准:与 McCandlish 的梯度噪声尺度计算进行对比。
  • 亮点:使用完全开源的模型和数据,确保可复现性。

3. 实验发现与分析

[图片]

发现一:CBS随训练过程动态演变

  • CBS 在初始化时接近 0。
  • 在训练初期(前50B tokens)迅速增长。
  • 随后进入平台期(Plateau),稳定在约 4096 (documents) 左右。
  • 结论:CBS不是一个静态常数,而是一个动态变化的量。这意味着在训练初期应该用小BS,后期可以用大BS。
    发现二:模型规模不影响 CBS
  • 对比 1B 和 7B 的曲线:
    • 两条曲线的形态和数值惊人地相似。
    • 启示:我们可以用小模型(1B)测出的 CBS 规律,去指导大模型(7B甚至更大)的训练配置,节省昂贵的探索成本。

发现三:梯度噪声尺度不可靠

[图片]
  • 实测的梯度噪声尺度(红色虚线)与本文测量的真实 CBS(蓝色实线)完全对不上。
  • 噪声尺度严重低估了真实的 CBS(差了几个数量级)。
  • 趋势也不匹配(特别是在 7B 模型上)。
  • 打击:证明了 McCandlish (2018) 的理论在 LLM/Adam 场景下失效。

4. 应用与结果

4.1 提出的策略:Batch Size Warmup

  • 策略逻辑:既然 CBS 随时间增长,我们应该动态调整 BS。
  • 具体算法:
    1. 从小 BS 开始。
    2. 定期检测 CBS 是否超过了当前 BS 的两倍。
    3. 如果是,则将 BS 翻倍,并根据 2\sqrt{2}2​规则调整学习率。
  • 实施:在 OLMo 1B 训练中,BS 经历了两次翻倍(1024 -> 2048 -> 4096)。

4.2 核心结果对比 (Table 1)

[图片]
  • 三组对比实验:
    1. Small-Batch Control (一直用小 BS, 1024): 理论上 Loss 最好,但慢。
    2. Large-Batch Control (一直用大 BS, 4096): 跑得快,但初期 BS > CBS,导致 Loss 差。
    3. BS Warmup (Ours): 动态调整。
  • 结果炸裂:
    • Loss:Warmup 方法的最终 Loss 甚至略优于 Small-Batch (2.5433 vs 2.5486)。
    • 效率:相比 Small-Batch,节省了 43% 的梯度步数。

对比 Large-Batch:Large-Batch 虽然也快,但最终 Loss 明显变差,且无法恢复。

[图片]

4.3 下游任务性能 (Downstream Tasks)

[图片]
  • 不仅仅看 Training Loss,还看了下游任务(C4, The Pile, BPB等)。
  • BS Warmup 在各项指标上均与 Small-Batch 持平或略优。
  • 结论:这种加速方法是“免费的午餐”,没有副作用。

5. 总结与个人思考

5.1 论文总结

  1. 方法论:提出了基于分支训练的 CBS 测量法,不依赖强理论假设。
  2. 科学发现:CBS 随训练过程增长并趋于平稳;CBS 与模型大小无关。
  3. 工程价值:证明了 Gradient Noise Scale 在 LLM 上的失效;提出了 BS Warmup,实现了 40%+ 的训练加速。

5.2 局限性分析

  • 成本问题:虽然比从头跑多次要省钱,但“分支训练”本身依然需要额外的计算资源(每次 Checkpoint 都要分叉跑 2B tokens)。
  • 参数敏感性: Δ\DeltaΔ (窗口大小)和epsilon(容忍度)的选择比较经验主义。如果 Δ\DeltaΔ 选小了,可能误判 CBS。
  • 通用性验证:目前只验证了 OLMo 架构和 Dolma 数据集,是否适用于 MoE 或其他架构还需验证。

5.3 对我们实验室的启示

  • 如果我们要训练新模型:不要迷信 OpenAI 提到的 Gradient Noise Scale。
  • 调参策略:不要从头到尾用固定的 Batch Size。可以尝试手动实现简单的 Warmup(比如在前 10% step 用小 BS,后面翻倍),这可能在资源受限的情况下提升效果。
  • Proxy 的使用:可以用小模型(如 1B)先跑一遍确定 CBS 曲线,直接套用到大模型训练中。

6. Q&A

(1) “Noise Scale 是错的”?
我们以前可能一直以为梯度的方差能告诉我们 Batch Size 设多少,但这篇论文说在用 Adam 的时候这完全是误导。

(2) 关于 Methodology:“这样测量是不是很贵?”
确实有开销,但相比于盲目用小 BS 浪费的时间,或者用大 BS 导致模型训练坏了重跑,这个开销是划算的。而且作者发现 1B 的规律可以用在 7B 上,这大大降低了测量成本。”

(3) 关于公式:Paper 中提到了 k\sqrt{k}k​ scaling rule for Adam。为什么不是线性缩放(Linear Scaling)
因为 Adam 的 update rule 里分母有二阶矩估计,导致梯度的 scaling 变成了平方根关系(引用 Malladi et al., 2022)。

(4) Appendix D,作者试图推导 T\sqrt{T}T​ 的 scaling law,但最后认为经验测量比强行推导理论更靠谱。这显示了作者严谨的态度。

Read more

Flutter 三方库 shelf_modular 的鸿蒙化适配指南 - 掌控服务器路由资产、精密模块治理实战、鸿蒙级服务端专家

Flutter 三方库 shelf_modular 的鸿蒙化适配指南 - 掌控服务器路由资产、精密模块治理实战、鸿蒙级服务端专家

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 shelf_modular 的鸿蒙化适配指南 - 掌控服务器路由资产、精密模块治理实战、鸿蒙级服务端专家 在鸿蒙跨平台应用执行高级服务端管理与多维 Shelf 路由资产指控(如构建一个支持全场景秒级交互的鸿蒙大型全量后端服务中枢、处理海量 API Route Payloads 的语义认领或是实现一个具备极致指控能力的资产管理后台路由审计中心)时,如果仅仅依赖官方的基础 Shelf 处理器或者是极其繁琐的手动路由映射,极易在处理“由于模块嵌套导致的资产认领偏移”、“高频服务请求下的认领假死”或“由于多语言环境导致的符号解析冲突死结”时陷入研发代码服务端逻辑崩溃死循环。如果你追求的是一种完全对齐现代模块化标准、支持全量高度可定制路由(Modular-driven Backend)且具备极致指控确定性的方案。今天我们要深度解析的 shelf_modular——一个专注于解决“服务端资产标准化认领与模块化解耦”痛点的顶级工具库,正是帮你打造“鸿蒙超

OpenClaw 飞书机器人搭建流程

OpenClaw 飞书机器人搭建流程

OpenClaw 飞书机器人搭建流程 手把手教你搭建属于自己的飞书 AI 机器人! 一、创建企业自建应用 首先进入飞书开发者后台: 👉 https://open.feishu.cn/app 填写应用名称和描述,直接点击创建即可。 创建完成后,会自动生成 App ID 和 App Secret,这两个凭证后面配置 OpenClaw 时会用到,先记下来。 二、添加机器人能力 在应用详情页左侧菜单找到「机器人」,点击添加。 添加成功后,机器人就可以在飞书中被搜索和使用了。 三、开通消息权限 进入「权限管理」,找到 im: 相关权限,全部勾选。 ⚠️ 注意:以下这个权限建议不要勾选: 获取群组中所有消息(im:message.group_msg) 否则群里所有消息机器人都会收到并响应,会造成不必要的干扰。

2026年 , 最新的机器人系统架构介绍 (1)

文章目录 * 第一部分:机器人的完整系统架构(由底向上) * 第二部分:最有前景、最具迁移性的核心是什么? * 第三部分:学习与技术路线图 * 标题数据驱动的机器人操作与决策算法 * 工业级机器人系统架构 * 第一部分:生动形象的工业级机器人系统架构 * 第二部分:热门公司技术路线全解析与优劣势对比 * **1. 宇树科技 (Unitree) —— 运动性能的极致派** * **2. 智平方 (AI² Robotics) —— 全栈VLA的实战派** * **3. 银河通用 (Galbot) —— 仿真数据驱动的垂直深耕派** * **4. 逐际动力 (LimX Dynamics) —— OS系统整合派** * **5. 优必选 (UBTECH) —— 全栈技术的老牌劲旅** * 第三部分:总结与你的切入路线图 第一部分:机器人的完整系统架构(由底向上) 我们可以把一个智能机器人系统想象成一个“人体”,从物理接触世界的大脑,分为以下几个层次: 1. 最底层:硬件平台与执行机构

AstrBot+NapCat 一键部署 5 分钟搞定智能 QQ 机器人!cpolar解决公网访问 :cpolar 内网穿透实验室第 777 个成功挑战

AstrBot+NapCat 一键部署 5 分钟搞定智能 QQ 机器人!cpolar解决公网访问 :cpolar 内网穿透实验室第 777 个成功挑战

这篇教程会带你用最简单的方式:**只用一份 docker-compose,一次命令,5 分钟以内完成 AstrBot + NapCat 部署,把 DeepSeekAI 接入你的 QQ。**AstrBot 本身就是为 AI 而生的现代化机器人框架,插件丰富、支持 DeepSeek/OpenAI 等大模型、带 WebUI、可扩展性强,真正做到"搭好就能用"。照着做,你马上就能拥有属于自己的 QQ AI 机器人。 1 项目介绍 1.1 AstrBot是什么? GitHub 仓库:https://github.com/AstrBotDevs/AstrBot AstrBot 是一个专为 AI 大模型设计的开源聊天机器人框架,