只需几个小操作,就能让transformer模型推理速度加3.5倍

简介: 只需几个小操作,就能让transformer模型推理速度加3.5倍

你在用 PyTorch 写 transformer 吗?请关注下这个项目。


大多数关于在生产中部署 Transformer 类模型的教程都是基于 PyTorch 和 FastAPI 构建的。两者都是很好的工具,但在推理方面的性能不是很好。

而如果你花费时间进行研究,可以在 ONNX Runtime 和 Triton 推理服务器上构建一些更好的东西。与普通 PyTorch 相比,推理速度通常会快 2 到 4 倍。

如果你想要在 GPU 上获得一流的性能,那么只有一种可能的组合:Nvidia TensorRT 和 Triton。与普通 PyTorch 相比,最终可以获得 5 倍的推理速度。有时它甚至能将推理速度提高 10 倍。

然而 TensorRT 并不是以简单易用著称的,对于 Transformer 模型更是如此,它需要使用特定的技巧。


然后,如果你花一些时间,你可以在 ONNX Runtime 和 Triton 推理服务器上构建一些东西。与普通 Pytorch 相比,你的推理速度通常会快 2 到 4 倍。

近日,Hugging Face 发布了一款名为 Infinity 的商业产品,可以以非常高的性能进行推理(与 PyTorch + FastAPI 部署相比,速度非常快)。不幸的是,根据该公司产品总监的说法,即使对于部署在一台机器上的单个模型,这也是一种付费产品,成本为 2 万美元(没有公开的具体规模信息)。

在 GitHub 上有一个项目 Transformer-deploy,它是一种基于企业级软件的开源替代版:

推理服务器:Nvidia Triton(它接受查询,传输给引擎,并添加对推理有用的功能,如动态批处理或多推理引擎调度)

推理引擎:Microsoft ONNX Runtime(用于 CPU 和 GPU 推理)和 Nvidia TensorRT(仅限 GPU)


我们似乎不费吹灰之力,就可以轻松匹敌极少数 HF Infinity 公共基准。

但事实上,现在仍然有机会进一步加快推理性能,AFAIK 尚未被任何其他 OSS 项目利用:对所有 Transformer 模型的 GPU 量化!

如下是对 Roberta-base、seq len 256、batch 32、MNLI 数据集的测试结果:



执行 GPU 量化需要修改模型源代码(在矩阵乘法等代价高昂的操作上添加一些称为 QDQ 的特定节点),这既容易出错,又很枯燥,并且是件自己给自己挖坑的事。对此,项目作者已经为多个模型手动完成了这项工作。在作者看来,只需修补模型模块抽象语法树(也就是源代码)就可以自动完成这项工作。

从用户端看,在 GPU 上执行模型的基本量化看起来就像这样:


如基准测试结果所示,要获得比普通 PyTorch 快 4.5 倍的模型,在 MNLI 数据集上的准确率需要牺牲 0.4 个百分点,这在许多情况下是一个合理的权衡。如果不希望损失准确度,加速也可以降到 3.2 倍左右。当然,实际应用时的 trade-off 取决于模型、数据集等,但它给出了一个基本概念。与该项目的先前版本相比,这是一个很大的改进。

成倍加速的背后,transformer 的源代码被解析为 AST,像 matmul 或 LayerNorm 这样的算子被一个量化器包装,线性层被它们的量化版本替换,一些不支持的 TensorRT 算子被替换等等。然后还有一部分新的源代码替换。

作者表示,他们目前已经成功测试了 ALBERT、BERT(包括 miniLM)、DistilBERT、Roberta(包括 Camembert、XLM-R、DistilRoberta 等)、Electra 的推理。对于任何可以导出为 ONNX 格式的 transformer 模型,它应该都是开箱即用的,或者只需很少的努力。

关于 CPU 的推理、量化非常容易,且也是由 Transformer-deploy 项目支持的。但是在极端情况下,transformer 的性能会变得非常差(如没有批处理、非常短的序列和蒸馏模型时)。另外如使用基于上代英特尔 CPU 的实例,如 C6 或 M6,与像 Nvidia T4 这样的廉价 GPU 相比,在 AWS 上的性价比会很低。

综上所述,在 Transformer 推理上,除非你对慢速推理感到满意并采用小实例,否则并不推荐使用 CPU 推理。

参考链接:https://www.reddit.com/r/MachineLearning/comments/rr17f9/p_45_times_faster_hugging_face_transformer/

相关实践学习
在云上部署ChatGLM2-6B大模型(GPU版)
ChatGLM2-6B是由智谱AI及清华KEG实验室于2023年6月发布的中英双语对话开源大模型。通过本实验,可以学习如何配置AIGC开发环境,如何部署ChatGLM2-6B大模型。
相关文章
|
传感器 监控
基于STM32的智能农业环境监测系统设计与实现
基于STM32的智能农业环境监测系统设计与实现
1166 0
|
JavaScript
|
9月前
|
人工智能 自然语言处理 并行计算
Chitu:清华核弹级开源!推理引擎3倍提速+50%省卡,国产芯片告别英伟达绑架
Chitu(赤兔)是清华大学与清程极智联合开源的高性能大模型推理引擎,支持多硬件适配,显著提升推理效率,适用于金融、医疗、交通等多个领域。
879 10
Chitu:清华核弹级开源!推理引擎3倍提速+50%省卡,国产芯片告别英伟达绑架
|
6月前
|
API
揭秘电商API接口:商品订单支付全解析
电商API接口种类繁多,涵盖商品、订单、支付、营销、用户等多方面。常见的有:商品相关(如item_get获取详情、item_search搜索商品)、订单相关(如buyer_order_list获取订单列表)、支付接口(处理支付请求)、营销相关(优惠券、促销活动接口)、用户相关(用户信息、授权、地址管理)及其他常用接口(评价、上下架、购物车管理等)。不同平台提供的API可能有所差异,需参考具体文档。
258 0
|
供应链 监控 Java
【开题报告】基于SpringBoot的药店药品管理系统的设计与实现
【开题报告】基于SpringBoot的药店药品管理系统的设计与实现
1289 0
|
存储 NoSQL Java
探索Java分布式锁:在高并发环境下的同步访问实现与优化
【7月更文挑战第1天】在分布式系统中,Java分布式锁解决了多节点共享资源的同步访问问题,确保数据一致性。常见的实现包括Redis的SETNX和过期时间、ZooKeeper的临时有序节点、数据库操作及Java并发库。优化策略涉及锁超时、续期、公平性及性能。选择合适的锁策略对高并发系统的稳定性和性能至关重要。
446 0
|
前端开发 JavaScript 算法
JavaScript制作简版计算器,提供加减乘除功能
JavaScript制作简版计算器,提供加减乘除功能
830 0
|
人工智能 城市大脑 运维
阿里云官网政企业务频道上线!
阿里云官网政企业务频道上线!
441 0
|
存储 关系型数据库 MySQL
MySQL必看表设计经验汇总-上(精华版)
MySQL必看表设计经验汇总-上(精华版)
516 1
|
编解码 网络协议 网络性能优化
VoIP与常见编码的带宽计算
VoIP与常见编码的带宽计算