← 全部论文 / 2022

BLOOM: A 176B-Parameter Open-Access Multilingual Language Model

2022 超大规模稠密 LLM 训练
下载 PDF

BLOOM: A 176B-Parameter Open-Access Multilingual Language Model - 中文验证版

英文原始依据卡片：bloom_2022.md

状态：已翻译。

元数据

计算设置

论文明确报告了训练机器。BLOOM 在 IDRIS/CNRS 的 Jean Zay 上训练，使用 48 个训练节点，每个节点配备"8 块 NVIDIA A100 80GB GPU"，共 384 块活跃 GPU，另有四个备用节点随时应对故障。每个节点配有两颗 AMD EPYC 7543 32 核 CPU 和 512 GB RAM。存储来自共享的 SpectrumScale/GPFS 并行文件系统。节点内 GPU 通信使用四条 NVLink GPU 到 GPU 互连；节点间每个节点通过四条 Omni-Path 100 Gbps 链路以增强超立方 8D 拓扑连接。

训练运行持续约 3.5 个月，消耗 1,082,990 个计算小时。最终 BLOOM 模型具有 176,247M 参数、70 层、隐藏维度 14,336、112 个注意力头、序列长度 2,048、250,680 个 token 的词表，全局 batch size 为 2,048 个序列。论文报告 BLOOM 的总训练 token 为 366B，从大约 341B token 的 ROOTS 语料库开始，然后在训练期间 Chinchilla 风格的数据缩放结果出现后增加了约 25B 的重复 token。最终运行在 A100 上使用 bfloat16 混合精度，而不是早期较小变体和实验中使用的 float16。

瓶颈

核心瓶颈是在公共超级计算机而非单一所有者超大规模集群上承载和维持一个 176B 的密集 decoder。参数内存、梯度、优化器状态和激活值无法放入一块 80 GB 的 GPU，而且模型对于纯数据并行来说太深太宽。因此 BLOOM 同时面临内存放置问题和通信问题：张量分片需要快速的层内交换，流水线段需要同步的前向/反向流，数据并行副本仍然需要优化器状态同步。

下限算术已经超出单设备规模。BLOOM 的 176.247B 参数意味着约 2.82 TB 的混合精度 Adam 训练状态（按每参数 16 字节计算），这还不包括激活值、临时缓冲区和碎片。对于推理，BF16 权重约为 352.5 GB，不含 KV 缓存。对于 70 层、112 个注意力头、头维度 128 和 2048 token 上下文，batch-1 的 KV 缓存增加约 8.2 GB。因此部署边界是权重加缓存加运行时工作空间，而不仅仅是参数存储本身。

第二个瓶颈是数值稳定性。论文指出，在 NVIDIA V100 GPU 上以 IEEE float16 进行的 104B 参数实验出现了不可逆的发散，可能源于 float16 有限的动态范围。A100 对 bfloat16 的支持改变了可行的精度范式，在保持浮点 Tensor Core 吞吐量的同时保留了类似 float32 的动态范围。

第三个瓶颈是带宽和编排。GPU 数学吞吐量超过了反复将中间张量移入移出 VRAM 的速度，因此 LayerNorm、掩码、softmax、bias 加法和 GeLU 等内存受限操作如果以朴素方式实现，会浪费 A100。在 384 块 GPU 规模下，平凡的运行时行为也成为瓶颈：异步 CUDA 启动使调试和死锁复杂化，大型参数组导致过多的 CPU 内存分配。

方法适配

BLOOM 使用 Megatron-DeepSpeed 将 GPT 风格的密集 Transformer recipe 适配到 Jean Zay 拓扑。Megatron-LM 提供 Transformer、张量并行和数据加载；DeepSpeed 提供 ZeRO、流水线并行和分布式训练组件。由此产生的 3D 并行结合了数据并行、张量并行和流水线并行。ZeRO stage 1 分片优化器状态，这是一个保守的内存收益：它减少了 Adam 状态复制，同时避免了更具侵入性的参数/梯度分片阶段。

若干设计选择明确受计算影响。论文指出 MoE 被拒绝的部分原因是项目时间线上没有成熟、广泛使用的 GPU 代码库来训练它们。ALiBi 位置嵌入避免了一个可学习的位置表，并且在作者的实验中平滑了训练。Embedding LayerNorm 是在 104B 不稳定性工作之后引入的。分词器词表大小设为可被 128 整除（用于 GPU 效率）和被 4 整除（用于张量并行）；最终大小为 250,680 个 token。来自 Megatron-LM 的融合 CUDA 核函数通过组合 LayerNorm、注意力缩放/掩码/softmax 以及 bias 加 GeLU 工作来减少内存流量，使得中间结果可以停留在更靠近寄存器的位置，而不是通过 VRAM 往返。

操作适配也很重要。最终系统禁用了异步 CUDA 内核启动以提高可调试性并避免死锁，拆分参数组以减少 CPU 内存峰值，每三小时保存一次检查点，并依赖备用节点来吸收硬件故障而不会造成显著的吞吐量损失。

证据

最强的计算证据是实测利用率：最快配置达到每块 A100 156 TFLOP/s，约为论文中 float32 或 bfloat16 Tensor 计算 312 TFLOP/s 理论峰值的一半。这不是单 GPU 基准测试；这是在 384 GPU 3D 并行训练作业中达到的，其中包括流水线气泡、张量并行集合通信、数据移动、数据加载器行为和检查点。

稳定性证据也很具体。早期 104B V100/float16 试验不可逆地发散，而最终的 A100 bfloat16 混合精度训练在作者的叙述中"解决了"这种不稳定性。硬件故障是常规的但可管理：论文报告每周一到两次 GPU 故障，自动使用备用节点，以及仅有零星的工程问题。一个 PyTorch 数据加载器死锁和磁盘空间问题导致 5-10 小时的停机，但只有一次损失尖峰，模型得以恢复。

基准测试证据表明这些计算投入产生了什么成果。在一次性 SuperGLUE 比较中，BLOOM-176B 在 Ax-b、CB、WSC 和 WiC 上优于 OPT-175B，在报告的子集的其他任务上与之持平。在 WMT14 上，最佳一次性 prompt 使 BLOOM 获得英语到法语 34.22 BLEU 和法语到英语 35.42 BLEU。在 Flores-101 上，论文报告在高资源和高到中资源语言对上的强一次性翻译性能，而对于 Swahili-Yoruba 等代表性不足的语言对则表现较差。HumanEval 性能与可比较的 Pile 训练的 GPT 模型相似，而经过代码微调的 Codex 仍然明显更强。

历史影响

BLOOM 表明，一个 100B+ 的多语言密集 LLM 可以作为开放科学的超级计算项目来构建，而不仅仅是一个封闭的工业平台。从历史上看，其重要性不仅仅是 176B 的参数数量；它暴露了多语言前沿规模运行的完整计算结构：公共资助分配、确切的 A100 拓扑、3D 并行、BF16 迁移、分词器可整除性约束、检查点节奏、故障处理、碳排放核算和训练后评估。

它还使"开放大模型"问题变得可操作。发布权重和文档只有在其他团队能够理解决定训练成为可能的硬件和软件决策时才有意义。因此 BLOOM 的报告成为后来需要理解 A100 内存、并行、batch size、数据混合、多语言分词和集群可靠性的开放 LLM 项目的参考。

局限

计算方案仍然昂贵且保守。作者排除了 MoE，因为 GPU 软件路径对项目来说不够成熟，因此 BLOOM 没有测试稀疏条件计算是否可以在每个 FLOP 上提供更好的质量。许多架构和目标决策是在小得多的规模上选择的，论文明确指出小规模消融实验并不总能干净地迁移到 176B 训练。

该运行也不是完整的部署成本模型。碳排放部分估计在训练、设备制造和空闲集群消耗中产生约 81 吨 CO2e，但 API 部署是单独处理的，取决于批处理、请求量、实现和 serving 硬件。最后，BLOOM 是多语言的但并非均匀强大：代表性不足的语言仍然很弱，安全性、偏见、毒性、幻觉和校准局限性仍然可见。

链接

  • 计算范式：history/compute_regimes/hyperscale_dense_llm_training/README.md
  • 来源 PDF 和抽取文本见上述元数据。
  • 队列状态：read_complete。