在GPT-4发布后，整个OpenAI团队对GPT-4的几乎所有信息都守口如瓶。
不过就在最近，OpenAI的GPT-4被业内人士“开源”了。SemiAnalysis的两位名叫Dylan Patel和Gerald Wong的撰稿人，发表了一篇题为《GPT-4 Architecture, Infrastructure, Training Dataset, Costs, Vision, MoE》的文章，曝光了GPT-4从模型架构、模型训练到成本的所有细节。
文章中详细介绍了GPT-4的架构、训练和推理的基础设施、参数量、训练数据集、token数、成本、混合专家模型（Mixture of Experts，MoE）等非常具体的参数和信息。
在爆料文章作者看来，OpenAI之所以不open，不是为了确保人类不被AI毁灭，而是因为他们构建的东西是可复制的。
他甚至预计，未来所有中国和美国的互联网大厂或者AI头部初创企业，都会有能力构建出和GPT-4一样，甚至是超过GPT-4的模型。以下，Enjoy:
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的参数是100万亿，但已被辟谣
为了保持合理的成本，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模型。
本文为专栏作者授权创业邦发表，版权归原作者所有。文章系作者个人观点，不代表创业邦立场，转载请联系原作者。如有任何疑问，请联系editor@cyzone.cn。
