Machine Translated by Google

www.semianalysis.com /p/gpt‑4‑architecture‑infrastruction

GPT‑4  架构、
基础设施、 培训
数据集、 成本、
愿景、MoE
迪伦·帕特尔、
杰拉德·黄        2023/7/11

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

如果您将前往夏威夷参加  ICML，
请告诉我们，
我们一起出去玩吧！

/付费内容

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  个月里，
我们意识到培训成本无关紧要。
Machine Translated by Google

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

未来几年，
谷歌、
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  服务器上，
万亿参数密集模型在数学上也无法实现此吞吐量。
每个生成的令牌
都需要每个
Machine Translated by Google

参数从内存加载到芯片上。
然后，
将生成的令牌输入到提示中，
并生成下一个令牌。
此外，
注意力机制的  KV  缓存中的流传输需要
额外的带宽。

该图假设由于无法融合每个操作而导致效率低下，
注意力机制所需的内存带宽以及硬件开销相当于参数读
取。
事实上，
即使使用“优化”
的库（例如Nvidia  的  FasterTransformer  库），
总开销也会更大。

上图展示了以足够高的吞吐量推理  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  的大小是  GPT‑3  的  10  倍以上。
我们认为它在  120  层中总共拥有约  1.8  万亿个参数，
而  GPT‑3  拥有约  1750  亿个参
数。

OpenAI  通过利用专家混合  (MoE)  模型能够将成本保持在合理⽔平。
如果您不熟悉MoE，
请阅读我们关于广泛的  
GPT‑4  架构和  6  个月起的培训成本的文章
Machine Translated by Google

前。

此外，
OpenAI  在其模型中使用了  16  位专家，
每个专家大约有  111B  个  MLP  参数。
每个前向传递都会路由其中  2  名专家。

虽然文献中大量讨论了用于选择将每个代币路由到哪些专家的高级路由算法，
但据称对于当前的  GPT‑4  模型来说，
OpenAI  的算法相当简单。

此外，
大约有约  55B  个共享参数需要注意。

每个前向传递推理（生成  1  个令牌）
仅利用约  280B  参数和约  560  TFLOP。
这与纯密集模型每次前向传递所需的约  1.8  万亿个参数和约  3,700  TFLOP  形成鲜明对比。

数据集组成
OpenAI  在约  13  万亿代币上训练了  GPT‑4。
这是有道理的，
因为  CommonCrawl  for  RefinedWeb  包含约  5  万亿个优质代币。
作为参考，
Deepmind  的  Chinchilla  和  Google  的  PaLM  模型分别使用约  1.4  万亿个令牌和约  0.78  万亿个令牌进行训练。
据称，
甚至  PaLM  2  也接受了约  
5  万亿个代币的训练。

该数据集不是  13  万亿个独特的代币。
相反，
由于缺乏高质量的令牌，
数据集包含多个纪元。
基于文本的数据有  2  个纪元，
基于代码的数据有  4  个纪
元。
有趣的是，
这远远低于  Chinchilla  最优值，
这表明需要在双倍的令牌数量上训练模型。
这表明网络上缺乏易于获取的代币。
那里有  1,000  倍以上的高
质量文本标记，
甚至更多的音频和视频，
但获取它们并不像网络抓取那么简单。

ScaleAI  以及内部有数百万行指令微调数据。
不幸的是，
我们无法找到更多关于他们的  RLHF  数据的信息。

预训练阶段的上下文长度  (seqlen)  为  8k。  GPT‑4  的  32k  seqlen  版本是基于预训练后的  8k  进行微调的。

集群上的批量大小在几天内逐渐增加，
但到最后，
OpenAI  使用的批量大小已达到  6000  万！
当然，
这“只是”
每个专家  750  万个代币的批量大小，
因为
并非每个专家都能看到所有代币。

并行策略
在所有  A100  GPU  上进行并行化的策略至关重要。
他们利用  8  路张量并行性，
因为这是  NVLink  的限制。
除此之外，
我们听说他们正在使用  15  路管道
并行性。
从理论上讲，
在考虑数据通信与计算时间时，
管道太多了，
但如果它们受到内存容量的限制，
那么这是有意义的。

当纯管道  +  张量并行时，
每个  GPU  FP16  的参数约为  30GB。
一旦添加  KV  缓存和开销，
如果  OpenAI  的  GPU  大部分是  40GB  A100，
这在理论上是
有意义的。
他们可能使用了  ZeRo  Stage  1。
他们也可能使用了块级  FSDP，
或者混合共享数据并行。
Machine Translated by Google

至于为什么他们不使用完整模型的FSDP，
可能是因为通信开销较高。
虽然  OpenAI  在大多数节点之间具有高速网络，
但可能并非在所有节点之间都具有高速网络。
我们相信至少有一些集群的连接
带宽比其他集群低得多。

我们不明白他们如何避免在如此高的管道并行性的情况下每批都出现巨大的气泡。
很可能他们只是吃了成本。

培训费用
OpenAI  的  GPT‑4  训练  FLOPS  约为  2.15e25，
在约  25,000  个  A100  上运行  90  至  100  天，
MFU  约为  32%  至  36%。
这种极低利
用率的部分原因是由于需要重新启动检查点的故障数量过多。
上述泡沫的成本极高。

另一个原因是这么多  GPU  之间的  all‑reduce  成本极高。
正如我们所怀疑的，
如果集群实际上是一堆较小的集群，
它们之间的网
络要弱得多，
即集群各段之间的  IE  800G/1.6T  无阻塞，
但这些段仅以  200G/400G  连接，
则情况尤其如此。

如果他们在云中的成本约为每  A100  小时  1  美元，
那么仅此一次运行的培训成本就约为  6300  万美元。
这忽略了所有的实验、
失
败的训练运行以及其他成本，
例如数据收集、
RLHF、
人员等。
由于这些因素，
真正的成本要高得多。
此外，
这意味着您有人
购买芯片/网络/数据中心，
吸收资本支出，
并将其出租给您。

如今，
预训练可在约  55  天内使用约  8,192  个  H100  完成，
费用为  2150  万美元，
每  H100  小时  2  美元。
请注意，
我们相信到今年年底将有  9  家公司拥有更多  H100。
并非所有这些公司都会将所有这些都专门用于一次训练，
但那些
这样做的公司将拥有更大的模型。
到今年年底，
Meta  将拥有超过  100,000  台  H100，
但其中很大一部分将分布在其数据中心用于推理。
它们最大的单个集群仍
将超过25,000  台  H100。
Machine Translated by Google

到今年年底，
许多公司将拥有训练  GPT‑4  规模模型的计算资源。

专家权衡的混合

MoE  是减少推理期间参数数量的好方法，
同时仍然增加参数数量，
这是为每个训练令牌编码更多信息所必需的。
这是必要的，
因为获得足够的高质量代币非常困难。
如果  OpenAI  真的想要让  Chinchilla  达到最佳状态，
他们就必须使用  2  倍的代币进
行训练。

话虽如此，
OpenAI  也做出了多种权衡。
例如，
MoE  在推理上非常难以处理，
因为并非模型的每个部分都会在每次代币生成中使用。
这意味着当其他部件正在使用时，
部件可能会处于休眠状态。
在服务用户时，
这确实会损害利用率。

研究人员表明，
使用  64  到  128  名专家比使用  16  名专家可以实现更好的损失，
但这纯粹是研究结果。
选择较少的专家有多种原
因。  OpenAI  选择  16  名专家的原因之一是因为更多的专家很难在许多任务上进行泛化。
更多的专家也可能更难以实现收敛。
面
对如此大规模的训练，
OpenAI  相反选择在专家数量上更加保守。

此外，
减少专家的参与也有助于他们的推理基础设施。
当转向混合专家推理架构时，
存在各种困难的权衡。
让我们从法学硕士推理
的基本权衡开始，
然后再讨论  OpenAI  面临的问题以及他们做出的选择。

推理权衡

在开始之前，
顺便说一句，
我们想指出，
我们接触过的每家法学硕士公司都认为  Nvidia  的  FasterTransformer  推理库相当
糟糕，
而  TensorRT  更糟糕。
缺乏采用  Nvidia  模板并对其进行修改的能力意味着人们从头开始创建自己的解决方案。

对于  Nvidia  阅读本文的人来说，
您需要尽快使用此工具进行  LLM  推理，
否则事实上的工具将成为一个开放工具，
可以更轻松地

添加第3方硬件支持。
一波巨模即将到来。
如果推理方面没有软件优势，
无论如何都需要手写内核，
那么AMD的MI300就有更
大的市场和其他硬件。

大型语言模型的推理存在  3  个主要权衡，
这些权衡沿着批量大小（服务的并发用户数量）
维度和所使用的芯片数量进行。

1.延迟 模型必须以合理的延迟做出响应。
人们不想在等待其输出在聊天应用程序中开始流式传输之前等待很多秒。
预填充
（输入令牌）
和解码（输出令牌）
需要不同的时间来处理。

2.吞吐量 模型必须每秒输出一定数量的令牌。
某处
人类使用时需要每秒大约  30  个令牌。
较低和较高的吞吐量对于各种其他用例来说都是可以的。

3.利用率 运行模型的硬件必须达到高利用率，
否则就太高了
昂贵。
虽然较高的延迟和较低的吞吐量可用于将更多的用户请求分组在一起
Machine Translated by Google

并实现更高的利用率，
但它们却让事情变得更加困难。

LLM  推理就是要平衡两个要点：
内存带宽和计算。
用最简单的术语来说，
每个参数都必须被读取，
并且它有  2  个与之
关联的  FLOP。
因此，
大多数芯片的比率（H100  SXM  只有  3TB/s  的内存带宽，
但  FP8  的  2,000  TFLOP/s）
在批量大小为  1  时
的推理完全不平衡。
如果只服务  1  个用户，
则批量大小1，
那么每次令牌生成的每个参数中流式传输所需的内存带宽将主导推
理时间。

计算时间几乎为零。

为了有效地将大型语言模型扩展到许多用户，
批量大小必须超过  1。
多个用户分摊参数读取成本。
例如，
在批量大小为  
256  或  512  时，
读入的每个内存字节有  512  FLOP/s  或  1024  FLOP/s。
此比率与  H100  的内存带宽与  FLOPS  更接近。
这
有助于实现更高的利用率，
但随之而来的缺点是延迟更高。

许多人认为内存容量是  LLM  推理的主要瓶颈，
因为模型的大小可以适应许多芯片，
但这是不正确的。
虽然大型模型需要多
个芯片来进行推理，
并且更高的内存容量会导致它们安装在更少的芯片上，
但实际上最好使用比所需容量更多的芯片，
这样
可以降低延迟，
提高吞吐量，
并实现更大的批量尺寸可用于越来越高的利用率。
Machine Translated by Google

Google  在其  PaLM  推理论文中展示了这些权衡。
然而，
值得注意的是，
这是针对像  PaLM  这样的密集模型，
而不是像  GPT‑4  这样的
稀疏模型。

如果应用程序需要尽可能低的延迟，
我们就需要应用更多的芯片，
并以尽可能多的方式对模型进行划分，
以实现盈利。
较小的批量大小通常可以实现较低的延迟，
但较小的批量大小也会导致  MFU  [利用率]  较差，
从而导致每个令
牌的总成本较高（以码片秒或美元计算）。

如果应用程序需要离线推理并且不关心延迟，
则主要目标是最大化每芯片吞吐量（即最小化每个令牌的总成本）。
增加批大小是最有效的，
因为较大的批通常会带来更好的  MFU  [利用率]，
但某些对于小批大小无效的分区策略会随着
批大小变大而变得高效。

更多的芯片和更高的批量大小是最便宜的，
因为利用率提高，
但这也引入了第三个变量，
即网络时间。
一些跨芯片分割模型的方

法对于延迟来说更有效，
但会牺牲利用率。

记忆时间的权重加载部分和非注意力计算时间都与模型大小成正比，
与芯片数量成反比。
然而，
对于给定的分区
布局，
芯片间通信所需的时间随着使用的芯片数量的增加而减少得不太快（或根本不减少），
因此随着芯片数量的增
加，
它成为一个越来越重要的瓶颈。

虽然我们今天只简单讨论它，
但应该注意的是，
随着批量大小和  seqlen  的增长，
KV  缓存的内存需求容量会呈爆炸式增长。

如果应用程序需要生成具有长注意力上下文的文本，
则会大大增加推理时间。
对于具有多头注意力的  500B+  模型，
注
意力  KV  缓存会变得很大：
对于批量大小  512  和上下文长度  2048，
KV  缓存总计  3TB，
是模型参数大小的  3  倍。
每生
成一个令牌，
片上存储器就需要从片外存储器加载一次  KV  缓存，
在此期间芯片的计算核心基本上处于空闲状态。

较长的序列长度对内存带宽和内存容量的影响尤其严重。  OpenAI  的  16k  seqlen  GPT  3.5  Turbo  和  32k  seqlen  GPT  4  价格昂
贵得多，
因为由于内存限制，
它们无法利用更大的批量大小。
较小的批量大小会导致较低的硬件利用率。
此外，
随着序列长度的增加，
KV  缓存会膨胀。  KV  缓存无法在用户之间共享，
因此需要单独的内存读取，
进一步成为内存带宽的瓶颈。
稍后将详细介绍  MQA。

GPT‑4  推理权衡和基础设施
上述所有内容对于  GPT‑4  推理来说都很困难，
但混合专家  (MoE)  的模型架构引入了一系列全新的困难。
每个代币生成前向传
递都可以路由到不同的专家组。
这给在较高批量大小下沿吞吐量、
延迟和利用率轴实现的权衡带来了麻烦。
Machine Translated by Google

OpenAI  的  GPT‑4  有  16  个专家，
每个前向传递有  2  个专家。
这意味着，
如果批量大小为  8，
则为每个专家读取的参数可能仅为批
量大小  1。
更糟糕的是，
这可能意味着  1  位专家的批量大小可能为  8，
而其他专家的批量大小可能为  4  或  1或  0。
每生成一个令
牌，
路由算法都会以不同的方向发送前向传递，
从而导致令牌到令牌延迟以及专家批量大小的显着变化。

推理基础设施是  OpenAI  专家数量少得多的主要原因。
如果他们配备更多数量的专家，
内存带宽将成为推理的瓶颈。  OpenAI  
的推理集群经常达到  4k+  的批量大小，
这意味着即使在专家之间实现最佳负载平衡，
专家的批量大小也只有  ~500。
这需要
大量的使用才能实现。

我们的理解是  OpenAI  在  128  个  GPU  的集群上运行推理。
他们在多个数据中心和地区拥有多个这样的集群。
推理是在8路
张量并行和16路管道并行下完成的。
每个包含  8  个  GPU  的节点只有约  130B  参数，
或者在  FP16  下每个  GPU  小于  30GB，
在  
FP8/int8  下每个  GPU  小于  15GB。
只要所有批次的  KV  缓存大小不会膨胀太大，
推理就可以在  40GB  A100  上运行。

包含不同专家的各个层不会跨不同节点进行分解，
因为这会使网络流量变得太不规则，
并且在每个令牌生成之间重新计算  KV  
缓存的成本太高。
未来  MoE  模型扩展和条件路由的最大困难是如何处理  KV  缓存周围的路由。

层数为  120，
因此很容易在  15  个不同的节点之间进行划分，
但由于第一个节点需要进行数据加载和嵌入，
因此在推理集群的头节
点上放置较少的层是有意义的。
此外，
还有一些猜测性解码的传闻，
我们稍后会讨论，
但我们不确定是否相信它们。
这也可以解释为
什么头节点需要包含如此少的层。

GPT‑4  推理成本
尽管前馈参数仅为  1.6  倍，
但  GPT‑4  的成本是  175B  参数  Davinchi  模型的  3  倍。
这主要是由于  GPT‑4  需要更大的集
群，
而利用率却低得多。

我们认为，
128  个  A100  推断  GPT‑4  8k  seqlen  的每  1k  代币成本为  0.0049  美分，
128  个  H100  推断  GPT‑4  8k  seqlen  
的每  1k  代币成本为  0.0021  美分。
应该指出的是，
我们假设利用率很高，
并保持较高的批量大小。

这可能是一个错误的假设，
因为很明显  OpenAI  有时利用率很低。
我们假设  OpenAI  在低谷时间关闭集群，
并重新调整这些
节点的用途，
以便从尝试各种新技术的较小测试模型的检查点恢复训练。
这有助于保持较低的推理成本。
如果  OfpenAI  不
这样做，
他们的利用率会更低，
我们的成本估计会增加一倍以上。

多查询注意力
Machine Translated by Google

质量保证这是其他人都在做的事情，
但我们想指出  OpenAI  也是如此。
长话短说，
KV  缓存只需要  1  个磁头，
并且可以显着减少内存容
量。
即便如此，
32k  seqlen  GPT‑4  绝对无法在  40GB  A100  上运行，
并且  8k  受到最大批量大小的限制。
如果没有它，
8k  的最大
批量大小将受到显着限制，
达到不经济的程度。

连续配料
OpenAI  实现了可变批量大小和连续批量处理。
这是为了允许一定程度的最大延迟并优化推理成本。
如果您不熟悉这个概念，  
AnyScale的此页面值得一读。

推测性解码
我们从一些可靠的人那里听说  OpenAI  在  GPT‑4  推理上使用推测性解码。
我们不确定我们是否相信它是清楚的。
令牌与令牌延
迟的一般变化执行简单检索任务与更复杂任务时的差异似乎表明这是可能的，
但有太多变量需要了解。
为了以防万一，
我们将在这
里通过使用“通过分阶段推测解码加速  LLM  推理”
中的一些文本并进行一些修改/添加一些颜色来解释它。

使用法学硕士通常分为两个阶段。
首先，  prefill ，
提示通过模型运行，
生成  KV  缓存和第一个输出  logits（可能的  token  输出
的概率分布）。
这通常很快，
因为整个提示可以并行处理。
Machine Translated by Google

第二阶段是解码。
从输出的  logits  中选择一个  token  并将其反馈到模型中，
该模型为下一个  token  生成  logits。
重复此操作，
直
到产生所需数量的令牌。
由于每次必须按顺序对流经计算单元的权重进行解码才能生成单个令牌，
因此当小批量运行时，
第
二阶段的算术强度（即计算的  FLOP/内存带宽的字节）
非常低。
因此，
解码通常是自回归生成中最昂贵的部分。

这就是  OpenAI  的  API  调用中输入令牌比输出令牌便宜得多的原因。

推测性解码的基本思想是使用更小、
更快的草稿模型提前解码多个令牌，
然后将它们作为单个批次输入到预言机模型中。
如果草
稿模型的预测是正确的（更大的模型也同意这一点），
人们可以用单个批次解码多个令牌，
这可以节省大量的内存带宽，
从而为每个
令牌节省时间。

但是，
如果较大的模型拒绝草稿模型预测的标记，
则该批次的其余部分将被丢弃，
算法自然会恢复到标准的逐个标记解码。
推测解
码还可以伴随拒绝采样方案以从原始分布中采样。
请注意，
这仅在带宽成为瓶颈的小批量设置中有用。

推测性解码会牺牲计算带宽。
推测性解码成为有吸引力的性能工程目标有两个关键原因。
首先，
它根本不会降低模型质量。

其次，
它提供的收益通常与其他方法正交，
因为它的性能来自将顺序执行转换为并行执行。

当前的推测方法预测批次的单个序列。
然而，
这不能很好地扩展到大批量或低拔模模型对⻬。
直观上，
两个模型对长连续标记序列达成
一致的概率呈指数级低，
这意味着随着计算强度的扩大，
推测性解码的回报会迅速递减。

我们相信，
如果  OpenAI  使用推测性解码，
他们很可能只将其用于约  4  个令牌的序列。
顺便说一句，
降低  GPT‑4  质量的整个阴谋
可能只是因为他们让预言机模型接受来自推测解码模型的较低概率序列。
另一个旁白是，
有些人推测巴德使用推测性解码，
因为谷歌
会等待整个序列生成后再将其发送给用户，
但我们不相信这种推测是真的。

视觉多模态

视觉多模态功能是  GPT‑4  中最不令人印象深刻的部分，
至少与领先的研究相比是这样。
当然，
目前还没有人将多模式法学硕士
的研究商业化。

它是与文本编码器分开的视觉编码器，
但存在交叉注意力。
我们听说该架构与  Flamingo  类似。
这在GPT‑4的1.8T之上增加了更多
参数。
在仅进行文本预训练之后，
它又使用约  2  万亿个令牌进行了微调。

在视觉模型上，
OpenAI想从头开始训练，
但还不够成熟，
所以他们想从文本开始来规避风险。
Machine Translated by Google

他们训练的下一个模型  GPT‑5  据称将从头开始训练视觉，
并且也能够自行生成图像。
此外，
它还可以处理音频。

这种视觉功能的主要目的之一是让自主代理能够阅读网页并转录图像和视频中的内容。
他们训练的一些数据是联合数据（渲染
的  LaTeX/文本）、
网页屏幕截图、
YouTube  视频：
采样帧，
并围绕它运行  Whisper  以获得转录本。

对于  LLM  的所有这些过度优化，
一件有趣的事情是视觉模型的  IO  成本与文本模型的  IO  成本不同。
在文本模型上，
正如我们在亚
马逊云危机中所描述的那样，
它非常便宜片。
从视觉上看，
数据加载的  IO  高出约  150  倍。
每个标记  600  个字节，
而不是像文本那样  4  个字节。
在图像压缩方面正在进行大量
工作。

这对于硬件供应商来说非常重要，
他们在  2‑3  年后围绕法学硕士的用例和比率优化硬件。
他们可能会发现自己处于一个每个
模型都具有强大的视觉和音频功能的世界。
他们可能会发现他们的架构不太适应。
一般来说，
该架构肯定会发展超过我们今天看到
的当前简化的基于文本的密集和/或  MoE  模型。

/付费内容