GPT-4被破解 训练成本 模型架构的秘密都被挖出来了？

几个小时前SemiAnalysis的DYLAN PATEL和DYLAN PATEL发布了一个关于GPT-4的技术信息，包括GPT-4的架构、参数数量、训练成本、训练数据集等。本篇涉及的GPT-4数据是由他们收集，并未公开数据源。仅供参考。

原文翻译如下：

揭秘 GPT-4：导致 OpenAI 架构的工程权衡

OpenAI保持GPT-4架构的封闭性并不是因为对人类存在一些生存风险，而是因为他们构建的东西是可复制的。事实上，我们预计Google、Meta、Anthropic、Inflection、Character、腾讯、字节跳动、百度等在短期内都将拥有与GPT-4一样强大的模型。

不要误解我们的意思，OpenAI拥有令人惊叹的工程技术，他们构建的东西令人难以置信，但他们得出的解决方案并不神奇。这是一个优雅的解决方案，具有许多复杂的权衡。做大只是战斗的一部分。OpenAI最持久的护城河是他们拥有最真实的使用情况、领先的工程人才，并且可以通过未来的模型继续领先于其他人。

我们从许多来源收集了大量有关GPT-4的信息，今天我们想分享一下。这包括模型架构、训练基础设施、推理基础设施、参数计数、训练数据集组成、令牌计数、层数、并行策略、多模态视觉适应、不同工程权衡背后的思维过程、独特的实施技术以及它们如何减轻一些问题他们最大的瓶颈与巨型模型的推理有关。

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

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

首先，问题陈述。从GPT-3到4，OpenAI希望扩展100倍，但问题是成本。 密集变压器模型将无法进一步扩展。密集变压器是OpenAI GPT-3、Google PaLM、Meta LLAMA、TII Falcon、MosaicML MPT等使用的模型架构。我们可以轻松说出50家使用相同架构培训法学硕士的公司。这是一个很好的方法，但它在扩展方面存在缺陷。

从训练成本的角度来看，请参阅我们在GPT-4公告之前关于即将推出的密集模型AI砖墙的训练成本讨论。在那里，我们揭示了OpenAI在GPT-4架构方面所做的高层工作以及各种现有模型的训练成本。

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

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

未来几年，谷歌、Meta、OpenAI/微软等多家公司将在价值超过千亿元的超级计算机上训练模型。Meta每年在“Metaverse”上燃烧超过160亿美元，Google每年在各种永远不会实现成果的项目上浪费100亿美元。亚马逊在Alexa上损失了超过50亿美元。加密货币在毫无价值的事情上浪费了超过1000亿美元。

这些公司和整个社会可以而且将会花费超过一千亿美元来创建可以训练单个大规模模型的超级计算机。然后可以通过多种方式将这些大型模型产品化。这项工作将在多个县和公司重复进行。这是新的太空竞赛。以前的浪费与现在的区别在于，人工智能可以在短期内从人类助手和自主代理身上带来有形的价值。

扩展人工智能（真正的人工智能砖墙）的更重要问题目标是将训练计算与推理计算分离。这就是为什么训练Chinchilla对于任何将要部署的模型来说都是最佳的。这就是为什么要进行稀疏模型架构；每个参数在推理过程中都不会被激活。

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

大型模型的推理是一个多变量问题，其中模型大小会导致密集模型的死亡。

我们已经在这里详细讨论了有关边缘的问题，但数据中心的问题陈述非常相似。简而言之，设备永远不可能有足够的内存带宽来容纳大型语言模型来实现一定水平的吞吐量。即使它们有足够的带宽，边缘硬件计算资源的利用率也会很糟糕。

在数据中心、云中，利用率就是一切。Nvidia因其卓越的软件而受到赞誉的一半原因是，在GPU的几代生命周期中，Nvidia不断更新低级软件，通过在芯片周围、芯片和内存之间更智能地移动数据来提高FLOPS利用率。

目前大多数用例中的LLM推理都是作为实时助手运行，这意味着它必须实现足够高的吞吐量，以便用户可以实际使用它。人类平均每分钟阅读约250个单词，但有些人的阅读速度高达每分钟约1,000个单词。这意味着您需要每秒至少输出8.33个令牌，但每秒需要输出33.33个令牌才能覆盖所有极端情况。

由于内存带宽要求，即使在最新的Nvidia H100 GPU服务器上，万亿参数密集模型在数学上也无法实现此吞吐量。每个生成的令牌都需要将每个参数从内存加载到芯片上。然后，将生成的令牌输入到提示中，并生成下一个令牌。此外，注意力机制的KV缓存中的流传输需要额外的带宽。

上图展示了以足够高的吞吐量推理LLM以便为单个用户提供服务所需的内存带宽。它表明，即使8x H100也无法以每秒33.33个令牌的速度提供1万亿参数密集模型。此外，每秒20个令牌的8xH100的FLOPS利用率仍低于5%，导致推理成本非常高。实际上，目前的8路张量并行H100系统存在约3000亿个前馈参数的推理约束。

然而，OpenAI正在通过A100实现人类的阅读速度，其模型超过1万亿个参数，并且以每1,000个代币仅0.06美元的低价广泛提供。那是因为它是稀疏的，IE并不是每个参数都被使用。

废话够多了，我们来谈谈GPT-4模型架构、训练基础设施、推理基础设施、参数计数、训练数据集组成、标记计数、层数、并行策略、多模态视觉编码器、不同工程权衡背后的思维过程、独特的实施的技术，以及它们如何缓解与大型模型推理相关的一些最大瓶颈。

总结主要的关于GPT-4的信息（总结来自Yam Peleg的推文）：

参数数量：GPT-4比GPT-3大10倍，估计参数数量在120层、1.8万亿左右。

MoE架构：即Mixture-of-Experts架构，这部分信息已经确认，OpenAI通过利用MoE架构保持一定的成本，包含16个Experts，每一个都是一个MLP.2，约1110亿参数，每个前向传播都被路由到这些专家中

MoE路由：尽管公开的技术文档中说了很多高级的路由功能，包括每个token如何选择每个专家等。但是现有GPT-4其实非常简单，大约就是为每个attention共享550亿参数的方式。

推理：每一个前向传播的推理（生成一个token）需要2800亿参数以及560 TFLOPS，这与纯dense模型每次正向传递所需的约1.8万亿参数和3700 TFLOPS形成了鲜明对比。

训练数据集：GPT-4在约13万亿tokens上训练。这不是指不同的token数量，是根据epochs计算使用的token数量。基于文本的数据集做了2次epoch训练，基于代码的数据集做了4次epoch训练。

GPT-4 32K：每一个预训练阶段都是8K的长度。32K的版本是8K预训练模型之后微调得到的。

Batch Size：batch size是逐渐上升的，在集群中经过几天的时间达到一个数值。最终，OpenAI的Batch Size达到了6000万！也就是每个专家大约有750万的token数量，但是并不是每个专家都能看到所有的tokens。

并行策略：由于NVLink的限制，OpenAI训练GPT-4做了8路tensor并行，15路的pipeline并行。

训练成本：OpenAI训练GPT-4的FLOPS约2.15e25，在2.5万个A100上训练了90-100天左右时间（MFU约32%到36%），如果是一个A100约1美元，那么训练成本约6300万美元（如果现在使用H100可能只要2150万美元）。

MoE的取舍：使用MoE之后做了很多取舍，包括推理的处理困难，因为每个模型都用来生成文本。这意味着生成的时候有的可以使用，有的空闲，对使用率来说非常浪费。研究显示64-128个专家的损失比16个专家更好。

GPT-4的推理成本：比1750亿的Davinchi（GPT-3/3.5系列）高3倍，主要是GPT-4的集群太大，利用率低一点。估计约1k tokens要0.0049美元（128个A100）。

MOA：Multi Query Attention，和其他人一样，都是正常使用MOA。因为只需要1个head，显存大大下降，但是32K依然无法在A100 40G运行。

持续batching：OpenAI使用可变的batch size和持续batching方法。可以平衡推理成本和推理速度。

Vision Multi-Modal：GPT-4的多模态部分是单独一个visiion encoder，带有cross attention。使得1.8万亿的GPT-4的参数扩展到2万亿左右。VisionModel是从头训练的，还不够成熟。Vision部分的一个作用是让代理可以月度网页，然后转换成图片和视频。部分数据是基于Latex与屏幕截屏训练的。还有YouTube视频，包括使用whisper翻译的脚本与抽帧结果。

推理架构：推理是在128个GPU集群上运行的，在不同的区域有不同的集群。每个节点有8个GPU，包含1300亿参数的模型。或者说每个GPU少于30GB的FP16、少于15GB的FP8/int8。

责任编辑：若风

以上就是手游巴士为您提供《GPT-4被破解 训练成本 模型架构的秘密都被挖出来了？》的详细内容,更多精彩内容请继续阅读上一篇《28nm芯片没入门就想一口吃胖子：富士康和印度“完美”互坑》