Asynchronous complex multi-model cooperative scheduling method and system

Abstract

The present invention relates to the technical field of artificial intelligence. Disclosed are an asynchronous complex multi-model cooperative scheduling method and system, and a device, a storage medium and a program product, which are used for solving the technical problem in the prior art of it being impossible to simply and efficiently perform task scheduling for highly dependent complex distributed asynchronous tasks that are required to be completed by means of the cooperation of complex multiple models. The method comprises: acquiring task dependency relationship information of a task to be processed, and on the basis of the task dependency relationship information, splitting said task into a plurality of asynchronous sub-tasks; receiving asynchronous sub-task acceptance requests, acquiring source task processors corresponding to the asynchronous sub-task acceptance requests, and on the basis of complex multi-model information configured in the source task processors, determining the types of sub-tasks that can be processed by the source task processors; and monitoring the task states of the asynchronous sub-tasks, and on the basis of the types of sub-tasks that can be processed by the source task processors and the task states of the asynchronous sub-tasks, allocating the asynchronous sub-tasks to corresponding task processors for processing.

Description

Asynchronous Complex Multi-Model Cooperative Scheduling Method and System Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to an asynchronous complex multi-model collaborative scheduling method, system, device, storage medium, and computer program product. Background Technology

[0002] Technological advancements in artificial intelligence have led to the application of various large-scale models in diverse scenarios, with these models capable of handling an increasing variety and complexity of tasks. Consequently, the training and usage demands of these large-scale models are growing. As tasks become more complex, large models often require multiple sub-models to collaborate on a single task. For example, a generative AI model, constructed from multiple independent machine learning or deep learning models utilizing specific computing and storage resources, requires the cooperation of these sub-models to process multiple steps in a specific order, while simultaneously coordinating and scheduling the service resources of each sub-model. Therefore, when executing specific tasks, it is crucial not only to consider the dependencies between sub-tasks but also to determine how to better coordinate and schedule the service resources of each sub-model.

[0003] In existing technologies, when the application scenario is an asynchronous task flow that requires complex task scheduling with multiple models, most task scheduling methods use a centralized task scheduler to schedule subtasks. This relies on manual configuration of the task processing steps in the early stages, and when there are many task flow links, strong dependencies, and complex system collaboration relationships, the scheduling consumes a lot of processing resources and the scheduling effect is not good. Summary of the Invention

[0004] The main objective of this invention is to solve the technical problem in the prior art that task scheduling cannot be performed easily and efficiently for complex tasks that require the collaboration of multiple models and have strong dependencies.

[0005] The first aspect of this invention provides an asynchronous complex multi-model cooperative scheduling method, comprising:

[0006] Obtain task dependency information of the task to be processed, wherein the task to be processed is a task that requires complex multi-model collaboration to complete, and the task dependency information is obtained after parsing and identifying the received task to be processed.

[0007] The task to be processed is split into multiple asynchronous subtasks based on the task dependency information;

[0008] Receive an asynchronous subtask acceptance request and obtain the source task processor corresponding to the asynchronous subtask acceptance request. Determine the subtask type that the source task processor can handle based on the complex multi-model information configured in the source task processor. The asynchronous subtask acceptance request is issued by an idle task processor every preset time.

[0009] Monitor the task status of each asynchronous subtask, and assign each asynchronous subtask to the corresponding task processor for processing based on the subtask type that the source task processor can handle and the task status of each asynchronous subtask.

[0010] Optionally, in a first implementation of the first aspect of the present invention, the task dependency information is a directed acyclic graph generated based on the processing flow of the task to be processed;

[0011] Before obtaining the task dependency information of the task to be processed, the following is also included:

[0012] Receive and parse the tasks to be processed to obtain task material data, task interface address and interface request parameters;

[0013] The task type of the task to be processed is identified based on the task interface address and interface request parameters;

[0014] Based on the task type of the task to be processed, find the corresponding task flow template, and generate a directed acyclic graph of the task to be processed based on the task material data and the task flow template.

[0015] Optionally, in a second implementation of the first aspect of the present invention, the step of splitting the task to be processed into multiple asynchronous subtasks according to task dependency information includes:

[0016] The task to be processed is split into multiple asynchronous subtasks based on the nodes in the directed acyclic graph of the task to be processed and the node connection order.

[0017] The monitoring of the task status of each of the asynchronous subtasks includes:

[0018] Obtain the number of predecessor tasks for each asynchronous subtask, and monitor the number of predecessor tasks that have been successfully executed for each asynchronous subtask in real time;

[0019] The task status of each asynchronous subtask is obtained based on the number of predecessor tasks of each asynchronous subtask and the number of predecessor tasks that have been successfully executed.

[0020] Optionally, in a third implementation of the first aspect of the present invention, the task state includes a waiting state and a ready state;

[0021] The process of obtaining the task status of each asynchronous subtask based on the number of predecessor tasks of each asynchronous subtask and the number of predecessor tasks that have been successfully executed includes:

[0022] When the number of predecessor tasks of an asynchronous subtask is greater than the number of predecessor tasks that have been successfully executed, the task status of the asynchronous subtask is a waiting state.

[0023] When the number of predecessor tasks of an asynchronous subtask is equal to the number of predecessor tasks that have been successfully executed, the task state of the asynchronous subtask is ready.

[0024] The step of assigning each asynchronous subtask to a corresponding task processor for processing based on the subtask type that the source task processor can handle and the task status of each asynchronous subtask includes:

[0025] Based on the target subtask type corresponding to the asynchronous subtask in the ready state, the asynchronous subtask in the ready state is assigned to a task processor that can process the target subtask type.

[0026] The model required to execute the asynchronous subtask in the task processor is invoked to process the allocated asynchronous subtask.

[0027] Optionally, in a fourth implementation of the first aspect of the present invention, the task state further includes a running state;

[0028] The step of assigning the asynchronous subtask in the ready state to a task processor capable of processing the target subtask type according to the target subtask type corresponding to the asynchronous subtask in the ready state includes:

[0029] Determine whether the source task processor corresponding to the asynchronous subtask receiving request is capable of processing the target subtask type corresponding to the asynchronous subtask in the ready state;

[0030] If so, first change the task status of the asynchronous subtask that is in the ready state to the running state, and then assign the asynchronous subtask whose task status has been changed to running to the source task processor.

[0031] Optionally, in a fifth implementation of the first aspect of the present invention, the task state further includes an execution failure state;

[0032] After changing the task state of the asynchronous subtask in the ready state to the running state, and then assigning the asynchronous subtask whose task state has been changed to running to the source task processor, the method further includes:

[0033] Receive heartbeat signals from the task processor that is currently processing a task;

[0034] Based on the heartbeat signal, it is determined whether the task processor that is processing the task has experienced a heartbeat timeout. If a heartbeat timeout occurs, the task status of the asynchronous subtask that the task processor is executing is changed from the running state to the execution failure state.

[0035] The task scheduling method further includes:

[0036] When the asynchronous subtask fails to execute, the allocation and scheduling of the asynchronous subtask is stopped, and the pending task is terminated.

[0037] Optionally, in a sixth implementation of the first aspect of the present invention, the task state further includes a service failure state;

[0038] After changing the task state of the asynchronous subtask in the ready state to the running state, and then assigning the asynchronous subtask whose task state has been changed to running to the source task processor, the method further includes:

[0039] Determine whether a business logic failure occurred when the task processor was executing the asynchronous subtask. If so, change the task status of the asynchronous subtask from running to business failure.

[0040] The task scheduling method further includes:

[0041] When the task status of an asynchronous subtask reaches a business failure state, the allocation and scheduling of the asynchronous subtask will stop, and the pending task will end.

[0042] A second aspect of the present invention provides an asynchronous complex multi-model cooperative scheduling system, comprising:

[0043] The business server is used to receive tasks to be processed, parse and identify them to obtain task dependency information of the tasks to be processed, and send the task dependency information to the task scheduler. The tasks to be processed are tasks that require complex multi-model collaboration to complete.

[0044] A task scheduler is used to obtain task dependency information of tasks to be processed; split the tasks to be processed into multiple asynchronous subtasks according to the task dependency information; receive asynchronous subtask acceptance requests and obtain the source task processor corresponding to the asynchronous subtask acceptance request; determine the subtask type that the source task processor can process based on the complex multi-model information configured in the source task processor; monitor the task status of each asynchronous subtask; and assign each asynchronous subtask to the corresponding task processor for processing based on the subtask type that the source task processor can process and the task status of each asynchronous subtask.

[0045] The task processor is used to send subtask acceptance requests to the task scheduler at preset intervals during idle periods; and to process asynchronous subtasks assigned by the task scheduler.

[0046] A third aspect of the present invention provides an asynchronous complex multi-model cooperative scheduling device, comprising: a memory and at least one processor, wherein the memory stores instructions; the at least one processor invokes the instructions in the memory to cause the asynchronous complex multi-model cooperative scheduling device to perform the steps of the above-described asynchronous complex multi-model cooperative scheduling method.

[0047] A fourth aspect of the present invention provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the steps of the above-described asynchronous complex multi-model cooperative scheduling method.

[0048] A fifth aspect of the present invention provides a computer program product, including a computer program / instructions, characterized in that, when the computer program / instructions are executed by a processor, the steps of the asynchronous complex multi-model cooperative scheduling method described above are implemented.

[0049] The technical solution provided by this invention involves: acquiring task dependency information of the task to be processed; splitting the task to be processed into multiple asynchronous subtasks based on the task dependency information; receiving asynchronous subtask acceptance requests and acquiring the source task processor corresponding to the asynchronous subtask acceptance request; determining the subtask type that the source task processor can handle based on the complex multi-model information configured in the source task processor, wherein the subtask acceptance request is issued by an idle task processor at preset intervals; monitoring the task status of each asynchronous subtask; and assigning each asynchronous subtask to the corresponding task processor for processing based on the subtask type that the source task processor can handle and the task status of each asynchronous subtask. This method can easily and efficiently schedule distributed asynchronous complex multi-model tasks when executing complex tasks with strong dependencies that require complex multi-model collaboration. The asynchronous complex multi-model collaborative scheduling system, electronic device, readable storage medium, and computer program product provided by this invention also solve the corresponding technical problems. Attached Figure Description

[0050] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0051] Figure 1 is a flowchart illustrating the first embodiment of the asynchronous complex multi-model cooperative scheduling method in this invention.

[0052] Figure 2 is a flowchart illustrating the second embodiment of the asynchronous complex multi-model cooperative scheduling method in this invention.

[0053] Figure 3 is a schematic diagram of component deployment in the second embodiment of the asynchronous complex multi-model cooperative scheduling method of the present invention;

[0054] Figure 4 is a schematic diagram of an embodiment of the asynchronous complex multi-model cooperative scheduling system of the present invention. Detailed Implementation

[0055] Exemplary embodiments of the invention will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limiting the invention to the embodiments set forth herein. Rather, these exemplary embodiments are provided to make the invention more comprehensive and complete, and to facilitate a full communication of the inventive concept to those skilled in the art. The same reference numerals in the drawings denote the same or similar elements, components, or parts, and therefore repeated descriptions of them will be omitted.

[0056] Subject to the technical concept of this invention, the features, structures, characteristics or other details described in a particular embodiment may be combined in one or more other embodiments in a suitable manner.

[0057] In the description of specific embodiments, the features, structures, characteristics, or other details described in this invention are intended to enable those skilled in the art to fully understand the embodiments. However, it is not excluded that those skilled in the art can practice the technical solutions of this invention without one or more of the specific features, structures, characteristics, or other details.

[0058] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily need to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0059] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0060] The terms “and / or” or “and / or” include all combinations of any one or more of the listed items.

[0061] Please refer to Figure 1. The first embodiment of the asynchronous complex multi-model cooperative scheduling method in this invention includes:

[0062] S101. Obtain the task dependency information of the task to be processed;

[0063] It is understood that the executing entity of this invention can be a task scheduling system, a terminal, or a server, such as a task scheduling server; no specific limitation is made here. This embodiment of the invention will be described using a task scheduling server as an example.

[0064] In this embodiment, the task to be processed refers to a complex task that requires the collaborative completion of multiple models. After receiving an asynchronous complex multi-model collaborative scheduling request, the task scheduling server first obtains the task dependency information corresponding to the task to be processed. This task dependency information is obtained by the business server after parsing and identifying the received task to be processed. This task dependency information refers to the processing order and processing level among multiple asynchronous subtasks contained in the task to be processed. This task dependency information can be stored in the form of a pre-configured task structure process chain.

[0065] In one specific implementation, the business server can respond to and receive task requests issued by users, obtain the specific task type corresponding to the task request issued by users, and obtain the task dependency relationship corresponding to the task to be processed based on the specific task type.

[0066] S102. Based on the task dependency information, split the task to be processed into multiple asynchronous subtasks;

[0067] After obtaining the task dependency information corresponding to the task to be scheduled, the task scheduler splits the received overall task to be processed into multiple asynchronous subtasks that can be processed independently according to the task dependency information, generates an asynchronous subtask table, and saves the relevant information of each asynchronous subtask into the asynchronous subtask table.

[0068] In one specific implementation, the task dependency information can be stored in a directed acyclic graph. When splitting the task to be processed into multiple asynchronous subtasks, the task to be processed can be split into multiple asynchronous subtasks based on the nodes in the directed acyclic graph of the task to be processed and the node connection order.

[0069] S103. Receive asynchronous subtask acceptance request and obtain the source task processor corresponding to the asynchronous subtask acceptance request, and determine the subtask type that the source task processor can handle based on the complex multi-model information configured in the source task processor.

[0070] In this embodiment, the task scheduler does not actively search for a matching task processor based on the pending asynchronous subtasks. Instead, it passively receives task acceptance requests from idle task processors. The task scheduler receives the asynchronous subtask acceptance requests from idle task processors and simultaneously obtains information about the corresponding source task processor based on these requests. Specifically, this information can be the task processor's encoding, which can be sent to the task scheduler along with the asynchronous subtask acceptance request or included within it. After parsing the received asynchronous subtask acceptance request, the task scheduler obtains the task processor's encoding, thus determining the source task processor corresponding to the asynchronous subtask acceptance request.

[0071] Furthermore, when parsing the asynchronous subtask acceptance request, the complex multi-model information configured in the task processor that issued the request can also be obtained. The complex multi-model information refers to the model that can be called in the corresponding task processor. Based on the complex multi-model information, the type of subtask that the task processor can handle can be determined.

[0072] In one specific implementation, a task processor can deploy multiple different models, enabling collaboration among multiple models within the same processor and achieving efficient resource utilization; that is, a task processor can contain multiple subtask types that it can process.

[0073] In this embodiment, the asynchronous subtask acceptance request is sent to the task scheduler by an idle task processor at preset intervals. The preset interval is determined based on information such as the processing time of each asynchronous subtask and the acceptable waiting time for asynchronous subtasks. The preset interval can ensure that requests are not frequently sent to the task scheduler when there are idle task processors but no ready executable asynchronous subtasks, and that there is not too much delay in the allocation of tasks when there are ready executable asynchronous subtasks.

[0074] S104. Monitor the task status of each asynchronous subtask, and assign each asynchronous subtask to the corresponding task processor for processing based on the subtask type that the source task processor can handle and the task status of each asynchronous subtask.

[0075] In this embodiment, the asynchronous subtask table contains a task status field for asynchronous subtasks, and the task status in the asynchronous subtask table is updated according to the execution status of each asynchronous subtask; therefore, the task scheduler in this embodiment also monitors the task status of asynchronous subtasks.

[0076] After receiving a task acceptance request from an idle task processor, the task scheduler first parses the task acceptance request to obtain the asynchronous subtask types that the corresponding task processor can handle. After obtaining the subtask types that the idle task processor can handle, it can allocate asynchronous subtasks that are in the ready state.

[0077] In one specific implementation, the task states include waiting state, ready state, running state, successful state, and failed state. Specifically, an asynchronous subtask being in a waiting state means that, based on task dependencies and the specific execution status of the asynchronous subtask, the current asynchronous subtask still has unfinished predecessor subtasks and needs to wait for the predecessor subtasks to complete before it can begin allocation and processing; an asynchronous subtask being in a ready state means that, based on task dependencies and the specific execution status of the asynchronous subtask, the current asynchronous subtask has no unfinished predecessor subtasks and can begin allocation and processing; an asynchronous subtask being in a running state means that the current asynchronous subtask is being executed by the allocated processor; an asynchronous subtask being in a successful state means that the asynchronous subtask has been successfully completed; and an asynchronous subtask being in a failed state means that the asynchronous subtask failed to execute or the execution time exceeded a preset time.

[0078] Based on the subtask types that the source task processor can handle and the task status of each asynchronous subtask obtained in the preceding steps, the asynchronous subtasks in the ready state are assigned to the task processors of the target asynchronous subtask types that can handle the asynchronous subtasks in the current ready state for processing; while assigning the asynchronous subtasks to the task processors, the task status in the asynchronous subtask table needs to be updated to running.

[0079] In this embodiment, the asynchronous subtask table also contains the task code of each asynchronous subtask. After the asynchronous subtask is assigned to the task processor for processing, the corresponding code of the task processor is recorded in the asynchronous subtask table to match the asynchronous subtask code with the task processor, so as to record the specific execution status.

[0080] Based on the scheme in this embodiment, all the split asynchronous subtasks are assigned to the corresponding models in the task processor for processing according to the task dependency information, until all asynchronous subtasks are executed and the task to be processed is completed.

[0081] The asynchronous complex multi-model collaborative scheduling method in this embodiment provides a simple and efficient distributed asynchronous task scheduling method when executing complex tasks with strong dependencies that require the collaboration of multiple models. It can realize the combination and matching of multiple model services and can be deployed quickly and stably in engineering.

[0082] Please refer to Figures 2 and 3. The second embodiment of the asynchronous complex multi-model cooperative scheduling method in this invention includes:

[0083] This embodiment uses an AIGC (Artificial Intelligence Generated Content) system as an example. For instance, it can be used in internet applications such as AI (Artificial Intelligence) generation of AIGC advertising materials and automatic tagging of advertising materials. Specifically, it can be an asynchronous task flow requiring complex multi-model collaboration. Users can submit tasks and required materials to the AIGC business server through a client or webpage interface. The business server then saves the required materials to a file storage server. This file storage server can provide object storage services, such as S3 (Simple Storage Service) storage, and distributed file storage services via HTTPS for uploading / downloading.

[0084] In a specific implementation, the task materials required for the task to be processed can be submitted to the business server at the same time as the task to be processed, or they can be submitted in advance before the task to be processed is submitted; for example, they can be the same task materials as the previously executed task, in which case the business server and task scheduler can directly download the corresponding task materials from the file storage server.

[0085] The business server receives and parses pending tasks from users. Based on the specific information contained in the pending task, it obtains the task interface address and interface request parameters, and simultaneously retrieves the submitted task material data or obtains the corresponding task material data from the S3 file storage service based on the specific information of the pending task. The task type of the pending task is identified based on the task interface address and interface request parameters. The task type described in this step determines the specific type of the pending task, facilitating the subsequent acquisition of the task flow relationship information corresponding to that specific task type. In one specific implementation, the task flow relationship information can be recorded using a directed acyclic graph.

[0086] The task flow template is found based on the task type of the task to be processed. Each task flow template contains a fixed set of subtasks and information such as the interdependencies between asynchronous subtasks. The variables in the task flow template are populated according to the task material data to be processed, and finally a directed acyclic graph of the task to be processed is generated.

[0087] S201. Obtain the directed acyclic graph generated based on the processing flow of the task to be processed;

[0088] S202. Based on the nodes in the directed acyclic graph of the task to be processed and the node connection order, the task to be processed is split into multiple asynchronous subtasks.

[0089] In this embodiment, after the business server generates a directed acyclic graph (DAG) of the tasks to be processed, it sends the DAG to the task scheduler. The task scheduler receives the DAG and splits the tasks to be processed into multiple asynchronous subtasks according to the nodes in the DAG and the node connection order. It also determines the connection information based on the connection relationship between each asynchronous subtask and other asynchronous subtasks in the DAG. The connection information also includes the number of predecessor tasks of each asynchronous subtask and the execution result of each predecessor task.

[0090] In one specific implementation, the task to be processed is split into subtasks, and the encoding and connection information of each asynchronous subtask are saved to the asynchronous subtask table.

[0091] S203. Receive asynchronous subtask acceptance request and obtain the source task processor corresponding to the asynchronous subtask acceptance request, and determine the subtask type that the source task processor can handle based on the complex multi-model information configured in the source task processor.

[0092] Idle task processors send asynchronous subtask acceptance requests to the task scheduler at preset intervals. The task scheduler receives and parses these requests, obtaining request parameters. These parameters include the types of subtasks that the task processor that issued the request supports. A task processor can contain multiple executable models, and it can use different models depending on the specific asynchronous subtask. After execution, it can release memory, improving the flexibility of task execution and saving resources. Furthermore, when executing an asynchronous subtask, a task processor can use multiple models within it to collaboratively execute the subtask, thereby reducing data transfer between multiple model services.

[0093] The preset time is determined based on information such as the processing time of each asynchronous subtask and the acceptable waiting time of the asynchronous subtask. The preset time can ensure that there are no frequent requests to the task scheduler when there are idle task processors but no ready executable asynchronous subtasks, and that there is no delay in assigning tasks when there are ready executable asynchronous subtasks.

[0094] In one specific implementation, to reduce the delay in processing asynchronous subtasks when task processors are idle, the preset time is preferably short. The minimum preset time can be calculated based on the number of task processors and the performance of querying the asynchronous subtask table. For example, if the asynchronous subtask table query uses MySQL and its performance supports n SQL (Structured Query Language) queries per second, then the preset time is the number of task processors divided by n. In a preferred embodiment, the preset time is 5 seconds.

[0095] In a preferred embodiment, after receiving a task acceptance request, the task scheduler will also assign the asynchronous subtask to a suitable task processor based on the specific information of the asynchronous subtask. For example, the task processor may have a variety of different characteristics, and different asynchronous subtasks can be assigned to suitable task processors according to the characteristics of the task processor.

[0096] S204. Obtain the number of predecessor tasks for each asynchronous subtask and monitor the number of predecessor tasks that have been successfully executed for each asynchronous subtask in real time.

[0097] S205. Obtain the task status of each asynchronous subtask based on the number of predecessor tasks of each asynchronous subtask and the number of predecessor tasks that have been successfully executed.

[0098] In this embodiment, the constructed asynchronous subtask table contains a task status field for asynchronous subtasks. The task status in the asynchronous subtask table is updated according to the execution status of each asynchronous subtask. Therefore, the task scheduler in this embodiment also monitors the task status of asynchronous subtasks.

[0099] In one specific implementation, the task state of an asynchronous subtask includes a waiting state and a ready state. The task state of an asynchronous subtask can be monitored by the total number of its predecessor tasks and the number of successfully executed predecessor tasks. Specifically, when the number of predecessor tasks of an asynchronous subtask is greater than the number of successfully executed predecessor tasks (i.e., some predecessor tasks have not completed successfully), the task state of the asynchronous subtask is waiting. These asynchronous subtasks in this state will not be assigned to a task processor for processing; instead, they will wait for the task state to be updated to the ready state before specific task scheduling will occur. When the number of predecessor tasks of an asynchronous subtask equals the number of successfully executed predecessor tasks (i.e., there are no predecessor asynchronous subtasks or all predecessor asynchronous subtasks have completed successfully), the task state of the asynchronous subtask is ready.

[0100] S206. Based on the target subtask type corresponding to the asynchronous subtask in the ready state, assign the asynchronous subtask in the ready state to a task processor that can process the target subtask type.

[0101] S207. Call the model required to execute the asynchronous subtask in the task processor and process the allocated asynchronous subtask.

[0102] Upon receiving an asynchronous subtask acceptance request from an idle task processor, the task processor assigns ready subtasks to available task processors based on the task types it can handle, and marks the started asynchronous subtasks as running. In this embodiment, the idle task processor actively sends an asynchronous subtask acceptance request to the task scheduler instead of the task scheduler actively assigning tasks to task processors, simplifying the communication between the task scheduler and task processors.

[0103] In one specific implementation, in response to an asynchronous subtask acceptance request from an idle task processor, the task scheduler first obtains the target task type of the ready asynchronous subtask to be assigned, and then determines whether there is an idle task processor capable of handling the corresponding target task type. If so, the task status of the ready asynchronous subtask is changed to running, and then the running asynchronous subtask is assigned to the idle task processor for processing. This is to prevent the task scheduler from assigning the same asynchronous subtask to multiple different task processors. Specifically, the status of a task can be updated using an UPDATE SQL statement with a WHERE clause in a relational database. For example, the statement could be: "UPDATE task_table SET status='running',processor_id='172.16.12.34' WHERE task_id=123 AND status='ready'". Here, `task` represents an asynchronous subtask, `task_id` is the subtask code, `task_table` refers to the asynchronous subtask table, `status` indicates the subtask status, `processor` represents the task processor, and `processor_id` is the task processor code. This ensures that only one task processor receives the asynchronous subtask with code 123. After the UPDATE statement executes successfully, the subtask status in the asynchronous subtask table will be updated to "running". For another concurrently executing SQL statement, this asynchronous subtask is no longer in the ready state and will not be assigned to it.

[0104] In this embodiment, task allocation primarily determines the types of subtasks that the source task processor can handle based on the complex multi-model information configured in the source task processor. Therefore, it essentially determines which corresponding task processor should be assigned to the asynchronous subtask based on the model required to execute the asynchronous subtask. In this embodiment, the task processor can be provided by various hardware types, including CPU servers and GPU servers. Referring to Figure 3, each different task processor can be configured with different task processing models, and each task processor can be configured with multiple task processing models. For example, a high-performance CPU server can be configured with a model that only requires CPU processing to share the workload of the GPU server; a low-performance CPU server can be configured with a model that can call external multi-service shared model services for processing; some GPU servers can be configured with multiple task processing models capable of handling large model tasks, such as a model for generating videos based on artificial intelligence; other GPU servers can be configured with models that can call other task execution tools based on the generated data, such as a model for compositing and exporting generated videos, etc. The task scheduler allocates different asynchronous subtasks based on the information of these specific task processors and then executes the tasks to be processed.

[0105] After an asynchronous subtask that is in a ready state is assigned to a task processor that can handle the target subtask type, the model required to execute the asynchronous subtask in the task processor will be invoked to process the assigned asynchronous subtask.

[0106] In this embodiment, the task status also includes successful execution. When an asynchronous subtask is assigned to a task processor and executed without exception, and the task processor's logic code determines that the subtask's business result is correct, the task processor will send the successful execution information back to the task scheduler. After receiving the information, the task scheduler will update the successful execution status to the asynchronous subtask table and update the information corresponding to the successor asynchronous subtasks of the successfully executed asynchronous subtask. For example, the number of successful predecessor nodes corresponding to the successor asynchronous subtasks of the successfully executed asynchronous subtask will be incremented by 1.

[0107] In one specific implementation, the task status also includes an execution failure status. The asynchronous complex multi-model collaborative scheduling method described in this embodiment further includes: receiving a heartbeat signal from a task processor currently executing an asynchronous subtask; and determining whether the task processor executing the asynchronous subtask has experienced a heartbeat timeout based on the heartbeat signal. If a heartbeat timeout occurs, the task status of the asynchronous subtask being executed by the task processor is changed from a running state to an execution failure state. Furthermore, execution failure also includes the task processor catching an exception during the execution of the asynchronous subtask. When the task status reaches an execution failure state, the allocation and scheduling of asynchronous subtasks is stopped. Even if there are subsequent asynchronous subtasks in a waiting state, they will not be executed, the pending task is directly terminated, and the specific information regarding the timeout failure is fed back to the user.

[0108] In one specific implementation, the task status also includes a business failure status. The asynchronous complex multi-model collaborative scheduling method described in this embodiment further includes: determining whether a business logic failure occurs when the task processor executes an asynchronous subtask; if so, changing the task status of the asynchronous subtask from a running state to a business failure state. The task scheduling method further includes: stopping the allocation and scheduling of asynchronous subtasks and ending the pending task when the task status shows a business failure state. Specifically, the business failure state is different from the aforementioned execution failure state; it refers to a failure in business logic, such as problems with user-submitted tasks or input data, causing the asynchronous subtask to fail to obtain the corresponding result. After execution failure, the specific information of the execution failure is fed back to the system administrator for troubleshooting.

[0109] The embodiments of the present invention can easily and efficiently schedule distributed asynchronous tasks when performing complex tasks related to artificial intelligence that require the collaboration of multiple models. It can also facilitate the combination and matching of multiple model services, make full use of service resources, and carry out engineering deployment quickly and stably.

[0110] The asynchronous complex multi-model cooperative scheduling method in the embodiments of the present invention has been described above. The asynchronous complex multi-model cooperative scheduling system in the embodiments of the present invention is described below. Referring to Figure 4, one embodiment of the asynchronous complex multi-model cooperative scheduling system in the embodiments of the present invention includes:

[0111] The business server 401 is used to receive tasks to be processed, parse and identify them to obtain task dependency information of the tasks to be processed, and send the task dependency information to the task scheduler. The task to be processed is a task that requires complex multi-model collaboration to complete.

[0112] The task scheduler 402 is used to obtain task dependency information of the task to be processed; split the task to be processed into multiple asynchronous subtasks according to the task dependency information; receive asynchronous subtask acceptance requests and obtain the source task processor corresponding to the asynchronous subtask acceptance request; determine the subtask type that the source task processor can process based on the complex multi-model information configured in the source task processor; monitor the task status of each asynchronous subtask; and assign each asynchronous subtask to the corresponding task processor for processing based on the subtask type that the source task processor can process and the task status of each asynchronous subtask.

[0113] Task processor 403 is used to send subtask acceptance requests to the task scheduler at preset intervals when idle; and to process asynchronous subtasks assigned by the task scheduler.

[0114] The embodiments of the present invention can easily and efficiently schedule distributed asynchronous complex multi-model tasks when performing complex tasks that require the collaboration of multiple complex models.

[0115] In another embodiment of this application, the task dependency information is a directed acyclic graph generated based on the processing flow of the task to be processed;

[0116] The business server 401 is specifically used to receive tasks to be processed and parse them to obtain task material data, task interface address and interface request parameters.

[0117] The task type of the task to be processed is identified based on the task interface address and interface request parameters;

[0118] Based on the task type of the task to be processed, find the corresponding task flow template, and generate a directed acyclic graph of the task to be processed based on the task material data and the task flow template.

[0119] In another embodiment of this application, the task scheduler 402 is specifically used for:

[0120] The task to be processed is split into multiple asynchronous subtasks based on the nodes in the directed acyclic graph of the task to be processed and the node connection order.

[0121] as well as,

[0122] Obtain the number of predecessor tasks for each asynchronous subtask, and monitor the number of predecessor tasks that have been successfully executed for each asynchronous subtask in real time;

[0123] The task status of each asynchronous subtask is obtained based on the number of predecessor tasks of each asynchronous subtask and the number of predecessor tasks that have been successfully executed.

[0124] In another embodiment of this application, the task state includes a waiting state and a ready state;

[0125] The task scheduler 402 is further used for:

[0126] When the number of predecessor tasks of an asynchronous subtask is greater than the number of predecessor tasks that have been successfully executed, the task status of the asynchronous subtask is a waiting state.

[0127] When the number of predecessor tasks of an asynchronous subtask is equal to the number of predecessor tasks that have been successfully executed, the task state of the asynchronous subtask is ready.

[0128] as well as,

[0129] Based on the target subtask type corresponding to the asynchronous subtask in the ready state, the asynchronous subtask in the ready state is assigned to a task processor that can process the target subtask type.

[0130] The model required to execute the asynchronous subtask in the task processor is invoked to process the allocated asynchronous subtask.

[0131] In another embodiment of this application, the task state further includes a running state;

[0132] The task scheduler 402 is further used for:

[0133] Determine whether the source task processor corresponding to the asynchronous subtask receiving request is capable of processing the target subtask type corresponding to the asynchronous subtask in the ready state;

[0134] If so, first change the task status of the asynchronous subtask that is in the ready state to the running state, and then assign the asynchronous subtask whose task status has been changed to running to the source task processor.

[0135] In another embodiment of this application, the task status further includes an execution failure status;

[0136] The task scheduler 402 is further used for:

[0137] Receive heartbeat signals from the task processor that is currently processing a task;

[0138] Based on the heartbeat signal, it is determined whether the task processor that is processing the task has experienced a heartbeat timeout. If a heartbeat timeout occurs, the task status of the asynchronous subtask that the task processor is executing is changed from the running state to the execution failure state.

[0139] Furthermore, when the asynchronous subtask's task status shows an execution failure state, the allocation and scheduling of the asynchronous subtask are stopped, and the pending task is terminated.

[0140] In another embodiment of this application, the task status further includes a service failure status;

[0141] The task scheduler 402 is further used for:

[0142] Determine whether a business logic failure occurred when the task processor was executing the asynchronous subtask. If so, change the task status of the asynchronous subtask from running to business failure.

[0143] Furthermore, when the task status of an asynchronous subtask reaches a business failure state, the allocation and scheduling of the asynchronous subtask shall be stopped, and the pending task shall be terminated.

[0144] The embodiments of the present invention can easily and efficiently schedule distributed asynchronous tasks that require multiple models to work together and have strong dependencies between different parts of the task. It can also facilitate the combination and matching of multiple model services, make full use of service resources, and quickly and stably deploy projects.

[0145] Based on the same inventive concept, embodiments of this specification also provide an asynchronous complex multi-model cooperative scheduling device, a memory and at least one processor, wherein the memory stores instructions;

[0146] The at least one processor invokes the instructions in the memory to cause the asynchronous complex multi-model cooperative scheduling device to perform the steps of the asynchronous complex multi-model cooperative scheduling method as described in any of the above embodiments.

[0147] Furthermore, the aforementioned asynchronous complex multi-model collaborative scheduling device may also include a transmission module and an input / output module, wherein the transmission module is connected to the aforementioned processor, and the input / output module is connected to the aforementioned processor.

[0148] The present invention also provides a computer program product, including a computer program / instruction that, when executed by a processor, implements the steps of the asynchronous complex multi-model cooperative scheduling method as described in any of the above embodiments.

[0149] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described in this invention can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this invention can be embodied in the form of a software product, which can be stored in a computer-readable storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the method described above according to this invention. When the computer program is executed by a data processing device, it enables the computer-readable medium to implement the asynchronous complex multi-model cooperative scheduling method described in any embodiment of this invention.

[0150] Furthermore, the computer program implementing the asynchronous complex multi-model cooperative scheduling method described in any of the above embodiments can be stored on one or more computer-readable media. The computer-readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0151] The computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The readable storage medium may also be any readable medium other than a readable storage medium, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0152] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the present invention is not inherently related to any specific computer, virtual device, or electronic device, and various general-purpose devices can also implement the present invention. The above descriptions are merely specific embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0153] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0154] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. An asynchronous complex multi-model cooperative scheduling method, characterized in that, The asynchronous complex multi-model cooperative scheduling method includes: Obtain task dependency information of the task to be processed, wherein the task to be processed is a task that requires complex multi-model collaboration to complete, and the task dependency information is obtained after parsing and identifying the received task to be processed. The task to be processed is split into multiple asynchronous subtasks based on the task dependency information; Receive an asynchronous subtask acceptance request and obtain the source task processor corresponding to the asynchronous subtask acceptance request. Determine the subtask type that the source task processor can handle based on the complex multi-model information configured in the source task processor. The asynchronous subtask acceptance request is issued by an idle task processor every preset time. Monitor the task status of each asynchronous subtask, and assign each asynchronous subtask to the corresponding task processor for processing based on the subtask type that the source task processor can handle and the task status of each asynchronous subtask.

2. The asynchronous complex multi-model cooperative scheduling method according to claim 1, characterized in that, The task dependency information is a directed acyclic graph generated based on the processing flow of the tasks to be processed; Before obtaining the task dependency information of the task to be processed, the following is also included: Receive and parse the tasks to be processed to obtain task material data, task interface address and interface request parameters; The task type of the task to be processed is identified based on the task interface address and interface request parameters; Based on the task type of the task to be processed, find the corresponding task flow template, and generate a directed acyclic graph of the task to be processed based on the task material data and the task flow template.

3. The asynchronous complex multi-model cooperative scheduling method according to claim 2, characterized in that, The step of splitting the task to be processed into multiple asynchronous subtasks based on task dependency information includes: The task to be processed is split into multiple asynchronous subtasks based on the nodes in the directed acyclic graph of the task to be processed and the node connection order. The monitoring of the task status of each of the asynchronous subtasks includes: Obtain the number of predecessor tasks for each asynchronous subtask, and monitor the number of predecessor tasks that have been successfully executed for each asynchronous subtask in real time; The task status of each asynchronous subtask is obtained based on the number of predecessor tasks of each asynchronous subtask and the number of predecessor tasks that have been successfully executed.

4. The asynchronous complex multi-model cooperative scheduling method according to claim 3, characterized in that, The task status includes a waiting state and a ready state; The process of obtaining the task status of each asynchronous subtask based on the number of predecessor tasks of each asynchronous subtask and the number of predecessor tasks that have been successfully executed includes: When the number of predecessor tasks of an asynchronous subtask is greater than the number of predecessor tasks that have been successfully executed, the task status of the asynchronous subtask is a waiting state. When the number of predecessor tasks of an asynchronous subtask is equal to the number of predecessor tasks that have been successfully executed, the task state of the asynchronous subtask is ready. The step of assigning each asynchronous subtask to a corresponding task processor for processing based on the subtask type that the source task processor can handle and the task status of each asynchronous subtask includes: Based on the target subtask type corresponding to the asynchronous subtask in the ready state, the asynchronous subtask in the ready state is assigned to a task processor that can process the target subtask type. The model required to execute the asynchronous subtask in the task processor is invoked to process the allocated asynchronous subtask.

5. The asynchronous complex multi-model cooperative scheduling method according to claim 4, characterized in that, The task status also includes the running status; The step of assigning the asynchronous subtask in the ready state to a task processor capable of processing the target subtask type according to the target subtask type corresponding to the asynchronous subtask in the ready state includes: Determine whether the source task processor corresponding to the asynchronous subtask receiving request is capable of processing the target subtask type corresponding to the asynchronous subtask in the ready state; If so, first change the task status of the asynchronous subtask that is in the ready state to the running state, and then assign the asynchronous subtask whose task status has been changed to running to the source task processor.

6. The asynchronous complex multi-model cooperative scheduling method according to claim 5, characterized in that, The task status also includes an execution failure status; After changing the task state of the asynchronous subtask in the ready state to the running state, and then assigning the asynchronous subtask whose task state has been changed to running to the source task processor, the method further includes: Receive heartbeat signals from the task processor that is currently processing a task; Based on the heartbeat signal, it is determined whether the task processor that is processing the task has experienced a heartbeat timeout. If a heartbeat timeout occurs, the task status of the asynchronous subtask that the task processor is executing is changed from the running state to the execution failure state. The task scheduling method further includes: When the asynchronous subtask fails to execute, the allocation and scheduling of the asynchronous subtask is stopped, and the pending task is terminated.

7. An asynchronous complex multi-model cooperative scheduling system, characterized in that, The asynchronous complex multi-model cooperative scheduling system includes: The business server is used to receive tasks to be processed, parse and identify them to obtain task dependency information of the tasks to be processed, and send the task dependency information to the task scheduler. The tasks to be processed are tasks that require complex multi-model collaboration to complete. A task scheduler is used to obtain task dependency information of tasks to be processed; split the tasks to be processed into multiple asynchronous subtasks according to the task dependency information; receive asynchronous subtask acceptance requests and obtain the source task processor corresponding to the asynchronous subtask acceptance request; determine the subtask types that the source task processor can process based on the complex multi-model information configured in the source task processor; monitor the task status of each asynchronous subtask; and assign each asynchronous subtask to the corresponding task processor for processing based on the subtask types that the source task processor can process and the task status of each asynchronous subtask. The task processor is used to send subtask acceptance requests to the task scheduler at preset intervals during idle periods; and to process asynchronous subtasks assigned by the task scheduler.

8. An asynchronous complex multi-model cooperative scheduling device, characterized in that, The asynchronous complex multi-model cooperative scheduling device includes: a memory and at least one processor, wherein the memory stores instructions; The at least one processor invokes the instructions in the memory to cause the asynchronous complex multi-model cooperative scheduling device to perform the steps of the asynchronous complex multi-model cooperative scheduling method as described in any one of claims 1-6.

9. A computer-readable storage medium storing a computer program / instructions thereon, characterized in that, When the program / instruction is executed by the processor, it implements the steps of the asynchronous complex multi-model cooperative scheduling method as described in any one of claims 1-6.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the steps of the asynchronous complex multi-model cooperative scheduling method as described in any one of claims 1-6.

Images