本文是对《GPT-4 Architecture,Infrastructure,Training Dataset, Costs, Vision, MoE 》的中文翻译。介绍了GPT-4使用的相关技术，希望对大家有一些帮助。群友分享了总结内容如下：
- 13T tokens预训练语料 （llama和palm是1.4T）
- MoE， 16个110B大的模型 （更多的experts理论上效果更好但工程难度更高(内存带宽要求高)，更难收敛）采用MoE是对推理成本的节省上的考量
- batchsize逐步提高， 最终达到60M bs/16experts
- 25,000个40G的A100训练了90+天 （6300万美元/ 用H100可节约至2150万美元）大概率采用了FB16和int8模式使其能在40G机器上训练
- 预训练context window为8k，经过微调拓展到32k
- MQA(多查询注意力，一个头部)减少KV的内存容量（尤其是在对较长序列时有明显作用）
- 连续批处理提高GPU利用率
- 采用speculative decoding加速推理
- GPT4的视觉编码器和文本编码器是分开的，在文本预训练完成后通过2T token再微调，采用类Flamingo的方式联合视觉模型和文本模型，未对其从头训练。（和开源社区的MLLM思路基本一致）
- 还有很多关于通讯效率、并行策略、吞吐量上的讨论，感觉搞预训练的时候可以进一步参考下。
目录
0. 引言
1. 模型结构
2. 数据组成
3. 并行策略
4. 训练费用
5.专家权衡
6.推理权衡
7. GPT-4 推理权衡和基础设施
8. GPT-4推理成本
9. Multi-Query Attention
10. Continuous batching
11. 推测性解码
12. 视觉多模态
0. 引言
OpenAI对GPT-4架构保密的原因并不是人类面临着某种生存风险，而是由于他们的工作是可复制的。我们预计Google、Meta、Anthropic、Inflection、Character、腾讯、字节跳动、百度等公司不久将会拥有同GPT-4一样甚至更强的能力。
OpenAI拥有令人惊叹的工程技术，取得了令人难以置信的成果，但他们的解决方案并不神奇。它是一个优雅的解决方案，其中有很多复杂的权衡。模型越来越大只是竞争的一部分。OpenAI最持久的护城河就是他们拥有最多的实际应用、领先的工程人才，并且能够在未来的模型中继续领先于其他公司。
我们从多个渠道收集了大量关于GPT-4的信息，今天我们希望与大家分享。其中包括模型架构、训练基础架构、推理基础架构、参数数量、训练数据集组成、token数量、层数、并行策略、多模态视觉适配、不同权衡背后的思考过程、独特的实现技术，以及他们如何缓解与巨型模型推理相关的一些最大瓶颈。
GPT-4最有趣的地方在于理解他们为什么做出某些架构决定。
此外，我们还将概述A100上GPT-4的训练和推理成本，以及在下一代模型架构中如何扩展到H100。
首先对问题进行陈述。从GPT-3到GPT-4，OpenAI希望模型尺寸扩大100倍，但问题在于成本。密集的transformer模型无法进一步扩展。OpenAI 的GPT-3、Google的PaLM、Meta的LLAMA、TII的Falcon、MosaicML的MPT等模型都使用了Transformer架构。我们可以很容易地列举出50家公司使用Transformer用来训练LLM。这是一个很好的架构，但其在扩展方面存在缺陷。
请参考《The AI Brick Wall – A Practical Limit For Scaling Dense Transformer Models, and How GPT 4 Will Break Past It》中我们关于训练成本的讨论。我们揭秘了OpenAI为GPT-4架构所做的高层次工作，以及各种现有模型的训练成本。
在过去的6个月中，我们已经意识到训练成本已不再重要。
从表面上看训练一个模型需要数千万甚至上亿美元的计算成本，这似乎有些疯狂，但对于这些大公司来说，这只是微不足道的花费。这实际上是一个资本支出项目，规模越大，效果越好。唯一的限制因素是将时间扩展到人类可以获得反馈并修改架构的时间尺度。
未来几年，Google、Meta和OpenAI/Microsoft等多家公司将在价值超过上千亿美元的超级计算机上训练模型。Meta每年在“Metaverse”上烧掉160多亿美元，谷歌每年在各种永远不会有结果的项目上浪费100亿美元。Amazon在Alexa上损失超过500亿美元。加密货币在毫无价值的的项目上浪费了超过1000亿美元。
这些公司和整个社会可以并将花费超过1000亿美元来制造能够训练单一大模型的超级计算机。然后，这些大模型可以以各种方式产品化。这项工作将在多个国家和公司重复进行。这是新的“太空竞赛”。与之前的浪费不同之处在于，AI将在短期内在人类助手和自主代理方向产生直接价值。
在扩展AI方面最重要的问题是推理，目标是将推理计算与训练计算解耦。这就是模型部署时，需要训练 Chinchilla是最优选择的原因。所以会选择稀疏架构以保证并不是所有参数都会被激活。
真正的难点在于，将这些模型推广到用户和代理的成本太高。推理的成本是训练成本的数倍。这正是OpenAI在模型架构和基础设施方面的创新目标。
大模型的推断是一个多变量问题，在这个问题上，模型的大小对密集模型来说是致命的，在《On Device AI – Double-Edged Sword》中详细讨论了边缘问题，这个问题表现于数据中心非常相似。简单来说，设备永远不可能为LLM提供足够的内存带宽来达到一定的吞吐量。即使有足够的带宽，边缘硬件计算资源的利用率也会非常低。
在数据中心和云计算中，利用率就是一切。NVIDIA的软件备受赞誉，一半原因在于在GPU的几代生命周期中，Nvidia不断更新底层软件，通过在芯片周围、芯片之间和内存中更智能的移动数据来提高FLOPS利用率。
在当前大多是应用案例中，LLM推理都是作为实时助手使用，这意味着它必须达到足够高的吞吐量，以便用户能够实际使用它。人类的平均阅读速度为250/min，但有些人的阅读速度高达1000/min。这意味着LLM的推理速度至少应该是8.33token/s，更近一步需要达到33.33token/s才能覆盖所有的情况。
由于内存带宽的限制，在即使是最新的Nvidia H100 GPU服务也达到实现数万亿参数的密集模型数学计算所要求的吞吐量。每个生成的Token都需要将参数从内存加载到芯片。然后将生成的token送入prompt，然后生成下一个token，此外，attention的KN缓存中的数据流也需要额外的带宽。
上图展示了在足够高吞吐量的情况下，为满足单个用户的需求LLM所需内存带宽与模型参数之间的关系。事实证明，即使是8*H100也无法支撑1万亿参数的密集模型达到33.33token/s的服务。
此外，8*H100的FLOPS利用率在20token/s的情况下忍将低于5%，导致推理成本高的可怕。实际上，对于目前的8路张亮6并行的H100系统来说，推理限制在~3000亿个前向参数左右。
然而，OpenAI正在用A100s实现人类的阅读速度，其模型参数超过1万亿个，而且他们亿每1000个token仅0.06美元的低价广泛提供。这是因为它是稀疏的，并非所有参数都参与计算。
1. 模型结构
GPT-4的规模是CPT-3的10倍之多。我们认为，与GPT-3的1750亿参数相比，GPT-4有120层参数量约为1.8万亿。
OpenAI通过采用专家混合（MoE）模式来保持合理的成本。关于MoE请参考《The AI Brick Wall – A Practical Limit For Scaling Dense Transformer Models, and How GPT 4 Will Break Past It》。
此外，OpenAI使用了16个专家，每个专家的MLP参数约为111B。其中2个专家路由到每个前向计算过程。
虽然文献中提到了很多先进的路由算法，用于选择将每个token给哪些专家，但OpenAI的路由算法据称非常简单，适用于当前的GPT-4模型。
此外，大约有55B个attention共享参数。
每个前向推理（生成1个token）仅使用~280B参数和560TFLOP。相比之下，密集模型每次前向推理需要约1.8w亿个参数和3700TFLOP。
2. 数据组成
OpenAI在约13万亿个Token上训练了GPT-4。鉴于RefinedWeb的CommonCrawl包含约1.5万亿个高质量token，这是有道理的。作为参考，Deepmind的Chinchilla和Google的PaLM模型分别用~1.4万亿个和~0.78万亿个token进行了训练。即使是PaLM 2，据称也是使用~5万亿个token进行训练。
该数据集并非13万亿个唯一的token。相反，由于缺乏高质量的token，数据集包含了多个epoch。基于文本的数据有2个epoch，基于代码的数据有4个epoch。有趣的是，这远远低于Chinchilla的最佳值，表明需要双倍的token数量用于模型训练。这表明网络上缺乏网络上缺乏易于获取的token。高质量的token数量是现有token的1000倍，音频和视觉token数量甚至更多，但这些token的来源并不像互联网爬虫那么简单。
来自ScaleAI和内部的指令微调数据多达数百万行。遗憾的是，我们无法获取关于RLHF数据更多的信息。
预训练阶段上下文长度（seqlen）为8k。GPT-4的32K seqlen版本是基于预训练后对8K的微调。
OpenAI使用的批量大小为6000万！当然，由于并非每个专家都能看到所有token，因此每个专家“只能”看到750w个token。
3. 并行策略
所有A100 GPU的并行化策略至关重要。他们采用了8路张量并行，因为这是NVLink的极限。除此之外，我们听说他们还使用了15路流水线并行。从理论上讲，考虑到通讯与计算时间的对比，这样的流水线数量过多，但如果他们的内存容量受到限制，那么这样做事合理的。
在纯流水线+张量并行的情况下，每个GPU FP16的参数就有~30GB。一旦加上KV缓存和开销，如果OpenAI大部分GPU都是40GB的A100，那么理论上这是合理的。他们很可能使用了ZeRo第一阶段。他们有可能使用了块级FSDP，或者混合共享数据并行。
至于他们为什么不使用全模型FSDP，可能是因为通信开销较大。虽然OpenAI在大多数节点之间都有高速网络，但不一定在所有节点之间都有高速网络。我们相信，至少有一些集群的连接带宽要比其他集群低得多。
我们不明白他们是如何在如此高的流水线并行下避免每个batch产生巨大的bubbles。似乎他们只承担了成本。
4. 训练费用
OpenAI的GPT-4训练FLOPS约为2.15e25，在约25,000个A100上运行90~100天，MFU约为32%到36%。这种极低的利用率部分是由于需要重新启动检查的的故障数量过多。上述泡沫的成本极高。
另一个原因是，在如此多的GPU之间进行all-reduce的成本极高。如果向我们所猜测的那样，集群实际上是一堆较小的集群，它们之间的联网能力要弱得多，那么情况就更是如此。
如果云计算的成本约为A100 1$/h，那么仅此次运行的训练成本约为6300万美元。这还不包括所有的实验、失败的训练、以及数据收集、RLHF、员工等其他成本。由于这些因素，实际成本要高得多。此外这还意味着你需要找人购买芯片、网络、数据中心，承担资本支出，然后租给你。
如今，预训练可以使用~8,192块H100训练55天来完成，H100按2$/h计算，总费用将为2,150万美元。请注意，我们相信到今年年底将会有9家公司拥有更多的H100。并非所有公司都会将其全部用于单一的训练使用，但哪些如此做的公司将拥有更大的模型。到今年年底，Meta将拥有超过100,000个H100，但相当数量的H100将分布在其数据中心进行推理。他们最大的单个集群仍将远远超过25,000个H100。
到今年年底，很多公司将拥有训练GPT-4规模模型的计算资源。
5.专家权衡
MoE是一种在推理过程中减少参数数量的好方法，同时还能增加参数数量，这对每个训练每个token编码更多信息是必须的。这是必要的，因为获得足够多的高质量token是及其困难的。如果OpenAI真的想达到Chinchilla最优，他们就必须在2倍的token上进行训练。
尽管如此，OpenAI还是做了多种权衡。例如，MoE在推理过程中处理起来非常困难，因为并非模型的每一部分都会在每一次token生成中都会被使用。这意味着当其他部分被使用时，某些部分可能处于休眠状态。在为用户提供服务时，这确实会损害利用率。
研究表明，使用64至128名专家比使用16名专家能取得更好的损失效果，但这纯粹是研究结果。使用较少专家有多种原因。OpenAI选择16名专家的一个原因是，更多的专家在许多任务中难以实现泛化。更多的专家也更难以实现收敛面对如此大的训练量，OpenAI选择在专家数量上更加保守。
此外，使用较少的专家也有助于他们的推理基础架构。在转向混合专家推理架构时，需要进行各种复杂的权衡。让我们先来了解一下LLMS推理的基本权衡，然后再来看OpenAI面临的问题以及他们做出的选择。
6.推理权衡
在开始之前，作为一个旁观者，我们想指出的是，我们接触过的每一家LLM公司都认为Nvidia的FasterTransformer推理库非常糟糕，而TensorRT甚至更糟由于无法使用Nvidia的模板并对其进行修改，这意味着人们需要从头开始创建自己的解决方案。对于正在阅读这篇文章的Nvidia公司来说，你们需要尽快为LLM推理解决这个问题，否则事实将成为一个开放的工具，可以更容易地添加第三方硬件支持。巨大的模型浪潮即将到来。如果在推理阶段没有软件优势，或需要从头写kernel，那么AMD的MI300或其他硬件将会有更大的市场。
对于大模型推理在batchsize维度（同时服务用户的数量）和使用芯片数量，有3个方面需要权衡。
- 延迟-模型必须在合理的延迟内响应。在聊天应用程序中，人类不希望等待数秒后才开始流式输出。预填充 (输入token)和解码 (输出token) 需要不同的处理时间。
- 吞吐量-模型必须每秒输出一定数量的token。人类使用时需要每秒大约30 token/s。对于其他各种用例，较低或较高的吞吐量也是可以的。
- 利用率-运行模型的硬件必须达到高利用率，否则成本太高。虽然可以利用较高的延迟和较低的吞叶量将更多的用户请求组合在一起，从而实现更高的利用率，但这也会使其变得更加困难。
LLM推理需要平衡两个要点: 内存带宽和计算量。用最简单的话来说，每个参数都必须被读取，并且有2个FLOP与之相关。因此，大多数芯片的比率 (H100SXM只有3TB/s的内存带宽，但FP8却有2.000 TFLOP/s) 对于批量规模为1的推理来说是完全不平衡的。如果只为1个用户提供服务，即批量规模为1，那么每次token生成的每个参数流所需的内存带宽将支配推理时间。计算时间几乎为零。
要将大型语言模型有效地扩展到众多用户，批量大小必须超过1.多个用户分摊参数读取成本。例如，当批量大小为256或512时，每读入一个字节的内存就有512 FLOP/s或1024 FLOP/s。这个比率更接近H100的内存带宽与FLOPS的比率。这有助于实现更高的利用率，但也带来了更高延迟的缺点。
许多人认为内存容量是LLM推理的主要瓶颈，因为模型的大小可以容纳在许多芯片上，但这是不正确的。虽然大型模型需要多个芯片进行推理，而且更高的内存容量就可以使用更少芯片，然而使用更多的芯片会更好没因为这样可以降低延迟，提高吞吐量，并使用更大的batchsize来提高利用率。
谷歌在其PaLM推理论文中展示了这些权衡。然而，值得注意的是，这是针对像PaLM这样的密集模型，而不是像GPT- 4这样的稀疏模型。
- 如果一个应用需要尽可能低的延迟，我们就需要应用更多的芯片，并以尽可能多的方式对模型进行分区。较小的批量可以实现较低的延迟，但较小的批量也会导致较差的MFU利用率，从而导致每个token的总成本较高以芯片秒数或美元计算)。
- 如果该应用为离线推理，并不考虑延迟，那么主要目标是最大化每个芯片的吞吐量（即最小化每个token的成本）。增加batch size是最明智的做法，因为batch size越大，MFU越高。但在某些情况下，更大的batch size并不会更高效。
更多的芯片和更大的批量是最便宜的，因为这样可以提高利用率，但同时也引入了第三个变量，即联网时间。在芯片间拆分模型的某些方法在延迟方面更为经济，但会影响利用率。
- 存储时间的权重加载部分和非关注计算时间都与模型大小成正比，与芯片数量成反比。然而，对于给定的分区布局，芯片到芯片通信所需的时间随着芯片数量的增加而减少 (或根本不减少) ，因此随着芯片数量的增加，芯片到芯片通信成为一个越来越重要的瓶颈。
虽然我们今天只是简单地讨论一下，但应该注意的是，KV缓存的内存需求会随着批量大小和seglen的增长而爆炸性增长。
- 如果应用需要生成具有较长注意力上下文的文本，则会大大增加推理时间。对于具有多头注意力的500B+模型，注意力KV缓存会变得很大:对于批量大小512和上下文长度2048，KV缓存总计3TB，是模型参数大小的3倍。在芯片计算核心基本处于空闲状态时，每生成一个token，片上存储器就需要从片外存储器加载一次KV缓存。
较长的序列长度对内存带宽和内存容量的影响尤为严重。OpenAI的16k seglenGPT 3.5 turbo和32k seglen GPT 4由于内存限制无法使用更大的批量，因此成本更高。
较小的批次规模会降低硬件利用率。此外，随着序列长度的增加，KV缓存也会膨胀，KV缓存不能再用户之间共享，因此需要单独读取内存，进一步限制了内存带宽。
7. 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的参数，或在FP16下每个GPU少于30GB，在FP8/int8下少于15GB。这使得推理可以在40GB的A100上运行只要所有批次的KV缓存大小不会过大。
包含各种专家的单个层不会在不同的节点上分解，因为这会使网络tramc太不规则，并且在每个token生成之间重新计算KV缓存的成本太高。对于任何未来的MIoE模型扩展和条件路由，最大的困难是如何处理KV缓存周围的路由。
层数为120，因此在15个不同的节点中进行下潜是很简单的，但由于第一个节点需要进行数据加载和嵌入，因此在推理集群的首节点上设置较少的层数是合理的。此外，还有一些关于推测解码的杂音。这也解释了为什么头节点需要包含更少的层。
8. GPT-4推理成本
尽管GPT-4的前馈参数仅为175B参数Davinchi模型的1.6倍，但其成本却是后者的3倍。这主要是由于GPT-4需要更大的集群和更低的利用率。
我们认为，128个A100推断GPT-4 8k seglen每1k token的成本为0.0049美分，128个H100推断GPT-4 8k seglen每1k token的成本为0.0021美分。需要注意的是，我们假设利用率很高，并保持较高的批量规模。
这可能是一个错误的假设，因为很明显OpenAI有时利用率很低。我们假定OpenAI在低谷时段关闭集群，并重新利用这些节点，从检查点恢复训练，用于尝试各种新技术的小型测试模型。这有助于保持较低的推理成本。如果OpenAI不这样做，他们的利用率会更低，我们的成本估计会增加一倍以上
9. Multi-Query Attention
MQA是每个人都在做的事情，但我们想指出OpenAI也在做。长话短说，只需要一个磁头，KV缓存的内存容量可以大大减少。即便如此，32k seqlen GPT-4肯定无法在40GB的A100上运行，而且8k是有最大批量上限的。如果没有它，8K的最大批处理容量将被大幅限制，以至于不划算。
10. Continuous batching
OpenAI实现了可变批量大小和连续批量。这是为了允许一定程度的最大延迟以及优化推理成本。如果您不熟悉这个概念，AnyScale的这一页值得一读.
11. 推测性解码
我们从一些可靠的人那里听说，OpenAI在GPT-4推理上使用了推测解码。我们不确定这是否属实。token到token的延迟以及简单检索任务与更复杂任务之间的差异似乎表明这是可能的，但有太多的变量需要了解。为了以防万一，我们将使用"Accelerating LLM Inference with Staged Speculative Decoding "中的一些文字，并稍作修改/添加一些颜色，在此对其进行解释。
使用LLMs通常分为两个阶段。首先是预填充，通过模型运行提示，生成KV缓存和第一个输出logits (可能token输出的概率分布) 。这通常是快速的因为整个提示可以并行处理
第二阶段是解码。从输出的logits中选择一个标记并反馈到模型中，由模型生成下一个标记的logits。如此反复，直到生成所需的标记数。由于每次必须按顺序对流经计算单元的权重进行解码才能生成单个token，因此当小批量运行时，第二阶段的算术强度（即计算的 FLOP/内存带宽的字节）非常低。因此，解码通常是自回归生成中最昂贵的部分。
这就是为什么在OpenAI的API调用中，输入token比输出token便宜得多。推测解码的基本思想是使用一个较小、较快的 drai 模型提前解码几个token，然后将它们作为一个批次输入 Oracle 模型。如果Drafi模型的预测是正确的_-较大的模型也同意--那么就可以用一个批次解码多个token，这就为每个token节省了大量的内存带宽，从而节省了时间。
然而，如果较大的模型剔除了Draf模型预测的token，那么剩下的批次将被丢弃，算法自然恢复到标准的逐个token解码。投机解码也可以采用拒绝采样方案，从原始分布中采样。请注意，这仅在带宽成为瓶颈的小批量设置中有用
推测性解码以计算换取带宽。推测解码是一个有吸引力的性能工程目标有两个关键原因。首先，它完全不会降低模型质量。其次，它提供的增益通常与其他方法正交，因为它的性能来自于将顺序执行转换为并行执行。
目前的推测方法预测批次的单一序列。然而，这并不能很好地扩展到大批量或低Draf模型排列。从直观上看，两个模型对长的连续的标记序列达成一致的概率是指数级低的，这意味着随着算术强度的增加，推测解码的收益会迅速降低。
我们认为，如果OpenAI正在使用推测解码，那么他们很可能只将其用于约4个token的序列。作为一个旁观者，降低GPT-4质量的整个阴谋可能只是因为他们让Ocracle模型接受来自推测解码模型的低概率序列。另一个旁证是，有些人猜测bard使用了推测性解码，因为谷歌会等待整个序列生成后再将其发送给用户，但我们不相信这种推测是真的。
12. 视觉多模态
视觉多模态功能是GPT-4最不令人印象深刻的部分，至少与领先的研究相比是如此。当然，目前还没有人将多模态LLM的研究成果商业化。
它是一个独立于文本编码器的视觉编码器，但存在交叉关注。我们听说其架构与Flamingo类似。它在GPT-4的1.8T之上增加了更多参数。在仅对文本进行预训练的基础上，又对约2万亿个token进行了微调。
在视觉模型方面，OpenAI希望从头开始训练，但该模型还不够成熟，因此他们希望从文本入手来降低风险。
他们训练的下一个型号GPT-5，据称将从头开始进行视觉训练，并能自行生成图像。此外，它还将能够进行音频处理。
这种视觉能力的主要目的之一是让自主代理能够阅读网页并转录图像和视频中的内容。他们训练的一些数据是联合数据 (渲染的LaTeX/文本) 、网页截图YouTube视频:取样帧，并围绕其运行Whisper以获得转录。
所有这些对LLM的过度优化的一个有趣之处在于，视觉模型的IO成本与文本模型的IO成本不同。在文本模型上，正如我们在Amazon Cloud Crisis一文中所描述的，IO成本极低。在视觉模型上，数据加载的IO成本要高出约150倍每个标记 600 字节，而不是文本的 4 字节。在图像压缩方面正在开展大量工作。
这对于那些在2-3年后围绕LLM的用例和比率优化硬件的硬件供应商来说极为重要。他们可能会发现自己身处的世界中，每个模型都具有强大的视觉和音频功能。他们可能会发现自己的架构适应性很差。总体而言，架构肯定会超越我们目前看到的基于文本的简化密集型和/或MIoE模型。