技术领域
[0001] 本申请涉及通信技术，尤其涉及一种模型推理进程组构建方法及模型推理方法。
相关背景技术
[0002] 随着深度学习技术的发展，为了获得更高的预测精度，深度学习模型的规模日益增大，其参数量已攀升至百亿乃至千亿级别。以FP16精度存储的百亿级别大型模型，其内存占用可达20GB，这不仅接近甚至超过了多数加速器片上存储的限制，而且由于其巨大的计算负担，仅依赖单一设备进行模型推理难以满足实时性的需求。尽管可以通过多设备分布式推理的方式来处理这些大型模型，但现有的分布式推理方案往往面临着资源利用率较低的问题。
[0003] 因此，如何提高分布式推理大型深度学习模型的资源利用率是亟需解决的问题。
具体实施方式
[0065] 这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
[0066] 首先对本申请所涉及的专业术语进行解释：
[0067] 分布式软件系统：指支持分布式处理的软件系统，在由通信网络互联的多处理机体系结构上执行任务。分布式软件系统可以包括分布式操作系统、分布式文件系统、分布式数据库系统等。
[0068] 动态合批(Dynamic batching)：指在模型推理过程中，根据一定的规则或条件，动态地将多个推理请求合并成一个批次进行处理，通过动态合批，可以减少推理过程中的计算次数和资源消耗，从而提高推理速度和吞吐量。
[0069] 张量并行(Tensor Parallelism)：是一种利用并行计算来加速深度学习训练的技术，该技术通过将神经网络中的张量分割成多个子张量，并在不同的处理器或计算单元上并行计算。这种方法比传统的数据并行更加灵活和高效，可以在更细粒度的层次上进行并行计算，有效利用硬件资源，并减少通信开销。
[0070] 3D并行(3D Parallelism)：是一种并行处理技术，主要应用于三维模型处理、大规模数据处理或深度学习训练等计算密集型任务。它通过结合不同的并行策略来加速处理过程，提高工作效率。
[0071] 在当前技术背景下，深度学习模型的规模日益扩大，其参数量已达到百亿甚至千亿级别。这种大型模型在进行推理时，若仅依赖单一设备，往往难以满足实时性的需求。因此，目前普遍采用多设备分布式推理的方式来处理这些大型模型，以期提高推理效率并满足实时性要求。
[0072] 然而，目前在实际操作中通过多设备分布式推理大型深度学习模型时，普遍采用单服务进程挂载一个GPU进行推理。但是，对于参数量较大的模型，单个GPU可能无法完整加载整个模型进行推理。而对于参数量较小的模型，模型加载完毕后，GPU的算力和显存又无法得到充分利用，导致了GPU资源的利用率较低的问题。
[0073] 此外，在分布式推理过程中，如何合理地将大型模型分割成多个部分，并分配到不同的计算节点上，也是一个亟待解决的问题。不合理的模型分割可能会导致某些节点过载，而其他节点则处于空闲状态，从而造成资源利用的不均衡。同时，分布式推理还涉及大量的节点间通信，模型巨大的内存占用意味着在推理过程中需要传输大量数据。通信延迟和带宽限制很可能成为性能的瓶颈，进一步降低整体资源的利用率。
[0074] 有鉴于此，本申请提供了一种模型推理方法，通过将多个模型推理请求执行动态合批操作，生成批量请求集合。并将批量请求集合输入将模型多层切割后分配在多个GPU和CPU上的模型推理进程组中，以通过该多个GPU和CPU的协作，并行处理完成模型推理过程，获得模型推理请求对应的模型推理结果。本申请的方法，优化了多个GPU和CPU之间的协同机制，在模型推理过程中将部分计算任务从GPU上移动到CPU上，提高了GPU和CPU资源利用率，从而提升了模型推理过程的资源利用率。
[0075] 为了便于理解，首先对本申请实施例提供的模型推理方法的场景进行详细的介绍。
[0076] 图1为本申请提供的一种模型推理方法的场景示意图。如图1所示，该场景包括：用户端、服务端。
[0077] 其中，该用户端用于为用户提供模型推理服务，即模型推理系统的前端。该用户端可以是实现以上功能的软件程序，或者可以是部署了该软件程序的电子设备。该电子设备例如可以是手机、电脑、平板电脑等设备。
[0078] 该服务端负责根据接到的来自用户端的模型推理请求执行模型推理过程。该服务端例如可以是模型推理系统的后端服务器、云平台等。在服务端中，包括多个计算节点。该计算节点为分布式软件系统(如云计算环境、高性能计算集群等)中执行计算任务的独立单元。每个计算节点通常具备处理能力和存储空间，可以运行深度学习模型的推理任务。每个计算节点下包括多个用于进行模型推理的GPU，这些GPU分别负责处理一部分模型的推理计算，实现高效的模型推理并行计算。
[0079] 服务端在接收到用户端发送的模型推理请求后，将多个用户请求动态合批为批量请求集合。服务端将批量请求集合输入部署在多个GPU上的模型推理进程组中，该多个GPU与服务端的CPU进行协作，并行处理以完成模型推理过程，获得模型推理请求对应的模型推理结果，并将模型推理结果返回至对应的用户端中。
[0080] 下面以执行主体为作为服务端的服务器为例，结合具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。
[0081] 图2为本申请实施例提供的一种模型推理方法的流程示意图。如图2所示，该方法可以包括：
[0082] S201、接收待推理模型的M个模型推理请求，并将M个模型推理请求缓存至第一共享变量中。
[0083] 其中，该待推理模型例如可以是用于各种用途的包括多层结构的深度学习模型。例如，该待推理模型可以是用于文本创作、智能对话、机器翻译等高级语言处理任务的自然语言处理模型；或者，该待推理模型可以是用于图像分类、目标检测等用途的大型图像识别图形等；又或者，该待推理模型可以是用于自动驾驶、智能助手等领域的大型深度学习模型。本申请对此不做限制。该模型推理请求用于请求通过待推理模型处理该模型推理请求中的需求，例如可以是请求通过自然语言处理模型进行文本创作的请求。
[0084] 其中，该M个模型推理请求来自模型推理系统的用户端。服务器接收一个或多个用户端发送的M个模型推理请求，并输入用于暂时存储模型推理请求的第一共享变量中。
[0085] 服务器可以在接收模型推理请求之前，初始化Web服务进程，创建第一共享变量，以通过第一共享变量缓存待进行动态合批的M个模型推理请求。具体地，服务器可以创建模型推理主进程，以及，根据服务器中GPU总数量，创建多个工作进程进行模型推理。例如，该工作进程的数量可以是服务器中GPU总数量的两倍。在完成通信初始化后，通过各Web服务进程接收不同用户端发送的模型推理请求，并将模型推理请求缓存至第一共享变量中等待进行动态合批。
[0086] S202、根据M个模型推理请求的等待时长，以及，动态合批进程的批次数量上限，将M个模型推理请求动态合批为若干个批量请求集合。
[0087] 记录接收每个模型推理请求的时间，根据当前时间和接收模型推理请求的时间计算每个请求的等待时长。
[0088] 根据每个请求的等待时长，以及，动态合批进程的批次数量上限(即每个批量请求集合中最多包含的请求数量)，动态调整合批的策略。例如，如果某些请求的等待时长超过了预设的阈值，或者系统的负载较低，可以触发合批操作。
[0089] 从第一共享变量中取出等待中的模型推理请求。根据请求的等待时长和批次数量上限，将请求动态合批为若干个批量请求集合。
[0090] S203、将若干个批量请求集合输入模型推理进程组中，生成若干个批量请求集合对应的模型推理结果。
[0091] 其中，该模型推理进程组配置在模型推理系统中的至少两个计算节点中、且每个计算节点中的至少两个GPU上。通过该模型推理进程组，能够通过3D并行的方式进行模型推理。该模型推理进程组的构建方法可以参照后续图4‑图8实施例的描述，此处不进行赘述。
[0092] 将动态合批后得到的若干个批量请求集合分配给模型推理进程组中的不同进程或线程进行处理。每个进程或线程接收到批量请求集合后，使用加载的模型对集合中的每个请求进行推理计算。生成若干个批量请求集合对应的模型推理结果。
[0093] S204、输出模型推理结果。
[0094] 一种可能的实现方式，直接输出模型推理结果。
[0095] 另一种可能的实现方式，缓存输出的所有模型推理结果，并根据模型推理结果与模型推理请求的对应关系，确定需要接收模型推理结果的用户端，将该模型推理结果从缓存中提取出来，以返回至该发出模型推理请求的用户端。
[0096] 下面，对前述步骤S204中具体如何输出模型推理结果进行详细介绍。图3为本申请实施例提供的另一种模型推理方法的流程示意图。如图3所示，前述步骤S204可以包括：
[0097] S301、将模型推理结果缓存至第二共享变量中。
[0098] 其中，该第二共享变量用于等待模型推理主进程从第二共享变量内循环提取模型推理结果，并依次将模型推理结果发送至模型推理结果对应的Web服务进程，以返回至该发出模型推理请求的用户端。
[0099] S302、从第二共享变量中循环获取模型推理结果，并将模型推理结果发送至模型推理结果对应的Web服务进程。
[0100] 本申请实施例提供的方法，通过接收待推理模型的M个模型推理请求，并将M个模型推理请求缓存至第一共享变量中，根据M个模型推理请求的等待时长，以及，动态合批进程的批次数量上限，将M个模型推理请求动态合批为若干个批量请求集合。将若干个批量请求集合输入配置在模型推理系统中的至少两个计算节点中、且每个计算节点中的至少两个GPU上的模型推理进程组中，生成若干个批量请求集合对应的模型推理结果，并将多个将模型推理结果缓存至第二共享变量中，通过模型推理主进程从第二共享变量中循环获取模型推理结果，并将模型推理结果发送至模型推理结果对应的Web服务进程，从而通过动态合批和3D并行的方式，提高了GPU和CPU资源利用率，从而提升了模型推理过程的资源利用率。
[0101] 下面，对前述模型推理方法中的模型推理进程组的构建方法进行详细介绍。该模型推理进程组的构建方法的执行主体可以为该执行模型推理过程的服务端的服务器，也可以是与该服务器连接的其他计算设备。若执行主体是与该服务器连接的其他计算设备，则可以在该计算设备完成模型推理进程组的构建后，将该模型推理进程组对应的参数配置到服务器中的计算节点上，以使服务器能够根据该模型推理进程组进行模型推理。
[0102] 图4为本申请实施例提供的一种模型推理进程组构建方法的流程示意图。如图4所示，该方法可以包括：
[0103] S401、获取模型推理系统的环境信息、待推理模型的模型信息。
[0104] 其中，该模型推理系统的环境信息包括模型推理系统中的至少两个计算节点的信息，各计算节点中包括至少两个GPU。该待推理模型的模型信息包括待推理模型的模型结构信息，模型结构信息中包括待推理模型每层的模型参数大小。
[0105] 该环境信息中具体可以包括计算节点信息(例如计算节点数量、计算节点的计算能力)。对于每个计算节点的计算节点信息，其可以包括该计算节点中包括的GPU数量、各GPU的显存、各GPU的计算能力等信息。该模型推理系统的环境信息可以通过系统调用或系统接口等获取，或者可以从第三方设备中获取预存储的该环境信息等。
[0106] 该待推理模型的模型结构信息可以通过加载待推理模型的配置文件或直接从模型中解析的方式获取。当直接从模型中解析模型结构信息时，可以通过提取模型的层数、模型中每一层的参数大小(例如权重矩阵的维度、偏置项等)获取该待推理模型的模型结构信息。
[0107] S402、根据计算节点的数量、各计算节点中的GPU数量、以及模型结构信息，将待推理模型切割为N个张量。
[0108] 其中，N为大于或等于4的整数。
[0109] 根据计算节点的数量、各计算节点中的GPU数量，计算确定切割待推理模型生成的张量的数量N。
[0110] 一种可能的实现方式，可以将模型推理系统中所有计算节点的数量和各计算节点中的GPU数量相乘，获得GPU的总数量，将该GPU的总数量作为切割待推理模型生成的张量的数量N。在该实现方式下，仅通过张量并行的方式进行该待推理模型的并行运算。
[0111] 另一种可能的实现方式，可以仅根据模型推理系统中部分计算节点的数量和这些计算节点中的GPU数量相乘，获得GPU的总数量，将该GPU的总数量作为切割待推理模型生成的张量的数量N。
[0112] 可选的，基于上述两种实现方式，还可以根据计算节点的数量先将待推理模型分割为多个子模型，构建子模型与计算节点的对应关系。再将各子模型切割为多个张量，分配至计算节点下的各GPU上。
[0113] 在切割待推理模型时，根据待推理模型的结构，包括各层的类型(如卷积层、池化层、全连接层等)和参数数量，评估模型中不同部分的计算复杂度和数据依赖性。根据计算复杂度和数据依赖性确定切割点，这些点应选在模型的不同层之间，以确保切割后的每个张量都能独立进行计算，同时保持数据的逻辑完整性。
[0114] 在一种可能的实现方式下，在切割待推理模型为N个张量时，除了考虑确保切割后的每个张量都能独立进行计算、保持数据的逻辑完整性之外，还根据该待推理模型的各层参数量，将待推理模型切割为N个参数量差异小于预设差异阈值的张量，以均衡各GPU并行计算时的负载，提高推理效率和资源利用率。
[0115] S403、根据张量的算力需求，以及，各GPU的显存，将N个张量分配至至少4个GPU上。
[0116] 根据每个张量的计算需求和显存占用情况，以及每个GPU的计算能力和显存大小，将张量合理地分配到与其计算需求和显存占用情况的GPU上，从而确保每个GPU上的负载相对均衡，以充分利用计算资源并提高推理速度。其中，每个张量的计算需求可以通过分析张量所包含的层的类型和参数数量来确定。
[0117] 例如，可以根据每个GPU的显存大小和计算能力，制定对应的分配策略。该分配策略能够最大化GPU的利用率，同时避免任何可能的显存溢出。
[0118] S404、将张量中目标模型神经元转移分配至CPU中。
[0119] 其中，目标模型神经元为对待推理模型的模型生成影响小于预设影响阈值的模型神经元。
[0120] 通过模型分析技术(如剪枝、量化等技术)评估模型中各个神经元对最终输出的影响。若神经元对模型的最终输出的影响小于预设影响阈值，则表征该神经元转移到CPU上处理后，不会对模型的整体性能产生显著影响。此时可以将该神经元确定为目标模型神经元，将该目标模型神经元转移(offload)到CPU上处理，能够降低对GPU的显存占用，减轻GPU的负载。
[0121] 具体的，可以通过使用深度学习框架提供的接口或工具，将这些目标模型神经元从GPU计算图中移除，并重新配置为在CPU上执行。
[0122] S405、根据各张量，以及，各目标模型神经元，生成模型推理进程组。
[0123] 其中，该模型推理进程组用于并行实现待推理模型的推理。
[0124] 对于每个分配到GPU的张量，创建该张量对应的独立的推理进程，对于转移到CPU处理的目标模型神经元，也创建相应的处理进程。通过进程间通信机制(例如共享内存、消息队列、网络通信等)，根据模型结构来协调各个进程之间的数据交换和同步操作，以实现模型推理的功能。
[0125] 本申请实施例提供的方法，通过获取模型推理系统的环境信息、待推理模型的模型信息，根据计算节点的数量、各计算节点中的GPU数量、以及模型结构信息，将待推理模型切割为N个张量。根据张量的算力需求，以及，各GPU的显存，将N个张量分配至多个GPU上，并将张量中对模型生成影响较小的目标模型神经元转移分配至CPU中，根据各张量，以及，各目标模型神经元，生成模型推理进程组，从而优化了多个GPU和CPU之间的协同机制，在模型推理过程中通过GPU对分割后的模型进行并行计算，并将部分计算任务从GPU上移动到CPU上，提高了GPU和CPU资源利用率，从而提升了模型推理过程的资源利用率。
[0126] 下面，以多次分割模型为例，对前述步骤S402中如何根据计算节点的数量、各计算节点中的GPU数量、以及模型结构信息，将待推理模型切割为N个张量进行详细介绍。图5为本申请实施例提供的另一种模型推理进程组构建方法的流程示意图。如图5所示，前述步骤S402可以包括：
[0127] S501、根据计算节点的数量、以及模型结构信息，将待推理模型切割为至少两个子模型。
[0128] 首先，根据计算节点的数量，计算确定切割待推理模型生成的子模型的数量。
[0129] 一种可能的实现方式，可以根据模型推理系统中所有计算节点的数量确定子模型的数量。例如模型推理系统中包括4个计算节点，则可以将待推理模型切割为4个子模型。其中，每个子模型后续可以分配至不同的计算节点上。
[0130] 另一种可能的实现方式，可以根据模型推理系统中部分计算节点的数量确定子模型的数量。例如模型推理系统中包括4个计算节点，则可以将待推理模型切割为2个子模型。其中，该2个子模型后续可以分配至该4个计算节点中的2个计算节点上。
[0131] 在确定切割待推理模型生成的子模型的数量后，根据模型结构信息将待推理模型切割对应数量个子模型。
[0132] 具体的，可以根据待推理模型的结构，包括各层的类型(如卷积层、池化层、全连接层等)和参数数量，评估模型中不同部分的计算复杂度和数据依赖性。根据计算复杂度和数据依赖性确定切割点，这些点应选在模型的不同层之间，以确保切割后的每个子模型都能独立进行计算，同时保持数据的逻辑完整性。
[0133] 进一步地，在切割待推理模型为多个子模型时，除了考虑确保切割后的每个子模型都能独立进行计算、保持数据的逻辑完整性之外，还根据该待推理模型的各层参数量，将待推理模型切割为多个参数量差异小于预设阈值的子模型，以均衡各计算节点并行计算时的负载，提高推理效率和资源利用率。
[0134] S502、根据子模型的算力需求，以及，各计算节点的算力，将至少两个子模型分配至至少两个计算节点上。
[0135] 其中，至少两个子模型为流水线并行子模型。
[0136] 通过对各子模型进行性能分析，以确定该子模型的算力需求。例如，可以通过对各子模型的参数量和结构的分析，估算推理该子模型所需的算力。通过各计算节点的硬件配置(例如计算节点中的GPU性能、GPU数量、CPU性能、内存大小等)，计算该计算节点的算力。
[0137] 将各子模型的算力需求和各计算节点的算力进行匹配，将各子模型分配到能够满足其计算需求的计算节点上。例如，可以生成子模型序列，以及，计算节点序列，从算力需求最高的子模型开始，依次匹配到算力最高的可用计算节点，直到所有子模型都被分配。
[0138] 进一步地，在考虑各子模型的算力需求和各计算节点的算力的基础上，还可以考虑各子模型之间的依赖关系和计算节点之间的传输效率进行子模型的分配。例如，子模型A的输出是子模型B和子模型C的输入，则子模型A、B、C之间的数据传输效率要求较高，需要将子模型B和子模型C分别分配至与子模型A对应的计算节点A之间数据传输效率较高的计算节点B和计算节点C上。
[0139] S503、在计算节点中，根据计算节点中的GPU数量、以及子模型的结构信息，将子模型切割为至少两个张量。
[0140] 其中，至少两个张量为并行张量。该将子模型切割为至少两个张量的方式可以参照前述步骤S402中将待推理模型分割为N个张量的方法，此处不再赘述。
[0141] 本申请实施例提供的方法，通过将待推理模型切割为多个子模型，将各子模型分配至不同的计算节点。并将每个子模型切割为多个张量，不同的张量分配至该子模型对应的计算节点中的不同GPU上，实现计算节点并行以及计算节点中GPU并行的计算结构，从而进一步提升了模型推理过程中的资源利用率。
[0142] 下面，对前述步骤S404中具体如何将所述张量中目标模型神经元转移分配至CPU中进行详细介绍。
[0143] 方式1：根据张量中包括的模型神经元的输入权重确定目标模型神经元。
[0144] 图6为本申请实施例提供的又一种模型推理进程组构建方法的流程示意图。如图6所示，前述步骤S404可以包括：
[0145] S601、获取张量中包括的模型神经元的输入权重。
[0146] 其中，该模型神经元为待推理模型的全连接层中的模型神经元。全连接层是深度学习模型中的一个重要组成部分，全连接层中的每一个神经元都与前一层中的所有神经元相连。模型神经元的输入权重表征该神经元对前一层神经元输出的依赖程度。
[0147] 通过模型的架构或配置文件，确定待推理模型中全连接层的位置。根据全连接层的位置，从模型的参数中提取出全连接层中每个神经元的输入权重。该输入权重通常以矩阵的形式存储，其中每一行或每一列代表一个神经元的输入权重。
[0148] S602、若输入权重小于或等于预设权重阈值，则将模型神经元确定为目标模型神经元。
[0149] 其中，预设权重阈值用于判断哪些模型神经元的输入权重较小，对模型输出的影响有限，该预设权重阈值可以根据实际需求确定，本申请对此不做限制。若输入权重小于或等于预设权重阈值，则表征该模型神经元对模型的输出影小于预期，将该模型神经元转移到CPU中进行处理也不会对模型推理过程和模型输出造成显著性影响。
[0150] 根据输入权重与预设权重阈值的比较，将输入权重小于或等于预设权重阈值的模型神经元确定为目标模型神经元，待后续将该目标模型神经元转移到CPU中进行推理计算。
[0151] S603、将张量中目标模型神经元转移分配至CPU中。
[0152] 通过将目标模型神经元的相关数据(包括权重、偏置等参数)从GPU的内存中复制到CPU的内存中，并更新模型的计算图，确保在后续的推理过程中，这些目标模型神经元的计算任务能够在CPU上正确执行。
[0153] 方式2：根据张量中包括的模型神经元的输出结果的归一化差异确定目标模型神经元。
[0154] 图7为本申请实施例提供的再一种模型推理进程组构建方法的流程示意图。如图7所示，前述步骤S404可以包括：
[0155] S701、获取张量中包括的模型神经元的输出结果的归一化差异。
[0156] 获取该张量中每个模型神经元的输出结果。对各输出结果进行归一化处理，例如可以将各输出结果归一化至0到1的范围内，或者可以计算输出结果的标准分数(即用该输出结果减去该张量中所有输出结果的平均值后，除以这些输出结果的标准差)。通过归一化处理，生成张量中包括的模型神经元的输出结果的归一化结果，并将该归一化结果与预设基准(例如所有输出结果的平均值、中位数等)进行比较，获取各模型神经元的输出结果的归一化差异。
[0157] S702、若归一化差异小于或等于预设差异阈值，则将模型神经元确定为目标模型神经元。
[0158] 其中，预设差异阈值用于判断哪些模型神经元的归一化差异较小，对模型输出的影响有限，该预设差异阈值可以根据实际需求确定，本申请对此不做限制。若归一化差异小于或等于预设差异阈值，则表征该模型神经元对模型的输出影小于预期，将该模型神经元转移到CPU中进行处理也不会对模型推理过程和模型输出造成显著性影响。
[0159] 根据归一化差异与预设差异阈值的比较，将归一化差异小于或等于预设差异阈值的模型神经元确定为目标模型神经元，待后续将该目标模型神经元转移到CPU中进行推理计算。
[0160] S703、将张量中目标模型神经元转移分配至CPU中。
[0161] 通过将目标模型神经元的相关数据(包括权重、偏置等参数)从GPU的内存中复制到CPU的内存中，并更新模型的计算图，确保在后续的推理过程中，这些目标模型神经元的计算任务能够在CPU上正确执行。
[0162] 本申请实施例提供的方法，通过将张量中对模型生成影响较小的目标模型神经元转移分配至CPU中进行后续计算，优化了多个GPU和CPU之间的协同机制，降低了GPU的显存占用率，从而提高了GPU和CPU资源利用率，提升了模型推理过程的资源利用率。
[0163] 在一种可能的实现方式下，还可以通过在模型推理系统中进行数据并行的方式，进一步提升模型推理效率和资源利用率。下面对如何在模型推理系统中进行数据并行进行详细介绍。
[0164] 图8为本申请实施例提供的再一种模型推理进程组构建方法的流程示意图。如图8所示，该方法还可以包括：
[0165] S801、根据各张量，以及，各目标模型神经元，生成第一模型推理进程组。
[0166] 其中，第一模型推理进程组配置在模型推理系统中的部分计算节点上。这部分计算节点的数量小于或等于该模型推理系统种计算节点总数量的一半。例如，模型推理系统中包括8个计算节点，则该第一模型推理进程组所在的计算节点的数量小于或等于4个。
[0167] 该根据各张量，以及，各目标模型神经元，生成第一模型推理进程组的方法可以参照前述图4至图7中描述的任意一种方法，此处不再赘述。
[0168] S802、将第一模型推理进程组的参数复制到模型推理系统中其他计算节点中，生成第二模型推理进程组。
[0169] 其中，第二模型推理进程组为第一模型推理进程组的并行模型推理进程组，其他计算节点的数量与第一模型推理进程组所占用的计算节点的数量相同。
[0170] 获取第一模型推理进程组所在的计算节点的参数，并复制这些计算节点的参数配置到模型推理系统中未配置第一模型推理进程组的计算节点上，以在模型推理系统中配置第一模型推理进程组和第二模型推理进程组两个能够并行推理数据的模型推理进程组。
[0171] 示例性的，假设模型推理系统中包括8个计算节点，第一模型推理进程组配置在模型推理系统中的节点1至节点4上。则可以复制第一模型推理进程组的参数至节点5至节点8上(例如节点1复制到节点5、节点2复制到节点6、节点3复制到节点7，节点4复制到节点8)。这样，便能够在模型推理系统中配置两个能够并行推理数据的模型推理进程组。
[0172] 可选的，也可以在模型推理系统中配置更多个能够并行推理数据的模型推理进程组，这取决于具体的并行需求、模型推理系统中的计算节点数量、以及、待推力模型的结构、待推力模型的参数量等因素，本申请对数据并行的模型推理进程组数量不做限制。
[0173] S803、根据第一模型推理进程组和第二模型推理进程组，生成模型推理进程组。
[0174] 本申请实施例提供的方法，根据各张量，以及，各目标模型神经元，生成第一模型推理进程组，将第一模型推理进程组的参数复制到模型推理系统中其他计算节点中，生成第二模型推理进程组，根据第一模型推理进程组和第二模型推理进程组，生成模型推理进程组，以在模型推理系统中配置更多个能够并行推理数据的模型推理进程组，从而进一步提高了模型推理的效率。
[0175] 图9为本申请实施例提供的一种模型推理进程组构建装置的结构示意图。如图9所示，该装置可以包括：获取模块11，处理模块12，控制模块13，生成模块14。
[0176] 获取模块11，用于获取模型推理系统的环境信息、待推理模型的模型信息，环境信息包括模型推理系统中的至少两个计算节点的信息，各计算节点中包括至少两个GPU。模型信息包括待推理模型的模型结构信息，模型结构信息中包括待推理模型每层的模型参数大小。
[0177] 处理模块12，用于根据计算节点的数量、各计算节点中的GPU数量、以及模型结构信息，将待推理模型切割为N个张量，根据张量的算力需求，以及，各GPU的显存，将N个张量分配至至少4个GPU上，N为大于或等于4的整数。
[0178] 控制模块13，用于将张量中目标模型神经元转移分配至CPU中，目标模型神经元为对待推理模型的模型生成影响小于预设影响阈值的模型神经元。
[0179] 生成模块14，用于根据各张量，以及，各目标模型神经元，生成模型推理进程组，模型推理进程组用于并行实现待推理模型的推理。
[0180] 可选的，处理模块12，具体用于根据计算节点的数量、以及模型结构信息，将待推理模型切割为至少两个子模型。根据子模型的算力需求，以及，各计算节点的算力，将至少两个子模型分配至至少两个计算节点上。在计算节点中，根据计算节点中的GPU数量、以及子模型的结构信息，将子模型切割为至少两个张量，至少两个张量为并行张量，至少两个子模型为流水线并行子模型。
[0181] 可选的，处理模块12，具体用于获取张量中包括的模型神经元的输入权重，若输入权重小于或等于预设权重阈值，则将模型神经元确定为目标模型神经元。将张量中目标模型神经元转移分配至CPU中，模型神经元为待推理模型的全连接层中的模型神经元。
[0182] 可选的，处理模块12，具体用于获取张量中包括的模型神经元的输出结果的归一化差异。若归一化差异小于或等于预设差异阈值，则将模型神经元确定为目标模型神经元。将张量中目标模型神经元转移分配至CPU中。
[0183] 可选的，生成模块14，具体用于根据各张量，以及，各目标模型神经元，生成第一模型推理进程组。将第一模型推理进程组的参数复制到模型推理系统中其他计算节点中，生成第二模型推理进程组。根据第一模型推理进程组和第二模型推理进程组，生成模型推理进程组，第二模型推理进程组为第一模型推理进程组的并行模型推理进程组，其他计算节点的数量与第一模型推理进程组所占用的计算节点的数量相同。
[0184] 本申请实施例提供的模型推理进程组构建装置，可以执行上述方法实施例中的模型推理进程组构建方法，其实现原理和技术效果类似，在此不再赘述。
[0185] 图10为本申请实施例提供的一种模型推理装置的结构示意图。如图10所示，该装置可以包括：接收模块21，控制模块22，处理模块23，输出模块24。
[0186] 接收模块21，用于接收待推理模型的M个模型推理请求，并将M个模型推理请求缓存至第一共享变量中。
[0187] 控制模块22，用于根据M个模型推理请求的等待时长，以及，动态合批进程的批次数量上限，将M个模型推理请求动态合批为若干个批量请求集合。
[0188] 处理模块23，用于将若干个批量请求集合输入模型推理进程组中，生成若干个批量请求集合对应的模型推理结果，模型推理进程组为如前述方法实施例中任一项的模型推理进程组。
[0189] 输出模块24，用于输出模型推理结果。
[0190] 可选的，输出模块24，具体用于将模型推理结果缓存至第二共享变量中。从第二共享变量中循环获取模型推理结果，并将模型推理结果发送至模型推理结果对应的Web服务进程。
[0191] 本申请实施例提供的模型推理装置，可以执行上述方法实施例中的模型推理方法，其实现原理和技术效果类似，在此不再赘述。
[0192] 图11为本申请实施例提供的一种电子设备的结构示意图。其中，该电子设备用于执行前述所说的模型推理方法和/或模型推理进程组构建方法，例如可以是前述所说的服务端的服务器。如图11所示，该电子设备1100可以包括：至少一个处理器1101、存储器1102、通信接口1103。
[0193] 存储器1102，用于存放程序。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。
[0194] 存储器1102可能包含高速RAM存储器，也可能还包括非易失性存储器(non‑volatile memory)，例如至少一个磁盘存储器。
[0195] 处理器1101用于执行存储器1102存储的计算机执行指令，以实现前述方法实施例所描述的方法。其中，处理器1101可能是一个CPU，或者是特定集成电路(Application Specific Integrated Circuit，简称为ASIC)，或者是被配置成实施本申请实施例的一个或多个集成电路。
[0196] 处理器1101通过通信接口1103可以与外部设备进行通信交互，外部设备例如可以是前述所说的用户端的电子设备。在具体实现上，如果通信接口1103、存储器1102以及处理器1101独立实现，则通信接口1103、存储器1102以及处理器1101可以通过总线相互连接并完成相互间的通信。总线可以是工业标准体系结构(Industry Standard Architecture，简称为ISA)总线、外部设备互连(Peripheral Component，简称为PCI)总线或扩展工业标准体系结构(Extended Industry Standard Architecture，简称为EISA)总线等。总线可以分为地址总线、数据总线、控制总线等，但并不表示仅有一根总线或一种类型的总线。
[0197] 可选的，在具体实现上，如果通信接口1103、存储器1102和处理器1101集成在一块芯片上实现，则通信接口1103、存储器1102和处理器1101可以通过内部接口完成通信。
[0198] 本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以包括：U盘、移动硬盘、只读存储器(ROM，Read‑Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁盘或者光盘等各种可以存储程序代码的介质，具体的，该计算机可读存储介质中存储有程序指令，程序指令用于上述实施例中的方法。
[0199] 本申请还提供一种程序产品，该程序产品包括执行指令，该执行指令存储在可读存储介质中。计算设备的至少一个处理器可以从可读存储介质读取该执行指令，至少一个处理器执行该执行指令使得计算设备实施上述装置的动作。
[0200] 最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。
