当前位置:首页|资讯|GPT-4

GPT-4 内幕泄露:比 GPT-3 大了不止 10 倍,训练成本不亚于太空竞赛|万字长文

作者:AppSo发布时间:2023-07-12

原标题:GPT-4 内幕泄露:比 GPT-3 大了不止 10 倍,训练成本不亚于太空竞赛|万字长文

今天半导体分析机构 SemiAnalysis 发布了一篇 GPT-4 内部技术解密文档:GPT-4 Architecture,Infrastructure,Training Dataset, Costs,Vision, MoE 。

该文档披露了GPT-4 的架构、基础设施、训练数据集、成本、视觉 和 MoE 等关键信息。

过去几个月都陆续有一些关于 GPT-4 架构的猜测和爆料,这篇则是最为详细的解密,该文作者表示:「最有趣的地方是理解 OpenAI 为什么做出某些架构决策。」

出品:Web3天空之城 x APPSO,把全球顶级的 AI 认知内容带到中文世界。

划重点:

1.OpenAI 保持 GPT-4 架构的封闭性,并非因为对人类存在着某种存在风险,而是因为他们所构建的东西是可复制的。

2.Google、Meta、Anthropic、Inflection、Character、腾讯、字节跳动、百度等公司在短期内都会拥有与 GPT-4 同样甚至更强大的模型。

3. GPT-4 的规模是 GPT-3 的 10 倍以上。我们认为它在 120 个层中拥有大约 1.8万 亿个参数,而 GPT-3 只有大约 1750 亿个参数。

4.OpenAI 在其模型中使用了 16 个使用混合专家(MoE)模型,每个专家的 MLP 参数约为 1110 亿个。

5.据说 OpenAI 的算法相当简单,适用于当前的 GPT-4 模型。此外,大约有 550 亿个共享参数用于注意力机制。

6.每次前向传递的推理(生成 1 个标记)仅利用了约 2800 亿个参数和 560 TFLOP 的计算。这与纯密集模型每次前向传递所需的约 1.8 万亿个参数和 3700 TFLOP 形成了对比。

7.OpenAI 训练了 GPT-4 使用大约 13 万亿个标记(token)。

8.预训练阶段的上下文长度(seqlen)为 8k。GPT-4 的 32k seqlen 版本是在预训练后对 8k 进行微调得到的。

9.将所有的 A100 GPU 并行化的策略非常重要。他们采用了8 路张量并行,因为这是 NVLink 的限制。

10.尽管 GPT-4 的前向参数仅为 1750 亿的 Davinchi 模型的 1.6 倍,但其成本是 Davinchi 模型的 3 倍。这主要是由于 GPT-4 需要更大的集群和较低的利用率所致。

💡 以下是全文编译,enjoy:

OpenAI 保持 GPT-4 架构的封闭性,并非因为对人类存在着某种存在风险,而是因为他们所构建的东西是可复制的。事实上,我们预计 Google、Meta、Anthropic、Inflection、Character、腾讯、字节跳动、百度等公司在短期内都会拥有与 GPT-4 同样甚至更强大的模型。

不要误会,OpenAI 具有令人惊叹的工程能力,他们所构建的东西令人难以置信,但他们达到的解决方案并非魔法。这是一个优雅的解决方案,涉及许多复杂的权衡。扩大规模只是战斗的一部分。OpenAI 最持久的优势在于他们在实际应用中具有最多的使用情况、领先的工程人才,并且可以继续在未来的模型中超越其他公司。

我们从许多来源收集了关于 GPT-4 的大量信息,今天我们想要分享。其中包括模型架构、训练基础设施、推理基础设施、参数数量、训练数据集的组成、标记数量、层数量、并行策略、多模态视觉适应、不同工程权衡背后的思考过程、实现的独特技术,以及他们如何减轻与庞大模型推理相关的一些最大瓶颈。

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

此外,我们将概述在 A100 上训练和推理 GPT-4 的成本,并说明它在下一代模型架构中如何与 H100 进行扩展。

首先,让我们来谈谈问题陈述。从 GPT-3 到GPT-4,OpenAI 希望将规模扩大 100 倍,但成本是一个困扰的问题。密集的 Transformer 模型将无法进一步扩展。密集 Transformer 是 OpenAI GPT-3、Google PaLM、Meta LLAMA、TII Falcon、MosaicML MPT 等所使用的模型架构。我们可以轻松列举出 50 家公司正在使用相同的架构进行 LLM(Large Language Models)训练。这是一个不错的架构,但对于扩展来说存在问题。

请参阅我们在 GPT-4 发布之前关于密集模型训练成本的讨论,涉及即将出现的 AI 瓶颈问题。在那里,我们透露了 OpenAI 在 GPT-4 架构和各种现有模型的训练成本方面的高级内容。

在过去的 6 个月里,我们意识到训练成本是无关紧要的。

当然,表面上看起来疯狂,需要花费数千万甚至数亿美元的计算时间来训练一个模型,但对于这些公司来说,这种支出微不足道。这实际上是一个固定资本支出项目,通过扩大规模可以持续获得更好的结果。唯一的限制因素是将计算资源扩展到人类能够获得反馈并修改架构的时间尺度上。

在未来几年里,包括 Google、Meta 和 OpenAI/Microsoft 在内的多家公司将在价值超过 1000 亿美元的超级计算机上训练模型。Meta 每年在「元宇宙」上烧掉 160 亿美元,Google 每年浪费 100 亿美元用于各种无法实现的项目。亚马逊在 Alexa 上已经亏损了超过 500 亿美元。加密货币在没有价值的东西上浪费了1000 亿美元。

这些公司和整个社会可以并且将会花费超过 1000 亿美元来创建能够训练单个大规模模型的超级计算机。然后,这些大规模模型可以以各种方式产品化。这个努力将在多个国家和公司中复制。这是一场新的太空竞赛。与以前的浪费不同的是,现在的AI具有明显的价值,短期内将从人类助理和自主代理中获得实际价值。

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

真正的挑战是将这些模型扩展到用户和代理上的成本过高。推理的成本比训练的成本高出多倍。这就是 OpenAI 在模型架构和基础设施方面的创新目标。

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

在数据中心和云计算中,利用率是至关重要的。Nvidia 之所以因软件卓越而受到赞扬,部分原因是因为在 GPU 的一代代生命周期中,Nvidia 不断更新低级软件,通过更智能地在芯片、芯片之间以及内存之间传输数据,提高了 FLOPS 的利用率。

在当前大多数应用场景中,LLM 推理的目标是作为实时助手,这意味着它必须实现足够高的吞吐量,以使用户能够真正使用它。人类平均阅读速度约为每分钟 250 个单词,但有些人的阅读速度高达每分钟 1000 个单词。这意味着你需要每秒输出至少 8.33 个标记,但更接近每秒输出 33.33 个标记以涵盖所有情况。

根据数学计算,一个拥有万亿参数的密集模型在最新的 Nvidia H100 GPU 服务器上也无法实现这样的吞吐量,因为它需要更大的内存带宽。每生成一个标记,都需要将每个参数从内存加载到芯片中。然后将生成的标记输入到提示信息中,生成下一个标记。此外,用于注意机制的 KV 缓存也需要额外的带宽进行流式传输。

该图表假定无法融合每个操作带来的低效率,注意力机制所需的内存带宽以及硬件开销等同于参数读取。实际上,即使使用 Nvidia 的 FasterTransformer 等「优化」库,总开销会更大

上面的图表显示了推理一个 LLM 所需的内存带宽,以实现足够高的吞吐量以为个体用户提供服务。

图表显示,即使使用 8 个 H100 GPU,也无法以每秒 33.33 个标记的速度为拥有万亿参数的密集模型提供服务。此外,8 个 H100 GPU 在每秒 20 个标记的情况下的 FLOPS 利用率仍然不到 5%,导致推理成本非常高。因此,目前对于 8 路张量并行的 H100 系统,存在着约 3000 亿前馈参数的推理约束。

然而,OpenAI 使用 A100 GPU 实现了人类的阅读速度,并且使用超过万亿参数的模型,以每 1000 个标记仅需 0.06 美元的低价格广泛提供服务。这是因为模型是稀疏的,即并非每个参数都被使用。

让我们来讨论一下 GPT-4 模型架构、训练基础设施、推理基础设施、参数数量、训练数据集组成、标记数量、层次数量、并行策略、多模态视觉编码器、不同工程权衡背后的思考过程、独特的实施技术,以及他们如何减轻与大规模模型推理相关的一些最大瓶颈。

模型架构

GPT-4 的规模是 GPT-3 的 10 倍以上。我们认为它在 120 个层中拥有大约 1.8万 亿个参数,而 GPT-3 只有大约 1750 亿个参数。

OpenAI 通过使用混合专家(MoE)模型来保持成本合理。如果您对 MoE 不熟悉,请阅读我们六个月前关于广义 GPT- 4 架构和训练成本的帖子。

此外,OpenAI 在其模型中使用了 16 个专家,每个专家的 MLP 参数约为 1110 亿个。每次前向传递有 2 个专家进行路由。

虽然文献中对于选择将每个标记路由到哪些专家的先进路由算法进行了很多讨论,但据说 OpenAI 的算法相当简单,适用于当前的 GPT-4 模型。

此外,大约有 550 亿个共享参数用于注意力机制。

每次前向传递的推理(生成 1 个标记)仅利用了约 2800 亿个参数和 560 TFLOP 的计算。这与纯密集模型每次前向传递所需的约 1.8 万亿个参数和 3700 TFLOP 形成了对比。

数据集构成

OpenAI 训练了 GPT-4 使用大约 13 万亿个标记(token)。鉴于 CommonCrawl中包含约 5 万亿个高质量标记的RefinedWeb数据,这是有道理的。作为参考,Deepmind的Chinchilla 模型和 Google的PaLM 模型分别使用了约 1.4 万亿个标记和约 7800 亿个标记进行训练。据称,即使 PaLM 2 也是基于约 5 万亿个标记进行训练。

这个数据集不包含 13 万亿个独特的标记。相反,由于缺乏高质量的标记,该数据集包含多个时期。对于基于文本的数据有 2 个时期,对于基于代码的数据有 4 个时期。有趣的是,这远远不及 Chinchilla 的最优解,表明需要对模型进行双倍数量的标记训练。这表明在网络上获取易得的标记的数量有限。高质量的文本标记有 1000 倍之多,而音频和视频则更多,但获取它们并不像网页抓取那么简单。

还有来自 ScaleAI 和内部的数百万行指令微调数据。不幸的是,我们在RLHF数据方面找不到太多信息。预训练阶段的上下文长度(seqlen)为 8k。GPT-4 的 32k seqlen 版本是在预训练后对 8k 进行微调得到的。

在集群上,批次大小逐渐在几天内逐步增加,但到最后,OpenAI 使用的批次大小为 6000 万!当然,由于并非每个专家都能看到所有标记,这「仅仅」是每个专家的批次大小为 750 万个标记。

并行策略

将所有的 A100 GPU 并行化的策略非常重要。他们采用了8 路张量并行,因为这是 NVLink 的限制。此外,我们听说他们还使用了 15 路流水线并行。从理论上讲,在考虑数据通信和计算时间时,这太多的流水线了,但如果他们受限于内存容量,那么这是有道理的。

仅仅通过流水线+张量并行,每个GPU的参数在FP16下就占用了约 30GB。一旦加上 KV 缓存和开销,从理论上讲,如果 OpenAI 的大部分 GPU 都是 40GB 的 A100,那么这是有道理的。他们可能使用了 ZeRo 阶段 1 。他们可能还使用了块级 FSDP 或混合共享数据并行。

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

我们不明白他们是如何在如此高的流水线并行度下避免每个批次产生巨大的延迟。很可能他们只是吸收了这个成本。

训练费用

OpenAI 用于 GPT-4 的训练 FLOPS 约为 2.15e25,使用了约 25000 个 A100 GPU 进行了 90 到 100 天的训练,利用率约为 32% 至 36%。极低的利用率部分是由于大量的故障导致需要重新启动检查点。

上述提到的延迟代价极高。另一个原因是在这么多 GPU 之间进行全局归约的代价极高。如果我们的猜测是正确的,那么集群实际上是许多较小集群的组合,在它们之间的网络连接非常薄弱,即在集群的各个部分之间的非阻塞连接速度为 800G/1.6T,但这些部分之间的连接速度只有 200G/400G。如果他们在云中的成本为每个 A100 的小时费用约为 1美元,仅此次训练的成本将约为 6300 万美元。这还不包括所有的实验、训练失败的运行和其他成本,如数据收集、RLHF、统计等。由于这些因素,实际成本要高得多。

此外,这意味着您需要有人购买芯片/网络/数据中心,承担资本支出,并将其租给您使用。今天,使用约 8192个H100 在大约 55 天内进行预训练的成本约为 2150 万美元,每个 H100 的小时费用为 2 美元。

请注意,我们相信到今年年底将有 9 家公司拥有更多的 H100。这些公司并不会将所有 H100 都用于单次训练运行,但那些使用所有 H100 进行训练的公司将会有更大规模的模型。Meta 将在今年年底拥有超过 100000 个H100,但其中相当一部分将分布在他们的数据中心进行推理。他们最大的单个集群仍将超过 25000 个 H100。到今年年底,许多公司将拥有足够的计算资源来训练一个与 GPT-4 规模相当的模型。

混合专家模式的权衡

MoE 是一种在推理过程中减少参数数量的绝佳方法,同时仍然增加参数数量,这对于每个训练标记来说是必需的,因为需要编码更多的信息。这是必要的,因为获取足够高质量的标记非常困难。如果 OpenAI 真的试图达到 Chinchilla的最佳状态,他们将不得不在训练标记上训练 2 倍的数量。

话虽如此,OpenAI 做出了多个权衡。例如,MoE 在推理过程中非常难处理,因为模型的每个部分并不在每个标记生成时都被利用。这意味着在使用其他部分时,某些部分可能处于休眠状态。对于为用户提供服务,这真的会对利用率造成很大的影响。

研究人员已经证明使用 64 到 128 个专家比使用 16 个专家的损失更好,但这仅仅是研究结果。选择较少的专家有多个原因。OpenAI 选择 16 个专家的一个原因是更多的专家在许多任务上难以进行泛化。更多的专家也可能更难实现收敛。在如此大规模的训练中,OpenAI 选择在专家数量上更为保守。

此外,使用较少的专家还有助于他们的推理基础设施。在转向专家混合推理架构时,存在许多困难的权衡。让我们从 LLMs 的推理基本权衡开始,然后再转向OpenAI面临的困境和他们所做的选择。

推理的权衡

在开始之前,我们想指出,我们与所有的 LLM公 司交流后发现,Nvidia 的 FasterTransformer 推理库非常糟糕,TensorRT 更糟糕。无法使用Nvidia的模板并进行修改意味着人们需要从零开始创建自己的解决方案。如果你是 Nvidia的工作人员,你需要尽快改进 LLM 推理的这个问题,否则事实上将成为一个开放的工具,可以更容易地添加第三方硬件支持。大规模模型的浪潮正在来临。如果在推理中没有软件优势,并且仍然需要手动编写内核,那么 AMD 的 MI300 和其他硬件将有更大的市场。

对于大型语言模型的推理,存在 3 个主要的权衡,涉及批处理大小(同时为多个用户提供服务的数量)和使用的芯片数量。

  1. 延迟 - 模型必须以合理的延迟响应。人们不希望在等待输出开始流动到聊天应用程序中之前等待几秒钟。预加载(输入令牌)和解码(输出令牌)需要不同的处理时间。
  2. 吞吐量 - 模型必须输出每秒钟一定数量的令牌。对于人类使用,大约需要每秒钟30个令牌。较低和较高的吞吐量对于其他各种用例也可以接受。
  3. 利用率 - 运行模型的硬件必须实现高利用率,否则成本太高。尽管较高的延迟和较低的吞吐量可以用于将更多的用户请求分组,并实现更高的利用率,但这使得情况变得更加困难。

LLM 推理的关键是平衡两个主要因素,即内存带宽和计算。简单来说,每个参数都必须读取,并且与之相关联的有 2 个 FLOP。因此,大多数芯片的比例(H100 SXM 仅具有 3TB/s 的内存带宽,但具有 2000 TFLOP/s 的 FP8)在批处理大小为 1 的推理中完全不平衡。如果只为一个用户提供服务,批处理大小为 1,那么为每个令牌生成流式传输所需的内存带宽将占据推理时间的主导地位,而计算时间几乎可以忽略不计。

要将大型语言模型有效地扩展到多个用户,批处理大小必须大于 1。多个用户分摊参数读取成本。例如,在批处理大小为 256 或 512 时,每个内存字节的读取对应 512 FLOP/s 或 1024 FLOP/s。这个比例更接近 H100 的内存带宽与 FLOPS 之间的比例。这有助于实现更高的利用率,但代价是更高的延迟。

许多人认为 LLM 推理的一个主要瓶颈是内存容量,因为模型的大小限制了它可以适应的芯片数量,但这是不正确的。虽然大型模型需要多个芯片进行推理,较高的内存容量使其适应的芯片数量减少,但最好使用比所需容量更多的芯片,以便将延迟降低,增加吞吐量,并使用更大的批处理大小以实现越来越高的利用率。

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

如果一个应用程序需要最低的延迟,我们需要应用更多的芯片,并以尽可能多的方式对模型进行分区。较低的延迟通常可以通过较小的批处理大小实现,但较小的批处理大小也会导致更差的 MFU(利用率),从而导致每个令牌的总成本(以芯片秒或美元计)更高。

如果一个应用程序需要离线推理,而延迟不是一个问题,主要目标是最大化每个芯片的吞吐量(即最小化每个令牌的总成本)。增加批处理大小是最高效的,因为较大的批处理通常会导致更好的 MFU(利用率),但某些在小批处理大小下不高效的分区策略在批处理大小增大时变得高效。

更多的芯片和更大的批处理大小是最便宜的,因为它们提高了利用率,但同时也引入了第三个变量,即网络时间。将模型分配到多个芯片上的某些方法对于延迟来说更加高效,但与利用率有一定的权衡。

内存加载部分的时间和非 attention 计算时间与模型大小成正比,与芯片数量成反比。然而,对于给定的分区布局,芯片间通信所需的时间随着使用的芯片数量减少得更慢(或根本不减少),因此随着芯片数量的增加,这成为一个越来越重要的瓶颈。

虽然今天我们只是简要讨论一下,但应该注意的是,随着批处理大小和序列长度的增长,KV缓存的内存需求会急剧增加。

如果一个应用程序需要生成具有长注意力上下文的文本,那么推理时间将大大增加。对于具有多头注意力的 500B+ 模型,注意力KV缓存会变得很大:对于批处理大小为 512 和上下文长度为 2048,KV缓存总共需要 3TB 的容量,这是模型参数大小的 3 倍。芯片上的内存需要从芯片外的内存中加载这个KV缓存,而在此期间,芯片的计算核心基本上处于空闲状态。

较长的序列长度对内存带宽和内存容量尤其具有挑战性。OpenAI 的 16k 序列长度的 GPT 3.5 Turbo 和 32k 序列长度的 GPT 4 要昂贵得多,因为它们由于内存限制无法利用更大的批处理大小。较小的批处理大小导致较低的硬件利用率。此外,随着序列长度的增加,KV 缓存也会增大。KV缓存无法在用户之间共享,因此需要进行单独的内存读取,进一步限制了内存带宽。稍后会详细介绍 MQA 的更多内容。

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

以上所有内容对于 GPT-4 的推理来说都很困难,因为作为 Mixture of Experts(MoE)的模型架构引入了一整套新的困难。每个标记生成的前向传递可以路由到不同的专家集合。这在吞吐量、延迟和利用率的权衡方面引入了一种新的困境,尤其是在较大的批次大小下。

OpenAI 的 GPT-4 拥有 16 个专家,每个前向传递路由到其中的 2 个专家。这意味着如果批次大小为 8,每个专家的参数读取可能只有批次大小为 1。更糟糕的是,这可能意味着一个专家的批次大小为8,而其他专家的批次大小可能为 4、1 或 0。每个标记生成,路由算法都会将前向传递发送到不同的方向,导致标记之间的延迟以及专家批次大小出现显著的变化。

推理基础设施是 OpenAI 选择采用较少专家的主要原因之一。如果他们选择更多的专家,内存带宽将更加成为推理的瓶颈。OpenAI 的推理集群通常达到 4k+ 的批次大小,这意味着即使在专家之间进行最佳负载均衡,专家们的批次大小也只有约500。这需要非常大量的使用才能实现。

我们了解到 OpenAI 在一个由 128 个 GPU 组成的集群上运行推理。他们在多个数据中心和地理位置拥有多个这样的集群。推理采用 8 路张量并行和 16 路管道并行。每个由8个GPU组成的节点仅拥有约 130B 的参数,或者在FP16模式下每个 GPU 不到 30GB,在 FP8/int8 模式下不到 15GB。这使得推理可以在 40GB 的 A100 上运行,前提是所有批次中的 KV 缓存大小不会膨胀得太大。

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

模型的层数为 120,因此在 15 个不同的节点之间进行简单的分配,但由于第一个节点需要进行数据加载和嵌入,所以在推理集群的头节点上放置较少的层是有道理的。此外,有一些关于推测解码的传闻,我们稍后会讨论,但我们不确定是否相信这些传闻。这也可以解释为什么头节点需要包含较少的层。

GPT-4 推理成本

尽管 GPT-4 的前向参数仅为 1750 亿的 Davinchi 模型的 1.6 倍,但其成本是 Davinchi 模型的 3 倍。这主要是由于 GPT-4 需要更大的集群和较低的利用率所致。

我们认为,在 128 个 A100 进行 GPT-4 8k 序列长度的推理过程中,每 1000 个标记的成本为 0.0049 美元,而在 128 个H100 进行 GPT-4 8k 序列长度的推理过程中,每 1000 个标记的成本为 0.0021 美元。需要注意的是,我们假设有良好的高利用率,并且保持批次大小较大。

这可能是一个错误的假设,因为很明显OpenAI有时利用率非常低。我们假设 OpenAI 会在低峰时段关闭集群,并重新利用这些节点来从检查点中恢复训练,用于较小的测试模型,尝试各种新技术。这有助于降低推理成本。如果 OpenAI 不这样做,他们的利用率将更低,我们的成本估计将翻倍以上。

多查询注意力

MQA 是其他所有人都在做的事情,但我们想指出 OpenAI 也在做。简而言之,只需要一个头部,而且可以显著减少KV缓存的内存容量。即便如此,32k 长度的 GPT-4 绝对无法在 40GB 的 A100 上运行,而 8k 的批次大小也受到限制。如果没有MQA,8k长度的模型将在批次大小上受到显著限制,甚至到了不经济的程度。

连续批处理

OpenAI 实现了可变批处理大小和连续批处理。这样做是为了在最大延迟和优化推理成本之间达到一定的平衡。如果您对这个概念不熟悉,可以阅读 AnyScale 的这个内容:

使用静态批处理完成四个序列。在第一次迭代(左边),每个序列从提示令牌(黄色)生成一个令牌(蓝色)。经过几次迭代(右边),完成的序列因为在不同的迭代中发出了它们的序列结束令牌(红色),所以它们的大小各不相同。尽管序列 3 在两次迭代后完成,但静态批处理意味着 GPU 在批处理中的最后一个序列完成之前处于未充分利用的状态(在这个例子中是序列 2 在六次迭代后完成)。

使用连续批处理完成七个序列。左侧显示了单次迭代后的批次,右侧显示了经过多次迭代后的批次。一旦一个序列发出一个序列结束令牌,我们会插入一个新的序列来取代它,例如序列 S5、S6 和 S7。这样可以实现更高的 GPU 利用率,因为 GPU 不需要等待所有序列完成后才开始新的序列。

猜测解码

我们从一些可靠的消息来源得知,OpenAI 在 GPT-4 的推理过程中使用了猜测解码(speculative decoding)。我们不确定是否应该相信这个说法。从令牌到令牌的推理时间的一般变化以及在执行简单的检索任务与执行更复杂任务时的差异似乎表明这是可能的,但是有太多的变量无法确定。为了确保,我们将在此处使用「加速LLM推理的分阶段猜测解码」一文中的一些文本,并进行适当的修改和补充。

使用 LLM 通常分为两个阶段。首先是预填充(prefill)阶段,将提示语通过模型运行以生成 KV 缓存和第一个输出的对数几率(可能的令牌输出的概率分布)。这通常很快,因为整个提示语可以并行处理。

第二个阶段是解码。从输出的对数几率中选择一个令牌,并将其反馈到模型中,模型会为下一个令牌生成对数几率。这个过程会重复进行,直到生成所需数量的令牌。由于解码必须按顺序进行,每次计算单元都需要流式传输权重以生成单个令牌,因此这个阶段的算术强度(即计算的浮点运算数/内存带宽字节)在小批次中非常低。因此,解码通常是自回归生成中最耗费资源的部分。这就是为什么在 OpenAI 的 API 调用中,输入令牌比输出令牌更便宜的原因。

猜测解码的基本思想是使用一个较小、更快的草稿模型预先解码多个令牌,然后将它们作为一个批次输入到正式模型中。如果草稿模型的预测是正确的,即与较大的模型达成一致,那么可以使用单个批次解码多个令牌,这样可以节省大量的内存带宽和时间。

然而,如果较大的模型拒绝了草稿模型预测的令牌,那么剩余的批次将被丢弃,算法会自然地恢复到标准的逐令牌解码方式。猜测解码可能还会伴随着拒绝抽样方案,用于从原始分布中进行抽样。请注意,这仅在带宽成为瓶颈的小批次设置中才有用。

猜测解码通过牺牲计算资源来换取带宽。有两个关键原因使得猜测解码成为一个有吸引力的性能优化目标。首先,它不会降低模型质量。其次,它所提供的优势通常与其他方法无关,因为它的性能来自于将顺序执行转换为并行执行。

目前的猜测方法是为批次预测一个单独的序列。然而,这种方法在大批次规模或草稿模型对齐度较低时无法很好地扩展。直观地说,两个模型在长连续的令牌序列上达成一致的概率是指数级低的,这意味着随着算术强度的增加,猜测解码的收益会迅速减少。

我们认为如果 OpenAI 在使用猜测解码,他们可能只会在长度约为 4 个令牌的序列中使用。另外,有人猜测 GPT-4 降低质量的整个阴谋可能是因为他们允许正式模型接受猜测解码模型中概率较低的序列。另外有人猜测 bard 使用猜测解码,因为谷歌在向用户发送完整序列之前会等待序列全部生成,但我们不相信这种猜测是正确的。

视觉多模态

GPT-4 的视觉多模态能力相对于领先的研究来说是最不引人注目的部分。当然,目前还没有任何人将多模态 LLM 的研究商业化。

GPT-4 的视觉编码器与文本编码器是分开的,但存在交叉注意力。据我们所知,该架构类似于 Flamingo。这使得 GPT-4 的参数数量增加了。在文本预训练之后,通过另外约 2 万亿个标记进行微调。

对于视觉模型,OpenAI 原本想从头开始训练,但该模型还不成熟,因此他们决定通过从文本开始进行降低风险。

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

视觉能力的一个主要目的是使自主代理能够阅读网页并转录图像和视频中的内容。他们训练的数据包括联合数据(渲染的LaTeX/文本),网页的屏幕截图,YouTube 视频:采样帧,并使用 Whisper 进行转录。

有趣的是,对于所有这些对 LLM 过度优化的内容来说,视觉模型的 IO 成本与文本模型不同。在文本模型中,数据加载非常便宜,就像我们在关于亚马逊云危机的文章中所描述的那样。而在视觉模型中,数据加载的 IO 成本高出约 150 倍。每个标记的数据加载约为 600 字节,而不是文本的 4 字节。目前在图像压缩方面有很多工作正在进行。

这对于正在针对 2 到 3 年后 LLM 的用例和比例进行硬件优化的硬件供应商来说非常重要。他们可能会发现自己处于一个每个模型都具备强大的视觉和音频功能的世界。他们可能会发现他们的架构不太适应这种情况。总的来说,架构肯定会进一步发展,超越当前我们所看到的基于文本的稠密模型和/或 MoE 模型的简化形式。

原文链接🔗

https://www.semianalysis.com/p/gpt-4-architecture-infrastructure

点击「在看

是对我们最大的鼓励


Copyright © 2024 aigcdaily.cn  北京智识时代科技有限公司  版权所有  京ICP备2023006237号-1