Asymmetric multi-gpu compute resource allocation method and system

Abstract

The application belongs to the technical field of GPU resource scheduling, and specifically discloses an asymmetric multi-GPU computing resource allocation method and system, aiming to solve the problem that in a 5G NR software-defined radio system, the asymmetric GPU computing power difference and data dependence cause large cross-GPU communication overhead, and the traditional scheduling strategy is difficult to meet the microsecond-level real-time constraint. The application establishes a task data dependence hypergraph model to uniformly represent the computing and communication cost, uses the chain and anti-chain mechanism in the quasi-ordered set to determine the task priority and parallel scheduling order, and solves the optimal anti-chain combination for task allocation with the optimization target of minimizing the longest GPU time consumption. The application can effectively reduce the additional transmission delay caused by cross-GPU data dependence, control the multi-task computing delay within the real-time time limit specified in the 3GPP protocol, and significantly improve the reliability and computing power resource utilization rate of multi-thread real-time signal processing.

Description

Technical Field

[0001] This invention relates to the field of GPU (Graphics Processing Unit) technology, and in particular to an asymmetric multi-GPU computing resource allocation method and system. Background Technology

[0002] In 5G New Radio (NR) systems, the complexity of physical layer signal processing algorithms has increased dramatically. Traditional processing architectures relying solely on general-purpose central processing units (CPUs) are no longer sufficient to meet stringent real-time requirements. Therefore, modern Software Defined Radio (SDR) systems commonly employ a heterogeneous computing architecture combining CPUs and GPUs. This offloads computationally intensive tasks such as channel estimation, equalization, Fast Fourier Transform (FFT), and LDPC (Low-Density Parity-Check) decoding to GPUs for hardware acceleration. As 5G NR continues to demand higher throughput and lower latency, the computing power of a single GPU is often insufficient to support the concurrent processing needs of multiple threads and slots. Therefore, multi-GPU collaborative computing solutions are frequently adopted in practical deployments.

[0003] In a multi-threaded NR SDR system, each thread independently processes a segment of received timeslot data and completes all physical layer algorithms within the real-time time limit specified by the protocol. This time limit is jointly determined by the parameter K1 of the downlink control information (DCI) in the 3GPP TS 38.213 protocol (i.e., the acknowledgment information must be fed back within K1 timeslots after the Physical Downlink Shared Channel (PDSCH) is received) and the timeslot duration defined by the 3GPP TS 38.211 protocol, and is typically only a few hundred microseconds. To meet this stringent real-time constraint, the system must efficiently utilize the computing resources of multiple GPUs.

[0004] However, existing methods for allocating computing resources for multiple GPUs have the following main shortcomings:

[0005] First, there is a lack of fine-grained adaptation to the asymmetric differences in GPU computing power. In real-world systems, the computing power of multi-GPU systems often exhibits asymmetric characteristics due to factors such as differences in PCIe bandwidth, generational differences in GPU architecture, and the span of NUMA (Non-Uniform Memory Access) nodes. Traditional load balancing strategies assume that all GPUs have the same performance and distribute tasks evenly, resulting in fast GPUs being idle while waiting for slow GPUs, or severe scheduling blockages due to overload of slow GPUs, thus exceeding real-time deadlines.

[0006] Second, it ignores the data dependencies between tasks and the resulting cross-GPU communication overhead. Signal processing tasks in NR SDR systems have explicit data dependency chains (e.g., the output of the FFT must be passed to the channel estimation and equalization module). When two dependent tasks are assigned to different GPUs, data backhaul and retransmission must be completed between them, and the resulting additional communication latency is not negligible under microsecond-level real-time constraints. Existing scheduling methods either assume that tasks are completely independent or only consider sequential dependencies within a single thread, failing to provide a unified model and optimization for cross-GPU data dependency conflicts.

[0007] Third, the native scheduling strategies provided by the GPU driver layer are not suitable for SDR real-time scenarios. Existing GPU drivers only allow one thread to operate in a single context, and simultaneous calls from multiple threads will cause thread conflicts and additional waiting overhead; while context isolation or stream isolation methods either destroy data interoperability or distribute GPU computing power evenly, causing task execution time to increase exponentially. The scheduling strategies designed for scenarios such as games and artificial intelligence cannot meet the dual requirements of first-in-first-out (FIFO) and microsecond-level deadlines in SDR systems.

[0008] Fourth, there is a lack of lightweight online scheduling decision-making mechanisms for real-time constraints. Theoretically, allocating tasks to multiple GPUs can be modeled as a combinatorial optimization problem, requiring exponential time for accurate solutions, making it unusable online. Existing heuristic methods (such as minimum completion time first and critical path scheduling) have low computational overhead, but they are difficult to adapt to dynamic environments coupled with asymmetric computing power and complex data dependencies. While neural network-based intelligent scheduling methods have strong fitting capabilities, deploying their inference process on GPUs would consume already limited computing power, and deploying it on CPUs might introduce additional scheduling delays due to excessive model computation, making it counterproductive. Summary of the Invention

[0009] This invention provides an asymmetric multi-GPU computing resource allocation method and system, which solves the technical problem of: how to design a multi-GPU resource allocation scheme that can adapt to the asymmetric GPU environment, effectively reduce cross-GPU communication overhead, and has low-overhead online decision-making capabilities, under the limited GPU computing power resources and considering the characteristics of multi-threading, strong real-time and data-dependent intensive 5G NR SDR systems.

[0010] To address the above technical problems, this invention provides an asymmetric multi-GPU computing resource allocation method, comprising:

[0011] The prior task information is described, including the sequence of multi-threaded tasks executed in a predetermined order, the task data dependencies between assigned and unassigned tasks in the multi-threaded task sequence, and the current state of the asymmetric GPU.

[0012] The task data dependency relationship is modeled using a hypergraph model to obtain a task data dependency hypergraph model;

[0013] Based on the prior task information, the task priority and parallel scheduling order are determined for unassigned tasks using the chain and anti-chain mechanism in the quasi-order set.

[0014] Based on the task data dependency hypergraph model and the prior task information, with the goal of minimizing the longest GPU time and the constraint that the load of the task at the end of any GPU queue meets the real-time requirements of that GPU, the optimal anti-chain combination is solved.

[0015] The tasks to be assigned are distributed to the corresponding GPUs according to the optimal anti-chain combination.

[0016] Furthermore, the construction process of the task data-dependent hypergraph model is as follows:

[0017] Define a set of nodes and a set of hyperedges. The nodes in the set of nodes include tasks that are being executed, have been executed, and are yet to be executed. The hyperedges in the set of hyperedges include compute-bearing hyperedges and data-dependent hyperedges. The compute-bearing hyperedges represent a set of tasks assigned to the same GPU. The data-dependent hyperedges represent a group of tasks that have data dependencies.

[0018] Furthermore, the chains in the quasi-order set are used to establish priority relationships. The comparability between tasks is established by prior task information and the order of task requests, and chains are generated to represent a set of task flows that must be executed serially in a predetermined order. The length and position of the tasks are determined by the order and priority of the tasks.

[0019] Furthermore, the anti-chain is selected by the nodes in the chain to plan to a specific GPU, with one anti-chain corresponding to one GPU; the anti-chain is used to distinguish the set of parallel tasks between different GPUs, and tasks belonging to the same anti-chain are assigned to the corresponding hyperedge; a combination of anti-chains represents a set of independent tasks that are not comparable in order, corresponding to the current task allocation scheme.

[0020] Furthermore, in the process of finding the optimal antichain combination, the GPU time corresponding to an antichain is equal to the sum of the time of all tasks on that GPU.

[0021] Furthermore, when a task has no cross-GPU dependency, the time taken by the task is equal to the relative computing power of the GPU to which it is allocated multiplied by the time taken by the task in the baseline GPU; when a task has cross-GPU dependency, the time taken by the task is equal to the product of the relative computing power of the GPU to which it is allocated and the time taken by the task in the baseline GPU, plus the cross-GPU communication latency of the task.

[0022] Furthermore, if all tasks in a thread have been assigned and the order condition in the prior task information is satisfied, then the completion time of the last task in the thread is equal to the completion time of the task in the GPU queue; the total load of a thread is equal to the sum of the time taken by the last task and all previous tasks in the task queue of the GPU where the last task of the thread is located.

[0023] Furthermore, the optimal GPU index is:

[0024] The scheduling decision function selects the GPU with the lowest cost as the GPU to carry the current task. The feature vector includes the index of the current GPU, the load status of the current GPU, whether assigning the current task to the current GPU will introduce data dependency conflicts, and the priority of the current task. The scheduling decision function is obtained by offline fitting and distillation of a neural network model, which means selecting the GPU with the lowest cost as the GPU to carry the current task.

[0025] Furthermore, when a new task is generated, the task is added to the end of the chain, and the chain is reordered according to priority. The priority is determined by the execution time of the current task's predecessor dependent tasks, the time the current task waits for allocation, and the time limit for the real-time requirement of the Slot thread. If the predecessor task of the reordered current node has been completed, GPU allocation is performed on the current node. If it has not been completed, the node is skipped, and the judgment and allocation of the next node is carried out.

[0026] This invention also provides an asymmetric multi-GPU computing resource allocation system. The key features of the asymmetric multi-GPU computing resource allocation method are: a bus device layer, a resource scheduling layer, and a program layer. The bus device layer defines the baseline GPU performance and provides the required performance requirements in NR SDR. The resource scheduling layer analyzes the data dependencies between various GPU tasks to establish a task data dependency hypergraph model and uses a pseudo-order set to determine task priorities and arrange the execution order of multiple tasks to be allocated. The program layer utilizes the data from the resource scheduling layer and fits the resource scheduling model through a neural network model to perform task scheduling for multiple GPUs with different computing power.

[0027] This invention provides an asymmetric multi-GPU computing resource allocation method and system that addresses the technical challenges of asymmetric GPU computing power differences, high cross-GPU data dependency communication overhead, and the inability of traditional scheduling strategies to meet microsecond-level real-time constraints during multi-threaded concurrent processing in 5G NR software-defined radio systems. It establishes a task data dependency hypergraph model to uniformly represent task execution time, heterogeneous GPU computing power, and cross-device communication costs. It utilizes chain and anti-chain mechanisms in quasi-ordered sets to determine task priorities and parallel scheduling order. Furthermore, it employs a neural network to fit the optimal allocation strategy and then constructs a lightweight cost function through symbolic distillation, thereby achieving low-overhead online scheduling decisions. This invention effectively reduces the additional transmission latency caused by cross-GPU data dependency conflicts in asymmetric multi-GPU environments, controlling the multi-task computing latency under complex data dependencies and task priority coupling within the real-time limits specified by the 3GPP protocol, significantly improving the reliability and computing resource utilization of multi-threaded real-time signal processing. Attached Figure Description

[0028] Figure 1 This is an overall framework diagram of the asymmetric multi-GPU computing resource allocation method and system provided in the embodiments of the present invention;

[0029] Figure 2 This is a schematic diagram illustrating the principle of multi-threaded multi-GPU access in the NR SDR system in this embodiment of the invention;

[0030] Figure 3 This is a schematic diagram illustrating the computing power required by the NR SDR system in this embodiment of the invention;

[0031] Figure 4 This is a schematic diagram illustrating the process of multiple threads directly calling the GPU through the driver in an embodiment of the present invention;

[0032] Figure 5 This is a schematic diagram of the GPU scheduling process after adding a scheduler in an embodiment of the present invention;

[0033] Figure 6 This is a framework diagram of the asymmetric GPU task scheduler in an embodiment of the present invention;

[0034] Figure 7 This is a schematic diagram of the task order dependency relationship within a single thread in an embodiment of the present invention;

[0035] Figure 8 This is a schematic diagram of an example of a task data dependency hypergraph model in an embodiment of the present invention;

[0036] Figure 9 This is a schematic diagram of the task prototyping and sorting model in an embodiment of the present invention;

[0037] Figure 10 This is a schematic diagram of the anti-chain construction process in an embodiment of the present invention;

[0038] Figure 11 This is an overall flowchart of the asymmetric multi-GPU computing resource allocation method in this embodiment of the invention;

[0039] Figure 12 This is a training loss curve of the policy neural network fitting model in an embodiment of the present invention;

[0040] Figure 13 This is a graph showing the polynomial regression fitting results in an embodiment of the present invention;

[0041] Figure 14 This is a comparison chart of the end-point task completion time in scenarios where a single card has sufficient computing power but insufficient hardware resources, as described in this embodiment of the invention.

[0042] Figure 15 This is a comparison chart of the end-point task completion time under scenarios where single-card computing power and hardware resources are sufficient in the embodiments of the present invention;

[0043] Figure 16 This is a comparison chart of the end-point task completion time in a symmetrical dual-card scenario (single card does not meet computing power requirements) according to an embodiment of the present invention;

[0044] Figure 17 This is a comparison chart of the end-task completion time in a symmetrical dual-card scenario (single card meets computing power requirements) according to an embodiment of the present invention;

[0045] Figure 18 This is a comparison chart of the end-point task completion time in a symmetrical three-card scenario (single card does not meet computing power requirements) according to an embodiment of the present invention;

[0046] Figure 19 This is a comparison chart of the end-point task completion time in a symmetrical three-card scenario (single card meets computing power requirements) according to an embodiment of the present invention;

[0047] Figure 20 This is a comparison chart of the end-task completion time in an asymmetric dual-card (upgrading one GPU) scenario according to an embodiment of the present invention;

[0048] Figure 21 This is a comparison chart of the end-task completion time in a symmetrical dual-card scenario (for comparison) according to an embodiment of the present invention;

[0049] Figure 22 This is a comparison chart of the end-task completion time in an asymmetric three-card (upgrading one GPU) scenario according to an embodiment of the present invention;

[0050] Figure 23 This is a comparison chart of the end-point task completion time in a symmetrical three-card scenario (for comparison) according to an embodiment of the present invention;

[0051] Figure 24This is a comparison chart of the end-task completion time in the scenario of expanding from symmetrical dual-card to asymmetrical triple-card in an embodiment of the present invention;

[0052] Figure 25 This is a comparison chart of the end-task completion time of the original symmetrical dual-card system (as a comparison) in an embodiment of the present invention. Detailed Implementation

[0053] The embodiments of the present invention are described in detail below with reference to the accompanying drawings. The embodiments are given for illustrative purposes only and should not be construed as limiting the present invention. The accompanying drawings are for reference and illustration only and do not constitute a limitation on the scope of patent protection of the present invention, because many changes can be made to the present invention without departing from the spirit and scope of the present invention.

[0054] In the scenario of multi-threaded multi-GPU calls in NR SDR systems, this paper addresses the problem that multi-threaded collaborative scheduling under limited GPU computing resources cannot meet the latency requirements of 5G NR. It proposes an asymmetric multi-GPU computing resource allocation method and system, the framework of which is shown in the figure below. Figure 1 As shown, firstly, a baseline GPU performance is defined at the bus device layer, and the required performance requirements in NR SDR are given. Then, at the resource scheduling layer, the data dependencies between various GPU tasks (i.e., the execution order constraints formed by data generation and usage between tasks) are analyzed, a task data dependency hypergraph model is established, and a quasi-order set is used to determine the execution order of multiple tasks to be assigned based on task priorities. Based on this, at the program layer, using the data from the resource scheduling layer, a neural network model is used to fit the resource scheduling model to achieve task scheduling of multiple GPUs with different computing power, thereby reducing the latency of multi-task computation under complex data dependencies and different task priorities.

[0055] (1) Resource scheduling model for multi-threaded and multi-GPU systems in NR SDR system

[0056] Establish a multi-threaded and multi-GPU scheduling model within the NR SDR system at the bus device layer, define the baseline GPU performance and quantify the performance unit to microseconds, and give the required performance requirements in NR SDR.

[0057] A simulation environment for an NR SDR system is defined. It is assumed that the NR SDR system is a multi-threaded system, where each thread processes a segment of received time slot data. During this process, the radio sampled data undergoes multiple signal processing steps, including channel estimation. In the 5G NR protocol, after receiving a radio frame, downlink data needs to return whether the data in that frame has been transmitted successfully within a certain time. This timeframe serves as the real-time constraint that the NR SDR system needs to achieve.

[0058] In the NR SDR system, the real-time requirement of the Slot thread is determined by the DCI information in the 3GPP TS 38.213 protocol. With respect to the time slots specified in the 3GPP TS 38.211 protocol (Slot Duration, SD) is jointly determined. In DCI information... The parameter means that after receiving the downlink data code block, in After each time slot, report whether the current code block has been received correctly. Define the real-time requirement time limit as:

[0059] ,

[0060] Right now The internal algorithm needs to complete all the algorithms for this frame of data.

[0061] Figure 2 This is a schematic diagram illustrating the multi-threaded multi-GPU operation of NR SDR. Figure 2 As shown, when multiple threads exist, these threads initiate multiple computation requests, delegating the signal processing algorithm's computation to the GPU. Every... At a certain time, one thread will send the first task's computation request to the GPU, and at an interval... The next computation request is sent at the designated time. Each thread has a total of [number missing]. Each thread needs to perform a computational task request. The end data of the last task is received within the microsecond real-time limit, i.e. The completion time for each task shall not exceed Microseconds, otherwise timeout. During scheduling, the latency caused by random driver and scheduling events during GPU asynchronous acceleration is satisfied.

[0062] Meanwhile, the total computing power of the multi-GPU system needs to meet the basic computing power required by all algorithms within a frame of information; otherwise, the corresponding real-time performance cannot be achieved in a physical sense. To simplify modeling, this embodiment uniformly represents computing power as time microseconds and defines the equivalent number of benchmark tasks that a benchmark GPU can process per unit time. Within a thread, the time consumed by each task on the benchmark GPU is... This setting accommodates the latency caused by random driver and scheduling issues during GPU asynchronous acceleration. It is a continuous probability distribution in probability theory, also known as a rectangular distribution. The interval is defined by parameters a and b, and its probability density function is a constant 1 / (ba) in the interval [a,b].

[0063] Figure 3 This is a diagram illustrating the computing power required for the NR SDR system. (Example:) Figure 3 As shown, in At microsecond intervals, Under microsecond real-time constraints, the total GPU computing power needs to meet the computing power requirements of two threads. According to the above task requirements, The total time for each task must comply with the Central Limit Theorem:

[0064] ,

[0065] in, It follows a normal distribution. It is the expected value (mean) of the normal distribution. It is the variance of the normal distribution; For the total task time, set a probability of over 84% that the task can be completed in real time, ensuring that... Within the time limit, it can process the equivalent of the time taken by a benchmark GPU. The computational load is sufficient to meet the real-time requirements of a single thread. To meet the requirements of all threads under the above conditions, it is necessary to... The equivalent computing power.

[0066] (2) Asymmetric GPU scheduling overhead and data dependency

[0067] This section analyzes the overhead incurred by multi-threaded GPU calls and proposes methods to mitigate this overhead using a scheduler. It briefly describes asymmetric GPU scenarios, scheduling overhead caused by multi-threaded GPU preemption, and transmission overhead caused by data dependency conflicts.

[0068] Asymmetric GPU scenarios arise when using multi-GPU collaborative computing. Influenced by factors such as differences in PCIe bandwidth, heterogeneous GPU architectures, and NUMA node spanning multiple nodes, multi-GPU systems often exhibit asymmetric computing power. This asymmetry leads to fast GPUs idling while waiting for slower GPUs. When tasks on fast GPUs must wait for tasks on slower GPUs to complete before execution, severe scheduling blockage occurs.

[0069] Table 1 shows the test results of performance differences between different GPUs. As can be seen from Table 1, there are significant differences in the computation time required for different GPUs to run the same operator.

[0070] Table 1 GPU Performance Difference Test

[0071]

[0072] Considering the differences in GPU computing power, the task allocation process matches asymmetric conditions such as computing power with priorities to ensure real-time performance.

[0073] GPU scheduling overhead manifests itself in the scenario where multiple threads simultaneously utilize the GPU as hardware acceleration; different invocation methods result in varying execution times. In NR SDR systems, when multiple threads share the same GPU Context, they can all invoke the GPU to perform computations, but this can lead to thread conflicts, causing additional waiting overhead for the GPU driver. Using simple alternating allocation with mutual exclusion produces regular alternating execution, but threads experience additional mutual exclusion waiting. In NR SDR systems, latency is relatively sensitive; therefore, an additional active allocation mechanism is needed. By uniformly managing tasks through queues, asynchronous management can be implemented, eliminating mutual exclusion waiting.

[0074] The process of multi-threaded direct access to the GPU through the driver is as follows: Figure 4 As shown, this approach has two problems. First, the driver, operating within a single context, only allows one thread to operate. Second, the multi-threaded calling methods provided by the driver can isolate the GPU through context isolation and stream isolation. Context isolation prevents data exchange, leading to significant inter-algorithm data interaction in the NR SDR system. Stream isolation divides the GPU into multiple computing channels, with all tasks sharing GPU computing power. When two tasks run simultaneously on the GPU using stream isolation, each task receives half the GPU computing power, doubling the execution time, which does not meet the real-time requirements of the NR SDR system. In the NR SDR system, the First-In, First-Out (FIFO) scheduling method better meets real-time requirements. However, FIFO scheduling is only suitable for single-threaded operation; otherwise, scheduling overhead occurs.

[0075] The scheduling strategies provided by the driver are applicable to scenarios such as AI and games. In the NR SDR system, an additional scheduler needs to be added, and its scheduling process is as follows: Figure 5 As shown, the scheduler buffers tasks submitted by threads and performs GPU scheduling on the cached tasks, running them in the current optimal orchestration mode. Data is transferred between the scheduler and threads through a non-blocking channel, so threads do not need to block. In the NR SDR system, threads can have more time to complete other tasks, such as solving the DM-RS data position after FFT and passing it to the GPU, thus achieving asynchronous acceleration.

[0076] Data dependency refers to two tasks where the execution of one task depends on the computation result of the previous task. Data dependency conflict occurs when two tasks reside on different GPUs; executing the latter task requires transferring data from the former to the GPU where the latter task resides. This GPU data transfer process incurs additional communication time.

[0077] In multi-GPU systems, data dependency conflicts can occur. For example, in an NR SDR system, if two data-dependent algorithms are assigned to different GPUs, additional data transfers will occur, leading to increased processing time. When two data-dependent computational tasks are assigned to different GPUs, identical data will be processed on the first GPU, then transferred back to RAM, and then passed to the second GPU for further processing. This data transfer process incurs additional data transfer overhead compared to processing within the same GPU. Therefore, when executing data-dependent tasks across GPUs, this data transfer overhead must be carefully considered.

[0078] (3) Asymmetric multi-GPU computing resource allocation method based on hypergraph and quasi-ordered set

[0079] In this section, we construct an asymmetric GPU task scheduler, the framework of which is as follows: Figure 6 As shown, the process begins with a description of the prior task information. This involves mathematically representing the sequence of tasks to be assigned, ordered by their initiation time, the data dependencies between assigned and unassigned tasks, and the current computing power of asymmetric GPUs. Next, a hypergraph model is used to model the data dependencies, simplifying data dependency conflicts and representing their impact, resulting in the task data dependency hypergraph model. Then, an unassigned task ranking model is used to sort the tasks and determine their priorities. Finally, based on these priorities, a matching GPU is calculated for each unassigned task based on the data dependencies provided by the task data dependency hypergraph model and the current computing power of asymmetric GPUs. This matching GPU is then sent to the matched GPU via the driver program.

[0080] 1) Prior task information

[0081] The signal processing flow in an SDR system exhibits phased and data flow characteristics, with sequential relationships and data dependencies between processing tasks. In a multi-threaded environment, different threads process signal data within different time slots. Taking a 5G NR system as an example, each slot can be processed by an independent thread, which internally includes operations such as IFFT, attention-based channel estimation, channel equalization, descrambling, rate matching, and LDPC decoding. The processing steps must be executed sequentially according to a predetermined order, and there are clear data dependencies between preceding and subsequent stages.

[0082] This section considers a containing A parallel thread NR SDR system, where each thread initiates... A set of tasks with sequential dependencies are executed in a predetermined order, such as... Figure 7 As shown. For example, the first The first thread The task is represented as For a specific signal processing task, such as channel estimation based on attention mechanisms, its operation requires... After that, among them , .

[0083] Within a single SDR signal thread, internal tasks must strictly follow... The tasks are executed sequentially, meaning that subsequent tasks can only run after the preceding tasks have completed. For task dependencies within a single thread, a Directed Acyclic Graph (DAG) is used as the model. , where the set of nodes edge set Used to describe the sequential relationship between tasks. Any adjacent tasks and There exists a directed edge This indicates execution constraints. All tasks and their order constraints in the NR SDR system are available. The set representation, .

[0084] There are data dependencies between tasks, and this relationship is also a directed edge relationship in the NR SDR system. Add an extra set of edges on top of the existing ones This is used to describe the data dependencies between tasks. There are tasks... and There exists a directed edge This indicates that the execution process requires the output data of a preceding task. For example, in an NR SDR system, both attention-based channel estimation methods and channel equalization require the output data of the FFT. In an NR SDR system, the FFT task refers to channel estimation and channel equalization.

[0085] In multi-GPU computing power, there is an asymmetry in the node set. Add the corresponding computing power representation in asymmetric GPUs to the task. Different runtimes occur in GPUs; parameters are introduced. As an expression of GPU computing power, setting As a benchmark for GPU speed, In the benchmark GPU, the task time is set to... GPUs with different computing power compared to the benchmark Numerical fluctuations exist, task Runtime on different GPUs:

[0086] ,

[0087] when At that time, the GPU's computing power was higher than the benchmark GPU. At that time, it is lower than the benchmark GPU. The runtime under the benchmark GPU is... As Attributes are included in the node set middle.

[0088] 2) Task data depends on hypergraph model

[0089] This section performs hypergraph modeling of data dependencies, constructs hyperedges between GPUs and tasks, and quantifies the required cross-GPU data transfer latency by the number of node hyperedges.

[0090] To characterize the coupling between data dependencies between tasks and GPU allocation, a task data dependency hypergraph model is introduced. The task GPU hypergraph model is defined as follows:

[0091] ,

[0092] in, A set of nodes, corresponding to tasks These represent tasks that are currently being executed, have already been executed, or are yet to be executed. It is a set of superedges.

[0093] Hyperedges are divided into two categories:

[0094] ① Calculate the bearing hyperedge , indicating that it is allocated to the first GPUs ( The task set;

[0095] ② Data Dependency Hyperedge This indicates a task group with data dependencies. If tasks Execution depends on the task set Then it can be defined .

[0096] Hyperedge contains Tasks that have been completed or are currently being carried out in China The hyperedge includes all pointing tasks. The parent task. A task depends on task data dependencies in a hypergraph model, such as... Figure 8 As shown. In the hypergraph In the middle, if a certain data depends on a hyperedge The tasks within are assigned to different computational bearer hyperedges. This will incur cross-GPU communication overhead. Let the unit cross-GPU communication latency be... If there exists in the dependent hyperedge Secondary cross-GPU data transfer, i.e. Hyperedge memory in different ,but for If the number of superedges is reduced by 1, the corresponding additional latency is:

[0097] .

[0098] The Middle Task exist The time taken is:

[0099] ,

[0100] in, express The relative computing power Indicates task Time taken on a benchmark GPU.

[0101] Communication overhead is equated to the additional computation time of the task, maintaining a consistent time metric framework. After considering communication costs, The total cost is defined as:

[0102] .

[0103] GPU allocation decisions are implicit in the hypergraph. of During the construction process, Defined data dependency constraints. Task execution time, GPU heterogeneous computing power, and cross-device communication costs can be based on the task data dependency hypergraph model. calculate.

[0104] 3) Task sequencing

[0105] First, based on the 3GPP protocol, the maximum processing time is defined, establishing the optimization problem and constraints. The concepts of quasi-ordered chains and anti-chains are introduced to model GPU resource allocation. Chains are used to establish priority relationships; the comparability between tasks can be established by the task request order in prior task information, generating chains. Then, nodes in the chains select anti-chains to allocate resources to specific GPUs. Finally, a neural network model is introduced, fusing hypergraph dependencies, the current GPU state, and prior task information to generate a cost function, producing comparability between anti-chains, ultimately achieving asymmetric GPU resource allocation. Finally, polynomial function distillation is used to improve the efficiency of the cost function.

[0106] Thread All tasks The total completion time must be less than This satisfies the real-time requirements of the NR SDR system. (Thread) The total workload of the medium task is:

[0107] ,

[0108] in, for The index of the GPU (the corresponding GPU is represented as) ), The total latency caused by GPU scheduling, waiting, and data transfer losses, when It meets the real-time requirements of the NR SDR system. This refers to the time slot processing time required by 5G NR. Represents a thread The Middle The time taken by each task on a benchmark GPU.

[0109] If thread All tasks have been assigned and the prior task information is satisfied. The order condition in the middle, then (thread) The completion time of the last task in the game is equivalent to the task's completion time. Location The completion time in the queue depends on the task data dependency hypergraph model. The total load can be defined as follows: Can be updated to:

[0110] ,

[0111] in, for forward Task queue, For threads The time taken by the last task in the benchmark GPU. (Visual) for The last task in the task queue, i.e., the assignment task. The last task Where the time is load Equivalent to For any thread The final task Even if the thread has not yet initiated the final task execution request, it can be considered as Equivalent to That is, the tasks assigned each time All require completion in the fastest possible time, therefore for any Among them, the largest satisfy Then it is The task at the end of the queue satisfies the real-time requirement, i.e., thread. To meet real-time requirements, the optimization problem is as follows:

[0112] ,

[0113] in, Is it allocated to The total time for all tasks to complete. The system has multiple GPUs; the GPU with the longest execution time is used as the baseline. (Tasks are assigned to multiple GPUs, which compute in parallel. When the GPU with the longest computation time finishes, the other GPUs will inevitably have completed their tasks.) The objective function states that the goal is to minimize the computation time of the longest-running GPU (equivalent to minimizing the total computation time of all tasks) during task allocation. The constraint is... End of queue task load Need to Completed within [timeframe]. This optimization problem characterizes the makespan minimization problem in parallel machine scheduling, rather than the total time minimization problem. Plan all [timeframes]. and The correspondence and queue relationship, that is In which Operation and exist The position in the task queue, and satisfying the constraints.

[0114] In the NR SDR system, scheduling is performed sequentially in units of slots. Slot data enters the system sequentially by processing threads, and the physical layer signal processing procedures (such as channel estimation, equalization, demodulation, and decoding) within a single slot are executed in a fixed order. While there are sequential relationships between tasks at the thread or algorithm level, the execution relationship at the GPU runtime level is uncertain. Considering the real-time constraints of FIFO scheduling in the NR SDR system, this embodiment introduces a quasi-ordered set to model the task scheduling order. The task queue relationship can be determined by comparing the thread order with the task data for sorting. The correspondence is rather ambiguous, so a neural network is introduced for training to find the optimal solution.

[0115] Figure 9 A schematic diagram of a task ranking model. (e.g.) Figure 9As shown, in the quasi-ordered set, two key concepts, "chain" and "anti-chain," are introduced to characterize the seriality and parallelism of tasks. A chain represents a flow of tasks that must be executed sequentially in a predetermined order, satisfying the order and priority relationships of the tasks. Its length and task position are determined by the order and priority of the tasks. An anti-chain combination represents a set of mutually independent tasks that are not comparable in terms of their order, integrating the task data dependency hypergraph model and the task execution baseline time. Parameters such as the current state of the GPUs are used to generate comparability of anti-chains. Tasks can be distributed in parallel across different computing resources. The maximum length of an anti-chain reflects the maximum computational load of the system at that stage, and the number of anti-chains is equal to the number of GPUs.

[0116] The core function of the quasi-order set is to constrain the execution order of tasks on the GPU. Each anti-chain in the quasi-order set corresponds to... The task execution order is defined in the anti-chain, and the GPU executes tasks in the order defined in the anti-chain, conforming to the GPU's operating rules. Anti-chains are used to distinguish sets of parallel tasks between different GPUs; tasks belonging to the same anti-chain can be distributed to the corresponding GPU. Hyperedge. An antichain combination represents a set of independent tasks that are not comparable in order, corresponding to the current task allocation scheme. Chains describe "queue relationships," while antichains describe "correspondence relationships."

[0117] A pending task chain is introduced into the prototyping set as the basic chain to record the set of tasks that have not yet been assigned to the GPU. When a processing thread calls the GPU to execute a task, it requests the task through a program interface. To ensure thread safety, this interface is a unidirectional pipe. The task generation process follows a chronological order and can be viewed as a time chain.

[0118] To describe this order relationship, a directed graph is introduced to represent the chain and the anti-chain:

[0119] ,

[0120] in, Indicates the task. This represents a priority-directed edge constructed based on prior information about unassigned GPU tasks. This represents the generated antichain connections, where each antichain represents a task assigned to a GPU and its execution order. (Figure) This describes the temporal sequence and priority of tasks. All newly generated tasks are prioritized based on prior information and added sequentially to the unconnected anti-chains in the tentatively ordered set. Combining thread priority and slot real-time constraints, tasks are reordered to ensure real-time processing requirements under FIFO scheduling.

[0121] For the problem of asymmetric GPU computing resource allocation, three types of basic information have been established: prior task information, task data dependency hypergraph model, etc. And a task prototyping and ranking model. Prior task information is collected by the NR SDR system, including algorithm order, average execution time, and GPU load; task data relies on a hypergraph model. The result consists of the completed allocation and the currently pending tasks, used to characterize the data dependency constraints at the current moment. Solving for the chains and anti-chains in the quasi-ordered set constitutes an abstract expression of asymmetric multi-GPU scheduling. The chains correspond to serial execution paths, and the anti-chains correspond to the set of parallelizable tasks. The final GPU allocation result can be viewed as the maximum anti-chain partition in the quasi-ordered set. The scheduling optimization objective is defined as a makespan minimization problem.

[0122] To address the asymmetric allocation of GPU computing resources, this invention proposes a triggered scheduling framework. When a new task is generated, the scheduler is triggered, and the task is added to the proto-order set. The unallocated last chain is used to represent the current set to be scheduled.

[0123] To ensure that the most advanced thread completes first to meet real-time requirements, Unassigned chains are reordered. The reordering relation is defined as:

[0124] ,

[0125] This indicates that tasks are arranged in ascending order of priority, ensuring that high-priority tasks are given priority in resource allocation. The priority function for a task.

[0126] The task priority function is determined by the completion time of the current task's preceding dependent tasks, the time the current task spends waiting for allocation, and the real-time requirement time limit of the Slot thread. The priority function for the current task is defined jointly as follows:

[0127] ,

[0128] in, For the current task The execution time of the preceding dependent tasks. The current task The time spent waiting for allocation, This is the total time elapsed from the start time of the slot thread to the current time. This priority function reflects the percentage of remaining available time for the task; the less time remaining, the higher the task priority, thus ensuring that urgent tasks are scheduled and executed first.

[0129] Then, the executability of the reordered chainhead task is verified. For example, the current chainhead task is... According to the thread sequence diagram To find its predecessor mission .like (when If the task is completed (indicated as true, so that its subsequent tasks can continue to be executed), then it enters the GPU allocation; otherwise, it skips the chain node until the end of the chain.

[0130] During the GPU allocation phase, based on the hypergraph The data dependencies are used to determine whether cross-GPU data transfer exists. Let the cross-GPU communication overhead be... Then the task exist The time spent on it is Including communication overhead, GPU allocation decisions are implicit in the hypergraph construction process and are constrained by defined data dependencies. Task execution time, heterogeneous GPU computing power, and cross-device communication costs are all incorporated into the task data dependency hypergraph model.

[0131] Anti-chain construction process as follows Figure 10 As shown. This invention transforms the selection of the anti-chain into a comparison problem. After task reordering, the anti-chain is selected based on the executable tasks. Considering the already assigned results, a strategy function is constructed. This is used to determine the sequence of tasks, calculate the running cost of tasks on each GPU, and select the optimal GPU. The policy function is defined as follows:

[0132] ,

[0133] in, This represents the task index, where the order determines priority. express The current load status, Indicates the task Assigned to Does it introduce data dependency conflicts? For the task Priority. It is a defined cost function that represents a policy. .

[0134] The scheduling decision is as follows:

[0135] ,

[0136] It represents choosing the option with the minimum cost. For the task GPU load.

[0137] Strategy Unable to be directly fitted as a function polynomial, this invention solves for the optimal solution through brute force, generating binary labels, and then transforming it into a latent variable fitting problem using a neural network. Anti-chain selection, under single-step decision-making, is a branching problem with a finite quasi-order set length. In the offline phase, the optimal allocation result for the current task node is solved using enumeration or branch-and-bound methods. The result is a binary parameter, and the optimal node allocation result output by the trained neural network is:

[0138] ,

[0139] in, This indicates that the GPU is not selected. Indicates a choice.

[0140] Since the output is a binary classification probability, binary cross-entropy is used as the supervised loss function. This loss function minimizes the mean squared error between the prediction cost and the optimal cost, thus approximating the optimal scheduling strategy. Because online scheduling runs on the CPU, deploying neural network inference to the GPU would incur additional overhead, and the GPU might be under full load. Therefore, a lightweight mathematical function needs to be constructed. To replace .

[0141] Define the eigenvector:

[0142] ,

[0143] By using symbolic distillation, the parameters of the neural network are mapped to polynomial approximation functions:

[0144] ,

[0145] in, The characteristic permutation polynomial basis function expansion, The weighting parameters are obtained from distillation.

[0146] During the online scheduling phase, the optimal GPU index is:

[0147] .

[0148] The asymmetric multi-GPU computing resource allocation method has been fully constructed, and the overall flowchart is as follows: Figure 11 As shown, the steps include:

[0149] Task thread Submit (task request) and add to the unassigned task set (add to the tentative order set chain). Prioritize the unassigned GPU task set (priority can be defined as how much time is left in the current time slot, the less time left, the higher the priority, and the tasks are reordered).

[0150] Select the first node after reordering, and determine whether its prerequisite tasks are completed. If they are completed, perform GPU allocation; otherwise, skip the node and proceed to the next node for judgment and allocation. If all nodes have been traversed, end the current scheduling.

[0151] When the prerequisite tasks of the selected task node have been completed, the task data dependency hypergraph of the task is built to indicate which tasks and GPUs it depends on.

[0152] The dependencies, the current state of the GPU's running tasks (how many tasks are there, how much time is needed to complete them), and the task priorities are used to implement the π policy function (i.e., ... ) perform the calculations, and select the GPU with the lowest cost ( Add this task to In the execution queue, the state of the currently running task on the GPU is updated, and the task data dependency hypergraph is updated based on the current state (the task has been assigned to this GPU, and the task dependencies have been bound to this GPU) (in subsequent task assignments, the data dependency hypergraph is built based on the updated parent graph). This completes the task assignment process.

[0153] The quasi-order set characterizes the task sequence and parallel relationships, and utilizes a task data dependency hypergraph model to uniformly represent data dependencies and communication losses. At the policy level, a near-optimal allocation rule is learned through a neural network, and a lightweight cost function is further constructed through symbolic distillation to achieve low-overhead decision-making. This method takes into account the real-time performance of NR SDR systems, providing real-time computing power guarantees for slot-level real-time execution of attention-based channel estimation in multi-GPU environments.

[0154] (5) Simulation experiment and result analysis

[0155] This section validates the asymmetric GPU resource allocation method using a system model. First, the neural network fitting degree is tested to determine if a comparable relationship can be found, and polynomial distillation is performed on the neural network to evaluate the distillation effect. Second, various symmetric and asymmetric GPU environments are established to evaluate the performance of the proposed method. Experimental results show that, when the total computing power of multiple GPUs reaches the requirements of an NR SDR system, the proposed method can stably maintain real-time performance.

[0156] The simulation environment was set up according to Table 2. Asymmetric GPU scenarios were randomly generated. The optimal scheduling was solved by brute force, and a dataset was generated to train the model. The model was a 3-layer DNN model with a learning rate of [missing information]. Finally, the model is distilled into simple polynomial weights to reduce the load on the scheduling algorithm.

[0157] Table 2 GPU scheduling simulation parameters

[0158]

[0159] Figure 12 For strategy The training loss curve of the neural network fitting model. From Figure 12 It can be seen that the model training loss value tends to stabilize after 300 rounds, and the neural network is able to find the corresponding relationship in the training set and implement the anti-chain selection strategy.

[0160] Figure 13 This is the result of a multinomial regression fit. From... Figure 13 It can be seen that the output of the distilled polynomial function is closer to the model output, among which the coefficient of determination The result is 0.9126, which can effectively replace neural networks as an anti-chain selection strategy. It is the most commonly used indicator to measure the goodness of fit of a regression model. A value close to 1 indicates a perfect fit, while a value less than 0 indicates a poor fit.

[0161] The polynomial fitted to the model is used as the core cost function in the heterogeneous GPU allocation method, and performance analysis is performed sequentially for symmetric multi-GPU computing pools and asymmetric multi-GPU computing pools. Computing power allocation tests are conducted in a symmetric multi-GPU environment. By generating random task requests and equivalent computing power lists, the transmission loss caused by cross-GPU data dependencies is evaluated, with the loss value set as the baseline task execution time. Experiments cover single-GPU, dual-GPU, and triple-GPU configurations, with the goal of "whether a single GPU can complete the baseline execution time within 1000 microseconds with a probability of over 84%". "Time consumption" is used as the criterion for determining whether the single-threaded computing power requirement is met. The symmetric GPU computing power allocation is shown in Table 3. As can be seen from Table 3, the computing power of each test group is set at the critical point that meets the real-time threshold, which aims to verify the scheduling performance of the system under extreme load.

[0162] Table 3 Symmetric GPU computing power allocation

[0163]

[0164] The test results of each simulated thread's end-point task under the condition that single-threaded computing power is sufficient but single-card hardware resources are insufficient to support multi-threaded concurrency requirements are as follows: Figure 14 As shown, Figure 14 The system records the end timestamps of the tasks at the end of each simulated thread during the single-card test, and marks them. Real-time cutoff line in scenario =2. From Figure 14It can be seen that, when single-threaded computing power is sufficient but single-card hardware resources are insufficient to support multi-threaded concurrency requirements, neither method fully meets the real-time requirements, and the timestamps exceed the real-time line. However, the proposed method optimizes the computing power allocation in the 5G NR scenario by reordering task priorities, and the average task time is reduced by 1431.10 microseconds compared with the load balancing method.

[0165] The test results of each simulated thread's end-point task under the condition that single-threaded computing power is sufficient and single-card hardware resources are sufficient to support multi-threaded concurrency requirements are as follows: Figure 15 As shown. From Figure 15 It can be seen that the performance of the proposed algorithm and the load balancing method are similar, and both can be stably kept within the real-time line.

[0166] The test results for a symmetrical dual-GPU setup, where a single card does not meet the single-threaded computing power requirements and do not, are as follows: Figure 16 and Figure 17 As shown. From Figure 16 , Figure 17 It can be seen that, in a dual-card symmetrical environment considering data transmission loss, the proposed method exhibits superior scheduling performance compared to traditional load balancing strategies under various computing power conditions. Specifically, under extremely limited conditions where single-card computing power is insufficient, although it cannot fully meet the requirements due to physical resource bottlenecks, the proposed method reduces latency by 5979.37 microseconds compared to the load balancing strategy. As single-card computing power increases to meet the basic requirements of single-threaded processing, the task completion timestamps of the proposed method successfully drop below the real-time threshold, and further reduce processing latency by 4621.42 microseconds. The proposed method can ensure the real-time performance of the dual-card system under the premise of meeting computing power requirements, effectively solving the real-time bottleneck problem of communication GPU resource allocation in SDR systems.

[0167] The test results for a symmetrical triple-GPU setup, where a single card does not meet the single-threaded computing power requirements and where it does, are as follows: Figure 18 and Figure 19 As shown. From Figure 18 , Figure 19 As can be seen, in a three-card symmetric environment, the proposed method can remain within the real-time line under different computing power conditions. Specifically, when the computing power of a single card is increased to meet the single-threaded requirement, the safety margin between the task end timestamp and the real-time line of the proposed method increases significantly, further enhancing the real-time performance of the processing. In contrast, traditional load balancing strategies cannot meet real-time constraints when computing power is insufficient. Although their stability improves after the computing power reaches the standard, their performance still fluctuates only around the real-time line. Data shows that in the two scenarios where computing power is insufficient and single-threaded requirements are met, the proposed method reduces latency by 4014.02 microseconds and 930.12 microseconds compared to the load balancing strategy, respectively. This proves that as physical computing resources increase, the real-time performance of the proposed algorithm in scheduling improves.

[0168] In asymmetric hardware environments, the computing power differences between GPUs significantly exacerbate the timing uncertainty of tasks while waiting for prerequisites to complete. This experiment designed three test cases for asymmetric scenarios: upgrading a dual-GPU system to a single GPU, upgrading a triple-GPU system to a single GPU, and introducing heterogeneous low-computing-power GPUs into a dual-GPU system. These three configurations simulate the typical paths of computing power systems during actual expansion and iteration. The asymmetric GPU computing power allocation is shown in Table 4. The computing power configuration of all test groups was set near the threshold that meets the real-time requirements of single-threaded tasks, aiming to verify the scheduling robustness of the system under extreme computing power mismatch conditions.

[0169] Table 4 Asymmetric GPU computing power allocation

[0170]

[0171] In an asymmetric dual-card environment, the test results for upgrading to one card and meeting the single-threaded computing power requirements are as follows: Figure 20 As shown, the test results for the symmetrical dual-card setup used for comparison are as follows: Figure 21 As shown. From Figure 20 , Figure 21 It can be seen that the proposed method can make reasonable use of computing resources with different performance levels, and the real-time performance improves synchronously with the increase of total computing power. Compared with symmetric configuration, the overlap frequency between the task end timestamp and the real-time line is significantly increased in the asymmetric environment, and the asymmetric computing power leads to a slight decrease in real-time stability. Compared with the load balancing strategy, the proposed method can still reduce the processing latency by 5325.30 microseconds in the asymmetric case. Experiments show that when the system performance is improved by upgrading some GPUs, the proposed method can use the asymmetric computing power increase to maintain real-time performance.

[0172] In an asymmetric three-card environment, the test results of upgrading to one card and meeting the single-threaded computing power requirements are as follows: Figure 22 As shown, the test results of the symmetrical three-card comparison are as follows: Figure 23 As shown. From Figure 22 , Figure 23 As can be seen, in a three-GPU system, upgrading the computing power of a single GPU in a symmetric three-GPU system to form asymmetric GPU resources results in the proposed method falling below the real-time performance threshold under both symmetric and asymmetric three-GPU conditions. The load balancing method exceeds the real-time performance threshold after the fourth thread in the symmetric three-GPU condition. After upgrading to asymmetric three-GPU, thanks to the overall system performance improvement, it exceeds the real-time performance threshold after the tenth thread. Compared to the load balancing method, the proposed method reduces latency by an average of 1469.61 microseconds after upgrading a single GPU in a three-GPU system to form an asymmetric three-GPU system. The figure shows that the proposed method meets the real-time requirements under both symmetric and asymmetric three-GPU conditions.

[0173] The test results for adding GPU computing power to the original symmetric dual-card system to create an asymmetric triple-card environment are as follows: Figure 24 As shown, the test results of the original symmetrical dual-card system are as follows: Figure 25 As shown. From Figure 24 , Figure 25 As can be seen, the proposed method remains within the real-time range both before and after scaling. However, after introducing a new GPU, the scheduling complexity brought about by the asymmetric system causes some fluctuations in the trend shown in the graph. In contrast, while the load balancing method shows a significant performance improvement after adding a new GPU, it still fails to fully meet the real-time requirements. Data indicates that after constructing an asymmetric three-GPU configuration, the proposed method reduces latency by an average of 1478.68 microseconds compared to the load balancing method. Experiments demonstrate that even with increased system instability due to the introduction of asymmetric computing power, the proposed method can stably meet the real-time requirements.

[0174] In summary, to address the challenge of meeting 5G NR latency requirements through multi-threaded collaborative scheduling under limited GPU computing resources in 5G SDR systems, an asymmetric dynamic scheduling method for GPU computing resources is proposed. First, the data dependencies between GPU tasks (i.e., execution order constraints formed by data generation and usage between tasks) are analyzed to establish a task data dependency hypergraph model. Then, a quasi-order set is used to determine the task priorities and arrange the execution order of multiple tasks. Based on this, a neural network model is used to fit the resource scheduling model to achieve task scheduling of multiple GPUs with different computing power, thereby reducing the computational latency of multiple tasks under complex data dependencies and different task priorities. Experimental results show that the proposed method can effectively guarantee the real-time performance of GPU tasks in 5G SDR systems, and reduces latency by at least 1000 microseconds compared to comparative methods under asymmetric conditions.

[0175] The above embodiments are preferred embodiments of the present invention, but the embodiments of the present invention are not limited to the above embodiments. Any changes, modifications, substitutions, combinations, or simplifications made without departing from the spirit and principle of the present invention shall be considered equivalent substitutions and shall be included within the protection scope of the present invention.

Claims

1. An asymmetric multi-GPU computing resource allocation method, characterized in that, include: The prior task information is described, including the sequence of multi-threaded tasks executed in a predetermined order, the task data dependencies between assigned and unassigned tasks in the multi-threaded task sequence, and the current state of the asymmetric GPU. The task data dependency relationships are modeled using a hypergraph model to obtain a task data dependency hypergraph model; the construction process of the task data dependency hypergraph model is as follows: Define a set of nodes and a set of hyperedges. The nodes in the set of nodes include tasks that are being executed, have been executed, and are yet to be executed. The hyperedges in the set of hyperedges include computation-carrying hyperedges and data-dependent hyperedges. The computational carrying hyperedge represents a set of tasks assigned to the same GPU; the data dependency hyperedge represents a group of tasks with data dependencies. Based on the prior task information, the priority and parallel scheduling order of unassigned tasks are determined using the chain and anti-chain mechanism in the pseudo-order set. The chain in the pseudo-order set is used to establish priority relationships. The comparability between tasks is established by prior task information and task request order, and a chain is generated to represent a set of task flows that must be executed serially in a predetermined order. Its length and task position are determined by the order and priority of the tasks. Anti-chains are selected by nodes in the chain to plan to a specified GPU. One anti-chain corresponds to one GPU. Anti-chains are used to distinguish parallel task sets between different GPUs. Tasks belonging to the same anti-chain are assigned to the corresponding hyperedge. A combination of anti-chains represents a set of independent tasks that are not comparable in terms of order, corresponding to the current task allocation scheme. Based on the task data dependency hypergraph model and the prior task information, with the goal of minimizing the longest GPU time and the constraint that the load of the task at the end of any GPU queue meets the real-time requirements of that GPU, the optimal anti-chain combination is solved. In the process of solving the optimal anti-chain combination, the GPU time corresponding to an anti-chain is equal to the sum of the time of all tasks in that GPU. The tasks to be assigned are distributed to the corresponding GPUs according to the optimal anti-chain combination.

2. The asymmetric multi-GPU computing resource allocation method according to claim 1, characterized in that: When a task has no cross-GPU dependency, the time taken by the task is equal to the relative computing power of the GPU to which it is allocated multiplied by the time taken by the task in the baseline GPU. When a task has cross-GPU dependency, the time taken by the task is equal to the product of the relative computing power of the GPU to which it is allocated and the time taken by the task in the baseline GPU, plus the cross-GPU communication latency of the task.

3. The asymmetric multi-GPU computing resource allocation method according to claim 2, characterized in that, If all tasks in a thread have been assigned and the order condition in the prior task information is satisfied, then the completion time of the last task in the thread is equal to the completion time of the task in the GPU queue; the total load of a thread is equal to the sum of the time taken by the last task and all previous tasks in the GPU task queue where the last task of the thread is located.

4. The asymmetric multi-GPU computing resource allocation method according to claim 3, characterized in that, The optimal GPU index is: The scheduling decision function selects the GPU with the lowest cost as the GPU to carry the current task. The feature vector includes the index of the current GPU, the load status of the current GPU, whether assigning the current task to the current GPU will introduce data dependency conflicts, and the priority of the current task. The scheduling decision function is obtained by offline fitting and distillation of a neural network model, which means selecting the GPU with the lowest cost as the GPU to carry the current task.

5. The asymmetric multi-GPU computing resource allocation method according to claim 4, characterized in that: When a new task is generated, the task is added to the end of the chain, and the chain is reordered according to priority. The priority is determined by the execution time of the current task's predecessor dependent tasks, the time the current task waits for allocation, and the time limit for the real-time requirement of the Slot thread. If the predecessor task of the current node has been completed after reordering, GPU allocation is performed on the current node. If it has not been completed, the node is skipped, and the judgment and allocation of the next node is carried out.

6. An asymmetric multi-GPU computing resource allocation system, employing the asymmetric multi-GPU computing resource allocation method according to any one of claims 1 to 5, characterized in that: It includes a bus device layer, a resource scheduling layer, and a program layer. The bus device layer is used to define the baseline GPU performance and give the required performance requirements in NR SDR. The resource scheduling layer is used to analyze the data dependencies between various GPU tasks, establish a task data dependency hypergraph model, and use a pseudo-order set to determine the task priority and arrange the execution order of multiple tasks to be assigned. The program layer is used to use the data from the resource scheduling layer and fit the resource scheduling model through a neural network model to perform task scheduling for multiple GPUs with different computing power.

Images