传媒教育网

 找回密码
 实名注册

QQ登录

只需一步,快速开始

搜索
做个试验
查看: 208|回复: 0
打印 上一主题 下一主题

GPT-4内幕大泄露!1.8万亿巨量参数,13万亿token训练,斥资6300万美元

[复制链接]
跳转到指定楼层
楼主
发表于 2023-7-11 17:42:21 | 只看该作者 |只看大图 回帖奖励 |倒序浏览 |阅读模式
就在刚刚,OpenAI的GPT-4又被业内人士「开源」了!
其中包括GPT-4的架构、训练和推理的基础设施、参数量、训练数据、token数、成本、混合专家模型(Mixture of Experts,MoE)等非常具体的参数和信息。
尤其是,在不同工程背后,OpenAI究竟是怎样权衡的。以及在巨型模型推理时,如何跨越其中最大的瓶颈。
如此重磅的爆料,出自何许人也?
文章作者,是SemiAnalysis的两位名叫Dylan Patel和Gerald Wong的撰稿人。
值得一提的是,此前曾在业内引起轩然大波的谷歌内部文件泄漏事件(「我们没有护城河,OpenAI也没有」),作者之一同样是Dylan Patel。
DeepMind CEO Hassabis近日在外媒The Verge的采访中,确认了这份谷歌工程师泄漏文件的真实性。
可见,Dylan Patel的确有一些特殊渠道,这就让今日这份爆料的真实性又提高了几分。
出门问问CEO李志飞对此也发表了感言
很多企业都能做出GPT-4
在爆料文章作者看来,OpenAI之所以不open,不是为了确保人类不被AI毁灭,而是因为他们构建的东西是可复制的。
他甚至预计,未来所有中国和美国的互联网大厂或者AI头部初创企业,都会有能力构建出和GPT-4一样,甚至是超过GPT-4的模型。
但他同时也承认,GPT-4是OpenAI的伟大杰作。它凝结了工程师的匠心设计,复杂的构架和各种巧妙的工程上的取舍。
OpenAI最持久的护城河,是他们拥有真实用户的使用反馈,业内最顶尖的工程人才,以及先发优势带来的持续领先地位。
模型框架
首先爆料作者认为,GPT-4在120层中总共包含了1.8万亿参数,而GPT-3只有约1750亿个参数。
也就是说,GPT-4的规模是GPT-3的10倍以上。
此前网上流传的说法是,GPT-4的参数是1万亿,看来离实际情况还是低估了
为了保持合理的成本,OpenAI采用了MoE模型来进行构建。
具体而言,GPT-4拥有16个专家模型,每个MLP专家大约有1110亿个参数。其中,有两个专家模型被用于前向传播。
虽然文献中大量讨论了选择每个token指向哪些专家的高级算法,但是据说,OpenAI用于GPT-4的算法,其实非常简单。
此外,模型中还有大约550亿个参数,被用做注意力机制的共享。
在每次的前向传播推理(生成一个token)中,GPT-4只需要使用大约2800亿参数和560TFLOPs。
这与很多纯密集模型每次前向传播需要大约1.8万亿参数和3700TFLOPs形成了鲜明的对比。
数据集的构成
OpenAI用13万亿的token训出了GPT-4。
这个数据集不单单是包含了13万亿的token,而且因为没有高质量的token,这个数据集还包含了许多个epoch。
Scale AI和数据集内部,还包含了数百万行的指令微调数据。
不过爆料作者说,在这些RLHF数据上,他们并没有找到太多信息。
在预训练阶段的上下文长度达到了8K(seqlen),而32k的版本是基于预训练后的8K版本微调而来的。
批大小在集群中是几天之内逐渐增加的,最终OpenAI使用的批大小为6000万。
当然,这「只是」每个750万token的专家模型的大小,因为不是每个专家模型都会看到全部的token。
并行策略
并行策略对于A100GPU是相当重要的。
OpenAI采用了8路张量并行,因为NVLink最高只支持这么多。
但除此之外,爆料作者听说OpenAI采用15路并行管线。
理论上,考虑到数据通信和计算时间,15个管线就有些多了。
但是因为受到内存容量的限制,这么多的管线就是有意义的了。
当纯管线和张量并行时,每个GPU的FP16参数大约是30GB。
但是一旦加上了KV缓存和成本,如果OpenAI使用的GPU大部分是40GB的A100,那这样的构架在理论上就是有意义的。
可能OpenAI使用的是ZeRo Stage 1,并且可能使用的是块级FSDP或者是混合共享数据并行。
为什么他们没有使用FSDP的全模型呢?可能是因为过高的通信成本。
虽然OpenAI大多数节点之间都有高速网络,但是没有覆盖所有的节点。
其中,至少有一些集群的连接带宽会比其他的集群低很多。
但是作者表示,他并不是太明白OpenAI在如此高的管线并行度下,如何避免在每批中产生如下图这样的「泡泡」(huge bubbles),很有可能OpenAI就是生生地抗下了这些成本。
训练成本
OpenAI训练GPT-4的FLOPS约为2.15e25,在大约25000个A100上训练了90到100天,利用率在32%到36%之间。
这种极低的利用率,部分原因是故障数量过多,这就会导致需要重新从之前的检查点开始训练。比如上面提到的气泡成本。
这种情况浪费的训练成本极高。
另一个原因是这么多GPU之间的all-reduce非常昂贵。
此图表假设,无法融合每个操作、注意力机制所需的内存带宽、硬件开销相当于参数读取,都会导致效率低下。实际上,即使使用优化的库,比如英伟达的FasterTransformrmer库,总开销甚至还会更大
爆料作者怀疑,如果这种集群实际上是一群具有较弱网络连接的较小集群构成的,那么集群不同部分之间的非阻断(non-block)连接速度为800G/1.6T,但这些部分之间的连接速度仅为200G/400G。
如果OpenAI云计算的成本是差不多1美元/每A100小时的话,那么在这样的条件下,训练成本大约是6300万美元。
这还不包括所有的实验、失败的训练和其他成本,比如数据收集、RLHF、人力成本等。
如果考虑到刚刚说的这些因素,真实成本要高得多的多。
此外,这还得是在能别人买得到芯片/网络/数据中心,承担资本支出组建了这些系统,并将它们租给OpenAI的前提下。
但是放到今天,在2美元/每H100小时的条件下,预训练可以在大约8,192个H100上进行,只需要55天,费用为2150万美元。
上图显示了一些已公开的先进模型各自的参数数量和token。图中的线是谷歌DeepMind的Chinchilla缩放观测值(平滑了较大的误差条),线上的每一点都显示了使用该参数和token数训练模型所需的理论FLOPS
不过,爆料作者称到今年年底,至少将会有9个公司拥有超过上述大小的H100集群。
虽然并非所有这些公司都会将它们全部用于单个模型训练,但如果有公司这样做的话,他们将拥有比GPT-4更大的模型。
比如Meta到今年年底将拥有超过100,000个H100,但其中相当一部分将分布在自己的数据中心进行推理。
但是它最大的单个集群仍将超过25,000个H100。
总之,到今年年底,许多公司都会拥有足够的算力资源,来训练GPT-4大小的模型。
本表是在英伟达A100上训练模型的理论最佳成本,没有考虑所需的人力、ML Ops工具、数据收集/预处理、故障恢复、one-shot/few-shot学习示例、推理等,许多部分的成本高得惊人
混合专家模型方面的权衡
MoE(混合专家模型)是一种在推理过程中减少参数量的很好方法,虽然同时会增加参数量。
但是这对于每个训练标记来编码更多信息是必要的,因为获取足够高质量的标记非常困难。
如果OpenAI真的想追求最佳性能,他们需要训练两倍的token才能达到。
话虽如此,OpenAI还是做出了不少的取舍。
例如,在推理过程中处理MoE非常困难,因为模型的每个部分并不在每个token生成时都被使用。
这意味着有些部分可能处于休眠状态,而其他部分在工作。
当为用户提供服务时,这种情况会大大降低利用率。
研究人员已经证明,使用64-128个专家模型比使用16个专家模型能够获得更好的损失情况,但这仅仅是研究结果。
采用相对比较少的专家模型的原因很多,OpenAI选择16个专家的原因之一是因为在许多任务上更多的专家模型很难泛化。
使用更多的专家模型也更难实现收敛。
在如此庞大的训练过程中,OpenAI选择在专家模型数量上反而更为保守。
此外,使用较少的专家模型还有助于他们的推理基础架构。在切换到混合专家模型推理架构时,存在各种困难的取舍和权衡。
爆料作者从对LLM推理的基本取舍开始讨论,然后再讨论OpenAI面临的问题和他们所做的选择。
推理权衡
在介绍推理权衡之前,顺带提一下,爆料者与所有的LLM公司交谈过后,发现英伟达的FasterTransformer推理库非常糟糕,TensorRT更是如此。
这意味着,如果英伟达不修改,人们还需要从头开始创建自己的解决方案。
推理大型语言模型有三个主要的权衡,即批大小(同时处理用户数)维度和使用的芯片数量,具体如下:
1. 延迟
模型必须在合理的延迟时间内做出响应。谁也不想在聊天APP中等待几秒钟才开始收到输出。预填(输入token)和解码(输出token)的处理时间各不相同。
2. 吞吐量
模型必须以每秒输出一定数量的token。人类大约需要每秒30个token。对于其他各种用例,较低和较高的吞吐量都可以接受。
3. 利用率
运行模型的硬件必须实现高利用率,否则成本过高。虽然更高的延迟和较低的吞吐量,可以用来将更多用户请求组合在一起,从而实现更高的利用率,但也会增加难度。
LLM推理的关键是平衡内存带宽和计算这两个要点。
LLM理论带宽要求:经假设可得出,在iPhone 14上可跑的最大模型大小为~10亿个FP16参数,或~40亿个int4参数,这是基于智能手机的LLM的基本限制,任何更大的模型会无法被采用
简单来讲,每个参数都必须被读取,并且与之相关的有2个FLOP。
因此,大多数芯片的比率(H100 SXM仅有3TB/s内存带宽,但FP8有2,000 TFLOP/s)在批大小为1的推理中完全是不平衡的。
如果只有一个用户(批大小为1),那么在每次生成token时,为了读取每个参数所需的内存带宽,会主要占据推理时间,而计算时间几乎可以忽略不计。
为了将大型语言模型高效地扩展到多个用户,批处理大小必须超过1。多个用户将参数读取成本分摊。例如,在批大小为256/512时,每个字节的内存读取可以获得512 FLOP/s或1024 FLOP/s。
这个比率更接近H100的内存带宽与FLOPS之间的平衡。这有助于实现更高的利用率,但代价是更高的延迟。
很多人认为内存容量是LLM推理的一个主要瓶颈,因为大型模型需要多个芯片进行推理,而较高的内存容量意味着它们可以适应较少的芯片。
然而,实际上更好的方法是使用更多的芯片,以便将延迟降低,增加吞吐量,并且可以使用更大的批大小以实现更高的利用率。
GPT-4推理权衡和基础设施
以上所提到的,对GPT-4推理来说非常困难。但是作为一个MoE模型,再次引入了一系列全新的困难。
每个生成token的前向传递可以路由到不同的专家组。这对在较大的批大小下的吞吐量、延迟和利用率之间的权衡造成了困扰。
OpenAI的GPT-4有16个专家,每个前向传递路由到其中2个专家。
这意味着如果批大小为8,每个专家的参数读取可能只有批大小为1。
更糟糕的是,这可能意味着一个专家的批大小为8,而其他专家的批大小为4、1或0。
每个生成token,路由算法都会将前向传递发送到不同的方向,导致token之间的延迟和专家批大小显著变化。
推理基础设施是OpenAI选择较少数量的专家的主要原因之一。如果他们选择更多的专家,内存带宽会成为推理的瓶颈。
OpenAI的推理集群通常可以达到4k+的批大小,这意味着即使在专家之间实现最佳的load平衡,专家的批大小也只有大约500左右。这需要非常大量的使用才能实现。
爆料者称,我们了解到OpenAI在一个由128个GPU组成的集群上进行推理。他们在多个数据中心和地理位置上都有多个这样的集群。
推理采用8路张量并行和16路管线并行。每个由8个GPU组成的节点只有约130B的参数,或者在FP16下每个GPU不到30GB,在FP8/int8下不到15GB。
这样可以在40GB的A100上运行推理,只要所有批的KV缓存大小不会过大。
不同节点上的包含不同专家的层不会被分割,因为那样会导致网络流量过于不规则,而在每个生成token之间重新计算KV缓存的代价太高。
对于未来的MoE模型扩展和条件路由,最大的困难是如何处理KV缓存的路由。
模型的层数为120,所以可以简单地将它们分配给15个不同的节点,但是因为第一个节点需要进行数据加载和嵌入,所以在推理集群的主节点上放置较少的层是有意义的。
此外,有一些关于「推测解码」(后续)的传闻,这也解释了为什么主节点需要包含较少的层。
推理成本
与拥有1750亿参数的Davinchi模型相比,GPT-4的成本是其3倍,尽管其前馈参数只增加了1.6倍。
这主要是因为GPT-4需要更大的集群,并且实现的利用率更低。
作者认为,在128个A100上推理GPT-4的8k序列长度每1,000个标记的成本为0.0049美元,而在128个H100上推理GPT-4的8k序列长度每1,000个标记的成本为0.0021美元。
需要注意的是,这是假设有相当高的利用率,并保持较高批大小的情况下。
但很明显,OpenAI有时的利用率非常低。
对此作者假设,OpenAI会在低峰时段关闭集群,重新配置节点,恢复训练较小的测试模型,并尝试各种新技术,从而降低推理成本。
如果OpenAI不这样做,他们的利用率会更低,而成本也将增加一倍以上。
多查询注意力
除此之外,OpenAI也在使用多查询注意力(Multi-Query Attention,MQA)。
论文地址:https://arxiv.org/pdf/1911.02150.pdf
简而言之,只需要一个注意力头,并且可以显著减少KV缓存的内存占用。
即便如此,32k长度的GPT-4肯定无法在40GB的A100上运行,而8k的最大批大小也有上限。
连续批处理
OpenAI实现了可变批大小和连续批处理。
这样做可以允许一定程度的最大延迟,并优化推理成本。
推测解码(Speculative Decoding)
爆料称,OpenAI在GPT-4的推理过程中使用了「推测解码」,这其中还有100%的不确定性。
token到token的延迟变化,以及在进行简单的检索任务和更复杂的任务时差异,似乎表明这一点是可能的,不过还是有太多的变量无法确定。
在此,爆料者通过DeepMind的一项研究「Accelerating LLM Inference with Staged Speculative Decoding」中的文本,进行了适当修改/添加一些细节,进行了解释。
使用LLM通常分为两个阶段。
首先是预填充(prefill),将提示文本输入模型中以生成KV缓存和第一个输出的对数几率(可能的token输出的概率分布)。这个过程通常很快,因为整个提示文本可以并行处理。
第二个阶段是解码(decoding)。从输出的对数几率中选择一个token,并将其反馈到模型中,模型将生成下一个token的对数几率。重复这个过程,直到生成所需数量的token。
由于解码必须按顺序进行,每次都需要将权重流通过计算单元以生成单个token。因此当以小量批运行时,这个第二阶段的计算密集度(即计算FLOP/内存带宽的字节数)非常低。因此,解码通常是自回归生成中最昂贵的部分。
这就是为什么OpenAI的API调用中,输入token比输出token便宜得多的原因。
「推测解码」的基本思想是使用一个更小、更快的草案模型提前解码多个token,然后将它们作为一个批输入到预测模型中。
如果草案模型的预测是正确的,即更大的模型也同意这些预测,那么可以使用单个批解码多个token,这样可以节省大量的内存带宽和时间。
然而,如果更大的模型拒绝了草案模型预测的token,则剩余的批将被丢弃,算法自然会恢复到标准的逐个token解码。
「推测解码」可能还伴随着拒绝抽样的方案,以从原始分布中进行采样。值得注意的是,这仅在带宽是瓶颈的小批设置中有用。
「推测解码」以计算换取带宽,而成为一个有吸引力的性能工程目标有两个关键原因:
首先,它不会降低模型质量。其次,它提供的性能改进通常与其他方法正交,因为其性能来自于将「顺序执行」转换为「并行执行」。
当前的推测方法为批预测的单独序列。然而,这种方法不能很好地拓展到大量的批,或低草案模型对齐上。
直观地说,两个模型在连续长序列的token上达成一致的概率呈指数级低,这意味着随着算术密度的增加,推测解码的收益会迅速减少。
爆料者认为,如果OpenAI使用「推测解码」,他们可能只在大约4个token的序列中使用。
顺便提一句,有关OpenAI阉割,而导致GPT-4质量降低的整个阴谋,可能只是因为他们让预测模型接受了「推测解码」模型的低概率序列。
另外有人推测,Bard也使用了「推测解码」,因为谷歌在将整个序列发送给用户之前会等待其完全生成,但在爆料者认为,这种猜测是完全不正确的。
视觉多模态
视觉多模态能力是GPT-4中最不令人印象深刻的部分,至少与领先的研究相比是如此。
当然,现在还没有人将多模态LLM的研究成果商业化。
爆料者称,它是一个独于文本编码器的视觉编码器,还有交叉注意力,架构类似于Flamingo,并在GPT-4 1.8T上增加了更多参数。
GPT-4多模态能力是在文本预训练之后,又用大约2万亿token进⾏了微调。
据称,在视觉模型上,OpenAI原本希望从头开始训练,但因其不够成熟,无奈从文本训练模型进行微调。
而下一代模型GPT-5,其训练应该从零开始训练视觉模型,并且能够生成图像,甚至生成音频。
这样的视觉能力主要目的之一,让自主智能体能够阅读网页,并转录图像,视频中的内容。
值得一提的是,OpenAI用来训练多模态模型的数据包括:「联合数据」(LaTeX/文本)、网页屏幕截图、YouTube视频(采样帧,以及运行Whisper获取字幕)。
关于LLM的过度优化,一个有趣的事实是视觉模型的IO成本不同于文本模型。在视觉模型中,数据加载IO大约是文本模型的150倍。
视觉模型的IO成本很低
视觉模型中的每个token 600字节,文本是4字节/token。
因此这需要在图像压缩方面做很多工作。这对于硬件供应商来说极为重要,因为他们正在围绕LLM的用例和比率优化2-3年后的硬件。
他们可能会发现自己身处的世界中,每个模型都具有强大的视觉和音频功能。
他们可能会发现自己的架构适应性会很差。
总的来说,架构肯定会超越我们今天看到的基于文本简化的密集模型,和MoE模型。
参考资料:https://www.semianalysis.com/p/gpt-4-architecture-infrastructure
来源:新智元(公众号)
链接:https://mp.weixin.qq.com/s/iqvdcnwl4pR4jDXn57Yg8Q
编辑:程博

开源11.png (238.15 KB, 下载次数: 54)

开源11.png
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 支持支持 反对反对

发表回复

您需要登录后才可以回帖 登录 | 实名注册

本版积分规则

掌上论坛|小黑屋|传媒教育网 ( 蜀ICP备16019560号-1

Copyright 2013 小马版权所有 All Rights Reserved.

Powered by Discuz! X3.2

© 2016-2022 Comsenz Inc.

快速回复 返回顶部 返回列表