简介
- 大型语言模型（LLM）推理框架已经遇到了“内存墙”，这是一种硬件强加的对内存受限代码的速度限制。这意味着LLM应用程序开发者不需要担心评估不同框架的各种细微差别，他们只需要了解自己系统的内存墙位置，选择一个接近它的框架即可继续。
- 请求/秒和标记/秒的指标可能存在误导性。根据MLPerf基准测试，在服务器和离线场景下的请求/秒数值通常比单流高得多。LLM开发者在选择推理框架时应理解如何计算请求/秒。
- 目前有很多关于量化和稀疏化等推理优化技术的讨论。虽然这些确实是深度学习中最重要的优化手段之一，但它们应该谨慎使用。过度剪枝或量化LLM可能会显著降低准确性，不如一开始就使用较小的模型。
- 我们通常建议使用经过验证的已发布模型以及它们的原始格式。例如，Meta发布的Llama 3.1 8B是采用bfloat16格式且不包含稀疏性的。而Mixtral-8x22B-v0.1则是在bfloat16格式下具有8路稀疏门控混合专家结构。专业团队可能能够更激进地进行量化或剪枝，但我们并不建议大多数用户这样做，因为其难度非常高。
- 我们构建我们的推理引擎时充分考虑到了这些因素。
- 我们的系统运行在AMD MI250和MI300 GPU以及Nvidia H100 GPU上，因此单流的内存墙分别是每秒200个标记、每秒331个标记及每秒209个标记。
- 我们为MLPerf服务器场景进行了优化，因为它提供了最佳的吞吐量并且灵活性最强。我们也可以处理单流和离线情况。
- 我们以有偏见的方式进行量化，在硬件支持加速的情况下选择模型发布的格式，例如MI250上的bfloat16 和MI300X上的float8。
- Lamini支持LLM的内存调优，可以将任何LLM转换为混合大规模专家模型（MoME）。我们的推理引擎无缝加载专家，并以高性能运行这些专家。
为了运行大型语言模型，你需要一个推理框架。有许多流行和新兴的推理框架，比如vLLM、TensorRT-LLM、llama.cpp和llm.c。模型在推理阶段是固定的，因此推理框架通常是基于性能——速度、延迟和吞吐量——或优化方法——量化、稀疏化、快速注意机制、KV缓存分页和推测解码进行竞争的。需要注意的是，准确性是由模型决定而不是由推理框架决定的，这也是为什么这些框架主要依据性能而不是准确性来竞争。在这篇文章中，我们将讨论为什么一些性能比较可能并不如你所期待的那样有用。
大型语言模型（LLM）的推理框架已经遇到了“内存墙”，即硬件施加的对于内存受限代码的速度限制。事实证明，支持LLM的Transformer模型在解码阶段是内存受限的。当一个程序受限于内存时，系统的内存速度决定了其性能。因此，不同的推理框架在同一硬件平台上且具有相同内存的情况下会得到近似相同的性能。
图1：来源
由于所有框架都受同一硬件速度的限制，因此LLM应用开发者面临的选择其实很简单：了解自己的系统的内存墙所在位置，选择一个接近它的框架，然后继续前进。当然，并没有下限表明某软件件到底能有多低效，你需要确保你的推理框架已经被良好地调优，但内存墙设定了一条上限。一旦接近此上限，就完成了任务。
这留给了进一步研究突破LLM推理中的“内存墙”的空间。然而，研究突破可能需要放弃有史以来最成功且最常用的模型之一——Transformer。
什么是内存墙？
内存墙是指处理器速度与内存带宽之间巨大且不断增大的差距。内存墙之所以产生是因为将数据从大容量内存（如HBM3）移动到GPU上的矩阵核心（如MI300x）所需的能量大于通过矩阵核心电路移动数据所需的能量。
图2：图片来源图1展示了内存墙的实际表现。追踪GPU速度的灰色线条增长得比追踪内存带宽的绿色线条更快。注意，图表的尺度是对数的，所以差距比看起来更大且增长速度也更快。
为何Transformer的解码过程受到内存限制？
Transformers在过去十年中已经是最成功的深度学习模型，甚至在视觉领域挑战了卷积神经网络（CNNs）。它们在LLM领域占据主导地位，如Llama 3.1、Claude 3.5、GPT4、Deepseek 和Mistral等。
Transformer的关键创新在于它们训练过程中避免了内存墙，但在推断过程中仍然难以避免。在推断过程中，Transformer使用一种叫做自回归解码(Autoregressive Decoding)的算法，这意味着Transformer必须完全预测出前一个标记才能开始处理下一个标记。例如对于Llama 3.1 400B模型，意味着在其输出每个标记之前，400亿个权重都需要从内存中读取出来。这个操作使得LLM推断在现代系统（如带有HBM的GPU）上受到内存限制。
那么，Transformers是如何在训练过程中避免内存墙的呢？在Transformers出现之前，语言模型中最流行的模型是循环神经网络（RNNs）。RNN用穿越时间的反向传播（BPTT）算法进行训练。这种算法会为训练数据中的每一个标记加载神经网络中的每一个权重。它需要这样做来确定序列中的下一个标记如何受前一个标记的影响。这就直接撞上了内存墙，因为RNN的权重需要反复从内存中重新加载。
Transformers通过使用另一种称为“教师强制教学”（Teacher Forcing）的训练算法打破了训练过程中的内存墙，取代了BPTT。在教师强制教学中，一次性加载大量标记并用于更新LLM的权重。这种方法避免了内存墙，因为处理器可以一次加载一个权重并执行数千次浮点运算。先前的研究者曾试图对RNN实施教师强制教学，但由于准确度显著下降而失败，这是因RNN无法在没有反向传播的情况下确定下一个标记如何受前一个标记影响。
Transformers的关键在于它们依赖注意力机制（这是计算受限而非内存受限的）来确定下一个标记如何受到前一标记的影响。因此，对于变换器而言教师强制教学能够成功，而在RNN中却不能奏效。
不同类型的内存
如果LLM的推理受到内存瓶颈，那么应该可以通过使用更高带宽的内存来加速推理吗？不幸的是，情况并非如此，因为改变内存技术需要硬件的变更。因此，LLM不受推理框架选择或软件级别优化的影响。
Cerebras和Groq公司的推断系统声称在单个请求中的令牌/秒上有巨大的加速。这些加速是真实的，因为这些推断引擎正在使用SRAM（静态随机访问存储器）这种不同的内存技术。
本地SRAM的能量消耗比DRAM低100倍（因此带宽更高），但容量也低得多。典型的CDNA 3核在MI300X上拥有512KB的本地SRAM。在MI300X GPU上的38核（CU）和8块芯片中，总共拥有152MB的本地SRAM。要将单个Llama 3.1 70B模型放入本地SRAM中，需要921个GPU。因此，最新的GPU拥有的SRAM比HBM少1263倍。
GroqChip每处理器集成了更多的本地SRAM，达到了高达230MB。这意味着一个小于600个GroqChip集群即可服务一个Llama 3.1 70B的bfloat16参数模型。Cerebras的晶圆级引擎3.0更进一步，在单个处理器上集成了44GB的SRAM。Cerebras可以通过一个包含四个晶圆级引擎的集群来服务Llama 3.1 70B。
图3: HC2023-K2: Hardware for Deep Learning
当今大多数推理系统使用GPU，这些GPU通常将大语言模型（LLM）参数存储在一种称为高带宽内存（HBM）的内存中，这是由JEDEC内存标准组织定义的标准。像MI300X或H100这样的GPU包含192GB或80GB的第三代高带宽内存（HBMv3），足以在一个GPU中以bfloat16格式存储包含96亿或40亿参数的大语言模型。顾名思义，HBM通过三维堆叠技术和硅通孔实现了比大多数其他类型的DRAM更高的带宽。提高带宽的一种方法是使用更先进的HBM内存，例如从HBM3升级到未来的HBM4。另一种方法是构建具有更多HBM模块的系统，即更多的GPU。
图4: 图片来源
您可以通过改变硬件来极大地加速推理。增加更多的GPU会提高内存带宽。如果您有足够的GPU使其能够将LLM权重移动到本地SRAM中，那么您可以获得巨大的速度提升。但是，是否值得将这么多硬件资源（和金钱）投入到单一模型中以降低推理延迟，则是另一个问题。
MLPerf 场景
MLPerf推理基准测试是一个行业标准，该标准定义了如何衡量深度学习应用（包括大语言模型推理）的性能。
对于大语言模型推理，我们通常考虑的是能够处理LLM请求的大GPU服务器。由于大语言模型较大，因此GPU服务器也较大。MLPerf根据对工业界中最常见的LLM使用情况的调查，定义了四种场景。
图5: MLPerf推理场景大语言模型相关的典型场景包括单流、服务器和脱机模式。
单流
单流意味着有一个用户与大语言模型进行交互。例如，如果您在系统上启用了一个大语言模型推理服务，并且一个用户通过游戏界面与大语言模型对话。这就是单流的情况。首个标记的时间和每秒标记数量会影响这一场景下的用户体验。首个标记的时间影响用户按回车键后等待查看响应的时间。而每秒标记数量则决定了标记呈现到屏幕的速度。每秒标记数量还会影响大语言模型代理形成请求并调用功能或工具所需的时间。
单流运行时直接撞上了内存墙，因为大语言模型一次解码一个标记。因此推理框架别无选择，只能在每个标记中从内存加载整个大语言模型。
服务器
服务器场景是指有一个单一的推理系统接收来自多个用户的并发请求。这一情景给予推理系统更多自由。如果它可以将请求组合成批处理，那么它可以同时为批次中的每个请求处理一个标记。这增加了每次从模型加载权重所需的计算量。如果批次大小足够大，通常为数百或数千个请求，推理系统可以克服内存墙。这也是为什么在服务器场景下，GPU系统的每秒标记数会更高。
脱机模式
脱机模式非常类似于服务器场景。许多请求被同时处理。事实上，所有的请求都被立即呈现在推理系统面前，系统可以以任意方式处理这些请求。这使批量处理变得容易且计划清晰。脱机模式几乎总是受计算能力限制，因为可以最优地选择批量大小。
如果您查看获得胜利的MLPerf提交结果，推理系统在脱机模式下的表现最好，其次是服务器模式。这两种情况下都避免了内存墙，因此它们的每秒标记数会远高于单流模式。由于这种差异巨大，在推理框架报告每秒标记数时，您应该仔细
