BIOS and BMC-based GPU resource intelligent dynamic optimization method and system

Abstract

The application relates to the field of computer technology and belongs to a GPU resource intelligent dynamic optimization method and system based on BIOS and BMC. The application adopts a four-layer cooperative architecture of a firmware layer (BIOS), a management controller layer (BMC), a system layer (an operating system kernel) and a hardware layer (a GPU device). The architecture is a cross-layer closed-loop optimization architecture. The optimization decision function is decoupled from the operating system kernel and is deployed in an independent hardware management unit, namely a baseboard management controller (BMC). The system collects GPU running data in the operating system kernel space in real time, and sends the data to the BMC. An intelligent optimization engine arranged in the BMC analyzes and calculates the data to generate an optimal GPU resource scheduling strategy. The strategy is returned to the operating system kernel, and is finally executed by the hardware layer. Through the above cross-layer interaction, the intelligent dynamic optimization of the GPU resource is realized. Thus, a continuous intelligent closed-loop optimization link of "deployment-data acquisition-intelligent decision-making-strategy execution" is formed.

Description

Technical Field

[0001] This invention relates to the field of computer technology, specifically to a method and system for intelligent dynamic optimization of GPU resources based on BIOS and BMC. Background Technology

[0002] Currently, GPU resource management heavily relies on a centralized model centered on the host operating system. Its strategies are static and rigid, and optimization tasks compete with business applications for valuable CPU and memory resources. Meanwhile, the Baseboard Management Controller (BMC), the core of server management, has long been limited to hardware status monitoring and remote control. While there have been some initial attempts at intelligence, its embedded environment's computing power and memory constraints prevent it from supporting complex AI models to participate in the real-time scheduling of core computing resources like GPUs. Although academia and industry have begun exploring machine learning for resource optimization on the host side, these solutions also cannot escape dependence on the host operating system and fail under high host loads. Furthermore, from a system initialization perspective, BIOS / UEFI and traditional deployment tools can only complete the basic installation of the operating system; subsequent deployment and configuration of optimization components still rely on manual or external tools, resulting in a fragmented process. In summary, existing technologies create siloed barriers between layers, lacking a cross-layer closed-loop optimization system that can connect firmware, management controllers, operating systems, and hardware to achieve resource awareness, intelligent decision-making, and automated deployment.

[0003] The existing technology system suffers from inherent structural flaws: at the GPU resource management level, strategies are static and rigid, competing for resources with business operations, lacking system-level multi-objective optimization capabilities, and heavily reliant on unreliable host operating systems. While resource scheduling schemes aiming to introduce intelligence are deployed "on the host side," they not only fail to eliminate resource conflicts but their reliability is also constrained by the host's state. Meanwhile, the Baseboard Management Controller (BMC), with its independent operating environment, suffers from severely underutilized computing potential and limited functionality, failing to provide a solution to the aforementioned problems. Furthermore, from a system-level perspective, the fragmentation of the initialization deployment process and the lack of environmental awareness in BIOS / UEFI prevent the construction of an integrated, adaptive optimization system from the ground up. Ultimately, these cross-layered technical bottlenecks collectively lead to a core gap: the lack of a collaborative management architecture capable of eliminating host dependence and achieving fully automated deployment and real-time closed-loop optimization.

[0004] Based on the above development status, the core bottlenecks exposed by the existing technology system can be summarized into the following interrelated points:

[0005] a. The fundamental contradiction of host-side optimization: All optimization solutions deployed at the host operating system level, no matter how intelligent, cannot resolve the fundamental contradiction between them and business applications competing for CPU and memory resources. This not only exacerbates system turbulence under high load, but also, because it heavily relies on the stability of the host operating system, the optimization functions fail during system crashes, kernel panics, or high loads, making reliability impossible to guarantee.

[0006] b. Idle BMC Potential and Architectural Waste: The BMC, with its independent operating environment and intended as a powerful out-of-band management tool, has its computing potential severely underutilized. Its current functionality is limited to basic status monitoring, failing to participate in computing resource scheduling that requires real-time intelligent decision-making, resulting in resource waste and capability shortcomings in the management architecture.

[0007] c. Lack of automation during system initialization: From the root of system startup, BIOS / UEFI lacks the ability to perceive and adaptively deploy the final operating environment. This prevents optimization components from being deployed and seamlessly integrated with the operating system, requiring subsequent manual intervention or external tools, thus rendering "out-of-the-box" automated optimization impossible.

[0008] The technical solution of patent CN120104357A (a method for dynamic scheduling of GPU resources in a cloud environment):

[0009] This patent relates to a dynamic scheduling method for GPU resources in a cloud environment, aiming to optimize GPU resource allocation through real-time monitoring and prediction. This scheme aims to reduce operational latency and costs, and improve resource utilization by jointly optimizing resource pool adjustments and task matching. Although this patent is innovative in cloud scheduling, it still has the following limitations:

[0010] a. Reliance on cloud service provider interfaces: Resource pool adjustments heavily depend on the instance specification metadata database and API of cloud service providers, which may lead to poor cross-platform compatibility and insufficient flexibility due to limitations imposed by the parameters provided by cloud providers.

[0011] b. Limitations of the prediction model: Autoregressive prediction models are based on historical data and are poorly adaptable to sudden or nonlinear changes in task requirements. Prediction errors may cause fluctuations in resource allocation.

[0012] c. Single resource dimension: It mainly focuses on video memory resources and ignores key indicators such as GPU computing power, power consumption, and temperature, which may lead to unbalanced overall resource optimization and affect task performance.

[0013] d. High implementation complexity: Multi-step computation increases system overhead and may introduce latency in large-scale clusters, making it difficult to guarantee real-time performance.

[0014] e. Lack of hardware layer integration: Scheduling is only performed at the cloud environment level and does not penetrate into the hardware layer, which makes it impossible to achieve fine control over power consumption, heat dissipation and hardware status, thus limiting energy efficiency and stability optimization. Summary of the Invention

[0015] To address the aforementioned technical problems, this invention provides a method and system for intelligent dynamic optimization of GPU resources based on BIOS and BMC.

[0016] To achieve the above objectives, the present invention provides the following technical solution:

[0017] This invention provides a method for intelligent dynamic optimization of GPU resources based on BIOS and BMC, comprising the following specific steps:

[0018] S1, BIOS, and BMC complete the loading and initialization of core components in parallel;

[0019] S2, BIOS automatically deploys the operating system, GPU optimization component package and GPU driver, wherein the GPU optimization component package includes optimization components adapted to different operating systems;

[0020] S3: The operating system kernel loads the optimized components and GPU drivers deployed in S2 and completes initialization;

[0021] S4. GPU running data is periodically collected through a timer. The GPU running data is encapsulated into a data structure and then transmitted to the BMC to provide a real-time data source for intelligent decision-making. The GPU running data is timestamped by the timer.

[0022] S5 and BMC analyze and calculate GPU running data through the intelligent optimization engine, generate optimized GPU resource scheduling strategy parameters, and send them to the operating system kernel layer.

[0023] S6. The operating system kernel layer calculates the actual control value based on the optimization strategy parameters obtained in S4, and then calls the GPU driver function to realize the control of the GPU and complete the intelligent regulation of GPU resources.

[0024] Preferably, step S1, specifically the loading and initialization steps of the BIOS and BMC core components, include:

[0025] S11, BIOS read-load file system parsing tool, GPU optimization component package and GPU driver;

[0026] S12, BMC loads a lightweight runtime environment, intelligent optimization engine, and daemon process starts.

[0027] Preferably, the intelligent optimization engine is a DQN-Lite model that is compressed through knowledge distillation and INT8 quantization;

[0028] The intelligent optimization engine encapsulates machine learning models, heuristic algorithms, or rule bases.

[0029] Preferably, in step S2, the specific steps for the BIOS to automatically deploy the operating system, GPU optimization component package, and GPU driver include:

[0030] S21. The BIOS parses the partition table of the target installation media and the file system of the newly installed operating system to obtain file system characteristics and identify the operating system type.

[0031] S22. Based on the operating system type, optimize the components to the specified kernel version and generate module dependency files based on the kernel version to ensure that they can be automatically loaded when the kernel starts.

[0032] S23. Modify the auto-boot configuration for different types of operating systems.

[0033] Preferably, step S5, the specific steps for generating the optimization strategy parameters, include:

[0034] S51, The GPU operating data is read by accessing the GPU register through the GPU driver. The GPU operating data includes core utilization, video memory usage, core temperature, and real-time power consumption.

[0035] S52. Normalize and perform temporal feature engineering on the GPU running data read in S51 to form a multi-dimensional composite feature vector and input it into the DQN-Lite model.

[0036] S53. The DQN-Lite model outputs a Q-value matrix;

[0037] The Q-value matrix includes a core frequency coefficient action set, a memory frequency coefficient action set, a power consumption adjustment action set, and a scheduling weight action set;

[0038] S54. Perform the following decision-making process in parallel and independently on the four action sets described in S53:

[0039] An ε-greedy strategy is adopted to select the action with the highest Q value with a probability of threshold one, and to uniformly and randomly select an action from the action set with a probability of threshold two, so as to determine the final GPU optimization strategy parameters.

[0040] The threshold one is greater than the threshold two, and the sum of the threshold one and the threshold two is 1;

[0041] S55. The final GPU optimization strategy parameters are encapsulated and returned to the operating system kernel layer.

[0042] Preferably, in step S6, the specific steps for optimizing the GPU hardware by optimizing the strategy parameters include:

[0043] S61. The policy processing unit at the operating system kernel layer receives and extracts the control parameters, and calculates the target physical value:

[0044] S62. Based on the target physical value calculated in S61, the target physical value is passed to the currently used GPU through the GPU driver function, and the CPU scheduling priority of the GPU process group is adjusted, thereby indirectly affecting its weight in acquiring GPU resources.

[0045] The present invention also provides a BIOS and BMC-based intelligent dynamic optimization system for GPU resources to implement the above method, comprising a four-layer collaborative architecture consisting of a BIOS firmware layer, a BMC management controller layer, an operating system kernel layer and a GPU hardware layer;

[0046] The BIOS firmware layer is used to identify the operating system type and to complete the deployment and auto-boot configuration of the operating system kernel layer;

[0047] The operating system kernel layer collects GPU running data in real time and sends it to the BMC management controller layer;

[0048] The BMC management controller layer is independent of the host CPU settings. It has an intelligent optimization engine deployed inside. The intelligent optimization engine analyzes and calculates the GPU running data, generates an optimized GPU resource scheduling strategy, and sends it to the operating system kernel layer.

[0049] The operating system kernel layer receives and sends optimized GPU resource scheduling policies to the GPU hardware layer, which then executes the GPU resource scheduling policies to optimize performance.

[0050] Preferably, the operating system kernel layer includes an information processing unit, a policy processing unit, and a communication module;

[0051] The information processing unit collects the GPU hardware layer's operating performance parameters in real time and sends the data to the BMC management controller layer, providing a real-time data source for generating resource scheduling strategies.

[0052] The strategy processing unit receives the optimization strategy returned by the BMC management controller layer, transforms the abstract strategy into specific instructions executable by the GPU hardware layer, and sends them to the GPU hardware layer for execution to adjust the GPU's operating state.

[0053] The communication module executes the sending of collected data and the return of optimization strategies, realizing data exchange between the operating system kernel layer and the BMC module.

[0054] Preferably, the BMC management controller layer integrates a lightweight Python runtime environment for executing intelligent optimization algorithms;

[0055] A daemon process resides on the BMC management controller layer, and the daemon process is responsible for detecting and managing the communication link between the management system and the operating system kernel.

[0056] The intelligent optimization engine is set in the BMC module and is loaded and run through the Python runtime environment.

[0057] Compared with existing technologies, this invention provides a method and system for intelligent dynamic optimization of GPU resources based on BIOS and BMC, which has the following beneficial effects:

[0058] 1. Decouple the decision-making function from the host OS to an independent BMC, completely eliminating competition for resources with business operations. Even if the host crashes, the optimization function will still run stably with zero resource consumption and high reliability.

[0059] 2. The BIOS intelligently identifies and automatically deploys optimized components during the boot phase, achieving "out-of-the-box usability," greatly improving efficiency and reducing maintenance costs, and realizing fully automated end-to-end deployment.

[0060] 3. Based on the lightweight AI model within the BMC, millisecond-level dynamic decision-making is achieved, comprehensively optimizing performance, power consumption, and temperature, improving system-level energy efficiency, and realizing real-time dynamic multi-objective optimization.

[0061] 4. By upgrading the BMC from a monitor to an intelligent decision-making center and utilizing its idle computing power to run lightweight AI models, the potential of the BMC has been unlocked, creating a new paradigm for intelligent management.

[0062] 5. This cross-layer collaborative architecture is highly versatile, can be extended to the management of other heterogeneous computing units, is compatible with mainstream operating systems, and has great potential for promotion.

[0063] The features and advantages of the present invention will be described in detail through embodiments and in conjunction with the accompanying drawings. Attached Figure Description

[0064] Figure 1 This is a flowchart illustrating the steps of a GPU resource intelligent dynamic optimization method based on BIOS and BMC according to the present invention.

[0065] Figure 2 This is a layered architecture diagram of a GPU resource intelligent dynamic optimization system based on BIOS and BMC according to the present invention;

[0066] Figure 3 This is a system architecture diagram of the present invention;

[0067] Figure 4 This is a system flowchart of the present invention;

[0068] Figure 5 The system lane diagram of this invention. Detailed Implementation

[0069] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. However, it should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of the invention. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.

[0070] See Figure 1-5 This invention provides a method for intelligent dynamic optimization of GPU resources based on BIOS and BMC, comprising the following specific steps:

[0071] S1, BIOS, and BMC complete the loading and initialization of core components in parallel;

[0072] S2, BIOS automatically deploys the operating system, GPU optimization component package and GPU driver, wherein the GPU optimization component package includes optimization components adapted to different operating systems;

[0073] S3: The operating system kernel loads the optimized components and GPU drivers deployed in S2 and completes initialization;

[0074] S4. GPU running data is periodically collected through a timer. The GPU running data is encapsulated into a data structure and then transmitted to the BMC to provide a real-time data source for intelligent decision-making. The GPU running data is timestamped by the timer.

[0075] S5 and BMC analyze and calculate GPU running data through the intelligent optimization engine, generate optimized GPU resource scheduling strategy parameters, and send them to the operating system kernel layer.

[0076] S6. The operating system kernel layer calculates the actual control value based on the optimization strategy parameters obtained in S4, and then calls the GPU driver function to realize the control of the GPU and complete the intelligent regulation of GPU resources.

[0077] Preferably, step S1, specifically the loading and initialization steps of the BIOS and BMC core components, include:

[0078] S11, BIOS read-load file system parsing tool, GPU optimization component package and GPU driver;

[0079] S12, BMC loads a lightweight runtime environment, intelligent optimization engine, and daemon process starts.

[0080] Preferably, the intelligent optimization engine is a DQN-Lite model that is compressed through knowledge distillation and INT8 quantization;

[0081] The intelligent optimization engine encapsulates machine learning models, heuristic algorithms, or rule bases.

[0082] Preferably, in step S2, the specific steps for the BIOS to automatically deploy the operating system, GPU optimization component package, and GPU driver include:

[0083] S21. The BIOS parses the partition table of the target installation media and the file system of the newly installed operating system to obtain file system characteristics and identify the operating system type.

[0084] S22. Based on the operating system type, optimize the components to the specified kernel version and generate module dependency files based on the kernel version to ensure that they can be automatically loaded when the kernel starts.

[0085] S23. Modify the auto-boot configuration for different types of operating systems.

[0086] Preferably, step S5, the specific steps for generating the optimization strategy parameters, include:

[0087] S51, The GPU operating data is read by accessing the GPU register through the GPU driver. The GPU operating data includes core utilization, video memory usage, core temperature, and real-time power consumption.

[0088] S52. Normalize and perform temporal feature engineering on the GPU running data read in S51 to form a multi-dimensional composite feature vector and input it into the DQN-Lite model.

[0089] S53. The DQN-Lite model outputs a Q-value matrix;

[0090] The Q-value matrix includes a core frequency coefficient action set, a memory frequency coefficient action set, a power consumption adjustment action set, and a scheduling weight action set;

[0091] S54. Perform the following decision-making process in parallel and independently on the four action sets described in S53:

[0092] An ε-greedy strategy is adopted to select the action with the highest Q value with a probability of threshold one, and to uniformly and randomly select an action from the action set with a probability of threshold two, so as to determine the final GPU optimization strategy parameters.

[0093] The threshold one is greater than the threshold two, and the sum of the threshold one and the threshold two is 1;

[0094] S55. The final GPU optimization strategy parameters are encapsulated and returned to the operating system kernel layer.

[0095] Preferably, in step S6, the specific steps for optimizing the GPU hardware by optimizing the strategy parameters include:

[0096] S61, The policy processing unit of the operating system kernel layer receives and extracts the control parameters and calculates the target physical value;

[0097] The formula for calculating the target physical value is as follows:

[0098] target_core_freq=(u32)(gpu_base_core_freq k_f);

[0099] target_mem_freq=(u32)(gpu_base_mem_freq k_m);

[0100] new_power_limit=gpu_base_power_limit+ΔP;

[0101] in:

[0102] k_f,k_m,ΔP,w_s are the control parameters sent from the BMC;

[0103] gpu_base_core_freq: The base frequency or nominal frequency of the GPU core, which is a fixed value defined by the hardware specification;

[0104] target_core_freq: The calculated target core frequency;

[0105] gpu_base_mem_freq: The base frequency of the GPU memory;

[0106] target_mem_freq: The calculated target memory frequency;

[0107] gpu_base_power_limit: The default power consumption of the GPU;

[0108] new_power_limit: The calculated new power consumption, dynamically adjusting the maximum power that the GPU is allowed to consume.

[0109] S62. Based on the target physical value calculated in S61, the target physical value is passed to the currently used GPU through the GPU driver function, and the CPU scheduling priority of the GPU process group is adjusted, thereby indirectly affecting its weight in acquiring GPU resources.

[0110] The present invention also provides a BIOS and BMC-based intelligent dynamic optimization system for GPU resources to implement the above method, comprising a four-layer collaborative architecture consisting of a BIOS firmware layer, a BMC management controller layer, an operating system kernel layer and a GPU hardware layer;

[0111] The BIOS firmware layer is used to identify the operating system type and to complete the deployment and auto-boot configuration of the operating system kernel layer;

[0112] The operating system kernel layer collects GPU running data in real time and sends it to the BMC management controller layer;

[0113] The BMC management controller layer is independent of the host CPU settings. It has an intelligent optimization engine deployed inside. The intelligent optimization engine analyzes and calculates the GPU running data, generates an optimized GPU resource scheduling strategy, and sends it to the operating system kernel layer.

[0114] The operating system kernel layer receives and sends optimized GPU resource scheduling policies to the GPU hardware layer, which then executes the GPU resource scheduling policies to optimize performance.

[0115] Preferably, the operating system kernel layer includes an information processing unit, a policy processing unit, and a communication module;

[0116] The information processing unit collects the GPU hardware layer's operating performance parameters in real time and sends the data to the BMC management controller layer, providing a real-time data source for generating resource scheduling strategies.

[0117] The strategy processing unit receives the optimization strategy returned by the BMC management controller layer, transforms the abstract strategy into specific instructions executable by the GPU hardware layer, and sends them to the GPU hardware layer for execution to adjust the GPU's operating state.

[0118] The communication module executes the sending of collected data and the return of optimization strategies, realizing data exchange between the operating system kernel layer and the BMC module.

[0119] Preferably, the BMC management controller layer integrates a lightweight Python runtime environment for executing intelligent optimization algorithms;

[0120] A daemon process resides on the BMC management controller layer, and the daemon process is responsible for detecting and managing the communication link between the management system and the operating system kernel.

[0121] The intelligent optimization engine is set in the BMC module and is loaded and run through the Python runtime environment.

[0122] In a specific embodiment, the specific implementation steps are as follows:

[0123] Step 0: Firmware and Model Loading

[0124] This step is the foundational stage of system startup, where the BIOS and BMC complete the loading and initialization of core components in parallel.

[0125] a. BIOSFlash Loading and Initialization

[0126] System power-on and hardware self-test: After the system is powered on, the BIOS starts from the BIOSFlash and executes the power-on self-test process to initialize key hardware such as the CPU, memory and PCIe bus.

[0127] The BIOS reads three types of core files from the UEFI application partition in its Flash memory:

[0128] The file system parsing tool, fs_parser.efi (a UEFI executable binary program), is compiled using the EDKII cross-compilation toolchain and integrates three types of file system parsing functions: ext4_parse() and xfs_parse(), which support parsing the superblock and inode of the EXT4 and XFS file systems of Linux systems; and ntfs_parse(), which is ported from the open-source library EfiFs and supports parsing the NTFS file system of Windows systems, capable of reading partition tables, superblocks, and directory structures such as / Windows / System32. This tool automatically identifies partition types through a GUID matching mechanism (such as the NTFS file system GUIDEBD0A0A2-B9E5-4433-87C0-68B6B72699C7), providing file system access capabilities for cross-OS deployments.

[0129] GPU optimization client component package: Includes cross-operating system optimization components, specifically: Linux environment: kernel module gpu_optimizer.ko (for kernel-mode data acquisition and policy execution), system service unit gpu_opt_agent.service (user-mode auxiliary component, responsible for logging and status reporting); Windows environment: kernel driver gpu_optimizer.sys (kernel-mode data acquisition and policy execution), user-mode service program GPUOptimizerSvc.exe (user-mode auxiliary component, responsible for service management).

[0130] The base GPU driver, gpu_base_driver.ko, is used to create data acquisition interfaces in the kernel.

[0131] BMCFlash loading and initialization

[0132] Environment and Engine Loading: The independent BMC controller starts. The BMC loads the following components from its BMCFlash:

[0133] Lightweight runtime environment loading: Loads a heavily trimmed Python 3.9 runtime and links to the cross-compiled TensorFlowLite 2.8 inference library.

[0134] Intelligent optimization engine: DQN-Lite model file (dqn_lite_model.tflite). This model has been compressed through knowledge distillation and INT8 quantization to ensure that the latency of a single inference is less than 100ms under the limited computing power of BMC.

[0135] Daemon startup: BMC starts a resident daemon process gpu_opt_daemon, which loads the Python environment and TFLite model and begins listening for communication requests from the operating system kernel.

[0136] Step 1: BIOS automatically deploys the operating system and optimizes pre-installed components.

[0137] This step is the core innovation for achieving "fully automated deployment of the operating system and optimization components." The BIOS intelligently identifies the OS type based on file system characteristics and pre-deploys the optimization components to the target system. The operating system then completes the final configuration during the first boot.

[0138] Operating System Installation and File System Parsing

[0139] The BIOS calls the fs_parser.efi tool to parse the partition table of the target installation media and the file system of the newly installed operating system.

[0140] The BIOS automatically identifies the operating system type based on file system characteristics (such as the existence of / etc / os-release indicating Linux, and the existence of / Windows / System32 indicating Windows).

[0141] Optimize component deployment

[0142] Linux system deployment: Mount the Linux root partition in the BIOS. Use the `ext4_parse()` / `xfs_parse()` functions of `fs_parser.ef` to traverse the ` / lib / modules` directory. The names of the subdirectories under this directory represent the installed kernel versions. By default, the Linux system only keeps the directory of the currently running kernel. If multiple subdirectories exist, the latest kernel version is selected by comparing version number strings. Copy `gpu_base_driver.ko` and `gpu_optimizer.ko` to ` / lib / modules / [obtained kernel version] / kernel / drivers / `. Then, use `depmod -a [kernel version]` to generate the module dependency file (`modules.dep`) to ensure that it can be automatically loaded when the kernel starts.

[0143] Windows system deployment: Mount the Windows system partition in the BIOS. If the directory C:\Program Files\GPUOptimizer\ does not exist, it will be created automatically. Copy gpu_optimizer.sys to C:\Windows\System32\drivers\ and copy GPUOptimizerSvc.exe to C:\Program Files\GPUOptimizer\.

[0144] c. Automatically modify startup configuration

[0145] Linux systems: The BIOS, through the UEFI's "LinuxLoaderProtocol," injects a "post-install script" (path: / etc / init.d / gpu_opt_init) before the operating system's first boot. This script executes automatically after the Linux kernel's first boot and after / proc and / sys are mounted. Its contents include: executing `depmod -a` to load `gpu_base_driver.ko` and `gpu_optimizer.ko`; executing `systemctlenable --now gpu_opt_agent.service` to ensure the optimization service starts with the system; and preventing the UEFI environment from directly manipulating the Linux virtual file system, ensuring the deployment process is compatible with UEFI specifications.

[0146] Windows system: Load the target system's registry hive using offline registry editing technology, create a service item under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\GPUOptimizer: Set the ImagePath key value to C:\ProgramFiles\GPUOptimizer\GPUOptimizerSvc.exe; set the Start key value to 0x2 (automatic startup) to ensure the service runs automatically when the system starts.

[0147] Step 2: Operating System Kernel Initialization and GPU Data Acquisition

[0148] This step completes the initialization of the kernel and GPU driver, and periodically collects GPU running data through a high-precision timer to provide a real-time data source for intelligent decision-making.

[0149] a. Kernel and GPU driver initialization

[0150] After the operating system starts, it will automatically add gpu_base_driver.ko and gpu_optimizer.ko deployed in step 1.

[0151] gpu_base_driver.ko maps the GPU's physical performance counter registers using ioremap() and registers interrupt handlers.

[0152] The information processing unit in gpu_optimizer.ko initializes a high-precision kernel timer and sets the acquisition period to 500ms.

[0153] b. Periodic data acquisition and packaging

[0154] After the timer is triggered, the information processing unit calls the read_gpu_metrics() function provided by gpu_base_driver.ko to read raw data such as GPU core utilization, memory usage, temperature, and power consumption.

[0155] The collected data is encapsulated in a structure named gpu_stats and a timestamp is added.

[0156] Step 3: Send GPU data to BMC

[0157] The information processing unit serializes the gpu_stats structure into a byte stream, encapsulates it using a fragmented custom protocol, and implements transmission based on the SMBus BlockWrite / Read function:

[0158] a. Protocol frame format (single fragment):

[0159] |Device Address (1B)|Frame Header (2B)|Command Type (1B)|Total Number of Fragments (1B)|Current Fragment Sequence Number (1B)|Data Length (1B)|Data Body (≤22B)|PEC Checksum (1B)|

[0160] Device address: Kernel-side SMBus slave device fixed address 0x20;

[0161] Frame header: 0x5A5A (fixed identifier);

[0162] Command types: 0x01 (data acquisition), 0x02 (policy return), 0x03 (retransmission request);

[0163] Data body: Maximum 22B (ensure total length 1+2+1+1+1+1+22+1=30B≤32B).

[0164] PEC verification: Based on the CRC-8 algorithm (covering "device address + all data fields"), ensuring transmission integrity;

[0165] b. Transmission process:

[0166] Sending end: Divide into 24-byte segments, mark the total number of segments and the current sequence number, and send all segments in sequence;

[0167] Receiver: Listens to SMBus slave device address 0x20, receives fragments and reassembles the data. If a fragment is missing, it sends command type 0x03 to request retransmission.

[0168] After the data is reassembled, the overall CRC-16 checksum is verified, and deserialization is performed after confirming that there are no errors.

[0169] Step 4: BMC Intelligent Decision Making and Strategy Generation

[0170] (1) Data computation optimization

[0171] a. Data Acquisition and Verification

[0172] Data Source: The data comes directly from the GPU, read through the `read_gpu_metrics()` function in the system OS layer kernel module `gpu_base_driver.ko`. This function directly accesses the following GPU registers through the physical addresses mapped by `ioremap`:

[0173] GRBM_STATUS(GraphicsRegisterBusManager): Used to read core utilization.

[0174] MC_SEQ_PERF_CNTR(MemoryController): Used to read the video memory usage rate.

[0175] CGTS_TSC_DID(TemperatureSensor): Used to read the core temperature.

[0176] SMU_POWER_CNTL(PowerManagementUnit): Used to read real-time power consumption.

[0177] Transmission verification: The BMC daemon gpu_opt_daemon listens to the SMBus slave device address 0x20. After receiving a data frame, it verifies the frame header (0x5A5A) and the CRC-16 checksum to ensure data integrity.

[0178] b. Data normalization and numerical stability

[0179] Use the deserialize_gpu_stats() function to restore the gpu_stats structure.

[0180] Min-Max Normalization: To avoid bias in the model caused by metrics with different dimensions, core utilization (U_core), memory utilization (M_mem), core temperature (T_core), and power consumption (P_power) are min-max normalized to scale them to the model-friendly [0, 1] range. The formula is: X_norm = (X - X_min) / (X_max - X_min). The normalized data is the standard format for constructing feature vectors. Without this step, features with large numerical ranges will dominate the model's learning, while features with small numerical ranges will be ignored. The normalization formulas for the four parameters are as follows:

[0181] U_core, norm = U_core / 100;

[0182] T_core,norm=M_mem / 100;

[0183] T_core,norm=T_core / 100.0

[0184] P_power,norm=P_power / 300;

[0185] Feature engineering: To improve the model's ability to perceive dynamic loads, the system constructed time-series features.

[0186] The system maintains a circular queue of size 5 in the BMC memory to store the U_core,norm and M_mem,norm for the most recent 5 cycles (a total of 2.5 seconds).

[0187] Calculate the moving average and standard deviation of these historical data as a new feature vector [U_avg, U_std, M_avg, M_std]. This helps the model distinguish between stable loads, fluctuating loads, or sudden loads.

[0188] c. Dynamic temporal feature engineering

[0189] This transforms static data into dynamic perception. The system maintains a fixed-length circular queue (RingBuffer) of 5 in the BMC memory for U_core,norm and M_mem,norm respectively.

[0190] Instantaneous rate of change calculation: U_delta = U_core,norm[t] - U_core,norm[t-1]. This value is used to determine whether the load is rising, falling, or in a steady state.

[0191] Short-term trend calculation: Calculate for 5 data points in the queue (representing the last 2.5 seconds).

[0192] Moving Average: U_avg = Σ(U_core, norm[i]) / 5, for i ∈ [t-4, t]. This value smooths out short-term fluctuations and reflects the recent average load level.

[0193] Standard Deviation: U_std = sqrt(Σ((U_core, norm[i] - U_avg)^2) / 5). This value quantifies the degree of load volatility; high volatility may indicate unexpected events.

[0194] d. Categorical variable coding

[0195] Task type One-hot encoding: Converts non-numerical task types (such as "graphics rendering", "scientific computing", "AI inference") into numerical vectors that can be processed by machine learning models. For example, the three task types are encoded as [1,0,0], [0,1,0], and [0,0,1], respectively.

[0196] Ultimately, a 13-dimensional composite feature vector is formed, describing the GPU's current state, recent trends, and tasks:

[0197] [U_core,norm,M_mem,norm,T_core,norm,P_power,norm,U_delta,U_avg,U_std,M_delta,M_avg,M_std,T_task[0],T_task[1],T_task[2]]

[0198] (2) Generation of the optimal scheduling strategy

[0199] a. DQN-Lite model inference

[0200] Input: The daemon inputs the preprocessed data [U_core,norm,M_mem,norm,T_core,norm,P_power,norm,U_delta,U_avg,U_std,M_delta,M_avg,M_std,T_task[0],T_task[1],T_task[2]] 13-dimensional vector into the model.

[0201] Model: The dqn_lite_model.tflite model is knowledge-distilled and INT8 quantized. This model is loaded and executed in BMC's lightweight Python environment using the TensorFlowLite interpreter.

[0202] Output: The model outputs a 4xN Q-value matrix. Each row corresponds to a discrete action value assessment for a control dimension.

[0203] Line 0: 5 Q values, corresponding to the core frequency coefficient action set A_f=[0.7,0.85,1.0,1.15,1.3].

[0204] Line 1: 5 Q values, corresponding to the memory frequency coefficient action set A_m=[0.7,0.85,1.0,1.15,1.3].

[0205] Line 2: 5 Q values, corresponding to the power consumption adjustment action set A_p=[-25,-10,0,+10,+25] (unit:W).

[0206] Line 3: 4 Q values, corresponding to the scheduling weight action set A_s=[0.5,1.0,2.0,4.0].

[0207] b. Optimal action selection (ε-greedy strategy)

[0208] The system executes the following decision-making process in parallel and independently for the four action sets (i.e., each row of the Q-value matrix):

[0209] Exploitation: Select the action with the highest Q value in the row with a 90% probability. For example, for the core frequency dimension: selected_f_index=argmax([Q_f0,Q_f1,Q_f2,Q_f3,Q_f4]), then k_f=A_f[selected_f_index].

[0210] Exploration: With a 10% probability, a single action is randomly selected uniformly from the action set. For example, if an index i is randomly selected from [0,1,2,3,4], then k_f = A_f[i]. This mechanism ensures that the system executes the currently known optimal strategy most of the time, while exploring other potentially better strategies with a small probability, thus achieving self-optimization in dynamic environments.

[0211] c. Encapsulation of optimal strategy parameters

[0212] The four finalized parameters (k_f, k_m, ΔP, w_s) are encapsulated into a gpu_policy structure and returned to the kernel via SMBus.

[0213] Step 5: Kernel Execution Optimization Strategies and GPU Hardware Tuning

[0214] This step is responsible for converting the policy parameters sent by the BMC into actual state changes of the GPU hardware through the operating system kernel and GPU driver.

[0215] a. Strategy parsing and instruction conversion

[0216] The kernel's policy processing unit receives and parses the `gpu_policy` from the BMC, extracting four control parameters: `k_f`, `k_m`, `ΔP`, and `w_s`.

[0217] Calculate the target physical values:

[0218] target_core_freq=(u32)(gpu_base_core_freq k_f); / /

[0219] target_mem_freq=(u32)(gpu_base_mem_freq k_m);

[0220] new_power_limit=gpu_base_power_limit+ΔP;

[0221] Calling the underlying driver interface:

[0222] Frequency and power consumption adjustment: Call the GPU driver function.

[0223] interr_core=gpu_set_core_freq(target_core_freq);

[0224] interr_mem=gpu_set_mem_freq(target_mem_freq);

[0225] interr_power=gpu_set_power_limit(new_power_limit);

[0226] Scheduling weight settings: By adjusting the CPU scheduling priority of process groups that are using the GPU through the Linux kernel's control group interface, the weight of their acquisition of GPU resources can be indirectly affected.

[0227] gpu_set_sched_weight(w_s); / /

[0228] b. Hardware register write and execution confirmation

[0229] The final execution of the aforementioned driver functions involves precise read and write operations on the GPUPCIe configuration space or memory-mapped I / O (MMIO) registers, thereby completing real-time adjustments to the GPU hardware state.

[0230] Step 6: Intelligent optimization closed loop formation

[0231] The steps Step 2 (Data Acquisition) → Step 3 (Data Transmission) → Step 4 (Intelligent Decision Making) → Step 5 (Strategy Execution) are executed continuously in a 500ms cycle.

[0232] a. Effect feedback and model optimization: After each policy execution, when collecting the next round of gpu_stats, the "information processing unit" synchronously reads the GPU throughput counter (reads the GPU's built-in task completion register through gpu_base_driver.ko) and calculates the throughput change ratio Throughputnew / Throughputold.

[0233] b. Reward Function-Driven Learning: The DQN-Lite model evaluates the quality of policies using a normalized reward function, the formula of which is:

[0234] R=0.6 (Throughputnew / Throughputold)−0.2 (∣Tcore,new−80∣ / 60)−0.2 (∣Pnew−250∣ / 100),

[0235] Where: |Tcore,new−80| / 60: normalize the temperature difference (the normal operating temperature range of the GPU is 20~80℃, and the upper limit of abnormality is 140℃, so 60 is taken as the maximum deviation) to [0,1];

[0236] |Pnew−250| / 100: Normalizes the power consumption difference (typical GPU power consumption is 150~350W, so 100 is taken as the maximum deviation) to [0,1]; the reward value R ranges from [-0.4,0.6], positive numbers indicate that the policy improves performance / reduces energy consumption, and negative numbers indicate that the policy deteriorates. The model implicitly optimizes the policy based on the R value.

[0237] The DQN-Lite model was trained and compressed offline before deployment. During the online operation phase after deployment, the model mainly performs inference; further fine-tuning of its parameters (online learning) can be done in batches using historical data during system idle periods through BMC, enabling GPU resources to continuously adapt to the real-time load and achieve dynamic intelligent optimization.

[0238] The core concept of this invention is highly versatile and scalable, extending far beyond GPU resource optimization. Essentially, it constructs a new paradigm of "cross-layer closed-loop intelligent control based on an independent hardware management controller." This paradigm can be widely applied to other technical fields requiring real-time performance, high reliability, and complex decision-making capabilities. Four major extended application areas are: edge computing and AIoT devices: global energy efficiency and resource management; autonomous driving domain controllers: cross-domain fusion and security redundancy; cloud computing data centers: hardware-level fine-grained resource scheduling; and Industry 4.0 and high-reliability systems: deterministic response and predictive maintenance.

[0239] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions or improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for intelligent dynamic optimization of GPU resources based on BIOS and BMC, characterized in that: The specific steps include the following: S1, BIOS, and BMC complete the loading and initialization of core components in parallel; S2, BIOS automatically deploys the operating system, GPU optimization component package and GPU driver, wherein the GPU optimization component package includes optimization components adapted to different operating systems; S3, the operating system kernel layer loads the optimized components and GPU drivers deployed in S2 and completes initialization; S4. GPU running data is periodically collected through a timer. The GPU running data is encapsulated into a data structure and then transmitted to the BMC to provide a real-time data source for intelligent decision-making. The GPU running data is timestamped by the timer. S5 and BMC analyze and calculate GPU running data through the intelligent optimization engine, generate optimized GPU resource scheduling strategy parameters, and send them to the operating system kernel layer. The intelligent optimization engine is a DQN-Lite model that is compressed through knowledge distillation and INT8 quantization. The intelligent optimization engine encapsulates machine learning models, heuristic algorithms, or rule bases. S6. The operating system kernel layer calculates the actual control value based on the optimization strategy parameters obtained in S4, and then calls the GPU driver function to realize the control of the GPU and complete the intelligent regulation of GPU resources.

2. The intelligent dynamic optimization method for GPU resources based on BIOS and BMC according to claim 1, characterized in that: In step S1, the specific steps for loading and initializing the BIOS and BMC core components include: S11, BIOS read-load file system parsing tool, GPU optimization component package and GPU driver; S12, BMC loads a lightweight runtime environment, intelligent optimization engine, and daemon process starts.

3. The intelligent dynamic optimization method for GPU resources based on BIOS and BMC according to claim 1, characterized in that: In step S2, the specific steps for the BIOS to automatically deploy the operating system, GPU optimization component package, and GPU driver include: S21. The BIOS parses the partition table of the target installation media and the file system of the newly installed operating system to obtain file system characteristics and identify the operating system type. S22. Based on the operating system type, optimize the components to the specified kernel version and generate module dependency files based on the kernel version to ensure that they can be automatically loaded when the kernel starts. S23. Modify the auto-boot configuration for different types of operating systems.

4. The intelligent dynamic optimization method for GPU resources based on BIOS and BMC according to claim 1, characterized in that: In step S5, the specific steps for generating the optimization strategy parameters include: S51, The GPU operating data is read by accessing the GPU register through the GPU driver. The GPU operating data includes core utilization, video memory usage, core temperature, and real-time power consumption. S52. Normalize and perform temporal feature engineering on the GPU running data read in S51 to form a multi-dimensional composite feature vector and input it into the DQN-Lite model. S53. The DQN-Lite model outputs a Q-value matrix; The Q-value matrix includes a core frequency coefficient action set, a memory frequency coefficient action set, a power consumption adjustment action set, and a scheduling weight action set; S54. Perform the following decision-making process in parallel and independently on the four action sets described in S53: An ε-greedy strategy is adopted to select the action with the highest Q value with a probability of 1, and to uniformly and randomly select an action from the action set with a probability of threshold 2, thus determining the final GPU optimization strategy parameters. The threshold one is greater than the threshold two, and the sum of the threshold one and the threshold two is 1; S55. The final GPU optimization strategy parameters are encapsulated and returned to the operating system kernel layer.

5. The intelligent dynamic optimization method for GPU resources based on BIOS and BMC according to claim 1, characterized in that: In step S6, the specific steps for optimizing the GPU hardware by optimizing the strategy parameters include: S61. The policy processing unit at the operating system kernel layer receives and extracts the control parameters, and calculates the target physical value: S62. Based on the target physical value calculated in S61, the target physical value is passed to the currently used GPU through the GPU driver function, and the CPU scheduling priority of the GPU process group is adjusted, thereby indirectly affecting its weight in acquiring GPU resources.

6. A GPU resource intelligent dynamic optimization system based on BIOS and BMC, characterized in that: Used to implement any one of the GPU resource intelligent dynamic optimization methods based on BIOS and BMC as described in claims 1-5; It includes a four-layer collaborative architecture consisting of the BIOS firmware layer, the BMC management controller layer, the operating system kernel layer, and the GPU hardware layer; The BIOS firmware layer is used to identify the operating system type and to complete the deployment and auto-boot configuration of the operating system kernel layer; The operating system kernel layer collects GPU running data in real time and sends it to the BMC management controller layer; The BMC management controller layer is independent of the host CPU settings. It has an intelligent optimization engine deployed inside. The intelligent optimization engine analyzes and calculates the GPU running data, generates an optimized GPU resource scheduling strategy, and sends it to the operating system kernel layer. The operating system kernel layer receives and sends optimized GPU resource scheduling policies to the GPU hardware layer, which then executes the GPU resource scheduling policies to optimize performance.

7. The GPU resource intelligent dynamic optimization system based on BIOS and BMC as described in claim 6, characterized in that: The operating system kernel layer includes an information processing unit, a policy processing unit, and a communication module; The information processing unit collects the GPU hardware layer's operating performance parameters in real time and sends the data to the BMC management controller layer, providing a real-time data source for generating resource scheduling strategies. The strategy processing unit receives the optimization strategy returned by the BMC management controller layer, transforms the abstract strategy into specific instructions executable by the GPU hardware layer, and sends them to the GPU hardware layer for execution to adjust the GPU's operating state. The communication module executes the sending of collected data and the return of optimization strategies, realizing data exchange between the operating system kernel layer and the BMC module.

8. The intelligent dynamic optimization system for GPU resources based on BIOS and BMC as described in claim 6, characterized in that: The BMC management controller layer integrates a lightweight Python runtime environment for executing intelligent optimization algorithms; A daemon process resides on the BMC management controller layer, and the daemon process is responsible for detecting and managing the communication link between the management system and the operating system kernel. The intelligent optimization engine is set in the BMC module and is loaded and run through the Python runtime environment.

Images