The Falcon Series of Open Language Models翻译-CSDN博客

摘要

我们推出了 Falcon 系列：这是分别具有7B、40B 和 180B 参数的因果解码器模型，这些模型主要在从网络数据中收集的多样化高质量语料库上进行训练。最大的模型 Falcon-180B 已在超过 3.5 万亿个文本token上进行了训练，这是公开记录的最大规模的预训练运行。Falcon-180B 的表现明显优于 PaLM 或 Chinchilla 等模型，并且比同时开发的模型（如 LLaMA 2 或 Inflection-1）有所改进。它以更低的预训练和推理成本接近 PaLM-2-Large 的性能，据我们所知，它与 GPT-4 和 PaLM-2-Large 一起成为世界上最好的三种语言模型之一。我们报告了详细的评估，并深入研究了用于预训练 Falcon 的方法和自定义工具。值得注意的是，我们报告了我们自定义的分布式训练代码库，这使我们能够在互连有限的云 AWS 基础设施上，在多达 4,096 个 A100 上高效地预训练这些模型。我们发布了 600B tokens的 Web 数据集，以及在开源许可下发布的 Falcon-7/40/180B 模型，以促进开放科学并加速大型语言模型开放生态系统的发展。

1.介绍

在这里插入图片描述
　　语言模型的持续发展主要得益于流行的基于 Transformer 的配方的独特可扩展性。这种可扩展性体现在多个方面：

Performance scalability (and predictability)。预训练计算预算的增加会以一致且可预测的方式系统地提高语言建模能力。Falcon-180B 是第一个公开记录的 GPT-3 大小模型，遵循 (Kaplan et al., 2020) 更新的缩放定律建议，总预训练长度为 3,5000 亿个token，无需任何上采样。
Data scalability。为了高效地扩大预训练规模，并解耦预训练和推理计算，越来越大的模型应该在更大的语料库上进行更长时间的训练。为了支持 Falcon 系列，我们开发了 RefinedWeb，这是一个 5 万亿个 token 的高质量过滤和去重网络数据集，是公开记录的最大数据集。
Hardware scalability。Transformer 模型天生适合现代 GEMM 优化硬件，允许其训练和推理高效地分布在大量加速器上。借助 Falcon-180B，我们展示了如何在经济高效的 AWS 云基础设施上将预训练扩展到 4,096 个 A100 40GB，每个加速器仅需 50 Gbps 互连。

基于这些基础，越来越大的语言模型产生了所谓的涌现能力。这些能力可以根据人类的偏好进一步定制，以构建指令遵循或聊天模型。所有这些方法都导致大型语言模型在面向客户的应用程序中得到广泛部署，例如 ChatGPT (GPT-3.5/4)、Claude、Bard (PaLM-2) 或 Pi (Inflection-1)。在本文中，我们主要报告 Falcon 系列模型的预训练，并将进一步的下游微调和对齐留待未来的工作。
　　Falcon 系列由三个纯因果解码器模型组成，这些模型在多达 4,096 个 A100 上进行训练。我们组装了一个包含 3,5000 亿个 token 的预训练数据集，主要来自我们在 RefinedWeb 上的工作——这是一个经过过滤和去重的海量网络数据集。模型的架构基于 PaLM，尽管我们独立验证了每个决策，最终进行了一些细微调整——详情请参阅第 4 节。Falcon 系列利用了大量自定义工具（即预训练代码库、数据管道），其开发于 2022 年 8 月开始，模型训练于 2022 年 12 月开始。深入评估表明，Falcon 系列在各个规模上都具有竞争力，Falcon-180B 的性能接近 PaLM-2 Large，使其成为最佳开放模型，并跻身最佳语言模型的前三名。
　　Contributions。通过本文和 Falcon 系列，我们做出以下贡献：

大型模型预训练的公开文档。最近的SOTA模型很少被记录下来，阻碍了该领域的进一步研究和进步。与这些工作不同，我们广泛记录了 Falcon 系列的预训练。
开放数据和模型。为了加速研究，并实现社区推动的大型语言模型改进，我们公开发布了 Falcon-7/40/180B 和具有6000 亿个 token的 RefinedWeb 数据集的：https://huggingface.co/tiiuae/。

2.State-of-the-art: from language modeling to frontier models

在这里插入图片描述
　　本节概述了 Falcon 系列的总体趋势和相关工作。有关各个技术组件的深入文献综述，请参阅相关章节。
　　Language modeling。除了语料库/特定任务方法之外，第一种大规模基于向量的词嵌入方法开创了从大量非结构化文本语料库中进行无监督学习的先河。深度循环神经架构的集成使模型能够处理多义性并整合上下文信息；直到迁移学习范式的出现，通过使用通用模型进行特定于下游任务的微调。尽管目前使用的许多第一原理都存在，但早期的扩展尝试只取得了好坏参半的成功，部分原因是循环方法在常见硬件上的苛刻性和较差的可扩展性。
　　Transfomer models。Vaswani 等人 (2017) 提出的基于注意力机制的 Transformer 架构引发了高效通用模型的产生，从专注于嵌入和分类的纯编码器 BERT，到纯因果解码器的 GPT。具体来说，GPT-2 是第一个推广新兴的少样本泛化能力的模型系列，允许模型仅根据上下文指令和演示样例来理解和执行任意任务。
　　Large language models。上述研究列出了当前模型的关键组成部分；最后一个要素，即扩展，已由 GPT-3 证明，并通过概述缩放定律而得到重视。随着越来越多的计算用于预训练模型，语言建模性能也相应提高。通往更强大语言模型的系统和直接途径的诱人前景导致了“扩展狂潮”：首先是使用 Jurassic-1 或 PanGu-Alpha 复制 GPT-3，以及 GPT-J、OPT 或 BLOOM 等开源的努力；其次，使用 Gopher、MT-NLG 或 PaLM 进一步突破扩展极限的工作。大型语言模型的开发和调整增加也导致了预训练方法的改进。值得注意的是，Hoffmann et al. (2022) 使用 Chinchilla 证明，最佳扩展实际上应该共同增加模型大小和预训练数据集。对于在现实世界中的部署，甚至可能需要远远超越所谓的最优性进行训练，以分离训练和推理计算并降低服务成本。LLaMA 模型就说明了这一点，该模型具有 7B/13B/30B/70B 参数，可在多达 2 万亿个 token 上进行训练。
　　Frontier models。与此同时，所谓的前沿模型也应运而生，其定义也不断变化，即“大规模机器学习模型，其能力超越了目前最先进的现有模型，并能执行各种各样的任务”。尽管目标还在不断变化，但我们认为最近关于 GPT-4 和 PaLM-2 的研究是这一类别的早期贡献。这些模型的突出之处在于其显著增加的计算预算和改进的能力。有关我们对未记录模型的方法的详细信息，请参阅附录 E。

3.Design philosophy

在这里插入图片描述
　　受惨痛教训 (Sutton, 2019) 的启发，我们相信，充分利用计算的可扩展方法最终是最有效的。因此，在设计 Falcon 系列模型时，我们主要关注可扩展性，涵盖三个方面：性能、数据和硬件。
　　Performance scalability。大型语言模型规模的持续增长（图 2）主要受到所谓的扩展定律的推动：随着预训练计算的增加，语言建模能力也相应提高。事实证明，这种系统化的模型改进方法比等待偶尔的研究顿悟来体现范式转换方法要可靠得多。但上游和下游性能不仅仅是扩展的动机，它们也是一个强大的驱动力。事实上，量化建模干预（例如，架构调整、数据来源、超参数选择）所带来的影响对于维持小规模消融提供的反馈回路至关重要。然而，量化什么的问题并不简单：上游性能本身可能与下游任务不一致，甚至下游指标也可能与人类偏好不一致。预训练目标（即在以网络语料为主的语料库上预测下一个单词）与常见的下游用途（即以有益、无害和诚实的方式遵循用户的指令）之间的根本对比使得这一点更具挑战性。当我们专注于 Falcon 模型的预训练阶段时，我们选择将我们的评估重点集中在zero/few-shot generalization on large aggregates of natural language tasks——类似于 Le Scao et al. (2022); Wang et al. (2022a)。我们构建了可以与其他最先进模型进行比较的集合，但请注意执行原则性比较的难度：在任务选择、提示甚至评估模式方面，不同论文的实践差异很大——标准化基准仍然很少被采用。我们在第 7 节中讨论了评估设置的局限性。
　　Data scalability。增加预训练计算预算可以用于构建更大的模型，也可以用于延长训练时间。虽然 Kaplan et al. (2020) 最初发现最佳缩放主要是由模型大小驱动的，但 Hoffmann et al. (2022) 修改了这一发现，发现联合缩放更可取——参见图 3 以了解影响。此外，增加模型大小也会增加推理负担；而增加预训练数据集大小与推理成本无关。最近的开放模型已在多达两万亿个 token 的数据集上进行了训练；由于简单的重复可能会降低模型的性能，这引发了人们对数据扩展可持续性的担忧。这些担忧因人们普遍认为精选语料库是构建最先进模型的必要条件而加剧，需要手动添加单个来源，例如 arXiv 论文、书籍等。对于 Falcon 系列模型，我们选择专注于通过严格的过滤和重复数据删除来扩展高质量的网络数据，这使我们能够收集 5,0000 亿个token的英语网络数据集，并且在训练期间不会重复任何数据。我们在 Penedo et al. (2023) 的论文中广泛报告了这项工作，但也在本文中提供了一些关键要素。
　　Hardware scalability。大规模训练需要数千个硬件加速器协同高效工作；要充分利用这些加速器，反过来又需要有原则的分布式训练方法。能够最高效运行并利用大规模计算的方法往往是在社区中获得最多关注的方法，Transformer 架构本身就是最好的例证。此外，很难找到能够显著提高模型任务性能（例如与数据的影响相比）的架构改进。因此，我们的架构决策重点不是提高任务性能，而是提高硬件可扩展性和吞吐量。我们还关注推理可扩展性，这促使我们采用了诸如多query注意力方案之类的调整。
　　最后，除了可扩展性之外，我们还关注成本效益并依赖经过验证的方法。我们重新实现了与优化器并行相结合的 3D 并行策略，使我们能够在具有有限互连的更具成本效益的云 AWS 基础设施上运行。我们还非常注重节省内存的方法，使我们能够在更便宜的 40GB A100 上运行。从头开始重新实现我们的数据预处理和预训练pipline使我们能够广泛验证它们，而不是依赖于未知的外部代码库。我们也不会探索与大型语言模型（例如状态空间模型）的经典设计截然不同的设计，因为这些模型通常尚未得到大规模验证。

4.Experiments and motivations for data, architecture, and hyperparameters

我们首先重点关注一系列小规模实验，这些实验使用 1B-3B 参数范围内的模型来验证推荐的做法，并确定有趣的调整。我们还进行了大量实验来验证我们的 Web 数据pipline，如 Penedo et al. (2023) 所述。对于每个感兴趣的主题，我们还概述了常见的做法以及我们探索这个方向的动机。

4.1 Setup for small-scale experiments

在这里插入图片描述
　　Small models。对于这些消融，我们力求能够以有限的计算成本快速迭代。这导致我们分别针对 300/600 B参数训练 1B和3B参数的模型。我们选择这些较短的训练长度来说明 Hoffmann et al.
(2022) 的最优机制，我们的大型模型可能会在该机制下进行训练。我们的参考架构和超参数以 GPT-3 描述的架构和超参数为基础，但需要注意的是使用 ALiBi 位置嵌入作为基线。有了合理的资源（32-64 A100），这些消融模型可以在一夜之间或几天内完成训练，从而实现快速迭代。我们注意到，使用较小模型的一个缺点是它们可能无法说明较大模型的某些行为：例如，Dettmers et al. (2022) 发现影响量化的异常特征出现在 6B 规模上；对数据重复和记忆的担忧也显示出对较大模型产生不成比例的影响。
　　Dedicated aggregate。尽管小型模型可以实现快速迭代，但它们的零样本能力也有限；简单的批量评估会导致大多数任务接近随机基线，并在评估中产生显著的噪音。使用在 The Pile 子集上训练的模型，我们确定了在小模型下表现出合理性能且在运行过程中变化有限的任务：我们独立量化了运行5次的 50 多个任务的方差和平均性能，这些运行使用了不同的种子（我们使用此 $σ$ 进行架构实验），以及 10 次运行中使用不同的数据子集和混洗（用于数据实验）。基于此分析，我们从 Brown et al. (2020); Le Scao et al. (2022); Srivastava et al. (2023) 的评估设置中获取了 11 个任务，用于我们的消融（zs-main/data/web）。请注意，这三个子集之间的差异主要是由于不同时间和团队之间的实践不同。zs-comp 是 main 的一个子集，用于与其他模型进行比较，基于常见的报告任务。我们还报告了 The Pile (ppl-pile) 上架构的困惑度（对于数据实验，我们发现 The Pile 上的困惑度主要说明格式而非内容的差异），以及 3 个方差较低的 NLP 任务的受限子集（zs-small）。对于我们的小规模评估，我们同时使用 EleutherAI 工具和 BigBench；请注意，我们的推理和评估代码库在本设置中和我们在第 6 节中报告的最终结果之间存在显著差异，因此结果无法直接比较。我们在表 2 中列出了汇总的概要。

4.2 Data: web vs curated, code and multilinguality impact on English performance

4.2.1 Web data alone can outperform curated corpora

我们主要在网络数据上进行训练的动机、处理流程的细节和广泛的评估在我们专门的 RefinedWeb 论文中进行了详细介绍。在本节中，我们仅重点介绍指导我们决定将精力集中在网络数据上的关键因素。

Background。自从使用更简单、更浅显的统计语言模型以来，自然语言处理长期以来一直利用非结构化的海量文本语料库。如果这些语料库最初是“逐句构建的”，那么更高级架构的出现使模型能够最好地利用统一文档中存在的长上下文信息。从单领域来源（例如 Wikipedia 或 BookCorpus）开始，数据集与模型一起扩展，大规模网络爬取变得流行起来。然而，人们普遍认为，仅靠网络数据不足以构建高性能模型。因此，大型语言模型在混合语料库上进行训练，结合大规模网络数据和精心挑选的所谓“高质量”单个来源（例如书籍、技术论文、社交媒体对话）——请参阅表 3 了解常见的预训练组合概述。
　　然而，正如我们在第 3 节的数据可扩展性讨论中概述的那样，获取用于预训练现代语言模型所需的数万亿个 token 可能具有挑战性。这导致我们质疑精选数据从根本上优于网络数据的观点。值得注意的是，在 Lee et al. (2022) 的工作基础上，我们研究了受 Rae et al. (2021) 启发的严格重复数据删除和广泛过滤如何使网络数据本身能够训练出高性能模型。

Question。能否仅使用网络数据（经过过滤和重复数据删除）来训练模型，使其性能优于使用精选数据训练的模型（以自然语言零样本性能来衡量）？

Methods。我们分别在具有 27B/60B 个token、大量有趣的数据集和我们数据管道的中间工件上训练了 1B/3B 参数的模型。对于最先进的网络数据集，我们考虑了 OSCAR 和 C4 的两个版本。对于精选数据集，我们考虑了最受欢迎的预聚合数据集 The Pile——许多模型也选择将其预训练数据基于 The Pile 的特定组件。RW-Raw 对应于我们管道的输出，过滤量最少，紧接着是文本提取——但仍然应用了英语语言识别以及已知成人内容的 URL 阻止列表；RW-Filtered 应用了第一轮启发式方法，类似于 Rae et al. (2021) 使用的方法；最后，RefinedWeb 对应于我们的最终网络数据集，分两个阶段应用了重复数据删除。我们在 zs-web 聚合上评估所有模型——有关其组成的详细信息，请参见表 2。
在这里插入图片描述
　　Results。本轮实验的结果列于表 4 中。与预期一致，我们发现原始网络数据 (RW-Raw) 表现不佳；同样，OSCAR 22.01 在所有数据集中表现最差。这可能是因为其创建者选择默认分发它而不应用任何重复数据删除。相反，OSCAR-21.09 和 C4 都是强大的基线。我们特别发现 The Pile 的表现很可能不比网络数据好。
　　我们流程中的后续阶段显著提升了数据集质量和基于该数据集训练的模型的性能。仅过滤一项就让我们缩小了与 The Pile 的差距，而严格的重复数据删除使 RefinedWeb 成为我们基准测试中最好的数据集。
　　我们注意到这些实验有两个局限性。首先，模型规模较小，并且只在有限量的数据上进行训练。但是，重复数据删除带来的收益实际上可能会随着模型规模的扩大而增加，因为较大的模型对重复数据更敏感，并且更有可能记住单个样本。其次，我们的评估侧重于自然语言任务。仅使用网络数据进行训练的模型不太可能在代码任务上优于使用 The Pile 进行训练的模型，因为 The Pile 明确包含代码，而大规模网络抓取可能除了一些偶然事件外大多不包含代码。

Finding。挑战对数据质量的信念，仅过滤和重复数据删除的网络数据就可以使模型匹配在精选数据上训练的模型的自然语言任务性能。

在这里插入图片描述

4.2.2 Against a strong web baseline, curated data can even be detrimental

Background。在第 4.2.1 节和表 3 中，我们注意到大型语言模型使用结合了海量网络爬取数据和单独设计的来源的预训练数据集。这些来源最初用于构建特定领域的模型；它们还被提议用于扩大模型的表现力，例如用于对话模式。其中一些来源也可能存在于精心设计的数据和爬取的交集处：例如，Laurençon et al. (2022) 提出使用人工选择的 URL 为爬取中的第一个链接播种。然而，这些量身定制的来源给从业者带来了挑战。首先，单个语料库的可扩展性远低于大规模网络爬取，因为它们需要分散的工作而不是集中的管道。其次，其中一些来源的提供者已开始采取措施禁止 LLM 接受其数据训练，并且获得足够的许可可能成本高昂。根据我们在上一节中的发现，我们可能想知道当我们将设计的数据与像 RefinedWeb 这样的强大网络基线相结合时会发生什么。

Question。在替换强大的网络基线时，来自单个语料库的精心策划数据对模型的自然语言零样本性能是否仍然有益？

Methods。我们使用 30B 的token上训练小型 1B 模型，将预训练数据分为网络数据和特定的精选类别。我们对目标类别的 1%、10%、25%、50%、75% 和 100% 进行抽样训练。我们只考虑一维方法，并将网络数据与单一类别的精选数据混合在一起。我们将类别分为书籍、对话和技术数据，如表 5 所示。对于构成这些类别的单个语料库，我们从 The Pile 中汲取灵感，并使用 Reddit 的数据对对话类别进行增强。我们的网络数据取自 RefinedWeb，我们通过类似的管道处理精选源，应用过滤和重复数据删除以进行公平比较。我们评估 zs 数据聚合的性能——详细构成见表 2。
在这里插入图片描述
　　Results。在图 4 中，我们绘制了随着精选数据比例的增加而产生的零样本准确率。当与强大的网络基线相结合时，我们发现添加精选数据从未显著提升性能。事实上，精选数据过多甚至会降低对book和technical的性能，超过 50% 后，我们开始观察到准确率显著下降。我们认为与网络数据的高度多样性相比，这可能是由于“模式崩溃”造成的。
　　有趣的是，对话自始至终表现良好，当数据比例为100%时降幅是最小的。我们认为这可能是因为我们的对话类别是三者中最具多样性的，或者对话更接近任务分配。事实上，这一类别可能包括人们互动、回答问题和向彼此发出指示——这种风格在书籍或论文和专利等技术驱动的内容中不太常见。
　　再次，这种消融受到所考虑任务范围的限制。技术含量高的任务可能会受益于特定领域的数据，而网络数据对于代码任务来说可能是一个相当差的基准。此外，我们的零样本评估都是在较短的上下文长度下进行的：例如，书籍可能有助于帮助模型学习长距离相关性。
在这里插入图片描述

Finding。当添加精选的数据类别来替代强大的网络基线时，它们并不会系统地提高自然语言零样本性能。

4.2.3 Limited code and multilingual data do not strongly degrade English performance

Question。在不影响模型英语性能的情况下，是否可以在添加的预训练数据中替换有限数量（5-10％）的代码和多语种数据？

Multilinguality。RNN 和 Transformer 的首次大规模部署部分用于机器翻译；注意力机制最初就是为此类用例引入的。因此，多语种语言模型与单语种模型一起迅速蓬勃发展也就不足为奇了。然而，多语种生成大型语言模型仍然难以捉摸。事实上，Lin et al. (2021) 和 Scao et al. (2022b) 都报告说，大规模的多语种是以牺牲英语性能为代价的，导致多语种模型的表现不如单语种模型。这种所谓的多语种诅咒导致从业者不敢天真地批量添加其他语言——即使是明确针对多语种能力的 PaLM，也只在 20% 的非英语数据上进行训练。此外，多语种数据很少可用：CommonCrawl 中近 60% 的文档是英语，而顶级语言的分布偏向欧洲语言。值得注意的是，尽管中文普通话在全球排名第二，但在 CommonCrawl 中它仅排第六；尽管印地语在全球排名第三，但它甚至没有进入前二十名。
　　我们选择使用受限制的多语种设置进行实验：我们考虑使用拉丁字母的语言，并专注于那些我们可以使用数据管道从 CommonCrawl 中收集大量（超过 100 亿个token）的语言。我们的实验分组如表 6 所示。我们使用固定的 10% 多语种数据（根据各个语言在 CommonCrawl 中的流行程度对其进行加权）训练模型，并评估英语任务。每个数据分组使用专用的tokenizer。
在这里插入图片描述
　　我们在表 7 中展示了结果。我们发现，10% 多语种导致的性能下降非常有限，并且在德语、西班牙语和法语的基础上添加其他欧洲语言不会导致进一步的性能下降。我们看到 HellaSwag 上的性能下降最为显著，而其他任务则没有受到太大影响。我们注意到，这些实验适用于非常有限的环境，可能无法说明其他多语言设置（例如，没有拉丁字母的语言、使用其他语言来弥补英语token的不足等）。
在这里插入图片描述
　　Code。大型语言模型已经展示了强大的编码能力，无论是通过通用预训练后的微调，还是通过专用的预训练混合训练。此外，与多语种数据不同，代码数据非常丰富，从抓取公共存储库中可以获得数万亿个token。代码任务是 LLM 驱动的助手的主要应用，因此允许使用 Falcon 进行此类用例非常重要。但是，我们不想冒着损害语言能力的风险：因此，我们在此验证了在预训练中添加有限代码数据的常见做法，与其他模型一致（见表 3 中预训练中的常见分数）。
　　我们从 GitHub 中选择了排名前 30 的编程语言，并用 5% 的预训练数据替换代码。请注意，我们对代码数据集应用了重复数据删除，但调整了我们的启发式方法以避免删除过多的数据。我们只考虑英语任务的表现。结果列于表 7。我们发现添加代码数据具有与多语种类似的效果（如果只是更弱，可能是因为比例较小），对任务的影响很小甚至没有。

Finding。少量代码和多语言数据（5-10%）与大型语言模型的常见方法一致，不会对英语任务的零样本性能产生广泛影响。

我们注意到，我们的消融规模较小是一个更大的限制，这可能导致我们在多语种和代码方面做出更保守的选择。有人认为，由于容量增加，较大的模型可以更好地处理多语种。代码数据也已被证明可以提高较大模型的常识能力。更广泛地说，在多语种模型中也观察到了类似的效果。

4.3 Architecture and pretraining: validating popular recipes, and inference optimizations

4.3.1 Extending multiquery into multigroup for tensor parallel training and inference

在这里插入图片描述
　　Background。大型语言模型首先统一采用了 Vaswani et al. (2017) 描述的多头注意力方案。每个token产生 $n$ 头三元组 (query、key和value)，然后将每个头的结果相加以产生注意力模块的最终输出。但是，这个方案可以改变。Shazeer (2019) 发现，可以在所有注意力头之间共享相同的key和value，而性能只会略有下降。在这种所谓的multi-query注意力中，query的头数量保持为 $n_q = n_{head}$ ，但key和value只有一个头，即 $n_{kv} = 1$ 。这显著减少了推理内存消耗：在自回归生成期间，key和value被缓存以加速生成——与 vanilla 注意力相比，使用multi-query时，K、V 缓存大小减少了 $n_{head}$ 倍，导致常见模型的内存消耗减少了 10-100 倍——见表 8。multi-query提高了大型模型推理的可扩展性。Chowdhery et al. (2022) 最近推广了这种架构修改，尤其是被 LLaMA-2 采用。
　　Scaling。有趣的是，multi-query对较大的模型特别有效。假设 N 为参数总数， $d_{model}$ 为模型隐藏维度大小， $n_{layer}$ 为层数，假设 $d_{head} = d_{model}/n_{head}$ 固定——这通常是使用 FlashAttention 时的情况。为了实现高效扩展，通常建议 $n_{layer} ∼ O(log(N))$ ；因为我们可以近似 $N ≃ n_{layer}(d_{model})^2$ ，因此具有多头注意力机制的 $K, V$ 缓存的大小以 $O(\sqrt{N}log(n))$ 为单位扩展。相反，对于multi-query， $K, V$ 缓存每层仅存储固定的 $2d_{head}$ ，不会随着宽度而增加；这导致整体扩展效率更高，且是以 $O (l o g (N))$ 为单位。
　　Multigroup。multi-query注意力机制的一个缺点是，当依赖张量并行时，很难有效地并行化，这在基于 GPU 的基础设施中很常见。要么每个 GPU 都保留共享的key/value的副本，单独重新计算它们，然后共享梯度以保持它们同步，要么在单个 GPU 上计算它们，然后根据需要进行通信。我们建议为每个张量并行结点引入单独的key/value对，以简化所需的通信。与 Shazeer (2019) 一样，我们保留 $n_q = n_{head}$ ，但现在 $n_{kv} = TP$ 。该方案不会改变 $K, V$ 缓存的缩放比例，因为它只应用了固定的 TP 因子。在开发 Falcon 系列的同时，Ainslie et al. (2023) 也提出了这种修改；我们将这种注意力变体称为group-query或者multi-group注意力。我们注意到，通信减少不仅适用于推理期间，也适用于训练期间。
　　Results。我们使用来自 The Pile 的 30B/60B token训练 1B/3B 模型，并采用multi-query和不同程度的multi-group注意力机制。重要的是，我们没有控制由于丢失额外key和value而导致的参数减少，因此预计会出现一定程度的下降。结果如表 9 所示。multi-query和multi-group均不会导致零样本性能大幅下降，即使不补偿可训练参数的减少。
在这里插入图片描述

Recipe decision。为了提高模型的性能可扩展性，Falcon 系列为所有型号实现了 KV=TP 的multi-group注意力（Falcon-7/40/180B 分别为 1/8/8）。

4.3.2 Rotary positionnal embeddings may only offer a limited edge over ALiBi

在这里插入图片描述
　　Background。默认情况下，注意力机制不会向模型提供位置信息：它仅将序列视为词袋。因此，原始的 Transformer 架构采用绝对正弦嵌入来编码位置信息。然而，绝对嵌入的受欢迎程度随后逐渐下降，社区转而使用相对嵌入。虽然这种转变有很好的经验动机，但实践者尚未在单一的相对位置嵌入上形成：BLOOM 和 MPT 使用 ALiBi，而 GPT-J、PaLM 和 LLaMA 使用旋转位置嵌入（RoPE）。RoPE 经常被认为在上述工作中提供了更好的上游性能，而 ALiBi 则受益于内置的外推能力。另一种最近推出的替代方案是通用相对位置嵌入 (URPE)，它解决了典型相对位置嵌入表达力的缺陷。另外，我们注意到因果模型的自回归mask也为模型提供了一些位置信息，使得没有任何位置嵌入的训练在零样本性能方面可以与绝对正弦训练相媲美。
　　与此项工作同时出现的是，使用 RoPE 实现零样本或微调长度外推的方案，从而弥补了与 ALiBi 在外推方面的差距。
　　Results。我们在 The Pile 上用 30B/60B token上训练了 1B/3B 模型。我们在表 10 中报告了结果。我们没有发现任何证据表明 URPE 的表现优于 RoPE——因为这需要对融合注意力内核进行重大修改才能提供可接受的性能，所以我们没有进一步研究。在 1B 规模下，我们发现使用 RoPE 可能比 ALiBi 更有优势；然而，这种优势在 3B 规模下会减弱，不足以得出明确的结论。ALiBi 的另一个优势是它的计算开销：它的计算成本明显低于 RoPE；但是，使用自定义 Triton 内核（第 5.3.2 节），我们能够减轻这种开销。

Recipe decision。与其他流行的大规模模型一致，我们采用旋转位置嵌入，并使用自定义内核来减轻开销。

4.3.3 The extra memory cost of GLU may not be worth it for cost-efficient training

在这里插入图片描述
　　Background。人们普遍认为，基于门控线性单元的激活函数比 GeLU 等传统激活函数表现更好。PaLM 和 LLaMA 等模型已采用此类激活函数。
　　Scaling。从扩展角度来看，GLU 激活函数也更受青睐，因为它们增加了 MLP 的大小（使其第一层翻倍），将更多的计算转移到简单的矩阵乘法上。然而，这确实需要付出代价：在 MLP 中存储中间激活函数所需的内存更高。请记住，通常，激活函数的输入会保存以备backward（因为重新计算激活函数本身可以忽略不计）。对于门控单元，此输入现在大两倍。总体而言，SwiGLU 将中间激活函数翻倍，并将 MLP 中的参数数量增加 50%：因此，MLP 每个参数的激活内存增加了 33%。
　　Results。在表 11 中，我们在 30 B token的数据 The Pile 上训练 1 B模型，我们发现采用 SwiGLU 对零样本性能没有明显的好处——而且由于评估设置的差异，困惑度的改善正处于不太可能表征实际改进的阈值。我们注意到，这可能是由于 SwiGLU 可能需要专门的超参数调整——对于所有架构消融，我们只是采用了 GPT-3 的消融。此外，我们几乎没有看到 SwiGLU 带来的额外吞吐量提升（因为我们已经使用了并行注意力/MLP 层）。由于我们在 40GB A100 上训练 Falcon 系列以优化成本，因此我们很早就担心内存消耗——因此，SwiGLU 的内存强度更高，性能与 GeLU 相似，这对我们来说可能是净负面的。

Recipe decision。出于对 A100-40GB 上的训练内存占用的担忧，并且由于零样本没有明显提升，我们选择不采用 SwiGLU。

4.3.4 Small tweaks help scalability: parallel layers and no biases in linear layers

在这里插入图片描述
　　Parallel attention and MLP blocks。Wang and Komatsuzaki (2021) 在训练 GPT-J 时首次引入了并行注意力和 MLP 层。这种增强对于降低与张量并行相关的通信成本非常重要：这个简单的修改将每层所需的 all_reduce 数量从两个减少到一个。我们发现零样本性能或困惑度没有明显下降，这与 Chowdhery et al. (2022) 的观点一致，并采用了这种做法。参见图 5 中的说明。
　　No biases。Chowdhery et al. (2022) 发现，消除线性层和层归一化中的偏差可以提高稳定性。我们验证了消除线性层中的偏差不会导致性能下降（见表 11）：无论是语言建模损失还是最终的零样本性能。因此，我们从 Falcon 系列的线性层中消除了偏差。

Recipe decision。我们采用并行注意力和 MLP，并消除线性层的偏差。

4.3.5 Validating best practices for hyperparameters: z-loss, weight decay, LR search

Z-loss。z-loss 首次由 Shazeer et al. (2018) 在 mesh-tensorflow 代码库中引入，旨在通过鼓励 logit 保持接近零来提高训练的稳定性。它可以作为辅助损失来实现： $z\_loss=10^{−4}log^2(\sum_ie^{z_i})$ ，其中 $z_i$ 是模型的输出 logit。请注意，z-loss 对小规模任务性能没有显著影响（表 11）。

Recipe decision。我们采用 z-loss，因为据称它可以提高大规模训练稳定性并且不会影响我们消融中的零样本性能。

在这里插入图片描述
　　Weight decay。我们尝试重现 Chowdhery et al. (2022) 的权重衰减方案，但未能取得任何改进——我们怀疑这是由于初始化的差异造成的。我们发现权重衰减对未去重/质量较低的数据集的影响不成比例（表 12）。我们使用 AdamW 进行权重衰减。

Recipe decision。对于所有 Falcon 模型，我们使用 AdamW 的固定权重衰减 0.1。

在这里插入图片描述
　　Optimal learning rate。设置运行学习率的做法各不相同，从简单的网格搜索到更有原则的方法。我们将在第 4.4 节中进一步讨论我们未能实现和重现后者的一些失败之处；在这一小节中，我们将重点介绍简单的方法及其验证。从广义上讲，设置过高的学习率可能会导致运行发散和训练期间的不稳定；相反，设置过低的学习率会导致一些上游和下游性能下降，从而导致训练效率低下。
　　我们建议通过以下方式搜索可能的学习率：（1）我们选择 4-6 个大致对数间隔的候选学习率，以 GPT-3 中使用的学习率为基础，并倾向于更高的学习率；（2）我们对所有候选学习率进行长达 5 亿个 token 的warm-up；（3）我们选择此时损失最低的学习率，并丢弃任何已经导致峰值的学习率。
　　我们在小规模上测试了这种方法，为 1B 模型挑选了 7 个学习率，然后将warm-up后获得的排名与实际获得的最终排名进行比较。结果如表 13 所示。我们发现，这种简单的方法成功地从warm-up结束时的排名中找到了最佳学习率。更广泛地说，warm-up结束时和训练结束时的排名相对稳定，只有第 2 名和第 3 名会互换位置。

Recipe decision。从候选 LR 中，我们挑选出warm-up后损失最低的 LR。

4.4 Further experimentation required: ideas that did not make the cut

在本节中，我们简要提到了一些我们尝试过但无法重现结果或获得有意义的结果的实践和想法。我们注意到，这不应被视为对这些实践的谴责：许多实践已在流行的模型中成功采用。
　　Alternative training objectives。最大的语言模型通常是用因果解码器专用架构和目标进行训练的。Wang et al. (2022a) 发现，此类模型表现出比 T5 等MASK编码器解码器更好的零样本能力；然而，他们还发现，经过多任务微调后，MASK编码器解码器表现更好，这突显出不同的方案和用例可能更倾向于不同的架构和目标。自始至终，非因果解码器专用（所谓的前缀语言模型）表现不俗，紧随其后。借助 UL2， Tay et al. (2022a) 发现，可以通过对混合目标进行训练来统一这些范式。我们尝试了 UL2，但即使在将任务调整到相关时适应各种范式后，也无法获得零样本性能的提升。由于时间和资源的限制，我们最终没有像 Tay et al. (2022b) 那样进一步推进实验。
　　对于code模型，所谓的中间填充 (FIM) 训练一直很受欢迎，因为它解决了此类模型的常见用例。据称 FIM 几乎不会牺牲自回归建模能力；我们大致能够证实这些结果，显示只有少数任务在中等填充率 (0.25-0.5) 下可能会出现性能下降。低填充率和高填充率对零样本性能的影响最小。然而，由于当时缺乏广泛采用，我们选择跳过 FIM，而是将其视为 Falcon-Coder 模型的调整步骤——这在 Code-LLaMA 中同时得到证明。
　　Principled hyperparameters。我们尝试使用 $µ$ 参数化，以原则性的方式将超参数从较小的运行扩展到较大的运行。不幸的是，我们无法证明我们的超参数估计策略比简单的策略有改进。
　　Alternative optimizers。受到 BERT 和 T5 上出色报告结果的鼓舞，我们尝试使用 Amos，这是 Adam 的替代品，具有自适应学习率和权重衰减。我们无法获得因果解码器专用模型的改进，即使是在小模型上。
　　Conversation mining。在开发 RefinedWeb 时，我们尝试了从网络上挖掘特定类型数据的想法。基于 BERT 模型训练专用分类器通常会导致过度拟合，因此我们改用简单的启发式方法（例如，通过过渡词的密度识别论点，通过查找用户的轮次识别对话）。我们能够获得显着的零样本性能提升，但这些数据非常稀缺。由于模型的训练是在处理完所有 CommonCrawl 之前开始的，因此我们无法有效地显示所有这些数据并优先于标准网络数据使用它，这导致我们将这个想法留给未来的模型。

4.5 Wrapping-it up: validating overall dataset and architecture recipes

在这里插入图片描述
　　为方便起见，我们请读者参阅第 4.4 节，以全面了解 Falcon 配方。我们现在将通过更长时间的训练运行并与最先进的模型进行比较，以更大规模验证配方的性能。我们独立验证：(1) 预训练数据集，特别是其 Web 组件；(2) 架构，通过在 The Pile 上训练采用它的模型。
　　Dataset validation。我们针对 27B token和 350B token分别训练 1B 和 7B 参数模型，以重现以前模型中的常见做法。我们使用基于 GPT-3 和 ALiBi 的基线架构。我们在 The Pile、RefinedWeb（我们的网络数据集）和 Falcon 数据混合上进行训练，后者结合了 RefinedWeb 和精选源，没有任何上采样。最后一种混合是为 Falcon-180B 设计的，目标是总共 3,500B 个token。有关详细信息，请参阅第 5.1 节。
　　在表 14 中，我们发现我们的数据混合显著提升了性能。这些提升中的绝大部分也是由 RefinedWeb 单独实现的，无需精选数据。这凸显了我们之前的发现，即仅使用经过充分过滤和重复数据删除的网络数据就可以训练出高性能模型。我们发现我们的 1B/7B 模型与其他最先进的模型相比毫不逊色，但我们注意到，我们的设置通过稍长的训练时间使其略占优势。
　　Architecture validation。我们遵循数据集验证的设置，并在 The Pile 上为 27B 和 350B 个 token 训练架构验证 1B 模型。请注意，我们未在此实验中包含超参数调整：所有模型都使用权重衰减，并使用与 Brown et al. (2020) 相同的学习率——此实验仅涉及模型本身的架构。
　　我们发现我们的架构性能略有下降（表 14），我们主要将其归因于multi-query导致的参数减少。我们怀疑，multi-query模型的发展可能会缩小这一差距。然而，值得注意的是，虽然数据改进具有非常显著的效果，但架构改进主要侧重于提高训练和推理的可扩展性；它们不会提高任务性能。