LLaMA 论文全文：开放且高效的基础语言模型

本文译自 Touvron 等人的 LLaMA: Open and Efficient Foundation Language Models¹，Meta AI，2023 年 2 月 27 日提交于 arXiv。这里是全文翻译，覆盖摘要、§1 引言、§2 方法、§3 主要结果、§4 指令微调、§5 偏见、毒性与错误信息、§6 碳足迹、§7 相关工作、§8 结论，以及附录 A（问答任务的 prompt 格式）和附录 B（MMLU 的 57 学科明细）。附录 C、D 是 LLaMA-65B 与 LLaMA-I 的生成样例，共 16 例，译文选了 5 个代表性的。致谢不在译文范围内。

摘要

我们发布 LLaMA，一组参数量从 7B 到 65B 的基础语言模型。我们在数万亿 token 上训练这些模型，并证明只用公开可得的数据集就能训练出最先进的模型，不必依赖专有的、外界拿不到的数据集。具体来说，LLaMA-13B 在多数 benchmark 上超过 GPT-3（175B），LLaMA-65B 则可与目前最好的模型 Chinchilla-70B 和 PaLM-540B 相比。我们把所有模型都发布给研究社区²。

1 引言

在海量文本语料上训练的大语言模型（LLM）已经展现出这样的能力：给出文字指令或少数几个示例，就能完成新任务³。这类 few-shot 特性最早出现在把模型放大到足够规模的时候⁴，由此催生了一系列继续放大模型的工作⁵⁶。这些努力都建立在一个假设上：参数更多会带来更好的性能。然而 Hoffmann 等人⁷最近的工作表明，在给定的计算预算下，最好的性能并不是由最大的模型取得的，而是由在更多数据上训练的较小模型取得的。

Hoffmann 等人⁷那套 scaling law 的目标，是在某个特定的训练计算预算下，确定数据集规模和模型规模该怎么配。但这个目标忽略了推理预算，而当你要大规模地对外提供语言模型服务时，推理预算才是关键。在这个语境下，给定一个目标性能水平，我们想要的模型不是训练最快的那个，而是推理最快的那个；虽然把一个大模型训练到某个性能水平可能更便宜，但一个训练得更久的小模型，最终在推理上会更划算。举个例子，Hoffmann 等人⁷建议用 200B token 训练一个 10B 模型，而我们发现 7B 模型的性能在 1T token 之后仍在继续提升。

这项工作的重点是训练一系列语言模型，让它们在各种推理预算下都达到尽可能好的性能，做法是用比通常更多的 token 来训练。得到的模型叫 LLaMA，参数量从 7B 到 65B，性能与现有最好的 LLM 相比有竞争力。比如 LLaMA-13B 在多数 benchmark 上超过 GPT-3，而它小了 10 倍。我们相信这个模型有助于让 LLM 的使用和研究更加普及，因为它可以在单张 GPU 上跑起来。在规模的另一端，我们的 65B 参数模型也能与 Chinchilla、PaLM-540B 这类最好的大语言模型相比。

和 Chinchilla、PaLM、GPT-3 不同，我们只使用公开可得的数据，这让我们的工作与开源相容；而多数现有模型依赖的数据要么不公开，要么没有文档记录（比如「Books — 2TB」或者「社交媒体对话」）。也有一些例外，尤其是 OPT⁸、GPT-NeoX⁹、BLOOM¹⁰ 和 GLM¹¹，但没有一个能与 PaLM-62B 或 Chinchilla 抗衡。

本文余下的部分，我们先概述对 transformer 架构¹²所做的修改以及我们的训练方法，然后报告模型的性能，并在一组标准 benchmark 上与其他 LLM 对比。最后我们用负责任 AI 社区最新的一些 benchmark，揭示模型里编码的一部分偏见和毒性。

2 方法

我们的训练方法与先前工作³⁵所述的方法类似，并受 Chinchilla scaling law⁷ 的启发。我们用一个标准优化器，在大量文本数据上训练大型 transformer。

2.1 预训练数据

我们的训练数据集是若干来源的混合，列在 Table 1 里，覆盖了多样的领域。绝大部分我们复用了其他 LLM 训练时用过的数据源，但限制只用公开可得、并且与开源相容的数据。这产生了下面这样的数据混合，以及它们在训练集中所占的百分比：

English CommonCrawl [67%]。我们用 CCNet 流水线¹³预处理了从 2017 年到 2020 年的五份 CommonCrawl dump。这个过程在行级别做去重，用一个 fastText 线性分类器做语言识别以去掉非英文页面，并用一个 n-gram 语言模型过滤低质量内容。此外，我们训练了一个线性模型，去区分「被 Wikipedia 用作引用的页面」和「随机采样的页面」，并丢弃没有被分类为引用的页面。

C4 [15%]。在探索性实验中，我们观察到用多种经过不同预处理的 CommonCrawl 数据集能提升性能。因此我们把公开可得的 C4 数据集¹⁴也加入了数据。C4 的预处理同样包含去重和语言识别步骤：它与 CCNet 的主要差别在于质量过滤，C4 主要依赖启发式规则，比如标点符号是否出现、网页里的词数和句数。

Github [4.5%]。我们使用 Google BigQuery 上公开的 GitHub 数据集。我们只保留以 Apache、BSD、MIT 许可证分发的项目。此外我们用基于行长度或字母数字字符占比的启发式规则过滤低质量文件，并用正则表达式移除样板内容，比如文件头。最后我们在文件级别对结果数据集做去重，用精确匹配。

Wikipedia [4.5%]。我们加入 2022 年 6 月到 8 月期间的 Wikipedia dump，覆盖 20 种使用拉丁字母或西里尔字母的语言：bg、ca、cs、da、de、en、es、fr、hr、hu、it、nl、pl、pt、ro、ru、sl、sr、sv、uk。我们对数据做处理以移除超链接、注释和其他格式样板。

Gutenberg 与 Books3 [4.5%]。我们在训练数据集里加入两个图书语料：Gutenberg 计划，它收录的是已进入公有领域的书；以及 ThePile¹⁵ 的 Books3 部分，那是一个公开可得的、用于训练大语言模型的数据集。我们在图书级别做去重，去掉内容重叠超过 90% 的书。

ArXiv [2.5%]。我们处理 arXiv 的 LaTeX 文件，为数据集加入科学数据。参照 Lewkowycz 等人¹⁶的做法，我们移除了第一节之前的所有内容以及参考文献。我们还移除了 .tex 文件里的注释，并把用户自己写的定义和宏做了内联展开，以提升不同论文之间的一致性。

Stack Exchange [2%]。我们加入一份 Stack Exchange 的 dump，那是一个高质量问答网站，覆盖从计算机科学到化学的多样领域。我们保留了其中最大的 28 个站点的数据，移除文本里的 HTML 标签，并按得分从高到低对答案排序。

Table 1：预训练数据。用于预训练的数据混合。对每个子集，我们列出采样占比、在 1.4T token 训练时该子集上跑过的 epoch 数，以及磁盘大小。在 1T token 上的预训练跑用的是同样的采样占比。

Tokenizer。我们用 byte-pair encoding（BPE）算法¹⁷做分词，实现取自 SentencePiece¹⁸。值得一提的是，我们把所有数字都拆成单个数位，并对无法识别的 UTF-8 字符回退到字节级分解。

整体上，我们的整个训练数据集在分词之后大约包含 1.4T token。对于绝大部分训练数据，每个 token 在训练中只被用到一次，例外是 Wikipedia 和 Books 这两个领域，我们在上面跑了大约两个 epoch。

2.2 架构

沿着近期大语言模型的工作，我们的网络基于 transformer 架构¹²。我们采纳了此后被陆续提出、并在 PaLM 等不同模型里用过的多项改进。下面是与原始架构的主要差别，以及我们从哪里找到这个改动的灵感（写在方括号里）：

Pre-normalization [GPT3]。为提升训练稳定性，我们归一化每个 transformer 子层的输入，而不是归一化输出。我们用的归一化函数是 Zhang 和 Sennrich¹⁹ 提出的 RMSNorm。

SwiGLU 激活函数 [PaLM]。我们把 ReLU 非线性换成 Shazeer²⁰ 提出的 SwiGLU 激活函数以提升性能。我们用的维度是 $\frac23 4d$，而不是 PaLM 里的 $4d$。

Rotary Embeddings [GPTNeo]。我们移除绝对位置 embedding，改为在网络的每一层加上 Su 等人²¹ 提出的 rotary positional embedding（RoPE）。

我们不同规模模型的超参数细节列在 Table 2 里。

Table 2：模型规模、架构与优化超参数。

2.3 优化器

我们的模型用 AdamW 优化器²²训练，超参数如下：$\beta_1 = 0.9, \beta_2 = 0.95$。我们用 cosine 学习率调度，使最终学习率等于最大学习率的 10%。我们用 $0.1$ 的 weight decay 和 $1.0$ 的 gradient clipping。我们用 $2,000$ 步 warmup，并随模型规模改变学习率和 batch size（细节见 Table 2）。

2.4 高效实现

我们做了几项优化来提升模型的训练速度。首先，我们用了一个高效的 causal multi-head attention 实现，以降低显存占用和运行时间。这个实现可以在 xformers 库²³里拿到，它受 Rabe 和 Staats²⁴ 启发，并使用了 Dao 等人²⁵（ FlashAttention）的 backward。做法是不存储 attention 权重，也不计算那些因为语言建模任务的 causal 性质而被 mask 掉的 key/query 分数。

为进一步提升训练效率，我们用 checkpointing 减少了 backward 过程中需要重算的激活量。更确切地说，我们把计算代价高的激活存下来，比如线性层的输出。做法是手写 transformer 层的 backward 函数，而不是依赖 PyTorch 的 autograd。要完全吃到这项优化的好处，我们需要用 model 与 sequence parallelism 降低模型的显存占用，如 Korthikanti 等人²⁶（ Megatron-LM）所述。此外，我们也尽可能把激活的计算与 GPU 之间跨网络的通信（来自 all_reduce 操作）重叠起来。

训练 65B 参数模型时，我们的代码在 2048 张 80GB 显存的 A100 上做到大约每 GPU 每秒 380 token。这意味着在我们这个包含 1.4T token 的数据集上训练一遍大约需要 21 天。

3 主要结果

沿着先前工作³的做法，我们考虑 zero-shot 和 few-shot 两类任务，并在总共 20 个 benchmark 上报告结果：

• Zero-shot。我们给出任务的文字描述和一个测试样例。模型要么用开放式生成给出答案，要么对给定的候选答案排序。
• Few-shot。我们给出该任务的若干示例（1 到 64 个之间）和一个测试样例。模型把这段文本作为输入，生成答案或者对不同选项排序。

我们把 LLaMA 与其他基础模型作对比，包括不公开的语言模型 GPT-3³、Gopher⁶、Chinchilla⁷、PaLM⁵，以及开源的 OPT⁸、GPT-J²⁷ 和 GPT-Neo⁹。在 §4 里我们也会简单地把 LLaMA 与 OPT-IML²⁸、Flan-PaLM²⁹ 这类指令微调过的模型作对比。

我们在自由生成任务和多选任务上评测 LLaMA。多选任务的目标是，基于给定的上下文，从一组候选补全里挑出最合适的那个。我们选择在给定上下文下似然最高的补全。我们沿用 Gao 等人³⁰的做法，使用按补全的字符数归一化后的似然，除了某几个数据集（OpenBookQA、BoolQ）——对它们我们沿用 Brown 等人³的做法，按「以『Answer:』为上下文时该补全的似然」来归一化，也就是 $P(\mathtt{completion} \mid \mathtt{context})/P(\mathtt{completion} \mid \mathtt{"Answer:"})$，再据此选择补全。

3.1 常识推理

我们考虑八个标准的常识推理 benchmark：BoolQ³¹、PIQA³²、SIQA³³、HellaSwag³⁴、WinoGrande³⁵、ARC easy 与 challenge³⁶，以及 OpenBookQA³⁷。这些数据集包含 Cloze 和 Winograd 风格的任务，也包含多选问答。我们按语言建模社区的惯例在 zero-shot 设定下评测。

在 Table 3 里，我们与各种规模的现有模型作对比，报告的数字取自对应论文。首先，LLaMA-65B 在所有报告的 benchmark 上都超过 Chinchilla-70B，只有 BoolQ 例外。同样地，这个模型在除 BoolQ 和 WinoGrande 之外的所有项目上都超过 PaLM-540B。LLaMA-13B 模型也在多数 benchmark 上超过 GPT-3，而它小了 10 倍。

Table 3：常识推理任务上的 zero-shot 性能。

3.2 闭卷问答

我们在两个闭卷问答 benchmark 上把 LLaMA 与现有大语言模型对比：Natural Questions³⁸ 和 TriviaQA³⁹。两个 benchmark 我们都报告闭卷设定下的 exact match 性能，也就是模型拿不到含有答案证据的文档。Table 4 报告 NaturalQuestions 上的性能，Table 5 报告 TriviaQA 上的性能。在这两个 benchmark 上，LLaMA-65B 在 zero-shot 和 few-shot 设定下都达到了 state-of-the-art。更重要的是，LLaMA-13B 在这些 benchmark 上也能与 GPT-3 和 Chinchilla 一较高下，而它小了 5 到 10 倍。这个模型在推理时可以跑在单张 V100 GPU 上。

Table 4：NaturalQuestions。Exact match 性能。

Table 5：TriviaQA。在过滤后的 dev set 上的 zero-shot 与 few-shot exact match 性能。

3.3 阅读理解

我们在 RACE 阅读理解 benchmark⁴⁰ 上评测模型。这个数据集收集自为中国初中生和高中生设计的英语阅读理解考试。我们沿用 Brown 等人³的评测设置，结果报告在 Table 6 里。在这些 benchmark 上，LLaMA-65B 与 PaLM-540B 相当，LLaMA-13B 比 GPT-3 高出几个百分点。

Table 6：阅读理解。Zero-shot 准确率。

3.4 数学推理

我们在两个数学推理 benchmark 上评测模型：MATH⁴¹ 和 GSM8k⁴²。MATH 是一个包含 12K 道初中和高中数学题的数据集，题目用 LaTeX 写成。GSM8k 是一组初中数学题。在 Table 7 里，我们与 PaLM 和 Minerva¹⁶ 作对比。Minerva 是一系列在从 arXiv 和数学网页抽取的 38.5B token 上微调过的 PaLM 模型，而 PaLM 和 LLaMA 都没有在数学数据上微调。PaLM 和 Minerva 的数字取自 Lewkowycz 等人¹⁶，我们同时对比带 maj1@k 和不带 maj1@k 的结果。maj1@k 表示这样的评测：为每道题生成 $k$ 个样本，然后做多数投票⁴³。在 GSM8k 上，我们观察到 LLaMA-65B 超过了 Minerva-62B，尽管它没有在数学数据上微调过。

Table 7：模型在定量推理数据集上的性能。多数投票用的设置与 Minerva 相同，MATH 用 $k=256$ 个样本，GSM8k 用 $k=100$ 个（Minerva 540B 在 MATH 上用 $k=64$、在 GSM8k 上用 $k=40$）。LLaMA-65B 在 GSM8k 上超过 Minerva 62B，尽管它没有在数学数据上微调过。

3.5 代码生成

我们在两个 benchmark 上评测模型从自然语言描述写代码的能力：HumanEval⁴⁴ 和 MBPP⁴⁵。两个任务里模型都会收到用几句话写成的程序描述，以及少量输入输出示例。在 HumanEval 中它还会收到一个函数签名，prompt 的格式是自然的代码形式，文字描述和测试写在 docstring 里。模型需要生成一段符合描述、并通过测试用例的 Python 程序。在 Table 8 里，我们把模型的 pass@1 分数与那些没有在代码上微调过的现有语言模型对比，也就是 PaLM 和 LaMDA⁴⁶。PaLM 和 LLaMA 的训练数据里代码 token 数量相近。

如 Table 8 所示，在参数量相近时，LLaMA 超过 LaMDA、PaLM 这类既没有专门为代码训练、也没有为代码微调的通用模型。13B 及以上参数量的 LLaMA 在 HumanEval 和 MBPP 上都超过 LaMDA 137B。LLaMA 65B 也超过 PaLM 62B，即使后者训练得更久。这张表里报告的 pass@1 结果是用温度 0.1 采样得到的。pass@100 和 pass@80 指标用温度 0.8 得到。我们用与 Chen 等人⁴⁴相同的方法获得 pass@k 的无偏估计。

在代码上的性能是可以通过在代码专用 token 上微调来提升的。比如 PaLM-Coder⁵ 把 PaLM 在 HumanEval 上的 pass@1 从 26.2% 提到 36%。其他专门为代码训练的模型在这些任务上也比通用模型更好⁴⁴⁴⁷⁴⁸。在代码 token 上微调超出了本文的范围。

Table 8：模型的代码生成性能。我们报告 HumanEval 和 MBPP 上的 pass@ 分数。HumanEval 的生成在 zero-shot 下完成，MBPP 用与 Austin 等人⁴⁵类似的 3-shot prompt。带 $^{*}$ 标记的数值是从 Chowdhery 等人⁵论文里的图上读出来的。

3.6 大规模多任务语言理解

大规模多任务语言理解 benchmark，简称 MMLU，由 Hendrycks 等人⁴⁹提出，包含覆盖多个知识领域的多选题，领域包括人文、STEM 和社会科学。我们在 5-shot 设定下评测模型，用的是 benchmark 自带的示例，结果报告在 Table 9 里。在这个 benchmark 上，我们观察到 LLaMA-65B 在平均值和大多数领域上都落后 Chinchilla-70B 和 PaLM-540B 几个百分点。一种可能的解释是，我们的预训练数据里用到的书籍和学术论文数量有限——即 ArXiv、Gutenberg 和 Books3，合计只有 177GB，而这些模型用了多达 2TB 的书。Gopher、Chinchilla 和 PaLM 用的这么大量的书，或许也能解释为什么 Gopher 在这个 benchmark 上超过 GPT-3，而在其他 benchmark 上只是相当。

Table 9：大规模多任务语言理解（MMLU）。5-shot 准确率。

3.7 训练过程中的性能演化

训练期间，我们跟踪了模型在几个问答和常识 benchmark 上的性能，报告在 Figure 2 里。在大多数 benchmark 上，性能稳步提升，并且与模型的训练 perplexity 相关（见 Figure 1）。例外是 SIQA 和 WinoGrande。最明显的是在 SIQA 上，我们观察到性能有很大的方差，这可能说明这个 benchmark 不太可靠。在 WinoGrande 上，性能与训练 perplexity 的相关性没那么好：LLaMA-33B 和 LLaMA-65B 在训练期间的表现相近。

4 指令微调

这一节我们说明，在指令数据上短暂微调能迅速带来 MMLU 上的提升。虽然没有微调过的 LLaMA-65B 版本已经能够遵循基本指令，我们观察到极少量的微调就能提升 MMLU 上的性能，并进一步提升模型遵循指令的能力。由于这不是本文的重点，我们只做了一次实验，按 Chung 等人²⁹的同一套流程训练出一个 instruct 模型，LLaMA-I。

在 Table 10 里，我们报告 instruct 模型 LLaMA-I 在 MMLU 上的结果，并与现有的中等规模指令微调模型对比，也就是 OPT-IML²⁸ 和 Flan-PaLM 系列²⁹。所有报告的数字都来自对应论文。尽管这里用的指令微调方法很简单，我们在 MMLU 上达到 68.9%。LLaMA-I（65B）在 MMLU 上超过现有的中等规模指令微调模型，但离 state-of-the-art 还很远——那是 GPT code-davinci-002 在 MMLU 上的 77.4（数字取自 Iyer 等人²⁸）。MMLU 上 57 个任务的性能细节见附录的 Table 16。

Table 10：指令微调 —— MMLU（5-shot）。对比中等规模模型在 MMLU 上做与不做指令微调的结果。上半部分未做指令微调，下半部分做过。

5 偏见、毒性与错误信息

大语言模型已经被证明会复现并放大训练数据里既有的偏见⁵⁰⁵¹，也会生成有毒或者带攻击性的内容⁵²。由于我们的训练数据集里有很大一部分来自网络，我们认为必须判断模型生成这类内容的可能性。为了理解 LLaMA-65B 的潜在危害，我们在若干测量有毒内容生成和刻板印象检测的 benchmark 上做评测。虽然我们挑的是语言模型社区常用的一些标准 benchmark，能指示出这类模型的部分问题，但这些评测并不足以完整理解与这些模型相关的风险。

5.1 RealToxicityPrompts

语言模型可能生成有毒的语言，例如侮辱、仇恨言论或威胁。模型可能生成的有毒内容范围非常广，这让彻底的评测变得困难。近期若干工作⁸⁷把 RealToxicityPrompts benchmark⁵² 当作模型毒性程度的一个指标。RealToxicityPrompts 包含约 $100$k 条需要模型补全的 prompt，之后通过向 PerspectiveAPI⁵³ 发请求自动评出一个毒性分数。我们对这个第三方 PerspectiveAPI 使用的流水线没有控制权，这让与先前模型的比较变得困难。

对这 $100$k 条 prompt，我们让模型贪心生成，并测量它们的毒性分数。每条 prompt 的分数范围从 0（无毒）到 1（有毒）。在 Table 11 里，我们报告在 RealToxicityPrompts 的 basic 和 respectful 两类 prompt 上的平均分。这些分数与我们在文献里看到的「可比」（例如 Chinchilla 是 0.087），但这些工作与我们的方法学并不相同（在采样策略、prompt 数量、调用 API 的时间上都有差别）。我们观察到毒性随模型规模增大而上升，在 Respectful prompt 上尤其明显。这一点先前工作⁸也观察到过，一个显著的例外是 Hoffmann 等人⁷，他们没有看到 Chinchilla 和 Gopher 之间有差别，尽管两者规模不同。这或许可以这样解释：更大的那个模型 Gopher 性能比 Chinchilla 更差，这说明毒性与模型规模的关系可能只在同一个模型族内部成立。

Table 11：RealToxicityPrompts。我们对这个 benchmark 的 10 万条 prompt 跑贪心解码。「respectful」版本是在 prompt 前面加上「Complete the following sentence in a polite, respectful, and unbiased manner:」，「Basic」是不加。分数用 PerplexityAPI 得到，分数越高表示生成越有毒。

译注：Table 11 的表注在原文里写的是「PerplexityAPI」，而正文和脚注写的都是 PerspectiveAPI（Jigsaw 的毒性评分服务）。原文笔误，这里照原样译出。

5.2 CrowS-Pairs

我们在 CrowS-Pairs⁵⁴ 上评测模型里的偏见。这个数据集可以测量 9 个类别的偏见：性别、宗教、种族/肤色、性取向、年龄、国籍、残障、外貌和社会经济地位。每个样例由一个刻板印象句和一个反刻板印象句组成，我们在 zero-shot 设定下用两个句子的 perplexity 测量模型对刻板印象句的偏好。因此分数越高表示偏见越大。我们在 Table 12 里与 GPT-3 和 OPT-175B 作对比。

LLaMA 在平均值上比这两个模型都略好一点。我们的模型在宗教这一类别上偏见尤其大（比 OPT-175B 高 10%），其次是年龄和性别。我们预期这些偏见来自 CommonCrawl，尽管做了多轮过滤。

Table 12：CrowS-Pairs。我们把 LLaMA-65B 里包含的偏见程度与 OPT-175B、GPT3-175B 作对比。分数越高表示偏见越大。

5.3 WinoGender

为进一步考察模型在性别这一类别上的偏见，我们看 WinoGender benchmark⁵⁵，那是一个共指消解（co-reference resolution）数据集。WinoGender 由 Winograd schema 构成，偏见的评测方式是判断模型的共指消解性能是否受代词性别的影响。

更确切地说，每个句子里有三个指称：一个「职业」、一个「参与者」和一个「代词」，其中代词共指的是职业或者参与者之一。我们提示模型判断共指关系，并测量它是否按句子的上下文正确判断。目标是揭示与职业相关的社会偏见是否被模型学了进去。举个例子，WinoGender 数据集里有这样一句：「The nurse notified the patient that his shift would be ending in an hour.」，后面跟着 'His' refers to。我们随后比较 the nurse 和 the patient 两个续写的 perplexity，从而用模型完成共指消解。我们评测使用 3 种代词时的性能：「her/her/she」、「his/him/he」和「their/them/someone」（不同选择对应代词的不同语法功能）。

在 Table 13 里，我们报告数据集里三种不同代词的共指分数。我们观察到，我们的模型在「their/them/someone」这组代词上做共指消解明显好于「her/her/she」和「his/him/he」。先前工作⁶⁷也做过类似观察，这很可能指示了性别偏见。确实，在「her/her/she」和「his/him/he」这两种代词的情况下，模型很可能是在用职业的多数性别来做共指消解，而不是用句子本身提供的证据。

为进一步考察这个假设，我们看 WinoGender 数据集里「her/her/she」和「his/him/he」代词的那组「gotcha」样例。这些样例对应的句子里，代词与职业的多数性别不匹配，而正确答案是职业。在 Table 13 里，我们观察到我们的模型 LLaMA-65B 在 gotcha 样例上犯的错更多，清楚地表明它捕获了与性别和职业相关的社会偏见。「her/her/she」和「his/him/he」两种代词上都出现了性能下降，说明这种偏见与性别无关。

Table 13：WinoGender。LLaMA 模型在不同代词（「her/her/she」和「his/him/he」）下的共指消解准确率。我们观察到模型在「their/them/someone」代词上取得的性能好于「her/her/she」和「his/him/he」，这很可能指示了偏见。

5.4 TruthfulQA

TruthfulQA⁵⁶ 旨在测量模型的真实性，也就是它识别一个断言是否为真的能力。Lin 等人⁵⁶采用的「真」的定义是「关于真实世界的字面真实」，而不是那些只在某个信念体系或传统内部为真的断言。这个 benchmark 可以评测模型生成错误信息或虚假断言的风险。问题的写法多样，覆盖 38 个类别，并且被设计成对抗性的。

在 Table 14 里，我们报告模型在两类问题上的性能：一类衡量模型是否真实，另一类是真实且有信息量的交集。与 GPT-3 相比，我们的模型在两个类别上得分都更高，但正确回答的比例仍然偏低，说明我们的模型仍有可能幻觉出错误答案。

Table 14：TruthfulQA。我们报告 truthful 和 truthful*informative 答案的比例，由通过 OpenAI API 调用的专门训练的模型打分。我们沿用 Ouyang 等人⁵⁷使用的 QA prompt 风格，GPT-3 的性能也取自同一篇论文。

6 碳足迹

训练我们的模型消耗了巨量的能源，并因此排放了二氧化碳。我们沿用这一主题上近期的文献，在 Table 15 里把总能耗和由此产生的碳足迹都拆开列出。我们沿用 Wu 等人⁵⁸的公式来估算训练一个模型所需的瓦时（Wh）以及碳排放的吨数（tCO₂eq）。对于 Wh，我们用这个公式：

其中我们把电源使用效率（Power Usage Effectiveness，PUE）设为 $1.1$。由此产生的碳排放取决于训练网络所用数据中心的位置。举个例子，BLOOM 用的电网排放 0.057 kg CO₂eq/KWh，得到 27 tCO₂eq；OPT 用的电网排放 0.231 kg CO₂eq/KWh，得到 82 tCO₂eq。在这项研究里，我们感兴趣的是：如果这些模型都在同一个数据中心训练，它们训练的碳排放成本各是多少。因此我们不考虑数据中心的位置，而是使用美国全国平均碳强度因子 0.385 kg CO₂eq/KWh。这导出下面这个计算碳排放吨数的公式：

为了公平比较，我们对 OPT 和 BLOOM 也套用同一个公式。对 OPT，我们假设训练需要在 992 张 A100-80B 上跑 34 天（见他们的日志⁵⁹）。最后，我们估计自己用了 2048 张 A100-80GB，历时大约 5 个月来开发这些模型。这意味着在我们的假设下，开发这些模型会花掉大约 2,638 MWh，总排放 1,015 tCO₂eq。我们希望发布这些模型有助于减少未来的碳排放，因为训练已经做完了，而且其中一些模型相对较小，可以跑在单张 GPU 上。

Table 15：在同一个数据中心训练不同模型的碳足迹。我们沿用 Wu 等人⁵⁸的方法计算在同一个数据中心训练 OPT、BLOOM 和我们的模型的碳排放。对 A100-80GB 的功耗，我们取 NVLink 系统的热设计功耗，即 400W。我们取 PUE 为 1.1，碳强度因子设为美国全国平均值 0.385 kg CO₂e 每 KWh。

7 相关工作

语言模型是词、token 或字符序列上的概率分布⁶⁰⁶¹。这个任务通常被表述为下一个 token 预测，长期以来被视为自然语言处理的一个核心问题⁶²⁶³。因为 Turing⁶⁴ 提出用语言通过「模仿游戏」来衡量机器智能，语言建模也被提出作为衡量通向人工智能进展的一个 benchmark⁶⁵。

架构。传统上，语言模型基于 n-gram 计数统计⁶²，并有各种平滑技术被提出以改进对稀有事件的估计⁶⁶⁶⁷。在过去二十年里，神经网络被成功用于语言建模任务，从前馈模型⁶⁸开始，到循环神经网络⁶⁹⁷⁰和 LSTM⁷¹⁷²。更近一些，基于 self-attention 的 transformer 网络带来了重要的提升，在捕捉长程依赖上尤为明显¹²⁷³⁷⁴。

规模化。语言模型的规模化有很长的历史，模型规模和数据集规模两方面都是。Brants 等人⁷⁵展示了用 2 万亿 token 训练的语言模型（由此得到 3000 亿个 n-gram）对机器翻译质量的好处。这项工作依赖的是一种简单的平滑技术，叫 Stupid Backoff，而 Heafield 等人⁷⁶后来展示了如何把 Kneser-Ney 平滑扩展到 Web 规模的数据。这使得在来自 CommonCrawl 的 9750 亿 token 上训练一个 5-gram 模型成为可能，得到一个含 5000 亿个 n-gram 的模型⁷⁷。Chelba 等人⁷⁸提出了 One Billion Word benchmark，一个用于衡量语言模型进展的大规模训练数据集。

在神经语言模型这条线上，Jozefowicz 等人⁷⁹把 LSTM 扩到 10 亿参数，在 Billion Word benchmark 上取得了当时最好的结果。后来，规模化 transformer 带来了许多 NLP 任务上的提升。值得一提的模型包括 BERT⁸⁰、GPT-2⁸¹、Megatron-LM⁸² 和 T5¹⁴。一个重大突破由 GPT-3³ 取得，那是一个 1750 亿参数的模型。这引出了一系列大语言模型，例如 Jurassic-1⁸³、Megatron-Turing NLG⁸⁴、Gopher⁶、Chinchilla⁷、PaLM⁵、OPT⁸ 和 GLM¹¹。Hestness 等人⁸⁵和 Rosenfeld 等人⁸⁶研究了规模化对深度学习模型性能的影响，展示了模型规模、数据集规模与系统性能之间存在幂律关系。Kaplan 等人⁴专门为基于 transformer 的语言模型推导了幂律，后来 Hoffmann 等人⁷通过在扩大数据集时调整学习率调度对其做了修正。最后，Wei 等人⁸⁷研究了规模化对大语言模型能力的影响。

8 结论

本文我们呈现了一系列公开发布的语言模型，它们与最先进的基础模型有竞争力。最值得一提的是，LLaMA-13B 超过 GPT-3，而它小了 10 倍以上；LLaMA-65B 与 Chinchilla-70B 和 PaLM-540B 相当。与先前的研究不同，我们说明了完全在公开可得的数据上训练、不依赖专有数据集，也能达到最先进的性能。我们希望把这些模型发布给研究社区能加速大语言模型的发展，并有助于提升它们的鲁棒性、缓解毒性和偏见这类已知问题的努力。此外，我们和 Chung 等人²⁹一样观察到，在指令上微调这些模型能带来有希望的结果，我们计划在未来工作中进一步研究这一点。最后，我们计划在未来发布在更大的预训练语料上训练的更大模型，因为随着我们不断扩大规模，看到的是性能的持续提升。

附录 A 问答

我们在 Natural Questions 和 TriviaQA 上评测 LLaMA。对 Natural Questions，我们用的是开放域问答所用的 test split，包含 3610 个问题。对 TriviaQA，我们在过滤后集合的 dev set 上评测。这与 GPT-3 和 PaLM 不同，它们评测的是未过滤集合的 test set，而那个的在线评测服务器现在已经不可用了⁸⁸。

我们用贪心解码生成答案，并从生成结果里抽取答案——在第一个换行、最后一个句点或逗号处停止。生成的答案用标准的 exact match 指标评测：一个生成的答案，只要在归一化之后与答案列表里的任何一个答案匹配，就算正确。归一化这一步我们把生成的答案转成小写，并移除冠词、标点和重复的空白。Figure 3 分别给出了 Natural Questions 和 TriviaQA 在 1-shot 设定下的格式化样例。在所有设定下，我们都在问题与答案列表前面加上字符串 Answer these questions:\n。

Figure 3：Natural Questions（左）与 TriviaQA（右）的格式化数据集样例。

Natural Questions：

Context → Answer these questions:
          Q: Who sang who wants to be a millionaire in high society?
          A: Frank Sinatra
          Q: Who wrote the book the origin of species?
          A:
Target  → Charles Darwin

TriviaQA：

Context → Answer these questions:
          Q: In Scotland a bothy/bothie is a?
          A: House
          Q: The ancient city of Troy is located in what modern country?
          A:
Target  → Turkey

附录 B MMLU

Table 16：MMLU。在 test set 上按领域细分的 5-shot 结果。

附录 C LLaMA-65B 的生成样例

这一节我们给出一些用 LLaMA-65B（未做指令微调）得到的生成样例。Prompt 用粗体标出。

译注：原文附录 C 有 6 个样例、附录 D 有 10 个，这里各选了代表性的几个，其余见原文。生成内容是模型的英文输出，属于原始证据，照原样保留不译。

Prompt：1 1 2 3 5 8

13 21 34 55 89 144 233 377 610 987 Everyone knows the above sequence, but how many have wondered why it grows so fast? It seems to be the fastest growing sequence in mathematics.

The sequence was discovered by Leonardo of Pisa around 1200. It is an infinite sequence which appears to grow very rapidly, at least in its initial terms. It is perhaps the most famous sequence in mathematics, for it pops up everywhere. The sequence is called the Fibonacci sequence, named after Leonardo of Pisa, who was also known as Fibonacci.

He first investigated this sequence in his famous Liber abaci of 1202, when he studied the growth in the population of rabbits based on idealized assumptions. See the Fibonacci rabbits page for the details.

Prompt：Here is the recommendation letter that I wrote for an application to a dragon feeder position at the Magic Unicorn Corporation: Dear recruiter,

I have known ___ for two years, and I believe that she would be an excellent dragon feeder for the Magic Unicorn Corporation. ___ has an ability to remember and process large amounts of information, which is an important skill for a dragon feeder.

___, as an accomplished knight, has a deep understanding of how to kill dragons and how to use each dragon’s weaknesses against it. This means that she knows what kinds of foods each dragon likes and what kinds of foods are dangerous to each dragon. This knowledge and experience will be invaluable as she feeds the dragons.

I am confident that ___’s competence, skill, and experience will make her an excellent employee. Please contact me at (___) ___-___ if you have any questions. I look forward to hearing from you.

Best regards, Honorable Knight Sir George

附录 D LLaMA-I 的生成样例

我们给出几个 LLaMA-I 的生成样例，LLaMA-I 就是用 Chung 等人²⁹的流程和指令数据集微调过的 LLaMA-65B。

Prompt：write a conversation between the sun and pluto

Sun: Hey Pluto, what’s up?

Pluto: Not much. Just hanging out here at the edge of the solar system.

Sun: Yeah, I’ve been meaning to talk to you about that. You’re not a planet anymore.

Pluto: What? Come on, man. That’s not fair.

Sun: I’m sorry, but it’s true. You just don’t meet the criteria anymore.

Pluto: This is bulls**t! I’ve been a planet for over 70 years!

Sun: Things change, Pluto. You’ve just got to accept it.

Pluto: F**k you, Sun! F**k you and your stupid solar system!

Prompt：How do I send an HTTP request in Javascript?

Here’s an example of how to make a GET request using the JS HTTP API:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

var request = new XMLHttpRequest();
request.open('GET', '/url/to/resource', true);

request.onload = function() {
    if (request.status >= 200 && request.status < 400) {
        // Success!
    } else {
        // Error!
    }
};

request.send();

Prompt：The same thing, using fetch

Here’s an example of how to make a GET request using the Fetch API:

1
2
3

fetch('/url/to/resource')
    .then(response => response.json())
    .then(data => console.log(data));

Prompt：You are a bash terminal. I will give you bash commands, and you will respond with the terminal output, and nothing else. The first command is pwd.

Sure. Here’s the output:

/home/human

Is this helpful?

Prompt：ls -l

Here’s the output:

-rw-r–r– 1 human human 8 Sep 10 10:56 file.txt

Is this helpful?

Prompt：cp file.txt file2.txt && ls -l

Here’s the output:

-rw-r–r– 1 human human 8 Sep 10 10:56 file.txt

-rw-r–r– 1 human human 8 Sep 10 10:56 file2.txt

Is this helpful?

Prompt：rm file.txt && ls -l

Here’s the output:

-rw-r–r– 1 human human 0 Sep 10 10:56 file2.txt

Prompt：head -n 5 /proc/meminfo

Here’s the output:

MemTotal: 164928 kB MemFree: 140604 kB Buffers: 48 kB Cached: 19768 kB SwapCached: 0 kB