Heterogeneous computing power resource pooling scheduling platform

Abstract

The invention provides a heterogeneous computing power resource pooling scheduling platform which comprises a task and resource tensor construction module, a scheduling decision module, a breakpoint state generation module and a rescheduling and recovery module. According to the platform, task requirements and node resources are modeled into a tensor structure in a unified mode, and accurate initial scheduling is achieved through a structured scoring function containing conditional penalty terms. In the task running process, interruption judgment is carried out based on the node dynamic state and the scheduling score, and a breakpoint state tensor containing an execution state is generated. When interruption occurs, a proper node is selected through compatibility screening, and task seamless migration and execution recovery are realized by utilizing the stored state. According to the method, the technical problems of non-uniform resource expression, lack of scene adaptability and incapability of realizing uninterrupted migration in a heterogeneous computing power environment are solved, and the resource utilization rate and the service continuity are remarkably improved.

Description

Technical Field

[0001] This invention belongs to the field of data processing, and in particular relates to a heterogeneous computing power resource pooling and scheduling platform. Background Technology

[0002] With the rapid development of cloud computing, artificial intelligence, and the Internet of Things (IoT), the complexity and diversity of computing tasks have significantly increased. Enterprises are increasingly adopting heterogeneous architectures that incorporate multiple computing resources, such as CPUs, GPUs, and FPGAs, to support various business scenarios when deploying computing platforms. However, most existing computing scheduling technologies are based on homogeneous resource pools or static allocation strategies, which have significant limitations when facing multi-source, heterogeneous, and dynamically fluctuating real-world operating environments. On the one hand, task requirements lack a unified structured form; different tasks are represented by various parameter sets at the scheduling input, making it difficult for the scheduler to directly compare and optimize, resulting in low resource utilization. On the other hand, scheduling algorithms typically only consider static task resource adaptation, lacking in-depth modeling of business characteristics and scenario differences. For example, there is a lack of differentiated scheduling strategies for low-latency real-time services or tasks supporting breakpoint recovery. Furthermore, existing systems still have relatively weak mechanisms for handling node failures, resource contention, or sudden interruptions during operation, often resorting to simple task termination and resubmission, resulting in wasted computational results and an inability to achieve uninterrupted migration and recovery. These problems are particularly prominent in cross-center, multi-cloud, and edge computing environments. Node performance fluctuations and network variability significantly increase scheduling uncertainty, further amplifying the shortcomings of traditional methods. Therefore, existing technologies cannot yet achieve a complete closed loop of unified modeling, precise scheduling, and non-disruptive migration in multi-source heterogeneous resource environments. This has become a significant bottleneck restricting the efficient operation and business continuity of computing power pooling platforms. Summary of the Invention

[0003] The purpose of this invention is to design a heterogeneous computing resource pooling scheduling platform that enables different task requirements and node capabilities to be directly compared and computed under the same structure.

[0004] To achieve the above objectives, the present invention provides a heterogeneous computing power resource pooling scheduling platform, the platform comprising: The tensor construction module is used to extract key fields, including the number of processor cores, video memory capacity, response latency, runtime, priority, interrupt support flag, and edge deployment flag, from task requests from the business system, and form task tensors through normalization processing based on the maximum values ​​configured on the platform; at the same time, the resource monitoring subsystem periodically collects status data of computing nodes, including the number of remaining CPU cores, remaining video memory capacity, average response latency, available time window, scheduling priority, breakpoint support flag, and edge node flag, and forms resource tensors through normalization processing. The scheduling decision module is used to calculate the matching score of each node based on the task tensor and resource tensor set through a structured scoring function. The scoring function includes a weighted distance calculation of resource parameters and a conditional penalty term for interruption support and edge deployment, and selects the node with the smallest score as the target node. The breakpoint state generation module is used to monitor the processor utilization, memory utilization, load change rate and resource jitter of nodes during task execution. It combines the scheduling score with the interruption judgment function to determine whether to generate a breakpoint state. When an interruption is determined, a breakpoint state tensor is generated, which includes the running time, model intermediate state, data processing progress and resource usage estimate. The rescheduling and recovery module is used to perform compatibility screening of available nodes based on the breakpoint state tensor when an interruption occurs. The screening conditions include that the node supports breakpoint recovery, the available time window is greater than the remaining estimated duration of the task, and the available resources are greater than the estimated resource usage value. Then, the node with the highest priority is selected as the recovery target node, and the task execution is resumed using the breakpoint state tensor.

[0005] Furthermore, the normalization process of the tensor construction module includes dividing the number of processor cores by the maximum number of schedulable cores configured on the platform, dividing the video memory capacity by the maximum video memory capacity configured on the platform, dividing the maximum response latency by the maximum response latency configured on the platform, dividing the expected running time by the longest running time configured on the platform, and dividing the task priority by the highest priority level configured on the platform.

[0006] Furthermore, the resource monitoring subsystem of the tensor construction module adopts a two-level acquisition mechanism, including a lightweight acquisition agent deployed locally on the node and a central controller. The acquisition agent periodically collects node status data and sends it to the central controller through a message bus. The central controller comprehensively evaluates the node load and available time window by polling the node operation logs and system status snapshots.

[0007] Furthermore, the structured scoring function of the scheduling decision module includes calculating the weighted squared difference of the first five consecutive fields of the task tensor and the resource tensor, adding a first penalty term to nodes that do not support breakpoint recovery when the task supports interruption recovery, and adding a second penalty term to non-edge nodes when the task allows edge node deployment.

[0008] Furthermore, the weights in the weighted squared difference calculation include processor core count weight, video memory capacity weight, response latency weight, runtime weight, and priority weight, and the sum of the weights is 1.

[0009] Furthermore, when there are multiple candidate nodes with the same matching score, the scheduling decision module sorts them according to node priority and selects the node with higher priority as the target node; if the node priorities are still the same, a round-robin mechanism is used to achieve load balancing.

[0010] Furthermore, the interrupt determination function of the breakpoint state generation module is based on the weighted sum of processor utilization, video memory utilization, node load change rate and resource jitter, and combined with the structural risk adjustment factor, which is calculated based on the ratio of the scheduling score to the maximum score of all tasks in the current scheduling cycle.

[0011] Furthermore, the resource usage estimate in the breakpoint state tensor generated by the breakpoint state generation module is calculated by multiplying the normalized processor core count by the running time and the normalized video memory capacity by the running time.

[0012] Furthermore, the compatibility screening of the rescheduling and recovery module includes using a recovery feasibility determination function to check whether the node supports breakpoint recovery, whether the node's available time window is greater than the remaining estimated duration of the task, and whether the sum of the node's available processor cores and video memory capacity is greater than the estimated resource usage value.

[0013] Furthermore, the recovery task execution of the rescheduling and recovery module includes loading the intermediate state of the model to the new node through the intermediate layer recovery interface of the underlying inference framework, obtaining the remaining data from the distributed task input cache system according to the data processing progress and rebuilding the input queue, initializing the resource scheduling controller to allocate resource retention period for the task, and restarting task execution on the new node.

[0014] The beneficial technical effects of the present invention are at least as follows: To address the aforementioned issues, this invention provides a heterogeneous computing power resource pooling scheduling platform. By designing a structured scoring function with breakpoint support and edge adaptation constraints, it achieves initial matching of tasks and nodes, enabling the scheduling process to consider not only computing power supply and demand but also interpretable differentiated decisions based on business characteristics. During task execution, this invention introduces an interruption determination mechanism based on task tensors and scheduling scores, and constructs a breakpoint state tensor to structurally store the task's execution time, model intermediate states, data processing progress, and consumed resources, thereby achieving fine-grained breakpoint capture during node performance fluctuations or resource interruptions. Furthermore, this invention proposes a rescheduling and resumption mechanism for breakpoint tasks. A node compatibility filtering function ensures that migrated nodes can carry the remaining tasks, and the breakpoint state tensor is used to quickly reconstruct the model, data, and resources, allowing tasks to seamlessly continue execution on new nodes. The overall solution forms a closed-loop structure from task modeling, scheduling decision-making, interruption judgment to resumption of execution, solving the problems of lack of unified expression, lack of scenario adaptability and inability to achieve non-disruptive migration in existing technologies, and greatly improving the scheduling robustness and business continuity of the computing resource pooling platform in heterogeneous environments. Attached Figure Description

[0015] The present invention will be further described with reference to the accompanying drawings, but the embodiments in the drawings do not constitute any limitation on the present invention. For those skilled in the art, other drawings can be obtained based on the following drawings without creative effort.

[0016] Figure 1 This is a framework diagram of the heterogeneous computing power resource pooling scheduling platform of the present invention. Detailed Implementation

[0017] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0018] In one or more embodiments, such as Figure 1 As shown, a heterogeneous computing power resource pooling scheduling platform is disclosed, the platform comprising the following: The tensor construction module is used to extract key fields, including the number of processor cores, video memory capacity, response latency, runtime, priority, interrupt support flag, and edge deployment flag, from task requests from the business system, and form task tensors through normalization processing based on the maximum values ​​configured on the platform; at the same time, the resource monitoring subsystem periodically collects status data of computing nodes, including the number of remaining CPU cores, remaining video memory capacity, average response latency, available time window, scheduling priority, breakpoint support flag, and edge node flag, and forms resource tensors through normalization processing. Specifically, the purpose of this module is to provide structured input to the scheduling system, that is, to model the scheduling requirements of business tasks and the real-time resource status of computing nodes as unified vector tensors. Each dimension of the tensor corresponds to a scheduling parameter with clear semantics, and normalization processing makes the different dimensions comparable. The core of this module is to standardize the source of input data and processing logic to achieve a unified computational foundation for subsequent scheduling logic.

[0019] When the platform receives a task request from a business system, it extracts several key fields from the task request message as scheduling input. These fields are sent to the scheduling platform by the upper-layer business system through the platform's unified task description interface. For example, when a conference system calls the AI ​​caption module through a RESTful interface, the accompanying task description includes: the required number of processor cores (e.g., 6 cores), the amount of video memory (e.g., 4GB), the maximum response latency (e.g., 200 milliseconds), the estimated running time (e.g., 180 seconds), the task priority (e.g., level 4), whether interrupt recovery is supported (Boolean value), and whether edge node deployment is supported (Boolean value). These fields are mapped to corresponding variables. ,in Indicates the number of processor cores. This indicates the video memory capacity of the graphics processor. This indicates the maximum response latency that the task can tolerate. Indicates the estimated runtime. Indicates the scheduling priority (the larger the integer, the higher the priority). This is a flag indicating whether breakpoint migration is supported (0 or 1). This is a flag (0 or 1) indicating whether execution on edge nodes is allowed. To ensure uniformity, these raw values ​​are normalized according to platform-defined baseline limits. For example, if the platform sets a maximum schedulable core count of 64, a maximum video memory of 32GB, a maximum response latency of 1000 milliseconds, a maximum runtime of 1000 seconds, and a priority level of 5, then a task requesting a 6-core CPU, 4GB video memory, a maximum latency of 200ms, a runtime of 180 seconds, and a priority of 4 will have the following normalized first five fields: .

[0020] The normalized values ​​above are arranged in a predetermined field order to form a seven-dimensional vector, which is the task tensor: ; in, Number of processor cores requested for the task Divide by the maximum number of cores configured on the platform ,Right now: ; , , , These are the graphics processor memory and video memory. Response delay runtime and priority The result is normalized using the maximum value set by the platform. and The value is a boolean (0 or 1), which indicates whether the task supports breakpoint migration and whether execution on edge nodes is allowed, respectively.

[0021] This tensor is automatically generated by the scheduling system during the task registration process. The first five fields of the tensor are normalized continuous variables, and the last two are binary flags. This tensor, as a description of the task's scheduling structure, will participate in the calculation during the matching process.

[0022] Meanwhile, the platform periodically collects the operational status of each computing node through its deployed resource monitoring subsystem. This data comes from two levels: firstly, a lightweight collection agent is deployed locally on each node, sending the current system resource status to the central controller every 10 seconds via a message bus; secondly, the central controller also comprehensively evaluates node load and availability time windows by polling the operational logs and system status snapshots of all nodes every minute. Specifically, the data collected in the node status includes the current number of remaining CPU cores, remaining video memory capacity, average response latency within a historical window (e.g., the average response time of all tasks in the past 5 minutes), the predicted maximum continuous availability time window (calculated based on the current task queue), the system's configured scheduling priority (higher priority indicates a greater tendency to accept new tasks), whether breakpoint recovery is supported, and whether it is an edge node. After the central scheduling system performs a unified data regularization on this data, the generated structure is as follows: ; The meanings of each field are completely consistent with the meanings of the corresponding fields in the task tensor, and the normalization methods are the same. Indicates the first Number of remaining CPU cores per node With the maximum value The ratio of the given values ​​is calculated similarly for the other dimensions.

[0023] For a specific example: A task requires an 8-core CPU, 4GB of VRAM, a maximum tolerable latency of 200 milliseconds, an estimated runtime of 300 seconds, a priority of 4, allows breakpoint migration, but does not allow edge deployment; the platform configuration is a maximum of 64 cores, a maximum of 32GB of VRAM, a maximum latency of 1000 milliseconds, a maximum runtime of 1000 seconds, and a priority level of 5. The task tensor is: ; A node currently has 16 CPU cores remaining, 8GB of VRAM, an average latency of 100 milliseconds, an idle window of 600 seconds, a priority of 3, supports breakpoints, and is an edge node. Then the tensor of this node is: ; This module's output includes: Task Tensor It is composed of normalized business request parameters and is assembled to represent the scheduling resource requirements of the task. The set of state tensors of all nodes in the current resource pool It is obtained by splicing together the normalized and unified structure of the data reported by the nodes in real time, and represents the scheduling capability status of the nodes.

[0024] The scheduling decision module is used to calculate the matching score of each node based on the task tensor and resource tensor set through a structured scoring function. The scoring function includes a weighted distance calculation of resource parameters and a conditional penalty term for interruption support and edge deployment, and selects the node with the smallest score as the target node. Specifically, this module constructs task tensors within the tensor construction module. and resource state tensor set Based on this, the initial task scheduling decision is made in a heterogeneous computing environment. This process is a key step in the system's "resource pooling scheduling" and a prerequisite for the subsequent breakpoint migration mechanism. Its core objective is to select the target node most suitable for the current task from a group of nodes with heterogeneous resource capabilities, considering a comprehensive evaluation of structural capabilities, operational status, and scheduling strategies. The design focus of this module is: how to map structurally unified tensor pairs into scheduling decision behaviors, and at the same time introduce scenario feature modeling items such as "breakpoint migration feasibility", "edge scheduling constraints" and "scheduling strategy priority" into the scheduling scoring mechanism, thereby forming a scheduling logic that is more structurally sensitive and business-aware than traditional resource allocation strategies.

[0025] To enable the scheduling platform to adapt to different scenarios, especially handling complex scheduling situations such as edge deployment and breakpoint migration, this invention designs a structured scoring function to calculate the matching distance between each node and the current task. The basic scoring function adopts a weighted distance metric model, but unlike traditional Euclidean distance, it introduces two special structural terms with constraint meanings into the scoring terms, which are used for: The degree to which modeling nodes accept breakpoint migration tasks; The ability to model the structural constraints of edge nodes; The scoring function takes the following form: ; in: This represents the first of the five normalized continuous fields in the task tensor. Each value corresponds to , , , , ; Indicates the first Fields corresponding to the dimensions in a node tensor; These are the platform's preset scheduling strategy weights, used to adjust the importance of each dimension; and These are the penalty coefficients, which control the degree to which the platform penalizes the lack of breakpoint support and insufficient edge capabilities; Indicates whether the node supports breakpoint recovery (0 or 1). Indicates whether it is an edge node (0 or 1); and It is the corresponding dimension in the task tensor, used as a conditional multiplier, so that these regularization terms are only activated when the task requires breakpoints or edge features.

[0026] The design of this formula reflects the uniqueness of this invention in the structural modeling of scheduling behavior: instead of treating breakpoints and edge deployments as scheduling "rules," they are used as structural regularization terms in the scoring function for computational guidance, thus possessing differentiability, tunability, and scalability. For example, if a task requires breakpoint support ( ), while a certain node does not support ( If ), then the node will be added. The penalty; if a task does not require breakpoint support ( If the value is zero, then that item will automatically become 0. The same principle applies to edge scheduling fields. .

[0027] In practical implementation, the platform generally will Set to: (Number of cores) (Video memory) (Delay), (Running time) (Priority), the sum is 1. and The default setting is between 1.5 and 3.0, and it can be dynamically set according to business stability requirements and hardware support.

[0028] The scheduling platform evaluates all scoring items. After calculation, the node with the smallest score is selected. This is the target node for this round of scheduling: ; This node will be marked as the task's execution target by the platform and written into the scheduling record for subsequent migration judgment. It should be noted that if multiple... For candidate nodes with the same value, the platform will prioritize them according to node priority. Sort the data and select the ones with higher priority; if they are still the same, use a round-robin mechanism to achieve load balancing.

[0029] The breakpoint state generation module is used to monitor the processor utilization, memory utilization, load change rate and resource jitter of nodes during task execution. It combines the scheduling score with the interruption judgment function to determine whether to generate a breakpoint state. When an interruption is determined, a breakpoint state tensor is generated, which includes the running time, model intermediate state, data processing progress and resource usage estimate. Specifically, this module aims to construct the state structure for interrupt recovery during the execution of scheduled tasks. This enables "structured breakpoint migration capability" during task execution within a heterogeneous computing resource pool. The uniqueness of this mechanism lies in the fact that it is not a general container snapshot mechanism, but rather relies on the task tensor generated by the first two modules. Target node tensor and scheduling score A method for determining and generating breakpoint states that is deeply integrated with scheduling logic and is structure-aware is constructed. This mechanism not only provides the basic conditions for cross-node task recovery in subsequent modules, but is also a key supporting technology for achieving "uninterrupted migration execution in pooled resources" in this solution.

[0030] The first key mechanism in this module is to design a dynamic interrupt determination function based on the aforementioned variables. This is used to control whether to generate breakpoint states. Considering that large model inference tasks, conference streaming tasks, and other services are highly sensitive to resource stability, and that traditional threshold judgments are difficult to capture the potential risks of scheduling structures, this solution introduces a structural risk adjustment factor. Scheduling score Incorporate interrupt detection logic and design the following function: ; in, Risk-sensitive weights are set for the platform to control the impact of various resource indicators. It is the interrupt threshold set by the system; This is from the "whether breakpoint migration is supported" field in the task tensor, used to ensure that tasks that do not support breakpoints will not accidentally trigger this mechanism. The core innovation lies in the structural risk adjustment factor. The definition, it is related to scheduling score The following relationship exists: ; This item will be used for scheduling scoring. This is mapped to a risk amplifier in the interrupt mechanism, making it easier for nodes with poor scores to trigger breakpoint save operations during operation, thereby avoiding the hidden danger of "initial scheduling instability" in advance, reflecting the structural binding between scoring logic and interrupt logic. This is the maximum score of all tasks in the current scheduling cycle of the system, used for normalization; It is an adjustable coefficient used to control the intensity of risk response.

[0031] when When the interrupt triggering conditions are met, the system will extract the key execution state of the current task and construct a breakpoint state tensor through the heterogeneous container runtime interface without interrupting the current process of the task. Its structure is as follows: ; in: This indicates the length of time the current task has been running, recorded by the task container runtime interface; The model state information representing the current task, such as the intermediate layer cache of a neural network, is provided by the model execution framework (such as an inference engine based on ONNX). This indicates the progress position of the data stream, such as the number of frames processed and the data segment number, and is returned by the application layer processing module of the task. This represents the current estimated resource usage, used to quantify the computing resources consumed by this task so far. The calculation method is as follows: ; This value reflects the correlation between task resource consumption and the breakpoint, facilitating resource compensation assessment during subsequent migration.

[0032] This state tensor The task status will be stored in the platform's task status database, and its metadata will be recorded in the task scheduling controller as input for subsequent task migration and rescheduling.

[0033] The entire breakpoint generation mechanism is characterized by the introduction of "scheduling structure scoring" into the "interruption risk assessment" process for the first time, and the use of a well-designed risk adjustment factor. By coupling scoring information with node running states, the system gains structure-aware interruption detection capabilities. Simultaneously, the breakpoint state tensor incorporates... This indicates the coupling state between resource consumption and time location, allowing the state to not only be recovered but also used for subsequent migration cost assessment.

[0034] The rescheduling and recovery module is used to perform compatibility screening of available nodes based on the breakpoint state tensor when an interruption occurs. The screening conditions include that the node supports breakpoint recovery, the available time window is greater than the remaining estimated duration of the task, and the available resources are greater than the estimated resource usage value. Then, the node with the highest priority is selected as the recovery target node, and the task execution is resumed using the breakpoint state tensor.

[0035] Specifically, the core task of this module is to handle tasks that are interrupted during execution and for which breakpoints have been generated. Under the premise of this, the task is migrated to another compatible node in the resource pool, and based on Complete state reconstruction and task resumption execution. Unlike the initial scheduling phase, which focuses on the matching and evaluation of tasks and resources, this module emphasizes how to use existing structural states to complete task recovery, especially in the context of ensuring task continuity and high availability of resource pools, providing a stable, fast, and low-cost breakpoint recovery mechanism.

[0036] The system detected Then, the recovery scheduling process immediately begins. At this point, the original scoring calculation and resource matching strategy modeling (already completed in Module 2) are no longer performed; instead, a new process based on... The status information in the current set of available nodes Perform compatibility screening. Compatible nodes must meet the following three conditions: node Breakpoint recovery functionality must be supported (i.e.) ); The currently available running window of a node should be greater than This refers to the remaining estimated duration of the task. The number of processor cores and video memory available on a node should meet the minimum resources required for breakpoint recovery. .

[0037] The platform checks the tensors of each node in sequence. And use the following recovery feasibility determination function for filtering: ; in, For the available time window of the node, This represents the number of cores and the percentage of GPU memory currently available for the node. Indicates an indicator function. When At that time, node It has been determined that it can be used for breakpoint recovery.

[0038] Once the platform finds what satisfies From the candidate nodes, the system will select the one with the highest priority. The largest one is used as the target node for recovery, denoted as . Then the actual recovery execution process begins.

[0039] The resumption process is as follows: use The model state stored in the middleware is restored through the intermediate layer recovery interface of the underlying inference framework (such as the ONNXRuntime state restoration API), and the model is loaded into the new node. according to The system records the processing position (such as the number of completed frames, data segment number, etc.), retrieves the remaining data from the platform's distributed task input cache system, and reconstructs the task input queue. Initialize the resource scheduling controller and allocate no less than [number] resources to this task. The shortest possible resource retention period ensures that tasks can be successfully completed. Restart the task execution on the new node and set a success flag for the recovery. .

[0040] For example: If a task has been executed for a certain period of time... (The original planned duration of the task was normalized to) ), resource usage (This indicates that the task has used 0.2 times the number of cores × time + the amount of video memory × time), and the output state of the third layer of the model has been saved. And the position of processing up to frame 20. The platform discovers nodes in the resource pool. satisfy: (Supports breakpoints); ; ; Then the node is selected as Platform call In the mid-state reconstruction model, the task is reconstructed by locating the 20th frame data segment and resuming execution. After the task is resumed, it is marked as a successful breakpoint migration.

[0041] This invention also provides a heterogeneous computing resource pooling scheduling device, including 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 the modules as described in the above-described heterogeneous computing resource pooling scheduling platform embodiment; or, when the processor executes the computer program, it implements the functions of each module in the above-described system embodiments.

[0042] For example, 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 can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program in the heterogeneous computing power resource pooling scheduling device.

[0043] The heterogeneous computing resource pooling and scheduling device can be a desktop computer, laptop, handheld computer, or cloud server, among other computing devices. This device may include, but is not limited to, processors and memory. Those skilled in the art will understand that the heterogeneous computing resource pooling and scheduling device may also include input / output devices, network access devices, buses, etc.

[0044] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASACs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. This processor is the control center of the heterogeneous computing resource pooling and scheduling device, connecting various parts of the device via various interfaces and lines.

[0045] The memory can be used to store the computer programs and / or modules. The processor implements various functions of the heterogeneous computing resource pooling scheduling device by running or executing the computer programs and / or modules stored in the memory and calling the data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function, etc.; the data storage area may store data created based on the operation of the air conditioner controller, etc. In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0046] If the modules integrated in the heterogeneous computing power resource pooling scheduling device are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above embodiments 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 modules 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.

[0047] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0048] 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 heterogeneous computing power resource pooling and scheduling platform, characterized in that, The platform includes: The tensor construction module is used to extract key fields, including the number of processor cores, video memory capacity, response latency, runtime, priority, interrupt support flag, and edge deployment flag, from task requests from the business system, and form task tensors through normalization processing based on the maximum values ​​configured on the platform; at the same time, the resource monitoring subsystem periodically collects status data of computing nodes, including the number of remaining CPU cores, remaining video memory capacity, average response latency, available time window, scheduling priority, breakpoint support flag, and edge node flag, and forms resource tensors through normalization processing. The scheduling decision module is used to calculate the matching score of each node based on the task tensor and resource tensor set through a structured scoring function. The scoring function includes a weighted distance calculation of resource parameters and a conditional penalty term for interruption support and edge deployment, and selects the node with the smallest score as the target node. The breakpoint state generation module is used to monitor the processor utilization, memory utilization, load change rate and resource jitter of nodes during task execution. It combines the scheduling score with the interruption judgment function to determine whether to generate a breakpoint state. When an interruption is determined, a breakpoint state tensor is generated, which includes the running time, model intermediate state, data processing progress and resource usage estimate. The rescheduling and recovery module is used to perform compatibility screening of available nodes based on the breakpoint state tensor when an interruption occurs. The screening conditions include that the node supports breakpoint recovery, the available time window is greater than the remaining estimated duration of the task, and the available resources are greater than the estimated resource usage value. Then, the node with the highest priority is selected as the recovery target node, and the task execution is resumed using the breakpoint state tensor.

2. The heterogeneous computing power resource pooling scheduling platform according to claim 1, characterized in that, The normalization process of the tensor construction module includes dividing the number of processor cores by the maximum number of schedulable cores configured on the platform, dividing the video memory capacity by the maximum video memory capacity configured on the platform, dividing the maximum response latency by the maximum response latency configured on the platform, dividing the expected running time by the longest running time configured on the platform, and dividing the task priority by the highest priority level configured on the platform.

3. The heterogeneous computing power resource pooling scheduling platform according to claim 1, characterized in that, The resource monitoring subsystem of the tensor construction module adopts a two-level acquisition mechanism, including a lightweight acquisition agent deployed locally on the node and a central controller. The acquisition agent periodically collects node status data and sends it to the central controller through a message bus. The central controller comprehensively evaluates the node load and available time window by polling the node operation logs and system status snapshots.

4. The heterogeneous computing power resource pooling scheduling platform according to claim 1, characterized in that, The structured scoring function of the scheduling decision module includes calculating the weighted squared difference of the first five consecutive fields of the task tensor and the resource tensor, adding a first penalty term to nodes that do not support breakpoint recovery when the task supports interruption recovery, and adding a second penalty term to non-edge nodes when the task allows edge node deployment.

5. The heterogeneous computing power resource pooling scheduling platform according to claim 4, characterized in that, The weights in the weighted squared difference calculation include processor core count weight, video memory capacity weight, response latency weight, runtime weight, and priority weight, and the sum of the weights is 1.

6. The heterogeneous computing power resource pooling scheduling platform according to claim 1, characterized in that, When multiple candidate nodes with the same matching score exist, the scheduling decision module sorts them according to node priority and selects the node with higher priority as the target node; if the node priorities are still the same, a round-robin mechanism is used to achieve load balancing.

7. The heterogeneous computing power resource pooling scheduling platform according to claim 1, characterized in that, The interrupt determination function of the breakpoint state generation module is based on the weighted sum of processor utilization, video memory utilization, node load change rate and resource jitter, combined with a structural risk adjustment factor, which is calculated based on the ratio of the scheduling score to the maximum score of all tasks in the current scheduling cycle.

8. The heterogeneous computing power resource pooling scheduling platform according to claim 1, characterized in that, The estimated resource usage in the breakpoint state tensor generated by the breakpoint state generation module is calculated by multiplying the normalized processor core count by the running time and the normalized video memory capacity by the running time.

9. The heterogeneous computing power resource pooling scheduling platform according to claim 1, characterized in that, The compatibility screening of the rescheduling and recovery module includes using a recovery feasibility determination function to check whether the node supports breakpoint recovery, whether the node's available time window is greater than the remaining estimated duration of the task, and whether the sum of the node's available processor cores and video memory capacity is greater than the estimated resource usage value.

10. The heterogeneous computing power resource pooling scheduling platform according to claim 1, characterized in that, The recovery task execution of the rescheduling and recovery module includes loading the intermediate state of the model to the new node through the intermediate layer recovery interface of the underlying inference framework, obtaining the remaining data from the distributed task input cache system according to the data processing progress and rebuilding the input queue, initializing the resource scheduling controller to allocate resource retention period for the task, and restarting task execution on the new node.

Images