> 自媒体 > (AI)人工智能 > 揭秘GPT-4:OpenAI在架构设计中所做的工程权衡|GGView
揭秘GPT-4:OpenAI在架构设计中所做的工程权衡|GGView
来源:GGV纪源资本
2023-07-15 10:57:54
370
管理

GGV有话说:

最近,网络发布了一篇GPT-4内部技术解密文档,原文:

GPT-4 Architecture, Infrastructure, Training Dataset, Costs,Vision, MoE by Dylan Patel and Gerald Wong 2023.7.11

这个文档解答了GPT-4的架构、基础设施、训练数据集、成本、视觉和MoE等详细信息。

其实,过去几个月陆续也都有一些关于GPT-4架构的猜测和爆料,今天的GGView

,就让我们一起来看看OpenAI在GPT-4架构设计中所做的工程权衡到底是怎样的。

来源 | Web3天空之城

OpenAI保持GPT-4架构的封闭性,并非因为对人类存在着某种存在风险,而是因为他们所构建的东西是可复制的。事实上,我们预计Google、Meta、Anthropic、Inflection、Character、Tencent、ByteDance、Baidu等公司在短期内都会拥有与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架构和各种现有模型的训练成本方面的高级内容。

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

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

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

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

数据集构成

OpenAI训练了GPT-4使用大约13万亿个标记。鉴于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万个标记。

训练费用

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

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

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

请注意,我们相信到今年年底将有9家公司拥有更多的H100。这些公司并不会将所有H100都用于单次训练运行,但那些使用所有H100进行训练的公司将会有更大规模的模型。Meta将在今年年底拥有超过100,000个H100,但其中相当一部分将分布在他们的数据中心进行推理。他们最大的单个集群仍将超过25,000个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个主要的权衡,涉及批处理大小(同时为多个用户提供服务的数量)和使用的芯片数量。

延迟 - 模型必须以合理的延迟响应。人们不希望在等待输出开始流动到聊天应用程序中之前等待几秒钟。预加载(输入令牌)和解码(输出令牌)需要不同的处理时间。

吞吐量- 模型必须输出每秒钟一定数量的令牌。对于人类使用,大约需要每秒钟30个令牌。较低和较高的吞吐量对于其他各种用例也可以接受。

利用率- 运行模型的硬件必须实现高利用率,否则成本太高。尽管较高的延迟和较低的吞吐量可以用于将更多的用户请求分组,并实现更高的利用率,但这使得情况变得更加困难。

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

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

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

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

猜测解码

我们从一些可靠的消息来源得知,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模型的简化形式。

温馨提示:虽然我们每天都有推送,但最近有读者表示因平台推送规则调整,有时候看不到我们的文章~

*文章观点仅供参考,不代表本机构立场。

0
点赞
赏礼
赏钱
0
收藏
免责声明:本文仅代表作者个人观点,与本站无关。其原创性以及文中陈述文字和内容未经本网证实,对本文以及其中全部或者 部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。 凡本网注明 “来源:XXX(非本站)”的作品,均转载自其它媒体,转载目的在于传递更多信息,并不代表本网赞同其观点和对 其真实性负责。 如因作品内容、版权和其它问题需要同本网联系的,请在一周内进行,以便我们及时处理。 QQ:617470285 邮箱:617470285@qq.com
关于作者
感恩的人(普通会员)
文章
351
关注
0
粉丝
0
点击领取今天的签到奖励!
签到排行

成员 网址收录40329 企业收录2981 印章生成186839 电子证书796 电子名片49 自媒体20953

@2022 All Rights Reserved 浙ICP备19035174号-7
0
0
分享
请选择要切换的马甲:

个人中心

每日签到

我的消息

内容搜索