自2018年以来，BERT、ERNIE、GPT等大规模预训练模型快速发展，在NLP、多模态、生物医学领域取得了巨大突破。超大预训练模型的参数规模从十亿、百亿扩展到千亿、万亿，模型大小突破单卡显存，甚至单机多卡显存限制。大模型具备标注数据更少、模型效果更优、创造能力更强和灵活定制场景等优势。因此，如何将超大预训练模型在生产环境中全量部署，并获得完整的模型效果，成为了业界关注的焦点。
Paddle Serving作为飞桨（PaddlePaddle）开源的服务化部署框架，为了更好解决超大预训练模型在生产环境中全量部署，发布v0.9.0版本——多机多卡分布式推理框架。支持自然语言理解、对话、跨模态生成等大不同种类的大模型结构，实现高速推理，让大模型真正落成应用。
旸谷社区——百度新发布基于文心大模型的创意社区，是Paddle Serving落地的一个典型应用。旸谷社区采用Paddle Serving分布式推理框架部署百亿、千亿级参数超大模型，在该社区成功部署上线了百度自研的4个大模型（智能作画『人人都是艺术家』、智能对话『AI聊吧』、智能创作『歌词生成』和故事生成『AI造梦师』），大模型产业级应用已启动。
「鹏城-百度·文心」（代号ERNIE 3.0 Titan），于2021年12月由百度联合鹏城实验室打造，作为全球首个知识增强千亿大模型，参数规模达到2600亿，是当时全球最大中文的单体模型，同样也采用Paddle Serving多机多卡分布式推理框架，实现其服务化部署。
Paddle Serving框架支持RESTful、gRPC、bRPC等多种协议，接入多种高性能推理引擎，适配多种计算芯片、Docker以及Kubernetes云端环境，提供基于DAG流水线设计，提供同步和异步2种处理框架，包括线程并发、自动批量、请求缓存等高性能并发处理能力。通过以上完善的基础功能、高性能推理能力，Paddle Serving为实现大模型分布式推理奠定了稳固的基础。
针对大模型占用显存量超过GPU单卡显存上限，甚至超过单机多卡显存上限的问题，借鉴分布式训练中模型并行、流水线并行技术，将大模型结构切分成多个子图，每个子图所占显存不超过单卡显存上限，将Tensor计算和不同层计算切分到多个GPU卡上，并插入集合通讯算子实现子图间参数同步。因此，大模型推理计算演绎成基于子图拓扑的多机多卡分布式推理。
Paddle Serving遵循分布式推理技术原理扩展多机多卡分布式能力，设计了第一个版本。如下图所示，由1个Master节点与多个Worker节点构成。Master节点接收用户请求，支持RESTful、gRPC、bRPC协议，基于Serving的有向无环图构建循环控制、子图拓扑管理，拓扑结构中共有4类算子，包括Request、Response、Loop和PP（流水线并行）算子。各算子之间采用内存引用方式交互数据，PP之间实现流水线并行计算，PP内实现模型并行计算，PP算子与Worker使用RPC交互，同机Worker之间采用集合通讯库NCCL同步数据。
该方案由Serving框架控制子图拓扑结构和数据流转，可支持复杂的拓扑，PP之间可实现流水线并行处理。缺点是性能较差，每一轮Loop中Worker间模型并行计算结果要从显存拷贝到内存，返回给Master，再由PP 0下发给PP 1的所有Worker，多次RPC打包、解包操作，非常耗时。
针对上述方案的性能问题，将子图拓扑结构和计算控制逻辑从Serving下移到推理引擎层，每一轮Loop计算结果保存在GPU显存中缓存，无需拷贝Host内存。PP节点之间插入Send、Recv算子，实现高性能数据通讯。新方案在服务启动时，以配置文件方式将子图拓扑结构传入到推理引擎中，每个节点有完整的子图拓扑，当前节点在拓扑结构中位置、相邻节点的IP和Port，并与相邻节点完成握手。Master节点接收用户请求，通过RemoteOp将数据发送到第0层子图的Worker Serving节点上，所有的计算和数据同步控制全部在推理引擎中完成，最终的计算结果由第0层子图的Worker Serving节点返回到Master Serving节点，返回给用户。
通过以上的改进，新框架推理的模型规模越大性能提升越明显，与原方案相比，推理千亿参数ERNIE模型耗时下降70%。
通常，大模型分布式推理优化技术包括动态批量、低精度fp16、TensorRT加速、fused优化和显存Cache等，Paddle Serving不仅采用了这些优化方法，同时也做了改进升级。例如动态批量技术在多个服务化推理框架中均有实现，原理是将多个请求shape维度相同但数值不同的Tensor自动Padding补0对齐，合并成一个大矩阵批量推理，充分利用GPU Kernel多Block、多线程特性，提升计算吞吐。
Paddle Serving动态批量技术的不同之处有2点。
第一，实现复杂的二维变长Tensor自动批量，如Transformer模型结构输入参数有二维变长Tensor。
第二，提出了2种动态批量Padding合并Batch的策略（满足任意1个策略即可合并数据），解决完全Padding导致计算性能的退化的问题。
上述策略数值是经过多种模型测试得到，针对不同的业务场景和请求数据，最佳配置也不相同，在大流量高并发场景效果会更明显。在ERNIE 3.0模型上有25%的吞吐提升。
大模型部署面临的异常问题有3个：硬件故障、网络异常、服务异常等。整体异常处理预案如下：
健康状态检查：定时端口检测&预测结果检测
服务夯住/挂掉：服务重启&supervise拉起
由于一组服务内Master Serving与Worker Serving之间进行通讯交互，服务内异常处理与服务间异常处理有差异的。Master Serving与Worker Serving之间数据通讯采用bRPC半同步机制，等待多个异步操作返回。由Master Serving发起调用并等待多个RPC都结束后再醒来，从而实现广播且同步等待的效果。由于网络或处理异常等原因， 部分Worker Serving节点返回值存在失败的情况，由于每层MP节点的计算结果全部相同，因此，并非全部请求失败时，我们认为请求推理计算是成功的，将第0层MP节点的计算结果返回。对于单卡和单机多卡的故障低成本迁移方案将是下一阶段重点工作。
8*A100-SXM4-40GB, 160 core Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz, 10000Gbps network
单机4卡A100部署百亿生成模型的单请求预测延时是201毫秒，batch=32时，预测耗时是330ms，单机4卡A100部署百亿分类模型的单请求预测延时是17.7ms，不仅满足在线服务的延时要求，与其他分布式推理框架相比具有优势，已具备大规模产业级应用技术条件。
Paddle Serving多机多卡分布式推理方案有良好的通用性和扩展性，能广泛支持不同种类的模型结构，实现高速推理，目前已支撑了如自然语言理解、对话、跨模态生成等大模型的实时在线应用。使用该方案实现大规模服务化部署，让大模型真正落成应用。
伴随中国人工智能走进产业规模化应用的「深水区」，百度在大模型上搭建了适配场景需求的体系，提供全流程支持应用落地的工具和部署方案，让大模型技术赋能产业，让AI助推工业大生产。
在2022WAVE SUMMIT 2022深度学习开发者峰会期间，文心大模型旸谷社区的大模型应用采用Paddle Serving分布式推理框架部署上线，为大模型大规模应用奠定了基础。Paddle Serving多机多卡分布式推理框架的整体部署方案设计复杂，多地多中心、多机多卡组合、多级负载均衡、流量调度和异常故障处理等。整体部署思路如下图所示，与常规服务化部署的差异在于构建分布式部署的结构化思路。
首先，大模型服务是以Group为单位，每个Group由多个Node组成，Node是经过虚拟化的部署容器，每个Node部署Master进程和Worker进程。其次，每个 Group中仅有一个Node部署Master进程，负责接收外部请求流量。可根据模型规模、切分方法、单卡显存和单机的显存数量等因素，决定每个Group上Node的数量，如单机多卡、2机多卡、4机多卡以及8机多卡等。最后，Paddle Serving 提供了多机自适应配置生成与启动脚本，可根据全局配置信息；在相同Group的不同Node自动生成部署配置和启动脚本，简化人工设置，提高了部署效率。
接下来，以百亿参数规模知识问答任务为例，为大家提供一个完整的部署案例，详细讲解Paddle Serving分布式推理的部署方案，详情请点击阅读原文。
⭐ 点击阅读原文获得 ⭐
ERNIE 3.0百亿参数模型部署案例
知识问答任务示例
Paddle Serving官网：
https://github.com/PaddlePaddle/Serving
飞桨文心大模型官网：
https://wenxin.baidu.com/
如果您想同更多开发者或其他用户沟通，欢迎扫码加入Paddle Serving技术交流群，与来自各大企业、高校的服务化部署开发者畅谈技术。
关注【飞桨PaddlePaddle】公众号
获取更多技术内容~
