本文作者：郁昌存 来自京东科技-危险管理中心

一、背景/指标

1） 风控智能化体系建设依赖大量深度学习/机器学习模型进行实时在线的危险辨认、智能决策。要求能够将算法模型疾速部署为在线服务，供决策引擎调用。

2） 风控决策引擎涵盖交易、领取、营销等外围链路，业务场景对决策零碎性能要求极高，均匀tp99<50ms。要求算法模型实时服务在高吞吐量下，仍能满足性能要求。

3）精细化经营大背景下，算法模型服务须要反对大促不降级，且不能通过横蛮加机器形式进步吞吐量。要求从技术及架构层进行改良，对算法模型在线推理性能有质的晋升。

二、平台整体概览

三、产品性能

四、在线推理模块设计方案

本文次要以在线推理服务模块开展解说：

1. 多引擎反对

形象底层，将不同框架实现、自定义脚本语言对立定义为引擎，引擎提供模型load、predict办法。

1）自定义脚本引擎：Python、Groovy。

2）机器学习引擎：Pytorch、Tensorflow、MxNet、XGBoost、PMML、TensorRT。

3）反对引擎动静扩大，接口继承实现load、predict办法即可。

2. 高性能

1) 集成native引擎。

2）优化pyhton执行引擎，改变传统REST接口封装形式，躲避python GIL性能限度。

3）除推理操作外，其余流程全副异步化。

4）CPU精细化管制。

5) GPU实时推理反对。

3. 动静部署

1）基于服务网关反对模型的动静发现、动静路由。

2）治理端配置模型服务信息，后告诉模型计算节点，节点进行模型文件下载、启动加载及服务注册。节点定时查看，校对须要上线/下线的模型。

3）对外提供对立jsf(公司外部RPC服务)/rest接口，基于业务+场景获取对应模型计算节点列表，进行负载转发。

4. 计算资源动静调整

1）对模型计算节点进行资源分组，不同资源组配置不同规格机器资源（基于JDOS可轻松实现）。

2）模型可部署至1到多个分组上，反对单机器多模型混部，通过网关进行路由转发。

5. 灵便输出数据源反对

反对实时加工数据，r2m(公司外部redis集群)、hbase数据源等作为模型输出数据。

五、在线推理模块实现

1. 在线推理服务模块设计

2. 外围性能及实现

1）网关服务注册及路由

将单个模型服务形象为一个独立的微服务，因而可套用微服务技术架构。基于SpringCloud，应用nacos做注册核心、ribbon负载、feign做服务间接口调用。

2）模型动静部署

▪治理端上传模型文件，配置对应的推理引擎，配置服务相干参数。

▪定义模型适配器为translator，Translator接口蕴含preProcess和postProcess办法，别离对应模型的前置和后置数据处理。Translator实现类反对动静编译加载（groovy/字节码），治理端配置时，定义对应模型translator代码，模型加载时进行代码动静编译和注册，如此可实现灵便的配置化形式。

▪服务节点通过事件播送、定时查看机制，更新拉取对应模型文件及适配器代码，执行模型部署。

▪模型部署胜利后，将相干信息注册的服务网关，业务申请通过网关入口进行路由。

▪模型调用过程：

▪对于模型输出数据，在translator前置解决（preProcess）中获取对应数据源/实时加工数据，汇总后进行数据对齐、标准化解决。

▪数据喂给模型，应用对应推理引擎执行推理操作，失去模型输入后果。

▪对于模型输入后果，在translator后置解决（preProcess）中进行模型输入后果解析提取、线性调整、解释加工等。

3）模型服务网关

反对服务动静注册、发现，基于nacos服务发现。

反对模型服务负载、路由，基于feign+ribbon。

反对一键降级/限流，基于nacos配置核心实现。

反对A/BTest、灰度公布，从配置核心获取到服务节点列表后，通过配置规定做对应路由转发即可。

反对实时推理数据回落10K（公司外部大数据集群，反对MQ音讯管道落数），不便算法人员进行模型迭代验证。发送申请出入参数MQ，通过MQ落10K。

4）模型主动迭代

提供python sdk，买通KuAI（公司外部一站式AI模型开发平台），模型推理数据通过MQ回落10K，算法同学通过KuAI提取数据加工，对模型进行迭代训练，验证实现后将训练好模型通过python sdk部署至算法服务平台，替换/灰度提供在线服务。

实现实时推理数据回落模型再训练模型版本迭代 流程自动化，基于此实现风控畛域主动反抗能力。

5）打通风控决策体系

集成风控特色平台，反对食蚁兽（风控自研流式数据加工平台）、flink数据获取，反对hbase、r2m(公司外部redis集群)等数据源数据获取，解决模型输出数据加工问题。

无缝对接天盾风控引擎，反对模型疾速转换为决策引擎原子规定。

3. 在线推理性能优化

1）集成native引擎

集成罕用机器学习框架C++ lib库，通过native调用形式应用C++来执行模型的推理，速度飞快。

如何整合各个lib库，及其间接so包依赖？JDOS 容器化（JDOS是公司外部基于k8s的一体化利用部署平台），一遍趟坑，构建根底环境镜像，解决各种环境依赖，在此之上构建利用镜像。

2）优化python引擎调用形式

因为python GIL（全局解释锁）的存在，同一时刻一个python过程只能应用一个CPU，传统通过flask封装Rest接口包装模型服务形式在高吞吐量场景存在重大性能瓶颈。

通过应用本地过程通信（基于socket），在计算节点启动多个python过程实例，由计算节点（java过程）对立管控python过程，通过多过程来躲避GIL限度，晋升CPU资源利用率。

3）模型计算资源动静分组

因为网关的存在，模型分组就很轻松随便了，建设对应的路由映射关系即可。

能够通过不同模型对CPU/GPU要求不同、计算资源量、IO申请量、内存占用量等进行组合调配，实现机器资源的最大化利用。

4）线程池资源隔离，参数动静配置

针对每个模型服务，建设独立的线程池资源和解决队列，这里很要害，后续很多优化都基于线程池和队列，相干配置（queueSize、batchSize、waitTime、workers等）可在治理端进行配置，模型加载时应用动静配置进行加载。

资源混部下，独立的线程池资源可管制每个模型最大资源使用量，避免单个模型服务流量异样对其余模型服务造成影响。

其次将tomcat线程资源与模型计算资源进行解耦，保障模型的计算不阻塞其余web资源拜访。

5）CPU精细化利用

模型推理服务不同于大多数的业务利用，业务利用多为IO密集型服务，少数业务操作为读写DB/cache等，少数工夫耗费在IO期待，该类利用能够通过适当加大解决线程数来晋升整体吞吐量。

然而模型推理服务为强计算密集型服务，对CPU耗费极大，如果对于每一次推理申请，都创立一个线程来进行进行推理，则会呈现CPU高速运转且线程频繁切换状态，效率必定高不了。如何解决？

5.1. 限度引擎框架CPU应用核数：

比方pytorch框架在推理时默认会应用全副CPU，这种状况对于只有一个训练任务时无疑是最高效的，然而对于在线推理服务来讲，单机每秒解决上千申请量，第一次申请把CPU占满，前面的申请只能和后面申请共享CPU，等待时间片切换调配计算，来回切换上下文解决，效率并不会高。这时候限度单次推理应用单核CPU，其余申请过去后调配到其余闲暇CPU上，缩小线程切换次数，晋升解决效率。数据比照验证，进行CPU核数限度后，tps可晋升5倍以上，且tp99 也可晋升40%以上。

5.2. 减少解决队列，应用独立线程池有序解决每次申请

CPU利用率最高的状态是，同一时刻单核CPU只解决一件事件，当本次申请解决实现后再持续下次申请解决，解决方案如下：

模型推理申请进入后，放入模型独立的解决队列，创立Future对象，由各模型独立的worker线程池来执行模型推理工作。如此，通过管制worker线程数量，尽可能减少上下文切换次数，晋升CPU利用率。

6）深度模型batch聚合

对于深度模型来说，解决卷积运算，执行一次batchSize=10的推理的耗时远小于执行10次batchSize=1的推理耗时。

由此咱们能够通过如上队列+独立线程池，人造的将申请和计算逻辑解耦，于是能够将单条的推理进行batch聚合操作，后果业务场景，通过工夫窗口+batchSize对推理申请进行聚合，即在肯定工夫内，batchSize达到制订数量或等待时间到了，将聚合的多条推理申请一次性送入模型，进行执行推理。失去后果后顺次散发，响应各future。

7）GPU推理减速

▪次要是环境依赖：容器环境下装置gpu驱动，cuda/cudnn。比拟好的实际计划是应用NVIDIA 官网的docker镜像作为根底镜像，在此基础上构建公司外部根底依赖base镜像，再基于base镜像构建环境服务依赖->利用镜像。

8）除模型推理外，其余解决逻辑均异步

▪场景治理/路由规定查问异步化，基于caffine本地缓存，当本地缓存过期时，异步加载更新数据，不会造成穿透及tps抖动。

▪推理后果MQ落10K，MQ发送逻辑异步+批量化。与模型batch聚合相似，MQ音讯推送本地内存队列，开启单个MQ发送线程，拉取队列音讯，满足工夫窗口/batchSize后进行聚合发送。

▪应用异步日志，性能晋升约30%。

六、性能比照（晋升近百倍）

以风控滑块人机辨认CNN模型为例，应用tensorflow引擎，基于老的模型服务平台与迁徙新的算法平台后，接口性能晋升近百倍！


大促多个模型混个压测，整体性能如下：（CPU 使用率55%，满负荷（80%）下可达10W+ tps，tp99 11ms）

七、结语

目前算法服务平台为外部天盾决策引擎、滑块人机辨认以及保险业务等多个场景提供实时模型推理服务，撑持相干模型推理服务大促不降级。

以上为在线推理服务模块整体设计与实现计划，其中细节局部未具体开展，感兴趣局部欢送大家随时沟通交流~