使用PyTorch II的新特性加快LLM推理速度

本文涉及的产品
智能开放搜索 OpenSearch行业算法版,1GB 20LCU 1个月
实时数仓Hologres,5000CU*H 100GB 3个月
实时计算 Flink 版,5000CU*H 3个月
简介: Pytorch团队提出了一种纯粹通过PyTorch新特性在的自下而上的优化LLM方法,包括:

Torch.compile: PyTorch模型的编译器

GPU量化:通过降低精度操作来加速模型

推测解码:使用一个小的“草稿”模型来加速llm来预测一个大的“目标”模型的输出

张量并行:通过在多个设备上运行模型来加速模型。

我们来看看这些方法的性能比较:

作为对比,传统的方式进行LLaMA-7b的推理性能为25tokens/秒,我们来看看看这些方法对推理性能的提高。

使用新的编译器和分配(76 TOK/S):

Pytorch分析了cpu限制的性能问题。这意味着编译开销是提高效率的首要目标。

所以使用编译器将较大的区域编译为预编译状态,每个操作的CPU调用数量会减少。这意味着该包装器现在可以在没有间隙的情况下执行,如下所示。

代码也非常简单:

 torch.compile(decode_one_token, mode="reduce-overhead", fullgraph=True)

当生成更多令牌时,kv-cache会增长,每次缓存增长时都需要重新分配和复制(昂贵的计算)。声明大缓存以允许最大大小。

在预填充阶段需要分别编译两种策略。整个提示被动态处理,令牌被解码为上面所示的代码。保持这些策略并行可以进一步优化。单独使用这两种策略,可以获得3倍的推理性能提高。

消除内存瓶颈,(102 TOK/S)

以静态方式为缓存分配最大内存时,会使内存问题变得更糟,因为我们上面只是让CPU计算更加高效,比如缓存肯定会加大内存的使用。

优化内存的最简单方式就是量化。量化试图将权重和计算转换为Int8甚至Int4——这将矩阵的大小减少了4 - 16倍,从而在矩阵操作期间大量节省内存。

如果有72亿个参数需要处理,每个权重需要2字节(fp16)来保存;我们可以计算每秒生成100个令牌所需的带宽。这意味着,要以每秒100个令牌的速度运行推理,我们需要处理总计1.4TB的内存吞吐量。A100的理论上限为2Tb/s,这意味着使用72%的带宽(没有瓶颈),A100可以轻松地每秒运行100个令牌。这取决于你的GPU,如果你是4090呢,大家可以计算一下,4090具有1008GBPS的内存带宽,基本上就是少了一半还要少一些。

重构问题(157.4 TOK/s)

假设对于要生成的每个新单词,要一次又一次地加载和处理所有标记。在自回归世代中我们不需要序列依赖。我们可以使用草稿模型和验证模型(缓慢但准确)并行生成下8个令牌,作为8个副本来验证生成。与验证器不匹配的草稿模型输出将被丢弃。

根据Pytorch文档,它不会降低生成文本的质量。实验也证明了这一点。当运行codellam - 34b + codellam - 7b时,能够在生成代码时获得2倍的token /s提升。当使用Llama-7B + TinyLlama-1B时,在token /s中获得1.3倍的提升。

Int4 (202 TOK/s)

从浮点数变为Int8可以减少内存带宽,我们可以通过将其降低到Int4来测试极限(最小值为-2147483648)。最大值为2147483647)。考虑到INT的范围仍然从负到正十亿,有足够的细微差别,在获得额外提升推理速度的同时,不会失去太多的准确性。

把上面所有的东西结合起来(240 TOK/s)

当所有上述方法一起使用时,由于不同策略的协同作用,还会带来额外的21%的收益。

总结

可以看到,我们最终获得了10倍左右的提高 25 TOK/s -》 246 TOK/s

使用Llama-7B,我们能够使用编译+ int4量化+推测解码达到246 tok/s。通过llama-70B,我们还可以将张量并行性提高到80 tok/s。这些都接近或超过SOTA性能数字!

本文代码:

https://avoid.overfit.cn/post/58c4ba8ee4f546ca81744c50733e46d9

作者:Dr. Mandar Karhade, MD. PhD

目录
相关文章
|
27天前
|
机器学习/深度学习 自然语言处理 测试技术
CoT神话破灭,并非LLM标配!三大学府机构联手证实,CoT仅在数学符号推理有用
【10月更文挑战第17天】链式思维(CoT)曾被认为是大型语言模型(LLM)激发推理能力的关键方法,但最新研究显示,CoT仅在数学和符号推理任务中有效,其他任务中效果不明显。加州大学伯克利分校、斯坦福大学和卡内基梅隆大学的联合研究打破了CoT作为LLM标配的神话,为重新评估LLM的推理能力提供了新视角。
32 1
|
5月前
|
机器学习/深度学习 缓存
Block Transformer:通过全局到局部的语言建模加速LLM推理
Block Transformer是一种优化自回归语言模型推理效率的新架构,通过块级自注意力来平衡全局和局部依赖,提高吞吐量。模型包含嵌入器、块解码器和令牌解码器,其中块解码器处理全局依赖,令牌解码器处理局部细节。这种方法减轻了KV缓存的延迟和内存开销,尤其是在长序列处理中。实验显示,尽管Block Transformer参数量增加,但推理速度显著提升,尤其是在大块长度和优化的组件比例下,实现了性能与速度的平衡。
312 7
|
14天前
|
机器学习/深度学习 监控 PyTorch
深度学习工程实践:PyTorch Lightning与Ignite框架的技术特性对比分析
在深度学习框架的选择上,PyTorch Lightning和Ignite代表了两种不同的技术路线。本文将从技术实现的角度,深入分析这两个框架在实际应用中的差异,为开发者提供客观的技术参考。
34 7
|
13天前
|
人工智能 自然语言处理
重要的事情说两遍!Prompt复读机,显著提高LLM推理能力
【10月更文挑战第30天】本文介绍了一种名为“问题重读”(Question Re-reading)的提示策略,旨在提高大型语言模型(LLMs)的推理能力。该策略受人类学习和问题解决过程的启发,通过重新审视输入提示中的问题信息,使LLMs能够提取更深层次的见解、识别复杂模式,并建立更细致的联系。实验结果显示,问题重读策略在多个推理任务上显著提升了模型性能。
31 2
|
23天前
|
JSON 人工智能 算法
探索LLM推理全阶段的JSON格式输出限制方法
文章详细讨论了如何确保大型语言模型(LLMs)输出结构化的JSON格式,这对于提高数据处理的自动化程度和系统的互操作性至关重要。
|
30天前
|
机器学习/深度学习 自然语言处理 测试技术
CoT神话破灭,并非LLM标配!三大学府机构联手证实,CoT仅在数学符号推理有用
【10月更文挑战第16天】近期,加州大学伯克利分校、斯坦福大学和卡内基梅隆大学联合研究发现,链式思维(CoT)方法在数学和符号推理任务中表现优异,但在其他类型任务中效果不明显。这一研究打破了CoT作为大型语言模型(LLM)标配的神话,为重新审视LLM的推理能力提供了新视角。
27 2
|
2月前
|
人工智能 Prometheus 监控
使用 NVIDIA NIM 在阿里云容器服务(ACK)中加速 LLM 推理
本文介绍了在阿里云容器服务 ACK 上部署 NVIDIA NIM,结合云原生 AI 套件和 KServe 快速构建高性能模型推理服务的方法。通过阿里云 Prometheus 和 Grafana 实现实时监控,并基于排队请求数配置弹性扩缩容策略,提升服务稳定性和效率。文章提供了详细的部署步骤和示例,帮助读者快速搭建和优化模型推理服务。
170 7
使用 NVIDIA NIM 在阿里云容器服务(ACK)中加速 LLM 推理
|
2月前
|
人工智能 Prometheus 监控
使用NVIDIA NIM在阿里云ACK中加速LLM推理
介绍在阿里云ACK集群上结合AI套件能力快速部署NVIDIA NIM模型推理服务,同时提供全面的监控指标和实现弹性伸缩。
使用NVIDIA NIM在阿里云ACK中加速LLM推理
|
2月前
|
编解码 定位技术 计算机视觉
多模态LLM视觉推理能力堪忧,浙大领衔用GPT-4合成数据构建多模态基准
【9月更文挑战第2天】浙江大学领衔的研究团队针对多模态大型模型(MLLM)在抽象图像理解和视觉推理上的不足,提出了一种利用GPT-4合成数据构建多模态基准的方法。该研究通过合成数据提高了MLLM处理图表、文档等复杂图像的能力,并构建了一个包含11,193条指令的基准,涵盖8种视觉场景。实验表明,这种方法能显著提升模型性能,但依赖闭源模型和高计算成本是其局限。论文详细内容见:https://arxiv.org/pdf/2407.07053
79 10
|
4月前
|
机器学习/深度学习 PyTorch 编译器
Pytorch的编译新特性TorchDynamo的工作原理和使用示例
PyTorch的TorchDynamo是一个即时编译器,用于优化动态图执行,提高运行效率。它在运行时分析和转换代码,应用优化技术,如操作符融合,然后编译成高效机器码。通过一个包含特征工程、超参数调整、交叉验证的合成数据集示例,展示了TorchDynamo如何减少训练时间并提高模型性能。它易于集成,只需对现有PyTorch代码进行小改动,即可利用其性能提升。TorchDynamo的优化包括动态捕获计算图、应用优化和编译,适用于实时应用和需要快速响应的场景。
76 11