Heterogeneous resource scheduling method and apparatus, computing device, and storage medium

Abstract

This application relates to the field of resource allocation technology, and discloses a heterogeneous resource scheduling method, a heterogeneous resource scheduling device, a computing device, and a computer-readable storage medium. Applied to a computing device, the computing device includes various computing resources. The method includes: parsing the task to be allocated, generating multiple subtasks and task attribute identifiers corresponding to each subtask; determining the execution order of the multiple subtasks according to priority; processing each subtask according to the execution order; calculating a cost function based on the task attribute identifiers and the target performance model of each computing resource; scheduling the subtasks to the computing resource with the minimum cost function; and simultaneously obtaining multiple target performance indicators fed back by the computing resources and updating the target performance model. Through the above method, the collaborative execution of heterogeneous resources is achieved, and it can adapt to dynamic changes in hardware performance, ensuring that all subtasks in the task to be allocated can be executed efficiently.

Description

Technical Field

[0001] This application relates to the field of resource allocation technology, specifically to a heterogeneous resource scheduling method, a heterogeneous resource scheduling device, a computing device, and a storage medium. Background Technology

[0002] Edge servers, industrial control computers and other computing devices typically contain a variety of computing resources such as a central processing unit (CPU), a graphics processing unit (GPU), and a neural network processing unit (NPU). Therefore, when a task arrives at the computing device, the device needs to allocate the task to the corresponding computing resources for execution according to a specific scheduling mechanism.

[0003] Currently, computing devices typically employ two types of scheduling mechanisms. The first is a static mapping strategy, which binds specific tasks to fixed computing resources during system deployment. The second is a general-purpose operating system scheduler, which treats all tasks as ordinary processes and schedules them according to time slices or priorities. Both of these scheduling mechanisms lack the ability to dynamically match tasks with computing power, making it impossible to achieve efficient and coordinated utilization of heterogeneous resources. This results in various computing resources failing to leverage their performance advantages, especially in industrial scenarios where computationally intensive tasks and latency-sensitive tasks coexist, failing to meet the high requirements for real-time performance, stability, and resource balance. Summary of the Invention

[0004] In view of the above problems, embodiments of this application provide a heterogeneous resource scheduling method, a heterogeneous resource scheduling device, a computing device, and a computer-readable storage medium to solve the problem that computing devices in the prior art cannot achieve efficient and coordinated utilization of heterogeneous resources, resulting in multiple computing resources being unable to exert their performance advantages.

[0005] According to one aspect of the embodiments of this application, a heterogeneous resource scheduling method is provided, applied to a computing device, the computing device including multiple computing resources, the method comprising: acquiring tasks to be allocated; parsing the tasks to be allocated to generate multiple subtasks and task attribute identifiers corresponding to each subtask; calculating the priority of each subtask according to the task attribute identifiers corresponding to each subtask; determining the execution order of the multiple subtasks according to the priority, and performing the following steps on each subtask according to the execution order: acquiring the target performance model corresponding to each computing resource according to the task attribute identifiers; calculating the cost function corresponding to each computing resource according to the task attribute identifiers and the target performance model; scheduling the subtask to the computing resource with the minimum cost function; acquiring multiple target performance indicators fed back when the computing resource executes the subtask, and updating the target performance model corresponding to the computing resource according to the target performance indicators.

[0006] In one optional approach, the task to be assigned is parsed to generate multiple subtasks and corresponding task attribute identifiers for each subtask. Specifically, this includes: decomposing the task to be assigned into multiple subtasks based on its structure, and determining the task type for each subtask; if the task type is a computationally intensive task, the model parsing graph of the subtask is parsed, model features are extracted, and a task attribute identifier corresponding to the subtask is generated based on the task type and model features, where the task attribute identifier is a computationally intensive task identifier; if the task type is a latency-sensitive task, the code of the subtask is analyzed, code features are identified, and a task attribute identifier corresponding to the subtask is generated based on the task type and code features, where the task attribute identifier is a latency-sensitive task identifier.

[0007] In one optional approach, the priority of each subtask is calculated based on the task attribute identifier corresponding to each subtask. Specifically, this includes: if the task attribute identifier is a computationally intensive task identifier, then the throughput requirement of the subtask and the resource load of the computing resources are obtained from the task attribute identifier corresponding to the subtask, and the priority of the subtask is calculated based on the throughput requirement and the resource load; if the task attribute identifier is a latency-sensitive task identifier, then the time constraint is obtained from the task attribute identifier corresponding to the subtask, and the priority of the subtask is calculated based on the time constraint.

[0008] In one optional approach, the task attribute identifier includes at least one task attribute, and the performance model corresponding to each computing resource includes multiple performance indicators, each of which is assigned a corresponding first weight. Based on the task attribute identifier and the target performance model, the cost function corresponding to each computing resource is calculated, specifically including: obtaining the first weights corresponding to various performance indicators; and calculating the cost function corresponding to each computing resource based on the task attribute, the first weights, and the performance indicators.

[0009] In an optional embodiment, the method further includes: periodically executing the following steps at preset time intervals: collecting the current performance indicators corresponding to each computing resource; obtaining the number of tasks completed on time and the number of tasks not completed within the preset time interval for each computing resource; calculating the reward corresponding to each computing resource based on the current performance indicators, the number of tasks completed on time, and the number of tasks not completed within the time interval for each computing resource; and updating the first weight corresponding to each performance indicator in the performance model corresponding to each computing resource based on the reward corresponding to each computing resource.

[0010] In one alternative approach, the target performance model includes multiple performance metrics, each corresponding one-to-one with a target performance metric. Updating the target performance model corresponding to the computing resources based on the target performance metrics specifically includes: for each performance metric in the target performance model, performing the following steps: obtaining a preset learning rate, and calculating the second weight corresponding to the target performance metric and the third weight corresponding to the performance metric in the performance model based on the learning rate; calculating a new performance metric based on the target performance metric, the second weight, the performance metric in the performance model, and the third weight; and replacing the performance metric in the target performance model with the new performance metric.

[0011] In one optional approach, a default computing resource is set among multiple computing resources; the target performance model corresponding to each computing resource is obtained based on the task attribute identifier, specifically including: determining the task type of the subtask based on the task attribute identifier; obtaining the performance model corresponding to the task type from the performance model set on each computing resource to obtain the target performance model corresponding to each computing resource, wherein the performance model set includes performance models corresponding to multiple task types; before scheduling the subtask to the computing resource with the minimum cost function, the method further includes: if the target performance models corresponding to each computing resource are all empty, then the subtask is submitted to the default computing resource.

[0012] According to another aspect of the embodiments of this application, a heterogeneous resource scheduling device is provided. The device includes: a first acquisition module, used to acquire tasks to be assigned; a parsing module, used to parse the tasks to be assigned and generate multiple subtasks and task attribute identifiers corresponding to each subtask; a first calculation module, used to calculate the priority of each subtask according to the task attribute identifiers corresponding to each subtask; an execution order determination module, used to determine the execution order of the multiple subtasks according to the priority; a second acquisition module, used to acquire the target performance model corresponding to each computing resource according to the task attribute identifiers; a second calculation module, used to calculate the cost function corresponding to each computing resource according to the task attribute identifiers and the target performance model; a submission module, used to schedule the subtasks to the computing resource with the minimum cost function; and an update module, used to acquire multiple target performance indicators fed back when the computing resource executes the subtasks, and update the target performance model corresponding to the computing resource according to the target performance indicators.

[0013] According to another aspect of the embodiments of this application, a computing device is provided, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the heterogeneous resource scheduling method described in any of the preceding claims.

[0014] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the heterogeneous resource scheduling method described in any of the preceding claims.

[0015] In this embodiment, the computing device can decompose the task to be assigned into multiple subtasks, calculate the priority of each subtask in real time, determine the execution order of the subtasks based on their priorities, and schedule multiple computing resources on the computing device according to the execution order. This avoids binding the entire task to a single technical resource and enables collaborative execution of heterogeneous resources. Furthermore, the computing device can calculate the cost of each computing resource executing a subtask based on the task attribute identifier of the subtask and the performance model of the computing resources. This allows for scheduling the subtask to the computing resource with the lowest cost, ensuring efficient execution of each subtask. Simultaneously, the performance indicators fed back from the execution of subtasks by the computing resources are updated in real time to adapt to dynamic changes in hardware performance. This more accurately predicts the cost of executing a subtask on different resources, helping to make more reasonable scheduling decisions and ensuring efficient execution of subtasks while meeting their time constraints and resource requirements.

[0016] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0017] The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating the heterogeneous resource scheduling method provided in an embodiment of this application is shown. Figure 2 A flowchart illustrating a heterogeneous resource scheduling method according to another embodiment of this application is shown; Figure 3 A schematic diagram of the heterogeneous resource scheduling device provided in an embodiment of this application is shown; Figure 4 A schematic diagram of the structure of a computing device provided in an embodiment of this application is shown. Detailed Implementation

[0018] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. Although exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein.

[0019] Industrial scenarios involve a wide variety of tasks, including latency-sensitive tasks such as control logic and real-time feedback, as well as computationally intensive tasks such as AI inference and image processing. Different tasks have different computational characteristics and performance requirements. To meet the needs of these diverse computing tasks and achieve efficient, reliable, and flexible system performance, edge servers, industrial control computers, and other computing devices typically integrate various computing resources such as CPUs, GPUs, and NPUs. CPUs excel at handling complex instruction streams and serial tasks, offering high flexibility and versatility; GPUs possess a large number of parallel computing units, making them ideal for handling large-scale parallel computing tasks such as image processing and deep learning inference; and NPUs can efficiently execute deep learning model inference tasks, typically with low power consumption.

[0020] Existing computing devices typically employ static mapping strategies or general-purpose operating system schedulers to achieve coordinated scheduling among various computing resources. Static mapping strategies bind specific tasks to fixed hardware during system deployment; for example, all computationally intensive tasks are fixedly assigned to the NPU, while latency-sensitive tasks are fixedly assigned to the CPU. This approach lacks real-time awareness and can easily lead to a situation where "the busy get busier, and the idle get idler." For instance, when the NPU is idle, the CPU may be inefficiently executing lightweight AI models, or when the GPU is fully loaded, image tasks may still be incorrectly scheduled to the GPU.

[0021] General-purpose operating system schedulers treat all tasks as ordinary processes and schedule them according to time slices or priorities, without distinguishing between the computational characteristics of tasks (such as parallelism and latency sensitivity) and their suitability for computing resources. For example, latency-sensitive tasks have hard real-time deadlines. When computationally intensive tasks suddenly experience high loads, the general-purpose operating system scheduler may schedule computationally intensive tasks to the CPU, causing latency-sensitive tasks to time out due to computationally intensive tasks preempting CPU resources.

[0022] In particular, industrial scenarios often involve hybrid tasks, which are complex tasks comprising at least one control subtask and one AI inference subtask, such as industrial vision servoing tasks (typically including PID control and object detection tasks). These tasks are often scheduled as a single computing resource. If the hybrid task is scheduled to the CPU based on the control subtask, the computationally intensive task within the hybrid task will consume most of the CPU's resources, while the CPU's efficiency in processing the AI ​​inference subtask will be low. This will limit the CPU's other general-purpose computing capabilities, resulting in resource waste, and latency-sensitive tasks will be more prone to timeouts. Conversely, if the hybrid task is scheduled to the GPU or NPU based on the AI ​​inference subtask, the latency-sensitive task within the hybrid task will consume resources on the NPU or GPU, preventing the full utilization of the NPU or GPU's AI computing power and resulting in resource waste.

[0023] In summary, existing heterogeneous resource scheduling methods are unable to fully leverage the performance advantages of various computing resources. Especially in industrial scenarios, existing heterogeneous resource scheduling methods lack the ability to dynamically match "tasks with computing power," making it impossible to achieve efficient and collaborative utilization of heterogeneous resources, and failing to meet the high requirements of real-time performance, stability, and resource balance.

[0024] Based on this, to ensure the efficient collaborative execution of high real-time tasks and computationally intensive tasks in industrial scenarios, this application provides a heterogeneous resource scheduling method. After acquiring a task to be assigned, the computing device decomposes the task into multiple subtasks to avoid binding the entire task to a single computing resource, thus achieving collaborative execution of heterogeneous resources. Then, the task to be assigned is parsed to generate multiple subtasks and their corresponding task attribute identifiers. The priority of each subtask is dynamically calculated based on these identifiers to determine the execution order of the subtasks, thereby improving the on-time completion rate of the subtasks.

[0025] Next, based on the task attribute identifiers of the subtasks and the performance model of the computing resources, the cost of executing the subtasks on each computing resource is calculated. This allows for the scheduling of subtasks to the computing resources with the lowest cost, ensuring that each subtask can be executed efficiently. Finally, by obtaining the performance metrics fed back by the computing resources when executing subtasks, the performance model of the computing resources is updated in real time based on these metrics to adapt to dynamic changes in hardware performance (such as temperature-controlled frequency reduction). This allows for a more accurate prediction of the cost of executing subtasks on different resources, helping to make more reasonable scheduling decisions and ensuring that subtasks can be executed efficiently while meeting their time constraints and resource requirements.

[0026] According to a first aspect of the embodiments of this application, a heterogeneous resource scheduling method is provided. The method is executed by a computing device, specifically an edge server, an industrial control computer, or other computing device. The computing device includes various computing resources, such as CPU, NPU, GPU, etc.

[0027] Each type of computing resource has different structural characteristics and operational advantages. For example, CPUs have strong instruction scheduling capabilities and are suitable for executing decision-making logic and flow control tasks; GPUs naturally support parallel processing and are suitable for handling data-intensive tasks such as image arrays and matrix operations, such as edge detection, convolutional smoothing, color conversion, and visual inspection; while AI accelerators such as NPUs / TPUs are usually optimized for specific deep learning operators and are particularly suitable for running lightweight neural network models, such as semantic understanding models and lightweight LSTMs.

[0028] This computing device can adopt a top-down layered architecture design, consisting of four main parts: the application layer, the scheduling layer, the computing power abstraction layer, and the hardware execution layer. The topmost application layer is responsible for initiating specific requests for computationally intensive tasks (such as YOLOv5s, YOLOv5n, ResNet-50, etc.) or latency-sensitive tasks (such as PID control tasks, communication processing tasks, state observation tasks, etc.).

[0029] The middle scheduling layer is the core decision-making module, capable of dynamically selecting appropriate computing resources based on the system's current load, temperature, and energy consumption, combined with the task type. As an example, the scheduling layer can include three sub-modules: a task classifier, a resource monitor, and a scheduling policy executor. The task classifier is used to identify task types (computation-intensive / latency-sensitive) and extract task metadata (deadlines, periodicity, model structure, etc.). The resource monitor is used to collect real-time data on the load rate, temperature, power consumption, queue depth, and memory / GPU usage of computing resources such as CPU, GPU, and NPU. The scheduling policy executor is used to select appropriate computing resources based on the characteristics of the tasks to be assigned and the status of the computing resources.

[0030] Because the programming interfaces for different hypothetical resources vary significantly (e.g., CPUs use function calls, GPUs rely on CUDA / OpenCL, and NPUs typically use vendor SDKs), directly coupling upper-layer system logic with these interfaces can easily lead to difficulties in platform portability, complex code maintenance, and poor system consistency. Therefore, below the scheduling layer, a unified heterogeneous interface encapsulation layer shields the underlying differences between CUDA, OpenCL, TensorRT, and NPU SDKs, exposing a unified API to the upper layers to ensure portability and scalability across different devices. The lowest-level hardware execution layer encompasses computing resources such as CPUs, GPUs, and NPUs, actually carrying out and executing assigned tasks to achieve efficient collaborative computing. The entire framework supports dynamic offloading, intelligent mapping, and highly reliable inference of multi-source tasks in industrial scenarios.

[0031] like Figure 1 As shown, Figure 1 A flowchart of a heterogeneous resource scheduling method provided in an embodiment of this application is shown. The method includes the following steps: Step S110: Obtain the tasks to be assigned.

[0032] The task to be assigned is specifically initiated by the application layer.

[0033] Step S120: Parse the task to be assigned and generate multiple subtasks and task attribute identifiers corresponding to each subtask.

[0034] Each task to be assigned can be parsed into multiple subtasks. These subtasks may be computationally intensive or latency-sensitive. The subtasks resulting from parsing a single task can belong to the same task type, such as all being computationally intensive or latency-sensitive tasks. Alternatively, the subtasks can belong to different task types, such as at least one subtask being a computationally intensive task and at least one subtask being a latency-sensitive task.

[0035] The computing device can parse the task to be assigned, generate multiple subtasks, and build a dynamic attribute set for each subtask. This dynamic attribute set includes, but is not limited to, time constraints (such as deadlines, periodic / non-periodic, etc.), resource requirements (such as expected computing power such as TOPS, memory bandwidth, and video memory usage), and task type (such as computationally intensive tasks such as small model inference, multi-objective collaboration, anomaly detection and predictive maintenance, and latency-sensitive tasks such as control logic and real-time feedback).

[0036] Next, corresponding task attribute identifiers are generated based on the dynamic attribute set of the subtask. For example, the task attribute identifiers for computationally intensive tasks may include model identifier or model fingerprint hash (such as model name), precision mode, model input tensor, etc., while the task attribute identifiers for latency-sensitive tasks may include task type, task name, deadline, etc.

[0037] The computing device can obtain the dynamic attribute set corresponding to each subtask through metadata submitted by the application layer, and then generate task attribute identifiers based on the dynamic attribute set. Alternatively, it can obtain the task attribute identifier corresponding to the subtask from historical execution records based on the subtask's identifier information (such as task ID). Furthermore, the computing device can parse the tasks to be assigned, extract the features corresponding to each subtask online, and then generate task attribute identifiers corresponding to each subtask based on the extracted features. Of course, the computing device can also use multiple methods to process the tasks to be assigned, enriching the information contained in the dynamic attribute set, thereby ensuring the accuracy of the task attribute identifiers.

[0038] Furthermore, since different types of tasks have different computational characteristics and performance requirements, the computing device can also adopt different methods when generating task attribute identifiers for subtasks, depending on the type of the subtask. Specifically, step S120 may include the following steps (steps S121 to S123): Step S121: Based on the structure of the task to be assigned, decompose the task to be assigned into multiple sub-tasks and determine the task type corresponding to each sub-task.

[0039] Step S122: If the task type is a computationally intensive task, then the model graph of the subtask is parsed, the model features are extracted, and a task attribute identifier corresponding to the subtask is generated according to the task type and model features. This task attribute identifier belongs to the computationally intensive task identifier.

[0040] Step S123: If the task type is a delay-sensitive task, the code of the subtask is analyzed, code features are identified, and a task attribute identifier corresponding to the subtask is generated based on the task type and code features. This task attribute identifier belongs to the delay-sensitive task identifier.

[0041] The computing device can parse the task structure of the task to be assigned, decompose the task into multiple subtasks, and determine the task type corresponding to each subtask. This task type is not a generalized computationally intensive task or latency-sensitive task, but a finely defined task type based on the semantics, structure, computational characteristics, resource requirements, etc. of the subtask, such as YOLOv5s task, ResNet-50 FP32 task, PID control task, communication processing task, etc.

[0042] As an example, computing devices can analyze the computational load of subtasks. If a subtask involves a large number of mathematical operations, matrix operations, loop calculations, etc., the computing device can first determine that the subtask is a computationally intensive task, and then determine the refined task type corresponding to the subtask based on the model structure in the subtask. If the computational load of a subtask is relatively small and has clear time constraints, the computing device can first determine that the subtask is a latency-sensitive task, and then determine the refined task type corresponding to the subtask based on the code behavior characteristics of the subtask.

[0043] When a subtask is a computationally intensive task, the computing device can parse the model analysis graph of the subtask (such as the ONNX model analysis graph, TensorRT model analysis graph, etc.) and extract model features such as operator type, tensor shape, parallelism, and computation density from the model analysis graph. Then, based on the model features, it can generate the corresponding task attribute identifier for the subtask, which specifically includes model identifier, precision mode, input tensor, deadline, etc.

[0044] When a subtask is a latency-sensitive task, the computing device can analyze the static code of the subtask and obtain code characteristics such as loop depth, branch frequency, and interrupt sensitivity. Then, based on the code characteristics, it can generate a task attribute identifier corresponding to the subtask, which includes task type, deadline, etc.

[0045] Through steps S121 to S123, the computing device first determines the task type of the subtask, and then analyzes the subtask according to the corresponding method based on the task type, so as to accurately determine the task attribute identifier corresponding to the subtask, thereby providing an accurate data foundation for the subsequent scheduling of heterogeneous resources.

[0046] After step S120, proceed to step S130: calculate the priority of each subtask based on the task attribute identifier corresponding to each subtask.

[0047] Priority is used to control the order of task scheduling. When multiple tasks are queued, the computing device can schedule them according to priority, executing higher-priority tasks first. After acquiring the tasks to be assigned, the computing device can dynamically adjust the priority of each subtask to make full use of the system's idle resources and improve overall throughput. For example, when the system is idle, the priority of AI inference tasks can be increased to achieve "intensive computing during idle time".

[0048] Because different types of subtasks have different computational requirements, for example, for latency-sensitive tasks with strict time constraints (such as control logic tasks), high priority can ensure that they are completed within the deadline and avoid system failures caused by timeouts. Therefore, computing devices can determine the task type of each subtask based on the task attribute identifier. If the task type is a latency-sensitive task, a higher priority is set for the subtask; if the task type is a computationally intensive task, a lower priority is set for the subtask to ensure that tasks with hard real-time requirements do not time out.

[0049] Specifically, the computing device can acquire the power consumption, resource load, and other statuses of computing resources in real time, and then dynamically calculate the priority of each subtask by combining the computational load, deadline, and other characteristics of the task. Step S130 may include the following steps (steps S131 to S132): Step S131: If the task attribute identifier belongs to the compute-intensive task identifier, then obtain the throughput requirement of the subtask from the task attribute identifier corresponding to the subtask, obtain the resource load of the computing resources, and calculate the priority of the subtask according to the throughput requirement and resource load.

[0050] Step S132: If the task attribute identifier is a delay-sensitive task identifier, then obtain the time constraint from the task attribute identifier corresponding to the subtask, and calculate the priority of the subtask according to the time constraint.

[0051] If the task attribute identifier includes a task type, the computing device can directly determine whether the task attribute identifier corresponding to each subtask belongs to a compute-intensive task identifier or a latency-sensitive task identifier based on the task type in the task attribute identifier. If the task type in the task attribute identifier is compute-intensive, then the task attribute identifier corresponding to the subtask is determined to be a compute-intensive task identifier; if the task type in the task attribute identifier is latency-sensitive, then the task attribute identifier corresponding to the subtask is determined to be a latency-sensitive task identifier.

[0052] If the task attribute identifier does not include a task type, the computing device can determine whether the task attribute identifier of each subtask belongs to a compute-intensive task identifier or a latency-sensitive task identifier based on characteristics such as the model identifier, precision mode, and deadline in the task attribute identifier. For example, if the task attribute identifier includes characteristics such as model identifier, precision mode, and model input size, then the task attribute identifier is determined to be a compute-intensive task identifier; if the task attribute identifier includes a specific deadline but does not include characteristics such as model identifier and precision mode, then the task attribute identifier is determined to be a latency-sensitive task identifier.

[0053] If a task is classified as computationally intensive, the priority of a subtask can be correlated with its throughput requirements and the load status of the NPU / GPU corresponding to the current computing resources. When computing resources are idle, the priority of computationally intensive tasks in the queue is increased to achieve "intensive computing during idle times." Specifically, the priority of a subtask belonging to a computationally intensive task can be calculated using the following formula:

[0054] in, Priority of subtasks To meet the throughput requirements of subtasks, To calculate the resource load of the resources. For computing resources, the preferred hardware for the subtask is defined. Specifically, a preferred hardware can be preset for each type of task in the computing device. For example, for subtasks with lightweight models, INT8, and low latency requirements, the preferred hardware can be set to NPU; for subtasks with large models, FP16 / FP32, and high throughput, the preferred hardware can be set to GPU; and for extremely lightweight subtasks or subtasks without accelerator support, the preferred hardware can be set to CPU.

[0055] If the task type is a delay-sensitive task, the priority of the subtask is related to its time constraint. For example, the closer the subtask is to the deadline, the higher its priority, to ensure that the subtask does not time out. Specifically, the priority of a delay-sensitive subtask can be calculated using the following formula:

[0056] in, The time constraint (i.e., deadline) for the subtask. To calculate the current system time of the device.

[0057] Through steps S131 to S133, the computing device can dynamically adjust the priority of subtasks based on their task type and by sensing the resource status of the computing device and the characteristics of the task itself in real time. This balances real-time performance and throughput, enabling latency-sensitive tasks to be scheduled in a timely manner, while computationally intensive tasks can make full use of the idle computing power of computing resources, thereby maximizing the utilization of computing resources. This ensures zero timeout for latency-sensitive tasks and low latency and high energy efficiency for computationally intensive tasks.

[0058] After step S130, step S140 is executed: the execution order of multiple subtasks is determined according to priority, and the following steps S150 to S180 are executed on each subtask according to the execution order.

[0059] The computing device can sort multiple subtasks according to priority, placing higher-priority subtasks before lower-priority subtasks to ensure that higher-priority subtasks are executed first. Of course, to ensure zero timeout for latency-sensitive tasks, priority preemption and rollback mechanisms can be set up, allowing high-priority tasks to preempt computing resources used by low-priority tasks, and setting resource reservation states and priority promotion strategies for preempted tasks to prevent them from "starving."

[0060] As an example, since latency-sensitive tasks have hard real-time requirements, while computationally intensive tasks have soft real-time requirements, when multiple subtasks include both latency-sensitive and computationally intensive tasks, latency-sensitive tasks have preemptive rights. That is, regardless of the priority of the subtasks, latency-sensitive tasks are always scheduled before computationally intensive tasks. Specifically, if the CPU is executing a computationally intensive task, when a higher-priority latency-sensitive task arrives, the computing device will interrupt the current computationally intensive task, prioritize the execution of the latency-sensitive task, and simultaneously set a resource reservation state for the preempted computationally intensive task and appropriately increase its priority.

[0061] When multiple subtasks contain multiple latency-sensitive or computationally intensive tasks, these tasks are sorted according to their priority, with higher-priority tasks being executed first.

[0062] Step S150: Obtain the target performance model corresponding to each computing resource based on the task attribute identifier.

[0063] Among them, the efficiency model is used to record the peak computing power of computing resources, the efficiency of computing resources when performing different types of tasks (such as FLOPS / Watt, latency of executing specific operators, etc.), and the performance indicators of computing resources (such as latency, power consumption, energy efficiency ratio, etc.).

[0064] Since the peak computing power, efficiency, and performance metrics of the same computing resource may differ when executing different tasks, the computing device can store the peak computing power, efficiency, and performance metrics obtained when the computing resource executes various types of tasks in the same performance model. The computing device can then retrieve the corresponding data from the performance model based on the task attribute identifier to form a target performance model.

[0065] Of course, the computing device can also save the peak computing power, efficiency, and performance metrics obtained when the computing resources execute various types of tasks into different performance models to generate performance models corresponding to each task type. The computing device can determine the task type of a subtask based on the task attribute identifier, and then determine the performance model corresponding to that task type as the target performance model. Specifically, step S150 includes the following steps (steps S151 to S152): Step S151: Determine the task type of the subtask based on the task attribute identifier.

[0066] Step S152: Obtain the performance model corresponding to the task type from the performance model set on each computing resource to obtain the target performance model corresponding to each computing resource. The performance model set includes performance models corresponding to multiple task types.

[0067] Among them, the performance model set is used on computing resources to store performance models corresponding to various task types. The computing device can first determine the task type of the subtask based on the task attribute identifier, and then obtain the target performance model from the performance model set on each computing resource that corresponds to the task type.

[0068] In steps S151 to S152, the computing resources store performance models corresponding to multiple task types, enabling the computing device to quickly find the corresponding target performance model based on the task type of each subtask, so as to provide a data basis for the subsequent calculation of the cost function.

[0069] After step S150, proceed to step S160: calculate the cost function corresponding to each computing resource based on the task attribute identifier and the target performance model.

[0070] In addition to prioritizing the subtasks, the computing device also needs to match the task attribute identifiers of the subtasks with the target performance models of each computing resource, and use a cost function to score the expected efficiency of the subtasks on all available computing resources.

[0071] The task attribute identifier of a subtask contains at least one task attribute to characterize the subtask's demand for computing resources, including but not limited to computational density (FLOPs / byte), parallelism (number of threads that can run in parallel), memory access pattern (whether it is regular or has high bandwidth), and operator type (e.g., convolution percentage, GEMM percentage). The target performance model corresponding to the computing resources includes various performance indicators, including but not limited to preset latency, resource load, and energy efficiency.

[0072] Cost functions can be set in various forms according to the computational requirements of different subtasks. For example, cost functions based on task type and resource characteristics can be used. Specifically, a matching score between each task type and computing resource can be pre-set (e.g., the matching score of control logic tasks on CPU is higher than that on GPU), and then the cost function corresponding to each computing resource can be calculated based on the matching score and the utilization rate of computing resources. Cost functions based on task urgency and resource availability can be used. Specifically, the urgency score of a subtask can be determined based on its deadline (e.g., tasks nearing their deadline have a higher score), and the availability score of computing resources can be determined based on resource complexity and the idle status of computing resources (e.g., low load and idle computing resources have a higher score). Then, the number of cost rows corresponding to each computing resource can be calculated based on the urgency score of the subtask and the availability score of the computing resources.

[0073] Furthermore, to further ensure the accuracy of the cost function, a corresponding first weight can be set for each performance index in the performance model corresponding to the computing resources. This first weight can be used to adjust the focus of the cost function to adapt to different task types, enabling the computing device to flexibly respond to various application scenarios and changing needs. Specifically, step S160 may include the following steps (steps S161 to S162): Step S161: Obtain the first weight corresponding to each performance indicator.

[0074] Step S162: Calculate the cost function corresponding to each computing resource based on the task attributes, the first weight, and the performance index.

[0075] Assuming the performance metrics include predicted latency, predicted power consumption, and resource load, the cost function is specifically formulated as follows:

[0076] in, The execution latency when executing subtask T is the predicted computational resource R in the target performance model. This is the deadline for task T. For the predicted power consumption in the target performance model, To calculate the current resource load of resource R in the target performance model, , , The first weight corresponding to each performance indicator, The first weight corresponding to the predicted execution latency in the target performance model. The first weight corresponding to the predicted power consumption in the target performance model; This is the first weight corresponding to resource complexity in the target performance model.

[0077] As an example, assuming the deadline for subtask T is 30ms, the prediction latency in the target performance model for the NPU is 12ms, the prediction power consumption is 1.5, and the resource load is 0.3, while the prediction latency in the target performance model for the GPU is 18ms, the prediction power consumption is 2.0, and the resource load is 0.3. , , ,but: ; ; The cost function for NPU is 0.62, and the cost function for GPU is 0.82.

[0078] It should be noted that the performance metrics used in the cost function can be set according to the computational requirements of the subtask. For example, if the computational requirements of the subtask do not concern time constraints, the cost function can only include predicted power consumption and resource load; if the computational requirements of the subtask do not concern device power consumption, the cost function can only include predicted execution latency and resource load; if the computational requirements of the subtask also concern queue length, then queue length-related performance metrics can also be added to the cost function.

[0079] Similarly, the first weight corresponding to each performance indicator can also be set according to the computational requirements of the subtask. For example, the larger the first weight corresponding to the predicted execution latency, the more the computing device will prioritize ensuring the task is completed on time; the larger the first weight corresponding to the predicted power consumption, the more the computing device will tend to select low-power computing resources; the larger the first weight corresponding to the resource load, the more the computing device will avoid concentrating tasks on high-load computing resources.

[0080] Through steps S161 to S162, the computing device can more accurately calculate the cost function between subtasks and computing resources based on the first weight corresponding to the performance index, thereby providing a more accurate data basis for subsequent scheduling of computing resources.

[0081] After step S160, proceed to step S170: schedule the subtask to the computing resource with the lowest cost function.

[0082] In this scenario, the computing device can schedule subtasks to the computing resources with the lowest cost function, achieving optimal matching between subtasks and computing resources, thereby reducing the overall average latency and power consumption of the computing device. As an example, if the cost function for the NPU is 0.62 and the cost function for the GPU is 0.82, the computing device can choose to schedule the subtasks to the NPU.

[0083] Step S180: Obtain multiple target performance indicators fed back when the computing resources execute subtasks, and update the target performance model corresponding to the computing resources based on the target performance indicators.

[0084] The computing device can obtain multiple target performance indicators fed back when computing resources execute subtasks, and update the target performance model in real time based on the target performance indicators to ensure the accuracy of subtask scheduling.

[0085] Specifically, after each subtask completes execution on a computing resource, the actual performance metrics of that execution (such as latency, power consumption, and energy efficiency ratio) are collected and integrated into the performance model of the corresponding task type for that computing resource, i.e., the target performance model for that computing resource. Specifically, the computing device can update the target performance model corresponding to the computing resource with the collected actual performance metrics to ensure that the computing device can quickly respond to performance changes of the computing resource; the computing device can also pre-store a learning rate and update the data in the target performance model according to this learning rate, thereby updating the data in the target performance model in real time and providing a more accurate data foundation for the scheduling of subsequent subtasks.

[0086] Furthermore, the computing device can simultaneously maintain performance models across multiple dimensions. For example, the target performance model can include multiple performance indicators, and these indicators correspond one-to-one with multiple target performance indicators. The computing device can update the multiple performance indicators in the target performance model one by one based on the multiple target performance indicators collected in real time. Specifically, step S180 may include the following steps (steps S181 to S183): For each performance index in the target performance model, the following steps are performed: Step S181: Obtain the preset learning rate, and calculate the second weight corresponding to the target performance index and the third weight corresponding to the performance index in the efficiency model based on the learning rate.

[0087] Step S182: Calculate new performance indicators based on the target performance indicators, the second weight, the performance indicators in the efficiency model, and the third weight.

[0088] Step S183: Replace the performance indicators in the target performance model with new performance indicators.

[0089] Taking predicted execution latency as an example, the computing device can first obtain a preset learning rate. The range of values ​​is The learning rate is used to control the degree of influence of the target performance index on the target effectiveness model. As the value approaches 1, the target performance model places greater trust in the target performance metric, meaning it relies more heavily on the most recently observed data. This results in a faster response to changes in computing resource performance, but the fluctuations may be more pronounced. When the target performance model approaches zero, it becomes more stable, but it is less responsive to changes in computing resource performance (such as overheating and frequency reduction). It can be set to 0.1~0.3.

[0090] Next, the second weight corresponding to the target performance model and the third weight corresponding to the performance index in the performance model are calculated based on the learning rate. For example, the learning rate... As the second weight, the third weight is set to Then, based on the target performance index, the second weight, the performance index in the efficiency model, and the third weight, a new performance index is calculated. Specifically, the new performance index can be calculated using the following formula:

[0091] in, The new performance index obtained through calculation; Before the kth scheduling of computing resources, the computing device predicts the execution latency of a certain type of task on the computing resources using the above formula, which is the performance index in the target performance model. The target performance metric is the actual execution latency reported when the resource is executed for the kth time for the subtask corresponding to the task type.

[0092] Finally, the execution latency predicted in the target performance model will be used. Replace with new performance metrics This enables real-time updates to the performance model.

[0093] Furthermore, performance metrics in the target performance model, such as the energy efficiency ratio (TOPS / W), memory bandwidth utilization, and temperature sensitivity coefficient (temperature rise per unit task), can also be updated in the same way. For example, the energy efficiency ratio... The following formula can be used for updating:

[0094] In addition, different performance metrics can have different learning rates. The specific learning rate can be set according to the focus of the performance metric. If the performance metric focuses more on the data observed in real time, the learning rate can be set to be larger.

[0095] As an example, suppose the NPU on an industrial edge server initially shows an average latency of 12ms for executing a "YOLOv5s" object detection task. After the industrial edge server runs under high load for two hours, insufficient heat dissipation triggers temperature control to reduce the frequency. At this point, the real-time execution latency for the same task type becomes 22ms, and the learning rate... If the value is 0.2, then:

[0096] The execution latency predicted in the target performance model for a subtask containing "YOLOv5s" in the NPU is updated to 14.0ms. When the computing device receives another subtask containing "YOLOv5s" with a deadline of 15ms, the execution latency predicted in the NPU's target performance model (14ms) is very close to the subtask's deadline. In this case, the computing device may be more inclined to schedule the subtask to a GPU with available capacity, or reject it outright to ensure the reliability of the computing device and avoid timeout risks caused by performance changes.

[0097] Through steps S181 to S183, the computing device can not only update the performance model corresponding to the computing resources in real time to provide more accurate data for the scheduling of subsequent subtasks, but also has a relatively low computational overhead when updating the target performance model, making it very suitable for real-time operation on resource-constrained computing devices.

[0098] In the above embodiments, the computing device can decompose the task to be assigned into multiple subtasks, calculate the priority of each subtask in real time, determine the execution order of the multiple subtasks based on their priorities, and schedule multiple computing resources on the computing device according to the execution order. This avoids binding the entire task to a single technical resource and enables the collaborative execution of heterogeneous resources. Furthermore, the computing device can calculate the cost of each computing resource executing a subtask based on the task attribute identifier of the subtask and the performance model of the computing resources. This allows for scheduling the subtask to the computing resource with the lowest cost, ensuring that each subtask can be executed efficiently. Simultaneously, the performance indicators fed back by the computing resources during subtask execution are used to update the performance model of the computing resources in real time to adapt to dynamic changes in hardware performance. This allows for more accurate prediction of the cost of executing a subtask on different resources, helping to make more reasonable scheduling decisions and ensuring that the subtask can be executed efficiently while meeting its time constraints and resource requirements.

[0099] Furthermore, to schedule each subtask more accurately, the first weight in the cost function formula can be defined as an adjustable strategy parameter. By adjusting the first weight in the cost function, scheduling preferences can be dynamically changed, such as... Figure 2 As shown, Figure 2 A flowchart of a heterogeneous resource scheduling method according to another embodiment of this application is shown. The method includes the following steps: The following steps are executed periodically at preset time intervals: Step S210: Collect the current performance metrics corresponding to each computing resource.

[0100] Step S220: Obtain the number of tasks completed on time and the number of tasks that failed to complete within the preset time interval for each computing resource.

[0101] Step S230: Calculate the reward corresponding to each computing resource based on the current performance indicators, the number of tasks completed on time, and the number of tasks that have not been completed due to timeout.

[0102] Step S240: Update the first weight of each performance indicator in the performance model corresponding to each computing resource according to the reward corresponding to each computing resource.

[0103] Among them, the current performance metrics and task queues are used to characterize the system state snapshot of the computing device, such as the resource load of each computing resource, task queues, and task type mix ratio, to comprehensively depict the operating status of the computing device at time t, and serve as the basis for updating the first weight. Specifically, the current state metrics can be expressed by the following formula:

[0104] in, , and These represent the current utilization rate of each computing resource (e.g., a floating-point number between 0 and 1) to reflect the busyness of the computing resources; and These represent the lengths of the current compute-intensive task queue and latency-sensitive task queue on the computing device, respectively, to reflect the pressure of the current task backlog on the computing device; The average end-to-end latency of all completed tasks within a preset time interval is used to measure the real-time performance of computing devices. This represents the total power consumption of the current computing device, used to constrain energy efficiency.

[0105] The computing device can periodically collect the above data at preset time intervals (e.g., 10 seconds) through system monitoring modules (such as Linux perf, NVIDIA nvidia-smi, NPU vendor driver API) and aggregate it into a state vector. .

[0106] Next, based on the current performance metrics of each computing resource, the number of tasks completed on time, and the number of tasks that failed to complete on time, the reward for each computing resource is calculated. This reward includes positive rewards (e.g., tasks completed before the deadline, high throughput) and negative rewards (e.g., tasks timed out, overall system power consumption exceeding limits). Specifically, the reward for each computing resource can be calculated using the following formula:

[0107] in, This indicates the number of tasks successfully completed before the deadline within the current sampling period, i.e., within the preset time interval (e.g., 10 seconds), which is the number of tasks completed on time. Indicates the number of tasks that have not been completed within the timeout period (especially control tasks); This indicates the current actual power consumption of computing resources. This indicates the preset power consumption limit of the computing resources (e.g., 30W). , Indicates the penalty for exceeding power consumption; , and A preset reward coefficient is used on computing devices to balance the importance of different data, such as in industrial scenarios. This is to reduce task timeout rates in industrial scenarios.

[0108] As an example, suppose computing resources complete 8 tasks within a certain period, including 2 latency-sensitive tasks, and all tasks complete on time with no timeouts. , The computing resources are currently at a total power consumption of 28W, and the preset power consumption limit is 30W. Then the reward for the computing resource This reward is a positive reward.

[0109] Finally, the first weight in the cost function is updated based on the reward to adjust the heterogeneous resource scheduling method to continuously adapt to the new workload mode of computing resources. Specifically, the first weight in the cost function can be updated using methods such as Proximal Policy Optimization (PPO) and Deep Q-Network (DQN).

[0110] As an example, the computing device can trigger a weight update every 10 seconds to collect the state vector. Then, the state vector Input Policy Network To generate a first set of weights Then, the calculation device uses this set of first weights within a preset time interval of 10 seconds. Perform heterogeneous resource scheduling and collect the state vector after 10 seconds. Based on the number of tasks completed on time Number of tasks that failed to complete within the time limit and the current actual power consumption of computing resources Calculate the new reward Then, based on the new rewards Policy network The parameters are updated to update the state vector. Input the updated policy network This enables policy networks Output a new set of first weights.

[0111] Specifically, the computing device can use the PPO algorithm to update the parameters of the policy network. The experience is stored in the experience replay pool, and the parameters of the policy network are updated according to the goal of maximizing long-term accumulated rewards. The specific formula is as follows:

[0112] in, This is the discount factor.

[0113] In the above embodiments, the computing device can adjust the first weight in the cost function by obtaining the performance indicators of computing resources and the task completion status, so that the heterogeneous resource scheduling method can continuously adapt to new workload modes of computing resources. The computing device has the ability to automatically optimize and can cope with unknown and changing workload scenarios to achieve long-term optimal scheduling.

[0114] Furthermore, to ensure that the heterogeneous resource scheduling method can handle subtasks of various task types, a default computing resource can be preset in the computing device, that is, a default computing resource is set among multiple computing resources. Before step S170, the method also includes: Step S310: If the target performance model corresponding to each computing resource is empty, then submit the subtask to the default computing resource.

[0115] If the target performance model corresponding to each computing resource is not empty, it means that the computing device has processed a task of the same type as the subtask, and at least one performance model set on the computing resource stores the target performance model corresponding to the task type of the subtask. The computing device can calculate the cost function corresponding to the subtask according to the target performance model, and then schedule the subtask to the computing resource with the minimum cost function, that is, execute step S170.

[0116] If the target performance model for each computing resource is empty, it means that the computing device has not processed a task of the same type as the subtask. A cold start strategy is required, which means that the subtask is assigned to the default computing resource (such as CPU) so that the default computing resource executes the subtask once, collects initial data, and generates the performance model corresponding to the task type of the subtask.

[0117] In the above embodiments, the computing device is provided with default computing resources, which enables the computing device to trigger a cold start strategy when it obtains the first subtask to be processed, and execute the subtask through the default computing resources, so as to ensure that the computing device can normally process subtasks of various task types.

[0118] Furthermore, this application embodiment also provides a complete example where the computing device is an edge computing device in a smart factory. The above-mentioned heterogeneous resource scheduling method is applied to a set of industrial robot vision servo control systems deployed in the smart factory. This system needs to handle two types of tasks simultaneously. The first type is a latency-sensitive task, specifically PID control of robot joints with a cycle of 5ms, which has hard real-time requirements. Timeout will cause the robot's robotic arm to go out of control. The second type is a computationally intensive task, specifically real-time target detection based on a camera (mainly using the YOLOv5s model), used to identify the workpiece position, requiring an average latency of ≤30ms and a throughput of ≥20 FPS.

[0119] When the computing device receives both types of tasks simultaneously, it first analyzes the two tasks to generate task attribute identifiers for the latency-sensitive task, which includes a task type of "control", a deadline of 5ms, and a peak memory usage of 0.1MB. It also generates task attribute identifiers for the computationally intensive task, which include a task type of "AI_inference", a model name of "YOLOv5s", a deadline of 30ms, an expected power consumption of 8.7e9, and an input tensor of (640, 640, 3).

[0120] The computing device includes computing resources such as CPU, GPU, and NPU, and the first weight corresponding to the current predicted execution latency is 0.6, the first weight corresponding to the predicted power consumption is 0.2, and the first weight corresponding to the resource load is 0.2.

[0121] Because latency-sensitive tasks have hard real-time requirements and are preempted, computing devices prioritize executing latency-sensitive tasks before executing computationally intensive tasks. The computing device first obtains the target performance models for latency-sensitive tasks on each computing resource. Specifically, the data in each target performance model is as follows: CPU predicted execution latency is 0.8ms, resource load is 0.6; GPU predicted execution latency is 2.5ms, resource load is 0.3; and NPU predicted execution latency is 5.0ms, resource load is 0.4. Based on the task attribute identifier and the target performance model, the computing device can calculate: The cost function corresponding to the CPU is: The cost function for GPU is The cost function corresponding to the NPU is .

[0122] Therefore, computing devices schedule latency-sensitive tasks to the CPU for execution. Simultaneously, the computing device acquires multiple target performance metrics from the CPU during the execution of these tasks and updates the CPU's target performance model based on these metrics.

[0123] Then, the computing device re-acquires the target performance models corresponding to the computationally intensive tasks on each computing resource. Specifically, the data in each target performance model is as follows: CPU's predicted execution latency is 45ms, and resource load is 0.6; GPU's predicted execution latency is 18ms, predicted power consumption is 2.0, and resource load is 0.3; NPU's predicted execution latency is 12ms, predicted power consumption is 1.5, and resource load is 0.4. Based on the task attribute identifier and the target performance model, the computing device can calculate: The cost function corresponding to the CPU is: The cost function for GPU is The cost function corresponding to the NPU is .

[0124] Therefore, the computing device schedules computationally intensive tasks to the NPU for execution. Simultaneously, the computing device acquires multiple target performance metrics from the NPU during these tasks and updates the corresponding target performance model of the NPU based on these metrics.

[0125] In addition, the computing device can also acquire the state vector S at preset time intervals (such as 10 seconds), specifically including the following data: CPU resource load is 0.6, GPU resource load is 0.3, NPU resource load is 0.4, queue length for computationally intensive tasks is 3, queue length for latency-sensitive tasks is 1, average end-to-end latency is 8ms, and total power consumption of the computing device is 22W.

[0126] Furthermore, within the current preset time interval, the computing device completed a total of 10 latency-sensitive tasks, all of which were completed on time. The device also completed 8 computationally intensive tasks, of which 7 were completed on time and 1 timed out. The total power consumption of the device did not exceed the expected power consumption. Therefore, the reward can be calculated as follows: .

[0127] The computing device can update the first weight with the state vector S and the reward r. For example, if the risk of control task timeout increases, the computing device will automatically increase the first weight corresponding to the preset execution delay from 0.6 to 0.75, so that the computing device can emphasize real-time performance more in the next cycle.

[0128] According to a second aspect of the embodiments of this application, a heterogeneous resource scheduling device is also provided, such as... Figure 3 As shown, Figure 3 A schematic diagram of the heterogeneous resource scheduling device provided in an embodiment of this application is shown. The device 1 includes: a first acquisition module 11, a parsing module 12, a first calculation module 13, an execution order determination module 14, a second acquisition module 15, a first calculation module 16, a submission module 17, and an update module 18.

[0129] The first acquisition module 11 is used to acquire tasks to be assigned, which include multiple subtasks. The parsing module 12 is used to parse the tasks to be assigned, generating multiple subtasks and task attribute identifiers corresponding to each subtask. The first calculation module 13 is used to calculate the priority of each subtask based on its corresponding task attribute identifier. The execution order determination module 14 is used to determine the execution order of the multiple subtasks based on their priorities. The second acquisition module 15 is used to acquire the target performance model corresponding to each computing resource based on its task attribute identifier. The second calculation module 16 is used to calculate the cost function corresponding to each computing resource based on its task attribute identifier and the target performance model. The submission module 17 is used to schedule the subtasks to the computing resource with the minimum cost function. The update module 18 is used to acquire multiple target performance indicators fed back when the computing resource executes the subtasks, and update the target performance model corresponding to the computing resource based on these indicators.

[0130] In the above embodiments, the computing device can decompose the task to be assigned into multiple subtasks, calculate the priority of each subtask in real time, determine the execution order of the multiple subtasks based on their priorities, and schedule multiple computing resources on the computing device according to the execution order. This avoids binding the entire task to a single technical resource and enables the collaborative execution of heterogeneous resources. Furthermore, the computing device can calculate the cost of each computing resource executing a subtask based on the task attribute identifier of the subtask and the performance model of the computing resources. This allows for scheduling the subtask to the computing resource with the lowest cost, ensuring that each subtask can be executed efficiently. Simultaneously, the performance indicators fed back by the computing resources during subtask execution are used to update the performance model of the computing resources in real time to adapt to dynamic changes in hardware performance. This allows for more accurate prediction of the cost of executing a subtask on different resources, helping to make more reasonable scheduling decisions and ensuring that the subtask can be executed efficiently while meeting its time constraints and resource requirements.

[0131] According to a third aspect of the embodiments of this application, a computing device is provided, such as... Figure 4 As shown, Figure 4 The diagram shows a structural schematic of a computing device provided in an embodiment of this application. The specific embodiments of this application do not limit the specific implementation of the computing device.

[0132] like Figure 4 As shown, the computing device 2 may include a processor 21 and a memory 22.

[0133] The memory 22 is used to store the computer program 23. The memory 22 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device. The computer program 23 may include computer-executable instructions.

[0134] The processor 21 is used to execute the computer program 23 to implement the above-described heterogeneous resource scheduling method embodiment.

[0135] The processor 21 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. The computing device includes one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.

[0136] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described heterogeneous resource scheduling method embodiment.

[0137] This application provides a computer program that can be executed by a processor to implement the above-described heterogeneous resource scheduling method embodiments.

[0138] This application provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described heterogeneous resource scheduling method embodiment.

[0139] In the several embodiments provided in this application, any function, if implemented as a software functional module / unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, part or all of the technical solutions of this application can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or other electronic device) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing computer program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0140] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, the embodiments of this application are not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of this application.

[0141] It should be noted that the above embodiments are illustrative of this application and not restrictive, and those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In claims enumerating several means, several units or modules of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

[0142] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A heterogeneous resource scheduling method, characterized in that, Applied to a computing device, the computing device including various computing resources, the method includes: Get tasks to be assigned; The task to be assigned is parsed to generate multiple subtasks and task attribute identifiers corresponding to each subtask. Calculate the priority of each subtask based on the task attribute identifier corresponding to each subtask; The execution order of the multiple subtasks is determined according to the priority, and the following steps are performed on each subtask according to the execution order: The target performance model corresponding to each computing resource is obtained based on the task attribute identifier; Based on the task attribute identifier and the target performance model, calculate the cost function corresponding to each computing resource; Schedule the subtask to the computing resource that minimizes the cost function; Obtain multiple target performance indicators fed back when the computing resources execute the subtask, and update the target performance model corresponding to the computing resources based on the target performance indicators.

2. The heterogeneous resource scheduling method according to claim 1, characterized in that, The step of parsing the task to be assigned to generate multiple subtasks and task attribute identifiers corresponding to each subtask specifically includes: Based on the structure of the task to be assigned, the task to be assigned is decomposed into multiple sub-tasks, and the task type corresponding to each sub-task is determined. If the task type is a computationally intensive task, then the model parsing graph of the subtask is parsed, model features are extracted, and a task attribute identifier corresponding to the subtask is generated according to the task type and the model features. This task attribute identifier is a computationally intensive task identifier. If the task type is a latency-sensitive task, the code of the subtask is analyzed, code features are identified, and a task attribute identifier corresponding to the subtask is generated based on the task type and the code features. This task attribute identifier is a latency-sensitive task identifier.

3. The heterogeneous resource scheduling method according to claim 1, characterized in that, The step of calculating the priority of each subtask based on the task attribute identifier corresponding to each subtask specifically includes: If the task attribute identifier belongs to the computationally intensive task identifier, then the throughput requirement of the subtask is obtained from the task attribute identifier corresponding to the subtask, the resource load of the computing resource is obtained, and the priority corresponding to the subtask is calculated based on the throughput requirement and the resource load. If the task attribute identifier is a delay-sensitive task identifier, then the time constraint is obtained from the task attribute identifier corresponding to the subtask, and the priority corresponding to the subtask is calculated based on the time constraint.

4. The heterogeneous resource scheduling method according to claim 1, characterized in that, The task attribute identifier includes at least one task attribute, and the performance model corresponding to each computing resource includes multiple performance indicators, and each performance indicator is assigned a corresponding first weight. The step of calculating the cost function corresponding to each computing resource based on the task attribute identifier and the target performance model specifically includes: Obtain the first weights corresponding to each of the aforementioned performance metrics; Based on the task attributes, the first weight, and the performance metrics, calculate the cost function corresponding to each computing resource.

5. The heterogeneous resource scheduling method according to claim 4, characterized in that, The method further includes: The following steps are executed periodically at preset time intervals: Collect the current performance metrics corresponding to each of the aforementioned computing resources; Obtain the number of tasks completed on time and the number of tasks that failed to complete within the preset time interval for each computing resource; The reward corresponding to each computing resource is calculated based on the current performance index, the number of tasks completed on time, and the number of tasks that have not been completed due to timeout. Based on the rewards corresponding to each computing resource, update the first weights of each performance indicator in the efficiency model corresponding to each computing resource.

6. The heterogeneous resource scheduling method according to claim 1, characterized in that, The target performance model includes multiple performance indicators, and each of the multiple performance indicators corresponds one-to-one with a multiple target performance indicator; The step of updating the target performance model corresponding to the computing resources based on the target performance index specifically includes: For each performance index in the target performance model, the following steps are performed: Obtain a preset learning rate, and calculate the second weight corresponding to the target performance index and the third weight corresponding to the performance index in the efficiency model based on the learning rate; Calculate a new performance index based on the target performance index, the second weight, the performance index in the efficiency model, and the third weight; Replace the performance indicators in the target performance model with the new performance indicators.

7. The heterogeneous resource scheduling method according to claim 1, characterized in that, A default computing resource is set among the various computing resources; The step of obtaining the target performance model corresponding to each computing resource based on the task attribute identifier specifically includes: The task type of the subtask is determined based on the task attribute identifier; The performance model corresponding to the task type is obtained from the performance model set on each of the computing resources, and the target performance model corresponding to each computing resource is obtained. The performance model set includes performance models corresponding to multiple task types. Before scheduling the subtask to the computing resource that minimizes the cost function, the method further includes: If the target performance model corresponding to each of the aforementioned computing resources is empty, then the subtask is submitted to the default computing resource.

8. A heterogeneous resource scheduling device, characterized in that, The device includes: The first acquisition module is used to acquire tasks to be assigned. The parsing module is used to parse the task to be assigned and generate multiple subtasks and task attribute identifiers corresponding to each subtask. The first calculation module is used to calculate the priority of each subtask based on the task attribute identifier corresponding to each subtask. An execution order determination module is used to determine the execution order of multiple subtasks based on the priority. The second acquisition module is used to acquire the target performance model corresponding to each computing resource based on the task attribute identifier; The second calculation module is used to calculate the cost function corresponding to each of the computing resources according to the task attribute identifier and the target performance model. The submission module is used to schedule the subtask to the computing resource that minimizes the cost function; An update module is used to obtain multiple target performance indicators fed back when the computing resources execute the subtask, and update the target performance model corresponding to the computing resources according to the target performance indicators.

9. A computing device, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the heterogeneous resource scheduling method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the heterogeneous resource scheduling method according to any one of claims 1 to 7.

Images