A task execution method and system based on computing power scheduling

Abstract

The application discloses a kind of task execution method and system based on computing power scheduling, belong to data processing technical field, the method is: the target task is split into several subtasks;The dependency between each subtask and the real-time load characteristics and historical task execution characteristics of each computing power node are obtained to determine the task execution strategy and target computing node of each subtask;According to the dependency, the task execution strategy control target computing node obtains the subtask execution result of each subtask;All the subtask execution results are obtained to obtain the task execution result of the target task, therefore, by implementing the present application, it can solve the technical problems caused by inaccurate task analysis, resource perception lag, parallel strategy rigidity, collaborative execution inefficiency, such as high computing delay, low resource utilization, complex problem solving failure in prior art, for improving the efficiency of task execution under the premise of reducing resource occupancy.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a task execution method and system based on computing power scheduling. Background Technology

[0002] With the rapid development of artificial intelligence technology, large language models are increasingly being used in professional fields such as power dispatching, financial analysis, and medical diagnosis. Due to the massive number of parameters and complex inference calculations of large models, the computing power of a single node is insufficient to meet the high concurrency and low latency requirements of business operations. Therefore, it is usually necessary to break down inference tasks into multiple parallel-executable subtasks and schedule them to heterogeneous computing power clusters for distributed collaborative inference. In this process, how to accurately parse and reasonably decompose complex inference requests input by users, how to dynamically schedule tasks based on the characteristics of each subtask and the real-time status of computing nodes, and how to adaptively match the optimal parallel acceleration strategy have become key factors determining the performance and resource utilization efficiency of the inference system.

[0003] Currently, there are several technical solutions in the field of large-scale model parallel inference and computational scheduling. Regarding task decomposition, existing solutions typically decompose the inference task based on the model's structural information (such as the number of Transformer layers, multi-head attention mechanisms, etc.) and the modal change characteristics of the task stage (such as different stages of text generation, image understanding, etc.). This involves dividing the model into several sub-tasks by layer or modality and estimating the computational resources and memory consumption required for each sub-task. Regarding computational scheduling, existing solutions collect information such as node memory parameters and remaining resources, and combine this with the task's computational load, duration, and latency requirements to establish a quantization model for task allocation and migration. Regarding parallel acceleration, existing solutions have proposed task decomposition and intelligent migration mechanisms, and academic literature has also disclosed the technical approach of using tensor parallelism as a runtime control plane for dynamic adaptive adjustment.

[0004] However, the above-mentioned existing technologies still have the following defects: (1) Task splitting relies heavily on the structural information of the model itself, and cannot automatically identify entities, determine task types, and perform atomic-level semantic decomposition on the natural language composite reasoning requests input by users, resulting in a lack of accurate input of task dimensions for subsequent scheduling and execution; (2) Computing power scheduling relies heavily on the static performance data of nodes or real-time indicators of a single dimension, lacking a comprehensive consideration of the historical execution performance of nodes, and cannot achieve accurate matching of task characteristics and node adaptability, resulting in fragmentation of computing power resources and uneven load; (3) Parallel strategies mostly adopt a fixed single mode, and cannot adaptively match different strategies such as single-card reasoning, tensor parallelism, or pipeline parallelism according to the characteristics of sub-tasks, and lack a two-way collaborative linkage mechanism between parallel strategies and scheduling decisions; (4) The dependency relationship processing between sub-tasks mostly adopts hard coding or static directed acyclic graphs, lacking dynamic topology sorting and state coordination mechanisms, and cannot cope with abnormal situations such as sub-task execution failure and timeout, and the reasoning process lacks intermediate result caching reuse, consistency verification, and traceable output mechanisms, resulting in low overall reasoning efficiency and poor interpretability. Summary of the Invention

[0005] This invention provides a task execution method and system based on computing power scheduling, which can solve the technical problems in the prior art, such as high computing latency, low resource utilization, and failure to solve complex problems caused by inaccurate task parsing, delayed resource awareness, rigid parallel strategies, and inefficient collaborative execution. It is used to improve the efficiency of task execution while reducing resource occupancy.

[0006] To address the aforementioned technical problems, this invention discloses a task execution method based on computing power scheduling, comprising: The acquired target task is semantically parsed to break it down into several subtasks; Obtain the data dependencies and control dependencies between each of the subtasks to construct a list of task features corresponding to the target task and the serial-parallel order between each of the subtasks; Real-time acquisition of operational data and static hardware data of each computing node in the computing center is used to construct real-time load characteristics and historical task execution characteristics corresponding to each computing node. Based on the task feature list, the real-time load features, and the historical task execution features, obtain the task execution strategy corresponding to each sub-task and match the target computing node corresponding to each sub-task from the computing center; According to the serial-parallel sequential control, the target computing node executes the subtasks according to the task execution strategy to obtain the subtask execution result of each subtask; Obtain the execution results of all the subtasks corresponding to the target task, and then assemble the execution results of each subtask to obtain the task execution result of the target task.

[0007] This invention discloses a task execution method based on computing power scheduling. It performs semantic parsing on the acquired target task to break it down into several sub-tasks, obtaining atomic units representing the internal logical structure of the task and initial association information between these units, providing foundational data for the automated decomposition of complex tasks. By acquiring the data and control dependencies between sub-tasks, it constructs a task feature list corresponding to the target task and the serial / parallel order between sub-tasks, obtaining a structured graph representing the logical constraints between sub-tasks and optimal execution order data, thus solving the problems of hard-coded dependencies and inability to dynamically plan execution paths in existing technologies. Furthermore, by acquiring real-time running data and static hardware data of each computing node in the computing center, it constructs real-time load characteristics and historical task execution characteristics for each computing node, obtaining dual-mode performance profile data representing the current availability and historical adaptation tendency of the nodes, thus solving the problems of static scheduling. This paper addresses the problem of the inability to perceive dynamic changes in nodes. By using a task feature list, real-time load characteristics, and historical task execution characteristics, it obtains the task execution strategy for each subtask and matches the target computing nodes corresponding to each subtask from the computing center. This generates scheduling mapping data representing the optimal matching relationship between tasks and nodes, thus solving the problem of lack of joint optimization in task-resource matching. Furthermore, by controlling the target computing nodes to execute subtasks according to the task execution strategy in a serial-parallel sequence, it obtains the subtask execution results of each subtask, acquiring execution feedback data representing the actual running status and output of each atomic task, enabling controllable execution and process tracking of distributed inference. Finally, by acquiring the execution results of all subtasks corresponding to the target task, it assembles these results to obtain the task execution result of the target task, acquiring the final output data representing the complete inference answer and its logical consistency, thus achieving reliable end-to-end delivery of inference results. In summary, this application constructs a complete data transformation link from natural language task description to executable computation graph and then to reliable inference answer, forming a data-driven forward-backward transmission relationship between each step. This overcomes the shortcomings of fragmented operation in existing technologies and improves the overall processing efficiency and resource utilization of large-scale parallel inference tasks.

[0008] As a preferred example, the semantic parsing of the acquired target task to break it down into several sub-tasks includes: The acquired target task is labeled and identified to obtain several key entities in the target task; The target task is identified and its priority is determined to obtain several task types corresponding to the target task and the execution priority of each task type. The length of the input text, the expected output length, the computing power requirement, and the video memory requirement of the target task are obtained as key information of the target task. Based on the key entity, the task type, the execution priority, and the key information, several task templates corresponding to the target task are obtained from a pre-built task template library, so as to split the target task into several sub-tasks according to the task templates.

[0009] The above scheme obtains several key entities in the target task by performing entity annotation and recognition, and obtains semantic tag data representing core elements such as devices, events, and targets in the task, which is used to support subsequent entity-driven dependency determination. By identifying the task type and determining the priority of the target task, several task types corresponding to the target task and the execution priority of each task type are obtained, and control data representing the urgency and resource scheduling level of the task is obtained, which is used to achieve differentiated service quality assurance. By obtaining the input text length, expected output length, computing power requirement, and memory requirement of the target task as key information, quantitative feature data representing the computational scale and resource consumption of the task is obtained, which is used to provide numerical basis for subsequent scheduling and matching. Based on key entities, task types, execution priorities, and key information, several task templates corresponding to the target task are obtained from a pre-built task template library, and the target task is split into several sub-tasks according to the task templates, obtaining structured sub-task list data representing the atomic decomposition results of the complex problem, which is used to realize the structured transformation from unstructured natural language to computable task units. In summary, the above solution transforms complex natural language requests that are originally incomprehensible to the scheduling system into a standard list of sub-tasks containing entity labels, type attributes, and quantification requirements through a four-stage semantic parsing process of entity recognition, type determination, information extraction, and template matching. This provides accurate task-dimensional data input for subsequent dependency modeling and resource matching.

[0010] As a preferred example, the step of obtaining the data dependencies and control dependencies between the subtasks to construct the task feature list corresponding to the target task and the serial-parallel order between the subtasks includes: For any given subtask, obtain the input entity set and output entity set corresponding to the subtask from all the key entities corresponding to the target task; For any two subtasks, if the output entity set of the first subtask and the input entity set of the second subtask intersect, the second subtask is determined to depend on the first subtask, which is used as a data dependency relationship between the first subtask and the second subtask. For any two subtasks, the first subtask and the second subtask are matched from a pre-built domain business rule base according to the task type, input entity set, and output entity set of the first subtask and the task type, input entity set, and output entity set of the second subtask. Based on the data dependencies and control dependencies, construct a list of task features corresponding to the target task and the serial-parallel order among the subtasks.

[0011] The above scheme obtains the input and output entity sets corresponding to any subtask from all key entities corresponding to the target task, thus acquiring entity boundary data representing the data consumption and output relationship of each subtask, which is used to construct the quantitative basis for data dependency determination. For any two subtasks, if the output entity set of the first subtask intersects with the input entity set of the second subtask, the second subtask is determined to depend on the first subtask, which serves as the data dependency relationship between the two subtasks. This obtains directed edge data representing the data flow direction between subtasks, used to automatically discover implicit data transit dependencies. Furthermore, for any two subtasks, the scheme obtains the first subtask's input entity set. The system first defines two subtasks. Based on the task type, input entity set, and output entity set of the first subtask, and the same for the second subtask, it matches the control dependencies between them from a pre-built domain business rule base. This obtains rule edge data representing the sequential constraints at the business logic level, supplementing domain-specific sequential constraints that data dependencies cannot cover. By constructing a task feature list corresponding to the target task and the serial / parallel order of each subtask based on data and control dependencies, it obtains a complete dependency graph and execution order data that integrates data flow and control flow, enabling automated and precise planning of subtask execution order. In summary, this solution achieves automated joint modeling of data and control dependencies through a dual-channel dependency identification mechanism combining entity set intersection determination and domain rule base matching. This overcomes the shortcomings of existing technologies that rely on manual configuration or hard coding, improving the completeness and accuracy of task dependency discovery.

[0012] As a preferred example, the step of constructing the task feature list corresponding to the target task and the serial-parallel order among the subtasks based on the data dependency relationship and the control dependency relationship includes: For any of the subtasks, based on the input text length, expected output length, computing power requirement, and video memory requirement of the target task and the task template corresponding to the subtask, obtain the task text length, expected output length, estimated computing power requirement, and estimated video memory requirement of the subtask. The task text length, expected output length, estimated power requirement, estimated memory requirement, task type, and execution priority corresponding to the subtask are used as the feature vector of the subtask. Based on the data and control dependencies between the subtasks, construct a directed acyclic graph of task dependencies corresponding to the target task; Based on the topological sorting of the layer-by-layer peeling, obtain several parallel execution queues and the peeling order of each parallel execution queue from the directed acyclic graph of the dependencies; wherein, each parallel execution queue includes several parallel execution subtasks; The serial execution order among different parallel execution queues in all the parallel execution queues is determined according to the stripping order; Based on the directed acyclic graph of task dependencies and the feature vectors corresponding to each of the subtasks, a list of task features corresponding to the target task is generated.

[0013] The above scheme, for any subtask, obtains the task text length, expected output length, estimated computational power requirement, and estimated memory requirement corresponding to the target task, based on the input text length, expected output length, computational power requirement, and estimated memory requirement of the target task, and the corresponding task template. This yields quantitative feature metadata representing the computational scale and resource consumption of a single subtask, used for differentiated comparison of resource requirements among subtasks. Furthermore, by using the task text length, expected output length, estimated computational power requirement, estimated memory requirement, task type, and execution priority of the subtask as feature vectors, standardized numerical vector data representing the multi-dimensional attributes of the subtask is obtained, supporting subsequent quantitative calculations for task-node matching. Finally, by constructing a directed acyclic graph of task dependencies corresponding to the target task based on the data and control dependencies between subtasks, a characteristic feature of the subtask is obtained. The graph structure data representing the complete logical constraints between tasks is used as the input data structure for topological sorting. Several parallel execution queues and their stripping order are obtained from the directed acyclic graph of dependencies based on a layer-by-layer stripping topological sorting. Scheduling queue data representing the groups of parallelizable subtasks and their order is obtained, used to achieve execution planning that maximizes parallelism. The serial execution order between different parallel execution queues is determined based on the stripping order, obtaining serialized control data representing cross-queue execution constraints to ensure dependencies are not violated. A task feature list corresponding to the target task is generated based on the directed acyclic graph of task dependencies and the feature vectors corresponding to each subtask, obtaining unified task description data that integrates graph structure dependencies and vectorized attributes, providing dual-dimensional information input including dependencies and features for subsequent scheduling matching. In summary, the above scheme, through a combination of directed acyclic graph construction and layer-by-layer stripping topological sorting, transforms implicit dependency constraints into explicit parallel queues and serial orders, effectively improving the parallelism of subtask execution and overall inference efficiency.

[0014] As a preferred example, the real-time acquisition of operational data and static hardware data of each computing node in the computing center to construct real-time load characteristics and historical task execution characteristics corresponding to each computing node includes: For any computing node, obtain its multi-dimensional operational metrics and static hardware data in real time. Based on the multi-dimensional operational metrics, generate the real-time load characteristics corresponding to the computing power node; For any subtask of a task type, obtain the actual execution delay and predicted delay of the computing node executing the subtask of that task type within a preset historical time period; The ratio of the actual execution delay to the predicted delay is obtained and used as a historical task execution characteristic of the computing node executing subtasks of this task type.

[0015] The above scheme acquires multi-dimensional operational metrics and static hardware data of any computing node in real time, obtaining raw index data characterizing the node's current instantaneous load state and inherent physical capabilities, which serves as the basic data source for generating load features. Based on the multi-dimensional operational metrics, it generates real-time load features corresponding to the computing node, acquiring instantaneous state vector data characterizing the node's current memory pressure, computing power occupancy, and queue backlog, enabling dynamic quantitative perception of the node's load state. For any task type's subtasks, it acquires the actual execution latency and predicted latency of the computing node executing subtasks of that task type within a preset historical time period, obtaining empirical data characterizing the node's historical performance for specific task types, used to evaluate the node's adaptability to task types. By acquiring the ratio of actual execution latency to predicted latency as the historical task execution feature of the computing node executing subtasks of that task type, it obtains normalized adaptation coefficient data characterizing the node's relative proficiency in short-sequence or long-sequence tasks, used as a correction term for load scoring. In summary, the above solution constructs a dual-mode performance profile that simultaneously generates real-time load characteristics and historical task execution characteristics. This enables the system to not only perceive the current load status of nodes but also understand the historical adaptation performance of nodes to different types of tasks. This overcomes the shortcomings of existing technologies that rely solely on static performance data or single-dimensional real-time indicators for scheduling, and improves the scientificity and accuracy of task-resource matching.

[0016] As a preferred example, the step of obtaining the task execution strategy corresponding to each subtask and matching the target computing node corresponding to each subtask from the computing center based on the task feature list, the real-time load characteristics, and the historical task execution characteristics includes: For any of the subtasks, obtain the business delay constraints and estimated execution time corresponding to the subtask based on the task template corresponding to the subtask. For any computing node in the computing center, if the available video memory of the computing node is greater than or equal to the estimated video memory requirement corresponding to the subtask and the sum of the queue waiting time of the computing node and the estimated execution time is less than or equal to the business delay constraint, the computing node shall be regarded as the candidate computing node corresponding to the subtask. For any candidate computing node, an adaptation score between the candidate computing node and the subtask is obtained based on the real-time load characteristics and historical task execution characteristics of the candidate computing node. Based on the adaptation score, all candidate computing nodes corresponding to the subtask are sorted, and a target computing node is assigned to the subtask according to the sorting order. Based on the feature vector of the subtask and the preset feature vector threshold, the corresponding task execution strategy is obtained from the preset task execution strategy library.

[0017] The above scheme obtains the business latency constraints and estimated execution time of any subtask based on the task template corresponding to that subtask, thus acquiring constraint data representing the time sensitivity requirements and expected computation time of the task, which is used as the time dimension filtering condition for candidate nodes. For any computing node in the computing center, if the available GPU memory of that computing node is greater than or equal to the estimated GPU memory requirement corresponding to the subtask, and the sum of the queue waiting time and the estimated execution time of that computing node is less than or equal to the business latency constraint, that computing node is designated as a candidate computing node for that subtask. This obtains preliminary set data of selectable nodes that simultaneously meet both GPU memory capacity and latency constraints, used to narrow down the search space for subsequent precise matching. Finally, for any candidate computing node, based on its real-time... Based on load characteristics and historical task execution characteristics, an adaptation score is obtained between the candidate computing node and the subtask. This score data represents the combined advantages and disadvantages of the node's current idleness and historical adaptability, and is used to achieve joint optimization of load balancing and task adaptation. By sorting all candidate computing nodes corresponding to the subtask according to the adaptation score and assigning target computing nodes to the subtask according to the sorting order, allocation result data representing the optimal task-node mapping relationship is obtained, which is used to achieve hybrid scheduling combining real-time minimum load priority and historical adaptation correction. Based on the subtask's feature vector and a preset feature vector threshold, the corresponding task execution strategy is obtained from a preset task execution strategy library, obtaining strategy selection data representing the matching relationship between the subtask and the parallel acceleration method, which is used to achieve adaptive alignment between computing mode and task characteristics. In summary, the matching process of the above scheme achieves accurate and optimal matching between subtasks and computing nodes, overcomes the shortcomings of separate decision-making for load balancing and task adaptation in existing technologies, and improves resource utilization and task response speed.

[0018] As a preferred example, the step of obtaining the task execution strategy corresponding to the subtask from a preset task execution strategy library based on the feature vector of the subtask and a preset feature vector threshold includes: When the task text length of the subtask is less than the preset first length threshold and the estimated video memory requirement of the subtask is less than the preset first video memory requirement threshold, a single-card inference strategy is matched for the subtask. When the task text length of the subtask is greater than or equal to the first length threshold and less than the preset second length threshold, and the estimated memory requirement of the subtask is greater than or equal to the first memory requirement threshold and less than the preset second memory requirement threshold, a tensor parallel strategy is matched for the subtask. When the task text length of the subtask is greater than or equal to the second length threshold and the estimated memory requirement of the subtask is greater than or equal to the second memory requirement threshold, a pipelined parallel strategy is matched for the subtask.

[0019] The above scheme matches a single-card inference strategy for a subtask when the task text length is less than a preset first length threshold and the estimated memory requirement of the subtask is less than a preset first memory requirement threshold. This obtains conservative execution mode data representing lightweight, short-sequence tasks that avoid cross-node communication overhead, thus eliminating unnecessary data transmission latency. It also matches a tensor parallel strategy for a subtask when the task text length is greater than or equal to the first length threshold and less than a preset second length threshold, and the estimated memory requirement of the subtask is greater than or equal to the first memory requirement threshold and less than a preset second memory requirement threshold. This obtains parallel execution mode data representing medium-scale tasks utilizing the collaborative computing capabilities of multiple cards within a single node, thus achieving a balance between computational intensity and communication overhead. Finally, it matches a pipelined parallel strategy for a subtask when the task text length is greater than or equal to the second length threshold and the estimated memory requirement of the subtask is greater than or equal to the second memory requirement threshold. This obtains distributed execution mode data representing large-scale tasks with cross-node hierarchical structure, thus breaking through the single-card memory limit and achieving stable inference for large-scale models. In summary, the above solution achieves adaptive and differentiated selection of a three-level parallel strategy through a dual-dimensional threshold determination mechanism based on task text length and estimated memory requirements. This overcomes the shortcomings of existing technologies where a single parallel mode cannot adapt to mixed long and short sequence scenarios, and improves the inference efficiency and execution success rate of various sub-tasks.

[0020] As a preferred example, the step of controlling the target computing node to execute the subtasks according to the task execution strategy based on the serial-parallel order, and obtaining the subtask execution result of each subtask, includes: For any of the subtasks, according to the serial-parallel order, the subtask is sent to the corresponding target computing node, and the target computing node is controlled to execute the subtask according to the task execution strategy to obtain the execution status of the subtask; Once the execution status indicates that the subtask has been completed, the execution result of the subtask is written to the shared cache to obtain the subtask execution result.

[0021] The above scheme, by assigning any subtask to the corresponding target computing node according to a serial-parallel order, and controlling the target computing node to execute the subtask according to the task execution strategy, obtains the execution status of the subtask and acquires real-time status data representing the current running stage and health status of the subtask, which is used to achieve process observability and anomaly detection in distributed inference. After determining the completion of the subtask based on its execution status, the execution result of the subtask is written to a shared cache to obtain the subtask execution result, acquiring structured intermediate result data that can be directly read by subsequent dependent subtasks, which is used to achieve result transfer across subtasks and avoid redundant computation. In summary, the above scheme, by combining the state tracking mechanism of the distributed task state coordinator with the result reuse mechanism of the shared cache, enables the system to perceive the execution status of each subtask in real time and store the execution results in a structured manner for dependent tasks to directly read. This overcomes the shortcomings of existing technologies that lack dynamic coordination and cache reuse mechanisms, and improves the reliability and execution efficiency of multi-node collaborative inference.

[0022] As a preferred example, obtaining the execution results of all the subtasks corresponding to the target task, and then assembling the execution results of each subtask to obtain the task execution result of the target task, includes: Obtain the execution results of all the subtasks corresponding to the target task, and perform logical consistency verification on the execution results of each subtask according to the pre-built domain rules to obtain the verification result corresponding to each execution result of the subtask. Based on the verification results, select several qualified subtask execution results from all the subtask execution results, and obtain the semantic structure of the target task; The execution results of all qualified subtasks are concatenated and assembled according to the semantic structure to obtain the execution result of the target task.

[0023] The above scheme obtains the execution results of all subtasks corresponding to the target task, performs logical consistency verification on each subtask execution result according to pre-built domain rules, obtains the verification result corresponding to each subtask execution result, and acquires verification label data representing whether there are logical contradictions between the results of each subtask to ensure the internal logical consistency of the final answer. Based on the verification results, several qualified subtask execution results are selected from all subtask execution results, and the semantic structure of the target task is obtained. Combined data representing the set of credible intermediate results that have passed verification and the original question organization framework is obtained to ensure that the data source used for splicing is reliable and structurally matched. By splicing and assembling all qualified subtask execution results according to the semantic structure, the task execution result of the target task is obtained, acquiring the final answer data that represents logical consistency and complete structure, used to achieve reliable reasoning result delivery to users. In summary, the above scheme, through consistency verification and semantic structure-guided splicing techniques, performs quality screening and orderly organization of scattered subtask results, overcomes the deficiency of existing technologies in lacking result verification mechanisms, and improves the accuracy, logical consistency, and credibility of the final output.

[0024] On the other hand, the present invention discloses a task execution system based on computing power scheduling, including a task splitting module, a task dependency module, a task feature module, a node matching module, a subtask execution module and an execution summary module; The task splitting module is used to perform semantic parsing on the acquired target task in order to split the target task into several sub-tasks; The task dependency module is used to obtain the data dependency relationship and control dependency relationship between each of the subtasks, so as to construct the task feature list corresponding to the target task and the serial-parallel order between each of the subtasks; The task feature module is used to acquire the running data and static hardware data of each computing node in the computing center in real time, so as to construct the real-time load features and historical task execution features corresponding to each computing node. The node matching module is used to obtain the task execution strategy corresponding to each subtask and match the target computing node corresponding to each subtask from the computing center based on the task feature list, the real-time load features and the historical task execution features. The subtask execution module is used to control the target computing node to execute the subtasks according to the task execution strategy based on the serial-parallel order, so as to obtain the subtask execution result of each subtask; The execution summary module is used to obtain the execution results of all the sub-tasks corresponding to the target task, and to splice and assemble the execution results of each sub-task to obtain the task execution result of the target task.

[0025] This invention discloses a task execution system based on computing power scheduling. It performs semantic parsing on the acquired target task to break it down into several sub-tasks, obtaining atomic units representing the internal logical structure of the task and initial association information between units, providing foundational data for the automated decomposition of complex tasks. By acquiring data and control dependencies between sub-tasks, it constructs a task feature list corresponding to the target task and the serial / parallel order between sub-tasks, obtaining a structured graph representing the logical constraints between sub-tasks and optimal execution order data, thus solving the problems of hard-coded dependencies and inability to dynamically plan execution paths in existing technologies. Furthermore, by acquiring real-time running data and static hardware data of each computing node in the computing center, it constructs real-time load characteristics and historical task execution characteristics for each computing node, obtaining dual-mode performance profile data representing the current availability and historical adaptation tendency of the nodes, thus solving the problems of static scheduling. This paper addresses the problem of the inability to perceive dynamic changes in nodes. By using a task feature list, real-time load characteristics, and historical task execution characteristics, it obtains the task execution strategy for each subtask and matches the target computing nodes corresponding to each subtask from the computing center. This generates scheduling mapping data representing the optimal matching relationship between tasks and nodes, thus solving the problem of lack of joint optimization in task-resource matching. Furthermore, by controlling the target computing nodes to execute subtasks according to the task execution strategy in a serial-parallel sequence, it obtains the subtask execution results of each subtask, acquiring execution feedback data representing the actual running status and output of each atomic task, enabling controllable execution and process tracking of distributed inference. Finally, by acquiring the execution results of all subtasks corresponding to the target task, it assembles these results to obtain the task execution result of the target task, acquiring the final output data representing the complete inference answer and its logical consistency, thus achieving reliable end-to-end delivery of inference results. In summary, this application constructs a complete data transformation link from natural language task description to executable computation graph and then to reliable inference answer, forming a data-driven forward-backward transmission relationship between each step. This overcomes the shortcomings of fragmented operation in existing technologies and improves the overall processing efficiency and resource utilization of large-scale parallel inference tasks. Attached Figure Description

[0026] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0027] Figure 1 This is a flowchart illustrating a task execution method based on computing power scheduling disclosed in an embodiment of the present invention; Figure 2This is a schematic diagram of the structure of a task execution system based on computing power scheduling disclosed in an embodiment of the present invention. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0029] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0030] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0031] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0032] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character "" in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0033] In the description of the embodiments of this application, the term "multiple" refers to two or more (including two), similarly, "multiple sets" refers to two or more (including two sets), and "multiple pieces" refers to two or more (including two pieces).

[0034] In the description of the embodiments of this application, unless otherwise expressly specified and limited, technical terms such as "installation," "connection," "joining," and "fixing" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in the embodiments of this application according to the specific circumstances.

[0035] See Figure 1 To address the technical problems in existing technologies, such as high computational latency, low resource utilization, and failure to solve complex problems due to inaccurate task parsing, delayed resource awareness, rigid parallel strategies, and inefficient collaborative execution, an embodiment of the present invention provides a task execution method based on computing power scheduling, comprising: Step 101: Perform semantic parsing on the acquired target task to break it down into several sub-tasks; Step 102: Obtain the data dependency and control dependency relationships between each of the subtasks to construct a task feature list corresponding to the target task and the serial-parallel order between each of the subtasks; Step 103: Real-time acquisition of the running data and static hardware data of each computing node in the computing center, in order to construct the real-time load characteristics and historical task execution characteristics corresponding to each computing node; Step 104: Based on the task feature list, the real-time load features, and the historical task execution features, obtain the task execution strategy corresponding to each sub-task and match the target computing node corresponding to each sub-task from the computing center; Step 105: Control the target computing node to execute the subtask according to the task execution strategy based on the serial-parallel order, and obtain the subtask execution result of each subtask; Step 106: Obtain the execution results of all the subtasks corresponding to the target task, and then assemble the execution results of each subtask to obtain the task execution result of the target task.

[0036] In this embodiment, step 101 includes: Step 1011: Perform entity annotation and recognition on the acquired target task to obtain several key entities in the target task; Step 1012: Identify the task type and determine the priority of the target task to obtain several task types corresponding to the target task and the execution priority of each task type; Step 1013: Obtain the input text length, expected output length, computing power requirement, and video memory requirement of the target task as key information of the target task; Step 1014: Based on the key entity, the task type, the execution priority, and the key information, obtain several task templates corresponding to the target task from the pre-built task template library, so as to split the target task into several sub-tasks according to the task templates.

[0037] In this embodiment, the target task is the original reasoning request input by the user through a natural language interface. Taking a power dispatching scenario as an example, the dispatcher inputs the task text "A certain 220kV operating line in a certain region's power grid tripped due to overload. Please analyze the cause of the fault, assess the load loss, and generate a load transfer plan" through a terminal device. This task text is the target task. It should be noted that this target task is unstructured natural language text, containing composite information such as equipment fault description, multiple analysis targets, and generated tasks.

[0038] Upon receiving the target task, this embodiment utilizes a large language model in collaboration with a power dispatching domain rule engine to perform comprehensive semantic analysis and feature extraction on the text content of the target task. Specifically, this embodiment employs a sequence labeling model for entity recognition and labeling of the target task. A power dispatching domain dictionary is pre-constructed, including power dispatching-specific terms such as equipment type, voltage level, event type, and action instructions. The sequence labeling model is fine-tuned and trained on a power dispatching corpus, and the trained model can output BIO (Begin, Inside, Outside) tag sequences for power dispatching text. Here, Begin represents the first character of an entity; Inside represents the remaining characters of an entity excluding the first character; and Outside represents characters that do not belong to any entity.

[0039] In this first embodiment, taking the text of the target task "overload tripping of a certain 220kV operating line in a certain region's power grid" as an example, the text is input into the sequence labeling model, and the model outputs the following BIO tag sequence: a certain region (B-LOC) power grid 220kV (B-VOL) a certain operating line (B-EQU) overload tripping (B-EVT), wherein: the certain region is labeled as a geographical area (LOC); 220kV is labeled as a voltage level (VOL); the certain operating line is labeled as an equipment name (EQU); and the overload tripping is labeled as an event type (EVT).

[0040] In this embodiment, the model also identifies multiple task target entities from the text "Please analyze the cause of the fault, assess the amount of load loss, and generate a load transfer plan," including "analyze the cause of the fault," "assess the amount of load loss," and "generate a load transfer plan." Through the above entity annotation and identification steps, this embodiment extracts several key entities from the target task, including equipment name, voltage level, event type, geographical region, and task target, for subsequent task decomposition and dependency determination.

[0041] This embodiment employs a multi-label text classification model combined with a rule-based decision tree for task type identification and priority determination. Specifically, a power dispatching task type system is predefined, which includes at least several categories such as lightweight question answering, batch data analysis, long text inference, and high-precision decision reasoning.

[0042] In this embodiment, the output entity recognition result and the original text of the target task are input into a multi-label text classification model, and the model outputs a task type probability distribution. This embodiment determines the task type of the target task based on the probability distribution; for example, the model determines that the current target task is a composite task, simultaneously including analytical reasoning tasks (analyzing the causes of failures), numerical calculation tasks (evaluating load loss), and solution generation tasks (generating load transfer solutions), corresponding to high-precision decision reasoning, batch data analysis, and long text deduction, respectively.

[0043] For priority determination, this embodiment is based on power dispatching business rules. In this embodiment, power dispatching business rules mark fault tripping issues as the highest priority and set corresponding delay constraints. Specifically, for the target task (including overload tripping events), this embodiment determines it as a highest priority fault handling task, and the corresponding delay constraint is set to P99 less than 500 milliseconds, that is, 99% of such tasks are required to complete the response within 500 milliseconds.

[0044] This embodiment extracts key information from the target task using a pre-set prompt template. Specifically, the prompt template is set to "extract input length, output length, computing power requirements, and video memory requirements," and the target task is input into the prompt template. The template guides the large language model to extract the corresponding structured key-value pairs from the target task.

[0045] This embodiment counts the number of input text tokens for the target task to obtain the input text length. For the expected output length, this embodiment estimates it based on the number of task objectives included in the target task and the expected output size of each task type. In this embodiment, the target task is a composite request, including three sub-objectives: analysis, evaluation, and generation; therefore, the estimated expected output token length is 1200 tokens. For computing power requirements, this embodiment estimates them based on the input text length, expected output length, and task type of the target task. In this embodiment, based on a pre-built computing power requirement mapping table and combined with the characteristic information of the target task, the computing power consumption required for the task is estimated. For GPU memory requirements, this embodiment estimates them based on the computational complexity and expected output size of the target task. In this embodiment, combined with the GPU memory usage patterns of large model inference, the peak GPU memory requirement for the target task is estimated to be 24GB.

[0046] This embodiment pre-constructs a task template library for the power dispatching field. The task template library stores multiple task templates, each containing a template identifier, a composite request mode, and a correspondence between the decomposed atomic task sequences. For example, the task template library contains a task template with template ID TPL-001, whose composite request mode is "fault cause analysis + load shedding assessment + solution generation," and the corresponding decomposed atomic task sequence is: Subtask 1: Extract information about the faulty line and associated protection action signals; Subtask 2: Retrieve the power flow data and weather conditions of the line within a preset time period before the fault occurred; Subtask 3: Query the power grid topology of the area where the line is located; Subtask 4: Search the knowledge base of typical overload tripping causes and generate a list of candidate causes; Subtask 5: Based on the power grid topology, analyze the load loss area and load loss amount caused by fault isolation; Subtask 6: Call the power flow calculation model to generate a load transfer scheme.

[0047] This embodiment uses the acquired key entities, task types, execution priorities, and key information as query conditions to retrieve and match data from the task template library. In one embodiment, this embodiment extracts multiple features of the target task, including the entity types contained in the task (equipment name, voltage level, event type), the number of task targets (three), and task target keywords (analysis, evaluation, and generation). These features are combined into a query vector and matched with the composite request patterns of each template in the task template library.

[0048] This embodiment calculates the matching degree between the target task and each task template, and selects the task template with the highest matching degree as the target template. In this embodiment, the task template with the highest matching degree is recalled from the task template library. The composite request pattern of this task template completely matches the target task, so that the target task can be split into several atomic subtasks according to the task template. It should be noted that each atomic subtask is a complete, independent problem that can be directly solved by querying a knowledge base, database, or calling a simple computational model.

[0049] This embodiment identifies and marks entities within the target task to obtain several key entities. Semantic tag data representing core elements such as devices, events, and targets within the task is acquired to support subsequent entity-driven dependency determination. Task type identification and priority determination are performed on the target task to obtain several task types and their corresponding execution priorities. Control data representing task urgency and resource scheduling levels are obtained to achieve differentiated service quality assurance. The input text length, expected output length, computing power requirements, and memory requirements of the target task are acquired as key information to obtain quantitative characteristic data representing the task's computational scale and resource consumption, providing numerical basis for subsequent scheduling matching. Based on key entities, task types, execution priorities, and key information, several task templates corresponding to the target task are obtained from a pre-built task template library. The target task is then divided into several sub-tasks based on these templates, resulting in a structured sub-task list representing the atomized decomposition results of the complex problem. This enables the structured transformation from unstructured natural language to computable task units. In summary, the above solution transforms complex natural language requests that are originally incomprehensible to the scheduling system into a standard list of sub-tasks containing entity labels, type attributes, and quantification requirements through a four-stage semantic parsing process of entity recognition, type determination, information extraction, and template matching. This provides accurate task-dimensional data input for subsequent dependency modeling and resource matching.

[0050] In this embodiment, step 102 includes: Step 1021: For any one of the subtasks, obtain the set of input entities and the set of output entities corresponding to the subtask from all the key entities corresponding to the target task; Step 1022: For any two subtasks, the first subtask and the second subtask, when the output entity set of the first subtask and the input entity set of the second subtask intersect, it is determined that the second subtask depends on the first subtask, which is used as the data dependency relationship between the first subtask and the second subtask. Step 1023: For any two subtasks, the first subtask and the second subtask, based on the task type, input entity set, and output entity set of the first subtask and the task type, input entity set, and output entity set of the second subtask, match the control dependency relationship between the first subtask and the second subtask from the pre-built domain business rule base. Step 1024: For any of the subtasks, based on the input text length, expected output length, computing power requirement, and video memory requirement of the target task and the task template corresponding to the subtask, obtain the task text length, expected output length, estimated computing power requirement, and estimated video memory requirement of the subtask. Step 1025: Use the task text length, expected output length, estimated power requirement, estimated memory requirement, task type and execution priority corresponding to the subtask as the feature vector of the subtask. Step 1026: Based on the data dependencies and control dependencies between the subtasks, construct a directed acyclic graph of task dependencies corresponding to the target task; Step 1027: Obtain several parallel execution queues and the stripping order of each parallel execution queue from the directed acyclic graph of the dependency relationship according to the topological sorting of the layer-by-layer stripping; wherein, each parallel execution queue includes several parallel execution subtasks; Step 1028: Determine the serial execution order among different parallel execution queues in all the parallel execution queues according to the stripping order; Step 1029: Generate a list of task features corresponding to the target task based on the directed acyclic graph of task dependencies and the feature vectors corresponding to each of the subtasks.

[0051] For any of the subtasks, this embodiment obtains the text description of the subtask, performs semantic analysis on the text description, and identifies two types of entities: (1) the input entities on which the execution of the subtask depends, that is, the data objects that the subtask needs to obtain as a consumer, which constitute the input entity set of the subtask; (2) the entities produced after the execution of the subtask, that is, the data objects generated by the subtask as a producer, which constitute the output entity set of the subtask.

[0052] This embodiment uses the subtasks obtained from the splitting process as an example: For subtask 1: extract fault line information (a certain operating line, 220kV, tripping time) and associated protection action signals; in this embodiment, the output entity set is extracted from the text description of this subtask as (fault line information, protection action signals); the input entity set is the fault description information contained in the original target task (i.e., the entity in the overload tripping of a certain operating line of a certain 220kV power grid in a certain region).

[0053] For subtask 2: retrieve the power flow data (active, reactive, and current) and meteorological conditions of the line 15 minutes before the fault, this embodiment extracts its input entity set as (fault line identifier, fault occurrence time), where the fault line identifier comes from the fault line information output by subtask 1, and its output entity set is (power flow data, meteorological conditions).

[0054] For subtask 3: query the power grid topology (adjacent lines, transformers, bus connections) of the area where the line is located; in this embodiment, the input entity set is extracted as (fault line identifier), and the input entities also come from the output of subtask 1, and the output entity set is (power grid topology).

[0055] For subtask 4: retrieve the knowledge base of typical overload tripping causes and generate a list of candidate causes (such as lightning strikes, tree obstructions, overload exceeding limits, and protection malfunctions); in this embodiment, the input entity set is extracted as (fault line information, protection action signals), wherein the input entity set comes from the output of subtask 1, and its output entity set is (candidate cause list).

[0056] For subtask 5: Based on the power grid topology, analyze the load loss area and load loss amount caused by fault isolation; in this embodiment, the input entity set is extracted as (power grid topology, fault isolation information), where the input of this subtask comes from the output of subtask 3 and subtask 1 respectively, and the output entity set of this subtask is (load loss area, load loss amount).

[0057] For subtask 6: invoke the power flow calculation model to generate a load transfer scheme (which tie switches to close and which transformer taps to adjust); in this embodiment, the input entity set is extracted as (candidate cause list, load loss area, load loss amount). The inputs of this subtask are derived from the outputs of subtasks 4 and 5, and the output entity set of this subtask is (load transfer scheme).

[0058] In summary, this embodiment establishes an input entity set and an output entity set for each subtask, so as to automatically determine the data dependency relationship between any two subtasks based on the input entity set and output entity set of each subtask.

[0059] In this embodiment, for any two subtasks, the first subtask A and the second subtask B are obtained, the output entity set of the first subtask A and the input entity set of the second subtask B are obtained, and the intersection between the two sets is calculated: when the output entity set of the first subtask A and the input entity set of the second subtask B have an intersection (that is, at least one entity belongs to both sets at the same time), it is determined that the second subtask B depends on the first subtask A, that is, the first subtask A must be executed before the second subtask B.

[0060] For example, for subtasks 1 and 2, this embodiment obtains the output entity set of subtask 1 (fault line information, protection action signal) and the input entity set of subtask 2 (fault line identifier, fault occurrence time). It is found that the two sets have an intersection (fault line information / fault line identifier), therefore, subtask 2 depends on subtask 1. For subtasks 1 and 3, obtaining the output entity set of subtask 1 (fault line information, protection action signal) and the input entity set of subtask 3 (fault line identifier) ​​shows that the two sets have an intersection, therefore, subtask 3 depends on subtask 1. For subtasks 1 and 4, obtaining the output entity set of subtask 1 (fault line information, protection action signal) and the input entity set of subtask 4 (fault line information, protection action signal) shows that the two sets completely overlap, therefore, subtask 4 depends on subtask 1. For subtasks 3 and 5, obtaining the output entity set of subtask 3 (power grid topology) and the input entity set of subtask 5 (power grid topology, From the fault isolation information, it can be seen that the two sets have an intersection entity (power grid topology), indicating that subtask 5 depends on subtask 3; for subtask 2 and subtask 5, obtaining the output entity set of subtask 2 (power flow data, weather conditions) and the input entity set of subtask 5 (power grid topology, fault isolation information), it can be seen that the two sets do not have an intersection, indicating that subtask 5 does not depend on subtask 2; similarly, between subtask 4 and subtask 6, obtaining the output entity set of subtask 4 (candidate cause list) and the input entity set of subtask 6 (candidate cause list, load loss area, load loss amount), it can be seen that the two sets have an intersection entity (candidate cause list), indicating that subtask 6 depends on subtask 4; between subtask 5 and subtask 6, obtaining the output entity set of subtask 5 (load loss area, load loss amount) and the input entity set of subtask 6 (candidate cause list, load loss area, load loss amount), it can be seen that the two sets have an intersection entity (load loss area, load loss amount), indicating that subtask 5 depends on subtask 4; (Unload loss), determine that subtask 6 depends on subtask 5; for subtasks 1, 2 and 3, the input entity sets of the three do not need to wait for the output entity sets of other subtasks, so there is no data dependency between the three and they can be executed in parallel.

[0061] Meanwhile, this embodiment automatically matches the control dependencies between subtasks based on a pre-built domain business rule base. Specifically, this embodiment pre-builds a power dispatching domain business rule base, which stores multiple control dependency rules, each containing a condition part and a conclusion part. This embodiment uses the task type, input entity set, and output entity set of the subtask as query conditions and matches them in the domain business rule base. For example, the domain business rule base pre-sets the following control dependency rule: when there is a subtask with the task type "cause deduction" and a subtask with the task type "solution generation", "cause deduction" must be executed before "solution generation". In this embodiment, subtask 4 is a cause retrieval task, and subtask 6 is a solution generation task. Matching the above rule generates a control dependency edge from subtask 4 to subtask 6.

[0062] Furthermore, to further improve the accuracy of dependency identification, this embodiment also inputs paired subtasks into a large language model for auxiliary verification. Specifically, for any two subtasks A and B, this embodiment inputs the paired subtasks A and B into the large language model and queries the large language model whether B depends on the output of A. The large language model outputs a probability score, which represents the confidence level of subtask B depending on subtask A. When the probability score is higher than a preset threshold, this embodiment confirms or adds a dependency edge from subtask A to subtask B. This large language model-assisted verification step is particularly suitable for special dependency scenarios that are not explicitly defined in the rule base.

[0063] In this embodiment, for each subtask, based on the global key information of the target task and the corresponding task template, the quantized feature parameters of the subtask are calculated. Specifically, this embodiment obtains the input text length and expected output length of the target task, as well as the computing power requirements and memory requirements of the target task. For each subtask, this embodiment obtains the corresponding task template, which contains the text description information of the subtask.

[0064] This embodiment calculates the task text length of a subtask based on the input text length and expected output length of the target task, combined with the task template of the subtask. In this embodiment, the task text length is obtained by segmenting and counting the words in the text description of the subtask. For subtask 1, "Extracting faulty line information and associated protection action signals," this embodiment counts the number of tokens contained in the subtask text to obtain the task text length of the subtask. Similarly, this embodiment counts the words for each of the other subtasks to obtain the task text length for each subtask.

[0065] For the expected output length of the task, this embodiment estimates it based on the task type and task template of the subtask. Specifically, this embodiment estimates the expected output token length of the subtask based on the expected output scale information of various types of tasks stored in a pre-built task template library, combined with the text description of the subtask. For the estimated computing power requirement, this embodiment estimates it based on the task type, task text length, and expected output length of the subtask. Specifically, the system, based on a pre-established computing power requirement assessment model, takes the task type, task text length, and expected output length of the subtask as input parameters and outputs the estimated computing power requirement of the subtask. For the estimated video memory requirement, this embodiment estimates it based on the task type and expected output length of the subtask. Specifically, this embodiment estimates the peak video memory requirement of the subtask based on the mapping relationship between video memory requirement and input length and output length, combined with the task type of the subtask.

[0066] This embodiment combines the multi-dimensional attribute information of each subtask into a unified feature vector representation. Specifically, for any subtask, this embodiment combines the data of the above six dimensions in a preset order according to the task text length, expected output length, estimated power requirement, estimated memory requirement, task type, and execution priority of the subtask to form the feature vector corresponding to the subtask. This feature vector represents all the key attributes of the subtask in a standardized numerical form.

[0067] This embodiment integrates the identified data dependencies and control dependencies to construct a unified directed acyclic graph (DAG). Specifically, using the aforementioned subtasks as vertices and the data dependencies and control dependencies between subtasks as directed edges, a DAG is constructed. The directed edges in the DAG represent the dependency direction between subtasks, i.e., from the dependent subtask to the subtask that depends on it.

[0068] In this embodiment, if the output entity set of subtask 1 is {fault line information, protection action signal}, the input entity sets of subtasks 2, 3 and 4 all contain the output entities from subtask 1. Therefore, there are directed edges from subtask 1 to subtask 2, from subtask 1 to subtask 3 and from subtask 1 to subtask 4 in the directed acyclic graph. Similarly, directed edges between other subtasks are constructed.

[0069] In this embodiment, a topological sorting process is performed on the constructed dependency-dependent directed acyclic graph (DAG) to determine the optimal execution level for each subtask. Specifically, this embodiment uses the Kahn algorithm to perform topological sorting on the dependency-dependent DAG. The basic principle of the Kahn algorithm is as follows: First, identify all vertices in the graph with an in-degree of zero (i.e., subtasks that are not depended upon by any other subtask), and group these vertices into the same level as a parallel execution queue; then, remove these vertices from the graph and update the in-degree of the remaining vertices; repeat the above process until all vertices in the graph have been removed. Based on the constructed dependency-dependent DAG, this embodiment calculates the in-degree of the DAG.

[0070] In this embodiment, the in-degree of subtasks 1, 2, and 3 is zero because these three subtasks do not depend on the output of any other subtasks. Therefore, (subtask 1, subtask 2, subtask 3) is set as the first-level parallel execution queue, with a stripping order of 1. After removing subtasks 1, 2, and 3 from the diagram, the in-degree of the remaining subtasks 4, 5, and 6 is updated. At this point, the in-degree of subtask 4 becomes zero (subtask 4 depends only on subtask 1, which has been removed). In this embodiment, subtask 4 is set as the second-level parallel execution queue, with a stripping order of 2. After removing subtask 4 from the diagram, the in-degree of the remaining subtasks 5 and 6 is updated. At this point, the in-degree of subtask 5 becomes zero (subtask 5 depends on subtasks 2 and 3, both of which have been removed). In this embodiment, subtask 5 is set as the third-level parallel execution queue, with a stripping order of 3. In this embodiment, after removing subtask 5 from the diagram, the in-degree of subtask 6 becomes zero (subtask 6 depends on subtasks 4 and 5, both of which have been removed). In this embodiment, subtask 6 is used as the fourth-level parallel execution queue, and the corresponding stripping order is 4.

[0071] Through the topological sorting of the above-mentioned layer-by-layer stripping, this embodiment obtains four parallel execution queues from the directed acyclic graph of the dependency relationship, namely: the first parallel execution queue (subtask 1, subtask 2, subtask 3) (stripping order 1), the second parallel execution queue (subtask 4) (stripping order 2), the third parallel execution queue (subtask 5) (stripping order 3), and the fourth parallel execution queue (subtask 6) (stripping order 4).

[0072] This embodiment maps the stripping order of each parallel execution queue to the serial execution order of all subtasks within that queue. Specifically, for multiple subtasks within the same parallel execution queue, there are no dependencies between them, so they can be executed in parallel without any order of execution. For different parallel execution queues, this embodiment determines the serial execution order based on the stripping order: subtasks in the parallel execution queue with a stripping order of 1 have priority over subtasks in the parallel execution queue with a stripping order of 2.

[0073] In this embodiment, the generated directed acyclic graph of task dependencies and the feature vectors of each subtask are fused to generate a structured task feature list corresponding to the target task. Specifically, the task feature list includes the following information for each subtask: task type, computing power requirement threshold, peak memory requirement, business latency constraint, execution priority, task association relationship, and sequence length parameter.

[0074] Taking the six sub-tasks obtained from the decomposition as an example, the structured task feature list generated in this embodiment is as follows: For subtask 1 (extracting faulty line information and associated protection action signals), the task feature list includes: task type (entity retrieval), estimated power requirement (determined based on the estimated power requirement in the feature vector), estimated memory requirement (determined based on the estimated memory requirement in the feature vector), service delay constraint (delay constraint corresponding to the highest priority), execution priority (highest priority), task association relationship (depended on by subtask 2, subtask 3, and subtask 4), and sequence length parameter (input token length and output token length).

[0075] For subtask 2 (retrieving power flow data and meteorological conditions of the line 15 minutes before the fault), the task feature list includes: task type (data extraction), estimated power requirements, estimated memory requirements, business delay constraints, execution priority, task association (dependent on subtask 1, dependent on subtask 5), and sequence length parameter.

[0076] For subtask 3 (querying the power grid topology of the area where the line is located), the task feature list includes: task type (topology query), estimated power demand, estimated memory demand, business delay constraints, execution priority, task association (dependent on subtask 1, dependent on subtask 5), and sequence length parameter.

[0077] For subtask 4 (retrieving the knowledge base of typical overload tripping causes and generating a list of candidate causes), the task feature list includes: task type (cause deduction), estimated capacity requirement, estimated memory requirement, business delay constraints, execution priority, task association (dependent on subtask 1, dependent on subtask 5 and subtask 6), and sequence length parameter.

[0078] For subtask 5 (based on the power grid topology, analyze the load loss area and load loss amount caused by fault isolation), the task feature list includes: task type (numerical calculation), estimated load requirement, estimated memory requirement, business delay constraint, execution priority, task association (dependent on subtask 2 and subtask 3, and dependent on subtask 6), and sequence length parameter.

[0079] For subtask 6 (calling the power flow calculation model to generate a load transfer scheme), the task feature list includes: task type (scheme generation), estimated power requirements, estimated GPU memory requirements, business latency constraints, execution priority, task association (depending on subtasks 4 and 5), and sequence length parameter. It is important to note that this task feature list is stored in a standardized data format, allowing it to be directly read and processed by the subsequent task-power dynamic mapping module, providing task-dimensional foundational data for power matching and acceleration strategy selection.

[0080] This embodiment obtains the input entity set and output entity set corresponding to any subtask from all key entities corresponding to the target task, thus acquiring entity boundary data representing the data consumption and output relationship of each subtask, which is used to construct the quantitative basis for data dependency determination. For any two subtasks, specifically the first and second subtasks, if the output entity set of the first subtask intersects with the input entity set of the second subtask, the second subtask is determined to depend on the first subtask, serving as the data dependency relationship between them. Directed edge data representing the data flow direction between subtasks is obtained, used to automatically discover implicit data transit dependencies. Furthermore, for any two subtasks... The system first defines a subtask and a second subtask. Based on the task type, input entity set, and output entity set of the first subtask, and the task type, input entity set, and output entity set of the second subtask, it matches the control dependency relationship between the first and second subtasks from a pre-built domain business rule base. This obtains rule edge data representing the sequential constraints at the business logic level, which is used to supplement domain-specific sequential constraints that cannot be covered by data dependencies. By constructing a task feature list corresponding to the target task and the serial and parallel sequences between each subtask based on the data dependency relationship and the control dependency relationship, it obtains a complete dependency relationship map and execution order data that integrates data flow and control flow, which is used to achieve automated and precise planning of the subtask execution order.In summary, the above scheme achieves automated joint modeling of data dependencies and control dependencies through a dual-channel dependency identification mechanism of entity set intersection judgment and domain rule base matching. This overcomes the shortcomings of existing technologies that rely on manual configuration or hard coding, and improves the completeness and accuracy of task dependency discovery. Specifically, for any subtask, based on the input text length, expected output length, computing power requirements, and memory requirements of the target task, as well as the corresponding task template, the scheme obtains the task text length, expected output length, estimated computing power requirements, and estimated memory requirements of the subtask. This yields quantitative feature metadata representing the computational scale and resource consumption of a single subtask, used for differentiated comparison of resource requirements among subtasks. By using the task text length, expected output length, estimated computing power requirements, estimated memory requirements, task type, and execution priority of the subtask as feature vectors, standardized numerical vector data representing the multi-dimensional attributes of the subtask is obtained, supporting the quantitative calculation of subsequent task-node matching. Based on the data and control dependencies between subtasks, a directed acyclic graph (DAG) of task dependencies corresponding to the target task is constructed to obtain graph structure data representing the complete logical constraints between subtasks, which is used as the input data structure for topological sorting. Several parallel execution queues and their stripping order are obtained from the DAG of dependencies through a layer-by-layer stripping topological sorting. Scheduling queue data representing the groups of parallelizable subtasks and their order is obtained to achieve execution planning that maximizes parallelism. The serial execution order between different parallel execution queues is determined according to the stripping order, and serialized control data representing cross-queue execution constraints is obtained to ensure that dependencies are not violated. A task feature list corresponding to the target task is generated based on the DAG of task dependencies and the feature vectors corresponding to each subtask, obtaining unified task description data that integrates graph structure dependencies and vectorized attributes, providing dual-dimensional information input including dependencies and features for subsequent scheduling matching. In summary, the above scheme, by combining directed acyclic graph construction with layer-by-layer topological sorting, transforms implicit dependency constraints into explicit parallel queues and serial sequences, effectively improving the parallelism of subtask execution and overall inference efficiency.

[0081] In this embodiment, step 103 includes: Step 1031: For any computing power node, obtain the multi-dimensional operating indicators and static hardware data of that computing power node in real time; Step 1032: Generate the real-time load characteristics corresponding to the computing power node based on the multi-dimensional operating indicators; Step 1033: For any subtask of a task type, obtain the actual execution delay and predicted delay of the computing node executing the subtask of that task type within a preset historical time period; Step 1034: Obtain the ratio of the actual execution delay to the predicted delay, as a historical task execution characteristic of the computing node executing subtasks of this task type.

[0082] In this embodiment, the computing center includes multiple heterogeneous computing power nodes, which contain different types of graphics processing units. This embodiment uses resource monitoring to collect quantitative operational metrics of each computing power node at fixed intervals. Specifically, for any given computing power node, this embodiment acquires its multi-dimensional operational metrics in real time. These multi-dimensional operational metrics include, but are not limited to, the following four categories: (1) Video memory resource indicators: Collect the used video memory, available video memory, video memory utilization rate and instantaneous video memory overflow times of the computing node; for example, for a certain A100 computing node in the computing center, the current available video memory of the node is 22.4GB and the video memory utilization rate is 72%.

[0083] (2) Computing load indicators: Collect the core utilization rate of the computing power node, the real-time inference throughput of a single card (in units of tokens / s) and the average computing time of a single task; for example, the core utilization rate of a certain computing power node is 25%, and the real-time inference throughput of a single card is 1200 tokens / s.

[0084] (3) Network communication indicators: Collect the card interconnection bandwidth, communication delay, communication congestion rate and number of data packet loss of the computing power node; for example, the communication delay of a certain computing power node is 15μs and the congestion rate is 0.3%.

[0085] (4) Queue backlog indicators: Collect the local task queue length, queue backlog growth rate and average task waiting time of the computing power node; for example, the local task queue backlog length of a certain computing power node is 3 tasks and the average task waiting time is 8ms.

[0086] Simultaneously, this embodiment also acquires static hardware data for each computing node; wherein, the static hardware data is the hardware specification information pre-configured for each computing node, which is stored in the resource management database when each computing node registers and joins the computing center. Specifically, the static hardware data includes, but is not limited to: model identifier (including graphics processing unit model, number of CPU cores, memory size), total video memory (e.g., 40GB), peak computing power (e.g., FP16 computing power), communication topology (including inter-card interconnection type such as NVLink or PCIe, inter-node network bandwidth), and maximum queue capacity threshold (e.g., 10 tasks, which is calibrated based on the node's historical performance).

[0087] This embodiment generates corresponding real-time load characteristics for each computing node based on real-time acquired multi-dimensional operational metrics. Specifically, the real-time load characteristics are instantaneous state vectors of the current node generated based on the latest collected quantized operational metrics. This embodiment combines the collected multi-dimensional operational metrics of the computing node, such as memory utilization, computing core utilization, local task queue backlog length, and network communication latency, to form the real-time load characteristic vector of the computing node. The real-time load characteristics directly reflect the current load capacity of the computing node, i.e., the available memory resources, idle computing resources, queue waiting time, and other instantaneous state information. For example, for a certain A100 computing node, the real-time load characteristics generated in this embodiment based on the collected multi-dimensional operational metrics include: memory utilization of 72%, computing core utilization of 25%, local task queue backlog of 3 tasks, and communication latency of 15μs.

[0088] In this embodiment, for each computing node, its execution performance on different types of subtasks within a preset historical time period is statistically analyzed. Specifically, the historical task execution characteristics record the execution performance of the computing node on different types of tasks over a past period. In this embodiment, the preset historical time period is the past hour, and the historical execution data of each computing node is maintained using a sliding window method. For any subtask of any task type, this embodiment obtains the actual execution latency of the computing node executing the subtask of that task type within the preset historical time period. The actual execution latency is the actual time consumed by the computing node when executing this type of subtask historically. Simultaneously, this embodiment obtains the predicted latency of the computing node for the subtask of that task type within the preset historical time period. The predicted latency is the expected time consumption pre-calculated by the system based on the hardware specifications of the computing node and the feature vector of the subtask before executing this type of subtask. The prediction latency includes computation latency and communication latency. The computation latency is determined jointly based on the number of model parameters, the length of the subtask input token, the length of the output token, the peak computing power of the node, and the historical average computing utilization of the node. The communication latency is only involved in the calculation of prediction latency in tensor parallel or pipelined parallel modes, and the communication latency is 0 in single-card inference mode.

[0089] This embodiment extracts the actual execution latency data for each execution of the same type of subtask from historical execution logs and obtains the corresponding predicted latency data from scheduling records. This embodiment performs statistical analysis on multiple execution records within a preset historical time period to obtain the actual execution latency and predicted latency of the computing node executing subtasks of that task type. For example, for a certain A100 computing node, this embodiment statistically analyzes the short-sequence type subtasks executed by the node in the past hour, obtains the actual execution latency and corresponding predicted latency for each execution, and then calculates the ratio of the actual execution latency to the predicted latency. This ratio is used as the historical task execution characteristic of the computing node executing subtasks of that task type. Specifically, for any subtask of a task type, this embodiment obtains the actual execution latency and predicted latency of the computing node executing subtasks of that task type within a preset historical time period, and calculates the ratio of the actual execution latency to the predicted latency. The ratio reflects the degree of deviation between the actual execution efficiency of the computing node for the subtask of that task type and the theoretical expectation. When the ratio is less than 1, it means that the actual performance of the computing node in executing this type of subtask is better than expected, indicating that the node has good adaptability to this type of task; when the ratio is greater than 1, it means that the actual performance of the computing node in executing this type of subtask is worse than expected, indicating that the node has poor adaptability to this type of task.

[0090] This embodiment divides subtasks into short-sequence tasks and long-sequence tasks based on the length of the input token. This embodiment calculates the ratio of the actual execution latency to the predicted latency for each computing node for short-sequence tasks to obtain the short-sequence task adaptation coefficient; and the ratio of the actual execution latency to the predicted latency for long-sequence tasks to obtain the long-sequence task adaptation coefficient. For example, for the aforementioned A100 computing node, this embodiment calculates its short-sequence adaptation coefficient to be 0.85, indicating that the actual latency of this node in executing short-sequence tasks is only 85% of the predicted latency, demonstrating good adaptability to short-sequence tasks; the long-sequence adaptation coefficient is 1.12, indicating that the actual latency of this node in executing long-sequence tasks is 112% of the predicted latency, demonstrating relatively poor adaptability to long-sequence tasks. This embodiment updates the historical task execution characteristics of each computing node using a sliding window method. Specifically, whenever a new subtask of the same type is completed, this embodiment obtains the actual execution latency of that execution, recalculates the ratio of the average actual execution latency to the average predicted latency for subtasks of that task type, and updates the corresponding long / short sequence task adaptation coefficients. The preset historical time period (e.g., 1 hour) can be adjusted according to the system configuration to balance the stability of historical data and the responsiveness to changes in node performance.

[0091] This embodiment associates and stores the real-time load characteristics and historical task execution characteristics (including short-sequence adaptation coefficient and long-sequence adaptation coefficient) of each computing node to form a dual-mode performance profile of that computing node. For example, the dual-mode performance profile of a certain A100 computing node is as follows: real-time load (memory utilization 72%, computing core utilization 25%, local task queue backlog length 3 tasks, communication latency 15μs); historical adaptation (short-sequence adaptation coefficient 0.85, long-sequence adaptation coefficient 1.12). It should be noted that in the dual-mode performance profile, the real-time load characteristics directly reflect the node's current load capacity, i.e., the instantaneous state such as available memory, idle computing power, and queue waiting time; the historical task execution characteristics are used to correct the load score and determine the node's task adaptation attributes, so that the scheduling decision considers not only the current load but also the node's historical performance for specific types of tasks.

[0092] Based on the load capacity and task adaptation attributes of each computing node, this embodiment generates a real-time computing resource status report. This report includes the available GPU memory, real-time load score, running status labels (e.g., moderate anomaly, low load, high adaptation), and long / short sequence task adaptation coefficients for each computing node. The real-time load score is calculated by weighting the GPU memory utilization, computing core utilization, local task queue backlog length, and network communication latency of each computing node, and the long / short sequence task adaptation coefficients are incorporated as a correction term. The running status labels are determined comprehensively based on the node's real-time load score and task adaptation coefficients. For example, a node with low load and both long / short sequence adaptation coefficients less than 1 is marked as low load, high adaptation; a node with more than a threshold number of GPU memory overflows is marked as moderate anomaly.

[0093] This embodiment acquires multi-dimensional operational metrics and static hardware data of any computing node in real time, obtaining raw index data characterizing the node's current instantaneous load state and inherent physical capabilities, which serves as the basic data source for load feature generation. Based on the multi-dimensional operational metrics, it generates real-time load features corresponding to the computing node, acquiring instantaneous state vector data characterizing the node's current memory pressure, computing power occupancy, and queue backlog, enabling dynamic quantitative perception of the node's load state. For any task type's subtasks, it acquires the actual execution latency and predicted latency of the computing node executing subtasks of that task type within a preset historical time period, obtaining empirical data characterizing the node's historical performance for specific task types, used to evaluate the node's adaptability to task types. By acquiring the ratio of actual execution latency to predicted latency as the historical task execution feature of the computing node executing subtasks of that task type, it obtains normalized adaptation coefficient data characterizing the node's relative proficiency in short-sequence or long-sequence tasks, used as a correction term for load scoring. In summary, the above solution constructs a dual-mode performance profile that simultaneously generates real-time load characteristics and historical task execution characteristics. This enables the system to not only perceive the current load status of nodes but also understand the historical adaptation performance of nodes to different types of tasks. This overcomes the shortcomings of existing technologies that rely solely on static performance data or single-dimensional real-time indicators for scheduling, and improves the scientificity and accuracy of task-resource matching.

[0094] In this embodiment, step 104 includes: Step 1041: For any of the subtasks, obtain the business delay constraints and estimated execution time corresponding to the subtask based on the task template corresponding to the subtask; Step 1042: For any computing node in the computing center, when the available video memory of the computing node is greater than or equal to the estimated video memory requirement corresponding to the subtask and the sum of the queue waiting time of the computing node and the estimated execution time is less than or equal to the business delay constraint, the computing node is regarded as the candidate computing node corresponding to the subtask. Step 1043: For any candidate computing node, obtain the compatibility score between the candidate computing node and the subtask based on the real-time load characteristics and historical task execution characteristics of the candidate computing node; Step 1044: Sort all the candidate computing nodes corresponding to the subtask according to the adaptation score, and assign a target computing node to the subtask according to the sorting order; Step 1045: When the task text length of the subtask is less than the preset first length threshold and the estimated video memory requirement of the subtask is less than the preset first video memory requirement threshold, match a single-card inference strategy for the subtask. Step 1046: When the task text length of the subtask is greater than or equal to the first length threshold and less than the preset second length threshold, and the estimated memory requirement of the subtask is greater than or equal to the first memory requirement threshold and less than the preset second memory requirement threshold, a tensor parallel strategy is matched for the subtask. Step 1047: When the task text length of the subtask is greater than or equal to the second length threshold and the estimated memory requirement of the subtask is greater than or equal to the second memory requirement threshold, a pipeline parallel strategy is matched for the subtask.

[0095] This embodiment obtains a task template corresponding to each subtask. The task template contains the business attribute information of the subtask, including the business scenario type to which the subtask belongs and the expected response time requirement. Based on the business scenario type in the task template and combined with the power dispatch business rules, the business delay constraint corresponding to the subtask is determined. The business delay constraint represents the maximum time allowed for the subtask from issuance to completion. For example, for the split subtask 4 (retrieving the knowledge base of typical overload tripping causes and generating a candidate cause list) and subtask 6 (calling the power flow calculation model and generating a load transfer scheme), since both are critical tasks in the fault handling scenario, this embodiment marks them as the highest priority according to the power dispatch business rules, and the corresponding business delay constraint is set to P99 less than 500 milliseconds, that is, 99% of such tasks are required to complete the response within 500 milliseconds.

[0096] Simultaneously, this embodiment obtains the estimated execution time corresponding to the subtask based on its feature vector. The estimated execution time is the expected execution time required for the subtask on a standard computing node, and its calculation method is as follows: In the formula, Let be the computation time of subtask j on computing node i. For communication time; the For execution time.

[0097] The calculation time Calculate using the following formula: in, For the number of model parameters, For the input token length, To output the token length, Let i be the peak computing power of node i. The historical average computing utilization rate of node i is calculated by the ratio of the node's historical actual computing power output to its peak computing power. If node i has no historical computing power output value, then... The value is 0.45.

[0098] In this embodiment, the communication time It only participates in computation in tensor parallel or pipelined parallel modes; in single-card inference mode, the communication time is 0. The communication time is calculated according to the following formula: Where Dy is the amount of intermediate activation data that needs to be transmitted between nodes in parallel mode, and Bx is the interconnection bandwidth between nodes.

[0099] In this embodiment, based on the above formula and combining the feature vector of the subtask and the static hardware data of the node, the estimated execution time of the subtask on the standard reference node is calculated.

[0100] In this embodiment, based on the acquired business latency constraints and estimated execution time, combined with the available GPU memory and current queue status of each computing node, all computing nodes in the computing center are screened. Specifically, for any computing node in the computing center, the available GPU memory of that node is first obtained. The available GPU memory is determined according to the collected GPU memory resource indicators, that is, the total GPU memory of the node minus the used GPU memory. This embodiment determines whether the available GPU memory of the computing node is greater than or equal to the estimated GPU memory requirement corresponding to the subtask. If so, the GPU memory constraint condition is checked. The estimated GPU memory requirement is determined based on the input token length and output token length of the subtask: for every 1000 additional tokens in the input, the GPU memory increases by approximately 4GB; if the subtask explicitly uses a model with a certain parameter scale, the standard GPU memory usage of the model is directly obtained by looking up a table, and then adjusted according to the actual sequence length ratio.

[0101] Simultaneously, this embodiment obtains the current queue waiting time of the computing node (i.e., the estimated time required for tasks in the current queue of the node to complete), adds the queue waiting time to the estimated execution time, and obtains the estimated response time of the subtask on the node. This embodiment determines whether the estimated response time is less than or equal to the business latency constraint corresponding to the subtask. If so, the latency constraint condition is checked. If and only if a computing node simultaneously meets both of the above conditions, this embodiment considers the computing node as a candidate computing node corresponding to the subtask. Through the above screening, this embodiment eliminates nodes with insufficient available video memory and nodes whose queue waiting time and estimated execution time exceed the business latency constraint, obtaining a set of candidate nodes that meet the basic constraint conditions.

[0102] In this embodiment, for each candidate computing node in the selected candidate node set, its compatibility score with the subtask is calculated. Specifically, this embodiment adopts a hybrid scheduling strategy combining real-time minimum load priority with heuristic weight correction, and calculates the compatibility score of each candidate computing node according to the following comprehensive load scoring formula: in, The comprehensive load score (i.e., adaptation score) for the i-th computing node. The memory utilization rate of node i; The core utilization rate of computing power for node i; Let be the length of the local task queue backlog for node i; Let be the maximum capacity threshold of the queue for node i; Let be the normalized value of the interconnection communication delay of node i; The long-short sequence task adaptation coefficient for node i is the average ratio of the actual latency to the predicted latency of historical tasks executed on that node, used to correct the load score; α, β, γ, and δ are service weight coefficients, calibrated offline by scheduling service latency constraints and memory sensitivity characteristics; k is the adaptation coefficient correction weight. The smaller the adaptation score Li, the higher the node's idle time and the better its task adaptation.

[0103] In this embodiment, the business weight coefficients are dynamically calibrated based on task type, power grid business scenario, and real-time feedback. For typical power dispatch task types (including fault handling, operation mode optimization, information query, and batch analysis), the basic weights are set as α=0.4, β=0.2, γ=0.3, and δ=0.1. This embodiment adjusts the weight coefficients based on feedback such as the memory overflow rate, queue timeout rate, and load imbalance of tasks within the most recent time period. Specifically, this embodiment uses a fixed-duration sliding statistical window of 1 hour to continuously collect power grid inference task operation feedback indicators, with a weight evaluation cycle of 30 minutes. A dual-timescale update mechanism is also set to distinguish between short-term fine-tuning and long-term benchmark recalibration, enabling the weight coefficients to adaptively track business changes. For example, if the proportion of memory overflow tasks reaches 12% within the sliding window (the preset threshold is a memory overflow proportion greater than 5%), the weight α for that dimension is adjusted. The magnitude of a single adjustment is limited to within ±5% of the initial weight value. After the adjustment, the weights of the other three items are reduced synchronously according to their original proportions, maintaining a total of 1. Meanwhile, in this embodiment, the optimal weight value is recalculated every 24 hours based on historical data from the past 7 days, serving as the initial benchmark value for short-term fine-tuning.

[0104] For the long and short sequence task adaptation coefficients In this embodiment, the subtask is determined to be either a short-sequence task or a long-sequence task based on the length of its input token, and the corresponding short-sequence adaptation coefficient or long-sequence adaptation coefficient is obtained. In this embodiment, when the length of the input token of a subtask is less than 512, it is determined to be a short-sequence task; when the length of the input token is greater than or equal to 512, it is determined to be a long-sequence task; wherein, the threshold of the adaptation coefficient is consistent with the threshold setting in the subsequent parallel strategy selection.

[0105] This embodiment obtains the real-time load characteristics (including memory utilization) of each candidate computing node from the constructed dual-mode performance profile. Utilization rate of computing cores Queue backlog length and communication delay ) and historical task execution characteristics (including long and short sequence task adaptation coefficients) Substituting these values ​​into the comprehensive load scoring formula above, the adaptation score for each candidate computing node is calculated. .

[0106] In this embodiment, all candidate nodes in the candidate node set are sorted according to their calculated adaptation scores. Specifically, all candidate computing nodes are arranged in ascending order of their adaptation scores. Nodes with lower adaptation scores indicate lower current load and better adaptability to the subtask, and thus rank higher in the sorting. Based on the sorting order, and considering the subtask's execution priority, sequence length, and business type, target computing nodes are assigned to the subtask.

[0107] For high-priority subtasks, this embodiment prioritizes selecting from the nodes ranked higher and reserves resources for them; for short-sequence subtasks, it prioritizes selecting nodes with high historical short-sequence adaptation coefficients. Through this method, this embodiment determines a unique execution node for each subtask.

[0108] After the above matching, this embodiment summarizes the allocation results of all subtasks into a scheduling mapping table. Each row in the scheduling mapping table records the subtask identifier, the name of the allocated computing power node, the execution priority, the resource quota, and the scheduling threshold. This embodiment outputs the task-computing power node scheduling mapping table, specifying the execution node, priority, resource quota, and scheduling threshold for each subtask. Furthermore, when a new computing power node first connects to the computing center, its historical task window is empty, making it impossible to calculate the adaptation coefficient using the average actual / predicted ratio. In this case, if there are mature nodes with the same hardware model as the new node in the computing center, this embodiment sets the initial values ​​of the new node's short-sequence adaptation coefficient and long-sequence adaptation coefficient to the median of the current adaptation coefficient of that mature node model; if there are no mature nodes with the same hardware model in the computing center, this embodiment initializes them uniformly to... =1 represents a neutral fit without historical bias.

[0109] After a set number of subtasks are completed, this embodiment obtains the measured average execution latency of similar subtasks and compares it with the corresponding predicted latency. When the systematic deviation between the measured average execution latency and the predicted latency exceeds a preset threshold (e.g., more than 10%), this embodiment adjusts the historical average computing utilization of the corresponding computing node.

[0110] In this embodiment, a differentiated parallel inference acceleration strategy is matched for each subtask based on its feature vector. Specifically, for any subtask, this embodiment obtains the task text length (i.e., the input token length) and the estimated memory requirement of the subtask, compares the task text length with a preset first length threshold, and compares the estimated memory requirement with a preset first memory requirement threshold.

[0111] In this embodiment, the preset first length threshold is 512 tokens, and the preset first video memory requirement threshold is 8GB. When the task text length of a subtask is less than 512 tokens and the estimated video memory requirement is less than 8GB, this embodiment determines that the subtask is a short-sequence, low-computing-power task and matches a single-card inference strategy for the subtask. The single-card inference strategy refers to executing the inference task independently using a single graphics processing unit on a single computing node without splitting the model. This strategy avoids cross-node communication overhead and is suitable for short-sequence, low-computing-power subtasks such as lightweight entity queries and topology searches.

[0112] In this embodiment, when the task text length of a subtask is greater than or equal to the first length threshold (512 tokens) and less than the preset second length threshold (2048 tokens), and the estimated GPU memory requirement of the subtask is greater than or equal to the first GPU memory requirement threshold (8GB) and less than the preset second GPU memory requirement threshold (16GB), the subtask is determined to be a medium-to-long sequence task, and a tensor parallel strategy is matched for the subtask. The tensor parallel strategy refers to splitting inter-layer model computations across multiple graphics processing cards within the same target computing node for collaborative execution. This strategy can accelerate inference within a single node by utilizing the parallel computing capabilities of multiple GPUs, and is suitable for medium-to-long sequence subtasks such as power flow calculations and fault cause deduction.

[0113] In this embodiment, when the task text length of a subtask is greater than or equal to the second length threshold (2048 tokens) or the estimated video memory requirement is greater than or equal to the second video memory requirement threshold (16GB), the system determines that the subtask is a high-video-memory long text task and matches a pipeline parallel strategy for the subtask.

[0114] The pipelined parallel strategy refers to splitting the model layer by layer and distributing it across multiple target computing nodes for collaborative execution, with each node responsible for inference computation at a specific layer of the model. This strategy can distribute the peak memory requirements of large models across multiple nodes, effectively breaking through the memory limit of a single GPU.

[0115] In this embodiment, auxiliary determination is also made based on the business type tags of the subtasks: if a subtask contains keywords such as "generate," "scheme," or "plan," it is preferentially classified as a long text generation task and matched with a pipelined parallel strategy. For example, for subtask 6 (calling the power flow calculation model to generate a load transfer scheme), its task text length is approximately 2048 tokens, the estimated memory requirement is approximately 24GB, and it contains the keyword "scheme." In this embodiment, it is determined to be a high-memory long text task and matched with a pipelined parallel strategy. In addition, for subtask 4 (retrieving the knowledge base of typical overload tripping causes and generating a candidate cause list), it is a high-priority cause retrieval task. In this embodiment, in addition to matching the pipelined parallel strategy, a speculative sampling strategy is further matched. The speculative sampling strategy involves using a small model to pre-generate multiple candidate results and then having them verified by a large model to reduce the number of iteration steps.

[0116] This embodiment outputs a parallel acceleration execution scheme for subtasks. The parallel acceleration execution scheme includes parameters such as the parallel mode, batch processing threshold, model parallel splitting granularity, and number of speculative sampling candidates for each subtask.

[0117] During execution, this embodiment monitors the running status of the parallel strategy on each node in real time and dynamically adjusts the scheduling threshold. When it is detected that the batch size of a node continuously increases after enabling dynamic batch processing, causing the queue backlog to exceed the preset threshold, this embodiment actively tightens the task distribution threshold of that node, reduces the number of tasks allocated in a single round, and avoids batch backlog timeouts. If a card in a node's tensor parallel processing is at risk of memory overflow, this embodiment immediately reschedules the subtask to a backup node, reduces its parallelism, and updates the scheduling mapping table. Through the above mechanism, a two-way collaborative linkage between the parallel strategy and scheduling decision is achieved.

[0118] This embodiment obtains the business latency constraints and estimated execution time corresponding to any subtask based on the task template corresponding to that subtask, acquiring constraint data representing the task's time sensitivity requirements and expected computation time, which is used as the time dimension filtering condition for candidate node selection. For any computing node in the computing center, if the available GPU memory of that computing node is greater than or equal to the estimated GPU memory requirement corresponding to the subtask, and the sum of the queue waiting time and estimated execution time of that computing node is less than or equal to the business latency constraint, that computing node is designated as a candidate computing node for that subtask. This obtains preliminary set data of selectable nodes that simultaneously meet both GPU memory capacity and latency constraints, used to narrow down the search space for subsequent precise matching. For any candidate computing node, based on the real-time performance of that candidate computing node... Based on load characteristics and historical task execution characteristics, an adaptation score is obtained between the candidate computing node and the subtask. This score data represents the combined advantages and disadvantages of the node's current idleness and historical adaptability, and is used to achieve joint optimization of load balancing and task adaptation. By sorting all candidate computing nodes corresponding to the subtask according to the adaptation score, and assigning target computing nodes to the subtask according to the sorting order, allocation result data representing the optimal task-node mapping relationship is obtained, which is used to achieve hybrid scheduling that combines real-time minimum load priority and historical adaptation correction. Based on the feature vector of the subtask and a preset feature vector threshold, the corresponding task execution strategy is obtained from a preset task execution strategy library. This strategy selection data represents the matching relationship between the subtask and the parallel acceleration method, and is used to achieve adaptive alignment between computing mode and task characteristics.In summary, the matching process of the above scheme achieves precise and optimal matching between subtasks and computing nodes, overcoming the shortcomings of separate load balancing and task adaptation decisions in existing technologies, and improving resource utilization and task response speed. Furthermore, when the task text length of the subtask is less than a preset first length threshold and the estimated memory requirement of the subtask is less than a preset first memory requirement threshold, a single-card inference strategy is matched for the subtask. This obtains conservative execution mode data representing lightweight, short-sequence tasks that avoid cross-node communication overhead, thus eliminating unnecessary data transmission latency. Conversely, when the task text length of the subtask is greater than or equal to the first length threshold and less than a preset second length threshold... When the estimated memory requirement of a subtask is greater than or equal to a first memory requirement threshold but less than a preset second memory requirement threshold, a tensor parallel strategy is matched for the subtask. This obtains parallel execution mode data representing the multi-GPU collaborative computing capabilities of medium-sized tasks within a single node, used to achieve a balance between computational intensity and communication overhead. When the task text length of the subtask is greater than or equal to a second length threshold and the estimated memory requirement of the subtask is also greater than or equal to the second memory requirement threshold, a pipelined parallel strategy is matched for the subtask. This obtains distributed execution mode data representing the cross-node hierarchical structure of large-scale tasks, used to break through the single-GPU memory limit and achieve stable inference for large-scale models. In summary, the above scheme, through a dual-dimensional threshold determination mechanism based on task text length and estimated memory requirement, achieves adaptive and differentiated selection of a three-level parallel strategy. This overcomes the shortcomings of existing technologies where a single parallel mode cannot adapt to mixed long and short sequence scenarios, improving the inference efficiency and execution success rate of various subtasks.

[0119] In this embodiment, step 105 includes: Step 1051: For any of the subtasks, according to the serial-parallel order, the subtask is sent to the corresponding target computing node, and the target computing node is controlled to execute the subtask according to the task execution strategy to obtain the execution status of the subtask; Step 1052: When the execution status determines that the subtask has been completed, the execution result of the subtask is written to the shared cache to obtain the subtask execution result.

[0120] In this embodiment, each subtask is sequentially dispatched to its corresponding target computing node for execution according to its serial-to-parallel order and the target computing node corresponding to each subtask. Specifically, this embodiment processes each parallel execution queue sequentially according to the stripping order; for the currently processed parallel execution queue, all subtasks in that queue are simultaneously dispatched to their respective target computing nodes, thereby achieving parallel execution of subtasks at the same level.

[0121] During the subtask distribution process, this embodiment distributes the corresponding task execution strategy (including single-card inference strategy, tensor parallel strategy, or pipelined parallel strategy and their related parameters) to the target computing node. After receiving the subtask and its corresponding task execution strategy, the target computing node invokes the configured inference engine and executes the subtask according to the task execution strategy.

[0122] This embodiment introduces a distributed task state coordinator, which records the execution status of each subtask in real time. In this embodiment, the distributed task state coordinator is implemented using a distributed key-value storage system, accessible to all computing nodes in the computing center, and used to store the execution status and metadata information of each subtask. The execution status includes, but is not limited to: pending scheduling (indicating the subtask has been generated but not yet sent to the computing node), executing (indicating the subtask has been sent to the computing node and is being executed), successful (indicating the subtask has been completed and the result is correct), failed (indicating an error occurred during the execution of the subtask), and timeout (indicating the subtask execution time exceeds a preset business delay constraint).

[0123] When a subtask is dispatched to the target computing node, this embodiment updates the execution status of the subtask to "in execution" through the distributed task state coordinator. During the execution of the subtask, this embodiment can query the current execution status of the subtask in real time through the distributed task state coordinator. The execution status is stored in the distributed task state coordinator and can be read in real time.

[0124] In this embodiment, the execution status of each subtask is monitored by the distributed task status coordinator. When the distributed task status coordinator detects that the execution status of a subtask has changed to success, it determines that the subtask has been completed and triggers subsequent processing. Specifically, after a target computing node completes the execution of a subtask, the target computing node writes the execution result of the subtask to a shared cache and updates the execution status of the subtask to success. The shared cache is a distributed shared cache system (such as Redis or a distributed memory cache), which can be accessed by all computing power nodes in the computing center.

[0125] After writing the execution result to the shared cache, this embodiment triggers a status update for subsequent subtasks that depend on the execution result based on the data dependencies between subtasks. Specifically, this embodiment queries the directed acyclic graph of task dependencies to identify all subsequent subtasks that directly depend on the current subtask. For each dependent subsequent subtask, this embodiment checks whether all its preceding dependencies have been completed (i.e., whether the execution results of all dependent preceding subtasks have been written to the shared cache). If all the preceding dependencies of the subsequent subtask are satisfied, this embodiment updates the execution status of the subsequent subtask to pending scheduling, enabling it to enter the subsequent scheduling and distribution process.

[0126] Furthermore, this embodiment also monitors the abnormal execution of subtasks through the distributed task state coordinator. When the distributed task state coordinator detects that the execution status of a subtask has changed to failure or timeout, it automatically triggers a rescheduling mechanism. Specifically, in this embodiment, a candidate computing node is reselected from the set of candidate computing nodes (for example, a computing node with the second-best adaptation score is selected), and the subtask is reassigned to the candidate computing node for re-execution. If the subtask still fails after rescheduling, it is marked as failed, and appropriate processing is performed in the final result aggregation stage.

[0127] In this embodiment, after a set number (e.g., 100) of subtasks are completed, the measured average execution latency of similar subtasks is obtained, and the measured average execution latency is compared with the corresponding predicted execution latency. When the comparison result shows that a systematic deviation exceeds a preset threshold (e.g., the deviation between the measured average execution latency and the predicted latency exceeds 10%), this embodiment corrects the historical average computing utilization parameter of the corresponding target computing node. Specifically, this embodiment adjusts the historical average computing utilization of the node in reverse according to the ratio of the measured average execution latency to the predicted latency, so that the subsequent predicted latency is closer to the actual execution latency.

[0128] This embodiment distributes any subtask to the corresponding target computing node according to a serial-parallel order, and controls the target computing node to execute the subtask according to the task execution strategy. This obtains the execution status of the subtask, acquiring real-time status data representing the current running stage and health status of the subtask, enabling process observability and anomaly detection in distributed inference. After the subtask is completed based on its execution status, its execution result is written to a shared cache to obtain the subtask execution result. This provides structured intermediate result data that can be directly read by subsequent dependent subtasks, enabling result transfer across subtasks and avoiding redundant computation. In summary, this scheme combines the state tracking mechanism of the distributed task state coordinator with the result reuse mechanism of the shared cache, enabling the system to perceive the execution status of each subtask in real time and store the execution results in a structured manner for direct reading by dependent tasks. This overcomes the shortcomings of existing technologies that lack dynamic coordination and cache reuse mechanisms, improving the reliability and execution efficiency of multi-node collaborative inference.

[0129] In this embodiment, step 106 includes: Step 1061: Obtain the execution results of all the subtasks corresponding to the target task, and perform logical consistency verification on the execution results of each subtask according to the pre-built domain rules to obtain the verification result corresponding to each subtask execution result; Step 1062: Select several qualified subtask execution results from all the subtask execution results based on the verification results, and obtain the semantic structure of the target task; Step 1063: Assemble all the execution results of the qualified subtasks according to the semantic structure to obtain the execution result of the target task.

[0130] In this embodiment, after all subtasks have been executed, the execution results of all subtasks corresponding to the target task are retrieved from the shared cache. These subtask execution results include the execution results of each atomic subtask obtained from the decomposition, such as: fault line information and protection action signals output by subtask 1, power flow data and weather conditions output by subtask 2, etc.

[0131] This embodiment acquires pre-built domain rules, which are logical consistency verification rules for the power dispatching domain. These domain rules are pre-stored in a rule base and contain multiple rules for verifying the logical consistency between the execution results of each subtask. Based on these domain rules, this embodiment performs logical consistency verification on the execution results of each subtask, obtaining a verification result corresponding to each subtask's execution result. The verification result includes two states: verification passed and verification failed.

[0132] Specifically, in this embodiment, the logical consistency check includes checks in the following multiple dimensions: (1) Matching verification of fault cause and load loss: This embodiment verifies the logical consistency between fault cause and load loss. For example, if the fault cause is overload tripping and the fault isolation results in some loads being unable to be powered, then the load loss should be greater than 0. If the candidate cause list output by subtask 4 includes overload tripping, but the load loss output by subtask 5 is 0, then there is a logical contradiction between the two, and the verification result is that it fails.

[0133] (2) Verification of the topology existence of tie switches in the power transfer scheme: This embodiment verifies whether the tie switches in the power transfer scheme actually exist in the power grid topology and are in an operable state. Specifically, this embodiment obtains the load transfer scheme output by subtask 6 and extracts the identifiers of the tie switches that need to be closed from the load transfer scheme; this embodiment obtains the power grid topology structure output by subtask 3 and queries whether the tie switch identifiers exist in the power grid topology structure; if the tie switch identifiers do not exist in the power grid topology structure, the verification result is a failure.

[0134] (3) Verification of other power dispatch rules: This embodiment also verifies other rules in the pre-built domain rule library, such as whether the power flow calculation is converged and whether the load loss value is within a reasonable range.

[0135] This embodiment performs the aforementioned verification on the execution result of each subtask, obtaining a verification result (pass or fail) for each subtask execution result. Based on the verification results, qualified subtask execution results that pass the verification are selected from all the subtask execution results. Specifically, for subtask execution results that pass the verification, this embodiment marks them as qualified subtask execution results for subsequent assembly. For subtask execution results that fail the verification, this embodiment triggers partial recalculation or marks them as requiring manual review. Partial recalculation means that the system re-executes the subtask that failed the verification, specifically including: re-distributing the subtask to the corresponding target computing node for execution, or rescheduling execution according to the alternative nodes in the scheduling mapping table. If the subtask execution result still fails the verification after partial recalculation, this embodiment marks the subtask execution result as requiring manual review, and notes this conclusion in the final output task execution result.

[0136] Simultaneously, this embodiment obtains the semantic structure of the target task. The semantic structure of the target task refers to the logical organization and expression order contained in the original target task (natural language text) input by the user. In this embodiment, the semantic structure is a logical chain of analyzing the cause of the fault, assessing the load loss, and generating a load transfer plan. This embodiment extracts the semantic structure of the target task from the semantic parsing results. The semantic structure reflects the user's expected answer organization order, that is, first explaining the cause of the fault, then assessing the load loss, and finally providing a load transfer plan.

[0137] Based on the semantic structure of the target task, this embodiment assembles the execution results of all qualified subtasks according to the semantic structure to generate a complete and logically coherent task execution result. Specifically, this embodiment determines the assembly order of the execution results of each qualified subtask according to the semantic structure. In this embodiment, the semantic structure is a logical chain of analyzing fault causes, assessing load loss, and generating load transfer schemes. Therefore, the candidate cause list output by subtask 4 (i.e., fault cause analysis results) is first used as the first part, the load loss area and load loss amount output by subtask 5 (i.e., load loss assessment results) are then used as the second part, and the load transfer scheme output by subtask 6 (i.e., load transfer scheme generation results) is finally used as the third part. The above three parts are assembled in sequence to obtain a complete task execution result.

[0138] During the assembly process, this embodiment also inputs the aggregated structured results into a large language model, which then generates a complete answer text in natural language. Specifically, this embodiment inputs the assembled structured data (including key conclusions such as fault causes, load loss, and transfer schemes) into the large language model and sets corresponding prompt templates to guide the large language model in generating a user-friendly, readable natural language response. Furthermore, this embodiment generates a confidence score for each key conclusion in the task execution results and generates a traceable chain of evidence for each key conclusion. The generation method of the confidence score varies depending on the type of conclusion source: For conclusions generated by large models, this embodiment calculates the confidence score based on the average probability per token during generation and the consistency of candidates in Beam search; for conclusions matching knowledge base rules, this embodiment uses the static baseline confidence score of the rules, combined with historical verification frequency and the degree of matching in this instance for dynamic correction; for numerical calculation conclusions (such as power flow calculation and load shedding calculation), this embodiment calculates the confidence score based on computational convergence, the timeliness of input data, and residual analysis; the basis chain includes the source type (such as knowledge base rules, large model generation, numerical calculation, SCADA data), source identifier (such as rule ID, model version, database table name), extraction location, and original data summary. When conclusions come from multiple sources, they are displayed in a list format and sorted by contribution.

[0139] Finally, this embodiment correlates and outputs the task execution result (i.e., the complete answer text), the execution results of each subtask (i.e., the intermediate results displayed step by step), the confidence score and the basis chain corresponding to each key conclusion. The final output also includes the overall solution time and dynamic path adjustment records (such as rescheduling records, alternative node switching records, parallelism adjustment records, etc.), forming a complete, traceable, and interpretable reasoning result.

[0140] In this embodiment, the source of evidence and confidence level are displayed next to each key conclusion in the final output task execution result in the form of a superscript or a floating window. For example, for the key conclusion that the cause of the failure is a lightning strike, this embodiment outputs that the cause of the failure is a lightning strike, and displays the subtask 4 hitting the knowledge base rule with a confidence level of 0.92 in the lightning strike superscript.

[0141] This embodiment obtains the execution results of all subtasks corresponding to the target task, performs logical consistency verification on each subtask execution result according to pre-built domain rules, obtains the verification result corresponding to each subtask execution result, and acquires verification label data representing whether there are logical contradictions between the subtask results to ensure the internal logical consistency of the final answer. Based on the verification results, several qualified subtask execution results are selected from all subtask execution results, and the semantic structure of the target task is obtained. Combined data representing the set of credible intermediate results that have passed verification and the original question organization framework is obtained to ensure that the data source used for splicing is reliable and structurally matched. By splicing and assembling all qualified subtask execution results according to the semantic structure, the task execution result of the target task is obtained, acquiring the final answer data representing logical consistency and complete structure, used to achieve reliable reasoning result delivery to users. In summary, the above scheme, through consistency verification and semantic structure-guided splicing techniques, performs quality screening and orderly organization of scattered subtask results, overcomes the deficiency of existing technologies in lacking result verification mechanisms, and improves the accuracy, logical consistency, and credibility of the final output.

[0142] On the other hand, such as Figure 2 As shown, based on the above method embodiments, corresponding device embodiments are provided; one embodiment of the present invention provides a task execution system based on computing power scheduling, including a task splitting module 201, a task dependency module 202, a task feature module 203, a node matching module 204, a subtask execution module 205, and an execution summary module 206.

[0143] The task splitting module 201 is used to perform semantic parsing on the acquired target task in order to split the target task into several sub-tasks; The task dependency module 202 is used to obtain the data dependency relationship and control dependency relationship between each of the subtasks, so as to construct the task feature list corresponding to the target task and the serial-parallel order between each of the subtasks; The task feature module 203 is used to acquire the running data and static hardware data of each computing node in the computing center in real time, so as to construct the real-time load features and historical task execution features corresponding to each computing node. The node matching module 204 is used to obtain the task execution strategy corresponding to each subtask and match the target computing node corresponding to each subtask from the computing center according to the task feature list, the real-time load features and the historical task execution features. The subtask execution module 205 is used to control the target computing node to execute the subtasks according to the task execution strategy according to the serial-parallel order, so as to obtain the subtask execution result of each subtask; The execution summary module 206 is used to obtain the execution results of all the sub-tasks corresponding to the target task, and to splice and assemble the execution results of each sub-task to obtain the task execution result of the target task.

[0144] It is understood that the above-described device embodiments correspond to the method embodiments of the present invention, and can implement a task execution method based on computing power scheduling provided by any of the above-described method embodiments of the present invention.

[0145] It should be noted that the device embodiments described above are merely illustrative, and some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the device embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can specifically be implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0146] Based on the above embodiment of a task execution method based on computing power scheduling, another embodiment of the present invention provides a terminal device, which includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements a task execution method based on computing power scheduling according to any embodiment of the present invention.

[0147] For example, in this embodiment, the computer program can be divided into one or more modules, which are stored in the memory and executed by the processor to complete the present invention. The one or more modules may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the terminal device.

[0148] The terminal device can be a desktop computer, laptop, handheld computer, or cloud server, etc. The terminal device may include, but is not limited to, a processor and memory. The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of the terminal device, connecting all parts of the terminal device via various interfaces and lines.

[0149] Based on the above-described method embodiments, another embodiment of the present invention provides a computer-readable storage medium including a stored computer program, wherein, when the computer program is running, it controls the device where the computer-readable storage medium is located to execute a task execution method based on computing power scheduling as described in any of the above-described method embodiments of the present invention.

[0150] The modules / units integrated in the device / terminal equipment, if implemented as software functional units and sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0151] This invention provides a task execution method, system, medium, and device based on computing power scheduling. Through the collaboration of a large language model and a rule engine in the power dispatching domain, it achieves entity recognition, task type determination, priority allocation, and atomic-level decomposition of complex problems. This generates a structured task list containing quantitative features such as computing power requirements, memory consumption, and latency constraints, laying a precise foundation for subsequent scheduling and acceleration. Simultaneously, it collects multi-dimensional indicators such as memory usage, computing power load, network communication, and queue backlog in real time, constructing a dual-mode performance profile and a comprehensive load scoring model. This enables the system to dynamically perceive the status of computing power resources, avoiding resource fragmentation and uneven load caused by static scheduling. Furthermore, it employs a hybrid scheduling strategy combining real-time minimum load priority with heuristic weight correction, introducing a long-short sequence task adaptation coefficient. Under the premise of satisfying memory and latency constraints, it achieves precise optimal mapping between subtasks and heterogeneous computing power nodes, significantly improving resource utilization and task response speed. Secondly, based on the characteristics of subtasks (short sequences and lightweight, medium-to-long sequences, and long texts with high GPU memory) and node hardware topology, adaptive matching strategies such as single-card independent inference, tensor parallelism, pipelined parallelism, and speculative sampling are implemented. The scheduling threshold and parallelism are dynamically adjusted in real-time to monitor the running status, avoiding communication overhead and GPU memory overflow risks, thus maximizing inference efficiency. Next, by constructing a directed acyclic graph of subtask dependencies and using topological sorting to generate the optimal parallel / serial execution queue, a distributed task state coordinator is used to achieve real-time state tracking, dependency triggering, failure rescheduling, and alternative node switching, ensuring the continuity, fault tolerance, and low latency of complex inference processes. Finally, the intermediate results of each subtask are subjected to domain rule consistency verification, structured integration, and confidence labeling to generate a complete answer containing the source of inference and dynamic adjustment records, significantly improving the accuracy, logical consistency, and credibility of the final output, meeting the needs of high real-time and high-reliability business scenarios.

[0152] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A task execution method based on computing power scheduling, characterized in that, include: The acquired target task is semantically parsed to break it down into several subtasks; Obtain the data dependencies and control dependencies between each of the subtasks to construct a list of task features corresponding to the target task and the serial-parallel order between each of the subtasks; Real-time acquisition of operational data and static hardware data of each computing node in the computing center is used to construct real-time load characteristics and historical task execution characteristics corresponding to each computing node. Based on the task feature list, the real-time load features, and the historical task execution features, obtain the task execution strategy corresponding to each sub-task and match the target computing node corresponding to each sub-task from the computing center; According to the serial-parallel sequential control, the target computing node executes the subtasks according to the task execution strategy to obtain the subtask execution result of each subtask; Obtain the execution results of all the subtasks corresponding to the target task, and then assemble the execution results of each subtask to obtain the task execution result of the target task.

2. The task execution method based on computing power scheduling according to claim 1, characterized in that, The semantic parsing of the acquired target task to break it down into several sub-tasks includes: The acquired target task is labeled and identified to obtain several key entities in the target task; The target task is identified and its priority is determined to obtain several task types corresponding to the target task and the execution priority of each task type. The length of the input text, the expected output length, the computing power requirement, and the video memory requirement of the target task are obtained as key information of the target task. Based on the key entity, the task type, the execution priority, and the key information, several task templates corresponding to the target task are obtained from a pre-built task template library, so as to split the target task into several sub-tasks according to the task templates.

3. The task execution method based on computing power scheduling according to claim 2, characterized in that, The step of obtaining the data dependencies and control dependencies between the subtasks to construct the task feature list corresponding to the target task and the serial-parallel order between the subtasks includes: For any given subtask, obtain the set of input entities and the set of output entities corresponding to that subtask from all the key entities corresponding to the target task; For any two subtasks, if the output entity set of the first subtask and the input entity set of the second subtask intersect, the second subtask is determined to depend on the first subtask, which is used as a data dependency relationship between the first subtask and the second subtask. For any two subtasks, the first subtask and the second subtask are matched from a pre-built domain business rule base according to the task type, input entity set, and output entity set of the first subtask and the task type, input entity set, and output entity set of the second subtask. Based on the data dependencies and control dependencies, construct a list of task features corresponding to the target task and the serial-parallel order among the subtasks.

4. A task execution method based on computing power scheduling according to any one of claims 2 to 3, characterized in that, The step of constructing the task feature list corresponding to the target task and the serial-parallel order between each subtask based on the data dependency relationship and the control dependency relationship includes: For any of the subtasks, based on the input text length, expected output length, computing power requirement, and video memory requirement of the target task and the task template corresponding to the subtask, obtain the task text length, expected output length, estimated computing power requirement, and estimated video memory requirement of the subtask. The task text length, expected output length, estimated power requirement, estimated memory requirement, task type, and execution priority corresponding to the subtask are used as the feature vector of the subtask. Based on the data and control dependencies between the subtasks, construct a directed acyclic graph of task dependencies corresponding to the target task; Based on the topological sorting of the layer-by-layer peeling, obtain several parallel execution queues and the peeling order of each parallel execution queue from the directed acyclic graph of the dependencies; wherein, each parallel execution queue includes several parallel execution subtasks; The serial execution order among different parallel execution queues in all the parallel execution queues is determined according to the stripping order; Based on the directed acyclic graph of task dependencies and the feature vectors corresponding to each of the subtasks, a list of task features corresponding to the target task is generated.

5. The task execution method based on computing power scheduling according to claim 1, characterized in that, The real-time acquisition of operational data and static hardware data of each computing node in the computing center to construct real-time load characteristics and historical task execution characteristics corresponding to each computing node includes: For any computing node, obtain its multi-dimensional operational metrics and static hardware data in real time. Based on the multi-dimensional operational metrics, generate the real-time load characteristics corresponding to the computing power node; For any subtask of a task type, obtain the actual execution delay and predicted delay of the computing node executing the subtask of that task type within a preset historical time period; The ratio of the actual execution delay to the predicted delay is obtained and used as a historical task execution characteristic of the computing node executing subtasks of this task type.

6. The task execution method based on computing power scheduling according to claim 5, characterized in that, The step of obtaining the task execution strategy corresponding to each subtask and matching the target computing node corresponding to each subtask from the computing center based on the task feature list, the real-time load characteristics, and the historical task execution characteristics includes: For any of the subtasks, obtain the business delay constraints and estimated execution time corresponding to the subtask based on the task template corresponding to the subtask. For any computing node in the computing center, if the available video memory of the computing node is greater than or equal to the estimated video memory requirement corresponding to the subtask and the sum of the queue waiting time of the computing node and the estimated execution time is less than or equal to the business delay constraint, the computing node shall be regarded as the candidate computing node corresponding to the subtask. For any candidate computing node, an adaptation score between the candidate computing node and the subtask is obtained based on the real-time load characteristics and historical task execution characteristics of the candidate computing node. Based on the adaptation score, all candidate computing nodes corresponding to the subtask are sorted, and a target computing node is assigned to the subtask according to the sorting order. Based on the feature vector of the subtask and the preset feature vector threshold, the corresponding task execution strategy is obtained from the preset task execution strategy library.

7. A task execution method based on computing power scheduling according to claim 6, characterized in that, The step of obtaining the task execution strategy corresponding to the subtask from a preset task execution strategy library based on the feature vector of the subtask and a preset feature vector threshold includes: When the task text length of the subtask is less than the preset first length threshold and the estimated video memory requirement of the subtask is less than the preset first video memory requirement threshold, a single-card inference strategy is matched for the subtask. When the task text length of the subtask is greater than or equal to the first length threshold and less than the preset second length threshold, and the estimated memory requirement of the subtask is greater than or equal to the first memory requirement threshold and less than the preset second memory requirement threshold, a tensor parallel strategy is matched for the subtask. When the task text length of the subtask is greater than or equal to the second length threshold and the estimated memory requirement of the subtask is greater than or equal to the second memory requirement threshold, a pipelined parallel strategy is matched for the subtask.

8. The task execution method based on computing power scheduling according to claim 1, characterized in that, The step of controlling the target computing node to execute the subtasks according to the task execution strategy based on the serial-parallel order, and obtaining the subtask execution result of each subtask, includes: For any of the subtasks, according to the serial-parallel order, the subtask is sent to the corresponding target computing node, and the target computing node is controlled to execute the subtask according to the task execution strategy to obtain the execution status of the subtask; Once the execution status indicates that the subtask has been completed, the execution result of the subtask is written to the shared cache to obtain the subtask execution result.

9. A task execution method based on computing power scheduling according to claim 8, characterized in that, The step of obtaining the execution results of all the subtasks corresponding to the target task, and then assembling the execution results of each subtask to obtain the task execution result of the target task, includes: Obtain the execution results of all the subtasks corresponding to the target task, and perform logical consistency verification on the execution results of each subtask according to the pre-built domain rules to obtain the verification result corresponding to each execution result of the subtask. Based on the verification results, select several qualified subtask execution results from all the subtask execution results, and obtain the semantic structure of the target task; The execution results of all qualified subtasks are concatenated and assembled according to the semantic structure to obtain the execution result of the target task.

10. A task execution system based on computing power scheduling, characterized in that, It includes a task splitting module, a task dependency module, a task feature module, a node matching module, a subtask execution module, and an execution summary module; The task splitting module is used to perform semantic parsing on the acquired target task in order to split the target task into several sub-tasks; The task dependency module is used to obtain the data dependency relationship and control dependency relationship between each of the subtasks, so as to construct the task feature list corresponding to the target task and the serial-parallel order between each of the subtasks; The task feature module is used to acquire the running data and static hardware data of each computing node in the computing center in real time, so as to construct the real-time load features and historical task execution features corresponding to each computing node. The node matching module is used to obtain the task execution strategy corresponding to each subtask and match the target computing node corresponding to each subtask from the computing center based on the task feature list, the real-time load features and the historical task execution features. The subtask execution module is used to control the target computing node to execute the subtasks according to the task execution strategy based on the serial-parallel order, so as to obtain the subtask execution result of each subtask; The execution summary module is used to obtain the execution results of all the sub-tasks corresponding to the target task, and to splice and assemble the execution results of each sub-task to obtain the task execution result of the target task.

Images