GPT-4详细架构技术细节泄漏，训练一次要 6300 万美元
原文来自一篇付费文章，看起来比较靠谱，可以参考一下，不能保证可信度。
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 家使用这种架构训练 LLM 的公司。这是个好架构，但对于扩展来说，它有缺陷。请参见我们之前在 GPT-4 公告之前关于训练成本的讨论，关于从训练成本角度看密集模型即将遇到的 AI 砖墙。在那里，我们揭示了 OpenAI 在 GPT-4 的架构以及现有模型的训练成本方面所做的高级工作。AI 砖墙——密集变压器模型扩展的实际限制，以及 GPT 4 如何突破它
在过去的 6 个月里，我们意识到训练成本是无关紧要的。
当然，表面看起来很疯狂，花费数千万甚至数亿美元的计算时间来训练一个模型，但对这些公司来说，这是微不足道的。这实际上是一个资本支出项目，其中规模越大，效果越好。唯一的限制因素是将这种计算扩展到人类可以得到反馈并修改架构的时间尺度。在未来几年中，像 Google、Meta 和 OpenAI/Microsofi 这样的公司会在价值超过一千亿美元的超级计算机上训练模型。Meta 每年在“元宇宙”上燃烧超过 160 亿美元，Google 每年在各种项目上浪费 100 亿美元，这些项目永远不会有所收获。Amazon 在 Alexa 上损失超过 500 亿美元。加密货币在没有价值的东西上浪费了超过 1000 亿美元。这些公司和社会总体上可以并将花费超过一千亿美元来创建可以训练单一巨大模型的超级计算机。这些巨大的模型然后可以通过各种方式产品化。这项工作将在多个县和公司中复制。这是新的太空竞赛。那些以前的浪费和现在的区别在于，AI 会在短期内从人工助手和自主代理人那里得到实实在在的价值。
AI 扩展的更重要的问题，真正的 AI 砖墙，是推断。目标是将训练计算和推断计算分离。这就是为什么对于任何将要部署的模型，有意义的是训练好过 Chinchilla 最优。这就是为什么你做稀疏模型架构；每个参数在推断过程中并不都被激活。真正的战斗是，将这些模型扩展到用户和代理人的成本太高。推断的成本超过了训练的成本数倍。这就是 OpenAI 在模型架构和基础设施方面的创新目标。对于大型模型的推断是一个多变量问题，其中模型的大小
会让你在密集型模型上倒下。我们已经详细讨论过这个问题，但对于数据中心来说，问题陈述非常相似。快速概述是，设备永远不会有足够的内存带宽，以便大型语言模型达到某种级别的吞吐量。即使他们有足够的带宽，在边缘硬件计算资源的利用率也会非常低。在设备 AI - 双刃剑
在数据中心，在云中，利用率是一切。Nvidia 被赞扬为软件卓越的一半原因是，因为在 GPU 的一代生命周期中，Nvidia 不断更新低级软件，通过更智能地在芯片、芯片之间和内存之间移动数据，将 FLOPS 利用率提高。在大多数当前的使用案例中，LLM 的推断是作为一个实时助手，意味着它必须达到足够高的吞吐量，用户才能真正使用它。人们平均每分钟阅读约 250 个单词，但有些人每分钟阅读的单词数可达到 1000 个。这意味着你需要每秒输出至少 8.33 个标记，但更像是每秒 33.33 个标记以覆盖所有的角落案例。
一个万亿参数的密集模型在数学上无法在最新的 Nvidia H100 GPU 服务器上达到这种吞吐量，因为需要的内存带宽。每生成一个标记，都需要从内存中加载到芯片上。然后将生成的标记输入到提示中，生成下一个标记。此外，还需要额外的带宽来流式传输注意力机制的 KV 缓存。
这个图表假设由于无法融合每个操作，注意力机制所需的内存带宽，和硬件开销等于参数读取的低效率。实际上，即使使用像 Nvidia 的 FasterTransformer 库这样的“优化”库，总的开销还要大。
上面的图表展示了推断 LLM 需要的内存带宽，以达到足以为单个用户服务的吞吐量。它显示，即使是 8x H100 也无法在每秒 33.33 个标记的速度上服务 1 万亿参数的密集模型。此外，8xH100 在每秒 20 个标记的 FLOPS 利用率仍然低于 5%，导致推断成本极高。实际上，有一个推断约束在今天的 8-路张量并行 H100 系统的 ~3000 亿前馈参数左右。然而，OpenAI 正在使用 A100，用一个超过 1 万亿参数的模型，达到人类阅读速度，并且他们以每 1000 个标记只需 0.06 美元的低价格广泛提供。那是因为它是稀疏的，即并非每个参数都被使用。足够的走弯路，让我们来谈谈 GPT-4 的模型架构、训练基础设施、推断基础设施、参数数量、训练数据集构成、标记数量、层次数量、并行策略、多模态视觉编码器，不同工程权衡背后的思考过程，独特实施的技术，以及他们如何缓解与巨型模型推断相关的一些最大瓶颈。
模型架构
GPT-4 的大小是 GPT-3 的 10 倍以上。我们相信它在 120 层中有总共约 1.8 万亿个参数，而 GPT-3 的参数约为 1750 亿个。OpenAI 能够通过使用混合专家 (MoE) 模型来保持成本合理。如果你对 MoE 不熟悉，可以阅读我们 6 个月前关于 GPT-4 广泛架构和训练成本的文章。此外，OpenAI 在他们的模型中使用了 16 个专家，每个 MLP 的参数约为 1110 亿。这些专家中有 2 个在每次前向传递时被路由。虽然文献中大量讨论了选择哪个专家来路由每个标记的高级路由算法，但据说 OpenAI 的 GPT-4 模型的算法相当简单。此外，大约有 550 亿个共享参数用于注意力。
每次前向传递推断（生成 1 个标记）只使用约 2800 亿个参数和约 560 TFLOPs。这与纯粹的密集模型每次前向传递所需的 1.8 万亿个参数和 3700 TFLOP 形成了对比。
数据集组成
OpenAI 在约 13 万亿个标记上训练了 GPT-4。这是有道理的，因为 RefinedWeb 的 CommonCrawl 包含约 5 万亿个高质量标记。供参考，Deepmind 的 Chinchilla 和 Google 的 PaLM 模型分别在约 1.4 万亿个标记和约 0.78 万亿个标记上进行训练。甚至据说 PaLM 2 在约 5 万亿个标记上进行了训练。这个数据集并不是 13 万亿个唯一的标记。相反，由于缺乏高质量的标记，数据集包含多个周期。文本数据有 2 个周期，代码数据有 4 个周期。有趣的是，这远远低于 Chinchilla 的最优，这表明需要在双倍的标记数量上训练模型。这表明网络上缺乏容易获取的标记。有 1000 倍以上的高质量文本标记，甚至更多的音频和视觉，但获取它们并不像网页抓取那样简单。ScaleAI 和内部提供了数百万行的指令微调数据。不幸的是，我们在他们的 RLHF 数据上找不到更多的信息。
预训练阶段的上下文长度（seqlen）为 8k。GPT-4 的 32k seqlen 版本基于预训练后的 8k 进行微调。批量大小在集群上运行的几天内逐渐提高，但到最后，OpenAI 使用的批量大小达到了 6000 万！当然，这“只是”每个专家看到的 7.5 万个标记的批量大小，因为并非所有专家都看到所有标记。
并行策略
跨所有 A100 GPU 并行化的策略至关重要。他们使用了 8 路张量并行，因为这是 NVLink 的限制。除此之外，我们听说他们正在使用 15 路管道并行。理论上，考虑到数据通信与计算时间，这是太多的管道，但如果他们受到内存容量的限制，那就有道理。在纯粹的管道 + 张量并行的情况下，每个 GPU 的参数大约为 30GB，精度为 FP16。一旦你加上 KV 缓存和开销，这在理论上是有道理的，如果 OpenAI 的大部分 GPU 都是 40GB 的 A100。他们可能使用了 ZeRo Stage 1。他们可能使用了块级 FSDP，或者混合共享数据并行。至于为什么他们没有使用全模型 FSDP，可能是因为通信开销较高。虽然 OpenAI 的大多数节点之间有高速网络，但可能不是所有节点之间都有。我们认为至少有一些集群的连接带宽比其他集群低。我们不明白他们如何避免在如此高的管道并行下，每个批次都有大量的泡沫。可能他们只是吞下了成本。
训练成本
OpenAI 的 GPT-4 训练 FLOPS 为约 2.15e25，在约 25,000 个 A100 上进行了 90 到 100 天的训练，MFU 率约为 32% 到 36%。这个极低的利用率部分原因是由于有大量的失败需要从检查点重新启动。上述提到的泡沫成本极高。另一个原因是在那么多的 GPU 之间进行全规约是非常昂贵的。这尤其是我们怀疑集群实际上是一群小的集群，它们之间的网络连接非常弱，即集群的部分之间是 800G/1.6T 的非阻塞连接，但这些部分只在 200G/400G 下连接。如果他们在云中的成本约为每小时 1 美元每 A100，那么这个运行的训练成本就会达到约 6300 万美元。这忽略了所有的实验、失败的训练运行和其他成本，如数据收集、RLHF、员工等。由于这些因素，实际成本要高得多。此外，它意味着你有人购买芯片/网络/数据中心，吸收 Capex，并租给你。今天，预训练可以用约 8192 个 H100 在约 55 天内完成，成本为 2150 万美元，每小时 H100 成本为 2 美元。注意，我们相信到今年底将有 9 家公司拥有更多的 H100。并非所有这些公司都会将所有的 H100 用于单次训练，但那些这样做的公司将拥有更大的模型。Meta 到今年底将拥有超过 100,000 个 H100，但其中很大一部分将分布在他们的数据中心进行推断。他们最大的单个集群仍然会超过 25k 个 H100。到今年底，许多公司将拥有训练 GPT-4 大小模型的计算资源。
混合专家权衡
MoE 是在推断过程中减少参数数量的同时，还能增加参数数量的一种好方法，这是在每个训练标记中编码更多信息所必需的。这是必要的，因为获取足够的高质量标记是极其困难的。如果 OpenAI 真的尝试去做 Chinchilla 最优，他们将不得不在 2x 的标记上进行训练。话虽如此，OpenAI 做出了多种权衡。例如，MoE 在推断上非常难处理，因为并非每个部分在每次生成标记时都被使用。这意味着当其他部分被使用时，部分可能处于休眠状态。当为用户提供服务时，这真的会损害利用率。研究人员已经证明，使用 64 到 128 个专家比 16 个专家能够获得更好的损失，但这只是研究。有多个理由选择更少的专家。OpenAI 选择 16 个专家的一个原因是，更多的专家在许多任务上难以推广。更多的专家也可能更难以实现收敛。在如此大的训练运行中，OpenAI 选择在专家数量上更为保守。此外，使用更少的专家也有助于他们的推断基础设施。当转向混合专家推断架构时，有各种各样的困难权衡。让我们从 LLMs 的推断的基本权衡开始，然后再讨论 OpenAI 面临的问题和他们做出的选择。
推断权衡
在开始之前，我们想指出，我们与之交谈的每一个 LLM 公司都认为 Nvidia 的 FasterTransformer 推断库相当糟糕，TensorRT 更糟。无法修改 Nvidia 的模板的能力意味着人们从头开始创建自己的解决方案。对于在 Nvidia 阅读这篇文章的你们，你们需要尽快开始为 LLM 推断工作，否则默认将成为一个开放的工具，它可以更容易地添加第三方硬件支持。一波巨大的模型
即将到来。如果没有软件优势
在推断上，而且 anyway 需要手写内核，那么 AMD 的 MI300 和其他硬件就有一个更大的市场。在批大小（同时服务的用户数量）维度和使用的芯片数量上，对大型语言模型的推断有 3 个主要权衡。
延迟 - 模型必须在合理的延迟时间内做出响应。人们不想在聊天应用程序中等待几秒钟才开始接收到他们的输出。预填充（输入标记）和解码（输出标记）需要不同的时间进行处理。
吞吐量 - 模型必须输出一定数量的标记每秒。人类需要的大约在 30 个标记每秒左右。对于各种其他用例，更低和更高的吞吐量也是可以的。
利用率 - 运行模型的硬件必须实现高利用率，否则成本会太高。虽然更高的延迟和更低的吞吐量可以用来将更多的用户请求组合在一起，从而达到更高的利用率，但它们使得事情变得更加困难。LLM 推断都是关于平衡 2 个主要点，内存带宽和计算。以最简化的术语来说，每个参数必须被读取，并且与其相关联的有 2 个 FLOPs。因此，大多数芯片的比率（H100 SXM 只有 3TB/s 的内存带宽，但 FP8 的 FLOPS 为 2000 TFLOP/s），对于批大小 1 的推断来说是完全不平衡的。如果只有 1 个用户被服务，批大小为 1，那么每个标记生成所需的从内存中读取每个参数的内存带宽就会主导推断时间。计算时间几乎为零。要有效地将大型语言模型扩展到许多用户，批大小必须超过
多个用户可以分摊参数读取成本。例如，在批大小为 256 或 512 的情况下，每字节内存的读取有 512 FLOP/s 或 1024 FLOP/s。这个比率更接近 H100 的内存带宽与 FLOPS。这有助于达到更高的利用率，但带来的是更高的延迟。许多人指出内存容量是 LLM 推断的主要瓶颈，因为需要多少个芯片来推断大模型，但这是不正确的。虽然大模型需要多个芯片进行推断，而且更高的内存容量导致 它们适合更少的芯片，但实际上最好使用比所需的容量更多的芯片，这样可以降低延迟，增加吞吐量，并使用更大的批量大小以提高利用率。
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）引入了一整套新的困难。每个令牌的生成前向传递可以被路由到一组不同的专家。这在高批次大小的吞吐量、延迟和利用率的权衡中引入了新的问题。OpenAI 的 GPT-4 有 16 个专家，每次前向传递路由到 2 个专家。这意味着如果有一个批大小为 8，每个专家的参数读取可能只有批大小为 1。更糟的是，这可能意味着一个专家可能有一个批大小为 8，而其他专家可能为 4 或 1 或 0。每次生成令牌，路由算法会将前向传递发送到不同的方向，导致令牌到令牌延迟以及专家批大小的显著变化。推断基础设施是 OpenAI 选择更少数量的专家的主要原因之一。如果他们选择了更多的专家，内存带宽会更大地阻碍推断。OpenAI 在他们的推断集群中经常达到 4k+ 的批量，这意味着即使专家之间的负载平衡最优，专家只有约 500 的批量。这需要大量的使用来实现。我们理解的是，OpenAI 在一个由 128 个 GPU 组成的集群上运行推断。他们在多个数据中心和地理位置都有这样的集群。推断是在 8-way 张量并行和 16-way 管道并行下完成的。每个包含 8 个 GPU 的节点只有大约 130B 的参数，或者在 FP16 下每个 GPU 少于 30GB，FP8/int8 下少于 15GB。只要所有批次的 KV 缓存大小不会膨胀太大，就可以在 40GB 的 A100 上运行推断。包含各种专家的各个层并没有被分解到不同的节点上，因为这将使网络流量过于不规则，而且在每个令牌生成之间重新计算 KV 缓存将花费太大。任何未来的 MoE 模型扩展和条件路由的最大困难是如何处理围绕 KV 缓存的路由。层计数为 120，所以很容易将其分配给 15 个不同的节点，但是因为第一个节点需要做数据加载和嵌入，所以将更少的层放在推断集群的头节点上是有意义的。此外，有一些关于推测解码的谣言，我们稍后将讨论，但我们不确定是否相信它们。这也可以解释为什么头节点需要包含这么少的层。
GPT-4 推理成本
尽管 GPT-4 的前向参数只有 1.6 倍，但 GPT-4 的成本是 175B 参数的 Davinchi 模型的 3 倍。这主要是由于 GPT-4 需要更大的集群和更低的利用率。我们认为，对于 128 个 A100s 来说，推断 GPT-4 8k seqlen 的成本是每 1k 令牌 0.0049 美分，对于 128 个 H100 来说，推断 GPT-4 8k seqlen 的成本是每 1k 令牌 0.0021 美分。应当注意，我们假设了适度的高利用率，并保持批次大小高。这可能是一个错误的假设，因为很明显 OpenAI 有时的利用率非常低。我们假设 OpenAI 在低谷小时将集群关闭，并将这些节点重新用于从检查点恢复训练，以便于较小的测试模型尝试各种新技术。这有助于降低推断成本。如果 OpenAI 不这样做，他们的利用率会更低，我们的成本估计会翻一番以上。
多查询注意力
MQA 是其他所有人都在做的事情，但我们想指出 OpenAI 也在做。长话短说，只需要 1 个头，就可以大大减少 KV 缓存的内存需求。即使这样，32k seqlen 的 GPT-4 肯定无法在 40GB 的 A100 上运行，8k 在最大批次大小上受到限制。没有它，8k 在最大批次大小上将被大大限制，到达不经济的地步。
连续批处理 OpenAI 实现了变量批大小和连续批处理。这是为了允许某种程度的最大延迟以及优化推断成本。如果你不熟悉这个概念，AnyScale 的这个页面值得一读。
推测解码
我们从一些可靠的人那里听说 OpenAI 在 GPT-4 推理上使用了推测解码。我们不确定我们是否相信它。一般的令牌到令牌延迟的变化和在执行简单检索任务 vs 更复杂任务时的差异似乎表明这是可能的，但是有太多的变量无法确定。以防万一，我们将在这里使用 "加速 LLM 推理的分阶段推测解码" 中的一些文本并做一些修改/添加一些色彩来解释它。使用 LLMs 通常分为两个阶段。首先，预填充，提示符通过模型生成 KV 缓存和第一个输出 logits（可能令牌输出的概率分布）。这通常很快，因为整个提示符可以并行处理。第二阶段是解码。从输出的 logits 中选择一个令牌并将其反馈到模型中，该模型会产生下一个令牌的 logits。这一过程重复，直到产生所需的令牌数。因为解码必须顺序进行，每次生成一个令牌时都需要通过计算单元传递权重，所以在小批次运行时，这个第二阶段的算术强度（即，FLOP 的计算 / 内存带宽的字节）非常低。因此，自回归生成的解码通常是最昂贵的部分。这就是为什么在 OpenAI 的 API 调用中，输入令牌比输出令牌便宜得多。
推测解码的基本思想是使用一个更小、更快的草案模型提前解码几个令牌，然后将它们作为一个单独的批次输入到 oracle 模型中。如果草案模型对其预测正确 - 更大的模型同意 - 可以用一个批次解码几个令牌，这可以大大节省每个令牌的内存带宽，因此节省时间。然而，如果大模型拒绝了草案模型预测的令牌，那么剩余的批次将被丢弃，算法自然地恢复到标准的令牌逐个解码。推测解码也可能伴随着一个拒绝抽样方案，从原始分布中抽样。注意这只在带宽是瓶颈的小批次设置中有用。推测解码以计算换带宽。有两个关键原因使得推测解码是一个吸引人的性能工程目标。首先，它完全不会降低模型质量。其次，它提供的收益通常与其他方法正交，因为其性能来自于将顺序执行转换为并行执行。当前的推测方法为批次预测一个序列。然而，这在大批次大小或低草案模型对齐时并不适用。直观地说，两个模型对长连续序列的令牌的一致性的概率是指数级低，这意味着推测解码在扩展其算术强度时有快速减少的收益。我们相信，如果 OpenAI 在使用推测解码，他们可能只使用它来解码约 4 个令牌的序列。另一方面，整个降低 GPT-4 质量的阴谋可能只是因为他们让 oracle 模型接受来自推测解码模型的较低概率序列。另一方面，有些人猜测 bard 使用推测解码，因为 Google 等待整个序列生成后才将其发送给用户，但我们不认为这种猜测是真的。
视觉多模态
视觉多模态功能是 GPT-4 中最不令人印象深刻的部分，至少与领先的研究相比。当然，没有人将这些研究商业化到多模态 LLMs 。它是一个与文本编码器不同的视觉编码器，但有交叉注意力。我们听说架构类似于 Flamingo。这在 GPT-4 的 1.8T 之上增加了更多的参数。它是在仅文本预训练之后，再用另一个约 2 万亿的令牌进行微调的。在视觉模型上，OpenAI 想从头开始训练，但它还不够成熟，所以他们想通过从文本开始来降低风险。他们训练的下一个模型，GPT-5，将从头开始进行视觉训练，并且也能自己生成图像。此外，它还将能够处理音频。这种视觉能力的主要目的之一是用于能够读取网页和转录图片和视频中的内容的自主代理。他们训练的一些数据是联合数据（渲染的 LaTeX/text）、网页截图、youtube 视频：抽取帧，并在其周围运行 Whisper 来获取转录。关于所有这些对 LLMs 的过度优化的有趣的事情是，视觉模型的 IO 成本与文本不同。在文本模型上，它非常便宜，正如我们在 Amazon Cloud Crisis 文章中描述的那样。在视觉上，
数据加载是 ~150x 更高的 IO。每个令牌 600 字节，而不是文本中的 4。在图像压缩上正在做很多工作。这对于正在优化 2-3 年后的使用情况和 LLMs 比例的硬件供应商非常相关。他们可能会发现自己生活在每个模型都有强大的视觉和音频能力的世界中。他们可能会发现他们的架构适应性差。总的来说，架构肯定会超越我们现在看到的基于当前简化的基于文本的密集和/或 MoE 模型。