CN111124708A - 面向微服务的批推理方法、服务器和计算机可读存储介质 - Google Patents

Abstract

本发明涉及深度学习技术领域，特别是涉及一种面向微服务的批推理方法、服务器和计算机可读存储介质。面向微服务的批推理方法包括：接收客户端发送的用户请求；将请求存入字典并添加到当前请求队列；等待子线程返回当前请求队列中所有请求对应的微服务的批推理结果；读取批推理结果；向客户端返回批推理结果。在实际的业务场景中，微服务之间往往是并发关系，使用框架级别的批推理无法对此进行优化，使用本发明提出的方案，可以节约并发场景下的无效等待时间，提升优化效果。

Description

面向微服务的批推理方法、服务器和计算机可读存储介质

技术领域

本发明涉及深度学习技术领域，特别是涉及一种面向微服务的批推理方法、、服务器和计算机可读存储介质。

背景技术

随着BERT、ERNIE、XLNET等大规模语言模型的问世，各种自然语言技术(文本分类、用户画像、知识图谱、命名实体识别、语义匹配、中文分词等)都逐渐基于此类模型，业务精度也随之不断提升。

由于BERT等语言模型中模型的参数越多，其在各个NLP(Natural LanguageProcessing，自然语言处理)任务上的精度也越高，进而导致训练和推理的资源消耗也越大。在当前业务耗时受约束、资源有限的条件下，如何支撑更大的流量成为大规模语言模型应用落地的一大难题。当前基于Tensorflow Serving的批推理框架兼容性较差，商业云解决方案必须购买云服务在云上实现，另外没有针对微服务本身的批推理方案。每个微服务的特点不同，业务逻辑也不同，目前并没有任何架构在云服务上提出通用的微服务级别的解决方案。因此，亟需一个微服务级别的批推理解决方案，在有限的资源约束下，支撑线上庞大的业务请求量。

发明内容

鉴于上述问题，提出了本发明实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种面向微服务的批推理方法、服务器和计算机可读存储介质。

为了解决上述问题，本发明实施例公开了一种一种面向微服务的批推理方法，其特征在于，包括：

接收客户端发送的用户请求；

将请求存入字典并添加到当前请求队列；

等待子线程返回当前请求队列中所有请求对应的微服务的批推理结果；

读取批推理结果；

向客户端返回批推理结果。

进一步地，等待子线程返回当前请求队列中所有请求对应的微服务的批推理结果包括：

等待子线程先确定当前请求队列符合进行批推理的条件，再返回当前请求队列中所有请求对应的微服务的批推理结果；其中，批推理的条件和微服务参数相关。

进一步地，微服务参数包括队列长度，符合进行批推理的条件包括：当前请求队列的长度等于预设的队列最大长度。

进一步地，微服务参数包括等待时间，符合进行批推理的条件包括：当前请求队列的等待时间达到预设的最长等待时间。

进一步地，等待子线程先确定当前请求队列符合进行批推理的条件，再返回当前请求队列中所有请求对应的微服务的批推理结果包括：

等待子线程通信返回的批推理结果；其中，子线程先确定当前请求队列符合进行批推理的条件，接着将当前请求队列中请求发送给各个模型对应的微服务由各个微服务单独进行批推理，然后获取所有微服务的批推理结果，根据请求对批推理结果进行拆分并将拆分后的批推理结果存入词典。

进一步地，子线程包括上游服务，其中，子线程将当前请求队列中请求发送给各个模型对应的微服务由各个微服务单独进行批推理包括：

子线程通过上游服务将当前请求队列中所有请求合并为一批请求，然后将该一批请求并发发送给各个模型对应的微服务由各个微服务单独进行批推理。

进一步地，所有微服务使用一个工作队列，该工作队列包括若干个请求队列。

进一步地，微服务包括：分类模型微服务、实体模型微服务、问答模型微服务、匹配模型微服务中的任意一个或多个。

本发明还提出一种服务器，服务器上设置有主线程，主线程可与若干个子线程进行通信，其特征在于，主线程包括：

接收单元，用于接收客户端发送的用户请求；

添加单元，用于将请求存入字典并添加到当前请求队列；

等待单元，用于等待子线程返回当前请求队列中所有请求对应的微服务的批推理结果；

读取单元，用于读取批推理结果；

返回单元，用于向客户端返回批推理结果。

本发明还提出一种服务器，其特征在于，包括：处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现上述任一项所述的面向微服务的批推理方法的步骤。

本发明还提出一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现上述任一项所述的面向微服务的批推理方法的步骤。

本发明实施例包括以下优点：

在实际的业务场景中，微服务之间往往是并发关系，使用框架级别的批推理无法对此进行优化，使用本发明提出的方案，可以节约并发场景下的无效等待时间，提升优化效果。

附图说明

图1是本发明的一种面向微服务的批推理方法实施例的步骤流程图；

图2是本发明的一种服务器实施例的结构框图；

图3是本发明单个微服务的批推理的示意图；

图4和图5是本发明并发场景下的微服务批推理在优化前和优化后的对比示意图；

图6是本发明单个微服务的批推理的效果对比图；

图7是本发明并发场景下的微服务批推理的效果对比图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

深度学习中推理服务通常是指将训练好的深度学习模型部署到云端，并对外提供gRPC/HTTP接口请求的服务。业界常用的深度学习推理服务框架包括Google的Tensorflowserving、Nvidia的Tensor RT inference server，Amazon的Elastic Inference等。

以上这些框架因为无法对并发场景下的批推理进行优化因而产生了多余的等待时间。

本发明实施例的核心构思之一在于，亟需一个微服务级别的批推理解决方案，在有限的资源约束下，支撑线上庞大的业务请求量。

参照图1，图1是本发明的一种面向微服务的批推理方法实施例的步骤流程图，具体可以包括如下步骤：

S1，接收客户端发送的用户请求；

S2，将请求存入字典并添加到当前请求队列；

S3，等待子线程返回当前请求队列中所有请求对应的微服务的批推理结果；

S4，读取批推理结果；

S5，向客户端返回批推理结果。

本方案中，字典用来保存请求和批推理结果。

如图2所示，本发明还提出了一种服务器，服务器上设置有主线程，主线程可与若干个子线程进行通信，其中，主线程包括：接收单元、添加单元、等待单元、读取单元和返回单元。各个单元的介绍如下：

接收单元，用于接收客户端发送的用户请求；

添加单元，用于将请求存入字典并添加到当前请求队列；

等待单元，用于等待子线程返回当前请求队列中所有请求对应的微服务的批推理结果；

读取单元，用于读取批推理结果；

返回单元，用于向客户端返回批推理结果。

具体地，面向微服务的批推理方法中，S1可以由主线程的接收单元实现，S2可以由添加单元实现，S3可以由等待单元实现，S4可以由读取单元实现，S5可以由返回单元实现。

本发明的一种面向微服务的批推理方法和服务器，通过主线程和子线程之间的通信，将主线程接收到的用户请求存入当前请求队列和字典，接收到字典通知后读取当前请求队列中所有请求对应的微服务的批推理结果，再进行分发；而子线程的作用是将当前请求队列的请求统一交付给对应的微服务并在满足条件后对请求进行批推理，将批推理的结果写入字典并通知主线程。

进一步地，面向微服务的批推理方法中，S3包括：等待子线程先确定当前请求队列符合进行批推理的条件，再返回当前请求队列中所有请求对应的微服务的批推理结果；其中，批推理的条件和微服务参数相关。

微服务参数包括队列长度和等待时间。可以预先依据微服务参数设定一个队列最大长度或最长等待时间中的任意一个或多个。

将由客户端发送的用户请求添加到当前请求队列后，在达到最长等待时间之前，当前请求队列长度不超过队列最大长度，则请求可以入队。若达到最大等待时间或队列长度达到最大，将当前请求队列中的所有请求进行批推理，并对结果进行分发。

即符合进行批推理的条件可以是：当前请求队列的长度等于预设的队列最大长度。

符合进行批推理的条件还可以是：当前请求队列的等待时间达到预设的最长等待时间。

设置队列最大长度过大，会导致机器内存不足，过小会导致批量任务吞吐量下降。队列最大长度的设置范围应考虑线上实际请求频率和机器内存大小。

设置最长等待时间过长，会导致服务延迟变慢，过短会导致批量任务吞吐量下降。最长等待时间的设置范围应考虑线上实际请求频率和处理本身时长。

通常，队列最大长度在50～150之间，最长等待时间在5～15ms之间效果较好。当然，也可以根据实际需要设置队列最大长度和最长等待时间，在此不做限制。

举例说明如图3。第一个请求队列达到最长等待时间，在t1时刻进行批推理，批大小为3；第二个请求队列达到队列最大长度，在t2时刻进行批推理，批大小为6。

具体地，主线程和子线程通信，等待子线程返回的批推理结果。

子线程先确定当前请求队列符合进行批推理的条件，即判断当前请求队列的队列长度或者等待时间，在当前请求队列的长度等于预设的队列最大长度，或者当前请求队列的等待时间达到预设的最长等待时间，视为当前请求队列符合进行批推理的条件。

子线程接着将当前请求队列中请求发送给各个模型对应的微服务由各个微服务单独进行批推理，然后获取所有微服务的批推理结果，根据请求对批推理结果进行拆分并将拆分后的批推理结果存入词典。

具体地，子线程包括上游服务，上游服务是专门用于处理请求合并和分发的微服务。并发微服务中，一个上游服务的下游有多个微服务，一条请求过来会同时发送给所有下游微服务，等待下游所有微服务返回结果后返回最终结果。

子线程将当前请求队列中请求发送给各个模型对应的微服务由各个微服务单独进行批推理包括：子线程通过上游服务将当前请求队列中所有请求合并为一批请求，然后将该一批请求并发发送给各个模型对应的微服务由各个微服务单独进行批推理。

本发明中，微服务包括：分类模型微服务、实体模型微服务、问答模型微服务、匹配模型微服务中的任意一个或多个。接下来通过单个微服务的批推理和多个微服务的批推理来进行对比说明：

1.在单个微服务进行批推理的情况中，上游服务将用户请求发送给对应的微服务，此次以分类模型微服务为例，分类模型微服务接收到请求后，对多个请求进行合并再进行统一的批推理。

2.在多个微服务批推理的情况中，以微服务包括：分类模型微服务、实体模型微服务、问答模型微服务和匹配模型微服务为例，子线程通过上游服务将当前请求队列中所有请求合并为一批请求，同时并发发送到不同模型的微服务中，由各个微服务单独进行批推理。

上述两者的区别在于，在单个微服务进行批推理的情况中单个微服务的所有逻辑都在这个微服务中；而在在多个微服务批推理的情况中，多个微服务的合并、分发逻辑单独启用一个微服务去处理，而各个模型微服务只保留批处理逻辑。这种批推理方法可以将端到端的等待时间缩为最短，理论最大值等待时间缩短为单个微服务批推理最大等待时间的一半。

进一步地，本发明的面向微服务的批推理方法中，所有微服务使用一个工作队列，该工作队列包括若干个请求队列。

在实际中，由于业务场景更加复杂，微服务之间往往是并发关系。框架级别的批推理无法对此进行优化因而产生多余的等待时间。

如图4所示，优化前每个微服务维护一个工作队列，单独做批推理，各个服务互不影响，但是这样每个工作队列中等待时间不一样，最终会产生多余的等待时间。

如图5所示，优化后所有微服务使用一个工作队列，统一做批推理，并发分发推理结果，由于这是针对于微服务级别批推理进行改进，因此节约了并发场景下的无效等待时间。

下面对批推理的应用效果做进一步说明：

在针对“单个微服务”的单条推理和批推理的应用中，使用的硬件环境和各个参数具体如下：

GPU：单卡TitanXP

批推理等待时间：15ms

队列最大长度：100

服务：单个微服务

测评工具：jmeter

评估模型：BERT(Bidirectional Encoder Representations fromTransformers，由Google提出的模型)

单个微服务的单条推理是指单个微服务在接收多条并发请求时，单个微服务会对请求排队，逐一进行请求的推理，每次返回一条请求的结果；批推理是指单个微服务在接收多条并发请求时，单个微服务会对请求排队，隔一段时间对队列中所有请求做统一一次推理，并对请求的结果进行分发。两者的输入和输出均相同，批推理比单条推理多了一个等待的逻辑，一般来说，包含一个最长等待时间和队列最大长度。

如图6所示，在请求量较少情况下，由于等待时间的关系，批推理会比单条推理耗时略长。而当请求量大于50次/秒时，应用批推理延迟降低2倍以上；在延迟不超过60ms时，应用批推理将吞吐量提升至两倍。

在针对并发场景下的批推理应用效果中，使用的硬件环境和各个参数具体如下：

GPU：单卡TitanXP

批推理等待时间：15ms

队列最大长度：100

服务：并发微服务(4个)

测评工具：jmeter

评估模型：BERT

并发微服务指一个上游微服务的下游有多个微服务，一条请求过来会同时发送给所有下游微服务，等待下游所有微服务返回结果后返回最终结果。并发微服务的批推理是指下游微服务的批推理的逻辑移到了上游微服务，所有请求在上游微服务中进行统一的排队和等待，下游微服务接收到多条请求后进行批量处理，最终结果返回给上游微服务，由上游微服务进行统一分发。为表述方便，本发明中，“单个微服务”的单条推理以“单条推理”作为简称；“单个微服务”的批推理以“批推理”作为简称；并发微服务的批推理以“并发批推理”作为简称，并且和“批推理”区分开，具体对比详见下面的表1。

表1

如图7所示，在并发业务逻辑的并发数为4时，并发批推理无论请求量多大，效果均优于(单个微服务的)批推理，在请求量较少的情况下，并发批推理延迟与单条推理接近。而在请求量达到200次/秒以上时，并发批推理将延迟降低4倍以上，在延迟不超过55ms时，并发批推理将吞吐量提升了近四倍。

综上所述，使用本发明提出的方案，可以节约并发场景下的无效等待时间，提升优化效果。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。

如图2所示，本发明还提出了一种服务器，服务器上设置有主线程，主线程可与若干个子线程进行通信，其中，主线程包括：接收单元、添加单元、等待单元、读取单元和返回单元。各个单元的介绍如下：

接收单元，用于接收客户端发送的用户请求；

添加单元，用于将请求存入字典并添加到当前请求队列；

等待单元，用于等待子线程返回当前请求队列中所有请求对应的微服务的批推理结果；

读取单元，用于读取批推理结果；

返回单元，用于向客户端返回批推理结果。

在本发明提出的服务器中，等待单元具体用于等待子线程先确定当前请求队列符合进行批推理的条件，再返回当前请求队列中所有请求对应的微服务的批推理结果；其中，批推理的条件和微服务参数相关。

具体地，在本发明提出的服务器中微服务参数包括队列长度，符合进行批推理的条件包括：当前请求队列的长度等于预设的队列最大长度。

具体地，在本发明提出的服务器中微服务参数包括等待时间，符合进行批推理的条件包括：当前请求队列的等待时间达到预设的最长等待时间。

进一步地，等待单元具体用于：等待子线程通信返回的批推理结果；其中，子线程先确定当前请求队列符合进行批推理的条件，接着将当前请求队列中请求发送给各个模型对应的微服务由各个微服务单独进行批推理，然后获取所有微服务的批推理结果，根据请求对批推理结果进行拆分并将拆分后的批推理结果存入词典。

具体地，在本发明提出的服务器中，所有微服务使用一个工作队列，该工作队列包括若干个请求队列。

具体地，在本发明提出的服务器中，微服务包括：分类模型微服务、实体模型微服务、问答模型微服务、匹配模型微服务中的任意一个或多个。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本发明实施例还提供了一种服务器，包括：处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，该计算机程序被处理器执行时实现上述面向微服务的批推理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

本发明实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储计算机程序，计算机程序被处理器执行时实现上述面向微服务的批推理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本发明实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本发明所提供的面向微服务的批推理方法、服务器和计算机可读存储介质，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (11)

1.一种面向微服务的批推理方法，其特征在于，包括：

接收客户端发送的用户请求；

将请求存入字典并添加到当前请求队列；

等待子线程返回当前请求队列中所有请求对应的微服务的批推理结果；

读取批推理结果；

向客户端返回批推理结果。

2.如权利要求1所述面向微服务的批推理方法，其特征在于，等待子线程返回当前请求队列中所有请求对应的微服务的批推理结果包括：

等待子线程先确定当前请求队列符合进行批推理的条件，再返回当前请求队列中所有请求对应的微服务的批推理结果；其中，批推理的条件和微服务参数相关。

3.如权利要求2所述面向微服务的批推理方法，其特征在于，微服务参数包括队列长度，符合进行批推理的条件包括：当前请求队列的长度等于预设的队列最大长度。

4.如权利要求2所述面向微服务的批推理方法，其特征在于，微服务参数包括等待时间，符合进行批推理的条件包括：当前请求队列的等待时间达到预设的最长等待时间。

5.如权利要求3或4所述面向微服务的批推理方法，其特征在于，等待子线程先确定当前请求队列符合进行批推理的条件，再返回当前请求队列中所有请求对应的微服务的批推理结果包括：

等待子线程通信返回的批推理结果；其中，子线程先确定当前请求队列符合进行批推理的条件，接着将当前请求队列中请求发送给各个模型对应的微服务由各个微服务单独进行批推理，然后获取所有微服务的批推理结果，根据请求对批推理结果进行拆分并将拆分后的批推理结果存入词典。

6.如权利要求5所述面向微服务的批推理方法，其特征在于，子线程包括上游服务，其中，子线程将当前请求队列中请求发送给各个模型对应的微服务由各个微服务单独进行批推理包括：

子线程通过上游服务将当前请求队列中所有请求合并为一批请求，然后将该一批请求并发发送给各个模型对应的微服务由各个微服务单独进行批推理。

7.如权利要求1所述面向微服务的批推理方法，其特征在于，所有微服务使用一个工作队列，该工作队列包括若干个请求队列。

8.如权利要求1所述面向微服务的批推理方法，其特征在于，微服务包括：分类模型微服务、实体模型微服务、问答模型微服务、匹配模型微服务中的任意一个或多个。

9.一种服务器，服务器上设置有主线程，主线程可与若干个子线程进行通信，其特征在于，主线程包括：

接收单元，用于接收客户端发送的用户请求；

添加单元，用于将请求存入字典并添加到当前请求队列；

等待单元，用于等待子线程返回当前请求队列中所有请求对应的微服务的批推理结果；

读取单元，用于读取批推理结果；

返回单元，用于向客户端返回批推理结果。

10.一种服务器，其特征在于，包括：处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1-8中任一项所述的面向微服务的批推理方法的步骤。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现如权利要求1至8中任一项所述的面向微服务的批推理方法的步骤。

Images