A method and device for predictive resource orchestration for heterogeneous loads

Abstract

The application provides a kind of predictive resource arrangement method and device for heterogeneous load, it is related to the technical field of data processing, method includes: by the workload characteristics of computing node and underlying resource state are layered collection, construct layered time series data, and establish resource demand prediction model based on periodic index, burst load mode and long tail load characteristics, combined with layered global scheduler node level load allocation, container grouping strategy and power consumption mode selection are jointly optimized, while using node local real-time resource state executes node local execution nature check and key state information incremental feedback, to realize large-scale cluster predictive resource arrangement and dynamic collaborative scheduling for heterogeneous load.The application can be aimed at the situation that the resource state information on which decision maker relies is outdated due to delay in large-scale cluster, improve the stability of overall resource arrangement.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and specifically to a predictive resource orchestration method and apparatus for heterogeneous loads. Background Technology

[0002] With the rapid development of cloud computing, edge computing, and artificial intelligence training and real-time inference technologies, data centers and cloud platforms need to simultaneously support various heterogeneous workloads, including AI training tasks, real-time inference tasks, data analysis tasks, and online service tasks. Since different workloads have significantly different resource requirements in terms of CPU, memory, GPU, I / O, and network bandwidth, existing technologies typically employ a centralized resource scheduling framework. This framework collects the resource status and task execution status of computing nodes, combines resource prediction models with scheduling algorithms, and uniformly orchestrates container instances, virtual machine instances, and physical nodes to improve cluster resource utilization and reduce system energy consumption. Simultaneously, some existing solutions also introduce machine learning-based resource demand prediction mechanisms and reinforcement learning-based scheduling optimization mechanisms to enhance dynamic scheduling capabilities in complex heterogeneous environments.

[0003] However, in large-scale heterogeneous cluster environments, existing technologies often exhibit strong temporal coupling between load scheduling, container scaling, and node power mode adjustment. The node resource status used by the scheduler to generate scheduling results is prone to update delays compared to the actual execution status. When container scaling is not yet complete, power mode switching has not taken effect, or the node's local resource status has not been synchronized to the central scheduler, subsequent scheduling processes may still generate new load allocation results based on outdated states. This can lead to nodes being incorrectly identified as idle, container resources being repeatedly allocated, or power modes not matching the actual load. Especially in scenarios with high-density GPU nodes, frequent sudden load changes, and mixed deployments of various heterogeneous hardware types, these temporal coupling problems can further amplify prediction errors and scheduling deviations, causing local resource congestion, increased task execution latency, abnormally high energy consumption, and decreased cluster resource utilization, thereby reducing the overall stability of the computer cluster's computing resource orchestration. Summary of the Invention

[0004] This invention provides a predictive resource orchestration method and apparatus for heterogeneous loads, which can improve the stability of the overall computing resource orchestration of computer clusters, addressing the issue that latency in large-scale clusters causes the resource status information relied upon by the decision-maker to become outdated.

[0005] In a first aspect, the present invention provides a predictive resource orchestration method for heterogeneous loads, the method comprising: The workload characteristics and underlying resource status of computing nodes are collected and aggregated in layers. Dynamic indicators are compressed and statistically analyzed locally on the nodes, while static indicators are uploaded to the central time series database to form layered time series data. Based on the hierarchical time series data, periodic indicators, burst load patterns, and long-tail load characteristics are extracted to construct a resource demand prediction model and output the prediction results. The prediction results are input into the hierarchical global scheduler, which splits the scheduling problem into two layers: macro scheduling and micro scheduling. The macro scheduling results are corrected by combining real-time status feedback. The macro scheduler performs node-level load allocation, container grouping strategy and power mode selection, while the micro scheduler performs load migration, container scaling and power mode switching locally on the node. In the hierarchical global scheduler, scheduling instructions are generated through joint optimization based on service performance, cluster resource utilization, energy consumption, and load balancing among heterogeneous hardware. The scheduling instructions are sent to each node, and the nodes monitor the resource status and task execution status locally in real time, and incrementally report key status information to the macro scheduler.

[0006] In a second aspect of the invention, a predictive resource orchestration apparatus for heterogeneous loads is provided. The apparatus is used to execute a predictive resource orchestration method for heterogeneous loads as described in any of the preceding embodiments. The apparatus includes an acquisition module, a processing module, and an output module, wherein: The acquisition module is used to perform hierarchical collection and aggregation of the workload characteristics and underlying resource status of computing nodes, compress and statistically analyze dynamic indicators locally on the nodes, and upload static indicators to the central time series database to form hierarchical time series data. The processing module is used to extract periodic indicators, burst load patterns and long-tail load characteristics based on the hierarchical time series data, construct a resource demand prediction model and output the prediction results. The processing module is used to input the prediction results into the hierarchical global scheduler, split the scheduling problem into two layers: macro scheduling and micro scheduling, and correct the macro scheduling results by combining real-time status feedback. The macro scheduler performs node-level load allocation, container grouping strategy and power mode selection, while the micro scheduler performs load migration, container scaling and power mode switching on the node. The processing module is used to perform joint optimization and generate scheduling instructions in the hierarchical global scheduler based on service performance, cluster resource utilization, energy consumption and load balancing among heterogeneous hardware. The output module is used to send the scheduling instructions to each node, and the nodes monitor the resource status and task execution status locally in real time, and incrementally report key status information to the macro scheduler.

[0007] A third aspect of the invention provides an electronic device including a processor and a memory, the memory having a stored computer program, wherein the computer program, when executed by the processor, implements a predictive resource orchestration method for heterogeneous workloads as described in any of the preceding claims.

[0008] In a fourth aspect, the present invention provides a non-transitory computer-readable storage medium storing instructions that, when executed, perform a predictive resource orchestration method for heterogeneous workloads as described in any of the preceding claims.

[0009] In summary, one or more technical solutions provided in the embodiments of the present invention have at least the following technical effects or advantages: This invention constructs hierarchical time-series data, a resource demand prediction model, and a hierarchical global scheduler. This allows the macro-scheduler to move beyond relying solely on the central resource status at a single moment to generate scheduling results. Instead, it combines periodic indicators, burst load characteristics, and long-tail load characteristics to predict future resource demand changes in advance. Furthermore, a micro-scheduler is introduced locally on each node to perform local execution verification of the macro-scheduling results. This allows for dynamic correction of resource capacity, container operating conditions, and power mode switching conditions based on real-time local resource status before actual load migration, container scaling, and power mode switching. Simultaneously, an incremental reporting mechanism for key status information continuously updates the global scheduling status table and the joint optimization status set. This enables the macro-scheduler to promptly perceive the completion status of container scaling, power mode switching, and real-time changes in node resources. This reduces resource status stagnation caused by status update delays, execution delays, and timing coupling, preventing nodes from being incorrectly identified as idle nodes, resource duplication, and power mode mismatches with actual loads. Ultimately, this improves the stability, scheduling accuracy, and resource coordination consistency of overall resource orchestration in large-scale heterogeneous cluster environments. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating a predictive resource orchestration method for heterogeneous loads disclosed in an embodiment of the present invention. Figure 2 This is a schematic diagram of a global scheduling status table disclosed in an embodiment of the present invention; Figure 3 This is a schematic diagram of a node local verification status table disclosed in an embodiment of the present invention; Figure 4 This is a schematic diagram of a predictive resource orchestration device for heterogeneous loads disclosed in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of the present invention.

[0011] Explanation of reference numerals in the attached drawings: 401, acquisition module; 402, processing module; 403, output module; 501, processor; 502, communication bus; 503, user interface; 504, network interface; 505, memory. Detailed Implementation

[0012] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0013] In the description of the embodiments of the present invention, words such as "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "for example" or "for instance" in the embodiments of the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Rather, the use of words such as "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0014] In the description of the embodiments of the present invention, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0015] While existing data center and cloud platform resource orchestration technologies can achieve dynamic scheduling of heterogeneous workloads by combining resource status monitoring, resource demand prediction, and intelligent scheduling algorithms, there is a strong temporal coupling relationship between load scheduling, container scaling, and node power consumption mode adjustment in large-scale heterogeneous cluster environments. This can easily lead to problems such as duplicate resource allocation, local node congestion, increased task execution delays, and abnormally high energy consumption due to delays in status update, power consumption mode switching, and container scaling execution. This reduces the overall stability and scheduling accuracy of resource orchestration.

[0016] This invention discloses a predictive resource orchestration method for heterogeneous loads, which is applied to a server. The server includes, but is not limited to, electronic devices such as mobile phones, tablets, wearable devices, and PCs (Personal Computers), and can also be a backend server running a predictive resource orchestration method for heterogeneous loads. The server can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0017] This embodiment discloses a predictive resource orchestration method for heterogeneous loads, referring to... Figure 1 It includes the following steps: S110 performs hierarchical collection and aggregation of workload characteristics and underlying resource status of computing nodes, compresses and statistically analyzes dynamic indicators locally on the nodes, and uploads static indicators to the central time series database to form hierarchical time series data.

[0018] S120 extracts periodic indicators, burst load patterns, and long-tail load characteristics from hierarchical time series data, constructs a resource demand forecasting model, and outputs the forecast results.

[0019] S130 inputs the prediction results into the hierarchical global scheduler, splits the scheduling problem into two layers: macro scheduling and micro scheduling, and corrects the macro scheduling results by combining real-time status feedback.

[0020] S140, in the hierarchical global scheduler, performs joint optimization to generate scheduling instructions based on service performance, cluster resource utilization, energy consumption, and load balancing among heterogeneous hardware.

[0021] S150 sends scheduling instructions to each node, and the nodes monitor the resource status and task execution status locally in real time, and incrementally report key status information to the macro scheduler.

[0022] In large-scale heterogeneous cluster environments, resource scheduling systems typically need to simultaneously control multiple scheduling actions, including load scheduling, container scaling, and node power mode adjustment. Load scheduling determines which compute node a workload should be deployed to; container scaling adjusts the number of container instances to meet changing resource demands; and node power mode adjustment switches between high-performance, balanced, and energy-saving modes to reduce overall energy consumption. Although these three scheduling actions logically correspond to resource allocation, resource supply, and energy control, respectively, there are clear temporal dependencies between them during actual execution.

[0023] For example, when generating load scheduling results, the scheduler needs to determine whether a node still has available resources based on the current CPU utilization, GPU utilization, memory utilization, and the number of container instances. Container scaling operations themselves involve processes such as image pulling, runtime initialization, GPU resource binding, network configuration, and service registration. Therefore, there is usually a significant delay between the issuance of the scaling command and the actual availability of the new container instances. During this delay, the central scheduler may have already determined that the compute node still has idle resources based on the old state and continue to allocate new workloads to that node, causing the node's actual resource usage to exceed its capacity. This ultimately leads to insufficient GPU memory, increased task queuing time, or abnormal latency in real-time inference tasks.

[0024] Similarly, node power mode switching also has a significant delay in taking effect. For example, when a compute node switches from power-saving mode to high-performance mode, it needs to go through a process of frequency increase, power supply strategy adjustment, and hardware stabilization. Before the power mode switch is truly complete, the scheduler may have already allocated the load according to the theoretical processing capacity of high-performance mode. However, because the node is still operating at a low frequency, the actual resource processing capacity cannot reach the expected level, leading to a decrease in AI training task throughput, timeouts in real-time inference task responses, or network I / O congestion. Conversely, if the scheduler performs a power-saving mode switch prematurely while the node is still carrying high-priority tasks, it may also cause a sudden performance drop during task execution.

[0025] The aforementioned problems are further amplified in high-density GPU node and heterogeneous hardware hybrid cluster environments. Due to the significant differences in resource characteristics among GPU nodes, CPU nodes, hybrid acceleration nodes, and storage-intensive nodes, different types of workloads have varying sensitivities to resources. For example, AI training tasks rely more heavily on GPU memory and network bandwidth, while data analysis tasks rely more on I / O and memory resources. When there is a delay in synchronizing the state of a certain type of resource, the scheduler may fail to accurately perceive the true available capacity of heterogeneous hardware, resulting in some GPU nodes being continuously assigned high-load tasks while other nodes remain idle for extended periods, creating a situation where local resource congestion and global resource waste coexist.

[0026] Furthermore, in short-term burst load scenarios, the aforementioned timing coupling issues can lead to a continuous accumulation of prediction errors. Because burst tasks rapidly change node resource states within a short period, and the central scheduler experiences acquisition, upload, and processing delays in obtaining state information, the scheduler's subsequent scheduling results often lag behind the actual state changes. When multiple scheduling cycles continuously execute resource allocation based on outdated states, erroneous scheduling accumulates, ultimately leading to problems such as node load aggregation, frequent container migration, repeated switching of power consumption modes, and service performance fluctuations, reducing overall system performance, resource utilization, and scheduling stability.

[0027] In practice, a local data collection process is set up within each compute node. This process continuously reads the workload characteristics and underlying resource status of the current compute node. A compute node refers to a server node in a data center or cloud platform capable of hosting container instances, virtual machine instances, or task processes. This can include CPU nodes, GPU nodes, hybrid acceleration nodes, and storage-intensive nodes. Workload characteristics refer to data describing task runtime attributes and resource requirements, including task type, task priority, task submission time, estimated task runtime, number of container instances, task queuing status, historical resource consumption patterns, and service level constraints. Underlying resource status refers to the actual operating status of the current compute node's hardware and system resources, including CPU utilization, memory utilization, GPU utilization, GPU memory usage, I / O queue length, network bandwidth utilization, real-time node energy consumption, hardware health status, and current power consumption mode.

[0028] The node-local data collection process performs layered collection of workload characteristics and underlying resource status according to different sampling frequencies. For rapidly changing dynamic metrics, such as CPU utilization, GPU utilization, GPU memory usage, I / O queue length, network bandwidth utilization, task execution latency, and task queuing status, shorter sampling intervals are used. For slower-changing static or quasi-static metrics, longer sampling intervals or event-triggered methods are used, such as hardware model, node performance level, GPU type, available memory limit, network interface type, hardware health status, power consumption mode capabilities, and rack location. Layered collection means dividing different types of metrics into different collection levels based on metric change frequency, scheduling sensitivity, and transmission overhead, thereby avoiding the communication burden caused by uploading all metrics at a high frequency.

[0029] After collecting dynamic indicators, the local node acquisition process does not directly upload all raw dynamic indicators to the central time-series database. Instead, it performs sliding window statistics, outlier filtering, and feature compression on the dynamic indicators within the current computing node. Sliding window statistics refers to continuously summarizing dynamic indicators over a fixed-length time window, such as calculating the average, maximum, minimum, quantiles, slope of change, and fluctuation amplitude over several recent sampling periods. Outlier filtering removes outlier data caused by instantaneous sampling errors, equipment monitoring jitter, or network acquisition anomalies. Feature compression converts high-frequency raw sampling points into statistical features that reflect resource change trends, enabling subsequent prediction models and schedulers to express the resource status changes of the current computing node with less data.

[0030] When static metrics are uploaded to the central time-series database, they are bound to the current compute node identifier, collection timestamp, and node resource type. The central time-series database is a database system used to centrally store time-series data from multiple compute nodes. It organizes resource status data according to timestamps, compute node identifiers, and metric types, allowing resource demand forecasting models and the macro scheduler to query it. Because static metrics change less frequently, they do not need to be uploaded as frequently as dynamic metrics. Uploads can be triggered when compute nodes start up, hardware configurations change, hardware health status changes, or power consumption mode capabilities change, thus reducing the amount of invalid data transmission.

[0031] After completing the local compression and statistics of dynamic indicators at each node and the centralized uploading of static indicators, the two types of indicators are correlated according to a unified timestamp to form hierarchical time series data. Hierarchical time series data refers to a time series data structure that simultaneously includes local node dynamic statistical results and central-side static configuration results. Local node dynamic statistical results describe the resource change trends of computing nodes within continuous time slices, while central-side static configuration results describe the hardware capability boundaries and scheduling adaptation conditions of computing nodes. Through hierarchical time series data, subsequent resource demand prediction models can simultaneously identify short-term resource fluctuations, task execution trends, and differences in computing node hardware capabilities. The macro scheduler can also perform node-level load balancing, container grouping strategies, and power consumption mode selection based on hierarchical time series data.

[0032] In one possible implementation, a multi-dimensional resource demand prediction model is constructed and prediction results are output based on the extraction of periodic indicators, burst load patterns, and long-tail load features from hierarchical time series data. Specifically, this includes: performing sliding window statistics and feature compression on the dynamic indicators of each computing node locally, and combining them with static indicators to form global hierarchical time series data; performing periodic pattern analysis on the short-term historical sequences at the node level to extract periodic indicators of load fluctuation cycles and task submission peaks; performing mutation detection and anomaly identification for burst load patterns, and constructing an adaptive model based on the node's historical response capabilities to obtain burst load features; statistically analyzing the distribution of low-frequency consumption tasks for long-tail load features and extracting key features through quantile analysis or heavy-tailed distribution fitting; integrating the periodic indicators, burst load features, and long-tail load features into a multi-dimensional feature vector, inputting it into the resource demand prediction model, and generating prediction results using rolling window recursive prediction, meta-learning, and adaptive incremental learning.

[0033] Specifically, when performing sliding window statistics on the dynamic metrics of each computing node locally, the node's local data acquisition process continuously collects dynamic metrics such as CPU utilization, memory utilization, GPU utilization, GPU memory usage, I / O queue length, network bandwidth utilization, task execution latency, task queue length, node real-time energy consumption, and current power consumption mode at preset sampling intervals, and constructs a sliding window according to continuous time slices. A sliding window refers to a data segment that continuously moves along the time axis according to a fixed window length and a fixed sliding step size, used to preserve the short-term trend of dynamic metrics without uploading all original sampling points. For each computing node and each dynamic metric, the mean, maximum, minimum, quantiles, slope of change, fluctuation amplitude, and anomaly ratio are calculated within the current sliding window, transforming high-frequency original dynamic metrics into low-dimensional statistical features. Feature compression refers to compressing continuous high-frequency sampling points into statistical results that can describe resource change patterns. For example, hundreds of CPU utilization sampling points within a window can be compressed into mean, peak, fluctuation range, and slope of change. This reduces the pressure of state uploading in large-scale clusters and provides a unified data foundation for subsequent periodic pattern analysis, burst load identification, and long-tail load identification. The expression for sliding window statistics is:

[0034]

[0035] in, This indicates the k-th type of dynamic metric of the i-th computing node in the sliding window. The average statistical value within; This represents the k-th type of dynamic metric of the i-th computing node in time slice. The sampled values ​​at each location are determined based on the normalization results of the corresponding indicators; This represents a sliding window that ends with the current time slice t. The window length can be set to several consecutive sampling points according to the scheduling period. This represents the number of sampling points within the sliding window. This formula, by averaging the sampled values ​​of dynamic indicators within the same sliding window, reduces the impact of instantaneous fluctuations on resource status assessment, enabling subsequent prediction models to obtain more stable node-level resource change trends.

[0036] When combining static metrics to form global hierarchical time series data, locally generated dynamic statistical features are timestamped with static metrics such as hardware model, node performance level, GPU type, available video memory limit, network interface type, power consumption mode capability, hardware health status, and rack location. Static metrics describe the hardware capability boundaries and scheduling adaptation conditions of compute nodes and do not need to be repeatedly uploaded at high-frequency cycles; dynamic statistical features describe the resource change trends of compute nodes within continuous time slices and need to be updated with the scheduling cycle. The global hierarchical time series data consists of a node-local layer and a central global layer. The node-local layer retains dynamic statistical features, while the central global layer stores static metrics and key dynamic statistical features after incremental reporting. Through this hierarchical structure, the resource demand prediction model can obtain real-time resource changes for each compute node and identify heterogeneous hardware differences between different compute nodes, thereby avoiding predicting GPU nodes, CPU nodes, and storage-intensive nodes as having the same capabilities. The global hierarchical time series data can be represented as:

[0037]

[0038] in, This represents the global hierarchical time series data corresponding to the i-th computing node in time slice t; This represents the set of dynamic statistical features formed by the i-th computing node within the sliding window; This represents the set of static metrics for the i-th compute node, which is typically updated when the node configuration or hardware status changes. This represents the hardware health status of the i-th compute node at time slice t; This represents the task queue state of the i-th computing node in time slice t. This expression combines dynamic statistical features, static indicators, hardware health status, and task queue state into the same time slice, enabling subsequent resource demand prediction models to simultaneously handle time-varying features and hardware capability features under a unified data structure.

[0039] When performing periodic pattern analysis on node-level short-term historical sequences, the short-term historical sequence of each computing node within the most recent scheduling cycles is extracted from the global hierarchical time series data. Autocorrelation analysis and frequency domain analysis are then performed on periodic-sensitive indicators such as CPU utilization, GPU utilization, IO queue length, network bandwidth utilization, task submission quantity, and task execution latency. The node-level short-term historical sequence refers to a statistical sequence of node resource status arranged in chronological order, used to describe the recent load changes of the current computing node. Periodic pattern analysis is used to identify recurring resource fluctuations within fixed time intervals, such as daily business peaks, concentrated batch task submissions, fixed start times for AI training tasks, or periodic peaks in inference requests. The load fluctuation cycle describes the recurring time intervals of resource usage from rise, peak, decline, to recovery; the task submission peak period describes periods where the number of tasks arriving is significantly higher than in ordinary time slices. The extraction of periodic indicators can be determined by the autocorrelation strength, expressed as:

[0040]

[0041] in, This represents the periodicity of the i-th computing node under the lag interval l, with a value ranging from -1 to 1. The closer the value is to 1, the stronger the periodicity corresponding to the interval l. This represents the target resource utilization or number of tasks submitted by the i-th computing node in time slice t; This represents the average resource utilization or average number of task submissions for the i-th computing node within the analysis time range; T represents the total number of time slices participating in the periodic analysis; and l represents the candidate lag interval, which is an integer greater than 0 and less than T. This formula identifies whether load fluctuations repeat at fixed time intervals by comparing the similarity between the current resource state sequence and the lagged resource state sequence, thereby extracting periodic indicators such as load fluctuation cycles and peak task submission periods.

[0042] When performing mutation detection and anomaly identification for burst load patterns, adjacent sliding windows in the short-term historical sequence at the node level are used as comparison objects to calculate the changes in resource utilization, task queue length, task execution latency, container instance size, and network bandwidth. When the changes within a certain time slice significantly deviate from the historical stable range, that time slice is marked as a burst candidate time slice. A burst load pattern refers to a rapid increase in resource demand caused by a large number of tasks being submitted in a short period of time, a sharp increase in hot requests, a sudden surge in AI inference requests, or a sudden change in external business traffic. Anomaly identification refers to locating time points in the short-term historical sequence at the node level that are inconsistent with the normal load change pattern and distinguishing between ordinary fluctuations and burst loads. To avoid misjudgments caused by a single resource change, multiple dynamic indicators can be jointly scored for mutation, and an adaptive model can be built by combining the node's historical response capability. The node's historical response capability refers to the ability of a computing node to complete load migration, container expansion, power mode switching, and task queue recovery under historical burst scenarios, which can be characterized by historical recovery time, expansion success rate, migration failure rate, and power mode switching time. The expression for the burst load score is:

[0043]

[0044] in, This represents the burst load score of the i-th computing node in time slice t. The larger the value, the higher the probability of burst load. K represents the number of dynamic indicators involved in burst detection. This represents the burst sensitivity weight of the k-th type of dynamic indicator, with a value ranging from 0 to 1, and includes all indicators participating in the detection. The sum is 1; This represents the sampled value of the k-th type of dynamic index of the i-th computing node in time slice t; This represents the average statistical value of the k-th type of dynamic indicator within the previous sliding window; This indicates the degree of fluctuation of the k-th type of dynamic indicator within the previous sliding window; This represents a stability coefficient to prevent the denominator from being zero, and its value is a decimal greater than 0. This formula compares the deviation of the current dynamic indicator from the stability level of the previous sliding window and standardizes it using the degree of fluctuation, allowing changes in CPU, GPU, IO, and network bandwidth, which were originally measured at different scales, to be integrated into the same burst score.

[0045] When constructing an adaptive model based on a node's historical response capabilities, burst load scores, historical recovery times, historical expansion success rates, historical migration failure rates, power mode switching times, and hardware health status are combined to form burst load characteristics. The adaptive model is used to determine the recoverability and resource capacity of a current compute node facing burst loads, rather than simply determining whether a burst load has occurred. For compute nodes with short historical recovery times, high expansion success rates, and stable hardware health, even if a burst load is detected, they can be judged to have strong short-term adaptive capabilities. For compute nodes with long power mode switching times, insufficient GPU memory, or high historical migration failure rates, it is necessary to improve burst risk estimation. The expression for the adaptive capability score is:

[0046]

[0047] in, This represents the historical response capability score of the i-th computing node in time slice t. The larger the value, the stronger the adaptability of the current computing node to sudden load. This represents the average recovery time of the i-th computing node under historical emergency scenarios; Indicates the maximum historical recovery time included in the statistics; This represents the historical expansion success rate of the i-th computing node, with a value ranging from 0 to 1; This represents the historical migration failure rate of the i-th computing node, with a value ranging from 0 to 1; This represents the normalized score of the hardware health status of the i-th computing node, with a value ranging from 0 to 1; , , and These represent the response capability weights corresponding to recovery time, expansion success rate, migration failure rate, and hardware health status, respectively, with values ​​ranging from 0 to 1. ; This represents the stability coefficient. The formula maps recovery speed, expansion reliability, migration reliability, and hardware health into a response capability score, enabling burst load characteristics to reflect the current computing node's actual capacity to handle burst tasks.

[0048] When analyzing the distribution of low-frequency resource-intensive tasks based on long-tail load characteristics, tasks with low frequency but high resource consumption or long duration are identified by tracking task execution records over a long time span. Examples include large model training tasks, offline data analysis tasks, massive log processing tasks, batch model evaluation tasks, or cross-node distributed training tasks. Low-frequency resource-intensive tasks refer to workloads that account for a small percentage of the total tasks but have a sustained impact on GPU memory, network bandwidth, I / O queues, memory capacity, or node power consumption. Long-tail load characteristics are used to describe the long-term impact of these tasks on resource orchestration, preventing predictive models from underestimating resource requirements based solely on short-term average loads. Quantile analysis is used to statistically analyze resource consumption or task execution time within high quantile intervals, such as the 90th, 95th, or 99th quantiles, to characterize the upper-tail risk of low-frequency, high-consumption tasks. Heavy-tail distribution fitting is used to determine whether a few maxima dominate overall resource consumption in task execution time or resource consumption. Long-tail strength can be expressed as:

[0049]

[0050] in, This represents the long-tail load intensity of the i-th computing node. The larger the value, the stronger the continuous impact of low-frequency consuming tasks on the current computing node. This represents the p-th quantile of the task duration on the i-th computing node, where P ranges from 0.8 to 0.99. This represents the p-th quantile of the resource occupancy intensity on the i-th computing node; This indicates the frequency of low-frequency resource consumption tasks, with a value ranging from 0 to 1. This represents the normalized number of times low-frequency, resource-intensive tasks migrate across nodes, with a value ranging from 0 to 1. , , and These represent the long-tail weights corresponding to duration, resource consumption intensity, frequency of occurrence, and number of cross-node migrations, respectively, with values ​​ranging from 0 to 1. This formula integrates the tail of task duration, the tail of resource consumption, the frequency of low-frequency occurrences, and cross-node migration, enabling the long-tail load characteristics to reflect the continuous impact of a small number of high-consumption tasks on future resource availability.

[0051] When integrating periodic indicators, burst load characteristics, and long-tail load characteristics into a multi-dimensional feature vector, the various features are first normalized to map CPU utilization, GPU memory usage, task execution latency, burst load scores, node historical response capability scores, and long-tail load intensity from different value ranges to a unified numerical range. Then, the features are concatenated according to the computing node identifier, workload type, and target prediction time slice to form a multi-dimensional feature vector that the resource demand prediction model can directly process. This multi-dimensional feature vector not only includes the resource status of a specific time slice but also periodic changes, burst offsets, persistent long-tail occupancy, hardware capability boundaries, and task queue status. Therefore, it can simultaneously characterize different resource demand patterns for AI training tasks, real-time inference tasks, and data analysis tasks. The expression for the multi-dimensional feature vector is:

[0052]

[0053] in, This represents the multi-dimensional feature vector corresponding to the i-th computation node in time slice t; This represents a set of periodic indicators, including load fluctuation cycle, periodic intensity, peak task submission periods, and idle intervals. Indicates burst load score; This indicates the node's historical response capability score; Indicates the long-tail load strength; Represents a set of static indicators; Indicates the health status of the hardware; Indicates the status of the task queue; This represents the container instance state and power consumption mode state. This expression organizes features from different sources, time scales, and resource dimensions into a unified vector, enabling resource demand prediction models to learn periodic, bursty, and long-tailed resource demand changes within the same structure.

[0054] The resource demand prediction model employs a shared temporal coding network (PTC) structure, consisting of a multi-scale prediction branch and a multi-resource output layer. The PTC handles the temporal dependencies of multi-dimensional feature vectors across consecutive time slices and can utilize gated recurrent units (ROUs), long short-term memory (LSTM) networks, temporal convolutional networks (TCNNs), or lightweight Transformer coding structures. For large-scale cluster scenarios, to reduce training and inference overhead, a PTC combining a temporal convolutional network and a gated attention structure can be used. The temporal convolutional network extracts local temporal trends, while the gated attention structure adjusts the impact of different time slices based on task type, hardware health status, and burst load scores. The PTC outputs a shared load latent state, which uniformly represents the evolution of resource demand for the current computing node across multiple future time slices. The expression for the shared load latent state is:

[0055]

[0056] in, This represents the hidden state of the shared load of the i-th compute node in time slice t; The nonlinear mapping function representing a shared temporal coding network is composed of temporal convolution, gating units, and attention computation. to This represents the multi-dimensional feature vector of the i-th computing node in the most recent m time slices; This represents the length of the historical observation window, and its value is determined based on the scheduling cycle, load change frequency, and cluster size. This expression encodes continuous historical features, enabling the resource demand forecasting model to extract resource demand change trends from multiple past time slices, rather than making predictions solely based on the current time slice state.

[0057] The multi-scale prediction branches include a periodic prediction branch, a burst load prediction branch, and a long-tail load prediction branch. The periodic prediction branch receives the shared load latent state and a set of periodic indicators, and uses a rolling window recursive prediction method to output the regular resource requirements for multiple future time slices. This is used to predict the regularly changing CPU, GPU, memory, I / O, and network bandwidth requirements. Rolling window recursive prediction involves first predicting the resource requirements for the next time slice, and then using the prediction results as part of subsequent predictions, recursively generating prediction results for multiple future time slices. The burst load prediction branch receives the shared load latent state, burst load score, and node historical response capability score, and outputs the probability of burst load occurrence, burst resource increment, and burst recovery time, used to correct prediction biases caused by short-term abnormal growth. The long-tail load prediction branch receives the shared load latent state and long-tail load intensity, and outputs the continuous occupancy of long-tail tasks and the probability of long-tail task release, used to characterize the long-term impact of low-frequency consuming tasks on subsequent resource availability. The multi-resource output layer merges the results of the three prediction branches and outputs predicted values ​​for CPU demand, memory demand, GPU demand, GPU video memory demand, IO demand, network bandwidth demand, energy consumption, and task execution latency.

[0058] The multi-resource output layer can use a weighted fusion method to generate the final prediction result. During fusion, the contributions of different prediction branches are dynamically adjusted based on burst load scores and long-tail load intensity, ensuring that regular periodic prediction results do not mask the impact of burst loads and long-tail loads. The expression for the final prediction result is:

[0059]

[0060] in, This represents the final prediction result of the i-th computing node in the future time slice t+Δ, which includes multiple prediction dimensions such as CPU, memory, GPU, GPU video memory, IO, network bandwidth, energy consumption, and task execution latency. This represents the prediction step size, and its value is an integer greater than 0. This represents the regular resource demand forecast results output by the periodic forecast branch; This indicates the result of the burst resource demand correction output by the burst load prediction branch; This indicates the long-tail resource occupancy correction result output by the long-tail load prediction branch; , and These represent the fusion weights of the periodic forecasting branch, the burst load forecasting branch, and the long-tail load forecasting branch, respectively, with values ​​ranging from 0 to 1. This formula dynamically merges three prediction branches based on different load patterns, enabling the resource demand prediction model to output more robust prediction results even when regular cycles, sudden shocks, and long-tail occupancy coexist.

[0061] During the training of the resource demand prediction model, training samples are first constructed from historical stratified time-series data. Multi-dimensional feature vectors from consecutive historical time slices are used as training sample features, and actual observed CPU consumption, memory consumption, GPU consumption, GPU memory consumption, I / O consumption, network bandwidth consumption, energy consumption status, and task execution latency within multiple future time slices are used as supervision labels. To adapt to heterogeneous workload scenarios, training samples are categorized into AI training tasks, real-time inference tasks, data analysis tasks, and online service tasks, and further categorized into CPU nodes, GPU nodes, hybrid acceleration nodes, and storage-intensive nodes. This allows the model training process to learn the differences in resource demand between different workload types and different computing node types. For burst load samples, the burst start time, burst peak time, and burst recovery time are retained in the training set. For long-tail load samples, the duration of low-frequency consumption tasks and upper-lower-end information on resource usage are retained in the training set, enabling the model training process to explicitly learn the impact of burst loads and long-tail loads on future resource demands.

[0062] The training loss function consists of multi-step prediction error, burst load identification error, long-tail load occupancy error, service latency error, and multi-resource balancing constraint error. Multi-step prediction error constrains the difference between predicted resource demands and actual resource consumption over multiple future time slices; burst load identification error constrains the burst load prediction branch's ability to identify burst probability and burst resource increments; long-tail load occupancy error constrains the long-tail load prediction branch's ability to predict sustained occupancy and release probability; service latency error constrains the predicted task execution latency; and multi-resource balancing constraint error prevents the model from optimizing only a single resource dimension while neglecting other resource dimensions. The expression for the training loss function is:

[0063]

[0064] in, This represents the total training loss of the resource demand prediction model. This represents the multi-step prediction error, used to measure the difference between the predicted values ​​of multiple resources and the actual resource consumption over multiple future time slices; This represents the burst load identification error, used to measure the difference between the output of the burst load prediction branch and the actual burst label; This represents the long-tail load occupancy error, used to measure the difference between the output of the long-tail load prediction branch and the actual long-tail resource occupancy. This represents the service latency error, used to measure the difference between the predicted task execution latency and the actual task execution latency. This represents the multi-resource balance constraint error, used to constrain the coordination between the prediction results of resources such as CPU, memory, GPU, IO, and network bandwidth; , , , and These represent the training weights of each loss term, with values ​​ranging from 0 to 1. These weights can be adjusted based on the proportion of burst load samples, the proportion of long-tail load samples, and service latency sensitivity in the current training set. This formula incorporates numerical prediction, burst identification, long-tail occupancy, and service latency into the training objective, enabling the resource demand prediction model to learn not only the numerical values ​​of resource consumption but also the differences in load patterns behind changes in resource demand.

[0065] Multi-step prediction error can be calculated using weighted mean squared error, assigning high weights to key resource dimensions such as GPU memory, task execution latency, and network bandwidth to adapt to the sensitivity of AI training and real-time inference tasks to critical resources. The expression for multi-step prediction error is:

[0066]

[0067] in, The multi-step prediction error is represented by: N, the number of computation nodes involved in training, D, the number of prediction steps, and Q, the number of resource prediction dimensions. This represents the error weight of the q-th resource prediction dimension, with a value ranging from 0 to 1, and the error weights of all resource prediction dimensions are... The sum is 1; This indicates that the i-th computing node is in the future time slice t. The predicted value of the qth resource dimension; This represents the corresponding actual resource consumption value. The formula uses a weighted summation of prediction errors across multiple future time slices and multiple resource dimensions, allowing the training process to focus on resource dimensions that have a greater impact on scheduling.

[0068] Adaptive incremental learning is used to continuously update the resource demand prediction model during resource orchestration. Whenever the macro-scheduler receives critical status information, it writes the actual resource status, task execution status, load migration completion status, container scaling completion status, and power mode switching completion status into the incremental sample cache, and compares the deviation with the previously output prediction results. When the prediction deviation exceeds a preset deviation threshold for multiple consecutive scheduling cycles, or when new workloads, new GPU models, new power modes, or sudden load mode changes occur, recent samples are extracted from the incremental sample cache to perform small-step updates to the resource demand prediction model. To avoid new samples overwriting historical stable patterns, a small number of representative historical samples are retained during incremental learning, and stability constraints are applied to the model parameters, ensuring that the model can adapt to changes in the current cluster state while retaining the original periodic load patterns and long-tail load patterns. The parameter expression for incremental updates is:

[0069]

[0070] in, This represents the parameters of the resource demand forecasting model after the (r+1)th incremental update; This represents the parameters of the resource demand forecasting model before the r-th incremental update; This represents the learning rate for the r-th incremental update, and its value is a decimal greater than 0 and less than 1; This indicates that the gradient is calculated with respect to the model parameters; This represents the training loss calculated based on recent incremental samples; This represents the stability constraint coefficient, with a value ranging from 0 to 1; This indicates the degree of deviation of the current model parameters relative to the model parameters before the incremental update. This formula drives the model to adapt to new load patterns through recent incremental samples, while using parameter stability constraints to limit drastic changes in model parameters, reducing the risk of degradation of historical predictive ability caused by adaptive incremental learning.

[0071] Meta-learning is used to improve the rapid adaptability of resource demand prediction models to new workloads or tasks with few samples. During the training phase, different workload types, compute node types, and sudden scenarios are divided into multiple meta-tasks. Each meta-task includes a small number of support samples and query samples. Support samples are used to quickly update temporary model parameters, while query samples are used to evaluate the predictive performance of these temporary parameters on the same meta-task. Through repeated training, the resource demand prediction model learns a set of initial parameters that can quickly adapt to new load patterns. When new AI training tasks, new real-time inference tasks, or new data analysis tasks enter the cluster, only a small number of running samples are needed to quickly adjust the model and output prediction results that better meet the resource requirements of the new task. The expression for meta-learning updates is:

[0072]

[0073] in, This represents the temporary model parameters after rapid adaptation for the i-th meta-task; The general initial model parameters obtained from meta-learning are represented; This represents the learning rate updated within the metata task, and its value is a decimal greater than 0 and less than 1. This represents the training loss calculated on the support samples for the i-th meta-task. This formula, by performing one or more gradient updates on a small number of support samples, allows the model parameters to quickly adapt to the current new load pattern, thereby mitigating the prediction instability caused by insufficient samples of sudden loads and novel long-tail loads.

[0074] After training, the resource demand prediction model continuously receives a multi-dimensional feature vector during runtime, consisting of periodic indicators, burst load characteristics, long-tail load characteristics, static indicators, hardware health status, task queue status, container instance status, and power consumption mode status. It then outputs prediction results for multiple future time slices. These predictions include node-level and container-level resource demand predictions. Node-level predictions are used by the macro-scheduler for node-level load allocation, container grouping strategies, and power consumption mode selection. Container-level predictions are used by the micro-scheduler for local load migration, container scaling, and power consumption mode switching on nodes. The predictions also include the probability of burst load occurrence, the continuous occupancy of long-tail tasks, and predicted task execution latency. These are used in subsequent joint optimization to determine the constraints between service performance, cluster resource utilization, energy consumption, and load balancing across heterogeneous hardware. Through this structure and training process, the resource demand prediction model can transform periodic changes, short-term burst changes, and low-frequency, high-consumption changes in hierarchical time-series data into prediction results usable for scheduling decisions.

[0075] In one possible implementation, before extracting periodic indicators, burst load patterns, and long-tail load features from hierarchical time series data, constructing a resource demand prediction model, and outputting the prediction results, the method further includes: performing time alignment and window segmentation on the hierarchical time series data to generate node window samples corresponding to computing nodes; performing periodic feature construction on the node window samples to form a periodic resource demand representation, performing burst load feature construction to form a burst load representation, and performing long-tail load feature construction to form a long-tail load representation; concatenating the periodic resource demand representation, burst load representation, and long-tail load representation to construct a resource demand feature vector; constructing a resource demand prediction model based on the resource demand feature vector, wherein the resource demand prediction model includes a shared time-series coding network, a periodic prediction branch, a burst load prediction branch, a long-tail load prediction branch, and a multi-resource output layer; training the resource demand prediction model using historical hierarchical time series data, and optimizing the model parameters by combining prediction error and multi-resource balance constraint error.

[0076] Specifically, when performing time alignment on hierarchical time series data, dynamic statistical features, static metrics, hardware health status, task queue status, container instance status, and power consumption mode status from different compute nodes, sampling frequencies, and data sources are mapped to a unified scheduling time axis. Dynamic statistical features typically have a high sampling frequency, and static metrics are usually updated when node configurations or hardware statuses change. Directly mixing these can easily lead to inconsistencies between resource and task states within the same time slice. Therefore, it is necessary to establish a time slice index according to a unified scheduling cycle, aggregate dynamic statistical features falling within the same time slice, and bind the most recent valid static metric to the corresponding time slice. This ensures that subsequent periodic feature construction, burst load feature construction, and long-tail load feature construction are all based on a consistent time benchmark. The node state expression after time alignment is:

[0077]

[0078] in, This represents the node state of the i-th computing node within the t-th unified scheduling time slice; This represents the dynamic statistical characteristics of the i-th computing node within the t-th unified scheduling time slice, including CPU utilization, memory utilization, GPU utilization, GPU memory usage, IO queue length, network bandwidth utilization, and real-time energy consumption of the node. This represents the static metrics bound to the i-th compute node within the t-th unified scheduling time slice, including hardware model, node performance level, GPU type, available video memory limit, and network interface type; This represents the hardware health status of the i-th computing node during the t-th unified scheduling time slice; This represents the task queue state of the i-th computing node within the t-th unified scheduling time slice; This represents the container instance state of the i-th compute node within the t-th unified scheduling time slice; This represents the power consumption pattern state of the i-th computing node within the t-th unified scheduling time slice. This expression organizes data from different sources into the same node state through unified scheduling time slices, enabling resource demand prediction models to learn resource change relationships based on time-consistent data.

[0079] Window segmentation, after time alignment, divides the continuous node states of each compute node according to the historical observation window length and prediction step size, generating node window samples corresponding to each compute node. A node window sample is a sample segment consisting of the node states of a compute node over several consecutive uniformly scheduled time slices, used to describe the resource changes, task changes, and power consumption pattern changes of that compute node over a period of time. The historical observation window length determines the time range of historical states the model can observe, and the prediction step size determines how many future time slices the model needs to predict resource requirements. During window segmentation, samples are generated separately for each compute node to avoid confusion caused by hardware differences and task distribution differences between different compute nodes. The expression for a node window sample is:

[0080]

[0081] in, This represents the node window sample corresponding to the i-th computing node in the t-th unified scheduling time slice; to This expression represents the continuous node state of the i-th computing node within the most recent m unified scheduling time slices; m represents the length of the historical observation window, which is an integer greater than 1 and is determined based on the scheduling cycle, workload fluctuation rate, and training sample coverage. By preserving the node state changes within continuous time slices, this expression enables subsequent models to identify periodic changes, sudden changes, and long-tail persistent occupancy changes from the node window samples.

[0082] When constructing periodic features for node window samples, a repetitive analysis is performed on metrics such as CPU utilization, GPU utilization, IO queue length, network bandwidth utilization, task submission quantity, and task execution latency to extract load fluctuation cycles, periodic intensity, peak task submission periods, resource usage troughs, and idle intervals. Periodic resource demand characterization describes recurring resource demand changes within fixed time intervals, such as AI training tasks starting in concentrated periods, data analysis tasks being executed in batches at night, or real-time inference requests increasing concentratedly during peak business periods. Periodic intensity can be determined using autocorrelation. The expression for periodic resource demand characterization is:

[0083]

[0084] in, This represents the periodic resource demand of the i-th computing node in the t-th unified scheduling time slice; Indicates the optimal lag interval The corresponding periodic intensity ranges from -1 to 1, with the value being closer to 1 indicating stronger periodic repetition. This represents the load fluctuation period that maximizes the periodicity among the candidate hysteresis intervals. This represents the peak period of task submissions identified by the i-th computing node in the node window sample; This represents the idle interval identified by the i-th computing node in the node window sample. By simultaneously preserving the periodic intensity, periodic length, peak position, and idle position, this expression enables the characterization of periodic resource demand to reflect regular changes in resource occupancy.

[0085] When constructing burst load characteristics for node window samples, the resource status differences between the current unified scheduling time slice and the previous sliding statistical interval are compared, with a focus on detecting sudden increases in CPU utilization, GPU memory usage, I / O queue length, network bandwidth utilization, task queue length, and task execution latency. Burst load characterization describes rapid shifts in resource demand caused by concentrated task submissions, surges in inference requests, container startup impacts, or sudden increases in network traffic within a short period. To avoid misjudgments due to fluctuations in a single metric, the standardized changes of multiple dynamic metrics can be weighted and fused to obtain the burst load intensity, which is then combined with the node's historical response capabilities to form a burst load characterization. The expression for the burst load characterization is:

[0086]

[0087] in, This represents the burst load characterization of the i-th computing node in the t-th unified scheduling time slice; This indicates the intensity of sudden load; the larger the value, the higher the probability that the current computing node will experience a sudden load. This represents the node's historical response capability score, with a value ranging from 0 to 1. The higher the value, the stronger the current computing node's ability to recover from sudden loads. This indicates a candidate time slice for burst load, used to locate the start position of burst load; This represents the set of resource increments caused by a sudden load spike, including CPU increments, GPU increments, IO increments, network bandwidth increments, and task execution latency increments. By organizing the spike intensity, node resilience, spike start location, and resource increments together, this expression enables the spike load characterization to reflect the short-term impact of the spike load on subsequent scheduling.

[0088] When constructing long-tail load features for node window samples, the frequency, duration, upper tail quantile of resource consumption, upper tail quantile of task execution latency, and number of cross-node migrations of low-frequency consumption tasks are statistically analyzed in the node window samples and their associated historical data. Long-tail load characterization describes workloads that occur infrequently but last long, consume a lot of resources, or have uncertain release times, such as large model training tasks, offline data analysis tasks, batch model evaluation tasks, and cross-node distributed training tasks. When constructing long-tail load features, it is not only determined whether a task is high-consumption, but also whether the task will continue to consume GPU memory, I / O queues, network bandwidth, or node power resources in subsequent time slices. The expression for long-tail load characterization is:

[0089]

[0090] in, This represents the long-tail load characterization of the i-th computing node in the t-th unified scheduling time slice; The p-th quantile of the task duration is represented by the statistic, where p ranges from 0.8 to 0.99. This represents the p-th quantile statistical value of resource occupancy intensity; This indicates the frequency of low-frequency resource consumption tasks, with a value ranging from 0 to 1. This represents the normalized result of the number of cross-node migrations for low-frequency consumption tasks, with a value ranging from 0 to 1. This represents the probability of resource release for long-tail tasks, with a value ranging from 0 to 1. This expression combines the long-tail duration, the long-tail resource consumption, the frequency of occurrence, cross-node migration, and the probability of resource release to enable the long-tail load characterization to reflect the sustained impact of low-frequency consuming tasks on future resource availability.

[0091] When concatenating periodic resource demand representations, burst load representations, and long-tail load representations, the numerical features of each representation are first normalized, and discrete features such as task type, node type, power consumption mode state, and container instance state are embedded and mapped. Then, they are concatenated according to a unified computing node identifier and a unified scheduling time slice to construct a resource demand feature vector. This resource demand feature vector is used to uniformly express the regular resource changes, short-term burst changes, and low-frequency continuous occupancy changes of the same computing node within the same node window sample, enabling the resource demand prediction model to utilize load information at different time scales simultaneously. The expression for the resource demand feature vector is:

[0092]

[0093] in, This represents the resource requirement feature vector corresponding to the i-th computing node in the t-th unified scheduling time slice; This represents a cyclical representation of resource demand. This indicates a burst load characteristic; This represents the long-tail load characterization; Indicates static indicators; Indicates the health status of the hardware; Indicates the status of the task queue; Indicates the state of the container instance; This indicates the power consumption mode state. This expression combines features from different sources and time scales into a single resource demand feature vector, enabling subsequent resource demand prediction models to learn the comprehensive demand relationship between heterogeneous workloads and multidimensional resources.

[0094] When constructing a resource demand prediction model based on resource demand feature vectors, the model includes a shared temporal coding network, a periodic prediction branch, a burst load prediction branch, a long-tail load prediction branch, and a multi-resource output layer. The shared temporal coding network handles the temporal dependencies of resource demand feature vectors within consecutive time slices. It can be a combination of a temporal convolutional network and a gated attention structure. The temporal convolutional network extracts local resource change trends, while the gated attention structure dynamically adjusts the impact of different time slices based on burst load representations, long-tail load representations, and task priorities. The shared temporal coding network outputs a shared load latent state. The periodic prediction branch outputs regular resource demand prediction results based on the shared load latent state. The burst load prediction branch outputs burst resource demand correction results based on the shared load latent state. The long-tail load prediction branch outputs long-tail resource occupancy correction results based on the shared load latent state. The multi-resource output layer fuses the results from each branch and outputs predicted values ​​for CPU demand, memory demand, GPU demand, GPU memory demand, I / O demand, network bandwidth demand, energy consumption, and task execution latency. The expression for the shared load latent state is:

[0095]

[0096] in, This represents the hidden state of the shared load of the i-th computing node in the t-th unified scheduling time slice; A nonlinear mapping function representing a shared-time coding network; to Indicates that the i-th computing node is in the nearest A resource demand feature vector within a unified scheduling time slice; m represents the length of the historical observation window, taking the value of an integer greater than 1. This expression enables the resource demand prediction model to learn the evolution relationship of resource demand across multiple time slices by temporally encoding the continuous resource demand feature vector.

[0097] When the multi-resource output layer fuses the outputs of the periodic prediction branch, the burst load prediction branch, and the long-tail load prediction branch, it can dynamically generate branch fusion weights based on the burst load intensity, long-tail load characteristics, and periodic intensity, enabling the final prediction result to adapt to different load patterns. When the periodic intensity is high and the burst load intensity is low, the weight of the periodic prediction branch is increased; when the burst load intensity is high, the weight of the burst load prediction branch is increased; when the risk of continuous occupancy by long-tail tasks is high, the weight of the long-tail load prediction branch is increased. The expression for the final prediction result is:

[0098]

[0099] in, This indicates that the i-th computing node is in the future time slice t. The corresponding final prediction result; This represents the prediction step size, and its value is an integer greater than 0. This represents the regular resource demand forecast results output by the periodic forecast branch; This indicates the result of the burst resource demand correction output by the burst load prediction branch; This indicates the long-tail resource occupancy correction result output by the long-tail load prediction branch; , and These represent the branch fusion weights for the periodic forecasting branch, the burst load forecasting branch, and the long-tail load forecasting branch, respectively, with values ​​ranging from 0 to 1. This formula dynamically adjusts the contribution of different prediction branches to the final prediction result, enabling the resource demand prediction model to output stable prediction results when periodic loads, burst loads, and long-tail loads coexist.

[0100] When training the resource demand prediction model using historical hierarchical time series data, training samples are constructed from the historical hierarchical time series data according to computing nodes and unified scheduling time slices. The resource demand feature vector within the historical window is used as the training sample features, and the actual CPU consumption, memory consumption, GPU consumption, GPU memory consumption, IO consumption, network bandwidth consumption, node energy consumption, and task execution latency recorded in multiple future time slices are used as supervision labels. The training samples are labeled according to workload type, node type, burst load label, and long-tail load label, enabling the resource demand prediction model to learn the differences in resource demand between different workloads and different hardware conditions. For real-time inference tasks, the training focus is increased on task execution latency samples; for AI training tasks, the training focus is increased on GPU and network bandwidth samples; for data analysis tasks, the training focus is increased on IO and memory samples, thus enabling the trained resource demand prediction model to adapt to heterogeneous workload resource orchestration scenarios.

[0101] When optimizing model parameters by combining prediction error and multi-resource balancing constraint error, both multi-step prediction error and multi-resource balancing constraint error are incorporated into the training loss. Prediction error measures the difference between the predicted results from the resource demand prediction model and the actual resource consumption. Multi-resource balancing constraint error constrains the coordination between predictions of various resources such as CPU, memory, GPU, I / O, and network bandwidth, preventing the model from reducing error only in a single resource dimension while neglecting other resource dimensions. Model parameters refer to the learnable weights in the shared temporal coding network, periodic prediction branch, burst load prediction branch, long-tail load prediction branch, and multi-resource output layer. The expression for the training loss is:

[0102]

[0103] in, This represents the total training loss of the resource demand prediction model. This represents the prediction error, used to measure the difference between the predicted values ​​of multiple resources and the actual resource consumption over multiple future time slices; This represents the multi-resource balance constraint error, used to constrain the coordination relationship between different resource prediction results; This represents the time smoothing constraint error, used to suppress unreasonable jumps in prediction results between adjacent time slices; , and These represent the training weights corresponding to the prediction error, multi-resource balancing constraint error, and time smoothing constraint error, respectively. Their values ​​range from 0 to 1 and can be adjusted based on the proportion of burst load samples, the proportion of long-tail load samples, and service latency sensitivity in the training set. This formula, by simultaneously constraining prediction accuracy, resource coordination, and temporal continuity, enables the resource demand prediction model to output prediction results that are more suitable for subsequent macro- and micro-timers.

[0104] Prediction error can be calculated using the multi-resource weighted mean square error, while multi-resource balancing constraint error can be calculated based on the load deviation between the prediction results of different resources. For the same computing node, if the prediction results show that GPU demand is close to saturation while CPU, network bandwidth, or IO prediction demand is significantly lower, it may indicate that there is a single resource bottleneck on that node. If the model ignores this bottleneck for a long time, the subsequent macro-timer is prone to generating incorrect load allocation. The expression for multi-resource balancing constraint error is:

[0105]

[0106] in, This represents the multi-resource balance constraint error; N represents the number of computing nodes participating in training; D represents the number of prediction steps; and Q represents the number of resource prediction dimensions. This indicates that the i-th computing node is in the future time slice t. Predict the utilization rate of the qth resource dimension; This indicates that the i-th computing node is in the future time slice t. The formula measures the deviation of predicted utilization rates for different resource dimensions from the average predicted utilization rate for multiple resources. This enables the training process to identify risks of individual resource overload and resource utilization imbalance, providing a more stable predictive basis for subsequent load balancing and container grouping.

[0107] After training, the resource demand prediction model is deployed to the macro scheduler or prediction service node. During runtime, it receives the resource demand feature vectors constructed in real time and outputs node-level and container-level resource demand prediction results. The node-level resource demand prediction results are used by the macro scheduler to generate node-level load allocation results, container grouping strategies, and power mode selection results; the container-level resource demand prediction results are used by the micro scheduler to execute load migration, container scaling, and power mode switching. If key status information shows that the deviation between the actual resource status and the prediction results continues to increase, recent samples are added to the incremental training cache, and the resource demand prediction model is slightly updated to enable it to adapt to new workloads, new hardware nodes, and sudden load pattern changes.

[0108] In one possible implementation, the prediction results are input into a hierarchical global scheduler, splitting the scheduling problem into two layers: macro-scheduling and micro-scheduling. Real-time status feedback is used to correct the macro-scheduling results. Specifically, this includes: constructing a global scheduling state table based on node-level resource demand predictions, container-level resource demand predictions, energy consumption predictions, and task execution latency predictions; performing node-level load allocation on the workload to be scheduled based on the global scheduling state table, generating node-level load allocation results; generating container grouping strategies based on the node-level load allocation results; generating power mode selection results using the node-level load allocation results and container grouping strategies; encapsulating the node-level load allocation results, container grouping strategies, and power mode selection results into a macro-scheduling result and sending it to the micro-scheduler; performing node-local executability verification on the macro-scheduling results based on the node's local real-time resource status; if the macro-scheduling result passes the node-local executability verification, performing load migration, container scaling, and power mode switching based on the container grouping strategy; if the macro-scheduling result fails the node-local executability verification, generating a local correction result and sending it back to the macro-scheduler; and updating the global scheduling state table based on the local correction result to form a corrected macro-scheduling result.

[0109] Specifically, when constructing the global scheduling status table based on the node-level resource demand forecasts, container-level resource demand forecasts, energy consumption forecasts, and task execution latency forecasts from the prediction results, the macro scheduler first merges the various forecast results according to the compute node identifier, target scheduling time slice, and workload type, forming a resource demand profile for each compute node over multiple future time slices. The node-level resource demand forecasts describe the overall expected resource usage of the compute node in terms of CPU, memory, GPU, GPU memory, I / O, and network bandwidth; the container-level resource demand forecasts describe the expected resource consumption of each container group or container instance over future time slices; the energy consumption forecasts describe the expected energy consumption of the compute node when executing the scheduled workload under different power consumption modes; and the task execution latency forecasts describe the response or completion latency that may occur when the workload runs on the target compute node. (Refer to...) Figure 2 The global scheduling status table is a unified state data structure used by the macro scheduler for subsequent node-level load allocation, container grouping strategies, and power mode selection. It not only stores predicted resource requirements but also the current real-time resource status, hardware health status, current power mode, number of container instances, and existing task queuing status. This allows the macro scheduler to determine whether a compute node is suitable for handling scheduled workloads within the same data structure. The expression for the predicted remaining resources of a compute node in the global scheduling status table is:

[0110]

[0111] in, Indicates the i-th computing node in the future time slice The predicted remaining quantity of the qth type of resource; This represents the rated capacity of the q-th type of resource on the i-th computing node; This represents the normalized score of the hardware health status of the i-th computing node in the current time slice. The value ranges from 0 to 1, and the larger the value, the better the hardware availability. Indicates the i-th computing node in the future time slice The predicted demand value for the qth type of resource; This represents the amount of resource type q that has been occupied or reserved by the i-th computing node in the current time slice; The prediction step size is represented by an integer greater than 0; q represents the resource dimension, including CPU, memory, GPU, GPU memory, I / O, and network bandwidth. This formula subtracts the rated resource capacity, hardware health status, predicted resource demand, and occupied resources to obtain the predicted amount of remaining resources available for scheduling decisions within the future time slice, enabling the global scheduling status table to reflect the actual carrying capacity of computing nodes.

[0112] When performing node-level load balancing based on the global scheduling status table for the workload to be scheduled, the macro scheduler first reads the task type, task priority, service level constraints, resource requirement prediction vector, container runtime environment constraints, and hardware compatibility conditions of the workload to be scheduled. The workload to be scheduled refers to AI training tasks, real-time inference tasks, data analysis tasks, or online service tasks that have not yet completed deployment, migration, or scaling decisions. Node-level load balancing refers to selecting target computing nodes from candidate computing nodes that can handle the workload to be scheduled, and determining the deployment location of the workload within the target scheduling time slice. For AI training tasks, computing nodes that meet the requirements for predicted remaining GPU resources, predicted remaining GPU memory resources, and predicted remaining network bandwidth resources are prioritized; for real-time inference tasks, computing nodes with lower predicted task execution latency, lower power mode switching costs, and stable hardware health are prioritized; for data analysis tasks, computing nodes with higher predicted remaining IO resources and memory resources are prioritized. The expression for node-level load balancing scoring is:

[0113]

[0114] in, This represents the node-level load allocation score for the j-th workload to be scheduled, which is allocated to the i-th compute node in the current time slice. The larger the value, the higher the allocation fit. Q represents the number of resource dimensions. This represents the demand weight of the j-th workload to the q-th resource, with a value ranging from 0 to 1, and the corresponding resource dimensions. The sum is 1; This represents the predicted remaining amount of the q-th type of resource for the i-th computing node in the future time slice; This represents the rated capacity of the q-th type of resource on the i-th computing node; This represents a stability coefficient to prevent the denominator from being zero, and its value is a decimal greater than 0. This represents the sensitivity weight of the j-th workload to task execution latency, with a value ranging from 0 to 1. This represents the predicted task execution latency of the j-th scheduled workload on the i-th compute node; This represents the energy consumption sensitivity weight of the j-th workload to be scheduled, with a value ranging from 0 to 1; This represents the predicted energy consumption of the j-th workload to be scheduled on the i-th compute node; This represents the sensitivity weight of the j-th workload to hardware adaptation, with a value ranging from 0 to 1; This represents the hardware compatibility score between the j-th scheduled workload and the i-th compute node, with a value ranging from 0 to 1. This formula, by simultaneously considering the predicted remaining resources, predicted task execution latency, predicted energy consumption, and the hardware compatibility score, ensures that the node-level load allocation results can adapt to the resource matching relationship between heterogeneous workloads and heterogeneous compute nodes.

[0115] When generating container grouping strategies based on node-level load balancing results, the macro scheduler analyzes the resource requirement complementarity, communication dependencies, task priority relationships, scaling sensitivity, and fault isolation requirements among corresponding container instances, focusing on the workload of the identified target compute nodes. Container grouping strategies divide multiple container instances or instances to be deployed into several container groups according to resource coordination and scheduling constraints, facilitating the micro scheduler to uniformly execute load migration and container scaling locally on the node. Resource requirement complementarity refers to a situation where one container instance primarily consumes GPU resources while another primarily consumes CPU or I / O resources; deploying them on the same compute node reduces the likelihood of single-resource bottlenecks. Communication dependencies refer to frequent data exchange, model parameter synchronization, or service call relationships between multiple container instances, making them suitable for being grouped into the same container group or near compute nodes. Scaling sensitivity refers to the sensitivity of container instances to scaling up start time, scaling down interruption risk, and service recovery time. Container grouping scores can be expressed as:

[0116]

[0117] in, This represents the grouping adaptation score for classifying the u-th container instance and the v-th container instance into the same container group. The larger the value, the more suitable they are to be classified into the same container group. This represents the resource requirement complementarity score between the u-th container instance and the v-th container instance, with a value ranging from 0 to 1; This represents the communication dependency score between the u-th container instance and the v-th container instance, with a value ranging from 0 to 1; This represents the task priority association score between the u-th container instance and the v-th container instance, with a value ranging from 0 to 1; This represents the resource contention conflict score between the u-th container instance and the v-th container instance, with a value ranging from 0 to 1; , , and These represent the grouping weights corresponding to resource demand complementarity, communication dependency, task priority, and resource contention conflict, respectively, with values ​​ranging from 0 to 1. This formula enhances the impact of resource complementarity, communication dependency, and priority association while reducing the impact of resource contention conflict, enabling the container grouping strategy to avoid GPU memory, I / O queue, or network bandwidth contention while minimizing communication costs.

[0118] When generating power mode selection results based on node-level load balancing results and container grouping strategies, the macro scheduler determines whether the target compute node should maintain high-performance mode, balanced mode, energy-saving mode, or standby mode based on the target compute node's predicted resource requirements over multiple future time slices, container grouping execution plans, current power mode, target workload priority, predicted task execution latency, power mode switching time, and hardware health status. The power mode selection result constrains the hardware power consumption of compute nodes during load migration, container scaling, and task execution. For compute nodes carrying real-time inference tasks, high-priority tasks, or GPU-intensive AI training tasks, if the predicted task execution latency is close to the service level constraint limit, high-performance mode or balanced mode is preferred. For compute nodes with low predicted resource requirements and only carrying low-priority data analysis tasks, energy-saving mode can be selected. For compute nodes with no scheduled workloads and no critical container instances running, standby mode can be selected. The expression for the power mode selection score is:

[0119]

[0120] in, This represents the power mode selection score of the i-th computing node when it selects the s-th power mode in the current time slice. The larger the value, the more suitable the power mode is for the current scheduling requirements. This indicates that the performance of the i-th computing node in the s-th power consumption mode meets the score, with a value ranging from 0 to 1; This represents the energy cost score of the i-th computing node in the s-th power consumption mode, with a value ranging from 0 to 1; The value represents the switching cost score from the current power consumption mode to the s-th power consumption mode, and its range is from 0 to 1; This represents the risk score for abnormal task execution delay or decreased hardware stability after switching to the s-th power consumption mode, with a value ranging from 0 to 1; , , and These represent the power consumption weights corresponding to performance satisfaction, energy cost, switching cost, and switching risk, respectively, with values ​​ranging from 0 to 1. This formula establishes a quantitative trade-off between performance satisfaction and energy reduction, ensuring that the power consumption mode selection result is consistent with the node-level load allocation result and container grouping strategy.

[0121] When the node-level load allocation results, container grouping strategies, and power mode selection results are encapsulated into macro-scheduling results and sent to the micro-scheduler, the macro-scheduler generates corresponding scheduling result packages according to the target compute nodes. The macro-scheduling result refers to the overall scheduling plan generated by the central macro-scheduler to guide local node execution. It includes the target scheduling time slice, scheduling version identifier, target compute node identifier, workload identifier to be taken over, migration source, target container group, number of containers to be scaled up, number of containers to be scaled down, target power mode, execution order, and exception rollback conditions. The micro-scheduler is an execution control component deployed locally on the compute nodes. It is responsible for performing local executability checks based on the macro-scheduling results and the node's real-time resource status. After the checks pass, it implements load migration, container scaling up / down, and power mode switching. By encapsulating the macro-scheduling results into scheduling result packages and carrying the scheduling version identifier and target scheduling time slice, the duplicate or out-of-order execution of older version scheduling results in large-scale clusters can be avoided.

[0122] When performing node-local executability verification on the macro-scheduling results based on the node's local real-time resource status, the micro-scheduler first obtains the current compute node's real-time CPU utilization, memory utilization, GPU utilization, GPU memory usage, I / O queue length, network bandwidth utilization, node real-time energy consumption, hardware health status, current power consumption mode, remaining time for power consumption mode switching, container instance running status, and task queuing status. This information is then timestamped with the target scheduling time slice in the macro-scheduling results to form a node-local verification status table. Node-local executability verification refers to determining on the node whether the macro-scheduling results can be safely executed according to the current real resource status, preventing the macro-scheduler from issuing outdated scheduling results due to status update delays. Node-local executability verification includes resource capacity verification, container execution verification, power consumption switching verification, and timing coupling verification. Resource capacity verification determines whether the target compute node has sufficient available resources; container execution verification determines whether the container grouping strategy includes image caching, runtime resources, GPU binding resources, and network ports; power consumption switching verification determines whether the target power consumption mode meets task execution latency constraints; and timing coupling verification determines whether there are any execution order conflicts between load migration, container scaling, and power consumption mode switching. The expression for the node-local executability score is:

[0123]

[0124] in, This represents the local executability score of the i-th computing node in the current time slice, with a value ranging from 0 to 1. The larger the value, the higher the executability of the macro scheduling result on the current computing node. This represents the resource capacity verification score, with a value ranging from 0 to 1. This indicates that the container performs a verification score, with a value ranging from 0 to 1; This represents the power consumption switching verification score, with a value ranging from 0 to 1; This represents the timing coupling verification score, with a value ranging from 0 to 1; , , and These represent the verification weights for resource capacity verification, container execution verification, power consumption switching verification, and timing coupling verification, respectively, with values ​​ranging from 0 to 1. This formula combines the local verification results of multiple nodes into a unified score, enabling the micro-scheduler to determine whether the macro-scheduling result meets the local execution conditions of the node.

[0125] When the macro-scheduling result passes the node-local executability verification, the micro-scheduler performs load migration, container scaling, and power mode switching based on the container grouping strategy. Passing the node-local executability verification means that the node's local executability score is greater than or equal to the preset executability threshold, and there are no hard resource capacity shortages, critical containers that cannot be started, target power mode that cannot be switched, or execution timing conflicts. Load migration refers to migrating the workload to be scheduled from the source compute node, source container group, or task queue to the target container group on the target compute node; container scaling refers to adding or releasing container instances based on container-level resource demand prediction results to match the actual carrying capacity of the container group with the predicted resource demand; power mode switching refers to adjusting the current compute node's high-performance mode, balanced mode, energy-saving mode, or standby mode based on the power mode selection results. During execution, the micro-scheduler continuously records the completion status of load migration, container scaling, power mode switching, task execution latency changes, and resource usage changes for subsequent incremental reporting to the macro-scheduler.

[0126] When the macro-scheduling result fails the node-local executability check, the micro-scheduler generates a local correction result based on the type of failure and sends it back to the macro-scheduler. The local correction result is feedback information generated by the micro-scheduler after locally correcting the macro-scheduling result based on the current real resource status of the compute nodes. It prompts the macro-scheduler to readjust node-level load allocation results, container grouping strategies, or power mode selection results. If the resource capacity check fails, the local correction result may include reducing the number of pending workloads, delaying load migration, or rejecting new workloads. If the container execution check fails, the local correction result may include limiting the number of container expansions, delaying container startup, or adjusting the container grouping execution order. If the power switching check fails, the local correction result may include maintaining the current power mode, delaying power mode switching, or reverting to the previous stable power mode. If the timing coupling check fails, the local correction result may include rearranging the execution order of load migration, container scaling, and power mode switching. The local correction result also carries the node-local executability score, the type of failure, the node's local real-time resource status, and the target scheduling time slice, enabling the macro-scheduler to identify the reason for scheduling failure.

[0127] When updating the global scheduling status table based on local correction results and forming the corrected macro scheduling result, the macro scheduler, upon receiving the local correction result, first locates the original macro scheduling result according to the scheduling version identifier and the target scheduling time slice. Then, it writes the node's local real-time resource status, node's local executability score, failed verification type, and local adjustment suggestions from the local correction result into the global scheduling status table. The updated global scheduling status table reflects the true executable status of the target compute node, rather than relying solely on prediction results or the status reported in the previous cycle. Subsequently, the macro scheduler re-evaluates the node-level load allocation score, container grouping score, and power mode selection score of the affected workloads to be scheduled, regenerates the corrected node-level load allocation result, corrected container grouping strategy, and corrected power mode selection result, and repackages these three into the corrected macro scheduling result, which is then sent to the corresponding micro scheduler. Through this process, the prediction result, macro scheduling result, node local executability verification, and local correction result form a closed-loop correlation, thereby reducing the risk of scheduling failure caused by scheduling execution latency, status update latency, and power mode switching latency.

[0128] In one possible implementation, node-local executability verification is performed on the macro-scheduling results based on the node's local real-time resource status. Specifically, this includes: obtaining the current compute node's local real-time resource status and aligning it with the timestamp of the target scheduling time slice corresponding to the macro-scheduling result to form a node-local verification status table; performing resource capacity verification on the node-level load allocation result in the macro-scheduling result based on the node-local verification status table to determine whether the node-level load allocation result causes resource over-provisioning; performing container execution verification on the container grouping policy in the macro-scheduling result based on the node-local verification status table to determine whether the container grouping policy meets the container running conditions of the current compute node; and performing power switching verification on the power mode selection result in the macro-scheduling result based on the node-local verification status table to determine whether the power mode selection result meets the task execution delay constraints.

[0129] Specifically, when acquiring the real-time local resource status of the current compute node, the micro-scheduler synchronously reads the current compute node's runtime data at the current sampling moment from the node-local monitoring interface, container runtime interface, GPU management interface, network monitoring interface, and power management interface. The node-local real-time resource status describes the actual available capabilities of the current compute node before the scheduling instruction is actually executed, including CPU real-time utilization, memory real-time utilization, GPU real-time utilization, GPU memory occupancy, I / O queue length, network bandwidth real-time utilization, node real-time energy consumption, hardware health status, current power mode, remaining time for power mode switching, container instance running status, and task queuing status. Since the macro-scheduling result is generated on the macro-scheduler side based on prediction results and the global scheduling status table, and the actual state of the current compute node may have changed due to task arrival, container startup, task completion, or power mode switching, it is necessary to re-acquire the node-local real-time resource status before local execution to avoid directly executing the already lagging macro-scheduling result.

[0130] When aligning the node's local real-time resource status with the target scheduling time slice corresponding to the macro scheduling result using timestamps, the micro scheduler reads the target scheduling time slice, scheduling version identifier, execution priority, and estimated execution time carried in the macro scheduling result, and maps the node's local real-time resource status to the target scheduling time slice according to the collection timestamp. Timestamp alignment is used to determine whether the node's local real-time resource status can represent the actual execution status of the target scheduling time slice. If the deviation between the collection time of the node's local real-time resource status and the target scheduling time slice exceeds a preset time tolerance range, the node's local real-time resource status is re-collected or the macro scheduling result is marked as having a risk of state lag. (Refer to...) Figure 3The node-local verification state table refers to a temporary state table formed locally on the node by the micro-scheduler for verifying execution resource capacity, container execution, and power consumption switching. It binds the current compute node's real-time resources, container status, task status, and power consumption status to the same target scheduling time slice. The expression for the timestamp alignment deviation is:

[0131]

[0132] in, This represents the timestamp alignment deviation of the i-th current computing node. The smaller the value, the more consistent the node's local real-time resource status is with the target scheduling time slice. This represents the local timestamp corresponding to the time when the i-th current computing node collects the local real-time resource status of the node; This indicates the target scheduling time slice corresponding to the macro scheduling result; when When the time tolerance is less than or equal to the preset time range, the node's local real-time resource status can be used to form the node's local verification status table; when When the time difference exceeds the preset tolerance range, it indicates that the node's local real-time resource status lags significantly behind the target scheduling time slice, requiring re-collection or triggering local correction. This formula determines whether the node's local execution capability verification is based on a valid real-time state by comparing the difference between the node's local collection time and the target scheduling time slice.

[0133] When performing resource capacity verification on the node-level load allocation results in the macro scheduling results based on the node's local verification status table, the micro scheduler first parses the number of workloads required to be undertaken by the current computing node, the workload type, the expected resource requirements, the task priority, and the service level constraints in the node-level load allocation results. Then, it reads the available CPU capacity, available memory capacity, available GPU capacity, available GPU memory capacity, available I / O capacity, and available network bandwidth capacity of the current computing node from the node's local verification status table. Resource capacity verification is used to determine whether the current computing node will experience resource overprovisioning after the actual load migration or deployment of new tasks. Resource overprovisioning refers to the situation where the new resource requirements required by the macro scheduling results to be undertaken by the current computing node, combined with existing resource usage and reserved safety margins, exceed the actual available resource capacity of the current computing node. For AI training tasks, the focus is on verifying GPU resources, GPU memory, and network bandwidth; for real-time inference tasks, the focus is on verifying CPU, GPU memory, and task execution latency-related resources; for data analysis tasks, the focus is on verifying memory, I / O, and network bandwidth.

[0134] Resource capacity verification can calculate the expected occupancy rate of each type of resource and select the maximum occupancy rate as the basis for resource capacity risk assessment. The expression is as follows:

[0135] in, represents the resource capacity utilization risk value of the i-th current computing node. The larger the value, the higher the risk of resource over-provisioning. q represents the resource dimension, including CPU, memory, GPU, GPU memory, IO, and network bandwidth. Q represents the set of resource dimensions participating in the resource capacity verification. This represents the amount of resources currently occupied by the i-th current computing node on the q-th resource type; This represents the expected resource requirement of the workload to be newly undertaken by the i-th current computing node on the q-th resource type, as required by the macro scheduling results. This represents the safety margin reserved by the i-th current computing node on the q-th type of resource, which is usually determined based on the intensity of workload fluctuations, task priorities, and hardware health status. This represents the real-time available capacity of the i-th current computing node on the q-th resource type; This represents the stability coefficient, a decimal value greater than 0. The formula compares the currently occupied resources, the estimated new resource demand, and the safety margin with the real-time available capacity to determine whether the node-level load allocation result will cause any critical resource to exceed its capacity. When the value is greater than 1, it is determined that there is a risk of resource over-allocation in the node-level load allocation result; when When the value is less than or equal to 1, the node-level load allocation result is determined to meet the execution conditions at the resource capacity level.

[0136] When performing container execution verification based on the node's local verification status table, the micro scheduler parses the target container group, the number of container instances to be expanded, the number of container instances to be scaled down, the workload to be migrated, the container image identifier, GPU binding requirements, network port requirements, and storage mounting requirements from the container grouping policy. It then combines this with the node's local verification status table to determine whether the current compute node meets the operational conditions for executing the container grouping policy. Container operational conditions refer to the necessary conditions for a container instance to be created, started, bound to resources, connected to the network, and to undertake tasks on the current compute node. These include image cache availability, container runtime availability, GPU binding resource availability, network port availability, storage mounting availability, service registration path availability, and the absence of uninterruptible task conflicts. For expansion operations, it is necessary to confirm that the newly added container instance can be started and completed before the target scheduling time slice; for scaling down operations, it is necessary to confirm that there are no incomplete tasks, uninterruptible tasks, or high-priority tasks in the released container instances; for workload migration operations, it is necessary to confirm that the state synchronization conditions and network connectivity conditions between the source and target container groups meet the requirements.

[0137] Container execution verification can be comprehensively judged by the product or weighted score of multiple running conditions, and its expression is:

[0138] in, This represents the container execution verification score of the i-th current compute node. The value ranges from 0 to 1. The larger the value, the more the container grouping strategy meets the container running conditions of the current compute node. This indicates the availability score of the image cache, with a value ranging from 0 to 1; This indicates the available rating at runtime for the container, with a value ranging from 0 to 1. This indicates the availability score of GPU-bound resources, with a value ranging from 0 to 1; This indicates the availability score for network ports and network connectivity, with a value ranging from 0 to 1. This indicates the storage mount availability score, with a value ranging from 0 to 1; This represents the task interruption risk score, with a value ranging from 0 to 1. The higher the value, the smaller the impact of scaling down or migrating on incomplete tasks and high-priority tasks. , , , , and These represent the verification weights corresponding to the runtime conditions of each container, with values ​​ranging from 0 to 1, and the sum of all weights is 1. This formula incorporates image, runtime, GPU binding, network, storage, and task status into the verification process, ensuring that container verification not only determines whether resources are sufficient but also whether the container grouping strategy can be actually executed on the current compute node. When the container execution threshold is lower than the preset threshold, the micro scheduler determines that the container grouping strategy does not meet the container operation conditions and generates local correction results that restrict expansion, postpone migration, or adjust the execution order of container groups.

[0139] When performing power mode switching verification based on the node's local verification status table, the micro-scheduler reads the current power mode, target power mode, remaining time for power mode switching, task execution latency constraints of the workload to be taken over, real-time inference task status, high-priority task status, GPU-intensive task status, and hardware health status to determine whether the target power mode can take effect without violating task execution latency constraints. The power mode selection result is used to control the switching of the current compute node between high-performance mode, balanced mode, power-saving mode, or standby mode. Power switching verification needs to assess risks in two directions simultaneously: when the target power mode is higher than the current power mode, it needs to be determined whether the performance improvement can be completed before the task arrives; when the target power mode is lower than the current power mode, it needs to be determined whether frequency reduction or power-saving strategies will cause increased task execution latency, inference response timeouts, or decreased training throughput. Task execution latency constraints refer to the maximum allowable execution latency of the workload under service level constraints or business requirements.

[0140] Power consumption switching verification can be determined by the relationship between the power consumption mode activation time and the task latency margin. The expression is as follows:

[0141] in, This represents the power consumption switching safety margin of the i-th current computing node. The larger the value, the easier it is for the target power consumption mode to meet the task execution latency constraints. This indicates the maximum allowed task execution latency for the workload to be executed on the current compute node; This represents the predicted task execution latency under the target power consumption mode; Indicates the remaining time required to switch from the current power mode to the target power mode; This represents the stability coefficient, a decimal value greater than 0. The formula calculates the latency margin that can be retained after a power mode switch by subtracting the predicted execution latency and the remaining time for power mode switching from the allowed latency. When When the value is greater than or equal to 0, it indicates that the target power consumption mode can meet the task execution latency constraint in terms of time; when When the value is less than 0, it indicates that the power mode switching may cause the task execution delay to exceed the constraint, and it is necessary to maintain the current power mode, postpone the power mode switching, or fall back to the previous stable power mode.

[0142] After completing resource capacity verification, container execution verification, and power consumption switching verification, the micro-scheduler writes the verification results to the node's local verification status table and forms the node's local executability judgment for the macro-scheduling result. If the resource capacity verification does not find any resource over-provisioning risk, the container execution verification meets the container running conditions, and the power consumption switching verification meets the task execution latency constraints, the micro-scheduler determines that the macro-scheduling result is executable on the current compute node and allows subsequent load migration, container scaling, and power consumption mode switching to be performed according to the container grouping strategy. If any verification fails, the micro-scheduler does not directly execute all macro-scheduling results. Instead, it generates a local correction result based on the type of failed verification and sends the local correction result, the node's local verification status table, the type of failed verification, and the target scheduling time slice back to the macro-scheduler, enabling the macro-scheduler to update the global scheduling status table and re-form the corrected macro-scheduling result.

[0143] In one possible implementation, the hierarchical global scheduler performs joint optimization to generate scheduling instructions based on service performance, cluster resource utilization, energy consumption, and load balancing among heterogeneous hardware. Specifically, this includes: constructing service performance evaluation metrics, cluster resource utilization evaluation metrics, energy consumption evaluation metrics, and load balancing among heterogeneous hardware evaluation metrics based on a joint optimization state set, wherein the joint optimization state set is constructed based on prediction results; normalizing the service performance evaluation metrics, cluster resource utilization evaluation metrics, energy consumption evaluation metrics, and load balancing among heterogeneous hardware evaluation metrics, and generating joint optimization weights; and constructing joint scheduling based on the joint optimization weights. The objective function is defined, and resource capacity constraints, service level constraints, container scaling constraints, power mode switching constraints, hardware health constraints, and timing coupling constraints are introduced into the joint scheduling objective function. A set of candidate scheduling actions is generated based on the joint scheduling objective function, and candidate scheduling actions that do not meet the constraints are eliminated. Hierarchical joint optimization is performed on the remaining candidate scheduling actions to generate macro scheduling results, and node local correction results are generated by combining them with node local executability verification. Scheduling instructions are generated based on the macro scheduling results that have passed the node local executability verification. The scheduling instructions include load scheduling instructions, container scaling instructions, and node power mode adjustment instructions.

[0144] Specifically, when constructing service performance evaluation metrics, cluster resource utilization evaluation metrics, energy consumption evaluation metrics, and load balancing evaluation metrics among heterogeneous hardware based on the joint optimization state set, the node-level resource demand prediction results, container-level resource demand prediction results, energy consumption prediction values, and task execution latency prediction values ​​in the prediction results are first bound to the global scheduling state table, node local executability score, node local correction results, hardware health status, container instance status, task queue status, and power consumption mode status to form the joint optimization state set. The joint optimization state set is used to uniformly describe the predicted resource demand, real-time resource occupation, task execution latency, container instance changes, power consumption mode changes, and hardware availability of each computing node within the future target scheduling time slice, enabling the joint optimization process to simultaneously consider the prediction-side status, scheduling-side status, and node local feedback status. Service performance metrics are used to measure whether the workload to be scheduled meets the requirements of task execution latency, service level constraints, and task priority under candidate scheduling schemes; cluster resource utilization metrics are used to measure whether resources such as CPU, memory, GPU, GPU memory, I / O, and network bandwidth are fully utilized; energy consumption metrics are used to measure the node energy consumption, power mode switching costs, and energy-saving benefits corresponding to candidate scheduling schemes; heterogeneous hardware load balancing metrics are used to measure whether there is local congestion or local idleness among CPU nodes, GPU nodes, hybrid acceleration nodes, and storage-intensive nodes. The expression for the service performance metrics is:

[0145]

[0146] Where P represents the service performance evaluation metric, with a larger value indicating better service performance; J represents the number of workloads to be scheduled; and j represents the j-th workload to be scheduled. This represents the predicted execution latency of the j-th workload to be scheduled under the candidate scheduling scheme; This represents the maximum allowable task execution delay for the j-th workload to be scheduled; This represents the queue length of the task queue containing the j-th workload to be scheduled; This represents the maximum allowed queue length for the j-th workload to be scheduled; This indicates a breach of service level constraint, with a value of 0 or 1, where 0 indicates no breach and 1 indicates a breach. , and These represent the service performance weights corresponding to task execution delay, task queue length, and service level constraint violation, respectively, with values ​​ranging from 0 to 1. ; This represents the stability coefficient, which is a decimal greater than 0. This formula incorporates task execution latency margin, task queuing margin, and service level constraint default into the evaluation, enabling the service performance evaluation metric to reflect the performance satisfaction of real-time inference tasks, AI training tasks, and data analysis tasks under different service requirements.

[0147] The cluster resource utilization evaluation metric is constructed based on the predicted utilization of multiple compute nodes and multiple resource dimensions. First, based on the joint optimization state set, the predicted CPU utilization, memory utilization, GPU utilization, GPU memory utilization, I / O utilization, and network bandwidth utilization of each compute node within the target scheduling time slice are calculated. Then, resource idle penalty and resource over-provisioning penalty are combined to obtain the cluster resource utilization evaluation metric. If a compute node has a high predicted GPU utilization but insufficient predicted network bandwidth utilization, it indicates that the compute node may have a single resource bottleneck. If some GPU nodes are consistently under high load while other GPU nodes are under low load for a long period, it indicates an imbalance in cluster resource utilization. The expression for the cluster resource utilization evaluation metric is:

[0148]

[0149] Where U represents the cluster resource utilization evaluation value, the larger the value, the more fully the cluster resources are utilized and the lower the risk of over-provisioning; N represents the number of computing nodes participating in scheduling; Q represents the number of resource dimensions; i represents the i-th computing node; q represents the q-th resource dimension; This represents the predicted utilization rate of the i-th computing node on the q-th resource, with a value ranging from 0 to 1; This represents the low utilization threshold of the q-th type of resource, with a value ranging from 0 to 1; This represents the high utilization threshold for the q-th type of resource, with a value ranging from 0 to 1. Greater than ; This represents the resource idle penalty coefficient, with a value ranging from 0 to 1; This represents the resource over-provisioning penalty coefficient, ranging from 0 to 1. This formula, by subtracting low-utilization and high-utilization penalties from the predicted resource utilization rate, ensures that the cluster resource utilization evaluation both encourages full resource utilization and suppresses task congestion caused by resource over-provisioning.

[0150] Energy consumption evaluation metrics can be constructed based on the current power consumption mode, target power consumption mode, predicted energy consumption, power consumption mode switching time, real-time node energy consumption, and hardware health status in the joint optimization state set. For computing nodes carrying real-time inference tasks or high-priority tasks within the target scheduling time slice, energy consumption evaluation metrics should not simply pursue low energy consumption, but should avoid abnormal task execution delays caused by switching to energy-saving modes; for computing nodes with low resource requirements and low task priority, the evaluation contribution of energy-saving benefits can be increased. The expression for the energy consumption evaluation metric is:

[0151]

[0152] Where E represents the energy consumption evaluation quantity, and the larger the value, the higher the energy consumption cost of the candidate scheduling scheme; N represents the number of computing nodes participating in the scheduling. This represents the predicted energy consumption of the i-th computing node within the target scheduling time slice; This represents the reference value for the upper limit of energy consumption corresponding to the i-th computing node; This represents the switching time required for the i-th computing node to switch from the current power mode to the target power mode; This represents the maximum power mode switching time allowed for the i-th computing node; This represents the risk of power switching when the i-th compute node executes the target power mode, resulting in abnormal task execution latency or decreased hardware stability. The value ranges from 0 to 1. This represents the power consumption mode switching time penalty coefficient, with a value ranging from 0 to 1; This represents the power consumption switching risk penalty coefficient, with a value ranging from 0 to 1; This represents the stability coefficient. This formula, by simultaneously measuring predicted energy consumption, switching time, and power switching risk, enables the energy consumption assessment to reflect the impact of node power mode adjustments on resource orchestration stability.

[0153] The load balancing evaluation metric for heterogeneous hardware can be constructed based on the predicted load share, actual load share, hardware compatibility, cross-node communication cost, and differences in hardware health status among different hardware types. Heterogeneous hardware refers to node types in a cluster with different computing capabilities and resource structures, including CPU nodes, GPU nodes, hybrid acceleration nodes, and storage-intensive nodes. Load balancing across heterogeneous hardware does not require all nodes to have identical resource utilization; rather, it requires that workloads be distributed to appropriate nodes according to hardware compatibility, while avoiding localized bottlenecks caused by a small number of GPU nodes, storage nodes, or network egress nodes. The expression for the load balancing evaluation metric for heterogeneous hardware is:

[0154]

[0155] Where B represents the load balancing evaluation value among heterogeneous hardware, and the larger the value, the more balanced the load among heterogeneous hardware; G represents the number of hardware types; g represents the g-th type of hardware. This represents the average predicted load percentage of the computing nodes corresponding to the g-th hardware type; This represents the average predicted load percentage across all computing nodes. This represents the normalized average cost of cross-node communication, ranging from 0 to 1. This represents the cross-node communication cost penalty coefficient, ranging from 0 to 1. This formula measures the deviation between the average load of each hardware type and the global average load, and deducts the cross-node communication cost, enabling the load balancing evaluation metric among heterogeneous hardware to simultaneously reflect load balancing and hardware collaboration efficiency.

[0156] When normalizing service performance evaluation metrics, cluster resource utilization evaluation metrics, energy consumption evaluation metrics, and heterogeneous hardware load balancing evaluation metrics, evaluation metrics with different value directions and numerical ranges are first mapped to a unified range to avoid a single evaluation metric dominating the joint optimization result due to its large numerical scale. Service performance evaluation metrics, cluster resource utilization evaluation metrics, and heterogeneous hardware load balancing evaluation metrics are usually benefit-oriented, with higher values ​​being better; energy consumption evaluation metrics are usually cost-oriented, with lower values ​​being better. Therefore, energy consumption evaluation metrics need to be converted into energy-saving benefit evaluation metrics. After normalization, joint optimization weights are generated based on the workload type proportion, task priority distribution, service level constraint violation degree, cluster congestion degree, energy consumption constraint strength, and heterogeneous hardware load deviation within the current scheduling cycle. Joint optimization weights are used to dynamically adjust the influence of different optimization objectives in the current scheduling cycle. For example, when the proportion of real-time inference tasks increases, the service performance weight is increased; when the cluster resource idle rate increases, the cluster resource utilization weight is increased; when energy consumption constraints are strengthened, the energy-saving benefit weight is increased; and when the heterogeneous hardware load deviation expands, the load balancing weight is increased. The expression for the joint optimization weights is:

[0157]

[0158] in, The value represents the joint optimization weight of the k-th optimization objective in the current scheduling cycle, ranging from 0 to 1, and the sum of all joint optimization weights is 1; k represents the type of optimization objective, corresponding to service performance, cluster resource utilization, energy saving benefits, and load balancing among heterogeneous hardware, respectively. This represents the urgency index of the k-th optimization objective in the current scheduling cycle, with a value ranging from 0 to 1; represents the sensitivity coefficient of the k-th optimization objective, with a value greater than 0, used to adjust the response strength of the corresponding optimization objective to changes in urgency; r represents the index of the optimization objective participating in normalization. This formula amplifies the weight of high-urgency objectives through exponential mapping and ensures a comparable allocation relationship among the joint optimization weights through normalization, enabling the hierarchical global scheduler to dynamically adjust the optimization direction according to changes in cluster state.

[0159] The hierarchical global scheduler is a hierarchical resource orchestration core architecture deployed in the control plane of a data center or cloud platform. It coordinates the relationship between macro-level scheduling decisions and node-local execution behavior in heterogeneous hardware environments. It performs unified resource orchestration on workloads to be scheduled, based on node-level resource demand forecasts, container-level resource demand forecasts, energy consumption forecasts, task execution latency forecasts, a global scheduling status table, a joint optimization status set, and the node's local real-time resource status. The hierarchical global scheduler consists of a macro-level scheduling layer and a micro-level scheduling layer. The macro-level scheduling layer analyzes the resource carrying capacity, power consumption mode status, hardware health status, and load distribution among heterogeneous hardware of each compute node within the future target scheduling time slice from a global perspective. It generates node-level load allocation results, container grouping strategies, and power consumption mode selection results based on a joint scheduling objective function. The micro-level scheduling layer is deployed within each current compute node. It performs node-local executability verification of the macro-level scheduling results based on the node's local real-time resource status. After passing the verification, it performs load migration, container scaling, and power consumption mode switching. Simultaneously, it continuously monitors resource status and task execution, and incrementally reports key status information to the macro-level scheduling layer. The hierarchical global scheduler achieves state synchronization between the macro-scheduling layer and the micro-scheduling layer through a global scheduling state table and a joint optimization state set. The global scheduling state table maintains the predicted resource requirements, real-time resource status, task execution status, container instance status, and power consumption mode status of each computing node. The joint optimization state set supports the joint optimization calculation of service performance evaluation metrics, cluster resource utilization evaluation metrics, energy consumption evaluation metrics, and load balancing evaluation metrics among heterogeneous hardware. Furthermore, the hierarchical global scheduler uses scheduling version identifiers, target scheduling time slices, node local executability scores, and local correction results to dynamically correct scheduling execution latency, state update latency, power consumption mode switching latency, and load migration timing conflicts. This ensures that load scheduling, container scaling, and node power consumption mode adjustment maintain timing consistency and resource coordination consistency in a large-scale heterogeneous cluster environment.

[0160] When constructing the joint scheduling objective function based on joint optimization weights, the normalized service performance evaluation, cluster resource utilization evaluation, energy saving benefit evaluation, and load balancing evaluation among heterogeneous hardware are weighted and summed according to the joint optimization weights. Resource capacity constraints, service level constraints, container scaling constraints, power mode switching constraints, hardware health constraints, and temporal coupling constraints are introduced into the joint scheduling objective function. Resource capacity constraints limit the resource usage after scheduling to ensure it does not exceed the real-time available capacity of the compute nodes; service level constraints limit task execution latency, task queuing length, and service default probability; container scaling constraints limit the number of container instances that can be scaled up, the scaling conditions, and the startup completion time; power mode switching constraints limit whether the target power mode can take effect before the target scheduling time slice; hardware health constraints avoid assigning high-risk tasks to compute nodes with abnormal hardware health; and temporal coupling constraints limit the execution order of load migration, container scaling, and power mode switching. The expression for the joint scheduling objective function is:

[0161]

[0162] Where J represents the comprehensive score of the joint scheduling objective function, and the larger the value, the better the candidate scheduling action; This represents the normalized service performance evaluation metric. This represents the normalized cluster resource utilization evaluation metric. Represents the normalized energy consumption evaluation quantity, using Indicates energy-saving benefits; This represents the normalized load balancing evaluation metric among heterogeneous hardware. , , and These represent the joint optimization weights for service performance, cluster resource utilization, energy saving benefits, and load balancing among heterogeneous hardware, respectively, with values ​​ranging from 0 to 1. ; This represents the total amount of default under the comprehensive constraint, with a value ranging from 0 to 1. The penalty coefficient represents the total amount of constraint violation, ranging from 0.5 to 2. This formula incorporates multi-objective benefits and constraint violation penalties into the same objective function, ensuring that candidate scheduling actions not only need to obtain higher resource benefits but also satisfy key execution constraints.

[0163] The total amount of default on multiple constraints can be weighted by the degree of default on each constraint, and its expression is as follows:

[0164] in, This indicates the total amount of defaults under the comprehensive constraints; Indicates the degree of violation of resource capacity constraints, with a value ranging from 0 to 1; This indicates the degree of breach of service level constraints, with a value ranging from 0 to 1; This indicates the degree of violation of the container's expansion and contraction constraints, with a value ranging from 0 to 1; This indicates the degree of violation of the power consumption mode switching constraint, with a value ranging from 0 to 1; This indicates the degree of breach of hardware health constraints, with a value ranging from 0 to 1; This indicates the degree of violation of the temporal coupling constraint, with a value ranging from 0 to 1; , , , , and These represent the constraint weights corresponding to the degree of violation of each constraint, with values ​​ranging from 0 to 1, and the sum of all constraint weights is 1. This formula unifies the degree of violation of different execution constraints into a comprehensive constraint violation amount, enabling the joint scheduling objective function to uniformly penalize resource over-provisioning, service latency, container inability to start, power consumption switching failure, hardware anomalies, and execution timing conflicts.

[0165] When generating the candidate scheduling action set based on the joint scheduling objective function, the hierarchical global scheduler generates multiple candidate scheduling actions around the workload to be scheduled, candidate compute nodes, candidate container groups, and candidate power consumption modes. The candidate scheduling action set includes actions such as allocating the workload to be scheduled to the target compute node, migrating the workload to the target container group, scaling up the target container group, scaling down the target container group, switching the target compute node to the target power consumption mode, delaying the execution of low-priority tasks, and rolling back the power consumption mode. Each candidate scheduling action is bound to the target scheduling time slice, execution order, resource demand prediction results, container operating conditions, and power consumption mode conditions. After generating the candidate scheduling action set, a hard screening is performed based on resource capacity constraints, service level constraints, container scaling constraints, power consumption mode switching constraints, hardware health constraints, and timing coupling constraints, eliminating candidate scheduling actions that do not meet the constraints. For example, if the target computing node's GPU memory is insufficient, the candidate scheduling action to allocate the AI ​​training task to that node will be eliminated; if the target power mode cannot be switched before the task arrives, the corresponding power mode adjustment action will be eliminated; if the container image is unavailable or there are insufficient network ports, the corresponding container expansion action will be eliminated.

[0166] When performing hierarchical joint optimization on the remaining candidate scheduling actions, the macro scheduler first calculates the comprehensive score of each remaining candidate scheduling action based on the joint scheduling objective function, and then selects the action combination that can improve the comprehensive score and meet the key constraints globally to form the macro scheduling result. The macro scheduling result includes node-level load allocation results, container grouping strategies, and power mode selection results, which describe the scheduling scheme that the central side wants each compute node to execute within the target scheduling time slice. Subsequently, the macro scheduler sends the macro scheduling result to the micro scheduler, which performs node-local executability verification based on the node's local real-time resource status. If the macro scheduling result can meet the requirements of resource capacity, container execution, power switching, and timing coupling on the target compute node, the micro scheduler accepts the macro scheduling result; if it fails the node-local executability verification, the micro scheduler generates a node-local correction result. The node-local correction result records the type of failure, the node-local executability score, the real-time resource status, and local adjustment suggestions, enabling the macro scheduler to update the joint optimization state set and recalculate subsequent scheduling actions.

[0167] When generating scheduling instructions based on macro-level scheduling results verified through node-local executability checks, the hierarchical global scheduler converts the verified node-level load allocation results, container grouping strategies, and power mode selection results into a set of instructions executable by compute nodes. These scheduling instructions include load scheduling instructions, container scaling instructions, and node power mode adjustment instructions. Load scheduling instructions specify the source compute node, target compute node, target container group, migration sequence, task priority, and rollback conditions for the workload to be scheduled. Container scaling instructions specify the number of containers to be scaled up or down, image identifier, resource binding requirements, execution time slice, and rollback conditions for the target container group. Node power mode adjustment instructions specify the target power mode, switchover trigger time, switchover protection conditions, and rollback conditions. By binding scheduling instructions to target scheduling time slices, scheduling version identifiers, and execution priorities, each compute node can execute corresponding actions according to a unified scheduling version. This avoids out-of-order or duplicate execution of load scheduling, container scaling, and node power mode adjustments in large-scale clusters, thereby reducing the risk of scheduling failures caused by scheduling execution latency and state update latency.

[0168] In one possible implementation, scheduling instructions are issued to each node, which locally monitors resource status and task execution in real time and incrementally reports key status information to the macro scheduler. Specifically, this includes: generating node execution instruction packages based on the scheduling instructions, whereby the node execution instruction packages include load scheduling instructions, container scaling instructions, and node power mode adjustment instructions; executing load scheduling instructions according to the migration sequence and generating a load migration completion status; performing container scaling processing on target containers based on container scaling instructions and generating a container scaling completion status; performing power mode switching processing on the current compute node based on node power mode adjustment instructions and generating a power mode switching completion status; monitoring resource status and task execution in real time during the execution of the node execution instruction packages; constructing key status information based on resource status, task execution status, load migration completion status, container scaling completion status, and power mode switching completion status; performing incremental filtering, timestamp binding, and scheduling version binding on the key status information to form incremental status reporting packages; uploading the incremental status reporting packages to the macro scheduler and updating the global scheduling status table and joint optimization status set based on the incremental status reporting packages.

[0169] Specifically, when generating node execution instruction packages based on scheduling instructions, the macro scheduler splits the scheduling instructions according to the target compute node. It encapsulates load scheduling instructions, container scaling instructions, and node power mode adjustment instructions related to the same current compute node into the same node execution instruction package, and binds the target scheduling time slice, scheduling version identifier, execution priority, exception rollback conditions, and status reporting rules to the node execution instruction package. The node execution instruction package is a local execution carrier that can be directly parsed and executed by the micro scheduler, used to convert the global scheduling intent generated by the macro scheduler into a set of specific actions that the current compute node can execute. Load scheduling instructions describe the workload to be migrated, source container group, target container group, migration sequence, and task priority; container scaling instructions describe the number of expansions, the number of reductions, image identifiers, resource binding requirements, and execution time slices for the target container group; and node power mode adjustment instructions describe the target power mode that the current compute node needs to switch to, the switching trigger time, switching protection conditions, and exception rollback conditions. By encapsulating the three types of instructions in the same node execution instruction package, the micro scheduler can coordinate load migration, container scaling and power mode switching according to a unified scheduling version, avoiding version inconsistencies or execution order conflicts between different instructions on the local node.

[0170] When executing load scheduling instructions according to the migration sequence, the micro-scheduler first reads the workload identifier to be migrated, source container group, target container group, migration start time, migration end time, and task priority from the node execution instruction packet. Based on the migration sequence, it determines whether the current compute node participates in the load migration as a source compute node, target compute node, or relay compute node. The migration sequence refers to the order in which load migration actions are executed within the target scheduling time slice. It is used to limit load migration to execution only after the target container group has the necessary conditions to accept the workload, or after the source container group has completed its state freeze. For stateful workloads, the micro-scheduler first performs task state snapshots, cache refreshes, session persistence, and network routing updates before migrating the workload to the target container group. For stateless workloads, the micro-scheduler can directly adjust traffic allocation or rebind the task queue. The load migration completion status records whether the load migration was successful, the migration completion time, the number of migration interruptions, the reason for migration failure, changes in task execution latency, and network occupancy during the migration, enabling the macro-scheduler to determine whether the load scheduling instructions were actually completed according to the scheduling intent.

[0171] When performing container scaling operations on a target container group based on container scaling instructions, the micro-scheduler parses the target container group, the number of instances to be scaled up, the number of instances to be scaled down, the image identifier, resource binding requirements, execution time slices, and rollback conditions. The target container group refers to the set of container instances designated to take on workloads or release resources in the macro-scheduling results. Container scaling operations are used to adjust the number of container instances within the target container group to match the predicted resource demand and the actual task queue status. During scaling up, the micro-scheduler checks the image cache, container runtime status, available CPU and memory capacity, GPU bound resources, GPU memory margin, network ports, storage mount paths, and service registration paths. After meeting the scaling conditions, it creates new container instances and adds them to the target container group. During scaling down, the micro-scheduler checks whether the container instances to be released have incomplete tasks, uninterruptible tasks, high-priority tasks, or workloads in migration. After meeting the scaling down conditions, it stops and releases the corresponding container instances. The container scaling completion status is used to record the number of target container groups that have completed scaling up, the number of containers that have completed scaling down, the scaling up / down completion time, the reasons for scaling up / down failures, the container startup time, and the resource binding results.

[0172] When performing power mode switching on the current compute node based on the node power mode adjustment instruction, the micro-scheduler reads the current power mode, target power mode, switching trigger time, switching protection conditions, abnormal rollback conditions, current task execution latency, real-time inference task status, high-priority task status, GPU-intensive task status, and hardware health status. The power mode switching process adjusts the current compute node between high-performance mode, balanced mode, power-saving mode, or standby mode to match the actual power consumption of the compute node with the predicted resource requirements and service performance constraints within the target scheduling time slice. If the target power mode is high-performance mode, the micro-scheduler prioritizes confirming that the power mode switch can be completed before the arrival of high-priority tasks; if the target power mode is power-saving mode or standby mode, the micro-scheduler needs to confirm that the current compute node does not have real-time inference tasks, high-priority tasks, uninterruptible tasks, or GPU-intensive tasks. The power mode switching completion status records the current power mode, target power mode, switching start time, switching completion time, whether the switching was successful, the reason for switching failure, abnormal rollback status, and changes in task execution latency after the switching, enabling the macro-scheduler to determine whether the node power mode adjustment instruction has truly taken effect.

[0173] During the execution of instruction packets by execution nodes, the micro-scheduler continuously reads the resource status and task execution status of the current compute node at a sampling frequency higher than that reported under normal conditions. Resource status describes the real-time changes in the hardware and system resources of the current compute node, including real-time CPU utilization, real-time memory utilization, real-time GPU utilization, GPU memory usage, I / O queue length, real-time network bandwidth utilization, real-time node power consumption, hardware health status, current power mode, and remaining time for power mode switching. Task execution status describes the running status of each workload and container instance on the current compute node, including task queue length, task execution latency, task completion status, task failure status, container instance running status, workload migration status, and container scaling status. Real-time monitoring is not only for recording execution results but also for detecting anomalies during execution, such as resource over-provisioning, container startup failure, power mode ineffectiveness, or sudden increases in task latency, enabling the micro-scheduler to take local protection actions based on anomaly rollback conditions.

[0174] When constructing key status information based on resource status, task execution status, load migration completion status, container scaling completion status, and power mode switching completion status, the micro-scheduler selects status fields directly related to the execution results of node instruction packets from continuous monitoring data. Key status information refers to the minimum necessary set of states that can influence subsequent scheduling decisions by the macro-scheduler; it does not need to include all original monitoring data. Key status information includes the current compute node's key resource utilization, changes in task execution latency, changes in task queue length, load migration completion status, container scaling completion status, power mode switching completion status, anomaly rollback status, node local executability score, and reasons for incomplete actions. By constructing key status information, nodes only report state changes that have practical corrective value to the macro-scheduler for the global scheduling status table and joint optimization status set, avoiding excessive communication overhead caused by full state backhaul in large-scale clusters.

[0175] When performing incremental filtering on critical status information, the micro-scheduler compares the critical status information in the current reporting period with the critical status information sent in the previous reporting period, retaining only the status fields that have changed, resource status fields that exceed the preset change threshold, execution status fields associated with node execution command packets, abnormal status fields, and incomplete action fields. Incremental filtering means not uploading unchanged or minimally changed status data repeatedly, but only uploading status increments that can change the macro-scheduling judgment. Timestamp binding means binding the local collection time, target scheduling time slice, and status effective time to each piece of critical status information, which is used by the macro-scheduler to determine whether the status belongs to the current scheduling period, a historical scheduling period, or a delayed arrival status. Scheduling version binding means associating critical status information with the scheduling version identifier in the node execution command packet, ensuring that the macro-scheduler can accurately assign the feedback status to the corresponding macro-scheduling result. After incremental filtering, timestamp binding, and scheduling version binding, an incremental status reporting packet is formed. The incremental status reporting packet is used to feed back the node's local execution results and real-time status changes to the macro-scheduler with low communication overhead.

[0176] After the incremental status reporting packets are uploaded to the macro scheduler, the macro scheduler first performs integrity verification, version matching, deduplication, out-of-order correction, and delay marking on the incremental status reporting packets. Integrity verification determines whether the incremental status reporting packets contain compute node identifiers, target scheduling time slices, scheduling version identifiers, and necessary status fields; version matching determines whether the incremental status reporting packets correspond to the currently valid macro scheduling result; deduplication removes duplicate reported status packets; out-of-order correction rearranges delayed status packets according to timestamps; and delay marking identifies status information that is not reported in a timely manner due to network or node load. After processing, the macro scheduler updates the global scheduling status table and the joint optimization status set based on the incremental status reporting packets. The global scheduling status table updates the real-time resource status, task execution status, container instance status, and power consumption mode status of the current compute node; the joint optimization status set updates the state basis required for service performance evaluation metrics, cluster resource utilization evaluation metrics, energy consumption evaluation metrics, and load balancing evaluation metrics among heterogeneous hardware. Through this update process, subsequent macro-schedule results and scheduling instructions can incorporate feedback from local node execution, reducing the risk of scheduling failures caused by scheduling execution delays, state update delays, and local node execution deviations.

[0177] This embodiment also discloses a predictive resource orchestration apparatus for heterogeneous loads, referring to... Figure 4 The device includes an acquisition module 401, a processing module 402, and an output module 403. It is used to execute any of the above-described predictive resource orchestration methods for heterogeneous loads, wherein: The acquisition module 401 is used to collect and aggregate the workload characteristics and underlying resource status of computing nodes in a hierarchical manner, compress and statistically analyze dynamic indicators locally on the nodes, and upload static indicators to the central time series database to form hierarchical time series data. Processing module 402 is used to extract periodic indicators, burst load patterns and long-tail load characteristics based on hierarchical time series data, construct a resource demand prediction model and output prediction results; The processing module 402 is used to input the prediction results into the hierarchical global scheduler, split the scheduling problem into two layers: macro scheduling and micro scheduling, and correct the macro scheduling results by combining real-time status feedback. The macro scheduler performs node-level load allocation, container grouping strategy and power mode selection, while the micro scheduler performs load migration, container scaling and power mode switching locally on the node. Processing module 402 is used to jointly optimize and generate scheduling instructions in the hierarchical global scheduler based on service performance, cluster resource utilization, energy consumption and load balancing among heterogeneous hardware. The output module 403 is used to send scheduling instructions to each node, and the nodes monitor the resource status and task execution status locally in real time, and incrementally report key status information to the macro scheduler.

[0178] It should be noted that the above embodiments of the apparatus are only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0179] This embodiment also discloses an electronic device, as shown in the reference. Figure 5 The electronic device may include: at least one processor 501, at least one communication bus 502, user interface 503, network interface 504, and at least one memory 505.

[0180] The communication bus 502 is used to enable communication between these components.

[0181] The user interface 503 may include a display screen and a camera. Optionally, the user interface 503 may also include a standard wired interface and a wireless interface.

[0182] The network interface 504 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0183] The processor 501 may include one or more processing cores. The processor 501 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 505, and by calling data stored in memory 505. Optionally, the processor 501 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 501 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 501 and may be implemented as a separate chip.

[0184] The memory 505 may include random access memory (RAM) or read-only memory. Optionally, the memory may include a non-transitory computer-readable storage medium. The memory 505 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 505 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 505 may also be at least one storage device located remotely from the aforementioned processor 501. As a computer storage medium, the memory 505 may include an operating system, a network communication module, a user interface 503 module, and an application program for a predictive resource orchestration method for heterogeneous workloads.

[0185] exist Figure 5In the electronic device shown, the user interface 503 is mainly used to provide an input interface for the user and obtain the user input data; while the processor 501 can be used to call an application stored in the memory 505 that is a predictive resource orchestration method for heterogeneous loads. When executed by one or more processors 501, the electronic device performs one or more methods as described in the above embodiments.

[0186] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, as some steps can be performed in other orders or simultaneously according to the present invention. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0187] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0188] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some service interface; the indirect coupling or communication connection between apparatuses or units may be electrical or other forms.

[0189] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0190] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0191] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 505 and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned memory 505 includes various media capable of storing program code, such as a USB flash drive, external hard drive, magnetic disk, or optical disk.

[0192] The present invention also discloses a non-transitory computer-readable storage medium storing instructions. When executed by one or more processors 501, these instructions cause an electronic device to perform one or more methods as described in the above embodiments.

[0193] The above are merely exemplary embodiments of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of other embodiments of this disclosure upon considering the specification and the disclosure of practical truths. This invention is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A predictive resource orchestration method for heterogeneous loads, characterized in that, The method includes: The workload characteristics and underlying resource status of computing nodes are collected and aggregated in layers. Dynamic indicators are compressed and statistically analyzed locally on the nodes, while static indicators are uploaded to the central time series database to form layered time series data. Based on the hierarchical time series data, periodic indicators, burst load patterns, and long-tail load characteristics are extracted to construct a resource demand prediction model and output the prediction results. The prediction results are input into the hierarchical global scheduler, which splits the scheduling problem into two layers: macro scheduling and micro scheduling. The macro scheduling results are corrected by combining real-time status feedback. The macro scheduler performs node-level load allocation, container grouping strategy and power mode selection, while the micro scheduler performs load migration, container scaling and power mode switching locally on the node. In the hierarchical global scheduler, scheduling instructions are generated through joint optimization based on service performance, cluster resource utilization, energy consumption, and load balancing among heterogeneous hardware. The scheduling instructions are sent to each node, and the nodes monitor the resource status and task execution status locally in real time, and incrementally report key status information to the macro scheduler. The step of inputting the prediction results into a hierarchical global scheduler, splitting the scheduling problem into two layers—macro-scheduling and micro-scheduling—and correcting the macro-scheduling results by incorporating real-time status feedback, specifically includes: A global scheduling status table is constructed based on the node-level resource demand prediction results, container-level resource demand prediction results, energy consumption prediction values, and task execution delay prediction values ​​in the prediction results. Based on the global scheduling status table, node-level load allocation is performed on the workload to be scheduled, resulting in node-level load allocation results. Generate a container grouping strategy based on the node-level load allocation results; The power consumption mode selection result is generated based on the node-level load allocation result and the container grouping strategy. The node-level load allocation result, the container grouping strategy, and the power consumption mode selection result are encapsulated into a macro-scheduling result and sent to the micro-scheduler. Based on the real-time resource status of the node, the macro scheduling result is subjected to node-local execution verification. When the macro scheduling result passes the node-local execution verification, load migration, container scaling up and down, and power mode switching are performed based on the container grouping strategy. When the macro scheduling result fails the node-local execution verification, a local correction result is generated and sent back to the macro scheduler. The global scheduling state table is updated based on the local correction results to form the corrected macro scheduling results.

2. The predictive resource orchestration method for heterogeneous loads according to claim 1, characterized in that, The process of extracting periodic indicators, burst load patterns, and long-tail load characteristics from the hierarchical time series data, constructing a multi-dimensional resource demand prediction model, and outputting prediction results specifically includes: For each computing node, the dynamic indicators are statistically analyzed and feature compressed locally using a sliding window method, and combined with the static indicators to form global hierarchical time series data. Perform periodic pattern analysis on short-term historical sequences at the node level to extract periodic indicators of load fluctuation cycles and peak task submission periods; For sudden load patterns, mutation detection and anomaly identification are performed, and an adaptive model is built by combining the historical response capabilities of nodes, thereby obtaining the characteristics of sudden load. Statistical analysis of low-frequency consumption tasks based on long-tail load characteristics, and extraction of key features through quantile analysis or heavy-tailed distribution fitting; The periodic indicators, burst load characteristics, and long-tail load characteristics are integrated into a multi-dimensional feature vector, which is then input into the resource demand prediction model. The prediction results are generated using rolling window recursive prediction, meta-learning, and adaptive incremental learning.

3. The predictive resource orchestration method for heterogeneous loads according to claim 1, characterized in that, Before extracting periodic indicators, burst load patterns, and long-tail load characteristics from the hierarchical time series data, constructing a resource demand forecasting model, and outputting the forecast results, the method further includes: Perform time alignment and window segmentation on the hierarchical time series data to generate node window samples corresponding to the computation nodes; The node window samples are respectively subjected to periodic feature construction to form a periodic resource demand representation, burst load feature construction to form a burst load representation, and long-tail load feature construction to form a long-tail load representation. The periodic resource demand representation, the burst load representation, and the long-tail load representation are concatenated to construct a resource demand feature vector; The resource demand prediction model is constructed based on the resource demand feature vector, wherein the resource demand prediction model includes a shared time-series coding network, a periodic prediction branch, a burst load prediction branch, a long-tail load prediction branch, and a multi-resource output layer. The resource demand forecasting model was trained using historical stratified time series data, and the model parameters were optimized by combining the forecast error and the multi-resource balance constraint error.

4. The predictive resource orchestration method for heterogeneous loads according to claim 1, characterized in that, The step of performing node-local executability verification on the macro-scheduling result based on the node's local real-time resource status specifically includes: Obtain the real-time local resource status of the current computing node and align it with the timestamp of the target scheduling time slice corresponding to the macro scheduling result to form a local node verification status table. Based on the node local verification status table, resource capacity verification is performed on the node-level load allocation result in the macro scheduling result to determine whether the node-level load allocation result causes resource over-provisioning. Based on the node local verification status table, the container grouping policy in the macro scheduling result is used to perform container execution verification to determine whether the container grouping policy meets the container running conditions of the current computing node. Based on the node's local verification status table, a power consumption switching verification is performed on the power consumption mode selection result in the macro scheduling result to determine whether the power consumption mode selection result meets the task execution delay constraint.

5. A predictive resource orchestration method for heterogeneous loads according to claim 1, characterized in that, The process of generating scheduling instructions through joint optimization in the hierarchical global scheduler based on service performance, cluster resource utilization, energy consumption, and load balancing among heterogeneous hardware specifically includes: Based on the joint optimization state set, service performance evaluation, cluster resource utilization evaluation, energy consumption evaluation, and load balancing evaluation among heterogeneous hardware are constructed respectively, wherein the joint optimization state set is constructed based on the prediction results. The service performance evaluation, cluster resource utilization evaluation, energy consumption evaluation, and load balancing evaluation among heterogeneous hardware are normalized and a joint optimization weight is generated. A joint scheduling objective function is constructed based on joint optimization weights, and resource capacity constraints, service level constraints, container scaling constraints, power consumption mode switching constraints, hardware health constraints, and timing coupling constraints are introduced into the joint scheduling objective function. A set of candidate scheduling actions is generated based on the joint scheduling objective function, and candidate scheduling actions that do not meet the constraints are removed. Perform hierarchical joint optimization on the remaining candidate scheduling actions to generate macro scheduling results and combine them with node local executability verification to generate node local correction results; The scheduling instructions are generated based on the macro scheduling results obtained through the local execution verification of the nodes. The scheduling instructions include load scheduling instructions, container scaling instructions, and node power consumption mode adjustment instructions.

6. A predictive resource orchestration method for heterogeneous loads according to claim 1, characterized in that, The process of issuing the scheduling instructions to each node, with each node locally monitoring resource status and task execution in real time, and incrementally reporting key status information to the macro scheduler, specifically includes: Based on the scheduling instructions, a node execution instruction package is generated, which includes load scheduling instructions, container scaling instructions, and node power consumption mode adjustment instructions. Execute the load scheduling instructions according to the migration sequence and generate a load migration completion status; Based on the container scaling instructions, the target containers are grouped and the container scaling process is executed, and a container scaling completion status is generated. Based on the node power consumption mode adjustment instruction, perform power consumption mode switching processing on the current computing node and generate a power consumption mode switching completion status; During the execution of the node execution instruction package, the resource status and task execution status are monitored in real time. Key status information is constructed based on the resource status, task execution status, load migration completion status, container scaling completion status, and power mode switching completion status. Incremental filtering, timestamp binding, and scheduling version binding are performed on the key status information to form an incremental status reporting packet; The incremental status reporting packet is uploaded to the macro scheduler, and the global scheduling status table and joint optimization status set are updated based on the incremental status reporting packet.

7. A predictive resource orchestration apparatus for heterogeneous loads, characterized in that, The apparatus is used to execute a predictive resource orchestration method for heterogeneous loads as described in any one of claims 1-6, the apparatus comprising an acquisition module, a processing module, and an output module, wherein: The acquisition module is used to perform hierarchical collection and aggregation of the workload characteristics and underlying resource status of computing nodes, compress and statistically analyze dynamic indicators locally on the nodes, and upload static indicators to the central time series database to form hierarchical time series data. The processing module is used to extract periodic indicators, burst load patterns and long-tail load characteristics based on the hierarchical time series data, construct a resource demand prediction model and output the prediction results. The processing module is used to input the prediction results into the hierarchical global scheduler, split the scheduling problem into two layers: macro scheduling and micro scheduling, and correct the macro scheduling results by combining real-time status feedback. The macro scheduler performs node-level load allocation, container grouping strategy and power mode selection, while the micro scheduler performs load migration, container scaling and power mode switching on the node. The processing module is used to perform joint optimization and generate scheduling instructions in the hierarchical global scheduler based on service performance, cluster resource utilization, energy consumption and load balancing among heterogeneous hardware. The output module is used to send the scheduling instructions to each node, and the nodes monitor the resource status and task execution status locally in real time, and incrementally report key status information to the macro scheduler.

8. An electronic device, characterized in that, It includes a processor and a memory, the memory having a computer program stored thereon, wherein the computer program, when executed by the processor, implements a predictive resource orchestration method for heterogeneous workloads as described in any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, perform a predictive resource orchestration method for heterogeneous workloads as described in any one of claims 1-6.

Images