共计 4059 个字符，预计需要花费 11 分钟才能阅读完成。
本文作者：郁昌存 来自京东科技 - 危险管理中心
一、背景 / 指标
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）
七、结语
目前算法服务平台为外部天盾决策引擎、滑块人机辨认以及保险业务等多个场景提供实时模型推理服务，撑持相干模型推理服务大促不降级。
以上为在线推理服务模块整体设计与实现计划，其中细节局部未具体开展，感兴趣局部欢送大家随时沟通交流~