A method and system for computing power coordination and management based on cross-architecture state perception engine

Abstract

The application discloses a computing power coordination management method and system based on a cross-architecture state perception engine, relates to the technical field of GPU computing power pooling scheduling, and comprises the following steps: a communication link set is established between a plurality of GPU instances and a plurality of CPU controllers, data throughput, queuing queue length, communication delay and other indexes of each link are collected and analyzed in real time, and a system bottleneck link is dynamically identified; the detected bottleneck link is finely split into a plurality of sub-links, an independent cache queue and a flow control strategy are allocated to each sub-link, fine management and isolation of link resources are realized; further, scheduling priorities are calculated according to real-time state indexes of each sub-link, and the optimal sub-link is preferentially selected for task scheduling during task allocation. Therefore, the resource utilization and task scheduling efficiency in the multi-tenant heterogeneous computing power pool environment are effectively improved, and the local link congestion and the 'false idle / false busy' situation of the computing power pool are significantly alleviated.

Description

Technical Field

[0001] This application relates to the field of GPU (Graphics Processing Unit) computing power pooling scheduling technology, and in particular to a computing power collaborative management method and system based on a cross-architecture state-aware engine. Background Technology

[0002] In multi-tenant cloud centers or high-performance computing centers, a large number of heterogeneous tasks need to share limited GPU resources. To improve resource utilization, cloud vendors generally combine multiple GPUs into computing power pools and dynamically allocate computing units, video memory, and bandwidth to tasks through a scheduler.

[0003] GPUs, with their numerous parallel computing units and high-speed memory, have become core accelerators in fields such as artificial intelligence and scientific computing. Modern GPUs boast tens of thousands of computing cores and enormous memory bandwidth, but many applications have limited parallelism, making it difficult for a single task to fully utilize the entire GPU. Therefore, multi-tenant sharing is commonly used in cloud computing environments: multiple applications run simultaneously on the same GPU through a scheduler, thereby improving resource utilization. However, this sharing requires addressing resource isolation and fairness issues. For example, NVIDIA's Multi-Instance GPU (MIG) technology can divide a single physical GPU into up to seven independent GPU instances, each with its own computing units, L2 cache, and DRAM controller, ensuring that tasks from different tenants do not interfere with each other.

[0004] When applications run on physical GPUs or MIG instances, the scheduler typically allocates resources based on macro-level metrics such as task queue length and estimated execution time. For example, some scheduling algorithms employ Shortest Job First (SJF) or task priority-based strategies, allowing jobs to migrate between multiple GPUs.

[0005] However, data transfer between the GPU and CPU is often accomplished via buses such as PCIe or InfiniBand, whose bandwidth is often relatively low compared to the GPU's internal computing power, easily becoming a performance bottleneck. The limited bandwidth of PCIe makes communication a transmission bottleneck for GPU applications, prompting manufacturers to develop high-bandwidth interconnect technologies such as NVLink. Furthermore, existing methods schedule tasks on a per-task basis, making it difficult to identify sudden traffic spikes or congestion in the GPU-CPU link. For example, while technologies like MIG or MPS (Multi-Process Service) can ensure instance isolation, they still rely on fixed link mappings. In addition, in scenarios such as deep learning training, job migration leads to the reloading of model states and data buffers, increasing latency and resulting in high task migration costs. Summary of the Invention

[0006] This application provides a computing power collaborative management method, system, storage medium, computer program product, and electronic device based on a cross-architecture state-aware engine, which at least solves the problem in current related technologies that the GPU-CPU link transmission bottleneck is difficult to identify and dynamically optimize in a timely manner in a multi-tenant environment, resulting in low system resource utilization and limited task scheduling efficiency.

[0007] In a first aspect, embodiments of this application provide a method for collaborative management of computing power based on a cross-architecture state-aware engine. The method includes: establishing a set of communication links between multiple GPU instances and multiple CPU controllers, and periodically collecting communication metrics for each communication link to construct a corresponding link state feature vector; the communication metrics include data throughput, queue length, and communication latency; identifying whether a corresponding communication link is a bottleneck link based on each link state feature vector; if a first communication link is determined to be a bottleneck link, splitting the first communication link into multiple sub-links; allocating independent cache queues and flow control policies to each sub-link, and sharing the physical bandwidth of the first communication link with each sub-link; calculating scheduling priorities for the sub-links based on their queue length, data throughput, and communication latency, and selecting a target sub-link for task execution from available sub-links during task scheduling based on the scheduling priorities.

[0008] Secondly, embodiments of this application provide a computing power collaborative management system based on a cross-architecture state-aware engine. The system includes: a data acquisition unit, used to establish a set of communication links between multiple GPU instances and multiple CPU controllers, and periodically collect communication metrics of each communication link to construct a corresponding link state feature vector; the communication metrics include data throughput, queue length, and communication latency; a bottleneck link identification unit, used to identify whether a corresponding communication link is a bottleneck link based on each of the link state feature vectors; a bottleneck link splitting unit, used to split the first communication link into multiple sub-links if it is determined to be a bottleneck link; each sub-link is allocated an independent cache queue and flow control policy, and each sub-link shares the physical bandwidth of the first communication link; and a task allocation unit, used to calculate the scheduling priority of the sub-link based on the queue length, data throughput, and communication latency of the sub-link, and select a target sub-link for executing the task from the available sub-links according to the scheduling priority during task scheduling.

[0009] Thirdly, an electronic device is provided, comprising: at least one processor, and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the steps of the computing power collaborative management method based on a cross-architecture state-aware engine according to any embodiment of the present application.

[0010] Fourthly, embodiments of this application provide a storage medium storing a computer program thereon, characterized in that, when the program is executed by a processor, it implements the steps of the computing power collaborative management method based on a cross-architecture state-aware engine according to any embodiment of this application.

[0011] Fifthly, embodiments of this application provide a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the computing power collaborative management method based on a cross-architecture state-aware engine according to any embodiment of this application.

[0012] The computing power collaborative management method and system based on a cross-architecture state-aware engine provided in this application can achieve at least the following technical effects:

[0013] (1) By periodically collecting multi-dimensional communication metrics of each communication link between the GPU instance and the CPU controller, the system can achieve comprehensive perception of the link status and data-driven bottleneck identification, breaking through the limitations of traditional task-centric and static scheduling, and enabling the system to continuously grasp the changes in link load under dynamic business pressure.

[0014] (2) When the link state awareness engine detects a communication bottleneck, it introduces a dynamic link splitting mechanism to divide the bottleneck link into multiple independently schedulable sub-links and allocates an independent cache queue and flow control strategy to each sub-link. This improves the fine management capability of bottleneck resources and realizes efficient sharing and dynamic diversion of link bandwidth, which significantly alleviates the performance degradation caused by traffic bursts or local congestion.

[0015] (3) For multi-sublink scenarios, a real-time scheduling priority evaluation method based on sublink communication indicators was further established. By integrating indicators such as queue length, data throughput, and communication latency, the current service capacity of each sublink is dynamically evaluated, and the optimal transmission path is selected for task scheduling accordingly. This not only improves the adaptability and accuracy of scheduling decisions, but also effectively reduces communication waiting and resource conflicts during job migration, ultimately improving the overall scheduling efficiency and fairness in a multi-tenant environment.

[0016] This technical solution establishes a link-level state awareness and dynamic scheduling mechanism between GPU instances and CPU controllers, enabling real-time identification of communication bottlenecks and fine-grained link decomposition. By combining multi-dimensional link metrics, it adaptively allocates tasks to optimal sub-links, effectively overcoming the "false idle / false busy" phenomenon in the computing pool caused by local link congestion. By dynamically adjusting the allocation of tasks across multiple sub-links, it maximizes the release of the true computing potential of each GPU within the computing pool, improving queue isolation and scheduling fairness in multi-task environments. This effectively localizes and alleviates link congestion, significantly enhancing computing power collaboration and service stability in multi-tenant heterogeneous environments. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart is shown as an example of a collaborative computing power management method based on a cross-architecture state-aware engine according to an embodiment of this application.

[0019] Figure 2 A flowchart illustrating an example of identifying bottleneck links based on link state feature vectors according to an embodiment of this application is shown.

[0020] Figure 3 A flowchart illustrating an example of splitting a first communication link into multiple sub-links according to an embodiment of this application is shown.

[0021] Figure 4 A flowchart is shown as another example of a collaborative computing power management method based on a cross-architecture state-aware engine according to an embodiment of this application;

[0022] Figure 5 A simulation diagram illustrating the impact of different scheduling methods on average task completion time under the same computing power pool load is shown.

[0023] Figure 6 A simulation diagram illustrating an example of the impact of the splitting threshold on system throughput and communication latency performance;

[0024] Figure 7 A structural block diagram of an example of a computing power collaborative management system based on a cross-architecture state-aware engine, according to an embodiment of this application, is shown. Detailed Implementation

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

[0026] It should be noted that, in the current related technologies, some experts and scholars have proposed some novel directions for GPU computing power pooling scheduling and management.

[0027] NVIDIA's MIG technology allows a single GPU to be divided into multiple isolated instances, resolving resource interference issues in multi-tenant scenarios. Ampere and higher architecture GPUs can be securely partitioned into up to seven independent instances, each with its own compute units, L2 cache, and DRAM controller, providing isolated GPU resources for multiple users. MIG provides cloud service providers with a mechanism to guarantee quality of service, allowing users to schedule virtual instances as if they were physical GPUs. However, MIG primarily focuses on the static partitioning of compute resources; communication between instances still relies on fixed link mappings, making it less effective at handling sudden bottlenecks in CPU-GPU or GPU-GPU links.

[0028] Recent studies have proposed MIGRator (Multi-Instance GPU Resource Allocator for Continuous Learning), which, for continuous learning scenarios, places model retraining and inference tasks within the same GPU instance. It achieves dynamic instance reconfiguration through ILP optimization, improving the "Goodput" metric. Experiments show that MIGRator improves performance by 17–21% compared to existing GPU sharing solutions. However, this approach relies on the instance partitioning of MIG, focusing on dynamically adjusting the number and size of instances, without addressing the traffic status of the CPU-GPU link and its impact on task scheduling.

[0029] Some studies have proposed a scalable task scheduling algorithm, FAR (Flexible Application-aware Resource Allocation), for MIG (Multi-GPU Configuration). This algorithm divides the physical GPU into multiple dynamically reconfigurable instances and generates a task-instance mapping scheme through a three-stage approach. Specifically, when the application's parallelism is insufficient to fully utilize the GPU, MIG can improve resource utilization by splitting instances and running multiple applications simultaneously. FAR utilizes techniques such as list scheduling and local search to generate optimal instance allocation for task batches and considers the MIG reconfiguration cost. However, FAR still confines the scheduling model to the GPU itself; it does not consider the dynamic changes in bandwidth between different GPUs or CPUs, nor does it provide a link splitting mechanism to alleviate link-layer bottlenecks.

[0030] Some studies have proposed the SJF-BSBF (Shortest Job First with BestSlot Best Fit) scheduling algorithm for multi-tenant GPU clusters. This algorithm allows multiple deep learning jobs to share the same GPU and dynamically determines sharing parameters (sub-batch size, sharing time) without changing the training configuration, thereby reducing job queuing time. However, SJF-BSBF mainly addresses resource sharing within a fixed GPU combination and lacks awareness of traffic fluctuations in GPU-CPU or GPU-GPU links. It cannot adjust the scheduling strategy in a timely manner when links are congested or suddenly interrupted.

[0031] Based on the above analysis, it is evident that most current related technologies perform task scheduling at the GPU or instance level, lacking link-layer state awareness and cross-architecture adaptive splitting mechanisms.

[0032] It should be understood that the above description of the relevant technologies is intended only to help the public better understand the inventive spirit and motivation of this application, and is not intended to limit this application. Furthermore, the technical solutions described in the above-mentioned relevant technologies are not prior art, and may also be undisclosed technical solutions, such as those under research or in the laboratory stage.

[0033] The technical solutions in this application, including the collection, storage, use, processing, transmission, provision, and disclosure of users' personal information, comply with relevant laws and regulations and do not violate public order and good morals.

[0034] Figure 1 A flowchart illustrating an example of a collaborative computing power management method based on a cross-architecture state-aware engine, according to an embodiment of this application, is shown.

[0035] Regarding the execution subject of the method in the embodiments of this application, it can be any controller or processor with computing or processing capabilities, such as a computing power scheduling platform controller. In some examples, it can be integrated and configured in an electronic device or terminal through software, hardware, or a combination of software and hardware, and the type of terminal or electronic device can be diverse.

[0036] It should be noted that in the GPU computing pool of a multi-tenant cloud center, resource scheduling is usually based on macro-level indicators such as the utilization rate of physical GPUs or the length of task queues for global resource allocation. However, this strategy ignores the bottleneck at the link layer between the GPU and the CPU. When a link becomes congested, although the GPU instance itself is not overloaded and still appears to be idle, the data transmission link between it and the CPU may be unable to handle more tasks due to bandwidth limitations or excessive communication latency. This situation prevents the seemingly idle GPU instance from receiving new computing tasks, resulting in inefficient task allocation and creating so-called "pseudo-idle" GPU instances.

[0037] Meanwhile, although some resources within the GPU computing pool are actually waiting for tasks, the task scheduling system fails to accurately detect the congestion status of the links. The scheduler prioritizes assigning tasks to GPU instances without link bottlenecks, causing task accumulation on these links and creating a "false busy" phenomenon. Thus, the system exhibits a contradiction: globally, resources are overloaded, while locally, resources are underutilized, leading to inefficient overall resource allocation.

[0038] Therefore, this application proposes a link-level state awareness mechanism to monitor the data transmission path status between the GPU and CPU in real time and react quickly to congestion. This not only dynamically adjusts task allocation and link traffic distribution but also effectively eliminates the "false idle / false busy" phenomenon caused by link bottlenecks, thereby optimizing resource allocation and improving the overall resource utilization and task scheduling efficiency of the system. In a multi-tenant cloud environment, tasks from different tenants may have different priorities and requirements. Through link state awareness and intelligent scheduling, it can be ensured that each tenant's tasks are not unfairly delayed or blocked due to link bottlenecks, thereby improving system fairness and service stability.

[0039] like Figure 1 As shown, in step S110, a set of communication links is established between multiple GPU instances and multiple CPU controllers, and the communication metrics of each communication link are periodically collected to construct the corresponding link state feature vector.

[0040] In multi-tenant cloud centers or high-performance computing centers, multiple GPU instances and multiple CPU controllers need to share computing resources to meet various computing demands. To improve resource utilization efficiency, scheduling systems typically allocate tasks to GPU instances. However, the communication link between GPUs and CPUs can become a bottleneck for system performance, especially when link bandwidth or communication latency exceeds expectations, potentially leading to uneven task scheduling or even resource idleness.

[0041] In a GPU computing pool, a complex network topology typically consists of multiple GPU instances and multiple CPU controllers. The link set contains detailed information about these links, such as high-speed transmission channels like PCIe links, NVLink, and InfiniBand. It's worth noting that the connection methods between GPU instances and CPU controllers in a computing pool can be diverse. For example, a single GPU instance might connect to a CPU controller via a single PCIe channel, or connect to multiple CPU controllers via high-speed network channels like InfiniBand. On the other hand, GPU instances often connect multiple GPUs via NVLink, rather than directly connecting to multiple CPU controllers, to enhance the interconnect bandwidth between GPUs.

[0042] To construct a link set, the status of each link can be obtained through a hardware monitoring interface. The collected communication metrics include, but are not limited to, data throughput, queue length, and communication latency. Queue length reflects the amount of data to be transmitted in the link, data throughput reflects the amount of effective data passing through the link per unit time, and communication latency reflects the delay in the transmission of data packets (or messages) from end to end in the link.

[0043] Furthermore, the aforementioned collected indicators are standardized to form the link state feature vectors for the corresponding links, and each link maintains a state vector sequence for the sampling period. By establishing a set of communication links and collecting link state feature vectors, the performance status of each link can be monitored in real time.

[0044] In step S120, the corresponding communication link is identified as a bottleneck link based on the link status feature vectors.

[0045] In multi-GPU systems, task scheduling is typically based on the utilization of computing resources. However, data transfer links between GPU instances often become performance bottlenecks, especially when bandwidth is limited or communication latency is high. These links may fail to meet the high bandwidth requirements of multiple tasks, leading to performance degradation.

[0046] When identifying bottleneck links, the computing power scheduling platform system may consider multiple factors, such as low throughput, excessively long queue length, and high communication latency. The methods for identifying bottleneck links can also be diverse, including rapid detection using threshold methods, time-series trend analysis, and deep learning models; these will not be limited here. By accurately identifying bottleneck links, the computing power scheduling platform can take timely measures to avoid assigning tasks to these links, thereby preventing task delays and performance degradation.

[0047] In step S130, if the first communication link is determined to be a bottleneck link, the first communication link is split into multiple sub-links.

[0048] Here, link splitting refers to physically dividing a bottleneck link into multiple sub-links. These sub-links share the physical bandwidth resources of the original link, but each has its own independent buffer queue and flow control management. Each sub-link will have its own independent buffer queue to store data packets to be transmitted, thereby preventing congestion in a single queue from causing a decrease in the overall transmission efficiency of the link. Each sub-link will have its own flow control policy to ensure that multiple tasks can be processed in parallel on the same physical link. All sub-links share the physical bandwidth of the original link and can perform flow control based on the current bandwidth load. For example, when a sub-link is overloaded, the flow control mechanism will limit its data transmission rate to prevent it from affecting other sub-links.

[0049] In some implementations, the number of sub-links can be dynamically set based on bottleneck level, total link bandwidth and task concurrency (e.g., splitting a x16 PCIe link into 4 x4 sub-links, with each sub-link corresponding to a task queue), and can support statically pre-configured or dynamically adjusted link splitting schemes.

[0050] More specifically, virtual channel technology (such as the VC mechanism in PCIe / InfiniBand) can be used to allocate independent buffer queues and flow control parameters to each sub-link, achieving true traffic isolation. Sub-link queue management is implemented through DMA channels, hardware queues, or software-defined buffer pools, ensuring high throughput and low latency. Preferably, differentiated flow control strategies can also be specified for different sub-links for different types of tasks (such as training, inference, and data migration).

[0051] Furthermore, maximum queuing length and maximum transmission window can be configured for each sub-link. In the event of a sub-link failure, backup sub-links can be automatically switched or tasks can be reallocated, achieving fault tolerance and self-healing. Thus, refined sub-link management optimizes the "false idle / false busy" phenomenon, significantly improves link bandwidth utilization efficiency and resource isolation in multi-tasking environments, and eliminates global congestion caused by a single traffic source.

[0052] In step S140, the scheduling priority of the sublink is calculated based on the queuing length, data throughput and communication latency of the sublink, and the target sublink for executing the task is selected from the available sublinks according to the scheduling priority during task scheduling.

[0053] After the link is split, the latest status of each sub-link can be evaluated by multi-dimensional indicators, and the scheduling priority can be dynamically calculated to guide the platform controller or scheduling controller to select the best sub-link first when distributing and migrating tasks, so as to achieve dynamic adaptation of tasks to links.

[0054] In some implementations, a weighted fusion calculation can be performed based on indicators such as the queuing length, data throughput, and communication latency of each sub-link, thereby assigning a scheduling priority to each sub-link. For example, the longer the queuing queue, the heavier the current load on the link, and the scheduling priority should be appropriately reduced.

[0055] Then, based on this priority, a suitable sub-link is selected for task allocation during task scheduling. The scheduler will select the most suitable target sub-link from multiple available sub-links and assign the task to that sub-link.

[0056] By using a priority scheduling mechanism for communication between GPU instances and CPUs based on sub-link state awareness, the system intelligently selects the most suitable sub-link for task execution, avoiding the assignment of tasks to sub-links that are overloaded or have high latency. This not only improves the system's task processing efficiency but also effectively avoids the waste of link resources.

[0057] This application's embodiments utilize a refined sub-link management mechanism to monitor and identify link bottlenecks between GPU instances and CPUs in real time. Bottleneck links are broken down into multiple sub-links, each independently managing cache queues and flow control policies. This avoids "false idle" and "false busy" phenomena caused by excessive load on a single link or communication bottlenecks. Through dynamic scheduling based on sub-link status, the scheduling platform can efficiently allocate tasks to the most suitable sub-links, ensuring full resource utilization even with uneven link loads. This significantly improves the overall system resource utilization and task scheduling efficiency, and eliminates imbalances caused by link congestion.

[0058] Regarding the specific construction details of the link state feature vector, in some examples of the embodiments of this application, the communication indicators of each communication link can be collected periodically, and the collected communication indicators can be smoothed by spatiotemporal weighted exponential filtering.

[0059] Specifically, time series data acquisition is periodic, and the specific sampling period interval can be set according to the stability requirements of the link. For example, for high-load and critical task links, the time interval can be set to be shorter.

[0060] To improve the accuracy of link status prediction and avoid misscheduling due to instantaneous fluctuations, a weighted moving average method was used for data smoothing. This method can eliminate instantaneous fluctuations in link performance and obtain a smooth link status curve.

[0061] Equation (1)

[0062] In the formula, Indicates at time t The smoothing index value, Indicates at time t Communication metrics It is a smoothing factor between 0 and 1. Controls the weight between the current link state and the historical state. A larger weight... A value that makes the current link state have a greater impact on the smoothing result; conversely, a smaller value has a greater impact. The value makes historical states have a higher weight in the smoothing calculation.

[0063] The smoothed communication metrics are arranged sequentially to form a link state feature vector. This results in a more stable link state after smoothing, effectively reducing misjudgments caused by instantaneous fluctuations and enabling the system to more accurately identify bottleneck links.

[0064] Figure 2A flowchart illustrating an example of identifying bottleneck links based on link state feature vectors according to an embodiment of this application is shown.

[0065] In step S210, an incremental density estimation algorithm is used to calculate the density value of each link in the state space based on the link state feature vectors of historical time periods and the current time.

[0066] Here, an incremental density estimation algorithm is introduced. Based on the link state feature vectors from historical periods and the current moment, the density value of each link is calculated. This density value can effectively reflect the relative congestion level of the link in the state space, helping the system to identify potential bottleneck links in real time. The algorithmic form of incremental density estimation can be diverse, such as incremental kernel density estimation (Incremental KDE), histogram-based incremental estimation, or incremental GMM (Gaussian Mixture Model), and is not limited here.

[0067] In some examples of embodiments of this application, the state feature vector of each link It consists of multiple communication metrics, such as throughput, queue length, and latency. By fusing the link state feature vector at the current moment with data from historical periods, the density value of each link is calculated using the Gaussian kernel density estimation method.

[0068] The state feature vector is composed of throughput, queue length, communication latency, etc., which are direct indicators of link load. If a link frequently stays in a certain region of the state space (i.e., high density), it indicates that these indicators fall in that region multiple times, reflecting a high-frequency link load pattern. The density value measures the "congestion level" of the link in the state space, that is, whether the link's performance is close to its upper limit of carrying capacity. In a multi-task scheduling environment, a momentary high link load may be accidental, but a sustained high load is a manifestation of bottleneck risk. Therefore, density analysis can effectively reduce the risk of misjudging occasional high link loads.

[0069] Equation (2)

[0070] In the formula, At any moment Calculated link density value, It is a moment The link state feature vector, It is the first in the historical period The state feature vector of the link, The bandwidth of the kernel function controls the smoothness of the density estimation; It refers to the number of historical data points.

[0071] By using an incremental density estimation algorithm, the density of each link in the state space can be dynamically evaluated, thereby identifying the performance change trend of the link, avoiding misjudgment during peak link load periods, and improving the accuracy and sensitivity of bottleneck link identification.

[0072] In step S220, when the density value of the second communication link is detected to exceed the preset density threshold, the dynamic queue length threshold and the dynamic communication delay threshold are calculated based on the average value and standard deviation of the queue length and communication delay of all links in the communication link set at the current time.

[0073] It should be noted that a high density value indicates that the link's state behavior is concentrated in a high-load area over a period of time, exhibiting high queue backlog, long latency, and high throughput, reflecting stable and frequent high-load states. For example, a high link state density value means that its historical states frequently appear in high-load areas in the state space, showing a trend of high-load patterns. Therefore, high-density links mean that the link is frequently in a high-load or near-bottleneck state region, showing a continuous trend of resource strain. It may be in an actual or potential congestion state and is a key focus for bottleneck identification.

[0074] Once high-density links are identified, it confirms that the long-term trend or clustering characteristics of the link status match the behavior pattern of a bottleneck link, but it cannot fully determine whether the link is actually overloaded at the current moment. Therefore, the system will further confirm whether it is a bottleneck link based on the queue length and communication latency of each selected high-density link.

[0075] It should be noted that the performance differences between different links can be significant. Therefore, it is necessary to set dynamic thresholds for each link to more accurately determine whether a link is in a bottleneck state. Specifically, the corresponding thresholds are dynamically adjusted by calculating the average and standard deviation of the queue length and communication latency of all links in the communication link set.

[0076] The queue length of a dynamic queue reflects the load on the link. When the queue length of a link exceeds a certain threshold, it indicates that the link is overloaded and may have become a bottleneck.

[0077] Equation (3)

[0078] In the formula, It is a moment The calculated dynamic queue length threshold, It is the average length of all link queues at the current moment, reflecting the average load level of queues in the system. It is the standard deviation of the queue length, used to measure the range of fluctuation in queue length. It is a regulating factor used to control the sensitivity of the threshold.

[0079] On the other hand, latency reflects the response speed of the link, and high latency usually means that the link is overloaded.

[0080] Equation (4)

[0081] In the formula, It is a moment The calculated dynamic communication latency threshold, It is the average latency of all links at the current moment. It is the standard deviation of communication delay. It is an adjustment factor that determines the sensitivity of the time delay threshold.

[0082] By calculating dynamic thresholds based on the set of communication links, the bottleneck identification criteria can be flexibly adjusted according to the link status distribution of the entire system. This avoids misjudgments caused by fixed thresholds under different load conditions, enabling more accurate assessment of the load status of each link and improving the accuracy of bottleneck link identification. For example, under high load, the queue length of a link may increase in a short period of time, and the dynamic threshold will be adjusted according to the average value and standard deviation of all links in the system, avoiding misjudging short-term fluctuations as bottlenecks and enabling timely identification of the true bottleneck link.

[0083] In step S230, if the current queue length of the second communication link exceeds the dynamic queue length threshold, or if the current communication delay of the second communication link exceeds the dynamic communication delay threshold, then the second communication link is determined to be a bottleneck link.

[0084] The status of a link is determined by calculating its density value, dynamic queue length, and communication latency threshold. When a link's density value is high, and its queue length or communication latency exceeds a dynamic threshold, that link is identified as a bottleneck link. Once a link's density value is found to be below the threshold, the system will adjust the current queue length based on that link's current status. and communication latency Compare with the corresponding dynamic queue length threshold and dynamic delay threshold This determines whether the link is a bottleneck link.

[0085] It should be noted that the communication link status between the GPU and CPU is affected by various dynamic factors, and relying solely on the current load or static thresholds is insufficient to accurately identify bottleneck links. By integrating the identification of high-density links with dynamic threshold determination, the system first filters out high-density links with concentrated loads and potential congestion in the global state space. Then, based on whether the current queuing length and communication latency of the link exceed the dynamically calculated system average threshold, it further determines whether it has become an actual bottleneck. This significantly improves the accuracy and efficiency of bottleneck identification and reduces scheduling deviations or resource waste caused by misjudgments.

[0086] Figure 3 A flowchart illustrating an example of splitting a first communication link into multiple sub-links according to an embodiment of this application is shown.

[0087] like Figure 3 As shown, in step S310, the link pressure index of the first communication link is calculated.

[0088] In heterogeneous multi-tenant computing environments, the usage of communication links dynamically changes with different tasks. The link status at a single moment (such as queue length or communication latency) is often affected by instantaneous fluctuations and cannot fully reflect the link's load capacity. Therefore, to achieve more accurate link splitting decisions, a comprehensive index needs to be constructed to reflect the overall load of the link within a certain time window, i.e., the link pressure index.

[0089] Equation (5)

[0090] In the formula, Indicates the first i The overall pressure index of the bottleneck links, and They represent the first i The bottleneck link's queue length and communication latency at the current moment. and These are the maximum queue length and maximum latency set by the system, respectively; The window length is the sampling period. and They represent the first m Queue length and communication latency at each sampling time, The interval between adjacent sampling times. This refers to the weighting parameters for elastic splitting.

[0091] In equation (5), we introduce the first... iThe system considers the queuing length and communication latency of each link at the current moment, and uses normalization to eliminate the impact of differences in physical link bandwidth and buffering, thus accurately reflecting the real-time load status. Simultaneously, it introduces the load fluctuation trend within a sampling period window, calculating the time averages of the queuing length change rate and the communication latency change rate, which represent the pressure change trend of the link within the sampling window and reflect whether the link is developing towards a bottleneck. Furthermore, a weighted summation of the above factors is used to derive a link pressure index. This index combines the current link status with its changing trend, avoiding misjudgments that may occur based solely on current sampled values.

[0092] In step S320, the splitting intention value of the first communication link is calculated using a nonlinear activation function based on the link pressure index.

[0093] It should be noted that not all high-voltage links need to be split. Instead, the strength of the willingness to split can be judged based on the link stress index. Since the relationship between link stress and whether splitting is necessary is not linear, using a nonlinear activation function (such as the sigmoid) can more naturally describe the nonlinear transition between link stress and the splitting decision.

[0094] Equation (6)

[0095] In the formula, Indicates the first i The willingness to split bottleneck links. This is a steepness adjustment parameter. These are the baseline parameters.

[0096] Thus, when When the willingness value is close to 0 (indicating no need for splitting); when When the willingness value is close to 1 (indicating an urgent need for splitting), the intermediate region exhibits a continuously adjustable transition effect. Through non-linear mapping, the sudden changes in task scheduling caused by the "hard threshold" are avoided, thus improving the smoothness of the system response.

[0097] In step S330, a global analysis is performed on the pressure index of each link in the communication link set to adaptively determine the corresponding splitting threshold.

[0098] There is a correlation between individual link stress and the overall system status. The system should not only make judgments based on the stress of a particular link, but also consider the average stress level of links in the current overall network, in order to avoid mistakenly disconnecting links due to excessively high individual stress, or misjudging low-pressure links as abnormal due to high global load.

[0099] Specifically, the splitting threshold is constructed using the average and maximum values ​​of all current link stress indices:

[0100] Equation (7)

[0101] In the formula, Indicates the splitting threshold. This represents the average stress index of all communication links in the communication link set. This represents the maximum stress index for the corresponding communication link within the set of communication links. These are adjustable weight parameters.

[0102] In equation (7), The system uses adjustable global weight parameters to control the trade-off between "global equilibrium" and "individual extremes." When the system pressure is relatively balanced, It better reflects the overall situation; when an abnormally high voltage occurs on a certain link, This helps prevent the average system load from masking individual extremes. Therefore, it balances the assessment between high individual link loads and the overall system capacity, reducing erroneous and missed link splits and enhancing the system's adaptability to structural differences in link load.

[0103] In step S340, when the splitting intention value is greater than the splitting threshold, the first communication link is adaptively split into multiple sub-links.

[0104] Here, the number of sub-links should be determined incrementally based on the severity of link pressure in order to achieve more refined resource management.

[0105] Equation (8)

[0106] In the formula, The number of sub-links that have been split. The maximum number of sub-links to be split, rounded up. The output is guaranteed to be an integer.

[0107] Considering that the severity of link stress does not always correspond to the number of sub-links in integer multiples, an upward rounding logic is adopted to ensure that the splitting operation responds promptly and adequately to high-pressure links.

[0108] For example, if , ,but This means splitting the link into four sub-links.

[0109] Therefore, the number of sub-links splits changes continuously with the pressure exponent, forming a smooth response curve combined with a nonlinear willingness function. This effectively avoids sudden changes or frequent jitter in link scheduling, improving the continuity and engineering controllability of the scheduling strategy. Fine-tuning the number of sub-links makes task scheduling more flexible, achieving tenant-level flow control isolation and ensuring fairness among tasks, while reducing resource contention.

[0110] In some examples of embodiments of this application, the scheduling priority score of each sub-link is calculated using a scheduling priority function.

[0111] After a link is split, it becomes multiple sub-links. The operating status of each sub-link may differ significantly, such as queue backlog, latency fluctuations, or data congestion. During task scheduling, if tasks are evenly distributed to all sub-links without differentiation, a new load imbalance problem can easily occur, where some sub-links are overloaded while others are idle, thus weakening the performance optimization effect brought about by link splitting.

[0112] ,

[0113] In the formula, , and Representing sub-links Queue length, communication latency, and data throughput; For the weighting coefficients, satisfying ; , and These are the maximum queue length, maximum latency, and maximum data throughput set by the system, respectively.

[0114] By integrating multiple operational metrics through a scoring function, scheduling decisions can comprehensively evaluate link congestion, latency, and throughput, thereby more fully reflecting link availability and improving scheduling accuracy.

[0115] Task scheduling is based on scheduling priority scores. The target sub-link is selected in ascending order for task response.

[0116] During each task scheduling, calculations are performed on all current sub-links. All sub-links are arranged according to Sort values ​​from smallest to largest (smallest is better); select the highest priority (i.e., ... By prioritizing the allocation of tasks to idle, low-latency, and high-throughput sublinks (those with the lowest latency), the system accelerates task access and reduces waiting time and system congestion. Furthermore, the dynamic scheduling mechanism prevents tasks from accumulating on a few seemingly idle (e.g., idle states determined solely by GPU utilization) but actually heavily loaded sublinks, thus preventing new bottlenecks and maintaining a balanced system link state.

[0117] Figure 4 A flowchart is shown as another example of a collaborative management method for computing power based on a cross-architecture state-aware engine, according to an embodiment of this application.

[0118] like Figure 4As shown, in step S410, the sub-link communication metrics of the target sub-link when performing tasks within the sampling period are monitored.

[0119] In a multi-tenant heterogeneous computing environment, the actual communication load of a sub-link after it is selected as a task scheduling target may change rapidly due to the complexity of the task itself, data fluctuations, or external resource interference. Performance cannot be consistently guaranteed solely based on the status score at the time of scheduling. Therefore, by setting a fixed sampling period, key communication metrics of the sub-link are collected in each period, such as the real-time queue length and real-time communication latency, to achieve continuous dynamic awareness of the sub-link's operating status and construct a feedback scheduling mechanism.

[0120] In step S420, if the sublink communication indicators meet the sublink congestion determination conditions, at least one temporary link is selected from the set of backup links to cooperate with the target sublink in sharing the task response.

[0121] Even if the pre-scheduling score is reasonable, the target sub-link may still become congested during task execution due to sudden task backlog or shared resource conflicts. Without dynamic intervention, this will lead to task delays or even failure.

[0122] Here, the sub-link congestion determination condition is that the queue length or communication delay of the target sub-link within the sampling period exceeds a corresponding preset congestion decision threshold. For example, the sub-link congestion determination condition is: or . and These are the congestion judgment thresholds set by the system for queue length and communication latency, respectively.

[0123] Regarding the backup link set, it refers to a set of schedulable physical or virtual link resources reserved or dynamically managed by the system within the GPU-CPU computing power pool and its interconnection network architecture. The deployment of backup link sets can include the following two methods: one is links that physically exist but are not allocated to regular task scheduling, and are only temporarily invoked by the system scheduler under high load or congestion conditions (such as redundant PCIe channels, backup NVLink / InfiniBand links); the other is logical link channels dynamically allocated based on existing physical links through network virtualization or software-defined networking (SDN) mechanisms, whose resources (bandwidth, cache) can be temporarily allocated and reclaimed as needed during system operation.

[0124] In practical applications, the system continuously monitors the status of all working links. When a target sub-link experiences congestion indicators such as queue backlog or communication delay, the system dynamically selects at least one low-load or idle backup link from the backup link set based on the current load and task priority, designating it as a temporary link. This temporary link is allocated an independent buffer and flow control policy, and works in conjunction with the congested sub-link to share some task traffic, achieving task data offloading and elastic scaling, ensuring the processing performance of high-priority or latency-sensitive tasks.

[0125] Furthermore, after task traffic decreases or sub-link congestion eases, the system continuously assesses the load of temporary links. When the communication metrics of the target sub-link and its temporary cooperating links return to normal and remain below the merging threshold, the scheduler reclaims the temporary links, releases their occupied resources, and reintegrates them into the backup link set for subsequent elastic scheduling. Thus, through the backup link set, efficient recycling of link resources is achieved, enhancing the ultimate service capacity and resource pooling elasticity of the entire GPU computing power pool. This enables fine-grained management and elastic scaling of the link layer with minimal physical resource redundancy, providing superior service guarantees and system stability for multi-tenant, high-concurrency business scenarios.

[0126] In step S430, if the sub-link communication indicators meet the sub-link merging determination conditions, the target sub-link and at least one sibling sub-link split from the same parent link are merged into a single link.

[0127] When certain sub-links are continuously under low load (e.g., short queues, low latency, low throughput), retaining their independent existence would waste resources and increase the complexity of system scheduling and management. Therefore, the system should have a merging mechanism to merge a sub-link back into its sibling link that split from the same parent link after determining that the sub-link has been under low load for an extended period, thus reorganizing it into a single communication link.

[0128] Here, the sub-link merging determination condition is that in consecutive... L Within each sampling period, the queue length and communication latency of the target sub-link are both less than the corresponding preset merging decision threshold. For example, the merging decision condition (based on consecutive sampling periods) can be set to a number of consecutive observation periods. L (e.g., 3-5 sampling periods).

[0129] For example, the criteria for merging are:

[0130]

[0131] If the above conditions are met, the system considers the sub-link to be under continuous low load. It can select idle or lightly loaded sibling sub-links under the same parent link to merge and reconstruct a single link, effectively reclaiming idle sub-link resources, avoiding a large number of underutilized sub-links, reducing link management complexity, and optimizing system overhead and resource waste.

[0132] In this embodiment, by monitoring the link status in real time, sub-link segmentation is first implemented on the bottleneck link to achieve queue isolation in a multi-task environment, effectively preventing the "false idle / false busy" phenomenon of GPU instances. Furthermore, congestion status is monitored at the sub-link level. If extreme congestion (true busy) occurs, resources from the backup link set are automatically introduced as temporary links to share the load, improving the system's extreme elasticity and service capacity. Through a closed-loop mechanism of splitting-merging and elastic scaling, fine-grained management and adaptive scheduling of the link layer in a multi-tenant computing pool environment are achieved.

[0133] On the other hand, by continuously sampling and detecting the queue length and communication latency of sub-links, when the key indicators of the target sub-link and its sibling sub-links are all below a preset threshold for L consecutive sampling windows, these sub-links are automatically merged into a single link. This effectively reclaims scattered resources, simplifies system management, reduces the negative impact of scheduling fragmentation and load fluctuations on resource utilization, and achieves adaptive, fine-grained management and dynamic resource aggregation at the link level.

[0134] To verify the effectiveness of the proposed method, we designed a simulation-based comparative experiment. The experiment was conducted on a simulated multi-tenant GPU-CPU cluster, including links between several GPU instances and CPUs. The system simulated different task loads and link states, and recorded metrics such as task completion time, link throughput, and average latency.

[0135] 1) Experimental setup

[0136] System topology: Simulates a node containing 8 GPU instances and 4 CPUs. Each GPU instance is interconnected with all CPUs via a shared PCIe / NVLink link; GPUs are interconnected with each other via NVLink.

[0137] Load model: Tasks are divided into two categories: training tasks and inference tasks. The task lengths follow a normal distribution, and task arrivals are generated according to a Poisson process. In different experiments, the peak load increased from 50% to 100%.

[0138] Algorithm selection comparison:

[0139] Static: Traditional static scheduling, which does not perform link splitting and schedules tasks in a fixed queue;

[0140] MIG Dynamics: Based on the MIGRator concept, scheduling is achieved solely by dynamically adjusting the number and size of MIG instances;

[0141] Proposed CSAE: The cross-architecture state-aware engine proposed in this paper implements link splitting, refactoring and priority scheduling, and introduces CSAE (Cross-architecture State-aware Engine) learning.

[0142] The following metrics are selected: average task completion time, link throughput, and average communication latency.

[0143] 2) Simulation Results

[0144] Figure 5 The simulation results show an example of the impact of different scheduling methods on the average task completion time under the same computing power pool load.

[0145] like Figure 5 As shown, traditional static scheduling methods generally have high and fluctuating task completion times due to their inability to detect bottlenecks. The MIG dynamic reconfiguration method achieves some latency optimization compared to static scheduling by dynamically adjusting GPU instance partitioning, but it still suffers from link congestion under high load. The CSAE method proposed in this paper effectively distributes link load through link-level state awareness and fine-grained sub-link splitting, significantly reducing the average task completion time and exhibiting more stable task scheduling efficiency across different time slices.

[0146] Figure 6 A simulation illustration shows an example of the impact of the splitting threshold on system throughput and communication latency performance. (Example:) Figure 6 As shown, the horizontal axis represents the splitting threshold parameter, and the vertical axis represents performance metrics. Throughput is measured in tasks per second (tasks / second), and latency is measured in milliseconds (ms). As the splitting threshold increases, system throughput significantly improves, indicating that link splitting is more cautious at higher thresholds, contributing to improved overall task processing capacity. In contrast, communication latency remains relatively stable across different threshold settings, without significant fluctuations. Therefore, the link splitting mechanism primarily affects system throughput, with a smaller impact on communication latency, helping to improve the processing efficiency and resource utilization of the computing pool without sacrificing service response speed.

[0147] Experimental results show that the CSAE method significantly outperforms traditional methods under various loads. Dynamic splitting at the link layer enables the diversion of burst traffic, reducing queue backlog and latency. In addition, priority scheduling and adaptive learning enable the system to adjust its strategy in real time according to the link status, avoiding false idle / false busy phenomena. Compared with the MIG dynamic method, CSAE not only adjusts GPU instance resources but also pays attention to the link layer status, thus maintaining good performance in GPU-CPU communication congestion scenarios.

[0148] This application proposes a collaborative computing power management method for GPU-CPU heterogeneous environments, achieving link-level state awareness, dynamic splitting, and intelligent reconfiguration, providing a new technical approach for GPU scheduling in multi-tenant cloud centers. Future work can further validate the CSAE framework in actual hardware environments and explore its collaborative optimization with modern interconnect technologies (such as NVSwitch and CXL).

[0149] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of combined actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Secondly, 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 this application. In the above embodiments, the descriptions of each embodiment have their own emphasis; for parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0150] Figure 7 A structural block diagram of an example of a computing power collaborative management system based on a cross-architecture state-aware engine, according to an embodiment of this application, is shown.

[0151] like Figure 7 As shown, the computing power collaborative management system 700 based on the cross-architecture state awareness engine includes a data acquisition unit 710, a bottleneck link identification unit 720, a bottleneck link splitting unit 730, and a task allocation unit 740.

[0152] The data acquisition unit 710 is used to establish a set of communication links between multiple GPU instances and multiple CPU controllers, and periodically collect communication metrics for each communication link to construct a corresponding link status feature vector; the communication metrics include data throughput, queue length and communication latency.

[0153] The bottleneck link identification unit 720 is used to identify whether the corresponding communication link is a bottleneck link based on each of the link status feature vectors.

[0154] The bottleneck link splitting unit 730 is used to split the first communication link into multiple sub-links if it is determined that the first communication link is a bottleneck link; each sub-link is allocated an independent buffer queue and flow control policy, and each sub-link shares the physical bandwidth of the first communication link.

[0155] The task allocation unit 740 is used to calculate the scheduling priority of the sub-link based on the queuing length, data throughput and communication latency of the sub-link, and select the target sub-link for executing the task from the available sub-links according to the scheduling priority during task scheduling.

[0156] In some embodiments, this application provides a non-volatile computer-readable storage medium storing one or more programs including execution instructions. The execution instructions can be read and executed by electronic devices (including but not limited to computers, servers, or network devices) to perform the steps of any of the above-described computing power collaborative management methods based on cross-architecture state-aware engines.

[0157] In some embodiments, this application also provides a computer program product, the computer program product including a computer program stored on a non-volatile computer-readable storage medium, the computer program including program instructions, which, when executed by a computer, cause the computer to perform the steps of any of the above-described methods for collaborative management of computing power based on a cross-architecture state-aware engine.

[0158] In some embodiments, this application also provides an electronic device, comprising: at least one processor, and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform steps of a computing power collaborative management method based on a cross-architecture state-aware engine.

[0159] The above-described product can perform the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for performing the methods. Technical details not described in detail in this embodiment can be found in the methods provided in the embodiments of this application.

[0160] The electronic devices in this application can exist in various forms, including but not limited to: mobile communication devices, ultra-mobile personal computer devices, portable entertainment devices, or other airborne electronic devices with data interaction functions.

[0161] The device embodiments described above are merely illustrative. 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 modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0162] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0163] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for collaborative management of computing power based on a cross-architecture state-aware engine, characterized in that, The method includes: A set of communication links is established between multiple GPU instances and multiple CPU controllers, and communication metrics for each communication link are periodically collected to construct a corresponding link state feature vector; the communication metrics include data throughput, queue length, and communication latency. Based on the link state feature vectors, identify whether the corresponding communication link is a bottleneck link; If the first communication link is determined to be a bottleneck link, then the first communication link is split into multiple sub-links; each sub-link is allocated an independent buffer queue and flow control policy, and each sub-link shares the physical bandwidth of the first communication link; The scheduling priority of the sub-link is calculated based on the queuing length, data throughput and communication latency of the sub-link, and the target sub-link for executing the task is selected from the available sub-links according to the scheduling priority during task scheduling. The step of splitting the first communication link into multiple sub-links includes: Calculate the link pressure index of the first communication link: ， In the formula, Indicates the first i The overall pressure index of the bottleneck links, and They represent the first i The bottleneck link's queue length and communication latency at the current moment. and These are the maximum queue length and maximum latency set by the system, respectively; The window length of the sampling period. and They represent the first m Queue length and communication latency at each sampling time, The interval between adjacent sampling times. For elastic splitting weight parameters; Based on the link pressure index, the splitting intention value of the first communication link is calculated using a non-linear activation function: ， In the formula, Indicates the first i The willingness to split bottleneck links. This is a steepness adjustment parameter. Baseline parameters; A global analysis of the pressure index of each link in the communication link set is performed to adaptively determine the corresponding splitting threshold: ， In the formula, Indicates the splitting threshold. This represents the average stress index of all communication links in the communication link set. This represents the maximum stress index for the corresponding communication link within the set of communication links. These are adjustable weight parameters; When the splitting intention value is greater than the splitting threshold, the first communication link is adaptively split into... Sub-link: ， In the formula, This is the maximum number of sub-links that can be split.

2. The method according to claim 1, characterized in that, The periodic collection of communication metrics for each communication link to construct a corresponding link state feature vector includes: Communication metrics for each communication link are periodically collected, and the collected metrics are smoothed using a spatiotemporal weighted exponential filter. ， In the formula, Indicates at time t The smoothing index value, Indicates at time t Communication metrics A smoothing factor between 0 and 1; The link state feature vector is composed of the parameters of each indicator in the smoothed communication indicator in sequence.

3. The method according to claim 1, characterized in that, The step of identifying whether a corresponding communication link is a bottleneck link based on each of the link state feature vectors includes: An incremental density estimation algorithm is used to calculate the density value of each link in the state space based on the link state feature vectors of historical periods and the current time. When the density value of the second communication link is detected to exceed the preset density threshold, the dynamic queue length threshold and the dynamic communication delay threshold are calculated based on the average and standard deviation of the queue length and communication delay of all links in the communication link set at the current time. If the current queue length of the second communication link exceeds the dynamic queue length threshold, or if the current communication delay of the second communication link exceeds the dynamic communication delay threshold, then the second communication link is determined to be a bottleneck link.

4. The method according to claim 3, characterized in that, The process of calculating the scheduling priority of a sub-link based on its queuing length, data throughput, and communication latency, and selecting a target sub-link for task execution from available sub-links during task scheduling according to the scheduling priority, includes: The scheduling priority score for each sub-link is calculated using the scheduling priority function: ， In the formula, , and Representing sub-links Queue length, communication latency, and data throughput; Let be the weighting coefficient, satisfying ; , and These are the maximum queue length, maximum latency, and maximum data throughput set by the system, respectively. Task scheduling is based on scheduling priority scores. The target sub-link is selected in ascending order for task response.

5. The method according to claim 4, characterized in that, The method further includes: Monitor the sub-link communication metrics of the target sub-link when it performs tasks within the sampling period; If the sub-link communication metrics meet the sub-link congestion determination criteria, at least one temporary link is selected from the backup link set to coordinate with the target sub-link in task response; the sub-link congestion determination criteria are that the queue length or communication delay of the target sub-link within the sampling period is greater than the corresponding preset congestion decision threshold; and If the sub-link communication metrics meet the sub-link merging criteria, then the target sub-link and at least one sibling sub-link split from the same parent link are merged into a single link; the sub-link merging criteria are that in consecutive... L The queue length and communication latency of the target sub-link within each sampling period are both less than the corresponding preset merging decision threshold.

6. A computing power collaborative management system based on a cross-architecture state-aware engine, characterized in that, The system includes: The data acquisition unit is used to establish a set of communication links between multiple GPU instances and multiple CPU controllers, and periodically collect communication metrics for each communication link to construct a corresponding link status feature vector; the communication metrics include data throughput, queue length, and communication latency. The bottleneck link identification unit is used to identify whether the corresponding communication link is a bottleneck link based on each of the link status feature vectors. The bottleneck link splitting unit is used to split the first communication link into multiple sub-links if it is determined that the first communication link is a bottleneck link; each sub-link is allocated an independent buffer queue and flow control policy, and each sub-link shares the physical bandwidth of the first communication link; The task allocation unit is used to calculate the scheduling priority of the sub-link based on the queuing length, data throughput and communication latency of the sub-link, and select the target sub-link for executing the task from the available sub-links according to the scheduling priority during task scheduling; The step of splitting the first communication link into multiple sub-links includes: Calculate the link pressure index of the first communication link: ， In the formula, Indicates the first i The overall pressure index of the bottleneck links, and They represent the first i The bottleneck link's queue length and communication latency at the current moment. and These are the maximum queue length and maximum latency set by the system, respectively; The window length of the sampling period. and They represent the first m Queue length and communication latency at each sampling time, The interval between adjacent sampling times. For elastic splitting weight parameters; Based on the link pressure index, the splitting intention value of the first communication link is calculated using a non-linear activation function: ， In the formula, Indicates the first i The willingness to split bottleneck links. This is a steepness adjustment parameter. Baseline parameters; A global analysis of the pressure index of each link in the communication link set is performed to adaptively determine the corresponding splitting threshold: ， In the formula, Indicates the splitting threshold. This represents the average stress index of all communication links in the communication link set. This represents the maximum stress index for the corresponding communication link within the set of communication links. These are adjustable weight parameters; When the splitting intention value is greater than the splitting threshold, the first communication link is adaptively split into... Sub-link: ， In the formula, This is the maximum number of sub-links that can be split.

Images