面向大规模AI在线推理的可靠性设计

作者 宋翔

概览

在AI项目中，大多时候开发者的关注点都集中在如何进行训练、如何调优模型、如何达到满意的识别率上面。但对于一个完整项目来说，通常是需求推动项目，同时，项目也最终要落到实际业务中来满足需求。

对于常用的AI训练和机器学习工具如TensorFlow，它本身也提供了AI serving工具TensorFlow Serving。利用此工具，可以将训练好的模型简单保存为模型文件，然后通过的脚本在TensorFlow Serving加载模型，输入待推理数据，得到推理结果。

但与拥有较固定计算周期和运行时长的AI训练不同，AI推理的调用会随着业务的涨落而涨落，经常出现类似白天高、夜间低的现象。且在大规模高并发的节点需求情况下，常规的部署方案，明显无法满足此类需求，此时需要使用更专业的AI推理模型和扩缩容、负载均衡等技术完成预测推理。

UAI Inference采用类似Serverless的架构，通过请求调度算法、定制扩缩容策略，自动完成AI请求的负载均衡，实行节点动态扩容和回收，可提供数万的AI在线推理服务节点。

某AI在线推理一天内的请求访问情况

AI推理（Inference）的在线执行有两大关键因素：一是通过GPU/CPU对数据进行快速决策，二是对访问请求的实时响应。下图为某一AI在线推理场景24小时内的资源使用情况，其中，横轴为时间、纵轴为用户资源请求量，橙色线现表示资源配置情况。

凌晨00:00-8:00点，用户基本处于睡眠状态，此刻的资源请求较少，闲置资源较多；8:00以后，手机等设备使用量增多，推理访问请求逐渐上升；直至中午，设备访问达到高峰，请求量超过设定的资源量，系统纺问出现延迟；之后在线使用量降低，部分资源又将闲置……

可以看到，一天内不同的时间段，访问量会随着用户作息规律而出现相应的起伏，若是将资源配置设置过小，则会导致计算资源不足，系统吞吐量变低，致使访问延迟。但若投入过多的配置，又会产生大量的闲置资源，增加成本。

面向大规模的AI分布式在线推理设计与实现

UAI Inference整体架构

为了应对在线推理对实时扩缩容以及大规模节点的需求，UAI Inference在每一台虚拟机上都部署一个AI在线服务计算节点，以类似Serverless的架构，通过SDK工具包和AI在线服务PaaS平台，来加载训练模型并处理推理（Inference）请求。整体架构如下：

SDK工具包：主要负责模型加载。包含接口代码框架、代码和数据打包模板以及第三方依赖库描述模板。用户根据SDK工具包内的代码框架编写接口代码，准备好相关代码和AI模型以及第三方库列表，然后通过打包工具将训练模型进行打包。

任务打包完毕后，系统自动将业务部署在AI在线推理PaaS平台上处理推理请求。这里，平台每个计算节点都是同构的，节点具有相等的计算能力，以保证系统的负载均衡能力。此外，动态扩缩容、分布式容灾等弹性可靠设计也是基于该平台实现。

在线推理实现原理

在实现上，系统主要采用CPU/GPU计算节点来提供推理任务的基础算力，通过Docker容器技术封装训练任务，内置Django Server来接受外部HTTP请求。下图展现了处理请求的简单原理与流程：

在初始化过程中（init）, Django Server会先根据conf.json加载AI Inference模块，然后调用该模块的load_model将AI模型加载到Django Http服务器中；在处理推理请求时，Django服务器会接受外部的http请求，然后再调用execute函数来执行推理任务并返回结果。

这里，采用容器技术的好处是可以将运行环境完全隔离，不同任务之间不会产生软件冲突，只要这些AI服务在平台节点上运行满足延时要求，就可进行在AI线推理服务部署。

功能特性

UAI Inference适用于常见的大规模AI在线服务场景，如图像识别、自然语言处理等等。整体而言，该系统具有以下功能特点：

· 面向AI开发：通过预制的NVidia GPU执行环境和容器镜像，UAI Inference提供基于Docker的Http在线服务基础镜像，支持TensorFlow、Keras、Caffe、MXNet多种AI框架，能快速AI算法的在线推理服务化。

· 海量计算资源：拥有十万核级别计算资源池，可以充分保障计算资源需求。且系统按照实际计算资源消耗收费，无需担心资源闲置浪费。

· 弹性伸缩、快速扩容：随着业务的高峰和低峰，系统自动调整计算资源配比，对计算集群进行横向扩展和回缩。

· 服务高可用：计算节点集群化，提供全系统容灾保障，无需担心单点错误。

· 用户隔离：通过Docker容器技术，将多用户存储、网络、计算资源隔离，具有安全可靠的特性。

· 简单易用：支持可视化业务管理和监控，操作简单。

在线推理的可靠性设计

因为推理请求是随着访问量的变化而变化的，因此，在线推理的可靠性设计，考虑以下几点：1）充足资源池，保证在高并发情况下，系统拥有足够的计算资源使请求访问正常；2）负载均衡：将请求合理的分配到各节点当中；3）请求调度算法：用于计算资源的实时调度；4）性能监控：查看用户访问状态，为系统扩缩容做参考；5）高可用部署：保证在单节点宕机时，系统能够正常运行。

负载均衡

UAI Inference为每个在线服务提供了自动负载均衡能力，当用户提交同构、独立的AI在线推理容器镜像时，平台会根据请求的负载创建多个计算节点，并使用负载均衡技术将请求转发到计算集群中。

如图所示，负载均衡主要包括网络层和转发层。网络层中，同一个交换机（IP）可以接多个后端节点，通过请求调度算法将请求分配到各个计算节点当中。调度算法可以采用Hashing、RR、Shortest Expected Delay等，其中，Hashing适用于长链接请求，Shortest Expected Delay适用于短链接请求。目前，AI Inference采用RR的方式在计算节点间调度请求。整个系统最底层是一个统一的资源池，用以保证充足的计算资源。

动态扩缩容

在实现扩容之前，需要通过监控了解各节点当前的在线推理状态，这里，主要是通过实时收集节点的负载（CPU、内存）、请求的QPS和延时信息，来制定动态的扩容和缩容策略。

系统状态实时监控

此外，AI Inference系统将Http请求、延时和Http返回码实时记录成日志，然后通过数据统计来在图形界面展示Http请求量、延时、成功率等信息。平台会实时收集所有计算节点的stdout数据，并录入日志系统，用户可以通过观察线上运行日志来了解线上运行状态，并根据监控信息自动选择扩容和缩容。

高可用

除了基本的扩缩容和负载均衡，我们也通过将计算节点集群化的方式，提供全系统容灾保障。如下图所示，系统会把整个服务切分成多个set，部署在跨机房的某几个机架或者区域里面，当某一个机房或者set宕机时，其他地区的在线推理处理还在进行。这种方式的好处是当出现单点故障时，其他区域的计算节点能够保证整个在线推理请求的正常执行，避免因单节点故障导致的系统不可用。

总结

本文通过对UAI Inference的实现原理、架构设计以及弹性扩缩容、负载均衡、高可用等可靠策略的介绍，讲解了大规模、高并发在线推理请求时，UCloud的部分解决策略和方案，希望能够抛砖引玉，为其他开发者做AI在线推理部署时带来新的思路。

截止目前，UAI Inference提供了CPU/GPU数万节点的在线推理服务。未来，我们会兼顾高性能在线服务和高性价比的在线服务两个方向，同时提供针对GPU硬件和CPU硬件的优化技术，进一步提升在线服务的效率。同时也会着力于公有云和私有云的结合，后期将会推出私有云的在线推理服务。

作者介绍

宋翔，UCloud高级研发工程师。负责UCloud AI产品的研发和运营工作，曾先后于系统领域顶级会议Eurosys、Usinex ATC等发表论文，在系统体系架构方面具有丰富的经验。