“风控算法服务平台”高性能在线推理服务设计与实现模型进行实时在线风险识别和智能决策。要求算法模型能够快速部署为在线服务，供决策引擎调用。2）风控决策引擎涵盖交易、支付、营销等核心环节。业务场景对决策系统的性能要求极高，平均tp99<50ms。要求算法模型的实时服务在高吞吐量下仍能满足性能要求。3）在精细化运营场景下，算法模型服务需要支持大促不降级，不能通过粗暴加机来增加吞吐量。需要从技术和架构层面进行改进，从质上提高算法模型的在线推理性能。2.平台总体概述3.产品功能4.在线推理模块设计方案模型加载和预测方法。1）自定义脚本引擎：Python、Groovy。2）机器学习引擎：Pytorch、Tensorflow、MxNet、XGBoost、PMML、TensorRT。3)支持引擎动态扩展，接口继承实现load和predict方法。2.高性能1)集成原生引擎。2）优化pyhton执行引擎，改变传统的REST接口封装方式，避免pythonGIL性能限制。3）除推理操作外，其他过程都是异步的。4）CPU精细控制。5)GPU实时推理支持。3.动态部署1)基于服务网关支持模型的动态发现和动态路由。2）管理端配置模型服务信息，然后通知模型计算节点，节点下载模型文件，开始加载并注册服务。定期检查节点，检查需要上线/下线的模型。3）对外提供统一的jsf（公司内部RPC服务）/rest接口，根据业务+场景获取对应模型计算节点列表，进行负载转发。4.计算资源的动态调整1)对模型计算节点进行资源分组，在不同的资源组中配置不同规格的机器资源（基于JDOS可以轻松实现）。2）模型可以部署到一个或多个组，支持单机混合多个模型，通过网关进行路由转发。5、灵活的输入数据源支持支持数据的实时处理，r2m（公司内部redis集群），hbase数据源等作为模型输入数据。五、在线推理模块的实现1.在线推理服务模块的设计2.核心功能及实现1)网关服务注册与路由将单一模型服务抽象为独立的微服务，从而可以应用微服务技术架构。基于SpringCloud，使用nacos作为注册中心，ribbon加载，feign作为服务间接口调用。2)模型动态部署?管理端上传模型文件，配置相应的推理引擎，配置业务相关参数。?将模型适配器定义为翻译器。Translator接口包括preProcess和postProcess方法，分别对应模型的数据处理前后。Translator实现类支持动态编译加载（groovy/bytecode）。在配置管理端时，定义相应的模型翻译器代码，在加载模型时动态编译注册代码，实现灵活的配置方式。?服务节点通过事件广播和定期检查机制更新拉取相应的模型文件和适配代码，并执行模型部署。?模型部署成功后，向服务网关注册相关信息，业务请求将通过网关入口进行路由。?模型调用流程：?对于模型输入数据，在翻译器预处理（preProcess）中获取对应的数据源/实时处理数据，汇总后进行数据对齐标准化。?数据被馈送到模型，由相应的推理引擎进行推理运算，得到模型的输出结果。?对于模型输出结果，在翻译器后处理（preProcess）中，对模型输出结果进行分析提取、线性调整、解释处理等。3）模型服务网关支持服务的动态注册和发现，基于nacos服务发现。支持模型服务加载和路由，基于feign+ribbon。支持一键降级/限流，基于nacos配置中心。支持A/BTest和灰度发布。从配置中心获取服务节点列表后，可以通过配置规则进行相应的路由转发。支持实时推理数据fallback10K（公司内部大数据集群，支持MQ消息管道dropcount），方便算法人员迭代验证模型。发送请求进出参数MQ，通过MQ掉10K。4）提供pythonsdk进行模型自动迭代，打通KuAI（公司内部一站式AI模型开发平台），模型推理数据通过MQ回落10K，算法同学通过KuAI抽取数据进行处理，迭代训练模型，以及验证完成后，将训练好的模型通过pythonsdk部署到算法服务平台，替换/灰度提供在线服务。实现实时推理数据回退模型再训练模型版本迭代过程的自动化，并在此基础上实现风控领域的自动化对抗能力。5）打通风控决策系统，集成风控特性平台，支持anteater（风控自研流数据处理平台）、flink数据采集，支持hbase、r2m（公司内部redis集群）等数据源数据获取，解决Model输入数据处理问题。与天盾风控引擎无缝对接，支持模型快速转化为决策引擎的原子规则。3.在线推理性能优化1)集成原生引擎集成通用机器学习框架C++lib库，使用C++通过原生调用执行模型推理，速度非常快。如何集成各种lib库及其间接so包依赖？JDOS容器化（JDOS是公司内部基于k8s的集成应用部署平台），反复搭建基础环境镜像，解决各种环境依赖，应用镜像构建在其之上。2）优化python引擎的调用方式由于pythonGIL（GlobalInterpretationLock）的存在，一个python进程一次只能使用一个CPU，传统的通过flask封装Rest接口封装模型服务的方式性能严重高吞吐量场景中的瓶颈。通过本地进程通信（基于sockets），在计算节点上启动多个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对象，每个模型的独立工作线程池执行模型推理任务。这样，通过控制工作线程的数量，可以尽可能减少上下文切换的次数，提高CPU利用率。6)DepthModelBatchAggregation对于深度模型，在batchSize=10的情况下执行一次卷积运算比在batchSize=1的情况下执行10次推理花费的时间要少得多。所以，我们可以通过上面的队列+独立线程池，自然而然的将请求和计算逻辑解耦，这样我们就可以对单个inference进行批量聚合操作。从而在业务场景中通过timewindow+batchSize聚合推理请求。在一定时间内，当batchSize达到指定数量或等待时间到时，将聚合的多个推理请求一次性发送给模型执行推理。得到结果后，依次分发，响应每个future。7）GPU推理加速主要看环境：在容器环境安装gpu驱动，cuda/cudnn。比较实用的方案是使用NVIDIA官方的docker镜像作为基础镜像，基于其构建公司内部基础镜像，并基于基础镜像构建环境服务依赖->应用镜像。8）除了模型推理，其他处理逻辑都是异步的。场景管理/路由规则查询是异步的。基于caffine本地缓存，当本地缓存过期时，会异步加载更新的数据，不会造成穿透和tps抖动。?推理结果MQ下降10K，MQ发送逻辑为异步+批处理。类似于模型批量聚合，将MQ消息推送到本地内存队列，启动单个MQ发送线程，拉取队列消息，满足时间窗口/batchSize后进行聚合发送。?使用异步日志，性能提升约30%。6、性能对比（近100倍提升）以风控滑块人机识别CNN模型为例，采用tensorflow引擎，基于老模型服务平台，迁移到新算法平台，界面性能有提升了近100倍！推动多机型混合压测，整体表现如下：（CPU使用率55%，满载下可达10W+tps（80%），tp9911ms）7.结论目前的算法服务平台为天盾内部决策引擎、滑块人机识别、保险业务等多个场景提供实时模型推理服务，并支持相关模型推理服务不降级。以上是在线推理服务模块的总体设计和实现方案，具体内容不再赘述。欢迎有兴趣的小伙伴随时交流~
