OpenAI 最新模型 GPT-4 大揭秘：从架构、基础设施、训练数据集、成本、视觉到 MoE

站长之家(ChinaZ.com) 7月11日消息:今天 SemiAnalysis 的 Dylan Patel 和 Gerald Wong 发表了一篇题为《GPT-4 Architecture,Infrastructure,Training Dataset,Costs,Vision,MoE》的文章，揭示 GPT-4 的所有细节。

文章中详细介绍了 GPT-4 的架构、训练和推理的基础设施、参数量、训练数据集、token 数、成本、混合专家模型（Mixture of Experts，MoE）等非常具体的参数和信息。

文章还同时还说明了在不同的路线选择上，OpenAI 面临的各类权衡，并直言，对 GPT-4 而言，最有趣的是理解 OpenAI 为什么会做出某些架构决策。

据了解，Dylan Patel 同样也是谷歌内部文件泄漏事件的作者。而 DeepMind CEO Hassabis 此前在接受媒体采访时，确认了这份谷歌被泄漏的文件的真实性。

原文翻译如下：

OpenAI 的 GPT-4 架构保持封闭，不是因为对人类的存在风险，而是因为他们所建立的模型是可以复制的。实际上，我们预计 Google、Meta、Anthropic、Inflection、Character、腾讯、字节跳动、百度等公司在短期内都将拥有与 GPT-4 同等甚至更强大的模型。

不要误会，OpenAI 拥有令人惊叹的工程能力，他们所构建的是令人难以置信的成果，但他们所采用的解决方案并非魔法。这是一个优雅的解决方案，其中包含许多复杂的权衡。扩大规模只是竞争的一部分。OpenAI 最持久的优势在于他们在实际应用中的使用量最大、拥有领先的工程人才，并且能够通过未来的模型继续领先于其他公司。

我们从多个渠道收集了关于 GPT-4 的大量信息，今天我们想分享一下。这包括模型架构、训练基础设施、推理基础设施、参数数量、训练数据集组成、token 数量、层次数量、并行策略、多模态视觉适应、不同工程权衡背后的思路、独特的实施技术以及他们如何缓解与庞大模型推理相关的一些最大瓶颈。

GPT-4 最有趣的方面是理解他们为何做出某些架构决策。

此外，我们还将概述 GPT-4 在 A100 上的训练和推理成本，并展示它在下一代模型架构中与 H100 的扩展情况。

首先，从 GPT-3 到 GPT-4，OpenAI 希望将模型扩大 100 倍，但成本是一个问题。密集的 Transformer 模型无法再进一步扩展。密集 Transformer 是 OpenAI GPT-3. Google PaLM、Meta LLAMA、TII Falcon、MosaicML MPT 等使用的模型架构。我们可以轻松地列举出使用这种相同架构的 50 家公司。这是一个不错的架构，但在扩展方面存在缺陷。

关于密集模型的训练成本，我们之前已经讨论过，在密集模型即将面临的 AI 瓶颈方面。在那里，我们透露了 OpenAI 在 GPT-4 的架构以及各种现有模型的训练成本。

在过去的六个月中，我们意识到训练成本是无关紧要的。

当然，乍看起来可能有些疯狂，需要数千万甚至数亿美元的计算时间来训练一个模型，但对于这些公司来说，这些开支微不足道。这实际上是一个资本支出项目，规模越大，效果越好。唯一的限制因素是将计算资源扩展到人类可以获得反馈并修改架构的时间尺度。

在接下来的几年里，Google、Meta 和 OpenAI/微软等多家公司将在价值超过一千亿美元的超级计算机上进行模型训练。Meta 每年在「元宇宙」上烧掉 160 亿美元，Google 每年在多个项目上浪费 100 亿美元，但这些项目永远无法实现。亚马逊在 Alexa 上损失了超过 500 亿美元。加密货币在毫无价值的事物上浪费了超过 1000 亿美元。

这些公司和整个社会可以且将会在创建能够训练单一大型模型的超级计算机上花费超过一千亿美元。然后，这些大型模型可以以多种方式进行产品化。这一努力将在多个国家和公司中复制。这是新的太空竞赛。与以前的浪费不同的是，通过人工智能，短期内将产生实际价值，例如人工助手和自主代理。

扩展人工智能的更重要问题，真正的 AI 瓶颈在于推理。目标是将训练计算与推理计算分离。这就是为什么训练 Chinchilla 对于任何将要部署的模型来说都是最佳的。这也是为什么要使用稀疏模型架构；在推理过程中，并非每个参数都被激活。

真正的问题是将这些模型扩展到用户和代理之间的推理成本远远超过了训练成本。推理成本比训练成本高出数倍。这是 OpenAI 在模型架构和基础设施方面的创新目标。

对于大型模型的推理，它是一个多变量问题，对于密集模型而言，模型大小成为了问题。我们之前在这方面详细讨论过边缘计算，但数据中心的问题陈述非常相似。简而言之，设备对于大型语言模型来说永远无法具备足够的内存带宽，以实现特定水平的吞吐量。即使有足够的带宽，边缘设备上的硬件计算资源利用率也将非常低。

即使使用最新的 Nvidia H100 GPU 服务器，8 个 H100 也无法以每秒 33.33 个 token 的速度为拥有 1 万亿参数的密集模型提供服务。此外，8 个 H100 在每秒 20 个 token 的情况下的 FLOPS 利用率仍然不到 5%，导致推理成本非常高。实际上，对于 8 路张量并行的 H100 系统，目前在 3000 亿前馈参数左右存在推理约束。

然而，OpenAI 通过使用 A100 实现了人类的阅读速度，并以每 1000 个 token 仅 0.06 美元的低价广泛提供服务。这是因为它是稀疏的，即并非每个参数都被使用。

说了这么多，让我们来谈谈 GPT-4 的模型架构、训练基础设施、推理基础设施、参数数量、训练数据集组成、token 数量、层次数量、并行策略、多模态视觉编码器、不同工程权衡的思路、独特的实施技术以及如何缓解与庞大模型推理相关的一些最大瓶颈的问题。

以下是网络流传付费墙内容 GPT 翻译：

GPT-4 模型架构

GPT-4 的规模是 GPT-3 的 10 倍以上。据我们了解，它具有大约 1.8 兆参数，分布在 120 个层，而 GPT-3 具有大约 1750 亿参数。

OpenAI 通过使用混合专家（MoE）模型，成功地控制了成本。此外，OpenAI 在其模型中使用了 16 个专家，每个专家的 MLP 参数约为 1110 亿。其中有 2 个专家路由到每个前向传递。

虽然文献中谈论了选择将每个 token 路由到哪个专家的高级路由算法，但据称 OpenAI 目前的 GPT-4 模型的路由算法相当简单。此外，注意力机制共享大约 550 亿参数。

每次前向传递推理（生成 1 个 token）只使用约 2800 亿参数和 560 TFLOPS。这与纯密集模型每次前向传递所需的约 1.8 兆参数和 3700 TFLOPS 形成了对比。

数据集成

OpenAI 在大约 13 兆 token 上对 GPT-4 进行了训练。考虑到 RefinedWeb 的 CommonCrawl 包含大约 5 兆高质量 token，这是有道理的。供参考，Deepmind 的 Chinchilla 模型和 Google 的 PaLM 模型分别使用了大约 1.4 兆 token 和 0.78 兆 token 进行训练。甚至据称 PaLM 2 是在大约 5 兆 token 上进行训练的。

该数据集不包含 13 兆个独特 token。相反，由于缺乏高质量 token，该数据集包含多个时期。文本数据有 2 个时期，代码数据有 4 个时期。有趣的是，这远远不及 Chinchilla 的最佳选择，表明需要以双倍的 token 数量对模型进行训练。

这表明在网络上缺乏易于获取的 token。高质量文本 token 的数量是其中的 1000 倍，而音频和视觉 token 的数量更多，但是获取它们并不像网页抓取那么简单。

他们拥有来自 Scale Al 和内部的数百万行指令微调数据，但可惜的是，我们找不到太多关于他们的强化学习数据。

预训练阶段的上下文长度为 8k。32k 的 token 长度版本是在预训练后的 8k 基础上进行微调的。

批量大小逐渐在几天内逐步增加，但到最后，OpenAI 使用的批量大小为 6000 万！当然，由于不是每个专家都看到所有 token，这实际上只是每个专家每批次处理 750 万个 token。

并行策略

在所有 A100 GPU 上进行并行化的策略非常重要。他们采用了 8 路张量并行，因为这是 NVLink 的极限。此外，我们听说他们正在使用 15 路管线并行。从计算时间和数据通信的角度来看，理论上管线并行的数量太多了，但如果他们受到内存容量限制，那么这是有道理的。

纯粹的管线 张量并行时，每个 GPU 仅参数就需要约 30GB（FP16）。一旦加上 KV 缓存和开销，理论上如果 OpenAI 的大部分 GPU 都是 40GB 的 A100，则这是有道理的。他们可能使用了 ZeRo 阶段 1。可能他们使用了块级 FSDP 或混合共享数据并行。

至于为什么他们没有使用完整模型 FSDP，可能是因为通信开销较高。尽管 OpenAI 的大多数节点之间有高速网络连接，但并非所有节点之间都是如此。我们相信至少有一些集群之间的带宽比其他集群低得多。

训练成本

OpenAI 在 GPT-4 的训练中，使用了大约 25，000 个 A100 芯片，在 90 至 100 天的时间内进行了约 32% 至 36% 的 MFU（平均功能利用率）。

另一个原因是在这么多 GPU 之间进行全局归约的代价非常高。如果我们的猜测是正确的，那么该集群实际上是由许多较小的集群组成的，它们之间的网络连接非常薄弱，即集群的不同部分之间的非阻塞连接为 800G/1.6T，但这些部分只能以 200G/400G 的速度连接起来。

如果他们在云中的成本约为每小时 1 美元的 A100 芯片，仅这次训练的成本就约为 6300 万美元。这还没有考虑到所有的实验、失败的训练运行和其他成本，比如数据收集、强化学习和人员成本等。由于这些因素，实际成本要高得多。此外，这意味着您需要有人购买芯片/网络/数据中心、承担资本支出并将其租给您。

目前，使用约 8，192 个 H100 芯片，以每小时 2 美元的价格，在约 55 天内可以完成预训练，成本约为 2150 万美元。需要注意的是，我们相信到今年年底将有 9 家公司将拥有更多的 H100 芯片。并非所有这些公司都会将它们全部用于单次训练运行，但那些这样做的公司将会拥有更大规模的模型。Meta 将在今年年底拥有超过 10 万个 H100 芯片，但其中相当多的芯片将分布在他们的数据中心用于推理。他们最大的单个集群仍然将超过 25，000 个 H100 芯片。

到今年年底，很多公司将拥有足够的计算资源来训练与 GPT-4 规模相当的模型。

MoE 的权衡

在推理过程中，MoE 是一种很好的方式，可以在推理时减少参数数量，同时增加参数数量，这对于编码更多的信息每个训练 token 是必需的，因为获取足够的高质量 token 非常困难。如果 OpenAI 真的试图实现 Chinchilla 最佳化，他们将不得不在训练中使用两倍于目前的 token 数量。

尽管如此，OpenAI 做出了多个权衡。例如，在推理过程中，MoE 非常难处理，因为模型的每个部分在每个 token 生成时都不会被使用。这意味着在为用户提供服务时，某些部分可能处于闲置状态，而其他部分则正在使用。这对利用率产生了很大的负面影响。

研究人员已经表明，使用 64 到 128 个专家比使用 16 个专家的损失更小，但那只是纯粹的研究结果。减少专家的数量有多个原因。OpenAI 选择 16 个专家的原因之一是因为更多的专家在许多任务上很难进行泛化。使用更多的专家也可能更难实现收敛。在如此大规模的训练运行中，OpenAI 选择在专家数量上更保守一些。

此外，减少专家的数量还有助于他们的推理基础设施。在采用专家混合推理架构时，存在各种困难的权衡。在探讨 OpenAI 面临的权衡和他们所做的选择之前，我们先从 LLM 的推理基本权衡开始。

推理的权衡

在大型语言模型的推理中，有 3 个主要的权衡，它们发生在批量大小（服务的并发用户数）和使用的芯片数量之间。

延迟 - 模型必须以合理的延迟做出响应。人们不想在等待输出开始流入聊天应用程序之前等待几秒钟。预加载（输入 token）和解码（输出 token）需要不同的时间来处理。

吞吐量 - 模型必须以每秒输出一定数量的 token。大约每秒 30 个 token 是人类使用所需的。对于其他各种用途，较低和较高的吞吐量都可以接受。

利用率 - 运行模型的硬件必须实现高利用率，否则成本将过高。虽然可以使用更高的延迟和较低的吞吐量将更多用户请求进行分组，从而实现更高的利用率，但这会增加难度。

LLM 的推理完全是关于平衡两个主要因素：内存带宽和计算。在最过度简化的术语中，每个参数都必须读取，并且与之相关联的是 2 个 FLOP。因此，大多数芯片的比例（例如 H100 SXM 芯片只有 3TB/s 的内存带宽，但有 2，000 TFLOP/s 的 FP8）在批量大小为 1 的推理中完全不平衡。如果只为一个用户提供服务，批量大小为 1，那么为了每个 token 生成，所需的内存带宽主导推理时间。计算时间几乎为零。为了有效地将大型语言模型扩展到多个用户，批量大小必须超过 4。多个用户会分摊参数读取的成本。例如，对于批量大小为 256 或 512，每个字节的内存读取有 512 个 FLOP/s 或 1024 个 FLOP/s。

这个比例更接近于 H100 的内存带宽与 FLOPS 之间的比例。这有助于实现更高的利用率，但代价是更高的延迟。

许多人将内存容量视为 LLM 推理的一个主要瓶颈，原因是大型模型需要多个芯片进行推理，而较大的内存容量会使其适应的芯片数量减少，但实际上，最好使用超过所需容量的芯片，以便将延迟降低，提高吞吐量，并且可以使用更大的批量大小来实现越来越高的利用率。

谷歌在他们的 PaLM 推理论文中展示了这些权衡。然而，值得注意的是，这是针对像 PaLM 这样的稠密模型，而不是像 GPT-4 这样的稀疏模型。

如果一个应用程序要求最低的延迟，我们需要应用更多的芯片，并将模型划分为尽可能多的部分。较小的批量大小通常可以实现较低的延迟，但较小的批量大小也会导致更差的利用率，从而导致每个 token 的总成本（以芯片秒或美元计）更高。如果一个应用程序需要离线推理，并且延迟不是问题，主要目标是最大化每个芯片的吞吐量（即尽量减少每个 token 的总成本）。

增加批量大小是最高效的，因为较大的批量通常可以实现更好的利用率，但某些对于小批量大小来说不高效的划分策略在批量大小增大时变得高效起来。更多的芯片和更高的批量大小是最便宜的，因为它们可以增加利用率，但这也引入了一个第三个变量，即网络时间。某些将模型分割到不同芯片上的方法对于延迟更高效，但与利用率相互制衡。

内存时间和非注意计算时间都与模型大小成正比，与芯片数量成反比。然而，对于给定的分区布局，芯片间通信所需的时间下降得较慢（或根本不下降），因此随着芯片数量的增加，它变得越来越重要，成为一个越来越重要的瓶颈。虽然我们今天只是简单地讨论一下，但应该注意到，随着批量大小和序列长度的增长，KV 缓存的内存需求会急剧增加。如果一个应用程序需要生成具有较长注意力上下文的文本，则推理时间会显著增加。

对于一个具有多头注意力的 500B 模型，注意力 KV 缓存会变得很大：对于批量大小为 512 和上下文长度为 2048，KV 缓存总共达到 3TB，这是模型参数大小的 3 倍。芯片上的内存需要将此 KV 缓存从芯片外存加载到内存中，而此期间芯片的计算核心基本上处于闲置状态。较长的序列长度对内存带宽和内存容量特别不利。OpenAI 的 16k 序列长度 GPT 3.5 turbo 和 32k 序列长度 GPT 4 的成本要高得多，因为由于内存限制，它们无法使用更大的批量大小。

较低的批量大小导致较低的硬件利用率。此外，随着序列长度的增加，KV 缓存也会变得更大。KV 缓存无法在用户之间共享，因此需要单独的内存读取，进一步成为内存带宽的瓶颈。

GPT-4 的推理权衡和基础设施

以上所有内容在 GPT-4 推理中都很困难，但是模型架构采用了专家混合模型（MoE），这引入了一整套新的困难。每个 token 生成的前向传递可以路由到不同的专家集合中。这对于在批量大小较大时在吞吐量、延迟和利用率之间实现的权衡造成了困扰。

OpenAI 的 GPT-4 有 16 个专家，每个前向传递中有 2 个专家。这意味着如果批量大小为 8，每个专家的参数读取可能只是批量大小为 1。更糟糕的是，可能一个专家的批量大小为 8，而其他的专家可能是 4. 1 或 0。每次 token 生成，路由算法都会将前向传递发送到不同的方向，导致 token 到 token 的延迟以及专家批量大小的显著变化。推理基础设施是 OpenAI 选择较少的专家数量的主要原因之一。如果他们选择了更多的专家，内存带宽将更加成为推理的瓶颈。

OpenAI 在推理集群上经常达到 4k 的批量大小，这意味着即使在专家之间进行了最佳的负载均衡，专家的批量大小也只有约 500 个。这需要非常大量的使用才能实现。我们了解到，OpenAI 在一个由 128 个 GPU 组成的集群上运行推理。他们在多个数据中心和地理位置上都有多个这样的集群。推理是在 8 路张量并行和 16 路流水线并行上进行的。每个由 8 个 GPU 组成的节点只有大约 130B 的参数，即每个 GPU 在 FP16 模式下不到 30GB，在 FP8/int8 模式下不到 15GB。这使得推理可以在 40GB 的 A100 芯片上运行，前提是所有批次的 KV 缓存大小不会过大。

包含各种专家的单个层不会分割到不同的节点上，因为这会使网络流量过于不规则，并且在每个 token 生成之间重新计算 KV 缓存的代价太高。对于任何未来的 MoE 模型扩展和条件路由，如何处理 KV 缓存的路由是一个最大的困难。

模型有 120 个层，所以将其平均分配到 15 个不同的节点上是很简单的，但由于第一个节点需要进行数据加载和嵌入，所以在推理集群的主节点上放置较少的层是有意义的。此外，我们听到了一些关于推理的猜测解码的传言，我们稍后会讨论，但我们不确定是否相信这些传言。这也可以解释为什么主节点需要包含较少的层。

GPT-4 的推理成本

与 175B 参数的 Davinchi 模型相比，GPT-4 的成本是其 3 倍，尽管其前馈参数只增加了 1.6 倍。这主要是因为 GPT-4 需要更大的集群并实现了更低的利用率。

我们认为，对于 128 个 A100 来推理 GPT-4 8k 序列长度，每 1ktoken 的成本是 0.0049 美分，而对于 128 个 H100 来推理 GPT-4 8k 序列长度，每 1ktoken 的成本是 0.0021 美分。

值得注意的是，我们假设有较高的利用率，并保持较高的批量大小。这可能是一个错误的假设，因为很明显 OpenAI 有时的利用率非常低。我们假设 OpenAI 在低谷时段关闭集群，并重新调整这些节点以从检查点恢复对较小测试模型的训练，尝试各种新技术。这有助于降低推理成本。如果 OpenAI 不这样做，他们的利用率将更低，我们的成本估计将增加一倍以上。

多查询注意力

MQA 是其他公司正在使用的技术，但我们想指出 OpenAI 也在使用。长话短说，只需要一个头部，KV 缓存的内存容量可以大大减少。即使如此，32k 序列长度的 GPT-4 肯定无法在 40GB 的 A100 芯片上运行，而 8k 序列长度的 GPT-4 在最大批量大小上受到限制。如果没有 MQA，8k 序列长度的 GPT-4 的最大批量大小将受到极大的限制，以至于经济上不可行。

连续批处理

OpenAI 实现了可变的批量大小和连续批处理。这样可以在一定程度上允许最大延迟，并优化推理成本。

关于猜测解码

我们从一些可靠的人士那里听说 OpenAI 在 GPT-4 推理中使用了猜测解码。我们不确定是否完全相信这一点。token 到 token 的延迟的普遍变化以及在进行简单的检索任务与更复杂的任务时的差异似乎表明这是可能的，但是变量太多，无法确定。以防万一，我们将在这里使用一些「使用分段猜测解码加速 LLM 推理」的文本并稍作修改/添加一些说明。

使用 LLM 通常分为两个阶段。首先是预填充阶段，将提示文本通过模型生成 KV 缓存和第一个输出的 logits（可能的 token 输出概率分布）。通常，这个阶段很快，因为整个提示文本可以并行处理。

第二阶段是解码。从输出的 logits 中选择一个 token，并将其反馈到模型中，生成下一个 token 的 logits。重复这个过程，直到生成所需数量的 token。因为解码必须按顺序进行，每次都要将权重流通过计算单元以生成单个 token，所以当以小批量运行时，第二阶段的算术强度（即计算的 FLOP / 内存带宽的字节数）非常低。

因此，解码通常是自回归生成中最昂贵的部分。这就是为什么在 OpenAI 的 API 调用中，输入 token 比输出 token 便宜得多的原因。

猜测解码的基本思想是使用一个更小、更快的草稿模型预先解码多个 token，然后将它们作为一个批次馈送给神谕模型。如果草稿模型对其预测的 token 是正确的，即较大模型也同意，那么可以通过一个批次解码多个 token，这样可以节省相当多的内存带宽和时间，每个 token 都能节省。

然而，如果较大模型拒绝了草稿模型预测的 token，那么剩下的批次将被丢弃，算法自然会恢复到标准的逐 token 解码。猜测解码可能还伴随着拒绝采样方案，以从原始分布中进行采样。请注意，这仅在带宽是瓶颈的小批量设置中有用。

猜测解码通过交换计算和带宽来进行权衡。猜测解码作为性能优化目标具有两个关键原因。首先，它完全不会降低模型质量。其次，它提供的优势通常与其他方法无关，因为其性能来自将顺序执行转换为并行执行。

目前的猜测方法为批次预测一个单独的序列。然而，这在大批量大小或低草稿模型对齐度的情况下无法很好地扩展。直观地说，两个模型在连续的长序列中达成一致的概率指数级地降低，这意味着随着算术强度的扩大，猜测解码的回报迅速减少。

我们认为如果 OpenAI 使用猜测解码，他们可能只在大约 4 个 token 的序列上使用它。

关于视觉多模态

视觉多模态能力是 GPT-4 中最不令人印象深刻的部分，至少与领先的研究相比。当然，还没有任何公司将多模态 LLM 的研究商业化。

它是一个独立的视觉编码器，与文本编码器分开，但存在交叉注意力。我们听说它的架构类似于 Flamingo。这在 GPT-4 的 1.8T 参数之上增加了更多的参数。在仅文本预训练之后，它还进行了另外约 2 万亿个 token 的微调。

对于视觉模型，OpenAI 原本希望从头开始训练，但这种方法还不够成熟，因此他们决定先从文本开始以减轻风险。

据称，下一个模型 GPT-5 将从头开始进行视觉训练，并且能够自己生成图像。此外，它还将能够处理音频。

这种视觉能力的主要目的之一是让自主代理能够阅读网页并转录图像和视频中的内容。他们训练的数据中有一部分是联合数据（渲染的 LaTeX/文本）、网页的屏幕截图、YouTube 视频：采样帧，并运行 Whisper 来获取转录。

关于所有这些针对 LLM 的过度优化的有趣之处在于，视觉模型的成本与文本模型的成本不同。在文本模型中，成本非常低。而在视觉模型中，数据加载的 IO 要高出约 150 倍。每个 token 的字节数为 600，而不是文本的 4。有很多关于图像压缩的研究正在进行中。

这对于那些正在根据未来 2-3 年内 LLM 的用例和比率来优化硬件的硬件供应商来说非常重要。他们可能会发现自己处于一个每个模型都具有强大的视觉和音频能力的世界中。他们可能会发现他们的架构适应不良。总的来说，架构肯定会发展到超越当前简化的基于文本的密集和/或 MoE 模型的阶段。