终极「揭秘」:GPT-4模型架构、训练成本、数据集信息都被扒出来了

简介: 终极「揭秘」:GPT-4模型架构、训练成本、数据集信息都被扒出来了

一直以来,大家都对 GPT-4 的模型架构、基础设施、训练数据集、成本等信息非常好奇。

奈何 OpenAI 嘴太严,很长时间以来,大家也都只是猜测这些数据。

不久之前,「天才黑客」乔治・霍兹(George Hotz)在接受一家名为 Latent Space 的 AI 技术播客采访时透露出一个小道消息,称 GPT-4 是由 8 个混合专家模型组成的集成系统,每个专家模型都有 2200 亿个参数(比 GPT-3 的 1750 亿参数量略多一些),并且这些模型经过了针对不同数据和任务分布的训练。

虽然此消息无法验证,但其流传度非常高,也被部分业内人士认为非常合理。

最近,更多的消息似乎被泄露了出来。

今日,SemiAnalysis 发布了一篇付费订阅的内容,「揭秘」了有关 GPT-4 的更多信息。

文章称,他们从许多来源收集了大量有关 GPT-4 的信息,包括模型架构、训练基础设施、推理基础设施、参数量、训练数据集组成、token 量、层数、并行策略、多模态视觉适应、不同工程权衡背后的思维过程、独特的实现技术以及如何减轻与巨型模型推理有关的瓶颈等。

作者表示,GPT-4 最有趣的方面是理解 OpenAI 为什么做出某些架构决策。

此外,文章还介绍了 A100 上 GPT-4 的训练和推理成本,以及如何拓展到下一代模型架构 H100 。

我们根据 Deep Trading(一家算法交易公司)创始人 Yam Peleg 的推文(目前已删除),整理了以下关于 GPT-4 的数据信息。感兴趣的读者可以细致研究下。

不过请注意,这并非官方确认的数据,大家自行判断其准确性。

1、参数量GPT-4 的大小是 GPT-3 的 10 倍以上。文章认为它 120 层网络中总共有 1.8 万亿个参数。

2、确实是混合专家模型。OpenAI 能够通过使用混合专家(MoE)模型来保持合理成本。他们在模型中使用了 16 个专家模型,每个专家模型大约有 111B 个参数。这些专家模型中的 2 个被路由到每个前向传递。

3、MoE 路由:尽管文献中对于选择将每个 token 路由到哪个专家模型的高级路由算法进行了大量讨论,但据称 OpenAI 在当前的 GPT-4 模型中采用了相当简单的路由方式。该模型大约使用了 550 亿个共享参数来进行注意力计算。

4、推理:每次前向传递的推理(生成 1 个 token)仅利用约 2800 亿个参数和约 560 TFLOP 的计算量。相比之下,纯密集模型每次前向传递需要大约 1.8 万亿个参数和约 3700 TFLOP 的计算量。

5、数据集:GPT-4 的训练数据集包含约 13 万亿个 token。这些 token 是重复计算之后的结果,多个 epoch 中的 token 都计算在内。

Epoch 数量:针对基于文本的数据进行了 2 个 epoch 的训练,而针对基于代码的数据进行了 4 个 epoch 的训练。此外,还有来自 ScaleAI 和内部的数百万行的指令微调数据。

6、GPT-4 32K:在预训练阶段,GPT-4 使用了 8k 的上下文长度(seqlen)。而 32k 序列长度版本的 GPT-4 是在预训练后对 8k 版本进行微调而得到的。

7、Batch Size:在计算集群上,几天时间里,batch size 逐渐增加,最后,OpenAI 使用 batch size 达到了 6000 万!当然,由于不是每个专家模型都能看到所有 token,因此这仅仅是每个专家模型处理 750 万个 token 的 batch size。

真实的 batch size:将这个数字除以序列长度(seq len)即可得到真实的 batch size。请不要再使用这种误导性的数字了。

8、并行策略:为了在所有 A100 GPU 上进行并行计算,他们采用了 8 路张量并行,因为这是 NVLink 的极限。除此之外,他们还采用了 15 路流水线并行。(很可能使用了 ZeRo Stage 1,也可能使用了块级的 FSDP)。

9、训练成本:OpenAI 在 GPT-4 的训练中使用了大约 2.15e25 的 FLOPS,使用了约 25,000 个 A100 GPU,训练了 90 到 100 天,利用率(MFU)约为 32% 至 36%。这种极低的利用率部分是由于大量的故障导致需要重新启动检查点。

如果他们在云端的每个 A100 GPU 的成本大约为每小时 1 美元,那么仅此次训练的成本将达到约 6300 万美元。(而如今,如果使用约 8192 个 H100 GPU 进行预训练,用时将降到 55 天左右,成本为 2150 万美元,每个 H100 GPU 的计费标准为每小时 2 美元。)

10、使用专家混合模型时的 tradeoff:在使用专家混合模型时存在多方面 tradeoff。

例如,在推理过程中处理 MoE 非常困难,因为并非模型的每个部分都在每个 token 生成时被利用。这意味着在某些部分被使用时,其他部分可能处于闲置状态。在为用户提供服务时,这会严重影响资源利用率。研究人员已经证明使用 64 到 128 个专家比使用 16 个专家能够实现更好的损失(loss),但这仅仅是研究的结果。

选择较少的专家模型有多个原因。OpenAI 选择 16 个专家模型的一大原因是:在许多任务中,更多的专家模型很难泛化,也可能更难收敛。

由于进行了如此大规模的训练,OpenAI 选择在专家模型数量上更加保守。

11、推理成本:GPT-4 的推理成本是 1750 亿参数的 Davinci 模型的 3 倍。这主要是因为 GPT-4 需要更大规模的集群,并且达到的利用率要低得多。

据估计,在用 128 个 A100 GPU 进行推理的情况下,8k 版本 GPT-4 推理的成本为每 1,000 个 token 0.0049 美分。如果使用 128 个 H100 GPU 进行推理,同样的 8k 版本 GPT-4 推理成本为每 1,000 个 token 0.0021 美分。值得注意的是,这些估计假设了高利用率和保持较高的 batch size。

12、Multi-Query Attention:OpenAI 和其他机构一样,也在使用 Multi-Query Attention(MQA)。由于使用 MQA 只需要一个注意力头(head),并且可以显著减少用于 KV 缓存的内存容量。即便如此,32k 序列长度的 GPT-4 也绝对无法在 40GB 的 A100 GPU 上运行,而 8k 序列长度的模型则受到了最大 batch size 的限制。

13、连续 batching:OpenAI 实现了可变 batch size 和连续 batching。这样做是为了允许一定程度的最大延迟,并优化推理成本。

14、视觉多模态:它是一个独立于文本编码器的视觉编码器,二者之间存在交叉注意力。该架构类似于 Flamingo。这在 GPT-4 的 1.8 万亿个参数之上增加了更多参数。在纯文本的预训练之后,它又经过了另外约 2 万亿个 token 的微调。

对于视觉模型,OpenAI 本来希望从零开始训练,但由于其尚未成熟,所以他们决定先从文本开始训练来降低风险。

这种视觉能力的主要目的之一是使自主智能体能够阅读网页并转录图像和视频中的内容。

他们训练的一部分数据是联合数据(包括渲染的 LaTeX / 文本)、网页的截屏、YouTube 视频(采样帧),并使用 Whisper 对其进行运行以获取转录文本。

15、推测式解码(Speculative Decoding):OpenAI 可能在 GPT-4 的推理过程中使用了推测式解码技术(不确定是否 100%)。这种方法是使用一个更小更快的模型提前解码多个 token,并将它们作为单个 batch 输入到一个大型的预测模型(oracle model)中。

如果小型模型对其预测是正确的,大型模型将会同意,我们可以在单个 batch 中解码多个 token。

但是,如果大型模型拒绝了草稿模型预测的 token,那么 batch 中剩余的部分将被丢弃,然后我们将继续使用大型模型进行解码。

有些阴谋论指出,新的 GPT-4 质量已经下降,这可能只是因为他们让推测式解码模型(speculative decoding model)将概率较低的序列传递给预测模型,从而导致了这种误解。

16、推理架构:推理运行在由 128 个 GPU 组成的集群上。在不同地点的多个数据中心存在多个这样的集群。推理过程采用 8 路张量并行(tensor parallelism)和 16 路流水线并行(pipeline parallelism)。每个由 8 个 GPU 组成的节点仅具有约 1300 亿个参数。

该模型有 120 层,因此适合于 15 个不同的节点。可能第一个节点的层数较少,因为它还需要计算嵌入。

根据这些数字,如果 OpenAI 试图按照 chinchilla 的最佳指标进行训练,他们应该使用的 token 数量是现在的两倍。这表明他们在获取高质量数据方面遇到了困难。

最后想说的是,这应该是迄今为止关于 GPT-4 最为详细的数据揭秘。目前还不能求证是否真实,但也值得大家研究下。正如原文作者所说,「有趣的方面是理解 OpenAI 为什么做出某些架构决策。

关于 GPT-4 的这些架构信息,你怎么看?

更多信息请参考原文:https://www.semianalysis.com/p/gpt-4-architecture-infrastructure

相关实践学习
部署Stable Diffusion玩转AI绘画(GPU云服务器)
本实验通过在ECS上从零开始部署Stable Diffusion来进行AI绘画创作,开启AIGC盲盒。
相关文章
|
27天前
|
机器学习/深度学习 自然语言处理 分布式计算
大规模语言模型与生成模型:技术原理、架构与应用
本文深入探讨了大规模语言模型(LLMs)和生成模型的技术原理、经典架构及应用。介绍了LLMs的关键特点,如海量数据训练、深层架构和自监督学习,以及常见模型如GPT、BERT和T5。同时,文章详细解析了生成模型的工作原理,包括自回归模型、自编码器和GANs,并讨论了这些模型在自然语言生成、机器翻译、对话系统和数据增强等领域的应用。最后,文章展望了未来的发展趋势,如模型压缩、跨模态生成和多语言多任务学习。
106 3
|
2月前
|
数据采集 API 决策智能
华为诺亚联合中科大发布工具调用模型ToolACE,效果持平GPT-4获开源第一
 【10月更文挑战第10天】华为诺亚方舟实验室与中国科学技术大学合作推出ToolACE,一种自进化合成过程的工具调用模型。ToolACE通过多智能体交互和双重验证系统生成准确、复杂、多样化的工具学习数据,显著提升大型语言模型(LLM)的功能调用能力。实验结果显示,使用ToolACE数据训练的80亿参数模型性能媲美GPT-4,在伯克利功能调用排行榜上获得开源第一。
87 4
|
12天前
|
数据采集 人工智能 数据可视化
InternVL 2.5,首个MMMU超过70%的开源模型,性能媲美GPT-4o
近期Internvl2.5发布,性能与GPT-4o和Claude-3.5-sonnet等领先的商业模型相媲美,成为首个在MMMU上超过70%的开源模型,通过链式思考(CoT)推理实现了3.7个百分点的提升,展示了强大的测试时间可扩展性潜力。
|
10天前
|
机器学习/深度学习 测试技术 定位技术
新扩散模型OmniGen一统图像生成,架构还高度简化、易用
近期,一篇题为“OmniGen: Unified Image Generation”的论文介绍了一种新型扩散模型OmniGen,旨在统一图像生成任务。OmniGen架构简洁,无需额外模块即可处理多种任务,如文本到图像生成、图像编辑等。该模型通过修正流优化,展现出与现有模型相当或更优的性能,尤其在图像编辑和视觉条件生成方面表现突出。OmniGen仅含3.8亿参数,却能有效处理复杂任务,简化工作流程。尽管如此,OmniGen仍存在对文本提示敏感、文本渲染能力有限等问题,未来研究将继续优化其架构与功能。
39 16
|
1月前
|
机器学习/深度学习 自然语言处理 C++
TSMamba:基于Mamba架构的高效时间序列预测基础模型
TSMamba通过其创新的架构设计和训练策略,成功解决了传统时间序列预测模型面临的多个关键问题。
124 4
TSMamba:基于Mamba架构的高效时间序列预测基础模型
|
26天前
|
自然语言处理 搜索推荐 Serverless
基于函数计算部署GPT-Sovits模型实现语音生成
阿里云开发者社区邀请您参加“基于函数计算部署GPT-Sovits模型实现语音生成”活动。完成指定任务即可获得收纳箱一个。活动时间从即日起至2024年12月13日24:00:00。快来报名吧!
|
24天前
|
网络协议 网络架构
TCP/IP协议架构:四层模型详解
在网络通信的世界里,TCP/IP协议栈是构建现代互联网的基础。本文将深入探讨TCP/IP协议涉及的四层架构,以及每一层的关键功能和作用。
112 5
|
25天前
|
机器学习/深度学习 存储 人工智能
【AI系统】模型演进与经典架构
本文探讨了AI计算模式对AI芯片设计的重要性,通过分析经典模型结构设计与演进、模型量化与压缩等核心内容,揭示了神经网络模型的发展现状及优化方向。文章详细介绍了神经网络的基本组件、主流模型结构、以及模型量化和剪枝技术,强调了这些技术在提高模型效率、降低计算和存储需求方面的关键作用。基于此,提出了AI芯片设计应考虑支持神经网络计算逻辑、高维张量存储与计算、灵活的软件配置接口、不同bit位数的计算单元和存储格式等建议,以适应不断发展的AI技术需求。
30 5
|
27天前
|
弹性计算 自然语言处理 搜索推荐
活动实践 | 基于函数计算部署GPT-Sovits模型实现语音生成
通过阿里云函数计算部署GPT-Sovits模型,可快速实现个性化声音的文本转语音服务。仅需少量声音样本,即可生成高度仿真的语音。用户无需关注服务器维护与环境配置,享受按量付费及弹性伸缩的优势,轻松部署并体验高质量的语音合成服务。
|
1月前
|
运维 Serverless 数据处理
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
88 1

热门文章

最新文章

下一篇
DataWorks