推理加速 GPT-3 超越英伟达方案50%！开源方案打通大模型落地关键路径( 二 ) 伴随着深度学习模型规模的指

文章图片
Batch管理流程示意图性能测试
并行推理超线性扩展

文章图片
张量并行可扩展性测试结果展示。硬件环境：8*A100GPU80GB 。由于单设备显存无法满足GPT-3推理需求，此处为GPT-312层的测试结果，设置句长为Padding的1/2 。 Energon-AI八卡并行推理在BatchSize为32时，相比于单卡Pytorch直接推理，可获得8.5倍的超线性加速。运行时推理性能提升50%

文章图片
张量并行运行时系统推理时延对比。硬件环境：8*A100GPU80GB 。设置句长为Padding的1/2 。 GPT-3-24-LayersforTP=2,GPT-3-48-LayersforTP=4 。我们选择高度优化的英伟达FasterTransformerGPT-3作为对比方案。 FasterTransformer在其4.0版本中推出了分布式推理特性，目前支持GPT-3模型的分布式推理，但由于其纯C++代码高度耦合的特点，灵活度与易用性相对较低。此外，对于NLP推理输入句长不同的特点，其分布式推理无冗余计算消除功能。对于GPT-3模型， Energon-AI的运行时系统在BatchSize为1时性能略低于FasterTransformer ，而在BatchSize较大时能够实现超过50%的性能提升。DynamicBatching吞吐量增加30%

文章图片
Dynamicbatching与直接打包batch吞吐量对比。硬件环境：8*A100GPU80GB 。测试使用的模型为GPT-3,测试句长为256以内随机生成， padding策略为batch内最长padding 。我们模拟真实场景下多用户同时发送大量变长推理请求的情况，将我们的动态batch规划方法与传统的FIFO(先入先出)队列打包方法进行了吞吐量对比。由于dynamicbatching的算法缓解了直接padding造成的大量冗余计算问题，在该策略下dynamicbatching的吞吐量实现了34.7%的提升。易用性
Pythonfromgptimportgpt3fromgpt_serverimportlaunch_engine#forenginemodel_class=gpt3model_type="gpt"host="127.0.0.1"port=29400half=Truebackend="nccl"#forparalleltp_init_size=4pp_init_size=2#forserverengine_server=launch_engineserver_host="127.0.0.1"server_port=8020rm_padding=TruePythonenergonaiserviceinit--config_file=gpt_config.py在追求性能的同时， Energon-AI希望保持系统使用的灵活度与易用性，用户仅需自定义【并行模型】、【并行参数】以及【服务请求逻辑】加入到配置文件中，即可启动推理服务。目前，我们提供了最常见的GPT、BERT和ViT模型作为示例，更详尽的教程将会在近期完善。
在构建新的并行模型时， Energon-AI使用Python ，且使用方式与Pytorch相似，有层的概念且初始化与执行逻辑清晰，用户无需考虑内存管理，并行通信等行为。如下代码展示了两层Linear层组成的模型并行运行的完整代码。
PythonclassMLP(nn.Module):def__init__(self,dim,dtype,bias):super().__init__()self.dense_0=Linear1D_Col(dim,dim,dtype=dtype,bias=bias,gather_output=False)self.dense_1=Linear1D_Row(dim,dim,dtype=dtype,bias=bias,parallel_input=True)defforward(self,x):x=self.dense_0(x)x=self.dense_1(x)returnx与之相对，在构建新的并行模型时， FasterTransformer需要使用C++代码并且需要用户自行进行内存管理，定义通信等底层行为组织。受篇幅限制，如下代码展示两层Linear层模型并行运行的内存管理，具体执行，通信的部分代码。除此之外，用户想要代码正确执行，还需要花费大量时间精力对内存管理、执行逻辑、通信行为之间的配合进行调试， C++代码还需要额外编译工作。这些都对用户的并行知识与编程能力提出了严峻挑战。