GPU resource management method and system of design simulation platform based on AI drive

Abstract

The invention provides a GPU resource management method and system for designing a simulation platform based on AI drive, and relates to the technical field of computers.The method comprises the steps that in response to a submission event of a simulation task, first feature data are processed, and an initial resource template of the simulation task is generated; based on the initial resource template and the GPU hardware state data, matching and generating a resource allocation strategy corresponding to the simulation task from a preset resource allocation strategy library; in response to the start of execution of the simulation task, inputting the collected second operation data and an expected target of the resource allocation strategy into a resource adjustment model to obtain a resource adjustment instruction; and adjusting the GPU resources allocated to the simulation task according to the resource adjustment instruction. According to the GPU resource management method and system of the design simulation platform based on AI driving, the simulation task execution efficiency and precision are improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a GPU resource management method and system based on an AI-driven design simulation platform. Background Technology

[0002] With the continuous upgrading of design simulation technology, the complexity of simulation tasks exhibits significant differentiation and dynamic changes. The computing power requirements and GPU memory usage of the same type of simulation task fluctuate greatly at different execution stages. Simultaneously, the number of simulation tasks running in parallel on the platform is also dynamically changing, leading to instability in the overall platform load. Based on the existing fixed resource allocation template management method, because the resource allocation parameters are fixed and cannot be adjusted according to the actual task running status and platform load changes, when there is a surge in computing power demand during task execution, task execution will be slowed down, the execution time will be significantly extended, and even task interruption may occur. When computing power demand decreases during task execution, the pre-allocated GPU resources will remain underutilized for a long time. These idle resources cannot be reused by other tasks on the platform that require computing power, resulting in serious waste of GPU resources. This mismatch between resource allocation and actual demand is further exacerbated, especially in multi-task parallel execution scenarios, limiting the overall operating performance of the design simulation platform. GPU resource utilization remains at a low level for a long time, failing to adapt to the high demands of dynamic changes in current simulation tasks and fluctuations in platform load. Summary of the Invention

[0003] To address the aforementioned technical issues, this application provides a GPU resource management method and system based on an AI-driven design simulation platform.

[0004] A first aspect of this application provides a GPU resource management method based on an AI-driven design simulation platform, comprising: In response to the submission event of the simulation task, the first feature data is processed to generate the initial resource template of the simulation task; the first feature data includes task submission parameters, historical performance profile and task structure features; the initial resource template includes the initial prediction results of GPU type, computing power requirements and video memory capacity. Based on the initial resource template and GPU hardware status data, the resource allocation strategy corresponding to the simulation task is generated by matching from the pre-set resource allocation strategy library; In response to the start of the simulation task, the collected second running data and the expected target of the resource allocation strategy are input into the resource adjustment model to obtain resource adjustment instructions; Adjust the GPU resources allocated to the simulation task according to the resource adjustment instructions.

[0005] A second aspect of this application provides a GPU resource management system based on an AI-driven design simulation platform, comprising: The data processing module is used to process the first feature data in response to the submission event of the simulation task and generate the initial resource template of the simulation task. The first feature data includes task submission parameters, historical performance profile and task structure features. The initial resource template includes the initial prediction results of GPU type, computing power requirements and video memory capacity. The resource allocation module is used to match and generate the resource allocation strategy corresponding to the simulation task from the pre-set resource allocation strategy library based on the initial resource template and GPU hardware status data. The instruction generation module is used to respond to the start of the simulation task by inputting the collected second running data and the expected target of the resource allocation strategy into the resource adjustment model to obtain resource adjustment instructions. The instruction execution module is used to adjust the GPU resources allocated to the simulation task based on the resource adjustment instructions.

[0006] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the GPU resource management method of the AI-driven design simulation platform described above.

[0007] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the GPU resource management method of the AI-driven design simulation platform described above.

[0008] The beneficial effects of the GPU resource management method and system for an AI-driven design simulation platform provided in this application are as follows: Firstly, by deeply mining the value of primary feature data, this application accurately generates initial resource templates, effectively solving the pain point of resource mismatch between traditional allocation and task requirements. This avoids task lag and crashes caused by resource surplus or shortage, significantly improving the basic utilization rate of GPU resources. Secondly, based on the real-time status of GPU hardware, a dedicated allocation strategy is matched, taking into account both task requirements and hardware load balancing, further optimizing the rationality of resource scheduling. By collecting running data in real time and dynamically generating adjustment instructions through a resource adjustment model, dynamic adaptation of resource configuration is achieved, ensuring efficient and stable execution of simulation tasks. During task execution, by dynamically adjusting resource allocation parameters, idle GPU resources can be promptly allocated to other simulation tasks with needs, avoiding the long-term idleness of GPU resources in existing technologies, maximizing the computing performance of GPU hardware, and improving the GPU resource utilization rate of the entire design simulation platform. The entire process of this application requires no manual intervention, relying on AI to complete the entire process of resource management, reducing manual maintenance costs and improving the execution efficiency and accuracy of simulation tasks. Attached Figure Description

[0009] Figure 1 A flowchart illustrating a GPU resource management method based on an AI-driven design simulation platform provided in an embodiment of this application; Figure 2 A structural block diagram of a GPU resource management system based on an AI-driven design simulation platform provided in one embodiment of this application; Figure 3 This is a schematic block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0010] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0011] To make the purpose, technical solution, and advantages of this application clearer, the following will be described in conjunction with the appendix. Figure 1-3 The following is an explanation using specific examples.

[0012] Please refer to Figure 1 , Figure 1 A flowchart illustrating a GPU resource management method for an AI-driven design simulation platform provided in an embodiment of this application is shown. The method includes: S101: In response to the submission event of the simulation task, process the first feature data to generate the initial resource template of the simulation task; the first feature data includes task submission parameters, historical performance profile and task structure features; wherein the historical performance profile is constructed based on the GPU resource utilization efficiency, execution time and error rate of historical simulation tasks; the initial resource template includes the initial prediction results of GPU type, computing power requirements and video memory capacity.

[0013] In this embodiment, in response to a simulation task submission event triggered by a user or the system, firstly, first feature data related to the simulation task is collected and preprocessed. Then, a pre-set feature fusion and prediction model is used to perform in-depth analysis of the first feature data, ultimately generating an initial resource template adapted to the simulation task. The first feature data consists of static features that can be obtained at the time of task submission or extracted from the platform's historical database, including: task attributes, historical execution experience, and the task's internal structure. The task submission parameters are submitted by the user and include parameters of the core requirements of the simulation task, specifically: simulation accuracy requirements (such as mesh density and computation step size), task parallelism settings, expected execution time, data input scale (simulation model file size and input dataset dimension), as well as user-specified priority (high / medium / low) and resource constraints (maximum number of GPU cores).

[0014] Building a historical performance profile is a data-driven characterization process, with the following specific steps: Step 1: Using the parameters and structural features (such as simulation type and input size) of the currently submitted task as query criteria, retrieve several most similar completed tasks from the historical task database.

[0015] The second step involves extracting key performance indicators (KPIs) for each retrieved similar historical task within its complete execution cycle. These KPIs include, but are not limited to, the average utilization of GPU computing cores, peak memory usage, total task execution time, and the number and types of error codes encountered during execution. Subsequently, these KPIs are statistically aggregated (e.g., calculating the average and high-quantile values ​​of all similar tasks for each KPI) to form a set of statistical features characterizing the typical resource consumption patterns of such tasks.

[0016] Step 3: The statistical features obtained in the previous step are used to reduce dimensionality and refine the data through a lightweight neural network, outputting a low-dimensional, dense historical performance profile vector. This historical performance profile vector encapsulates the resource behavior patterns of similar tasks in past executions.

[0017] Step 4: When generating the initial resource template, it's not simply a matter of piecing together various data. Instead, the task submission parameters, task structure features, and the generated historical performance profile vector are all input into a feature fusion layer. This fusion layer uses an attention mechanism to automatically evaluate and weightedly integrate feature information from these three different sources, thereby generating a comprehensive and balanced final task feature representation for subsequent initial resource prediction.

[0018] Task structure features are used to characterize the inherent computational characteristics of simulation tasks, specifically including: the computationally intensive / data-intensive attributes of the task, the granularity of computational task splitting, the data transmission frequency, the complexity of the core computational modules, and the parallel computing requirements during task execution (e.g., whether multi-GPU collaboration is supported, and the dependencies between parallel tasks). These task structure features can be automatically extracted by parsing the simulation task's model file and executing the script.

[0019] The initial resource template is a preliminary prediction of the GPU resource requirements for the simulation task. It is generated after processing such as feature fusion, outlier removal, and regression prediction. Specifically, it includes: GPU type (computational, general-purpose, high-performance computing, matching the computational characteristics of the task), computing power requirements (such as the number of GPU cores, single-core computing power threshold, predicted based on task parallelism and computational complexity), and initial prediction results of memory capacity (combining the input data scale and the amount of intermediate data generated during the calculation process, reserving a certain amount of redundancy space to avoid memory overflow), along with the prediction confidence level.

[0020] S102: Based on the initial resource template and GPU hardware status data, match and generate the resource allocation strategy corresponding to the simulation task from the preset resource allocation strategy library.

[0021] In this embodiment, after generating the initial resource template, the hardware status data of all available GPUs on the current platform are combined to construct the basis for resource allocation decisions. The optimal resource allocation strategy is matched from the pre-set resource allocation strategy library, which ensures the rationality and efficiency of the initial resource allocation, while also taking into account the overall load balancing of the platform's resources.

[0022] This embodiment uses a hardware monitoring module built into the simulation platform to collect the real-time operating status of all available GPU nodes. Specifically, it includes the core utilization, memory usage, current load, temperature, power consumption, network bandwidth usage, number of available cores, available memory capacity, and hardware health status (whether there are faults or maintenance status) of each GPU. At the same time, it records the cluster to which each GPU node belongs and the network topology (which affects the efficiency of multi-GPU collaboration), forming a real-time GPU hardware status matrix.

[0023] The resource allocation strategy library in this embodiment is built based on long-term operational experience of the design simulation platform. It includes various resource allocation strategies adapted to different scenarios, specifically divided into basic strategies, optimization strategies, and emergency strategies. Among them, basic strategies include allocation by task priority and precise matching by resource demand; optimization strategies include load balancing strategies, resource utilization maximization strategies, and energy consumption optimization strategies; emergency strategies include resource reclamation and reallocation strategies after task interruption and resource switching strategies in case of hardware failure. Each of the above resource allocation strategies corresponds to clear applicable conditions and execution logic. The applicable conditions include: task type, resource demand range, and design simulation platform load.

[0024] This embodiment first processes the initial resource template to generate a task requirement feature vector; then processes the GPU hardware status data to generate a hardware status feature vector. The task requirement feature vector and the hardware status feature vector are input into a preset weight prediction model to obtain adaptive weights for the two vectors. Based on these adaptive weights, the task requirement feature vector and the hardware status feature vector are weighted and fused to obtain a comprehensive requirement score. Based on the comprehensive requirement score and a preset score-level mapping relationship, the resource requirement level of the simulation task is determined. According to the resource requirement level, a basic strategy is matched from a preset resource allocation strategy library, and the specific parameters of the strategy (such as GPU node selection) are fine-tuned based on the current GPU hardware status data to generate a dedicated resource allocation strategy for this simulation task.

[0025] S103: In response to the start of the simulation task, the collected second running data and the expected target of the resource allocation strategy are input into the resource adjustment model to obtain the resource adjustment instruction; the second running data includes the actual resource utilization rate, progress data and GPU hardware status data of the simulation task.

[0026] In this embodiment, once the simulation task officially begins execution, the design simulation platform enters the dynamic resource adjustment phase. Through the real-time monitoring module, task operation data and hardware status data are continuously collected. Combined with the expected goals of the resource allocation strategy, a preset resource adjustment model is input. The resource adjustment model analyzes the matching degree between the current resource allocation and the task execution requirements, and outputs precise resource adjustment instructions to achieve dynamic resource adaptation.

[0027] The second operational data acquisition in this embodiment combines high-frequency acquisition (e.g., acquisition every 100ms) with timed aggregation (aggregation every 10s). The acquired data comprehensively covers the task execution status and hardware operation status, specifically including: the actual resource utilization rate of the simulation task, task progress data, GPU hardware status data, and abnormal data. Among them, the actual resource utilization rate of the simulation task includes: the actual utilization rate of GPU cores, the actual utilization rate of video memory, and the actual consumption of computing power; the task progress data includes: the percentage of completed calculation steps, the prediction of remaining calculation time, and the efficiency of intermediate result generation; the GPU hardware status data includes: real-time updated GPU core load, remaining video memory, temperature, power consumption, and whether hardware abnormalities or data transmission delays have occurred; the abnormal data during task execution includes: calculation errors, resource lag, and data loss.

[0028] The expected goals of the resource allocation strategy in this embodiment, which serve as the benchmark for resource adjustment, are clearly defined by the strategy itself. Specifically, they include resource utilization goals, task execution efficiency goals, resource redundancy goals, and overall platform load balancing goals.

[0029] The resource adjustment model in this embodiment adopts a hybrid architecture of temporal Transformer encoder-reinforcement learning decision maker, specifically including a feature encoding module, a bias calculation module, and a decision generation module.

[0030] The feature encoding module employs a multi-layer Transformer encoder structure to extract features from the time-series sequence of the second running data. The input is a running state data matrix from the past T time steps. ;in, Where D is the time step and D is the feature dimension. The multi-layer Transformer encoder structure outputs the context encoding vector for the last time step. . This represents the model dimension of the Transformer encoder.

[0031] State fusion module: Concatenates the context encoding vector with the expected target vector G of the resource allocation strategy (including expected GPU utilization, expected task progress, etc.) to form the state input of the reinforcement learning decision-maker. , in, The dimension of the expected target vector.

[0032] The policy decision-making module employs an Actor-Critic-based reinforcement learning framework. The Actor network (policy network) receives the state. Output action probability distribution This corresponds to a pre-defined set of adjustment instructions (e.g., no operation, add one GPU slice, reduce one GPU slice, migrate task to node X, etc.). The Critic network (value network) evaluates the state value. It is used to optimize strategies during training.

[0033] The strategy decision-making module is trained end-to-end using the Proximal Policy Optimization (PPO) algorithm. The reward function is designed as follows: R = w1 × (current task progress rate / expected task progress rate) + w2 × (current GPU resource utilization / expected GPU resource utilization) - w3 × adjustment operation cost - w4 × task interruption penalty, where w1, w2, w3, and w4 are weighting coefficients.

[0034] The adjustment operation cost is normalized to the [0,1] interval, specifically: Adjustment operation cost = Actual adjustment cost / Maximum allowed adjustment cost. The task interruption penalty is also normalized to the [0,1] interval, specifically: Task interruption penalty = Actual interruption duration / Total expected task duration. The normalized cost and penalty terms can be directly weighted with other normalized indicators, making the reward function more balanced and comparable.

[0035] In this embodiment, the weight coefficients w1, w2, w3, and w4 are determined through multi-objective optimization and tuning based on historical task data. Specifically, based on the core objectives of task execution efficiency and resource utilization, w1=0.4, w2=0.4, w3=0.1, and w4=0.1 are initially set, making progress and utilization the primary factors influencing reward. The reward function is simulated and evaluated using historical task execution data, and the weights are adjusted within the range [0,1] using grid search or Bayesian optimization to select the weight combination that minimizes the average task completion time and maximizes resource utilization. In actual operation, the weights are lightly tuned quarterly based on the overall platform load and task type distribution to adapt to changes in task structure or hardware environment. Ultimately, the weight coefficients satisfy: w1+w2+w3+w4=1, with w1 and w2 being the dominant terms and w3 and w4 being the suppressive terms, allowing the model to improve efficiency while avoiding frequent adjustments and task interruptions.

[0036] During task execution, operational data is collected in real time, and the current state is obtained through the feature encoding module and the state fusion module. The Actor network generates actions (i.e., resource adjustment instructions), executes these instructions, and continuously monitors and provides feedback.

[0037] S104: Adjust the GPU resources allocated to the simulation task according to the resource adjustment instruction.

[0038] In this embodiment, based on the resource adjustment instructions output by the resource adjustment model, the platform resource management module makes precise adjustments to the GPU resources allocated to the simulation task through interface calls, and monitors the adjustment effect in real time, so that the simulation task can obtain optimal GPU resource support throughout its entire life cycle.

[0039] Specifically, the system first parses resource adjustment instructions and executes corresponding operations for different types of adjustment needs. For example, when it is necessary to increase the number of GPU cores, it selects available idle cores from the platform's available GPU nodes, allocates them to the simulation task, and updates the task's resource allocation record. When it is necessary to adjust the video memory quota, it releases the task's currently unused redundant video memory or supplements the quota from idle video memory resources to ensure that video memory adjustments do not cause intermediate data loss. When it is necessary to switch GPU nodes, it first saves the task's current execution state and intermediate results, then migrates the task to the target GPU node, restores the execution state, and avoids task interruption. Secondly, after the resource adjustment is completed, the second running data of the task is continuously collected, and the resource utilization, task progress, hardware status and other indicators before and after the adjustment are compared to determine whether the adjustment command has achieved the expected goal (whether the resource utilization has been improved, whether the task lag has been alleviated, and whether the hardware load has been balanced). In addition, if the adjustment effect does not meet expectations (the resource utilization rate is still low after adjustment, and the task is still stuck), the adjusted running data will be re-input into the resource adjustment model, and the model will re-analyze and output new adjustment instructions until the expected goal is achieved; if an abnormality occurs during the adjustment process (the adjustment causes task errors or hardware failures), an emergency strategy will be immediately executed to stop the resource adjustment, restore the resource allocation state before the adjustment, and trigger an abnormal alarm to notify the platform administrator for handling. Finally, when the simulation task is completed (or terminated by the user), a resource reclamation command is executed to release all GPU resources (including cores, video memory, etc.) occupied by the task. The reclaimed resources are then added back to the platform's available resource pool for allocation by other simulation tasks, thus achieving resource recycling.

[0040] By adopting the above technical solution, an initial resource template is generated by combining the simulation task's submission parameters, historical performance profiles, and task structure characteristics. The historical performance profile is constructed based on historical GPU resource usage data, ensuring that the initial prediction aligns with actual needs. Furthermore, a resource allocation strategy is matched to the current GPU hardware status to avoid blind allocation. During task execution, actual running data is collected and compared with the expected target. Adjustment instructions are generated using a resource adjustment model to achieve dynamic resource adaptation. These technical features are interconnected, forming a closed loop from initial prediction to dynamic adjustment, effectively improving GPU resource utilization, avoiding resource waste and shortages, ensuring stable and efficient execution of the simulation task, and reducing task execution error rates and delay probabilities.

[0041] As can be seen from the above, this application deeply mines task features through a configurable Transformer architecture resource prediction model to accurately generate initial resource templates; it achieves dynamic trade-offs between task requirements and hardware status through a lightweight MLP weight prediction model; and it achieves closed-loop optimization during runtime through a time-series Transformer-reinforcement learning hybrid architecture resource adjustment model. These three elements work together to form a complete AI-driven resource management closed loop from static prediction to dynamic adjustment. Secondly, based on the real-time status of GPU hardware, a dedicated allocation strategy is matched, taking into account both task requirements and hardware load balancing, further optimizing the rationality of resource scheduling. By collecting runtime data in real time and dynamically generating adjustment instructions through the resource adjustment model, dynamic adaptation of resource configuration is achieved, ensuring efficient and stable execution of simulation tasks. During task execution, by dynamically adjusting resource allocation parameters, idle GPU resources can be promptly allocated to other simulation tasks with needs, avoiding the long-term idleness of GPU resources in existing technologies, maximizing the computational performance of GPU hardware, and improving the GPU resource utilization rate of the entire design simulation platform. The entire process of this application requires no manual intervention, relying on AI to complete the entire process of resource management, reducing manual operation and maintenance costs, and improving the efficiency and accuracy of simulation task execution.

[0042] In one embodiment of this application, the first feature data is processed to obtain an initial resource template, including: The first feature data is standardized and encoded to generate a task feature vector; Based on the estimated computational complexity of the simulation task and the load fluctuation rate of the simulation platform, the configuration of the resource prediction model is adjusted to obtain the target prediction model. The resource prediction model adopts a configurable multi-layer Transformer encoder architecture, and dynamically selects the network depth and the number of attention heads according to the task complexity. Input the task feature vector into the target prediction model to obtain the initial resource template.

[0043] In this embodiment, the numerical data (input data size, historical execution time, etc.) in the first feature data are processed using Z-Score normalization and mapped to a normal distribution to eliminate the influence of dimensions. The categorical data (task type, GPU type, computationally intensive / data-intensive attributes, etc.) are converted using Embedding encoding. All processed data are integrated to form a task feature vector with a unified dimension.

[0044] Based on the estimated computational complexity of the simulation task and the load fluctuation rate of the simulation platform, the configuration of the resource prediction model is adjusted to obtain the target prediction model. The resource prediction model employs a configurable multi-layer Transformer encoder architecture, specifically including an input embedding layer, positional encoding, N Transformer encoder layers (each containing a multi-head self-attention mechanism and a feedforward neural network), and an output layer. The output layer comprises three branches: a fully connected layer for GPU type classification (connected to Softmax), and two more fully connected layers for computational power requirement and memory capacity regression (connected to ReLU). During model training, historical task data is used, with each sample including a task feature vector, the true GPU type (one-hot encoded), the true computational power requirement (normalized), and the true memory capacity (normalized). The loss function is a weighted sum of classification cross-entropy (GPU type) and mean squared error (computational power requirement, memory capacity), trained using the Adam optimizer. The pre-trained parameter matrix is ​​obtained as follows: during the training phase, the model is trained and parameters are saved for different combinations of encoder layers, attention heads, and learning rates, establishing a mapping table from configuration combinations to model parameters.

[0045] The estimated computational complexity is comprehensively evaluated based on the parameter configuration of the simulation task, the number of computation steps, and the scale of data processing. The load fluctuation rate of the simulation platform is calculated based on the ratio of the standard deviation to the mean of the platform's GPU resource utilization rate within a preset time period. Combining these two factors, the number of hidden layer neurons, activation function type, and iterative learning rate of the resource prediction model are dynamically adjusted to adapt the model to the current task characteristics and the load status of the simulation platform.

[0046] The task feature vector is input into the target prediction model. The target prediction model performs multi-dimensional analysis and feature correlation mining on the task feature vector, and outputs the initial prediction results of GPU type, computing power requirements and video memory capacity. After outlier removal and confidence verification, the initial resource template is finally generated.

[0047] As can be seen from the above, this application, by adopting the aforementioned technical solution, first standardizes and encodes the first feature data to eliminate data dimensional differences and redundancy, generating accurate task feature vectors to provide reliable input for subsequent predictions. Combining the simulation task's estimated computational complexity and platform load volatility, the resource prediction model configuration is adjusted to obtain the target prediction model, making the model adaptable to different task complexities and platform operating states, avoiding excessive prediction bias from a fixed model. The task feature vector is input into the target prediction model to generate an initial resource template, achieving accurate matching between the prediction model and the task and platform states. This improves the accuracy of GPU type, computing power, and video memory predictions in the initial resource template, laying a solid foundation for subsequent resource allocation and reducing resource waste or task execution anomalies caused by initial prediction bias.

[0048] In one embodiment of this application, the configuration of a preset resource prediction model is adjusted based on the estimated computational complexity of the simulation task and the load volatility of the simulation platform to obtain a target prediction model, including: Adjust the number of Transformer encoder layers in the resource prediction model based on the estimated computational complexity of the simulation task; the higher the estimated computational complexity, the more encoder layers are adjusted. The number of attention heads in the resource prediction model is adjusted based on the coefficient of variation of the task feature data; the larger the coefficient of variation, the more attention heads are needed. The learning rate of the resource prediction model is adjusted based on the load volatility of the design simulation platform; the higher the load volatility, the higher the learning rate should be adjusted to. Based on the adjusted number of encoder layers, number of attention heads, and learning rate, the corresponding model parameters are loaded from the pre-trained parameter matrix to obtain the target prediction model.

[0049] In this embodiment, the number of Transformer encoder layers is adjusted based on the estimated computational complexity. The estimated computational complexity is comprehensively evaluated based on the simulation task's parameter configuration, number of computational steps, data processing scale, and core computational module complexity, and a quantitative scoring method is used to determine the complexity level (e.g., low, medium, high). The higher the complexity, the more layers (depth) of the Transformer encoder are added. Increasing the number of layers enhances the model's ability to capture and understand deep, nonlinear feature correlations in high-complexity tasks, thereby improving prediction accuracy.

[0050] Adjusting the number of attention heads based on the task feature variation coefficient: Combining the task feature variation coefficient calculated earlier (representing the dispersion of task features), dynamically adjust the number of attention heads in each Transformer layer. A larger variation coefficient indicates more significant differences in task features, requiring a stronger parallel feature interaction capability from the model; therefore, the number of attention heads should be increased accordingly. This aims to improve the model's ability to distinguish and fuse diverse and heterogeneous task features.

[0051] The learning rate is adjusted based on the platform load volatility: The load volatility of the simulation platform is calculated based on the ratio of the standard deviation to the mean of the platform's GPU resource utilization over a preset time period (the most recent 10 minutes). A higher load volatility indicates more drastic changes in platform resource status; in this case, the model learning rate is adjusted to a higher value range to accelerate the model's adaptation to the dynamic environment during inference or fine-tuning. Conversely, a lower learning rate is used to maintain prediction stability.

[0052] Based on the determined combination of encoder layers, attention heads, and learning rate, the system loads the corresponding optimal model parameters from the pre-trained parameter matrix to quickly construct the target prediction model. This pre-trained parameter matrix uses offline grid search or automated machine learning techniques to pre-train and save optimal parameters for different combinations (number of layers, number of attention heads, learning rate), establishing an index mapping from configuration combinations to model parameter files. Directly loading pre-trained parameters avoids the significant overhead of online retraining, significantly shortens model adaptation time, and ensures excellent initial performance of the target prediction model, thereby generating initial resource templates efficiently and accurately.

[0053] As can be seen from the above, by adopting the aforementioned technical solution, this application firstly achieves high-precision and adaptive prediction of the initial GPU resource requirements (type, computing power, and video memory) for simulation tasks by using a resource prediction model based on a configurable Transformer encoder architecture and dynamically adjusting its layer number, attention head number, and learning rate according to task complexity, feature variation coefficient, and platform load volatility, thus providing a scientific and reliable benchmark for resource allocation. Secondly, a lightweight MLP weight prediction model dynamically balances task requirements and real-time hardware status, generating adaptive fusion weights to ensure that the resource allocation strategy not only meets the core requirements of the task but also takes into account the overall load balance of the platform and the health of the hardware. Furthermore, a resource adjustment model based on a temporal Transformer-reinforcement learning hybrid architecture accurately compares and makes decisions on real-time data and expected targets during task execution, dynamically generating and executing fine-grained resource adjustment instructions (such as computing power slicing adjustment and task migration), achieving real-time dynamic matching between resource supply and task requirements. The three models mentioned above are interconnected and work together to form a complete closed loop of "accurate prediction - intelligent trade-off - dynamic adjustment - feedback optimization". This fundamentally solves the problems of GPU resource waste and low task execution efficiency caused by inaccurate initial prediction, rigid allocation, and delayed adjustment, and significantly improves the overall resource utilization and task execution efficiency of the design simulation platform.

[0054] In one embodiment of this application, adjusting the learning rate of the resource prediction model based on the load volatility of the design simulation platform includes: Obtain time-series data of GPU utilization of the design simulation platform within a preset time window; Calculate the standard deviation and mean of time series data; If the mean is greater than or equal to the load threshold, then the load volatility is the ratio of the standard deviation to the mean. If the mean is less than the load threshold, the load volatility is the ratio of the standard deviation to the preset normalization factor. Based on load volatility, the learning rate of the resource prediction model is calculated and set using a preset nonlinear function.

[0055] In this embodiment, the preset time window can be flexibly configured (5 minutes or 10 minutes) according to the platform load change characteristics, which can comprehensively capture the recent fluctuations in the platform GPU load. The time series data is the utilization data of all GPU nodes obtained within the time window according to a fixed collection frequency (collected once every 1 second), which is integrated to form a unified GPU utilization time series.

[0056] This embodiment first preprocesses the acquired GPU utilization time series data to remove outliers. Then, it calculates the mean and standard deviation of the time series. If the mean is greater than or equal to the load threshold, the load volatility is characterized by relative volatility intensity. The load volatility is obtained by dividing the standard deviation by the mean. The larger the ratio, the more drastic the GPU load fluctuation on the platform, and vice versa.

[0057] If the mean is less than the load threshold, the system is considered to be in a low-load state. To avoid the relative volatility being abnormally amplified due to an excessively small mean, the load volatility is represented by normalized absolute volatility intensity, i.e., the load volatility is the ratio of the standard deviation to a preset normalization factor. The normalization factor maps the absolute volatility standard deviation to an order of magnitude similar to the relative volatility intensity range under normal load conditions, thus ensuring consistency of the input to the subsequent learning rate calculation function. The value of the normalization factor is obtained through statistical historical data. For example, it takes time windows of historical data where the mean is greater than or equal to the load threshold, calculates the arithmetic mean of the standard deviations σ corresponding to these windows, and uses this mean as the normalization factor.

[0058] Next, based on the load volatility, the learning rate of the resource prediction model is calculated and set using a preset nonlinear function. This nonlinear function is designed and calibrated for a uniform dimension and numerical range of the load volatility. The preset nonlinear function (such as a variant of the sigmoid function) has been pre-trained and optimized using a large amount of platform load scenario data. Its input is the load volatility, and its output is the appropriate learning rate value. The mapping logic of this nonlinear function follows the principle that the higher the load volatility, the higher the output learning rate. At the same time, the range of the learning rate is limited (0.001-0.01) to avoid the model becoming unstable due to an excessively high learning rate or unable to quickly adapt to load changes due to an excessively low learning rate. Finally, the learning rate calculated through the nonlinear function is directly set as the adjusted learning rate of the resource prediction model, completing the dynamic adaptation of the learning rate.

[0059] In this embodiment, the load threshold is used to distinguish between the platform's normal load state and low load state. Its value is not a fixed empirical value, but is dynamically determined based on statistical analysis of the historical operating data of the design simulation platform. The specific method is as follows: Collect time-series data on the utilization of all GPUs in the design simulation platform over a typical historical operating cycle (e.g., the past 30 days). The data acquisition granularity is consistent with the preset time window.

[0060] All collected GPU utilization data are used to calculate their window mean within a preset time window (e.g., 10 minutes), forming data points representing the average load level of the platform as a whole within each time window. Statistical analysis is performed on the above window mean dataset to plot its probability distribution or cumulative distribution. Platform load typically exhibits a bimodal or multimodal distribution, with one of the lower peaks or the left inflection point of the distribution curve corresponding to the platform's basic idle state. Based on the distribution analysis results, the load threshold is determined using one of the following two methods.

[0061] The quantile method calculates the lower quantile (e.g., the 5th or 10th percentile) of the window mean dataset and sets this quantile value as the load threshold. This method implies that historically, the average load was below this load threshold for approximately 5% or 10% of the time window.

[0062] The distribution pattern method involves observing the histogram or kernel density estimation curve of the window mean data distribution and setting the utilization value corresponding to the first obvious trough (i.e., the critical point separating idle clusters from clusters with basic load) as the load threshold. If there is no obvious trough in the distribution, the inflection point where the probability density starts to rise significantly from the platform's idle background value can be selected.

[0063] As can be seen from the above, this application, by adopting the aforementioned technical solution, obtains time-series data of GPU utilization within a preset time window, comprehensively capturing the dynamic changes in platform load and avoiding calculation deviations in load volatility caused by data from a single time point. The load volatility is obtained by calculating the ratio of the standard deviation to the mean of the time-series data, accurately quantifying the degree of platform load fluctuation and providing a scientific basis for learning rate adjustment. Based on the load volatility, the learning rate is calculated using a preset nonlinear function, ensuring a reasonable correspondence between learning rate adjustment and the degree of load volatility, avoiding insufficient adaptation caused by linear adjustment. The synergistic effect of these technical features achieves accurate calculation of load volatility and reasonable adaptation of the learning rate, ensuring that the resource prediction model maintains high prediction accuracy under different load fluctuation scenarios.

[0064] In one embodiment of this application, a GPU resource management method based on an AI-driven design simulation platform further includes: The scalar data in the first feature data are numericalized and standardized to obtain the first scalar feature data. Calculate the mean and standard deviation of the first scalar feature data, and use the ratio of the standard deviation to the mean as the coefficient of variation; this coefficient of variation characterizes the micro-dispersion of the task-level feature data. When the coefficient of variation is greater than the first threshold, the number of attention heads in the resource prediction model is increased by the first step length; when the coefficient of variation of task features is high, it indicates that the task types are diverse or the requirements are different, and the model needs to have stronger feature extraction and interaction capabilities. Therefore, the number of attention heads is increased to improve the model capacity. When the coefficient of variation is less than or equal to the first threshold and greater than or equal to the second threshold, the number of attention heads of the resource prediction model is increased by a second step size; wherein the second step size is less than the first step size. When the coefficient of variation is less than the second threshold, the number of attention heads in the resource prediction model is reduced by a third step size. The second threshold is less than the first threshold. The first and second thresholds are determined based on the statistical distribution characteristics of the coefficient of variation of historical task feature data.

[0065] In this embodiment, based on the microscopic dispersion of the first feature data, the number of attention heads of the resource prediction model is dynamically adjusted to further optimize the model's feature extraction capability and adapt to the differences in features of different tasks. The specific process is as follows: The scalar data in the first feature data is numericalized and standardized to obtain the first scalar feature data. The scalar data refers to the basic data that can be directly quantified in the first feature data (task input data scale, historical execution time, GPU resource utilization efficiency, expected execution time, etc.). The numericalization process is used to convert the non-pure numerical scalar data (percentage form) into a pure numerical format. The standardization process adopts a normalization method to map the numericalized scalar data to a preset unified interval [0,1] to eliminate the influence of the units. Finally, the first scalar feature data is obtained by integration.

[0066] The mean and standard deviation of the first scalar feature data are calculated, and the ratio of the standard deviation to the mean is used as the coefficient of variation. The coefficient of variation characterizes the micro-dispersion of the task-level feature data. The larger the coefficient of variation, the higher the dispersion of the first scalar feature data, that is, the more significant the differences in scalar features of different dimensions, reflecting the greater diversity of simulation task types or resource requirements. The smaller the coefficient of variation, the more concentrated the first scalar feature data, and the smaller the differences in task features.

[0067] In this embodiment, based on the comparison between the coefficient of variation and a preset threshold, the number of attention heads in the resource prediction model is dynamically adjusted, as follows: When the coefficient of variation is greater than the first threshold, the number of attention heads of the resource prediction model is increased by a step size. When the coefficient of variation of the task features is high, it indicates that the task types are diverse or the requirements are different. The model needs to have stronger feature extraction and interaction capabilities. Therefore, the number of attention heads is increased to improve the model capacity and ensure that the model can accurately capture the correlation between scalar features of different dimensions and reduce prediction bias. When the coefficient of variation is less than or equal to the first threshold and greater than or equal to the second threshold, the number of attention heads of the resource prediction model is increased by a second step size; wherein the second step size is less than the first step size. In this scenario, the task features are moderately discrete, so there is no need to significantly increase the number of attention heads. A small increase is sufficient to balance model performance and computational efficiency. When the coefficient of variation is less than the second threshold, the number of attention heads in the resource prediction model is reduced by a third step, where the second threshold is less than the first threshold. In this scenario, the task features are low in dispersion and concentrated in distribution. Reducing the number of attention heads can reduce model redundancy, reduce computational overhead, and avoid model overfitting. The first and second thresholds are determined based on the statistical distribution characteristics of the coefficient of variation of historical task feature data. Specifically, the distribution pattern (normal distribution) of the coefficient of variation of the first scalar feature data of all historical simulation tasks of the simulation platform is analyzed by statistically designing the simulation platform. Combined with the prediction accuracy requirements of the resource prediction model, the threshold range is set so that the threshold can accurately distinguish different task feature dispersion scenarios and can be continuously optimized based on the long-term operation data of the platform.

[0068] After the number of attention heads is adjusted, the configuration of the resource prediction model is updated synchronously. Combined with the previously adjusted network depth, width, learning rate and loaded pre-training parameters, the target prediction model is finally determined, so that the target prediction model is adapted to the dispersion of the current task features, and the prediction accuracy of the initial resource template is further improved.

[0069] As can be seen from the above, this application, by adopting the aforementioned technical solution, performs numerical and standardized processing on the scalar data in the first feature data, ensuring data standardization and providing a reliable foundation for calculating the coefficient of variation. Calculating the coefficient of variation of the scalar feature data accurately characterizes the micro-dispersion of the task-level feature data, reflecting the magnitude of differences in task type and requirements. Based on the comparison results of the coefficient of variation with different thresholds, the number of attention heads is adjusted with different step sizes; the higher the coefficient of variation, the larger the step size, ensuring a precise match between the number of model attention heads and the dispersion of task features. This adjustment method enables the model to have stronger feature extraction and interaction capabilities when task features differ greatly, reduces redundancy when differences are small, improves model prediction efficiency and accuracy, and further optimizes the generation effect of the initial resource template.

[0070] In one embodiment of this application, a resource allocation strategy for the simulation task is generated by matching the initial resource template and current GPU hardware state data from a pre-set resource allocation strategy library, including: The initial resource template is processed to generate a task requirement feature vector; The GPU hardware status data is processed to generate a hardware status feature vector; the GPU hardware status data includes the overall cluster load, single GPU utilization, and health status. Input the task requirement feature vector and hardware state feature vector into the preset weight prediction model to obtain the adaptive weights of the task requirement feature vector and hardware state feature vector. Based on adaptive weights, the task requirement feature vector and hardware status feature vector are weighted and fused to obtain a comprehensive requirement score. Based on the comprehensive demand score and the pre-defined score-level mapping relationship, the resource demand level of the simulation task is determined. Based on the resource requirement level, the resource allocation strategy for the simulation task is matched from the pre-set resource allocation strategy library; the resource allocation strategy library stores the GPU type, quantity, memory configuration and scheduling priority strategy corresponding to different resource requirement levels.

[0071] In this embodiment, the initial resource template is processed to generate a task requirement feature vector. The initial resource template includes the initial prediction results of GPU type, computing power requirement, and video memory capacity. During the processing, the prediction results of various types in the initial resource template are first quantized and encoded (such as quantizing GPU type by computing power level and video memory capacity by interval). Then, normalization is used to eliminate the difference in dimensions. All the quantized and encoded data are integrated to generate a task requirement feature vector with unified dimensions that can be used for model calculation, accurately representing the core GPU resource requirements of the simulation task.

[0072] The GPU hardware status data is processed to generate a hardware status feature vector. The GPU hardware status data includes the overall cluster load, single GPU utilization and health status, as well as the number of available cores, available video memory capacity, temperature, power consumption, network bandwidth usage and node cluster information for each GPU. During processing, outliers in the hardware status data are first removed, numerical data such as the overall cluster load and single GPU utilization are normalized, and categorical data such as GPU health status are converted using one-hot encoding. All processed data are integrated to generate a hardware status feature vector that comprehensively reflects the overall status and availability of the current platform's GPU hardware.

[0073] The task requirement feature vector and hardware state feature vector are input into a pre-defined weight prediction model to obtain adaptive weights for the task requirement feature vector and hardware state feature vector. The weight prediction model adopts a lightweight multilayer perceptron structure, including an input concatenation layer, three fully connected hidden layers, and an output layer. It has been trained and optimized using a large amount of historical resource allocation data and can dynamically output adaptive weights based on the real-time matching of task requirements and hardware state. Specifically, the weight prediction model uses a three-layer fully connected neural network (MLP). The input layer dimension is the sum of the dimensions of the task requirement feature vector and the hardware state feature vector, the hidden layer dimensions are 128 and 64 respectively, and the output layer dimension is 2. The Softmax activation function is used to output the weights of the two features. The training data comes from historical task execution records, and each record includes a task requirement feature vector, a hardware state feature vector, and a label. The label construction method is as follows: For the historical task, different weight combinations (i.e., the weights of the task requirement feature vector and the hardware state feature vector) are tried. A comprehensive requirement score is calculated by weighted fusion under each weight. Then, a resource allocation strategy is matched based on this score, and the strategy is simulated to obtain a task execution performance score (calculated based on actual completion time, resource utilization, cost, etc.). The weight combination with the highest task execution performance score is selected as the label for the training sample. During training, the mean squared error loss function is used, and the optimizer is Adam.

[0074] When the platform has sufficient GPU resources (low hardware load), increase the weight of the task requirement feature vector to prioritize meeting the resource requirements of the task itself; when the platform has limited GPU resources (high hardware load), increase the weight of the hardware status feature vector to prioritize overall platform load balancing and ensure that the weight allocation fits the actual scenario requirements.

[0075] The task requirement feature vector and hardware state feature vector are weighted and fused based on the adaptive weights to obtain a comprehensive requirement score. The fusion process adopts a linear weighted calculation method, multiplying the data of each dimension of the task requirement feature vector with the corresponding adaptive weight, multiplying the data of each dimension of the hardware state feature vector with the corresponding adaptive weight, and then summing all the product results to obtain the comprehensive requirement score. This score comprehensively considers the resource requirements of the simulation task and the carrying capacity of the platform hardware, providing a quantitative basis for determining the resource requirement level.

[0076] Based on the comprehensive demand score and the pre-defined score-level mapping relationship, the resource demand level of the simulation task is determined. The method for establishing the score-level mapping relationship is as follows: Collect comprehensive demand score data of historical simulation tasks to form a dataset; use the elbow method to analyze the distribution of the above dataset and determine the optimal number of clusters. Calculate the sum of squared errors (SSE) within clusters of K-means clustering under different optimal cluster size values ​​(2-10), and select the optimal cluster size value corresponding to the inflection point (elbow point) of the SSE decreasing trend as the number of levels and as the final division criterion. Use unsupervised clustering algorithms such as K-means to cluster the dataset according to the determined number of levels to obtain multiple clusters. Calculate the minimum and maximum values ​​of all scores in each cluster, and use this range as the score range for the corresponding resource demand level. For example, after clustering, three clusters may be generated, with score ranges corresponding to [0, 0.4), [0.4, 0.75], and [0.75, 1.0], which can be defined as low, medium, and high resource demand levels, respectively. Each level and its corresponding rating range are stored as a rating-level mapping table.

[0077] The resource allocation strategy library stores the GPU type, quantity, memory configuration, and scheduling priority strategies corresponding to different resource requirement levels. For example, high resource requirement levels correspond to high-performance computing GPUs, more cores, larger memory configurations, and higher scheduling priorities, while low resource requirement levels correspond to general-purpose GPUs, a moderate number of cores, and conventional memory configurations. During matching, based on the determined resource requirement level, the corresponding preset strategy in the strategy library is directly retrieved, and minor adjustments are made in conjunction with the current hardware status to ultimately generate a dedicated resource allocation strategy adapted to the simulation task.

[0078] The training method for the weighted prediction model includes: collecting historical simulation task data, each data point including: historical task requirement feature vector, historical hardware state feature vector, and corresponding strategy execution effect score label; the strategy execution effect score label is obtained by weighted calculation based on the actual completion time, total resource utilization rate, and resource cost of the corresponding historical task; using the historical task requirement feature vector and historical hardware state feature vector as input features, and the strategy execution effect score label as supervision signal, the weighted prediction model is trained so that the model learns to predict feature fusion weights that make the comprehensive requirement score approach the strategy execution effect score label.

[0079] As can be seen from the above, this application, by adopting the aforementioned technical solution, processes the initial resource template and GPU hardware status data separately to generate corresponding feature vectors, clearly distinguishing between task requirements and hardware status, and providing clear input for subsequent weighted fusion. Adaptive weights of the two types of feature vectors are obtained using a weight prediction model, achieving a dynamic balance between task requirements and hardware status, avoiding unreasonable resource allocation caused by a single factor. A comprehensive requirement score is obtained through weighted fusion, and the resource requirement level is determined by combining the score-level mapping relationship, making the requirement level classification scientific and accurate. Resource allocation strategies are matched according to the requirement level, ensuring a high degree of adaptation between the strategy and task requirements and hardware status, improving the rationality and targeting of GPU resource allocation, ensuring efficient task execution while reducing resource waste.

[0080] In one embodiment of this application, a GPU resource management method based on an AI-driven design simulation platform further includes: If the average deviation rate between the actual execution time and the predicted execution time of the most recent N historical simulation tasks is greater than the first deviation threshold, then the weight of the task requirement feature vector is increased based on the first proportion; the first deviation threshold is determined based on the statistical distribution results of the historical task execution deviations of the design simulation platform. If the frequency of abnormal GPU health events detected within a unit of time exceeds the first frequency threshold, the weight of the GPU health status component in the hardware status feature vector is increased based on the second ratio.

[0081] In this embodiment, if the average deviation rate between the actual execution time and the predicted execution time of the most recent N historical simulation tasks is greater than a first deviation threshold, the weight of the task requirement feature vector is increased based on a first proportion. Here, N is a preset number of historical tasks, which can be flexibly configured according to the platform's task execution frequency, such as N=10 or 20. The average deviation rate is obtained by calculating the average of "|actual execution time - predicted execution time| / predicted execution time" for each of the most recent N historical tasks, and is used to characterize the degree of deviation in the predicted execution time of historical tasks. The first deviation threshold is determined based on the statistical distribution results of the historical task execution deviations of the simulation platform. Specifically, it is determined by analyzing the distribution pattern of the execution time deviation rates of all past simulation tasks on the platform (e.g., taking the 90th percentile as the threshold), and setting the first deviation threshold in conjunction with task execution efficiency requirements. When the average deviation rate is greater than this first deviation threshold, it indicates that the weight of the current task requirement feature vector is insufficient to accurately match the actual task requirements, and its weight needs to be increased according to a first proportion (e.g., 5%-10%) to enhance the dominant role of task requirements in resource allocation and reduce execution time deviation. If the frequency of abnormal GPU health events detected within a unit of time exceeds a first frequency threshold, the weight of the GPU health status component in the hardware status feature vector is increased based on a second ratio. The unit of time can be preset to 1 hour or 2 hours. Abnormal GPU health events include abnormalities determined by the platform's hardware monitoring module, such as excessive GPU temperature, abnormal power consumption, memory errors, and hardware fault warnings. The frequency is the cumulative number of such abnormal events within a unit of time. The first frequency threshold is set according to the stable operation standard of the GPU hardware and is used to characterize the degree of abnormality in the GPU health status. When the frequency exceeds this first frequency threshold, it indicates a significant risk to the current GPU hardware health status. Therefore, the weight of the GPU health status component in the hardware status feature vector needs to be increased according to the second ratio (3%-8%) to enhance the consideration of GPU health status in resource allocation, avoid allocating resources to GPU nodes with poor health status, and ensure stable execution of simulation tasks. The second ratio can be set independently of the first ratio based on the impact of GPU health status on task execution.

[0082] After the weight correction is completed, the corrected adaptive weight is used as the final weight for the subsequent weighted fusion of the task requirement feature vector and the hardware status feature vector, so that the comprehensive requirement score can more accurately take into account the task requirements, platform load and hardware health status.

[0083] As can be seen from the above, this application, by adopting the aforementioned technical solution, monitors the execution time deviation rate of the most recent N historical simulation tasks, accurately capturing the matching degree between task requirement prediction and actual execution. When the deviation rate exceeds the first deviation threshold, the weight of the task requirement feature vector is increased, making resource allocation more focused on the actual task requirements and reducing unreasonable resource allocation caused by requirement prediction deviations. It also monitors the frequency of GPU health status anomalies within a unit of time, promptly identifying potential GPU hardware health issues. When the frequency exceeds the first frequency threshold, the weight of the hardware health status component is increased, ensuring that resource allocation takes hardware stability into account and reducing the risk of task execution failure due to hardware anomalies. These two weight adjustment mechanisms work synergistically to dynamically adapt to changes in task execution deviation and hardware health status, optimizing the accuracy of the comprehensive requirement score, further improving the adaptability of the resource allocation strategy, and ensuring the stability and efficiency of task execution.

[0084] In one embodiment of this application, the second operating data and the expected target of the resource allocation strategy are input into the resource adjustment model to obtain a resource adjustment instruction, including: The expected goals of the resource allocation strategy are used as the baseline input to the resource adjustment model; the expected goals include the expected range of GPU resource utilization and the expected task progress speed; the resource adjustment model is pre-set with the expected goals corresponding to the resource allocation strategy, including the expected range of GPU resource utilization and the expected task progress speed. The second set of operational data is preprocessed to obtain standardized status data, which is then input into the resource adjustment model. In the resource adjustment model, the deviations between the actual resource utilization rate and the expected target, and the deviations between the actual task progress and the expected target in the status data are calculated, and their weighted sum is calculated as the comprehensive deviation. Based on the overall deviation and preset threshold conditions, corresponding resource adjustment instructions are generated.

[0085] In this embodiment, the expected target of the resource allocation strategy is used as a benchmark input to the resource adjustment model; the expected target includes the expected range of GPU resource utilization and the expected task progress speed; the resource adjustment model is preset with the expected target corresponding to the resource allocation strategy, and the expected target includes the expected range of GPU resource utilization and the expected task progress speed. The second running data is preprocessed to obtain standardized status data, which is then input into the resource adjustment model. The preprocessing process includes outlier removal and numerical normalization (mapping numerical data such as actual resource utilization and task progress to the [0,1] interval to eliminate the influence of units), which improves the accuracy and consistency of the status data and meets the input requirements of the resource adjustment model.

[0086] Specifically, the inputs to the resource adjustment model include: a preprocessed and standardized second-run data time series; the expected target vector defined in the resource allocation strategy; and a calculated multidimensional deviation index. These inputs are converted into a unified feature representation through a feature encoding module.

[0087] In the resource adjustment model, the deviations of actual resource utilization from the expected target and actual task progress from the expected target in the status data are calculated, and their weighted sum is calculated as the comprehensive deviation. The deviation of actual resource utilization is the amount of deviation between the actual resource utilization and the upper and lower bounds of the expected utilization range (0 if within the range). The deviation of actual task progress is |actual task progress - expected task progress| / expected task progress, used to quantify the degree of deviation in task progress. The weights of the weighted sum are set based on the priority of the resource allocation strategy. For example, when the priority of task execution efficiency is higher than that of resource utilization, the weight of the deviation of actual task progress is increased; conversely, the weight of the deviation of actual resource utilization is increased, ensuring that the comprehensive deviation accurately reflects the shortcomings in the matching between current resource allocation and task requirements. Based on the comprehensive deviation and the preset threshold conditions, corresponding resource adjustment instructions are generated. The preset threshold conditions are divided into multiple intervals, each corresponding to a different adjustment scenario. The adjustment range and timing are also clearly defined so that the adjustment process does not affect the normal execution of the simulation task.

[0088] As can be seen from the above, this application, by adopting the aforementioned technical solution, uses the expected goals of the resource allocation strategy as a benchmark input to the resource adjustment model, clarifies the evaluation criteria for resource adjustments, and ensures that the adjustment direction aligns with expected needs. The second set of operational data is preprocessed to obtain standardized state data, eliminating data interference and ensuring the accuracy and reliability of the data input to the model. The deviation value and comprehensive deviation degree between the actual data and the expected goals are calculated in the model, accurately quantifying the degree of deviation between resource usage and task progress, providing a scientific basis for resource adjustments. Adjustment instructions are generated based on the comprehensive deviation degree and preset threshold conditions, giving resource adjustments clear triggering standards and directions, avoiding blind adjustments. These technical features form a complete adjustment logic, achieving precise and standardized resource adjustments and ensuring a dynamic balance between resource supply and demand during task execution.

[0089] In one embodiment of this application, a corresponding resource adjustment instruction is generated based on a comprehensive deviation and a preset threshold condition, including: When the overall deviation is greater than the first positive threshold, a computing power expansion instruction is generated. The computing power expansion instruction includes the number of GPU computing power slices to be increased based on the ratio of the overall deviation to the first positive threshold. Among them, a GPU computing power slice refers to the smallest allocatable logical unit with a fixed proportion of stream processors and video memory, which is divided by GPU virtualization technology. When the overall deviation is less than the first negative threshold, a computing power reduction instruction is generated. The computing power reduction instruction includes the number of GPU computing power slices to be released, calculated based on the ratio of the overall deviation to the first negative threshold. If the GPU hardware error rate in the second running data exceeds a predefined health threshold, a task migration instruction is generated. The task migration instruction includes: interrupting the execution of the task on the currently faulty GPU, saving the checkpoint, and rescheduling the checkpoint to a healthy GPU in the cluster to continue execution; the first positive threshold and the first negative threshold are dynamically adjusted based on historical task execution stability statistics.

[0090] In this embodiment, when the overall deviation is greater than a first positive threshold, a computing power expansion instruction is generated. The computing power expansion instruction includes the number of GPU computing power slices to be increased based on the ratio of the overall deviation to the first positive threshold. The GPU computing power slice refers to the smallest allocatable logical unit with a fixed ratio of stream processors and video memory, which is divided by GPU virtualization technology. The larger the ratio, the more GPU computing power slices are added, ensuring that the expansion range matches the overall deviation, accurately making up for resource gaps, and improving task execution efficiency. When the overall deviation is less than the first negative threshold, a computing power reduction instruction is generated. The computing power reduction instruction includes the number of GPU computing power slices to be released based on the ratio of the overall deviation to the first negative threshold. The larger the absolute value of the ratio, the more GPU computing power slices are released. Under the premise of not affecting the normal execution of the task, redundant resources are released, and the overall utilization rate of the platform's GPU resources is improved. If the GPU hardware error rate in the second running data exceeds a predefined health threshold, a task migration instruction is generated. The task migration instruction includes: interrupting the execution of the task on the currently faulty GPU, saving the checkpoint (key information such as the current execution status of the task, intermediate calculation results, and parameter configuration), and rescheduling the checkpoint to a healthy GPU in the cluster to continue execution, ensuring that the task is not interrupted and the data is not lost; The first positive threshold and the first negative threshold are dynamically adjusted based on the statistical results of historical task execution stability. Specifically, the correlation between the comprehensive deviation data of all historical simulation tasks and task execution stability (uninterrupted execution time and error rate) is analyzed through the statistical platform, and the threshold values ​​are dynamically optimized so that the thresholds can accurately distinguish between resource shortage and resource redundancy scenarios, taking into account both task execution stability and resource utilization efficiency.

[0091] As can be seen from the above, this application, by adopting the aforementioned technical solution, generates targeted computing power expansion and reduction instructions based on the comparison of the comprehensive deviation with different thresholds. The greater the comprehensive deviation exceeds the standard, the larger the adjustment range, achieving precise matching between computing power adjustment and the degree of deviation. Introducing GPU computing power slices as the smallest allocatable logical unit makes computing power adjustment more refined and flexible, avoiding waste or insufficiency caused by overall resource adjustments. When the GPU hardware error rate exceeds the standard, a task migration instruction is generated. By interrupting the task, saving checkpoints, and migrating to a healthy GPU, task failure or data loss due to hardware failure is avoided. Simultaneously, positive and negative thresholds are dynamically adjusted to adapt to different task execution scenarios. The synergistic effect of these technical features achieves precise computing power adjustment and reliable task migration, ensuring stable task execution while improving resource utilization.

[0092] In one embodiment of this application, a GPU resource management method based on an AI-driven design simulation platform further includes: The quality of the second set of operational data was assessed to obtain the data confidence level. Based on the data confidence level, the deviations of the actual resource utilization rate from the expected target and the deviations of the actual task progress from the expected target in the status data are corrected to obtain the corrected comprehensive deviation.

[0093] In this embodiment, the second running data is subjected to quality assessment to obtain data confidence level. The quality assessment is carried out around three dimensions: data integrity, accuracy, and stability. Data integrity assesses the missing rate of the collected data, data accuracy assesses the deviation range of the collected data from historical normal data and the proportion of abnormal data, and data stability assesses the fluctuation range of the collected data. The three dimensions are weighted and scored using a preset assessment model to generate a data confidence level between 0 and 1. The closer the confidence level is to 1, the better the quality and the higher the credibility of the second running data. The closer it is to 0, the worse the data quality and the lower the credibility. Based on the data confidence level, the deviations of the actual resource utilization rate from the expected target and the deviations of the actual task progress from the expected target in the status data are corrected to obtain the corrected comprehensive deviation. The correction logic follows the principle that the higher the data confidence level, the smaller the correction magnitude; and the lower the data confidence level, the larger the correction magnitude. Specifically, the two deviation values ​​are multiplied by the data confidence level respectively to obtain the corrected deviation values, and then the weighted sum of the two is calculated based on the original weighting ratio to serve as the corrected comprehensive deviation. When the data confidence level is too low (below the preset confidence threshold), the normal deviation values ​​of similar historical tasks are introduced as auxiliary correction factors to avoid deviations in the comprehensive deviation calculation due to data quality issues. The preset confidence threshold is determined as follows: during the model training phase, the average data confidence level corresponding to the significant decrease in model accuracy (e.g., a decrease of more than 10%) caused by testing resources with data subsets of different qualities to adjust the model's decision accuracy is set as the preset confidence threshold.

[0094] As can be seen from the above, this application, by adopting the aforementioned technical solution, performs a quality assessment of the second operational data to obtain data confidence, accurately determining the reliability of the operational data and avoiding resource adjustment deviations caused by low-confidence data. Based on the data confidence, the deviation between actual resource utilization and task progress is corrected, and the deviation corresponding to low-confidence data is reasonably corrected, reducing the impact of data errors on the calculation of the overall deviation and improving the accuracy of the overall deviation. The corrected overall deviation can more realistically reflect the actual situation of task operation and resource allocation, making the resource adjustment instructions generated based on it more in line with actual needs, avoiding blind adjustments caused by unreliable data, further optimizing the dynamic adjustment effect of resources, and ensuring resource supply and demand balance and efficient task execution.

[0095] In one embodiment of this application, the quality of the second running data is evaluated to obtain data confidence level, including: The monitoring component's own health status indicators are used to score each data item in the second running data to obtain the individual confidence level of each data item. The monitoring component's own health status indicators include: whether the data reporting heartbeat is normal, whether the reporting timestamp is continuous, and whether the resource utilization rate of its own process is within the normal range. The confidence scores of each data item in the second run data are obtained by weighting the confidence scores of each data item according to their importance weights.

[0096] In this embodiment, each data item in the second running data is scored based on the health status indicators of the monitoring component to obtain the individual confidence score of each data item. The health status indicators of the monitoring component include: whether the data reporting heartbeat is normal, whether the reporting timestamp is continuous, and whether the resource utilization rate of its own process is within the normal range. Among them, if the data reporting heartbeat is normal, the timestamp is continuous, and the process resource utilization rate is within the normal range, the individual confidence score of the corresponding data item is high (approaching 1). If there are situations such as heartbeat interruption, missing / discontinuous timestamps, or excessive process resource utilization rate, the individual confidence score of the corresponding data item is reduced according to the severity of the abnormality (the more severe the abnormality, the lower the score, approaching 0), to ensure that the individual confidence score can accurately reflect the credibility of a single data item. The data confidence score is obtained by weighting the individual confidence scores of each data item in the second operational data according to the importance weight of each data item; wherein, the importance weight is set based on the degree of influence of the data item on resource adjustment decisions. In this embodiment, when calculating the weighted average, the individual confidence score of each data item is multiplied by the corresponding importance weight and then summed to obtain the final data confidence score between 0 and 1. The closer the confidence score is to 1, the better the overall quality and the higher the credibility of the second operational data; the closer it is to 0, the worse the data quality and the lower the credibility.

[0097] As can be seen from the above, this application, by adopting the aforementioned technical solution, scores each data item based on the health status indicators of the monitoring component itself. This allows for the assessment of data reliability from the data collection source, as the health status of the monitoring component directly affects data quality. This scoring method ensures the accuracy of individual item confidence scores. By combining the importance weights of each data item, a weighted average of the individual item confidence scores is obtained, ensuring that the reliability of important data items accounts for a higher proportion of the overall confidence score and preventing secondary data items from interfering with the overall judgment. This evaluation method considers both the data collection source and the importance of the data, comprehensively and accurately quantifying the quality of the second operational data, providing a scientific basis for subsequent deviation correction, ensuring the rationality of resource adjustment instructions, and improving the accuracy of resource management.

[0098] In one embodiment of this application, adjusting GPU resources allocated to a simulation task according to a resource adjustment instruction includes: Based on resource adjustment instructions, at least one of the following operations are performed by the resource scheduler: Computing power expansion: Based on the computing power expansion instruction, allocate an additional number of GPU computing power slices for the simulation task from the same GPU or other idle resource pools within the cluster that meet the type requirements; if resources are insufficient, add the expansion request to the waiting queue and notify the user. Computing power reduction: According to the computing power reduction instruction, release part of the GPU computing power slice currently occupied by the simulation task and return it to the idle resource pool; Task migration: According to the task migration instruction, all GPU computing power slices currently bound to the simulation task are migrated to the target GPU as a whole, and the mapping relationship between the task process and the GPU computing power slice is rebuilt after the migration is completed; if no suitable target GPU is found, the task is kept running on the current GPU and its health monitoring level is improved.

[0099] In this embodiment, resource adjustment is executed. Based on the resource adjustment instruction, the platform resource management module calls the resource scheduler through an interface, and the resource scheduler performs at least one of the following operations to complete the precise adjustment of GPU resources: For computing power expansion, according to the computing power expansion instruction, additional GPU computing power slices are allocated to the simulation task from the same GPU or other idle resource pools within the cluster that meet the type requirements. During the allocation process, GPU computing power slices are preferentially retrieved from the idle resource pool of the same GPU to ensure the continuity of task execution. If the resources of the same GPU are insufficient, GPU computing power slices are matched from other idle resource pools within the cluster that meet the GPU type requirements of the task. If there are not enough idle GPU computing power slices that meet the requirements in the entire cluster, the expansion request is added to the waiting queue, and the user is notified through a platform message that the expansion request is in a waiting state and the estimated waiting time. Computing power reduction: According to the computing power reduction instruction, a portion of the GPU computing power slice currently occupied by the simulation task is released and returned to the idle resource pool. During the release process, the number of releases specified in the computing power reduction instruction is precisely matched, and the GPU computing power slice with the lowest utilization rate is released first to ensure that the normal execution of the simulation task is not affected. The released GPU computing power slice is returned to the platform's idle resource pool in real time, and the resource pool status is updated for other tasks to call. Task migration involves migrating all GPU computing power slices currently bound to the simulation task to the target GPU according to the task migration instructions. After the migration is completed, the mapping relationship between the task process and the GPU computing power slices is rebuilt. Before the migration, the resource scheduler first verifies whether the hardware status and resource capacity of the target GPU meet the task requirements. During the migration, the current execution status and intermediate data of the task are saved synchronously to avoid data loss. If no suitable target GPU is found (e.g., no healthy and available GPU node with suitable resources), the task continues to execute on the current GPU, and its health monitoring level is immediately upgraded, the monitoring and collection cycle is shortened, the GPU hardware status is tracked in real time, and potential faults are detected and handled in a timely manner. As can be seen from the above, by adopting the aforementioned technical solution, the resource scheduler executes corresponding operations according to different resource adjustment instructions, achieving standardized and efficient resource adjustment. When expanding computing power, GPU computing power slices are allocated first from the idle resource pool. When resources are insufficient, they are added to a waiting queue and the user is notified, balancing expansion needs with the current resource status and avoiding resource contention. When reducing computing power, excess GPU computing power slices are released and returned to the resource pool, achieving resource recycling and reuse, and improving the overall resource utilization of the cluster. During task migration, GPU computing power slices are migrated as a whole and the mapping relationship is rebuilt to ensure task continuity. If the target GPU is not found, the monitoring level is increased to ensure task security. The coordinated operation of these operations ensures that resource adjustment instructions are implemented efficiently, achieving flexible allocation and efficient utilization of resources, and guaranteeing stable task execution.

[0100] In one embodiment of this application, after resource allocation based on the initial resource template, the method further includes: Monitor the overall contention level of GPU resources within the cluster from the current GPU hardware status data; If the overall contention level continues to exceed the first contention threshold, the conservatism coefficient of the resource prediction model when generating the initial resource template for subsequent tasks will be increased so that the generated computing power demand prediction value tends to have a higher safety margin. If the overall contention level remains below the second contention threshold, the conservatism coefficient is lowered to improve the overall resource utilization of the cluster; where the first contention threshold is greater than the second contention threshold.

[0101] In this embodiment, a conservative coefficient α (0 < α ≤ 1) is introduced during the inference process of the resource prediction model to adjust the predicted value of computing power demand. Specifically, the predicted value of computing power demand = the original output value of the model × (1 + α). The initial value of the conservative coefficient is 0.1. In subsequent steps, this coefficient is dynamically adjusted according to the cluster contention level to balance the safety margin of resource allocation and resource utilization.

[0102] This embodiment monitors the overall contention level of GPU resources in the cluster. After the initial resource allocation is completed, it continuously monitors the overall contention level of GPU resources in the cluster based on the current GPU hardware status data. The overall contention level is calculated by comprehensively quantifying the average resource utilization rate of all GPU nodes in the cluster, the proportion of idle resources, and the length of the resource request waiting queue. The larger the quantification value, the more intense the competition for GPU resources in the cluster, and vice versa. In the specific calculation, the above three indicators are normalized and then weighted and summed to obtain a quantification value of the overall contention level between 0 and 1, ensuring the objectivity and comparability of the monitoring results.

[0103] The conservatism coefficient is adjusted based on the level of contention. A first contention threshold and a second contention threshold are preset, with the first contention threshold being greater than the second contention threshold. Both thresholds are preset based on the platform cluster resource carrying capacity and historical contention scenario statistics, and can be continuously fine-tuned based on long-term operating data. The specific adjustment rules are as follows: If the overall contention level continues to exceed the first contention threshold, it indicates that the cluster's GPU resources are in a high contention state. At this time, the conservative coefficient of the resource prediction model when generating the initial resource template for subsequent tasks should be increased. After the conservative coefficient is increased, the predicted computing power demand value generated by the model will tend to have a higher safety margin, reserve more redundant resources, avoid subsequent tasks from being blocked or interrupted due to insufficient resource allocation, ensure that subsequent simulation tasks can be executed stably, and adapt to the resource allocation requirements of high contention scenarios.

[0104] If the overall contention level remains below the second contention threshold, it indicates that the cluster's GPU resources are in a low contention state with significant resource redundancy. In this case, the conservatism coefficient should be lowered. After the conservatism coefficient is lowered, the model's generated computing power demand prediction will reduce unnecessary safety margins, avoid resource waste, thereby improving the overall resource utilization of the cluster and fully leveraging the value of idle resources.

[0105] The adjustment range of the conservative coefficient is positively correlated with the deviation of the overall contention level and the corresponding threshold. The greater the deviation, the greater the adjustment range. At the same time, the range of the conservative coefficient is limited (0.1-0.5) to avoid excessive adjustment leading to resource allocation imbalance. This ensures that the adjusted conservative coefficient can accurately adapt to the current cluster resource contention scenario and achieve dynamic optimization of the subsequent initial resource template generation.

[0106] As can be seen from the above, this application, by adopting the aforementioned technical solution, monitors the overall contention level of GPU resources, accurately grasps the supply and demand situation of cluster resources, and provides a basis for optimizing the initial resource template. When the contention level is consistently higher than the first contention threshold, the conservatism coefficient is increased to give the predicted computing power demand a higher safety margin, avoiding task delays or failures due to insufficient resources and ensuring task stability. When the contention level is consistently lower than the second contention threshold, the conservatism coefficient is decreased to improve resource utilization and avoid resource waste. The reasonable setting of the first and second contention thresholds ensures accurate adjustment triggering timing, and the dynamic adjustment of the conservatism coefficient achieves a balance between task stability and resource utilization, enabling the initial resource template to adapt to changes in cluster resource status and optimizing the overall resource allocation effect.

[0107] Corresponding to the GPU resource management method of the AI-driven design simulation platform in the above embodiment, Figure 2 This is a structural block diagram of a GPU resource management system based on an AI-driven design simulation platform provided in one embodiment of this application. For ease of explanation, only the parts relevant to the embodiment of this application are shown. References Figure 2 The GPU resource management system 20 of the AI-driven design simulation platform includes: a data processing module 21, a resource allocation module 22, an instruction generation module 23, and an instruction execution module 24.

[0108] The data processing module 21 is used to process the first feature data in response to the submission event of the simulation task and generate the initial resource template of the simulation task. The first feature data includes task submission parameters, historical performance profile and task structure features. The initial resource template includes the initial prediction results of GPU type, computing power requirements and video memory capacity. The resource allocation module 22 is used to match and generate the resource allocation strategy corresponding to the simulation task from the preset resource allocation strategy library based on the initial resource template and GPU hardware status data. The instruction generation module 23 is used to respond to the start of the simulation task by inputting the collected second running data and the expected target of the resource allocation strategy into the resource adjustment model to obtain the resource adjustment instruction; Instruction execution module 24 is used to adjust the GPU resources allocated to the simulation task according to the resource adjustment instruction.

[0109] See Figure 3 , Figure 3 This is a schematic block diagram of an electronic device provided according to an embodiment of this application. Figure 3The electronic device 300 in this embodiment may include one or more processors 301, one or more input devices 302, one or more output devices 303, and one or more memories 304. The processors 301, input devices 302, output devices 303, and memories 304 communicate with each other via a communication bus 305. The memories 304 store computer programs, including program instructions. The processors 301 execute the program instructions stored in the memories 304. Specifically, the processors 301 are configured to invoke the program instructions to perform the functions of the modules in the aforementioned device embodiments, for example... Figure 2 The functions of the data processing module 21, resource allocation module 22, instruction generation module 23, and instruction execution module 24 are shown.

[0110] It should be understood that, in the embodiments of this application, the processor 301 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0111] Input device 302 may include a touchpad, a fingerprint sensor (for collecting the user's fingerprint information and fingerprint orientation information), a microphone, etc., and output device 303 may include a display (LCD, etc.), a speaker, etc.

[0112] The memory 304 may include read-only memory and random access memory, and provides instructions and data to the processor 301. A portion of the memory 304 may also include non-volatile random access memory. For example, the memory 304 may also store device type information.

[0113] In specific implementations, the processor 301, input device 302, and output device 303 described in the embodiments of this application can execute the implementation methods described in any embodiment of the GPU resource management method based on the AI-driven design simulation platform provided in the embodiments of this application, or they can execute the implementation methods of the electronic devices described in the embodiments of this application, which will not be repeated here.

[0114] In another embodiment of this application, a computer-readable storage medium is provided. This computer-readable storage medium stores a computer program, which includes program instructions. When executed by a processor, the program instructions implement all or part of the processes in the methods described above. Alternatively, the computer program can instruct related hardware to complete the process. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include any entity or device capable of carrying computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0115] The computer-readable storage medium can be an internal storage unit of the electronic device in any of the foregoing embodiments, such as a hard disk or memory of the electronic device. The computer-readable storage medium can also be an external storage device of the electronic device, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc., equipped on the electronic device. Furthermore, the computer-readable storage medium can include both internal and external storage units of the electronic device. The computer-readable storage medium is used to store computer programs and other programs and data required by the electronic device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0116] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0117] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the electronic devices and units described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0118] In the several embodiments provided in this application, it should be understood that the disclosed electronic devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces or units, or it may be an electrical, mechanical, or other form of connection.

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

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

[0121] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A GPU resource management method based on an AI-driven design simulation platform, characterized in that, include: In response to the submission event of the simulation task, the first feature data is processed to generate the initial resource template of the simulation task; The first feature data includes task submission parameters, historical performance profiles, and task structure features; The initial resource template includes initial predictions of GPU type, computing power requirements, and video memory capacity. Based on the initial resource template and GPU hardware status data, a resource allocation strategy corresponding to the simulation task is generated by matching from a preset resource allocation strategy library; In response to the start of the simulation task, the collected second running data and the expected target of the resource allocation strategy are input into the resource adjustment model to obtain resource adjustment instructions; According to the resource adjustment instruction, the GPU resources allocated to the simulation task are adjusted.

2. The GPU resource management method based on an AI-driven design simulation platform according to claim 1, characterized in that, The process of processing the first feature data to obtain the initial resource template includes: The first feature data is standardized and encoded to generate a task feature vector; Based on the estimated computational complexity of the simulation task and the load fluctuation rate of the simulation platform, the configuration of the preset resource prediction model is adjusted to obtain the target prediction model. The task feature vector is input into the target prediction model to obtain the initial resource template.

3. The GPU resource management method based on an AI-driven design simulation platform according to claim 2, characterized in that, The step of adjusting the configuration of the preset resource prediction model based on the estimated computational complexity of the simulation task and the load volatility of the simulation platform to obtain the target prediction model includes: Adjust the number of Transformer encoder layers in the resource prediction model based on the estimated computational complexity of the simulation task. Adjust the number of attention heads in the resource prediction model based on the coefficient of variation of the task feature data; Adjust the learning rate of the resource prediction model based on the load fluctuation rate of the design simulation platform; Based on the adjusted number of encoder layers, number of attention heads, and learning rate, the corresponding model parameters are loaded from the pre-trained parameter matrix to obtain the target prediction model.

4. The method according to claim 3, characterized in that, The step of adjusting the learning rate of the resource prediction model based on the load volatility of the design simulation platform includes: Obtain time-series data of GPU utilization of the design simulation platform within a preset time window; The ratio of the standard deviation to the mean of the time series data is calculated as the load volatility. Based on the load volatility, the learning rate of the resource prediction model is calculated and set using a preset nonlinear function.

5. The GPU resource management method based on an AI-driven design simulation platform according to claim 1, characterized in that, The step of generating a resource allocation strategy for the simulation task based on the initial resource template and GPU hardware status data by matching from a pre-set resource allocation strategy library includes: The initial resource template is processed to generate a task requirement feature vector; The GPU hardware status data is processed to generate a hardware status feature vector; The task requirement feature vector and hardware state feature vector are input into a preset weight prediction model to obtain the adaptive weights of the task requirement feature vector and hardware state feature vector. Based on the adaptive weights, the task requirement feature vector and the hardware status feature vector are weighted and fused to obtain a comprehensive requirement score. Based on the comprehensive demand score and the preset score-level mapping relationship, the resource demand level of the simulation task is determined. Based on the resource requirement level, the resource allocation strategy for the simulation task is matched from a pre-set resource allocation strategy library.

6. The GPU resource management method based on an AI-driven design simulation platform according to claim 5, characterized in that, Also includes: If the average deviation rate between the actual execution time and the predicted execution time of the most recent N historical simulation tasks is greater than the first deviation threshold, then the weight of the task requirement feature vector is increased based on the first ratio. The first deviation threshold is determined based on the statistical distribution results of historical task execution deviations from the design simulation platform; If the frequency of abnormal GPU health events detected within a unit of time exceeds the first frequency threshold, the weight of the GPU health status item in the hardware status feature vector is increased based on the second ratio.

7. The GPU resource management method based on an AI-driven design simulation platform according to claim 1, characterized in that, The step of inputting the collected second operational data and the expected target of the resource allocation strategy into the resource adjustment model to obtain resource adjustment instructions includes: The expected goals of the resource allocation strategy are used as a benchmark to input the resource adjustment model; the expected goals include the desired range of GPU resource utilization and the expected task progress speed. The second running data is preprocessed to obtain status data, which is then input into the resource adjustment model. In the resource adjustment model, the deviations between the actual resource utilization rate and the expected target, and the deviations between the actual task progress and the expected target in the status data are calculated, and their weighted sum is calculated as the comprehensive deviation. Based on the comprehensive deviation and the preset threshold conditions, a corresponding resource adjustment instruction is generated.

8. A GPU resource management system based on an AI-driven design simulation platform, characterized in that, include: The data processing module is used to process the first feature data in response to the submission event of the simulation task and generate the initial resource template of the simulation task; the first feature data includes task submission parameters, historical performance profile and task structure features. The initial resource template includes initial predictions of GPU type, computing power requirements, and video memory capacity. The resource allocation module is used to generate a resource allocation strategy corresponding to the simulation task by matching the initial resource template and GPU hardware status data from a preset resource allocation strategy library. The instruction generation module is used to respond to the start of the simulation task by inputting the collected second running data and the expected target of the resource allocation strategy into the resource adjustment model to obtain the resource adjustment instruction; The instruction execution module is used to adjust the GPU resources allocated to the simulation task according to the resource adjustment instructions.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images