CN112069205B

CN112069205B - 用于业务应用的处理方法、装置、智能工作站和电子设备

Info

Publication number: CN112069205B
Application number: CN202011069395.2A
Authority: CN
Inventors: 苑辰
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2020-09-30
Filing date: 2020-09-30
Publication date: 2024-05-10
Anticipated expiration: 2040-09-30
Also published as: CN112069205A

Abstract

本申请公开了一种用于工作流的处理方法，涉及人工智能技术领域，可用于机器学习和深度学习、云计算和云平台、计算机视觉、自然语言处理、语音交互等领域。具体实现方案为：确定预定义的多个业务应用；基于多个业务应用，生成至少一个业务任务，其中每个业务任务中包含多个业务应用中的多个数据源和执行计划都相同的业务应用；以及对每个业务任务中包含的业务应用进行批量控制。

Description

用于业务应用的处理方法、装置、智能工作站和电子设备

技术领域

本申请涉及人工智能技术领域，可用于云计算和云平台等领域，更具体地，涉及一种用于业务应用的处理方法、装置、智能工作站、电子设备和存储介质。

背景技术

随着人工智能技术的不断发展，人工智能服务开始向各行业渗透。例如，各行业开始在各个环节引入人工智能服务，导致人工智能服务的创新快速呈现碎片化、场景化的趋势。

发明内容

本申请提供了一种用于业务应用的处理方法、装置、电子设备以及存储介质。

根据第一方面，提供了一种用于业务应用的处理方法，包括：确定预定义的多个业务应用；基于上述多个业务应用，生成至少一个业务任务，其中每个业务任务中包含上述多个业务应用中的多个数据源和执行计划都相同的业务应用；以及对上述每个业务任务中包含的业务应用进行批量控制。

根据第二方面，提供了一种用于业务应用的处理装置，包括：确定模块，用于确定预定义的多个业务应用；生成模块，用于基于上述多个业务应用，生成至少一个业务任务，其中每个业务任务中包含上述多个业务应用中的多个数据源和执行计划都相同的业务应用；以及控制模块，用于对上述每个业务任务中包含的业务应用进行批量控制。

根据第三方面，提供了一种电子设备，包括：至少一个处理器；以及与上述至少一个处理器通信连接的存储器；其中，上述存储器存储有可被上述至少一个处理器执行的指令，上述指令被上述至少一个处理器执行，以使上述至少一个处理器能够执行本申请实施例的方法。

根据第四方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，包括：上述计算机指令用于使上述计算机执行本申请实施例的方法。

根据第五方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现本申请实施例的上述方法。

根据本申请实施例提供的技术方案，针对共用数据源的多套业务逻辑，可以进行合并，即在一个业务任务中创建多个应用实例，实现批量控制多套业务逻辑的目的。

应当理解，本部分所描述的内容并非旨在标识本申请的实施例的关键或重要特征，也不用于限制本申请的范围。本申请的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本申请的限定。其中：

图1A示例性示出了根据本申请实施例的系统架构；

图1B示例性示出了根据本申请实施例的应用场景；

图1C示例性示出了根据本申请实施例的智能工作站的框图；

图2A示例性示出了根据本申请实施例的用于工作流的处理方法的流程图；

图2B和图2C示例性示出了根据本申请实施例的人脸识别应用和人脸识别工作流的示意图；

图2D示例性示出了根据本申请实施例的AI系统的工作原理图；

图3A示例性示出了根据本申请实施例的用于业务应用的处理方法的流程图；

图3B示例性示出了根据本申请实施例的将多个应用实例合并成一个业务任务的示意图；

图3C示例性示出了根据本申请实施例的批量处理多个应用实例的原理图；

图4示例性示出了根据本申请实施例的用于算子服务的处理方法的流程图；

图5A示例性示出了根据本申请另一实施例的用于算子服务的处理方法的流程图；

图5B示例性示出了根据本申请实施例的部署算子服务的示意图；

图5C示例性示出了根据本申请实施例的生成服务镜像的示意图；

图5D～5F示例性示出了根据本申请实施例的操作、算子服务和容器之间的三种组合关系的示意图；

图5G示例性示出了根据本申请实施例的模型混部的示意图；

图6A示例性示出了根据本申请再一实施例的用于算子服务的处理方法的流程图；

图6B示例性示出了根据本申请实施例的流量调度的示意图；

图7A示例性示出了根据本申请实施例的用于工作流的处理装置的框图；

图7B示例性示出了根据本申请实施例的用于业务应用的处理装置的框图；

图7C示例性示出了根据本申请实施例的用于算子服务的处理装置的框图；

图7D示例性示出了根据本申请另一实施例的用于算子服务的处理装置的框图；

图7E示例性示出了根据本申请再一实施例的用于算子服务的处理装置的框图；

图8是可以实现本申请实施例的方法和装置的电子设备。

具体实施方式

以下结合附图对本申请的示范性实施例做出说明，其中包括本申请实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本申请的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

在实现本申请实施例的过程中，发明人发现相关技术中存在如下问题：随着人工智能服务开始渗透到各个行业中，各行业在各个环节引入人工智能服务时，都是各自根据各个环节的实际应用场景单独开发一套AI业务服务的，导致人工智能服务的创新快速呈现碎片化、场景化的趋势。

对此，本申请实施例提供了一套比较完整的AI系统，可以克服上述相关技术中存在的诸如人工智能服务的创新呈现碎片化、场景化的缺陷。

需要说明的是，在本申请实施例中，该AI系统例如可以包括：智能工作站(AI工作站)，用于工作流、业务应用、算子服务、算力资源等的处理方法。

以下将结合适于该AI系统的系统结构、应用场景以及实现该方案的示意性实施例详细阐述本AI系统。

图1A示例性示出了根据本申请实施例的系统架构。

如图1A所示，该AI系统的系统架构100A包括：智能工作站110、应用中心模块120、任务中心模块130、数据接入模块140、工作流引擎150、算力资源管理模块160、租户用户管理模块170、日志管理模块180和数据共享模块190。

简单而言，智能工作站110包括组件集市、用户界面和扩展端口等。组件集市用于提供各类应用组件，包括但不限于逻辑组件、算子组件、业务组件、告警组件、统计组件、数据共享组件等组件。用户界面用于供用户基于组件集市提供的各类应用组件针对各种特定应用场景自定义各种对应的业务应用。扩展端口用于接收外部输入的AI模型文件或算子服务，使得智能工作站110能够通过推理服务框架并基于该扩展端口接收的AI模型文件或算子服务生成对应的算子组件来丰富和更新智能工作站110内的组件集市。

应用中心模块120用于对用户在智能工作站110内定义的各种业务应用进行管理。应用中心模块120支持将智能工作站110产出的业务应用与数据接入模块140接入的数据整合为独立的人工智能应用定义模板；支持应用版本管理、应用描述、应用类型、默认参数配置和登记等；可以提供统一的AI应用管理服务，支持用户快速加载应用。数据接入模块140将各种数据源产生的数据接入AI系统，以便作为各应用实例的数据输入。任务中心模块130，用于对通过智能工作站110自定义的业务应用和由应用中心模块120管理的业务应用进行处理和管理，同时在每个业务任务内基于相互关联的数据源、业务应用和执行计划生成对应的工作流实例，并将生成的工作流实例发送至工作流引擎150进行处理。工作流引擎150用于对各工作流实例进行处理，并将处理结果存入对应的数据库。

算力资源管理模块160用于部署各算子服务，从而为工作流引擎150处理工作流实例提供算力支持。在算力资源管理模块160中可以划分多个资源组，不同的资源组可以提供给不同的租户使用，以便在各租户之间实现资源隔离。租户用户管理模块170用于对针对各租户以及各租户内的用户以及针对各租户分配的资源组进行配置和管理。由此，在本申请实施例中，可以以一套人工智能平台(AI系统)批量化地将AI算子服务提供给不同的业务单元(不同的业务部门，对应于不同的租户)，从而降低企业内部各个业务单元的AI系统的建设成本和使用成本。

日志管理模块180用于管理该AI系统中产生的所有日志。

数据共享模块190用于对外共享上述数据库中存储的数据。

此外，该系统架构100A还可以包括：系统统计模块和其他模块(图1A中没有示出)。系统统计模块用于针对组件集市、应用中心模块120、任务中心模块130、数据接入模块140进行数据统计。

与传统云平台需要各自扩张建设不同，本申请实施例提供的用于AI系统的云平台可以实现算力资源、算子服务、应用服务的共享和互通，因而可以实现算力资源和数据资源的集约化发展。

图1B示例性示出了根据本申请实施例的应用场景。

在车辆抓拍场景中，通常需要先检测车型，再对不同的车型进行属性提取和特征提取，其中有些车型如四轮车还需要进行OCR文字识别；之后，还需要分别依次执行图片存储、ABF入库和属性/小图推送处理。并且有些车型如四轮车在ABF入库后通常还需要执行人脸识别的相关操作。

通过本申请实施例提供的AI系统，可以通过组件拼接自定义出车辆抓拍应用，并由此生成如图1B所示的车辆抓拍工作流。如图1B所示，该工作流100B包括：start(开始)节点，end(结束)节点，switch和parallel等逻辑节点，车型检测节点，针对四轮车的OCR节点、提属性节点和提特征节点，针对三轮车的提属性节点和提特征节点，针对摩托车的提属性节点和提特征节点，以及针对四轮车的存图节点、ABF入库节点和属性/小图推送节点，针对三轮车的存图节点、ABF入库节点和属性/小图推送节点，针对摩托车的存图节点、ABF入库节点和属性/小图推送节点，以及针对四轮车的人脸识别的提属性节点、提特征节点、存图节点和ABF入库节点。

应该理解，在本申请实施例中，工作流中的不同任务节点对应于业务应用中的不同应用组件。

根据本申请的实施例，本申请提供了一种智能工作站。

图1C示例性示出了根据本申请实施例的智能工作站的框图。

如图1C所示，该智能工作站110可以包括组件集市111和用户界面112。

组件集市111，用于提供多种应用组件。

用户界面112，用于供用户基于组件集市111提供的多种应用组件自定义各种业务应用。其中在各种业务应用中可定义多个应用组件和多个应用组件之间的连接关系。并且在各种业务应用中定义的多个应用组件中包括至少一个算子组件。

需要说明的是，在本申请实施例中，组件集市111提供的应用组件可以包括但不限于以下各类组件：逻辑组件、算子组件(AI算子组件)、业务组件、告警组件、统计组件、数据共享组件等。

进一步，每类组件均可以包括至少一种组件。示例性的，上述逻辑组件可以包括但不限于以下各种组件：顺序组件、并行组件、并发组件、跳过组件、终止组件、条件执行组件等。示例性的，上述算子组件可以包括但不限于以下各种组件：视觉目标检测组件、视觉目标分类组件、视觉目标特征提取组件、视觉视频分类组件、视觉像素分割组件、视觉光学字符识别组件(OCR组件)、语音识别组件、语音合成组件等。示例性的，上述业务组件可以包括但不限于以下各种组件：抓拍去重组件、目标位置去重(目标位置，即一段时间内无变化的位置)组件、位置相对关系描述(如A、B之间的位置关系描述，包括但不限于：A与B之间的相对距离、A与B的相对位置(如上、下、左、右、内、外等)等的关系描述)组件等。示例性的，上述告警组件可以包括但不限于以下各种组件：密度告警组件、跨线告警组件、属性告警组件、流量告警组件、时长告警组件、关键词告警组件等。示例性的，上述统计组件可以包括但不限于以下各种组件：密度统计组件、流量统计组件、时长统计组件等。示例性的，上述数据共享组件可以包括但不限于以下各种组件：数据持久化组件、数据推送组件、消息队列组件、数据缓存组件等。

在本申请实施例中，针对特定应用场景，尤其是新出现的应用场景，用户可以少开发甚至不开发任何代码逻辑，而是直接从组件集市110中选取已有的各种应用组件进行拼接，从而快速地自定义出一套完整的业务逻辑(业务应用)。

与相关技术中需要针对不同的应用场景分别定制对应的业务逻辑，导致对于新出现的应用场景，无法利用已有的应用组件，尤其是无法利用已有的算子组件快速地定义出与当前应用场景匹配的业务逻辑相比，通过本申请实施例，由于智能工作站中设置有组件集市和用户界面，因而在出现新的应用场景时，用户可以直接选用组件集市中提供的算子组件快速地定义出与当前应用场景匹配的业务逻辑。此种情况下，用户(开发者)无需从上层到下层做全新的逻辑代码开发和适配，因而可以提高工作效率，同时还可以提高各已有算子组件的复用率。

作为一种可选的实施例，该智能工作站还可以包括：扩展端口，用于接收外部输入的AI模型文件或算子服务。其中该智能工作站可以通过推理服务框架并基于外部输入的AI模型文件或算子服务，生成对应的算子组件。

需要说明的是，通过本申请实施例提供的技术方案，软件开发者不再是孤军奋战，而是可以深度参与社区建设(智能工作站建设)，与其他软件开发者一起实现人工智能技术的创新。示例性的，每个企业中的任何业务部门的软件开发者都可以将自己编写的AI模型文件输入智能工作站，从而注册成对应的算子组件。

在一个实施例中，可以通过扩展端口直接将AI模型文件输入上述智能工作站，然后在该智能工作站先通过推理服务框架生成对应的算子服务，再注册成对应的算子组件。在另一个实施例中，也可以先基于AI模型文件在外部生成对应的算子服务，再通过扩展端口直接将算子服务输入上述智能工作站，从而在该智能工作站内注册成对应的算子组件。

需要说明的是，在本申请实施例中，注册算子组件(即注册算子服务)时登记的注册信息可以包括但不限于：算子组件的名称、标识、类型、版本号，算子服务的输入参数类型、输出参数类型和配置信息，算子服务的算力配额(包括配额上限和下限)，等等。其中算子服务的算力配额可以在注册时通过预测得到。在预测算子服务的算力配额的过程中，可以针对算子服务开启不同的线程数，然后记录每个算子服务副本(不同副本开启的线程数不同)所需要的算力配额(包括但不限于实例数、QPS、CPU占比、GPU占比等)。此外，算子服务的配置信息包括针对算子服务配置的原始字段。在本申请实施例中，注册算子组件时登记的注册信息还可以包括算子组件的各原始字段与各标准字段之间的映射关系。

此外，需要说明的是，在本申请实施例中，智能工作站内的应用组件不仅可以增加，而且还可以删除、修改和更新。并且，算子服务的配置信息是可以修改的，因而本申请实施例对已实现的执行逻辑，具有再定义的能力，即对于已实现的执行逻辑的具有细节微调的能力。

通过本申请实施例，提供了一个综合的、可扩展的AI平台(AI系统)，该平台可以接收外部传入AI组件，并将其注册为本平台的共享组件，能够以平台化的方式来支持对AI需求的灵活扩展和迭代，因而可以支持持续的、可发展的人工智能技术的创新。并且，通过本申请实施例，通用的执行逻辑可以以组件的形式注册在智能工作站内，因而可以最大可能地复用共享组件，并且针对新的应用场景可以通过这些共享组件以最小的成本、最快的速度拼接出与新应用场景匹配的业务应用。

根据本申请的实施例，本申请提供了一种用于工作流的处理方法。

图2A示例性示出了根据本申请实施例的用于工作流的处理方法的流程图。

如图2A所示，该用于工作流的处理方法200A可以包括操作S210～S240。

在操作S210，获取用户自定义的业务应用。在一个实施例中，可以获取用户通过上述智能工作站自定义的业务应用。其中在用户自定义的业务应用中，定义了多个应用组件和多个应用组件之间的连接关系，多个应用组件可以包括至少一个算子组件。

在操作S220，基于该业务应用，预生成对应的工作流。其中该业务应用中定义的多个应用组件中的每个应用组件对应于该工作流中的一个任务节点，该多个应用组件之间的连接关系对应于工作流中的多个任务节点之间的数据流向。

在操作S230，针对该工作流中的每个任务节点，进行目标节点校验，其中该目标节点包括以下至少一项：上游节点、下游节点。

在操作S240，响应于目标节点校验通过，保存工作流。

示例性的，如图2B所示，用户自定义的人脸识别应用包括start组件，人脸检测组件，switch组件，parallel组件1和parallel组件2，提属性组件，提特征组件，parallel组件3和parallel组件4，存图组件，ABF入库组件和end组件；各组件之间的连接关系如图所示。基于如图2B所示的人脸识别应用，预生成的人脸识别工作流如图2C所示，包括start节点(对应于start组件)，人脸检测节点(对应于人脸检测组件)，switch节点(对应于switch组件)，parallel节点1(对应于parallel组件1)和parallel节点2(对应于parallel组件2)，提属性节点(对应于提属性组件)，提特征节点(对应于提特征组件)，parallel节点3(对应于parallel组件3)和parallel节点4(对应于parallel组件4)，存图节点(对应于存图组件)，ABF入库节点(对应于ABF入库组件)和end节点(对应于end组件)；工作流中各节点之间的数据流向如图中带箭头的连线所示。

在本申请实施例中，预生成工作流之后，响应于用户发出保存工作流的请求，可以先校验工作流中各任务节点之间的连接关系是否准确。响应于校验结果表征工作流中所有任务节点之间的连接关系都准确再保存该工作流；否则，响应于校验结果表征工作流中存在任意一个或多个任务节点之间的连接关系不准确，则针对该工作流进行告警。

在一个实施例中，对于相互连接的上游节点和下游节点，可以根据上游节点输出的数据类型与下游节点输出的数据类型来校验该上游节点和该下游节点之间的连接关系是否准确。简单来说，对于相互连接的上游节点和下游节点，如果上游节点输出的数据类型与下游节点输出的数据类型一致，则表征该上游节点和该下游节点之间的连接关系是准确的；否则，如果上游节点输出的数据类型与下游节点输出的数据类型不一致，则表征该上游节点和该下游节点之间的连接关系是不准确的。对于校验出的不准确的连接关系可以通过告警，告知开发人员错误之处。进一步，还可以针对错误之处给出修改建议。

继续参考图2C，如图2C所示的人脸识别工作流，针对图中的start节点，可仅校验该节点输出的数据类型与其下游节点即switch节点输入的数据类型是否一致。针对图中的end节点，可仅校验该节点输入的数据类型与其上游节点即ABF入库节点输出的数据类型是否一致。针对图中除start节点和end节点之外的其他节点，需要同时校验本节点输入的数据类型与其上游节点输出的数据类型是否一致，以及本节点输出的数据类型与其下游节点输出的数据类型是否一致。

与根据业务应用直接生成并保存对应的工作流，导致无法保证工作流中上、下游任务节点之间的连接关系是准确的相比，通过本申请实施例，在保存工作流之前，可以先预生成工作流，并自动校验工作流中相互连接的上、下游任务节点之间的连接关系是否准确。如果工作流中的所有相互连接的上、下游任务节点之间的连接关系都准确，则保存工作流，可以保证所保存的工作流中上、下游任务节点之间的连接关系是准确的；否则，进行告警，以便开发人员能够及时发现当前定义的业务应用的不足/错误之处。

作为一种可选的实施例，该方法还可以包括如下操作。

响应于目标节点校验未通过，针对该工作流进行告警。

作为一种可选的实施例，该方法还可以包括：在保存工作流之后，执行以下操作。

获取被保存的工作流的输入数据。

基于获取的输入数据和该工作流，生成对应的工作流实例。

基于该工作流实例，生成对应的工作流实例图。

在本申请实施例中，在保存工作流之后，用户还可以配置相应的任务，包括配置任务的执行计划、数据源和工作流之间的映射关系。示例性的，对于人脸检测工作流，人脸检测任务的配置信息包括：执行计划“如每周一和周二晚十点执行人脸检测任务”与数据源“指定的摄像头采集的视频流或图片流，或者指定区域内的摄像头采集的视频流或图片流”以及与工作流“如图2C所示的人脸识别工作流”之间的映射关系。因此，在本申请实施例中，可以从任务配置信息中获取与当前工作流关联的数据源，并通过该数据源的数据接收器获取该工作流的输入数据。获取到工作流的输入数据(如视频流)后，可以基于该输入数据对该工作流进行实例化，即生成工作流实例，进而生成该工作流实例示意图，即工作流实例图。

需要说明的是，在本申请实施例中，数据接入模块可以包括多个接收器，不同接收器用于接收来自不同厂商生产的数据采集设备采集的数据。

通过本申请实施例，采用工作流实例图对AI应用的编写逻辑进行可视化展示，可以帮助开发者快速地理解AI应用的内部功能结构。

进一步，作为一种可选的实施例，该方法还可以包括如下操作。

生成工作流实例后，任务中心模块可以通过分发器将生成工作流实例发送至工作流引擎。

工作流引擎通过分发端将分发器分发的工作流实例中的各个任务节点对应的任务分发至队列中。

通过至少一个执行端从队列中获取任务并进行处理。

其中，执行端将各任务的执行结果存储在预设存储器(如内存)中，分发端从预设存储器读取各任务的执行结果并基于读取的执行结果向队列分发后续任务。

示例性的，如图2D所示，可以先在智能工作站110自定义业务应用，然后将自定义的业务应用发送至应用中心模块120。在按照预先设定的执行计划执行业务任务时，由任务中心模块130从应用中心模块120获取与该执行计划关联的业务应用，同时从数据接入模块140(包括接收器141～接收器14n)获取与该执行计划关联的数据源，然后生成工作流实例，并通过分发器131～分发器13n中的任意一个将该工作流实例发送至工作流引擎150。工作流引擎150通过分发端151将接收到的工作流实例中的各个任务节点对应的任务分发至队列152中。然后，由执行端1和执行端2根据自己的计算能力从队列152中获取任务并进行处理。执行端1和执行端2每执行完一个节点任务都会将执行结果存储在内存153中，然后由分发端151从内存153读取各任务的执行结果并基于读取的执行结果向队列分发后续任务。应该理解，工作流实例中，任意子节点对应的任务需要在该子节点的所有父节点对应的任务全部执行完成后才能被放入分发端151分发至队列152中。

需要说明的是，在本申请实施例中，执行端1和执行端2可以是不同虚拟机上的执行端，也可以是同一虚拟机上的执行端。此外，一个虚拟机上可以具有一个或者多个执行端。

通过本申请实施例，由于分发端和执行端之间的数据全部基于内存运行，因而可以减少网络请求带来的系统资源占用。

更进一步，作为一种可选的实施例，该方法还可以包括如下操作。

对上述的至少一个执行端中的每个执行端在单位时间内获取的任务量进行控制。

通过本申请实施例，可以限制各执行端每秒拉取的任务量总数，保证每个执行端的性能，防止其超载。

进一步，在本申请实施例中，对工作流实例图进行可视化展示还可以包括对运行过程中的全部节点的输入参数、输出参数进行可视化展示。此外，在本申请实施例中，在一个完整的业务应用执行过程中，对业务应用所包含的全部组件(如算子组件、业务组件、逻辑组件、其他组件等)还可以进行统一的参数配置，或者还可以根据用户请求切换到各组件的最新版本上运行。

或者，作为另一种可选的实施例，该方法还可以包括如下操作。

控制工作流实例中满足亲和路由的多个任务节点对应的任务都在同一个执行端上处理。

需要说明的是，在本申请实施例中，可以将任务关联性比较强的多个任务节点对应的任务作为满足亲和路由的任务。示例性的，对于人脸检测应用而言，提属性节点和提特征节点对应的任务关联性比较强，因而可以将这两个节点对应的任务作为满足亲和路由的任务，并控制这两个任务在同一个执行端上处理。

通过本申请实施例，在定义上层AI应用调度时，可以选择AI工作流中的一部分任务节点定义为亲和路由任务节点，使得执行端可以有选择性的拉取满足亲和路由的任务来处理，从而可以减少资源占用。

执行工作流实例中各个任务节点对应的任务。

根据任务执行结果记录每个任务节点的输入参数和/或输出参数。

在本申请实施例中，针对任意工作流实例，可以生成如下表格(表1)，用于记录工作流中各任务节点输入参数、输出参数、配置参数等。

表1

通过本申请实施例，可以支持所有工作流实例的实例记录查询以及工作流实例详情查询；还可以支持对已实现的业务逻辑在具体应用场景中每一步执行步骤的执行结果的查看、检验等，可以有效检验实际实现的功能细节或效果是否与预期相一致；还可以支持对具体某一类AI应用的历史执行记录进行统一的检索、筛选，快速定位问题所在；可以实现对AI应用细粒度的统一执行策略管理，以便用户了解各任务节点的输入、输出和配置等。

根据本申请的实施例，本申请提供了一种用于业务应用的处理方法。

图3A示例性示出了根据本申请实施例的用于业务应用的处理方法的流程图。

如图3A所示，该用于业务应用的处理方法300A可以包括操作S310～S330。

在操作S310，确定预定义的多个业务应用。

在操作S320，基于该多个业务应用，生成至少一个业务任务，其中每个业务任务中包含该多个业务应用中的多个数据源和执行计划都相同的业务应用。

在操作S330，对每个业务任务中包含的业务应用进行批量控制。

在本申请实施例中，针对通过智能工作站自定义的每个业务应用，可以进一步定义该业务应用、数据源和执行计划之间的映射关系。对于数据源和执行计划都相同的多个应用实例可以合并在一个业务任务(即批量任务)中执行。

示例性的，如图3B所示，车辆检测任务300B中，四轮车检测任务310、三轮车检测任务320和摩托车检测任务330等三个应用实例的数据源相同，都是针对某路口采集的车辆抓拍视频流，并且这三个应用实例的执行计划也相同，都是每周一和周二晚十点到晚十二点进行车辆检测，因而这三个应用实例可以合并为一个业务任务执行。

如图3B所示，该车辆检测任务300B包括：start(开始)节点，end(结束)节点，switch和parallel等逻辑节点，车型检测节点301；其中的四轮车检测任务310包括针对四轮车的OCR节点311、提属性节点312和提特征节点313、存图节点314、ABF入库节点315和属性/小图推送节点316；其中的三轮车检测任务320包括针对三轮车的提属性节点321和提特征节点322、存图节点323、ABF入库节点324和属性/小图推送节点325；其中的摩托车检测任务330包括针对摩托车的提属性节点331和提特征节点332、存图节点333、ABF入库节点334和属性/小图推送节点335。

在一个实施例中，任务中心模块可以根据用户自定义的任务配置信息，快速在每个业务应用与对应的数据源和执行计划之间建立映射关系，并将数据源和执行计划相同的多个应用实例(多种应用实例)合并在一个业务任务(即批量任务)中，然后以批量模式统一开启、关闭和配置批量任务中的所有应用实例。此外，在本申请实施例中，在批量任务内部支持按照每个设备单元的最小粒度管理应用实例的开启和关闭状态；同时支持在批量任务中对具体应用实例的独立管理。

应该理解，传统的AI系统(如AI视觉系统)，仅能针对特定的场景单独制定一套专用的AI执行逻辑(AI业务应用)。并且传统的AI系统对来自同一个设备(即数据源)的数据输入只能匹配一套AI执行逻辑，无法灵活切换给不同的AI执行逻辑。因而对于传统的AI系统，在一个业务任务中只能对一种AI应用实例执行批量启、停及配置操作，不支持将一个应用场景中的多种应用实例合并在一个业务任务中同时执行批量启、停和配置操作。

与传统的AI系统不同，本申请实施例中，AI系统可以提供多种已实现的应用组件，外部开发人员也可以将自己开发的算子组件共享到该AI系统中，因而针对新出现的应用场景，可以从AI系统中选择相应的应用组件进行灵活拼接，从而自定义完成一套执行逻辑(业务应用)。并且，该AI系统可以进行业务应用合并，即可以将数据源和执行计划都相同多个应用实例合并在一个业务任务中。因而该AI系统对来自同一个设备(即数据源)的数据输入可以灵活匹配给不同的AI执行逻辑，并且支持将一个应用场景中的多种应用实例合并在一个业务任务中同时执行批量启、停和配置操作。

作为一种可选的实施例，该方法还可以包括：在上述的多个业务应用中存在至少两个业务应用需要在底层调用相同的算子服务的情况下，控制至少两个业务应用复用算子服务。

示例性的，如图3B所示，四轮车检测任务310包括提属性节点312和提特征节点313、存图节点314、ABF入库节点315和属性/小图推送节点316；三轮车检测任务320包括针对三轮车的提属性节点321和提特征节点322、存图节点323、ABF入库节点324和属性/小图推送节点325；摩托车检测任务330包括针对摩托车的提属性节点331和提特征节点332、存图节点333、ABF入库节点334和属性/小图推送节点335。因此，四轮车、三轮车和摩托车检测任务可以在底层复用提属性、提特征、存图、ABF入库和属性/小图推送等算子服务。

应该理解，传统的AI系统(如AI视觉系统)，由于不同的AI执行逻辑(AI业务应用)都是针对特定的场景专门单独制定的，因而传统的AI系统对运行在同一个设备上的多个AI业务应用，即使上层引用了相同的AI执行逻辑，那么也无法通过策略在底层复用算子服务，造成性能损失。

与传统的AI系统不同，本申请实施例中，AI系统支持多个业务应用在底层复用算子服务，因而可以节省算力资源的开支，提高算力资源的性能(包括软件资源，如响应次数)。

进一步，作为一种可选的实施例，控制上述的至少两个业务应用复用算子服务，可以包括：控制该至少两个业务应用复用算子服务的同一服务镜像。

由于同一个算子服务下可以注册多个服务镜像，因而在一个实施例中，在存在多个业务应用在底层复用相同的算子服务的情况下，可以控制该多个业务应用在底层复用同一算子服务的不同服务镜像或者相同服务镜像。

通过本申请实施例，在底层复用算子服务时，复用同一算子服务的同一服务镜像与复用同一算子服务的不同服务镜像相比，可以节省硬件算力资源的开支，提高算力资源的性能。

更进一步，作为一种可选的实施例，控制上述的至少两个业务应用复用算子服务的同一服务镜像，可以包括：在针对该至少两个业务应用中的每个业务应用，服务镜像的输入数据相同的情况下，控制服务镜像执行一次并向至少两个业务应用中的每个业务应用返回执行结果。

示例性的，业务应用1和业务应用2能够在底层复用算子服务a，并且算子服务a下注册有服务镜像a₁至服务镜像an，那么控制业务应用1和业务应用2优先复用算子服务a的同一服务镜像(如服务镜像a₁)。在业务应用1和业务应用2复用算子服务a的服务镜像a₁的情况下，如果业务应用1先调用并执行服务镜像a₁，业务应用2后调用服务镜像a₁，并且业务应用1调用服务镜像a₁时的输入参数与业务应用2调用服务镜像a₁时的输入参数相同，都是“xxx”，则可以仅在业务应用1调用服务镜像a₁时执行服务镜像a₁的算法逻辑，在业务应用2调用服务镜像a₁时不再执行服务镜像a₁的算法逻辑，而是直接将业务应用1调用服务镜像a₁时的执行结果返回给业务应用2。此外，如果业务应用1和业务应用2同时调用服务镜像a₁，并且业务应用1和业务应用2调用服务镜像a₁时的输入参数相同，都是“xxx”，此种情况下，可以仅对服务镜像a₁执行一次算法逻辑，同时向业务应用1和业务应用2返回执行结果。

通过本申请实施例，在存在多个业务应用复用同一算子服务的同一服务镜像的情况下，并且该多个业务应用调用该服务镜像时的输入参数相同，则可以仅对该服务镜像执行一次算法逻辑，直接共享该服务镜像的执行结果即可。

或者，作为一种可选的实施例，该方法还可以包括：针对每个业务任务，在当前业务任务中存在针对不同业务方的至少两个相同的业务应用的情况下，在当前业务任务中合并该至少两个相同的业务应用。

应该理解，在本申请实施例中，相同的业务应用可以为业务逻辑、输入参数、输出参数和配置参数均相同的业务应用。

具体地，在本申请实施例中，可以对多个用户创建的AI应用实例进行任务合并，即如果多个用户同时在相同设备或相同区域上启用同一种AI业务应用的执行任务，那么可以将这些执行任务合并为多个用户名下的同一个任务。

示例性的，如果用户1创建的应用实例1和用户2创建的应用实例2的执行计划和数据源均相同，则应用实例1和应用实例2可以合并在一个任务如任务1中。如果应用实例1和应用实例2的输入参数、输出参数以及配置参数均相同，则应用实例1和应用实例2在任务1中可以合并为一个应用实例如应用实例0，只是应用实例0需要同时挂在用户1和用户2名下。

应该理解，当多个用户在同一个设备上重复创建了同一种应用实例时，如果对这些应用实例进行合并，那么这些应用实例会重复占用资源。

而通过本申请实施例，针对不同用户创建的同一种应用实例进行应用合并，不仅可以简化整个业务任务，而且可以避免同一种应用实例重复占用资源，造成资源紧缺和浪费。

进一步，作为一种可选的实施例，在当前业务任务中合并至少两个相同的业务应用，可以包括：控制至少两个相同的业务应用在底层共用同一应用实例。

通过本申请实施例，针对不同用户创建的同一种应用实例进行应用合并，如在底层共用同一应用实例(工作流实例)，不仅可以在上层简化整个业务任务，而且在底层可以避免同一种应用实例重复占用资源，造成资源紧缺和浪费。

更进一步，作为一种可选的实施例，控制至少两个相同的业务应用在底层共用同一应用实例，可以包括如下操作。

获取应用实例针对至少两个相同的业务应用中的一个业务应用的执行结果。

将获取的执行结果发送至与至少两个相同的业务应用关联的所有业务方。

示例性的，在将用户1的应用实例1和用户2的应用实例2合并为应用实例0后，无论应用实例1先调用工作流实例0，还是应用实例2先调用工作流实例0，还是应用实例1和应用实例2同时调用工作流实例0，都可以仅执行一次该工作流实例0，并将执行结果同时返回至用户1和用户2。

通过本申请实施例，在合并多个用户的应用实例后，通过仅执行一次该工作流实例0，而使多个用户共享执行结果，可以节省算力资源的开支，提高算力资源的性能(如硬件资源)，同时还可以提高工作效率。

应该理解，对于传统的AI系统，一套业务应用的配置通常都是固定写死的，因而无法对其配置进行灵活调整，导致应用场景非常有限。

而在本申请实施例中，用户可以使用应用定义模板自定义业务应用。对于已定义业务应用，用户还可以在两个层面上对业务应用进行微调。例如在应用层面上，可以调整业务应用中引用的AI算子组件。再例如在组件层面上，还可以进一步调整业务应用中引用的AI算子组件的配置参数(如各种阈值)。因而本申请实施例提供的AI系统应用更加灵活，应用场景更加广阔。

示例性的，对于AI视觉系统，如果多个AI视觉应用共用一个数据源(如图片流)，并分别针对图片流中存在的多个区域进行检测，例如一个AI视觉应用用于对图片中的A区域进行车辆密度统计，另一个AI视觉应用用于对图片中的B区域进行行人密度统计，那么可以对这两个AI视觉应用的相关配置参数如车辆密度阈值和行人密度阈值进行差异化配置。

通过本申请实施例，针对图片流中的不同检测区域，支持对不同的AI视觉应用中的相关组件的配置参数进行区域级别的差异化配置，可以适应不同的应用场景。

在本申请实施例中，如图3C所示，任务中心模块可以从应用中心模块获取多个已定义的业务应用，并从接收器A、接收器B、接收器C……获取各业务应用的输入数据，然后根据预先设定的策略，进行任务合并、工作流合并、对任务内部的多个应用实例进行批量启、停控制(任务启停控制)等，再然后通过分发器A、分发器B、分发器C……将批量各任务对应的工作流实例分发至工作流引擎中的工作流A(包括任务节点A、任务节点B、任务节点C……)、工作流B(包括任务节点X、任务节点Y、任务节点Z……)……。此外，任务中心模块包括执行节点管理模块，用于对执行节点进行管理；应用定义管理模块，用于定义应用(如调整应用中的算子模块)；业务管理模块，用于管理业务。

根据本申请的实施例，本申请提供了一种用于算子服务的处理方法。

图4示例性示出了根据本申请实施例的用于算子服务的处理方法的流程图。

如图4所示，该用于算子服务的处理方法400可以包括操作S410～S440。

在操作S410，确定针对目标算子服务配置的至少一个原始字段，其中每个原始字段用于描述目标算子服务的处理对象的一个特征属性。

在操作S420，确定目标算子服务所属的算子类别。

在操作S430，基于确定的算子类别，获取至少一个原始字段与至少一个标准字段之间的映射关系。

在操作S440，基于获取的映射关系，将由每个原始字段描述的特征属性的特征属性信息转换为由对应的标准字段描述的特征属性信息。

应该理解，对于较大体量的AI系统建设方，经常存在分批、分部门建设AI系统的情况。比较典型的例如交通、应急管理等领域，在多期项目建设完成后，同一类AI算子服务在AI系统中通常会出现多个版本(由多家厂商提供)并存的情况。例如，AI系统中存在一类特殊应用，即针对特定对象的视频抓拍应用，不同厂商针对这类应用提供的AI算子服务定义的特征字段的数量和所描述的内容都可能不同，导致不同AI算子服务输出的参数对同一特征的描述可能彼此不一致，不利于进行统一管理。而对于建设方或管理方而言，自然希望能够对各家厂商提供的算子服务进行统一管理，从而减少因为算子定义不同而带来的应用管理和日常应用中的不便。

针对上述问题，本申请实施例提供的上述用于算子服务的处理方法，可以预先建立各类算子服务中定义的所有原始字段与AI系统中定义的所有标准字段之间的映射关系。然后，对于每一个算子服务可以根据该算子服务所属的算子类别，确定该算子服务的所有原始字段与对应的标准字段之间映射关系。最后，根据该映射关系将该算子服务的输出参数中由每个原始字段描述的特征属性的特征属性信息转换为由对应的标准字段描述的特征属性信息。

示例性的，对于人脸识别应用而言，假设A厂商提供的算子服务描述男、女性别时所用的原始字段分别为“male”和“female”，B厂商提供的算子服务描述男、女性别时所用的原始字段分别为“1”和“2”，AI系统中定义的描述男、女性别时的标准字段分别为“0”和“1”，那么针对人脸识别应用而言，A、B厂商定义的描述男、女性别的原始字段与AI系统中定义的描述男、女性别的标准字段之间的映射关系如下表(表2)所示。

表2

厂商	男(标准映射)	女(标准映射)
			A厂商	“male”→“0”	“female”→“1”
B厂商	“1”→“0”	“2”→“1”

需要说明的是，在本申请实施例中，可以在注册算子服务时登记算子服务/AI模型所属的算子类别以及生产厂商自定义的原始字段，同时还可以记录算子服务的原始字段与对应的标准字段之间的映射关系。

相关技术中即使针对同一类算子服务，由于不同厂商定义的用于描述同一特征属性的字段可能不尽相同，因而不同厂商自定义的字段对同一特征属性的描述或多或少会存在差异，从而不利于信息的统一管理。

与上述相关技术不同，本申请实施例中，针对每类算子服务，各定义了一套标准字段，同时定义了各厂商的原始字段与本标准字段之间的映射关系，以便对同一特征属性进行统一描述。

作为一种可选的实施例，该方法还可以包括：将转换后的特征属性信息存储到目标数据库中。其中，可以通过以下操作得到该目标数据库。

确定每个标准字段，其中每个标准字段用于描述属于上述的算子类别的算子服务的处理对象的一个特征属性。

获取数据库模板。

基于每个标准字段对数据库模板进行配置，以得到目标数据库。

在本申请实施例中，针对每类算子服务，各定义了一套标准字段，同时定义了各厂商的原始字段与本标准字段之间的映射关系，因而基于该映射关系可以将调用同一类别的算子服务而输出的不同格式的参数转换为标准格式的参数进行统一存储。

在一个实施例中，对于每一类算子服务，可以先确定利用该类算子服务处理对象时需要描述的所有特征属性维度，然后获取用于描述该所有特征属性维度的所有标准字段，最后在预先定义的通用数据库模板中对与该所有标准字段对应的配置项进行配置即可得到用于存储该类算子服务的标准输出参数(通过原始字段与标准字段之间的映射关系对原始输出参数进行转换得到的)的数据库。应该理解，上述配置项包括针对数据库表的结构定义和字段定义的配置项。

通过本申请实施例，针对不同类别的算子服务可以快速配置出与其标准输出参数的格式匹配的数据库，以便能够统一存储同类算子服务的标准输出参数。

进一步，作为一种可选的实施例，该方法还可以包括：生成上述的目标数据库的索引字段。

需要说明的是，本申请实施例提供的AI系统中可以包括数量、种类众多的算子服务，并且该AI系统还可以对外提供针对算子服务的扩展端口。因而需要管理的算子服务较多。并且通过该AI系统可以快速地自定义出数量、种类众多的AI应用。面对众多的AI应用，需要存储的数据自然也很多，需要的数据库数量和种类自然也很多。因而需要管理的数据库也较多。

因此，在本申请实施例中，还可以针对不同的数据库的生成不同的索引字段，以方便管理数据库。

进一步，作为一种可选的实施例，基于当前针对上述的目标数据库使用的高频搜索词，生成目标数据库的索引字段。

在一个实施例中，用户可以手动配置各个数据库的索引字段。在另一个实施例中，系统可以根据用户搜索各个数据库所使用的高频搜索词自动生成各个数据库的索引字段。

应该理解，由于本申请实施例中的AI系统需要管理的数据库可能会很多，导致手动配置索引字段时可能会出现命名重复的情况，进而可能会导致数据库管理比较混乱。而自动配置数据库的索引字段时不仅可以深度学习用户的搜索习惯，以便于大多数用户快速检索到对应的数据库，而且可以自动校验是否出现命名重复的情况，因而可以尽量避免数据库管理出现混乱的情况。

或者，作为一种可选的实施例，该方法还可以包括以下操作中的至少之一。

操作1，将用于配置目标数据库的所有标准字段，分别配置为针对目标数据库中存储的信息的检索项。

操作2，将所有标准字段中当前搜索频次高于预设值的至少一个标准字段，配置为针对目标数据库中存储的信息的检索项。

操作3，将所有标准字段中被指定的至少一个标准字段，配置为针对目标数据库中存储的信息的检索项。

在一个实施例中，用户可以手动执行操作1～操作3，为每个数据库配置对应的检索项。在另一个实施例中，系统也可以自动执行操作1～操作3为每个数据库配置对应的检索项。

应该理解，操作2中配置检索项的方法与上述实施例中配置索引字段的方法类似，因而手动配置检索项时也可能会出现命名重复的情况，进而可能会导致检索结果不够精准。而自动配置检索项时不仅可以深度学习用户的搜索习惯，以便于大多数用户快速检索到对应的信息，而且可以自动校验是否出现命名重复的情况，因而可以尽量提高检索结果的精准度。

通过本申请实施例，针对同类算子服务的输出参数，不仅可以以标准字段进行统一存储，而且还可以进行统一检索。

或者，作为一种可选的实施例，该方法还可以包括：响应于接收到外部针对存储在目标数据库中的特征属性信息的获取请求，先将所请求的特征属性信息转换为通过外部通用标准字段描述的特征属性信息，再进行输出。

应该理解，本申请实施例提供的AI系统除了可以提供AI算子服务、AI应用和AI工作流等的共享服务之外，还可以提供数据共享服务。而基于使用内部通用标准字段存储的数据对外提供数据共享服务，可能会给外部使用者带来阅读和理解困难。

因此，在本申请实施例中，提供数据共享服务时，还可以基于外部通用标准字段再次进行数据格式的转换，以便对外提供可阅读性和可理解性更强的共享数据。

需要说明的，在本申请实施例中，基于外部通用标准字段进行数据格式转换的方法与基于内部通用标准字段进行数据格式转换的方法类似，在此不再赘述。

或者，作为一种可选的实施例，该方法还可以包括如下操作。

针对目标数据库生成数据生存周期(数据淘汰周期)。

基于数据生存周期，对目标数据库中存储的历史数据进行淘汰处理。

在一个实施例中，对于数据增长速度较慢的应用场景，可以根据实际需要，针对数据库设置数据生存周期。在每个数据生存周期内，数据库可以自动清除创建时间落在上个数据生存周期内的数据。

通过本申请实施例，用户可以自定义数据库的数据生存周期，数据库可以根据数据生存周期自动清除其中存储的部分历史数据，由此可以减少数据库中的数据存储量，进而可以提高数据库的检索速度。

或者，作为一种可选的实施例，该方法还可以包括：响应于所述目标数据库中存储的信息的数据量达到预设值(数据量上限值)，针对目标数据库进行分库分表处理。

在一个实施例中，对于数据增长速度较快的应用场景，如果还根据数据生存周期来管理数据库，则可能会丢失目前还有使用价值的数据。因此，在该应用场景下，可以根据实际需要，针对数据库设置数据量上限值(预设值)。在实际数据量达到数据量上限值的情况下，针对当前数据库创建分数据库和分数据库表。其中分数据库和分数据库表的数据结构与当前数据库的数据结构相同。

通过本申请实施例，用户可以自定义数据库的数据量上限值，数据库可以根据数据量上限值自动配置对应的分库分表逻辑，由此可以减少单个数据库或数据库表中的数据存储量，进而也可以提高数据库的检索速度，同时还可以避免丢失目前还有使用价值的数据。

在一个实施例中，可以先预测各数据库的数据增长趋势，然后根据实际预测结果选择合理的数据库管理方式。

或者，作为一种可选的实施例，该方法还可以包括：在将转换后的特征属性信息存储到目标数据库中之前，检验目标数据库中是否存在与转换后的特征属性信息匹配的字段。

在一个实施例中，响应于检验结果表征目标数据库中存在与转换后的特征属性信息匹配的字段，则将转换后的特征属性信息存储到该目标数据库中的对应字段下；否则，响应于检验结果表征目标数据库中不存在与转换后的特征属性信息匹配的字段，则进行告警。

通过本申请实施例，提供动态的数据库插入接口，支持符合数据库字段定义的数据插入，例如可以保证上层AI工作流能够完成新增抓拍数据的准确记录。

此外，在另一个实施例中，响应于检验结果表征目标数据库中不存在与转换后的特征属性信息匹配的字段，除了告警之外，还可以校验该转换后的特征属性信息是否是通过新增标准字段描述的特征属性信息。响应于校验结果表征该转换后的特征属性信息是通过新增标准字段描述的特征属性信息，还可以对数据库的字段进行扩展。

根据本申请的实施例，本申请提供了另一种用于算子服务的处理方法。

图5A示例性示出了根据本申请另一实施例的用于算子服务的处理方法的流程图。

如图5A所示，该用于算子服务的处理方法500A可以包括操作S510～S530。

在操作S510，确定用于部署算子服务的N类算力资源。其中在N类算力资源中的每类算力资源中，针对算子服务设置有至少一个容器。

在操作S520，获取基于算子服务生成的N个服务镜像。

在操作S530，将N个服务镜像分别部署到N类算力资源中针对算子服务设置的容器内。

在实现本申请实施例的过程中，发明人发现：传统的人工智能技术中，各环节割裂严重。如训练AI模型需要一个单独系统(模型训练系统)，AI模型产出后需要再到另一个系统(镜像发布系统)中生成镜像文件进行发布，最后再到生产系统中进行镜像部署和实际预测。因此，AI模型的训练系统和预测系统无法顺畅对接。此外，传统的人工智能技术中，一套AI应用中包含的所有镜像都部署在一个单独的硬件设备上，并且在实现AI应用之前，应用的部署方案就已固化并确定下来了。因此，运行AI应用时无法实现异构资源调度，导致异构算力资源效率差，单位算力成本高，资源浪费严重。例如，某企业内部拥有GPU 2.7w张，但整体利用率仅为13.42％。

此外，在实现本申请实施例的过程中，发明人发现：

(1)从算力演进角度看，目前，人工智能系统的算力基本每6个月就能翻一翻，各个AI芯片厂商每年都在不断地推出新的计算平台。这些计算平台一方面降低了人工智能的使用成本，另一方面，旧有的计算平台和新推出的计算平台混合存在于用户的人工智能云平台中，加大了人工智能云平台的管理难度。

(2)从AI系统建设成本角度看，目前，人工智能云平台无法实现算力资源、算子服务、应用服务的共享和互通，增加了企业之间以及企业内部各部门(业务单元)之间建设和使用AI系统的成本。

因此，本申请实施例提供了一套人工智能方案，可以在享受到算力飞速增长的同时，有效去除不同计算平台之间的差异性，实现算力资源、算子服务、应用服务的共享和互通，同时减低建设和使用成本。

在本申请实施例中，可以将注册在同一算子服务下的多个服务镜像同时部署在多种算力资源的容器中，以便执行应用逻辑时可以以该算子服务为统一请求接口，通过调用部署在不同类别的算力资源中的服务镜像来实现异构资源的无差别调度。

示例性的，如图5B所示，人工智能云平台500B包括：算力资源510、算力资源520、算力资源530和算力资源540，并且这些算力资源为不同厂商提供的不同类别的算力资源。对于AI系统中注册的每个算子服务如算子服务A，可以在算力资源510、算力资源520、算力资源530和算力资源540中依次设置容器511、容器521、容器531和容器541，同时基于算子服务A生成服务镜像A₁、服务镜像A₂、服务镜像A₃和服务镜像A₄，并将服务镜像A₁、服务镜像A₂、服务镜像A₃和服务镜像A₄依次对应部署在容器511、容器521、容器531和容器541中。

与相关技术中同一应用的算子服务固定部署在一个单独的硬件设备上，无法实现算子服务在异构资源中共享，因而无法实现算子服务的异构调度相比，本申请实施例可以基于一个算子服务生成多个服务镜像，并将不同的服务镜像部署在不同类别的算力资源中，因而可以实现算子服务在异构资源中共享，进而可以实现算子服务的异构调度。

作为一种可选的实施例，该方法还可以包括如下操作。

预测支持上述的算子服务运行所需的资源配额。

基于预测的资源配额，在上述的N类算力资源中的每类算力资源中，针对算子服务设置至少一个容器。

继续参考图5B，在本申请实施例中，注册算子服务A时可以预测运行算子服务A所需的算力配额，并根据该算力配额设置容器511、容器521、容器531和容器541的配置参数(如QPS、CPU占比、GPU占比等的上限值和下限值)。

在本申请实施例中，通过预测各算子服务所需的资源配额并基于此部署各算子服务，因而不仅可以实现算力资源的共享，而且可以提高资源效率。

进一步，作为一种可选的实施例，基于预测的资源配额，在N类算力资源中的每类算力资源中，针对算子服务设置至少一个容器，包括：针对每类算力资源，执行以下操作。

将预测的资源配额(抽象算力配额)转换为与当前类别的算力资源匹配的资源配额。

基于转换后的资源配额，在当前类别的算力资源中针对算子服务设置至少一个容器。

需要说明的是，由于不同算力资源的计量方式不同，因而在本申请实施例中使用统一的抽象算力资源计量方式先预测算力资源配额，再进行转换，可以实现对多元算力资源的统一管理。

继续参考图5B，在本申请实施例中，注册算子服务A时可以预测运行算子服务A所需的抽象算力配额，然后通过等价换算，将该抽象算力配额换算成具体到各类算力资源的实际算力配额，然后根据各实际算力配额设置容器511、容器521、容器531和容器541的配置参数(如QPS、CPU占比、GPU占比等的上限值和下限值)。

通过本申请实施例，以一套人工智能计算平台，在享受到算力飞速增长的同时，可以有效去除不同计算平台之间的差异性，如通过抽象算力配额消除不同类别的算力资源在计量上的差异等，从而在异构计算平台之间实现算力资源的透明化和统一化管理。此外，在本申请实施例中，通过预测各算子服务所需的资源配额并基于此部署各算子服务，不仅可以实现算力资源的共享，而且可以提高资源效率。

需要说明的是，在本申请实施例中，可以以一套算子管理服务，快速接入各类AI算子服务，包括视觉、语音、语义、知识图谱等。在算子服务注册过程中完成算子的算力评测，并以算力评测结果生成并登记算子服务的算力配额，实现跨平台算子统一抽象定义。

或者，作为一种可选的实施例，该方法还可以包括：响应于针对上述的算子服务设置的任一容器的负载超出预设值(如实例数、QPS、CPU占比、GPU占比等的上限值)，对负载超出预设值的容器进行扩容处理。

继续参考图5B，在将算子服务A的服务镜像A₁、服务镜像A₂、服务镜像A₃和服务镜像A₄依次对应部署在容器511、容器521、容器531和容器541中后，响应于算子服务A在容器511中的实例数超出容器511的实例数上限值，可以重新配置容器511的参数，如将其实例数上限值调大。

应该理解，在本申请实施例中，对超负载的容器进行扩容处理还包括但不限于修改容器的QPS、CPU占比、GPU占比等的上限值。

在本申请实施例中，通过动态扩容处理，可以满足高频算力服务的业务需求。

响应于新增了M类算力资源，获取基于算子服务新生成的M个服务镜像，其中在M类算力资源中的每类算力资源中，针对算子服务设置有至少一个容器。

将M个服务镜像分别部署到M类算力资源中的容器内。

应该理解，将上述算子服务的M个服务镜像部署在新增的M类算力资源中的方法与将上述算子服务的N个服务镜像部署在新增的N类算力资源中的方法类似，本申请实施例在此不再赘述。

通过本申请实施例，除了支持对人工智能云平台中已有的多元算力资源进行跨平台调度之外，还可以提供算力资源扩展接口，以便在该云平台中扩展其他异构算力资源。

或者，作为一种可选的实施例，该方法还可以包括：响应于接收到针对算子服务的请求，基于N类算力资源之间的算力负载平衡情况，调度用于响应该请求的算力资源。

在本申请实施例中，可以预先设定异构平台流量分发策略和平台内部流量分发策略。响应于接收到任意一个算子服务的至少一个请求，可以先根据该异构平台流量分发策略将请求分发至对应的算力资源(计算平台)，再根据该平台内部流量分发策略将分发至请求分发至算力资源(计算平台)的请求进一步分发至平台内部的对应节点上。

通过本申请实施例，采用合理的动态流量调度策略(如异构平台流量分发策略和平台内部流量分发策略)，可以提升资源效率，同时可以提升各异构算力平台的性能。

或者，作为一种可选的实施例，该方法还可以包括：在获取基于算子服务生成的N个服务镜像之前，执行以下操作。

获取至少一个AI模型文件。

基于至少一个AI模型文件，生成包含至少一个子算子服务的算子服务。

基于算子服务，生成N个服务镜像。

在一个实施例中，推理服务平台可以基于一个AI模型文件生成一个算子服务，然后再生成该算子服务的多个服务镜像。在另一个实施例中，推理服务平台可以先基于多个AI模型文件分别生成多个小的子算子服务，再将多个小的子算子服务组装成一个大的算子服务，然后再生成该算子服务的多个服务镜像。

需要说明的是，上述推理服务平台(推理服务框架)可以直接对接模型仓库，从中读取AI模型文件。此外，该模型仓库可以支持针对AI模型文件的增、删、改、查操作。此外，每个AI模型可以包括至少一个模型版本，因此该模型仓库还可以支持AI模型的多版本管理控制。此外，不同的AI模型文件可能是不同的厂商提供的(共享的)，而不同厂商生产的AI模型文件可能具有不同的模型格式。因此，上述推理服务平台还可以提供AI模型转换功能，以将AI模型转化为推理服务平台支持的模型格式。

应该理解，在本申请实施例中，AI系统可以注册的AI模型包括但不限于：机器学习模型、各种训练框架产出的深度学习模型。并且，上述的AI模型可以包括但不限于图像、视频、NLP、广告推荐等模型。

通过本申请实施例，支持从AI模型、到算子服务、再到服务镜像的全流程管理，并且在流程上可以和训练平台打通，确保资源申请和部署流程的效果体验。

此外，通过本申请实施例，可以注册AI模型，实现AI模型的单独部署，也可以将多个AI模型通过组合后进行混合部署，从而提供灵活多样的部署方式。

进一步，作为一种可选的实施例，基于算子服务，生成N个服务镜像，可以包括如下操作。

获取与算子服务匹配的至少一个预处理组件(前处理组件)和至少一个后处理组件。

基于算子服务、至少一个预处理组件和至少一个后处理组件，生成N个服务镜像。

需要说明的是，在本申请实施例中，推理服务框架可以提供前处理组件库和后处理组件库，用户可以根据需要自主选配对应的前处理组件和后处理组件。

在一个实施例中，可以使用推理服务框架提供的推理逻辑来生成算子服务的各个服务镜像。在另一个实施例中，推理服务框架还可以接收用户上传的推理代码，因而还可以使用用户上传的推理代码生成算子服务的各个服务镜像。

示例性的，如图5C所示，model-A(模型A)和pre-processor-0(前处理组件0)、pre-processor-1(前处理组件1)、pre-processor-2(前处理组件2)以及post-processor-0(后处理组件0)、post-processor-1(后处理组件1)组合在一起生成model-A的一个服务镜像A，进一步在服务镜像A中添加不同的标签可以生成服务镜像A₁、服务镜像A₂、服务镜像A₃、......等多个服务镜像。其中，model-A(模型A)表示算子服务A；pre-processor-0(前处理组件0)、pre-processor-1(前处理组件1)、pre-processor-2(前处理组件2)表示算子服务A的前处理组件；post-processor-0、post-processor-1表示算子服务A的后处理组件。需要说明的是，服务镜像通过自身携带的标签信息可以匹配到用于部署该服务镜像的算力资源。

进一步，作为一种可选的实施例，N个服务镜像中的每个服务镜像可以包括：基于算子服务生成的第一镜像，其中第一镜像包括至少一个第一子镜像；基于至少一个预处理组件生成的第二镜像，其中第一镜像包括至少一个第二子镜像；以及基于至少一个后处理组件生成的第三镜像，其中第一镜像包括至少一个第三子镜像。

因此，将N个服务镜像分别部署到N类算力资源中针对算子服务设置的容器内，可以包括：针对每类算力资源，执行操作4至操作6中的任意一个。

操作4，将对应的第一镜像、第二镜像和第三镜像分别部署在针对算子服务设置的不同容器内。

操作5，将对应的第一镜像、第二镜像和第三镜像中的至少两个部署在针对算子服务设置的同一容器内。

操作6，将对应的至少一个第一子镜像、至少一个第二子镜像和至少一个第三子镜像中的每个子镜像分别部署在针对算子服务设置的不同容器内。

在一个实施例中，推理服务框架可以用一个算子服务构建一个独立的服务。在另一个实施例中，推理服务框架还可以用多个算子服务构建一个组合型的服务(DAG服务)。需要说明的是，在本申请实施例中，推理服务框架可以基于通过AI系统提交的AI模型生成算子服务。或者AI系统还可以接收用户直接提交符合系统标准的算子服务。在本申请实施例中，算子服务和AI模型可以是一对一的关系，也可以是一对多的关系，即支持多个AI模型组成一个算子服务DAG。

在本申请实施例中，除了可以用多个AI模型组成一个DAG算子服务之外，还可以对算子服务进行拆分。算子服务拆分的前提在于保证用户的延时指标，在此基础上做利用率和性能优化。通过算子服务拆分，可以避免CPU资源不足以及GPU闲置的情况。此外，通过算子服务拆分，还可以将高频逻辑算子化，提高服务质量。

需要说明的是，操作、算子服务、单容器DAG之间的三种组合关系如图5D～图5F所示。图中的虚线框表示容器，也对应于推理服务框架的算子服务；实现框对应于算子服务的操作；连线表示各操作之间数据流关系。

如图5D所示，该组合关系表示单容器DAG，即一个算子服务的所有操作全部部署在同一容器中。该组合关系的优势在于服务形式简单，便于集群管理，并且数据流传输不占用网络带宽，响应速度较快。该组合关系的劣势在于不能用于进行算子拆分。

如图5E所示，该组合关系表示多容器DAG，即一个算子服务的每个操作都单独部署在一个独立的容器中。该组合关系的优势在灵活性好，能用于进行算子拆分。该组合关系的劣势在于多个容器之间进行数据流传输需要占用网络带宽，响应速度较慢，即多容器的数据流传输存在潜在性能问题。

如图5F所示，该组合关系表示另一种多容器DAG，每个容器可以部署多个操作。例如，model-A(模型A)、model-B(模型B)、model-C(模型C)组合部署在一个容器中；pre-processor-0(前处理组件0)、pre-processor-1(前处理组件1)、pre-processor-2(前处理组件2)组合部署在另一个容器中；post-processor-0(后处理组件0)、post-processor-1(后处理组件1)组合部署在再一个容器中。该组合关系的劣势在于多个容器之间进行数据流传输需要占用网络带宽，但是单个容器内部的数据流传输不需要占用网络带宽，响应速度相对于图5E所示的组合关系要快，相对于图5D所示的组合关系要慢，即数据流传输方面的性能问题可以通过容器内多个操作DAG来解决；同时多容器DAG又可以达到灵活性好(例如可以将高频逻辑model-A(模型A)、model-B(模型B)、model-C(模型C)算子化)以及能够进行算子拆分的目的。

需要说明的是，在本申请实施例中，在基于AI模型文件生成算子服务的过程，可以考虑各预处理组件、各后处理组件、以及算子服务本身的集成方式，以便为实现算子拆分提供基础。

此外，需要说明的是，推理服务框架还可以直接对接镜像仓库，向其写入服务镜像文件。此外，该镜像仓库可以支持针对服务镜像文件的增、删、改、查操作。

通过本申请实施例，支持单容器、多容器DAG、多容器DAG以及容器内操作DAG等多种组合关系。其中，多容器DAG以及容器内操作DAG组合关系，既可以解决数据的传输性能，又便于对算子服务进行集群管理，灵活性好。

进一步，在本申请实施例中，还可以利用GPU的监控数据对业务进行分类，从而提供合理的混布的模型组合方案。

示例性的，如图5G所示，可以将资源占用较低的模型如model-A(模型A)、model-B(模型B)、model-C(模型C)组合部署在一个容器中如容器1中(即在单容器内实现多模型混部)，共享GPU资源如GPU0；将资源占用较高的模型如model-E和model-F分别部署在两个容器中如容器2和容器3中(即将多个容器挂载在相同的计算卡(计算节点)上，在底层通过MPS实现模型混部)。其中，model-E(模型E)和model-F(模型F)彼此之间既可以实现资源隔离(占用不同的容器)，又可以共享GPU资源如GPU1。

图6A示例性示出了根据本申请再一实施例的用于算子服务的处理方法的流程图。

如图6A所示，该用于算子服务的处理方法600A可以包括操作S610(即接收调用目标算子服务的至少一个请求)以及响应于接收到调用目标算子服务的至少一个请求，执行以下操作S620～S640。

在操作S620，确定基于目标算子服务生成的多个服务镜像。

在操作S630，确定用于部署多个服务镜像的多个异构算力资源平台。

在操作S640，基于预先设定的异构平台流量分发策略，将至少一个请求分发至多个异构算力资源平台中对应的算力资源平台进行处理。

其中，所述异构平台流量分发策略包括以下至少之一：异构轮询策略、异构随机策略、异构优先级策略和异构权重策略。

在一个实施例中，可以根据每个算子服务的注册信息，确定每个算子服务名下注册的所有服务镜像，进而根据这些服务镜像各自携带的标签信息，匹配出部署了这些服务镜像的所有异构算力资源平台(计算平台)，然后根据预先设定的异构平台流量分发策略先将接收到的请求分发至对应的算力资源平台(计算平台)，再根据该平台内部流量分发策略将分发至请求分发至各算力资源(计算平台)的请求进一步分发至各平台内部的对应节点上。

在另一个实施例中，部署算子服务后可以记录对应的部署信息，然后在进行流量调度(分发请求)时，可以根据该部署信息确定部署有算子服务的服务镜像的所有异构算力资源平台，然后根据预先设定的异构平台流量分发策略先将接收到的请求分发至对应的算力资源平台(计算平台)，再根据该平台内部流量分发策略将分发至请求分发至各算力资源(计算平台)的请求进一步分发至各平台内部的对应节点上。

需要说明的是，在本申请实施例中，异构轮询策略：对同一个算子服务的请求，按照设定的特定顺序依次分发给特定计算平台的内部负载均衡代理。异构随机策略：对同一个算子服务的请求，随机分发给特定计算平台的内部负载均衡代理。异构优先级策略：对同一个算子服务的请求，按照设定的优先顺序分发给特定计算平台的内部负载均衡代理，特定平台服务的QPS数或GPU利用率或CPU利用率达到监控指标时，超出指标部分的QPS数会分发给下一优先级的计算平台的内部负载均衡代理。异构权重策略：对同一个算子服务的请求，根据指定的平台权重，按比例地随机分发给特定计算平台的内部负载均衡代理。

与相关技术中算子服务仅能部署在单独的固定的硬件设备上，因此针对同一算子服务无法跨平台实现异构资源调度相比，通过本申请实施例，采用将同一算子服务的不同服务镜像同时部署在多个不同的异构算力资源平台中，因而针对同一算子服务可以实现异构资源调度。

作为一种可选的实施例，该方法还可以包括：在将至少一个请求分发至多个异构算力资源平台中对应的算力资源平台之后，在对应的算力资源平台包括多个执行节点的情况下，基于预先设定的平台内部流量分发策略，将已分发至对应的算力资源平台的请求分发至多个执行节点中对应的执行节点进行处理。其中，平台内部流量分发策略包括以下至少之一：内部轮询策略、内部随机策略、内部优先级策略和内部权重策略。

在本申请实施例中，对于已分发至算力资源平台上的流量(1个或者多个算子服务请求)，在单平台内部可以按照预先设定的平台内部流量分发策略将流量进一步分发给最终的执行节点进行处理并响应。

需要说明的是，在本申请实施例中，内部轮询策略：对已分发给计算平台的算子服务请求，按照设定的特定顺序依次分发给平台内部的执行节点。异构随机策略：对已分发给计算平台的算子服务的请求，随机分发给平台内部的执行节点。异构优先级策略：对已分发给计算平台的算子服务的请求，按照设定的优先顺序分发给平台内部的特定执行节点，特定执行节点服务的QPS数或GPU利用率或CPU利用率达到监控指标时，超出指标部分的QPS数会分发给下一优先级的执行节点。异构权重策略：对已分发给计算平台的算子服务的请求，根据指定的节点权重，按比例地随机分发给特定执行节点。

示例性的，如图6B所示，来自用户的针对同一算子服务的流量(至少一个请求)先通过一级代理Proxy根据异构平台流量分发策略分发至计算平台，在计算平台内部(如GPUType1～GPU Type5)再通过二级代理(如Proxy1～Proxy5)根据平台内部流量分发策略分发至平台内部的执行节点(如在GPU Type1内部分发至Node T1-1～Node T1-2)。

通过本申请实施例，可以在算力资源平台内部灵活地进行资源调度。

进一步，作为一种可选的实施例，该方法还可以包括：在分发至少一个请求的过程中，针对目标算子服务，响应于出现实际资源占用量达到预设资源配额上限的至少一个异构算力资源平台，针对目标算子服务进行扩容处理，以便继续分发至少一个请求中尚未分发完的请求。

示例性的，在一个实施例中，在将算子服务A的服务镜像A₁、服务镜像A₂、服务镜像A₃和服务镜像A₄依次对应部署在容器1、容器2、容器3和容器4中后，响应于算子服务A在容器1中的实例数超出容器1的实例数上限值，可以重新配置容器1的参数，如将其实例数上限值调大。

应该理解，在本申请实施例中，对超负载(实际资源占用量达到预设资源配额上限)的容器进行扩容处理还包括但不限于修改容器的QPS、CPU占比、GPU占比、显存占比等的上限值。

示例性的，在另一个实施例中，在出现实际资源占用量达到预设资源配额上限的至少一个异构算力资源平台的情况下，除了可以修改超负载的容器的相关参数之外，还可以新增一个或者多个容器，用于部署当前算子服务的服务镜像。

在本申请实施例中，通过动态扩容处理，可以满足高频算子服务的业务需求，并且可以提升资源效率。

进一步，作为一种可选的实施例，针对目标算子服务进行扩容处理，可以包括如下操作。

基于上述的实际资源占用量达到预设资源配额上限的至少一个异构算力资源平台，获取基于目标算子服务生成的至少一个服务镜像。

将至少一个服务镜像分别部署到上述的至少一个异构算力资源平台中针对目标算子服务设置的容器内。

应该理解，在扩容阶段针对算子服务部署服务镜像和在初始建设阶段针对算子服务部署服务镜像的方法类似，本申请实施例在此不再赘述。

此外，在本申请实施例中，在特定计算平台上进行扩容的过程中，可以通过对特定计算平台进行标签校验，并根据标签校验结果向算子管理服务申请关于算子服务的对应于该特定计算平台的服务镜像，然后引用该特定计算平台的部署库进行扩容部署。

需要说明的是，在本申请实施例中，可以在注册算子服务时完成算子服务的资源配额登记，包括登记用于部署各服务镜像的单容器的最大QPS、GPU占用、显存占用、实例数，以及各线程数下对应的QPS、GPU占用、显存占用，以便用于在初始建设阶段和扩容阶段为各服务镜像配置资源。

通过本申请实施例，可以支持根据算子服务实际资源占用(如QPS配额或GPU配额等)与特定计算平台为部署算子服务已配置的资源上限值之间的比例，自动执行扩容操作；在扩容阶段可以支持硬件资源的智能分配。

更进一步，作为一种可选的实施例，将上述的至少一个服务镜像分别部署到至少一个算力资源平台中针对目标算子服务设置的容器内，包括：针对至少一个异构算力资源平台中的每个算力资源平台，执行以下操作。

确定用于部署该至少一个服务镜像中对应的服务镜像的资源组。

在资源组内创建容器。

将对应的服务镜像部署在新创建的容器内。

更进一步，作为一种可选的实施例，该方法还可以包括：在资源组内创建容器之前，响应于资源组的实际资源占用量已达到资源组的资源配额上限，执行告警操作。

需要说明的是，在本申请实施例中，由于AI系统可以以共享型的模式同时面对多个业务方(如多个企业之间，或者企业内的多个部门之间)提供服务，因此可以在AI系统的算力资源中为每个业务方(一个业务方可以作为一个租户)分配一个资源组作为该业务方的专用算力资源。

因此，在本申请实施例中，在扩容阶段，如果某个业务方的某个或者某几个容器当前资源不足，则可以优先在分配给该业务方的资源组内进行扩容。如果该业务方的资源组当前限额不足以继续扩容，则进行告警。

应该理解，在本申请实施例中，AI系统可以支持对服务器节点、计算卡单元登记GPU、显存及CPU资源总量；支持将服务器节点、计算卡单元组合为资源组，其中资源组所能提供的资源为所包含的服务器节点、计算卡单元所能提供的资源总量之和。

在本申请实施例中，可以仅为一部分业务方配置专用的资源组(私用资源组)，剩余一部分业务方可以使用共用资源(共用资源组)。因此，在部署算子服务时，用户可以指定算子服务计划部署的资源组以及每个资源组计划部署的实例数或所需资源(如QPS、GPU占用量等)，AI系统将按照用户指定的实例数或所需资源在对应资源组内进行随机部署。

此外，在本申请实施例中，AI系统还可以支持配置算子服务的资源配额，即在当前资源组内配置当前算子服务允许占用的最大资源额度与最小资源额度，以保证资源的有效规划。

通过本申请实施例，可以在提供算力资源共享服务的同时，在多个业务方之间实现算力资源的隔离，即划分不同的资源组，以保证各业务方数据安全。同时，在当前资源不足以支持继续扩容时可以进行告警，以便人工介入解决。

或者，作为一种可选的实施例，该方法还可以包括：在获取基于目标算子服务生成的至少一个服务镜像之前，执行以下操作。

获取至少一个AI模型文件。

基于至少一个AI模型文件，生成包含至少一个子算子服务的目标算子服务。

基于目标算子服务，生成至少一个服务镜像。

需要说明的是，本申请实施例提供的服务镜像的生成方法与本申请前述实施例提供的服务镜像的生成方法相同，在此不再赘述。

通过本申请实施例，AI系统支持外部提交的AI模型，并且支持将一个AI模型单独部署为一个算子服务，也支持将多个AI模型通过算子服务DAG组合后进行混合部署一个算子服务，从而提供灵活多样的部署方式。

根据本申请的实施例，本申请提供了一种用于工作流的处理装置。

图7A示例性示出了根据本申请实施例的用于工作流的处理装置的框图。

如图7A所示，该用于工作流的处理装置700A可以包括获取模块701、生成模块702、校验模块703和保存模块704。

获取模块701(第一获取模块)，用于获取用户定义的业务应用，其中在业务应用中，定义了多个应用组件和多个应用组件之间的连接关系，多个应用组件包括至少一个算子组件。

生成模块702(第一生成模块)，用于基于业务应用，预生成对应的工作流，其中多个应用组件中的每个应用组件对应于工作流中的一个任务节点，多个应用组件之间的连接关系对应于工作流中的多个任务节点之间的数据流向。

校验模块703，用于针对工作流中的每个任务节点，进行目标节点校验，其中目标节点包括以下中的至少一项：上游节点、下游节点。

保存模块704，用于响应于目标节点校验通过，保存工作流。

根据本申请的实施例，用于工作流的处理装置700A例如还可以包括输入数据获取模块、实例生成模块和实例图生成模块。输入数据获取模块用于获取工作流的输入数据。实例生成模块用于基于获取的输入数据和工作流，生成对应的工作流实例。实例图生成模块用于基于工作流实例生成对应的工作流实例图。

作为一种可选的实施例，用于工作流的处理装置例如还可以包括任务分发模块，用于通过分发端将工作流实例中的各个任务节点对应的任务分发至队列中；任务执行模块，用于通过至少一个执行端从所述队列中获取任务并进行处理。其中，执行端将各任务的执行结果存储在预设存储器中，分发端从预设存储器读取各任务的执行结果并基于读取的执行结果向队列分发后续任务。

作为一种可选的实施例，用于工作流的处理装置例如还可以包括：任务量控制模块，用于对至少一个执行端中的每个执行端在单位时间内获取的任务量进行控制。

作为一种可选的实施例，用于工作流的处理装置例如还可以包括：处理控制模块，控制工作流实例中满足亲和路由的多个任务节点对应的任务都在同一个执行端上处理。

作为一种可选的实施例，用于工作流的处理装置例如还可以包括：任务执行模块和参数记录模块。任务执行模块用于执行工作流实例中各个任务节点对应的任务。参数记录模块用于根据任务执行结果记录每个任务节点的输入参数和/或输出参数。

作为一种可选的实施例，用于工作流的处理装置例如还可以包括：告警模块，用于响应于目标节点校验未通过，针对工作流进行告警。

需要说明的是，本申请装置部分的实施例与本申请对应的方法部分的实施例对应相同或类似，实现的技术效果和所解决的技术问题也对应相同或者类似，本申请实施例在此不再赘述。

根据本申请的实施例，本申请提供了一种用于业务应用的处理装置。

图7B示例性示出了根据本申请实施例的用于业务应用的处理装置的框图。

如图7B所示，该用于业务应用的处理装置700B可以包括应用确定模块705、任务生成模块706和批量控制模块707。

应用确定模块705，用于确定预定义的多个业务应用。

任务生成模块706，用于基于多个业务应用，生成至少一个业务任务，其中每个业务任务中包含多个业务应用中的多个数据源和执行计划都相同的业务应用。

批量控制模块707，用于对每个业务任务中包含的业务应用进行批量控制。

作为一种可选的实施例，该装置还可以包括：复用控制模块，用于在多个业务应用中存在至少两个业务应用需要在底层调用相同的算子服务的情况下，控制至少两个业务应用复用算子服务。

作为一种可选的实施例，复用控制模块还用于控制至少两个业务应用复用算子服务的同一服务镜像。

作为一种可选的实施例，复用控制模块还用于在针对至少两个业务应用中的每个业务应用，服务镜像的输入数据相同的情况下，控制服务镜像执行一次并向至少两个业务应用中的每个业务应用返回执行结果。

作为一种可选的实施例，该装置还可以包括：应用合并模块，用于针对每个业务任务，在当前业务任务中存在针对不同业务方的至少两个相同的业务应用的情况下，在当前业务任务中合并至少两个相同的业务应用。

作为一种可选的实施例，应用合并模块，用于控制至少两个相同的业务应用在底层共用同一应用实例。

作为一种可选的实施例，应用合并模块包括：结果获取单元，用于获取应用实例针对至少两个相同的业务应用中的一个业务应用的执行结果；结果发送单元，用于将获取的执行结果发送至与至少两个相同的业务应用关联的所有业务方。

根据本申请的实施例，本申请提供了一种用于算子服务的处理装置。

图7C示例性示出了根据本申请实施例的用于算子服务的处理装置的框图。

如图7C所示，该用于算子服务的处理装置700C可以包括第一确定模块708、第二确定模块709、获取模块710和转换模块711。

第一确定模块708，用于确定针对目标算子服务配置的至少一个原始字段，其中每个原始字段用于描述目标算子服务的处理对象的一个特征属性。

第二确定模块709，用于确定目标算子服务所属的算子类别。

获取模块710(第二获取模块)，用于基于确定的算子类别，获取至少一个原始字段与至少一个标准字段之间的映射关系。

转换模块711，用于基于获取的映射关系，将由每个原始字段描述的特征属性的特征属性信息转换为由对应的标准字段描述的特征属性信息。

作为一种可选的实施例，该装置还可以包括：信息存储模块，用于将转换后的特征属性信息存储到目标数据库中。其中，通过数据库配置模块执行相关操作得到目标数据库。数据库配置模块包括：字段确定单元，用于确定每个标准字段，其中每个标准字段用于描述属于算子类别的算子服务的处理对象的一个特征属性；模板获取单元，用于获取数据库模板；模板配置单元，用于基于每个标准字段对数据库模板进行配置，以得到目标数据库。

作为一种可选的实施例，该装置还可以包括：索引字段生成模块，用于生成目标数据库的索引字段。

作为一种可选的实施例，索引字段生成模块还用于基于当前针对目标数据库使用的高频搜索词，生成目标数据库的索引字段。

作为一种可选的实施例，该装置还可以包括以下至少之一：第一配置模块，用于将用于配置目标数据库的所有标准字段，分别配置为针对目标数据库中存储的信息的检索项；第二配置模块，用于将所有标准字段中当前搜索频次高于预设值的至少一个标准字段，配置为针对目标数据库中存储的信息的检索项；第三配置模块，用于将所有标准字段中被指定的至少一个标准字段，配置为针对目标数据库中存储的信息的检索项。

作为一种可选的实施例，该装置还可以包括：信息转换模块，用于响应于接收到外部针对存储在目标数据库中的特征属性信息的获取请求，将所请求的特征属性信息转换为通过外部通用标准字段描述的特征属性信息；信息输出模块，用于基于信息转换模块的处理结果进行信息输出。

作为一种可选的实施例，该装置还可以包括：数据生存周期生成模块，用于针对目标数据库生成数据生存周期；数据淘汰处理模块，用于基于数据生存周期，对目标数据库中存储的历史数据进行淘汰处理。

作为一种可选的实施例，该装置还可以包括：分库分表处理模块，用于响应于目标数据库中存储的信息的数据量达到预设值，针对目标数据库进行分库分表处理。

作为一种可选的实施例，该装置还可以包括：校验模块，用于在将转换后的特征属性信息存储到目标数据库中之前，检验目标数据库中是否存在与转换后的特征属性信息匹配的字段。

根据本申请的实施例，本申请提供了另一种用于算子服务的处理装置。

图7D示例性示出了根据本申请另一实施例的用于算子服务的处理装置的框图。

如图7D所示，该用于算子服务的处理装置700D可以包括确定模块712、获取模块713、和部署模块714。

确定模块712(第四确定模块)，用于确定用于部署算子服务的N类算力资源，其中在N类算力资源中的每类算力资源中，针对算子服务设置有至少一个容器。

获取模块713(第三获取模块)，用于获取基于算子服务生成的N个服务镜像。

部署模块714，用于将N个服务镜像分别部署到N类算力资源中针对算子服务设置的容器内。

作为一种可选的实施例，该装置还可以包括：预测模块，用于预测支持算子服务运行所需的资源配额；以及设置模块，用于基于预测的资源配额，在N类算力资源中的每类算力资源中，针对算子服务设置至少一个容器。

作为一种可选的实施例，设置模块包括：匹配单元，用于针对每类算力资源，将预测的资源配额转换为与当前类别的算力资源匹配的资源配额；以及设置单元，用于基于转换后的资源配额，在当前类别的算力资源中针对算子服务设置至少一个容器。

作为一种可选的实施例，该装置还可以包括：扩容模块，用于响应于针对算子服务设置的任一容器的负载超出预设值，对负载超出预设值的容器进行扩容处理。

作为一种可选的实施例，该装置还可以包括：第二获取模块，用于响应于新增了M类算力资源，获取基于算子服务新生成的M个服务镜像，其中在M类算力资源中的每类算力资源中，针对算子服务设置有至少一个容器；以及第一部署模块，用于将M个服务镜像分别部署到M类算力资源中的容器内。

作为一种可选的实施例，该装置还可以包括：调度模块，用于响应于接收到针对算子服务的请求，基于N类算力资源之间的算力负载平衡情况，调度用于响应请求的算力资源。

作为一种可选的实施例，该装置还可以包括：第三获取模块，用于在获取基于算子服务生成的N个服务镜像之前，获取至少一个AI模型文件；第二生成模块，用于基于至少一个AI模型文件，生成包含至少一个子算子服务的算子服务；以及第三生成模块，用于基于算子服务，生成N个服务镜像。

作为一种可选的实施例，该装置还可以包括：基于第三生成模块包括：

获取单元，用于与算子服务匹配的至少一个预处理组件和至少一个后处理组件；以及

生成单元，用于基于算子服务、至少一个预处理组件和至少一个后处理组件，生成N个服务镜像。

作为一种可选的实施例，N个服务镜像中的每个服务镜像包括：基于算子服务生成的第一镜像，其中第一镜像包括至少一个第一子镜像。

该装置还可以包括：第四生成模块，用于基于至少一个预处理组件生成的第二镜像，其中第一镜像包括至少一个第二子镜像；以及第五生成模块，用于基于至少一个后处理组件生成的第三镜像，其中第一镜像包括至少一个第三子镜像；第一部署模块，包括：第一部署单元，用于针对每类算力资源，将对应的第一镜像、第二镜像和第三镜像分别部署在针对算子服务设置的不同容器内；或者，第二部署单元，用于将对应的第一镜像、第二镜像和第三镜像中的至少两个部署在针对算子服务设置的同一容器内；或者，第三部署单元，用于将对应的至少一个第一子镜像、至少一个第二子镜像和至少一个第三子镜像中的每个子镜像分别部署在针对算子服务设置的不同容器内。

根据本申请的实施例，本申请提供了再一种用于算子服务的处理装置。

图7E示例性示出了根据本申请再一实施例的用于算子服务的处理装置的框图。

如图7E所示，该用于算子服务的处理装置700E可以包括接收端715和处理器716。

接收端715，用于调用各算子服务的请求。

处理器716，用于响应于接收到调用目标算子服务的至少一个请求，执行以下操作：(第一确定模块，用于)确定基于目标算子服务生成的多个服务镜像；(第二确定模块，用于)确定用于部署多个服务镜像的多个异构算力资源平台；(第一流量分发模块，用于)基于预先设定的异构平台流量分发策略，将至少一个请求分发至多个异构算力资源平台中对应的算力资源平台进行处理；其中，异构平台流量分发策略包括以下至少之一：异构轮询策略、异构随机策略、异构优先级策略和异构权重策略。

作为一种可选的实施例，该处理器还可以包括：第二流量分发模块，用于在将至少一个请求分发至多个异构算力资源平台中对应的算力资源平台之后，在对应的算力资源平台包括多个执行节点的情况下，基于预先设定的平台内部流量分发策略，将已分发至对应的算力资源平台的请求分发至多个执行节点中对应的执行节点进行处理；其中，平台内部流量分发策略包括以下至少之一：内部轮询策略、内部随机策略、内部优先级策略和内部权重策略。

作为一种可选的实施例，该处理器还可以包括：扩容模块，用于在分发至少一个请求的过程中，针对目标算子服务，响应于出现实际资源占用量达到预设资源配额上限的至少一个异构算力资源平台，针对目标算子服务进行扩容处理，以便继续分发至少一个请求中尚未分发完的请求。

作为一种可选的实施例，该处理器还可以包括：扩容模块包括：获取单元，用于基于至少一个异构算力资源平台，获取基于目标算子服务生成的至少一个服务镜像；部署单元，用于将至少一个服务镜像分别部署到至少一个异构算力资源平台中针对目标算子服务设置的容器内。

作为一种可选的实施例，该处理器还可以包括：部署单元还用于：针对至少一个异构算力资源平台中的每个算力资源平台，确定用于部署至少一个服务镜像中对应的服务镜像的资源组；在资源组内创建容器；将对应的服务镜像部署在容器内。

作为一种可选的实施例，该部署单元还用于：在资源组内创建容器之前，响应于资源组的实际资源占用量已达到资源组的资源配额上限，执行告警操作。

作为一种可选的实施例，该处理器还可以包括：获取模块，用于在获取基于目标算子服务生成的至少一个服务镜像之前，获取至少一个AI模型文件；第一生成模块，用于基于至少一个AI模型文件，生成包含至少一个子算子服务的目标算子服务；第二生成模块，用于基于目标算子服务，生成至少一个服务镜像。

根据本申请的实施例，本申请还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。计算机程序产品包括计算机程序，所述计算机程序在被处理器执行时可以实现上述任意实施例的方法。

如图8所示，是根据本申请实施例的方法(如用于工作流的处理方法等)的电子设备的框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

如图8所示，该电子设备包括：一个或多个处理器801、存储器802，以及用于连接各部件的接口，包括高速接口和低速接口。各个部件利用不同的总线互相连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在电子设备内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备)上显示GUI的图形信息的指令。在其它实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样，可以连接多个电子设备，各个设备提供部分必要的操作(例如，作为服务器阵列、一组刀片式服务器、或者多处理器系统)。图8中以一个处理器801为例。

存储器802即为本申请所提供的非瞬时计算机可读存储介质。其中，所述存储器存储有可由至少一个处理器执行的指令，以使所述至少一个处理器执行本申请所提供的方法(如用于工作流的处理方法等)。本申请的非瞬时计算机可读存储介质存储计算机指令，该计算机指令用于使计算机执行本申请所提供的方法(如用于工作流的处理方法等)。

存储器802作为一种非瞬时计算机可读存储介质，可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块，如本申请实施例中的方法(如用于工作流的处理方法等)对应的程序指令/模块(例如，附图7A所示的获取模块701、生成模块702、校验模块703和保存模块704)。处理器801通过运行存储在存储器802中的非瞬时软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例中的方法(如用于工作流的处理方法等)。

存储器802可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据方法(如用于工作流的处理方法等)的电子设备的使用所创建的数据等。此外，存储器802可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中，存储器802可选包括相对于处理器801远程设置的存储器，这些远程存储器可以通过网络连接至如用于工作流的处理方法等的电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

用于实现本申请的方法(如用于工作流的处理方法等)的电子设备还可以包括：输入装置803和输出装置804。处理器801、存储器802、输入装置803和输出装置804可以通过总线或者其他方式连接，图8中以通过总线连接为例。

输入装置803可接收输入的数字或字符信息，以及产生与如用于工作流的处理方法等的电子设备的用户设置以及功能控制有关的键信号输入，例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出装置804可以包括显示设备、辅助照明装置(例如，LED)和触觉反馈装置(例如，振动电机)等。该显示设备可以包括但不限于，液晶显示器(LCD)、发光二极管(LED)显示器和等离子体显示器。在一些实施方式中，显示设备可以是触摸屏。

此处描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、专用ASIC(专用集成电路)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令，并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(PLD))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系；服务器可以为分布式系统的服务器，或者是结合了区块链的服务器。服务器也可以是云服务器，或者是带人工智能技术的智能云计算服务器或智能云主机。

根据本申请实施例的技术方案，针对新出现的应用场景，用户不再需要从上层到下层进行全新的开发和适配，而是可以共享智能工作站提供的多种已有应用组件，快速定义能够用于该新出现的应用场景的业务应用，因而可以提高工作效率，并且可以提高各应用组件(包括AI算子组件，简称算子组件)的复用率；同时，基于用户自定义的业务应用，还可以自动预生成工作流，并对该工作流中的各个任务节点进行上、下游节点校验，以便保证工作流的正确性。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本申请公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。

Claims

1.一种用于业务应用的处理方法，包括：

确定预定义的多个业务应用；

基于所述多个业务应用，生成至少一个业务任务，其中每个业务任务中包含所述多个业务应用中的多个数据源和执行计划都相同的业务应用；以及

对所述每个业务任务中包含的业务应用进行批量控制；

其中，所述方法还包括：

在所述多个业务应用中存在至少两个业务应用需要在底层调用相同的算子服务的情况下，控制所述至少两个业务应用复用所述算子服务；

其中，控制所述至少两个业务应用复用所述算子服务包括：

控制所述至少两个业务应用复用所述算子服务的同一服务镜像；

其中，控制所述至少两个业务应用复用所述算子服务的同一服务镜像包括：

在针对所述至少两个业务应用中的每个业务应用，所述服务镜像的输入数据相同的情况下，控制所述服务镜像执行一次并向所述至少两个业务应用中的每个业务应用返回执行结果。

2.根据权利要求1所述的方法，还包括：针对所述每个业务任务，

在当前业务任务中存在针对不同业务方的至少两个相同的业务应用的情况下，在所述当前业务任务中合并所述至少两个相同的业务应用。

3.根据权利要求2所述的方法，其中，在所述当前业务任务中合并所述至少两个相同的业务应用，包括：

控制所述至少两个相同的业务应用在底层共用同一应用实例。

4.根据权利要求2所述的方法，其中，控制所述至少两个相同的业务应用在底层共用同一应用实例，包括：

获取所述应用实例针对所述至少两个相同的业务应用中的一个业务应用的执行结果；

将获取的执行结果发送至与所述至少两个相同的业务应用关联的所有业务方。

5.一种用于业务应用的处理装置，包括：

应用确定模块，用于确定预定义的多个业务应用；

任务生成模块，用于基于所述多个业务应用，生成至少一个业务任务，其中每个业务任务中包含所述多个业务应用中的多个数据源和执行计划都相同的业务应用；以及

批量控制模块，用于对所述每个业务任务中包含的业务应用进行批量控制；

其中，所述装置还包括：

复用控制模块，用于在所述多个业务应用中存在至少两个业务应用需要在底层调用相同的算子服务的情况下，控制所述至少两个业务应用复用所述算子服务；

其中，所述复用控制模块还用于：

6.根据权利要求5所述的装置，还包括：应用合并模块，用于针对所述每个业务任务，

7.根据权利要求6所述的装置，其中，所述应用合并模块，还用于

8.根据权利要求7所述的装置，其中，所述应用合并模块包括：

结果获取单元，用于获取所述应用实例针对所述至少两个相同的业务应用中的一个业务应用的执行结果；

结果发送单元，用于将获取的执行结果发送至与所述至少两个相同的业务应用关联的所有业务方。

9. 一种电子设备，其特征在于，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-4中任一项所述的方法。

10.一种存储有计算机指令的非瞬时计算机可读存储介质，其特征在于，所述计算机指令用于使所述计算机执行权利要求1-4中任一项所述的方法。

11.一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据权利要求1-4中任一项所述的方法。