A method and apparatus for scheduling heterogeneous cognitive hub nodes

Abstract

The application discloses a method and device for scheduling heterogeneous intelligent computing center nodes, and belongs to the technical field of intelligent computing center infrastructure. The application generates a node resource description table by detecting nodes and identifying protocol types; maps a standardized API call request to target node native instructions and executes the same; encapsulates collected node attribute data into a resource description file and stores the same into a computing power resource directory; when detecting that a comprehensive thermal risk index is greater than or equal to a preset risk threshold, sends a scheduling instruction inside a hardware abstraction layer to trigger scheduling operations such as task migration, node frequency reduction or refrigeration power up-regulation. The application realizes plug-and-play of heterogeneous nodes, unified instruction scheduling and a thermal sensing intelligent scheduling closed loop, and improves the heterogeneous computing power resource management efficiency and operation reliability of the intelligent computing center.

Description

Technical Field

[0001] This application relates to the field of intelligent computing center infrastructure technology, specifically a method and apparatus for scheduling heterogeneous intelligent computing center nodes. Background Technology

[0002] With the explosive growth of high-density computing power services such as AI large-scale model pre-training, industry large-scale model inference, scientific computing, and autonomous driving simulation, intelligent computing centers have become the core computing power infrastructure for the development of the digital economy and the artificial intelligence industry. Currently, newly built and expanded large-scale intelligent computing centers in China generally adopt a heterogeneous computing power cluster deployment model, no longer limited to acceleration chips from a single vendor or architecture, but instead deploying a mix of heterogeneous computing power nodes from multiple brands, generations, and architectures, including NVIDIA GPUs, Huawei Ascend NPUs, Cambricon MLUs, Biren Technology GPUs, and Muxi GPUs. The heterogeneous acceleration chips from different vendors exhibit significant differences in underlying communication protocols, management interface specifications, driver instruction sets, authentication handshake mechanisms, hardware attribute definitions, and interconnection topology protocols, creating serious technical barriers and compatibility issues.

[0003] Meanwhile, many high-level intelligent computing centers are located in high-altitude mountainous areas, such as Shannan in Tibet, Haixi in Qinghai, and Ganzi in western Sichuan. These sites generally have natural environmental characteristics such as high altitude, low atmospheric pressure, and thin air density. The air convection heat transfer efficiency is 30% to 40% lower than that at sea level, and the heat dissipation conditions for servers and accelerator chips are harsh. In order to ensure the stable operation of computing equipment, intelligent computing centers generally deploy a complete set of cooling terminal infrastructure, such as closed hot aisles, rear-mounted mini air conditioning units, high-precision temperature detectors on the air intake panels of the racks, and distributed temperature sensor arrays in the hot aisles, forming a multi-point, high-density, real-time temperature sensing network.

[0004] In complex application scenarios involving the mixed deployment of heterogeneous chips from multiple vendors, the coexistence of multiple communication protocols, low heat dissipation efficiency at high altitudes, and dense deployment of high-power-density racks, unified access management of heterogeneous computing nodes, cross-protocol instruction compatibility scheduling, global sharing of hardware capabilities, and coordinated linkage between cooling environment and computing power scheduling have become key technological directions that the industry urgently needs to break through. Summary of the Invention

[0005] This application provides a method and apparatus for scheduling heterogeneous intelligent computing center nodes. By constructing a pluggable and extensible hardware abstraction layer between the operating system layer and the heterogeneous hardware layer, this application achieves plug-and-play automatic access for multi-protocol heterogeneous nodes, intelligent translation from standardized APIs to vendor-native instructions, semantic global sharing of multi-level hardware capabilities, and a closed-loop thermal sensing scheduling mechanism within the hardware abstraction layer. This effectively improves the efficiency of heterogeneous computing resource management and maintenance in intelligent computing centers, enhances the transparency of cross-hardware task migration, optimizes cluster communication scheduling, and improves operational reliability in harsh environments such as high altitudes.

[0006] This application provides a method for scheduling nodes in a heterogeneous intelligent computing center. The intelligent computing center includes an operating system layer, heterogeneous hardware, and a hardware abstraction layer built between the operating system layer and the heterogeneous hardware. The heterogeneous hardware includes multiple independently deployed heterogeneous computing power hardware units with computing capabilities, and end-point cooling devices that provide cooling for the heterogeneous computing power hardware units. A node is the logical representation of a heterogeneous computing power hardware unit in the hardware abstraction layer. The method is applied to the hardware abstraction layer and includes:

[0007] When the comprehensive thermal risk index is detected to be greater than or equal to the preset risk threshold, the target node is determined to be in an overheating risk state, and a scheduling instruction is sent.

[0008] Receive scheduling instructions and parse the node identifier of the target node, current temperature reading, preset temperature threshold, comprehensive thermal risk index and scheduling operation type carried in the scheduling instructions;

[0009] Dispatch priority levels are determined based on the comprehensive thermal risk index;

[0010] When the scheduling operation type is task migration, the computing task to be migrated is selected from the target node according to the scheduling priority level, and the computing task to be migrated is scheduled to other nodes with a comprehensive thermal risk index lower than the preset safety threshold for continued execution.

[0011] When the scheduling operation type is frequency reduction, the computing frequency of the target node is reduced to the preset safety frequency level;

[0012] When the scheduling operation type is cooling adjustment, a power increase command is sent to the terminal cooling equipment.

[0013] The embodiment also provides a device for scheduling heterogeneous intelligent computing center nodes. The intelligent computing center includes an operating system layer, heterogeneous hardware, and a hardware abstraction layer built between the operating system layer and the heterogeneous hardware. The heterogeneous hardware includes multiple independently deployed heterogeneous computing power hardware units with computing capabilities and end-point cooling devices that provide cooling for the heterogeneous computing power hardware units. A node is a logical representation of a heterogeneous computing power hardware unit in the hardware abstraction layer. The device is disposed in the hardware abstraction layer and includes:

[0014] The thermal sensing scheduling module is used to determine that the target node is in an overheating risk state when the comprehensive thermal risk index is detected to be greater than or equal to the preset risk threshold, and to generate a scheduling instruction. The scheduling instruction carries the node identifier of the target node, the current temperature reading, the preset temperature threshold, the comprehensive thermal risk index and the scheduling operation type.

[0015] The computing power scheduling module receives scheduling instructions from the thermal sensing scheduling module, parses the node identifier of the target node, current temperature reading, preset temperature threshold, comprehensive thermal risk index, and scheduling operation type carried in the scheduling instructions, and determines the scheduling priority level based on the comprehensive thermal risk index. When the scheduling operation type is task migration, it selects the computing task to be migrated from the target node according to the scheduling priority level and schedules the computing task to be migrated to other nodes with a comprehensive thermal risk index lower than the preset safety threshold for continued execution. When the scheduling operation type is frequency reduction, it reduces the computing frequency of the target node to the preset safety frequency level. When the scheduling operation type is cooling adjustment, it sends a power increase instruction to the terminal cooling equipment.

[0016] Compared with existing traditional heterogeneous computing power management and scheduling solutions for intelligent computing centers, the technical solution provided in this application has the following advantages:

[0017] First, it enables plug-and-play and fully automated access for multi-protocol heterogeneous intelligent computing nodes. Through the node management module architecture, protocol feature vector extraction, and cosine similarity intelligent matching algorithm, no manual configuration is required. After a new hardware node is powered on and connected to the network, it can automatically complete protocol identification, adapter loading, identity authentication, and resource registration. The access time for a single node is reduced to the second level, and the access efficiency is improved by more than 18 times.

[0018] Second, a standardized instruction translation and adaptation mechanism is constructed to achieve complete decoupling between upper-layer applications and lower-layer heterogeneous hardware. By establishing a one-to-one mapping relationship between standardized APIs and native instructions from various manufacturers through a built-in instruction mapping table, and with the matching parameter adaptive conversion and instruction assembly logic, AI training and inference tasks can be seamlessly migrated between heterogeneous nodes. The migration time for a single task is reduced from several hours in the traditional solution to less than 5 minutes, improving migration efficiency by 48 times.

[0019] Third, it achieves semantic standardization and global sharing of heterogeneous hardware capabilities and interconnect topologies, breaking down information silos. A four-layer standardized hardware attribute description system is constructed, consisting of a device layer, a computing layer, a memory layer, and an interconnect topology layer. This system is stored in a distributed computing resource catalog and has an open query interface. The upper-layer scheduler can accurately perceive high-speed interconnect topology relationships and prioritize scheduling communication-sensitive tasks to high-speed link clusters. In actual tests, this can reduce AllReduce communication latency by 35% and shorten the total iteration time of large model training by approximately 22%.

[0020] Fourth, a closed-loop thermal sensing and scheduling mechanism is established within the hardware abstraction layer to effectively eliminate localized hotspots in high-density server racks. The hardware abstraction layer directly breaks down the data barriers between multi-source temperature sensing data from the cooling terminals and computing power scheduling. It constructs a multi-dimensional thermal risk index calculation model that integrates instantaneous temperature deviation, long-term heat accumulation effects, and differences in rack thermal inertia. This model predicts overheating risks in advance and automatically triggers scheduling commands within the hardware abstraction layer, enabling coordinated scheduling of task migration, node frequency reduction, and cooling power increase. After deployment, no overheating protection downtime events occurred in the cluster, and the effective utilization rate of computing power increased to over 95%.

[0021] Fifth, the overall architecture is pluggable, modular, and scalable, reducing hardware iteration and maintenance costs. Through thermal sensing-based intelligent scheduling, it reduces high-energy-consuming scenarios such as ineffective hardware frequency reduction and high-power operation of idle nodes, effectively lowering the overall PUE value of the intelligent computing center and reducing comprehensive operating costs by approximately 25%. Attached Figure Description

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

[0023] Figure 1 This is a flowchart illustrating the method for scheduling heterogeneous intelligent computing center nodes in this application;

[0024] Figure 2 This is a schematic diagram illustrating the calculation process of the comprehensive thermal risk index of the target node in this application embodiment;

[0025] Figure 3 This is a schematic diagram of the node resource description table generation method in the embodiments of this application;

[0026] Figure 4 This is a schematic diagram of the instruction translation process in an embodiment of this application;

[0027] Figure 5 This is a schematic diagram of the resource description file generation process in the embodiments of this application;

[0028] Figure 6 This is a schematic diagram of the system architecture for scheduling heterogeneous intelligent computing center nodes in this application;

[0029] Figure 7 This is a schematic diagram of the field structure of the node resource description table in the embodiments of this application;

[0030] Figure 8 This is a bar chart showing the statistical comparison of local hotspot events for the three comparative schemes in the experimental verification of this application. Detailed Implementation

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

[0032] This application constructs a hardware abstraction layer between the operating system layer and heterogeneous hardware in the intelligent computing center. This hardware abstraction layer integrates a node management module, an instruction translation module, a resource description module, a thermal sensing scheduling module, and a computing power scheduling module. The node management module enables automatic detection, protocol identification, and resource registration of multi-protocol heterogeneous nodes; the instruction translation module enables automatic mapping and execution of standardized APIs to native instructions from various hardware vendors; the resource description module enables standardized collection, encapsulation, and global sharing of multi-level hardware attributes of nodes; the thermal sensing scheduling module collects cooling terminal temperature data, calculates the node's comprehensive thermal risk index, and generates scheduling instructions; and the computing power scheduling module receives scheduling instructions and executes scheduling operations such as task migration, node frequency reduction, or cooling power increase.

[0033] In this application, the intelligent computing center includes an operating system layer, heterogeneous hardware, and a hardware abstraction layer connecting the operating system layer and the heterogeneous hardware. The heterogeneous hardware includes multiple independently deployed heterogeneous computing power hardware units with computing capabilities, as well as end-point cooling devices that provide cooling for the heterogeneous computing power hardware units. A node is the logical representation of a heterogeneous computing power hardware unit within the hardware abstraction layer. The hardware abstraction layer interfaces upwards with upper-layer applications and downwards with the heterogeneous computing power hardware units and end-point cooling devices.

[0034] Currently, traditional heterogeneous computing power management solutions for intelligent computing centers suffer from several problems: incompatible heterogeneous node protocols lead to reliance on manual configuration for new node access; strong hardware-software coupling makes cross-vendor task migration difficult; silos between hardware capabilities and interconnect topology information prevent scheduling optimization; and isolation between cooling temperature data and computing power scheduling leads to frequent local hotspots. This application addresses these technical issues by constructing a hardware abstraction layer that unifies four core capabilities: node discovery and registration, instruction translation and adaptation, hardware semantic modeling, and thermal sensing-based collaborative scheduling.

[0035] The technical solution of this application is preferably applied to large-scale artificial intelligence computing centers with high altitude, high power density, mixed heterogeneous chips from multiple manufacturers, coexistence of multiple communication protocols, and closed hot aisle cooling architecture.

[0036] Taking a Southwest Intelligent Computing Center as a typical example, the center plans to deploy 100 35kW ultra-high power density server racks and 20 5kW network switch racks, with a total rated installed power of 3780kW for the overall IT equipment. The site is located in a high-altitude mountainous area at an altitude of 3548 meters, with an annual atmospheric pressure of 65.8kPa and an air density of only 67% of the standard air density at sea level. Due to the air density limitation, the efficiency of natural convection and forced air cooling is reduced by 30% to 40% compared to plains areas. The heat dissipation conditions for servers and AI acceleration chips are harsh, and they are prone to forming local hot spots when running under high load.

[0037] At the computing hardware deployment level, the cluster is deployed in a hybrid manner with three types of mainstream heterogeneous acceleration nodes: (1) NVIDIA H800 GPU node: adopts NVLink 4.0 card-to-card direct interconnection protocol, device monitoring, status acquisition and task management are based on NVML private management protocol, and are adapted to CUDA ecosystem instruction set; (2) Huawei Ascend 910B NPU node: adopts self-developed HCCS high-speed interconnection architecture, upper-layer development interface is based on CANN computing framework, and the underlying driver and device authentication are Huawei private protocol specifications; (3) Cambricon MLU590 smart acceleration card: adopts standard PCIe 5.0 physical interconnection interface, device resource monitoring and power consumption temperature acquisition are based on self-developed CNMON private management protocol.

[0038] At the network interconnection protocol level, the cluster simultaneously constructs three types of high-speed communication networks: NVLink card-to-card direct connection domain, InfiniBand rack-to-rack high-speed switching subnet, and Ethernet RoCE cross-rack communication domain. The bandwidth, latency, and topology rules of these three protocols are incompatible with each other.

[0039] At the cooling infrastructure level, the entire cluster adopts a standard air conditioning architecture with enclosed hot aisles and rear-mounted mini air walls. Each enclosed hot aisle has a uniformly deployed mini air wall unit at its end, responsible for hot air recirculation and cooling. Multiple temperature sensor arrays are distributed throughout the enclosed hot aisles to collect real-time aisle return air temperature. Each server rack's air intake panel is independently equipped with a high-precision digital temperature detector, collecting real-time temperature data from the rack's air intake surface on a one-to-one basis. All sensing devices support real-time data push via MQTT and MODBUS protocols, possessing millisecond-level data acquisition and reporting capabilities.

[0040] This application provides a device for scheduling heterogeneous intelligent computing center nodes. This device is positioned between the operating system layer and the heterogeneous hardware of the intelligent computing center, forming a hardware abstraction layer. For example... Figure 6 As shown, the device adopts a microservice modular architecture design, supporting independent deployment, independent upgrades, and on-demand expansion. The device includes a heat-sensing scheduling module, a computing power scheduling module, a node management module, an instruction translation module, and a resource description module.

[0041] It should be noted that the hardware abstraction layer adopts a plug-in layered architecture, logically deployed between the operating system layer and the heterogeneous hardware layer. It interfaces with upper-layer applications and with various heterogeneous acceleration hardware and end-point cooling sensing devices. Each unit is decoupled and independent, with standardized interfaces, supporting modular deployment and dynamic expansion.

[0042] The node management module is the fundamental support unit of the hardware abstraction layer, used to maintain the pre-built protocol adapter library, manage plugin lifecycles, and dynamically load / unload protocol adapter plugins. The module pre-builds three types of basic plugins: NVIDIA NVML protocol adapter, Huawei CANN protocol adapter, and Cambricon CNMON protocol adapter, while also reserving interfaces for third-party protocol adapter extensions to support the integration of new hardware plugins from various manufacturers.

[0043] It should be noted that each protocol adapter is an independent pluggable program module (dynamic link library or containerized microservice) with three core components: (1) Probe parser: used to construct probe messages according to the protocol discovery template, parse the hardware response message format, extract protocol feature fields, and complete the protocol feature vector encoding; (2) Instruction mapping table: used to persistently maintain the mapping relationship between standardized API calls and corresponding manufacturer hardware native driver instructions and kernel function calls, and supports online editing and dynamic updates; (3) Resource acquirer: used to remotely read the original hardware attribute data of the node device layer, computing layer, memory layer, and interconnection topology layer according to the hardware private protocol, and complete the initial regularization and format conversion.

[0044] The node management module performs node detection and protocol identification functions: sending probe messages to target nodes within a preset network address range; receiving response messages and extracting protocol feature information; identifying node protocol types by matching the protocol feature information with a pre-set protocol template feature library; loading the corresponding protocol adapter based on the protocol type; performing two-way authentication with each target node through the protocol adapter; collecting basic node identification information and basic resource information of each target node after successful authentication; and generating a node resource description table based on the collected information. The output of this module is the node resource description table, which is queried and used by the thermal sensing scheduling module and the instruction translation module.

[0045] The instruction translation module is the core unit for achieving unified adaptation of multi-protocol instructions. It incorporates five sub-components: a request parser, a mapping retrieval unit, a parameter converter, an instruction assembler, and a result encapsulator. The instruction translation module receives standardized API call requests initiated by upper-layer applications, maps these requests to native instructions corresponding to the target node, sends them for execution, and encapsulates the execution results in a standard format before returning them. Specifically, the instruction translation module receives standardized API call requests initiated by upper-layer applications; parses the requests to extract operator type identifiers, tensor shape parameters, computational precision identifiers, and target node identifiers; queries the node resource description table based on the target node identifier to obtain the target communication protocol type; queries the instruction mapping table based on the operator type identifier and the target communication protocol type to match and obtain the target hardware native instruction sequence; performs parameter conversion according to the parameter format required by the native instruction sequence and assembles the native instructions; sends the native instructions to the target node for execution; receives the execution results and encapsulates them in a standard format before returning them to the upper-layer application. The output of this module is the standardized execution result, which is returned to the upper-layer application.

[0046] The resource description module is the core unit for semantic modeling of hardware capabilities and resource exposure, comprising an attribute acquisition scheduler, a semantic encapsulator, a directory synchronizer, and interface service sub-components. The resource description module collects multi-level raw hardware attribute data from each node, encapsulates it into resource description files, and stores them in the computing resource directory, providing a query interface for querying the computing resource directory. Specifically, the resource description module obtains all node identifiers from the node resource description table to generate a global node identifier list; for each node identifier, it calls the resource acquirer of the corresponding protocol adapter to collect multi-level raw hardware attribute data; after classifying and organizing the data according to four layers—device layer, compute layer, memory layer, and interconnect topology layer—it encapsulates it according to a preset unified resource description language schema to generate node resource description files; it distributes and stores the node resource description files in the computing resource directory; and it provides a standardized query interface for querying the computing resource directory. The output of this module is the computing resource directory and the standardized query interface, which are used by the upper-layer computing scheduler for resource awareness and node status evaluation.

[0047] The thermal sensing scheduling module is the core unit for implementing thermal sensing scheduling, comprising a communication access unit, a temperature data association and matching unit, a thermal risk calculation unit, and a scheduling instruction generation unit. The thermal sensing scheduling module determines that a target node is in an overheating risk state and generates a scheduling instruction when the comprehensive thermal risk index is detected to be greater than or equal to a preset risk threshold. Specifically, the thermal sensing scheduling module establishes an encrypted data communication channel with the terminal cooling equipment through the communication access unit; it collects raw temperature data at preset sampling intervals through the temperature data association and matching unit, and associates and corrects the temperature data with each node one by one based on the physical location binding mapping relationship; it reads the preset temperature threshold from the node resource description table through the thermal risk calculation unit, and calculates the temperature deviation, time-series cumulative heat effect value, and comprehensive thermal risk index; when the comprehensive thermal risk index is detected to be ≥ the preset temperature threshold, the scheduling instruction generation unit generates a scheduling instruction. The output of this module is a structured scheduling instruction, which is sent to the computing power scheduling module.

[0048] The computing power scheduling module is integrated within the hardware abstraction layer. It receives scheduling instructions from the thermal sensing scheduling module, parses the node identifier of the target node, the current temperature reading, the preset temperature threshold, the comprehensive thermal risk index, and the scheduling operation type carried in the scheduling instructions, and determines the scheduling priority level based on the comprehensive thermal risk index. When the scheduling operation type is task migration, it selects the computing task to be migrated from the target node according to the scheduling priority level and schedules the computing task to be migrated to other nodes with a comprehensive thermal risk index lower than the preset safety threshold for continued execution. When the scheduling operation type is frequency reduction, it reduces the computing frequency of the target node to the preset safety frequency level. When the scheduling operation type is cooling adjustment, it sends a power increase instruction to the terminal cooling equipment.

[0049] It should be noted that the various functional units within the hardware abstraction layer communicate using a private standardized RPC interface, and data interaction uses the encrypted protobuf format to ensure efficient, secure, and reliable communication. The overall architecture supports horizontal scaling and multi-site active-active deployment, adapting to the management and control needs of ultra-large-scale intelligent computing center clusters.

[0050] Based on the above-described apparatus, this application provides a method for scheduling heterogeneous intelligent computing center nodes. Please refer to... Figure 1 The method includes steps S10 to S60.

[0051] Step S10: When the comprehensive thermal risk index is detected to be greater than or equal to the preset risk threshold, the target node is determined to be in an overheating risk state, and a scheduling instruction is sent.

[0052] Specifically, in this embodiment, the thermal sensing scheduling module continuously monitors the comprehensive thermal risk index R of each node. i (t). Comprehensive thermal risk index R i(t) is a dimensionless constant, ranging from 0 to 1, continuously calculated by the thermal risk calculation unit of the thermal sensing and scheduling module. The preset risk threshold R... th It is a dimensionless constant, with a typical value of 0.7. The thermal sensing and scheduling module will integrate the thermal risk index R. i (t) and the preset risk threshold R th The comparison is made, and the judgment condition is R. i (t) ≥ R th Does this hold true when R_i(t) ≥ R? th When R is in an overheating risk state, the target node is determined to be in an overheating risk state. i (t) <R th If the target node is deemed to be in a safe thermal state, the scheduling process is not triggered, and monitoring continues.

[0053] After determining that the target node is in an overheating risk state, the thermal sensing scheduling module assembles and generates a structured scheduling instruction SchedCmd. This instruction contains the following fields: node identifier, current temperature reading, preset temperature threshold, comprehensive thermal risk index, and scheduling operation type. The scheduling operation type is selected from at least one of the following three types: (1) Task migration: migrate the computing task of the target node to other nodes with a comprehensive thermal risk index lower than the preset safety threshold; (2) Frequency reduction: reduce the computing frequency of the target node to the preset safety frequency level; (3) Cooling adjustment: send a power increase instruction to the end cooling equipment. After the scheduling instruction SchedCmd is generated by the thermal sensing scheduling module, it is sent to the computing power scheduling module through the internal RPC interface of the hardware abstraction layer.

[0054] It should be noted that the comprehensive thermal risk index is a quantitative indicator that integrates instantaneous temperature deviation and long-term heat accumulation effects. When this index exceeds a preset risk threshold, it indicates that the node's heat dissipation capacity can no longer meet the current computing load requirements, and continued operation may lead to hardware overheating, frequency reduction, or system crash. Step S10 is the decision node that converts continuous thermal risk values ​​into discrete scheduling trigger signals, providing a decision starting point for subsequent scheduling.

[0055] It should also be noted that scheduling instructions are the standard data units for communication between modules within the hardware abstraction layer, and their design follows the principle of "data-driven scheduling." All parameters required for scheduling decisions are encapsulated within the instructions, enabling the receiving module to independently complete scheduling execution without needing to look up the data source. Three scheduling operation types correspond to different thermal risk mitigation paths: task migration directly reduces the computational load on the target node, frequency reduction reduces heat generation per unit time, and cooling adjustment enhances external heat dissipation capabilities. These three operations can be combined to achieve the optimal thermal risk mitigation effect.

[0056] Step S20: Receive scheduling instructions and parse the node identifier of the target node, current temperature reading, preset temperature threshold, comprehensive thermal risk index and scheduling operation type carried in the scheduling instructions.

[0057] Specifically, in this embodiment, the computing power scheduling module receives the structured scheduling instruction SchedCmd sent by the thermal sensing scheduling module. The computing power scheduling module deserializes and decodes SchedCmd according to a predefined protobuf data format, extracting the following fields in sequence: node identifier, current temperature reading, preset temperature threshold, comprehensive thermal risk index, and scheduling operation type. After each field is extracted, format validation and validity verification are performed according to the data type definition. After parsing, a set of scheduling parameter fields containing node identifier, current temperature reading, preset temperature threshold, comprehensive thermal risk index, and scheduling operation type is obtained.

[0058] It's important to note that the reception and parsing of scheduling instructions is a crucial step in decoupling the modules within the hardware abstraction layer. Through standardized data formats and interface protocols, the thermal sensing scheduling module (responsible for thermal risk monitoring) and the computing power scheduling module (responsible for scheduling execution) achieve functional separation. The two modules can be developed, tested, and upgraded independently without affecting each other. Field type validation during parsing ensures data integrity and correctness, preventing scheduling errors due to data anomalies.

[0059] Step S30: Determine the scheduling priority level based on the comprehensive thermal risk index.

[0060] Specifically, in this embodiment, the computing power scheduling module will use the comprehensive thermal risk index R parsed in step S20. i (t) are respectively compared with the preset low-risk threshold R low and high-risk threshold R high Comparison. Low-risk threshold R low It is a dimensionless constant, with a typical value of 0.3~0.4; the high-risk threshold R high It is a dimensionless constant, typically 0.7~0.8. The scheduling priority level is determined according to the following logic: If R... i (t) ≥ R high If R low < R i (t) <R high If R i (t) ≤R low If so, the scheduling priority level is determined to be low priority.

[0061] It should be noted that the scheduling priority level determines the intensity of scheduling operations and the degree of resource consumption. Nodes with higher heat risk indices have a stronger urgency of overheating and require more aggressive and faster scheduling intervention. The division into high, medium, and low priorities enables the computing power scheduling module to handle multiple nodes overheating simultaneously in an orderly manner according to the severity of the risk, avoiding suboptimal scheduling results caused by scheduling resource competition.

[0062] Specifically, in this embodiment, the computing power scheduling module executes the corresponding scheduling operation branch according to the value of the scheduling operation type parsed in step S20.

[0063] Step S40: When the scheduling operation type is task migration, select the computing task to be migrated from the target node according to the scheduling priority level, and schedule the computing task to be migrated to other nodes with a comprehensive thermal risk index lower than the preset safety threshold for continued execution.

[0064] When OpType is "Task Migration," the computing power scheduling module selects the computing tasks to be migrated from the target node according to the scheduling priority level determined in step S30: all tasks are selected for high priority (0 load retention), some tasks exceeding the preset load threshold (typically 80% utilization) are selected for medium priority, and a small portion of tasks exceeding the higher load threshold (typically 90% utilization) are selected for low priority. Then, the selected computing tasks to be migrated are scheduled to other nodes with a comprehensive thermal risk index lower than the preset safety threshold for continued execution. After migration is completed, the corresponding tasks on the original target node stop executing, the load on the target node decreases, and the inlet air temperature drops.

[0065] Step S50: When the scheduling operation type is frequency reduction, the computing frequency of the target node is reduced to a preset safe frequency level.

[0066] The computing power scheduling module reduces the computing frequency of the target node to a preset safe frequency level. After frequency reduction, the node's power consumption decreases, heat generation decreases, and the temperature of the air intake surface drops.

[0067] Step S60: When the scheduling operation type is cooling adjustment, a power increase command is sent to the terminal cooling equipment.

[0068] The computing power scheduling module sends a power increase command to the end-point cooling equipment. Upon receiving the command, the end-point cooling equipment increases its cooling power and decreases the supply air temperature, thereby lowering the temperature of the air inlet surface of the target node.

[0069] A further embodiment includes: after the scheduling operation is completed, the computing power scheduling module generates an execution result status (success / failure). If the execution is successful, the comprehensive thermal risk index is expected to decrease to below the preset risk threshold; if the execution fails, an alarm log is sent to the upper-level operation and maintenance management platform.

[0070] It's important to note that the three scheduling operations operate on different dimensions: task migration operates on the load dimension, removing heat sources (computing tasks) from overheated nodes; frequency reduction operates on the power consumption dimension, reducing the heat generated by nodes per unit time; and cooling adjustment operates on the environmental dimension, enhancing external heat dissipation capabilities. These three operations can be executed independently or in combination. For example, task migration and frequency reduction can be performed simultaneously to achieve rapid cooling. In the task migration branch, the scheduling priority level determines the selection strategy for migration tasks, ensuring that high-priority scheduling migrates enough tasks to quickly reduce thermal risks, while low-priority scheduling migrates only a small number of tasks to avoid over-scheduling.

[0071] This method embodiment achieves autonomous scheduling decision-making and execution of the hardware abstraction layer when thermal risks exceed the limit by sending, receiving, parsing and executing scheduling instructions within the hardware abstraction layer in a closed loop, without the need for external intervention, thus improving the scheduling response speed; the total response time from overheat detection to the completion of scheduling instruction execution is less than 2 seconds, ensuring that no overheat protection downtime events occur in the cluster.

[0072] The embodiment also provides a method for calculating the comprehensive thermal risk index of the target node. Please refer to... Figure 2 The comprehensive thermal risk index is calculated through the following steps, including steps S101 to S107.

[0073] Step S101: Establish a data communication channel with the terminal refrigeration equipment.

[0074] Specifically, in this embodiment, the thermal sensing scheduling module establishes communication connections for each end-user cooling device based on its communication parameters, including the device's IP address, communication port number, communication protocol type (MQTT or MODBUS), and authentication credentials (username and password). For devices supporting the MQTT protocol, a subscription connection is established through the MQTT Broker to register a temperature data reporting topic; for devices supporting the MODBUS protocol, a MODBUS communication session is established through TCP / IP. After the connection is established, a two-way authentication handshake mechanism is performed to verify the device's legitimacy. The output of step S101 is a successfully established encrypted data communication channel set (Channel_set), with each end-user cooling device corresponding to a channel handle (Channel_handle).

[0075] It should be noted that the cooling terminal equipment in the intelligent computing center typically supports multiple industrial IoT communication protocols. This step establishes a communication channel through protocol adaptation, enabling the hardware abstraction layer to shield the differences in communication protocols between different devices. The encrypted communication channel ensures the security of temperature data transmission, preventing data tampering or eavesdropping.

[0076] Step S102: Periodically collect the raw temperature data of each terminal cooling device according to the preset sampling interval.

[0077] Specifically, in this embodiment, the thermal sensing scheduling module sends temperature data read requests to the corresponding end-user cooling devices through each communication channel (Channel_handle) according to a preset sampling interval Δt (unit: seconds, typical value 30 seconds). After the device responds, it returns the raw temperature data packet. The thermal sensing scheduling module receives and caches the raw temperature data, recording the acquisition timestamp t and the source device identifier (DeviceID). j The output of step S102 is the original temperature dataset. Where j represents the j-th terminal cooling device, t represents the data acquisition time, and each data point contains the device identifier DeviceID. j Temperature value , Collection timestamp t.

[0078] It should be noted that the timed sampling strategy ensures the real-time and continuous nature of temperature data. The selection of the sampling interval Δt needs to strike a balance between data timeliness and system overhead. Too short a Δt will increase communication load, while too long a Δt will reduce the sensitivity of thermal risk detection. A typical value of 30 seconds can meet real-time detection requirements in most scenarios.

[0079] Step S103: Based on the preset physical location binding mapping relationship, the original temperature data collected in a dispersed manner are associated and matched with each node, and the temperature data after association and matching is fitted and corrected to obtain the air inlet surface temperature data of each node.

[0080] Specifically, in this embodiment, the thermal sensing scheduling module binds to the mapping table Mapping{(DeviceID) based on the preset physical location. j )→(NodeID i )}, for each raw temperature data Associated with the corresponding NodeID i The mapping table is pre-stored in the node resource description table based on the cabinet deployment location relationship. For cases where the same node may be associated with multiple sensor data, the following filtering and fitting correction logic is adopted: (1) Outlier removal: Calculate the average value μ and standard deviation σ of all temperature values ​​associated with the same node, and remove data points that deviate from the average value by more than 3 times the standard deviation; (2) Data filtering: Take the median of the effective data points after removing outliers as the original air inlet surface temperature value of the node. (3) Fitting correction: Considering the sensor system error δ sensor According to the formula The corrected inlet surface temperature is obtained by performing calibration. The output of step S103 is the inlet surface temperature of each node. (Unit: °C), where i represents the node identifier and t represents the data acquisition time.

[0081] It should be noted that a node in the intelligent computing center may be covered by multiple temperature sensors (such as multiple detection points on the air intake panel of the server rack), or one sensor may serve only one node. By binding and mapping relationships based on physical locations, the scattered sensor data is aggregated to a specific node, forming a "node-level" temperature view. Outlier removal and data filtering ensure the accuracy of temperature data, preventing abnormal data caused by momentary sensor failures or interference from entering the thermal risk calculation.

[0082] Step S104: Read the preset temperature threshold for each node from the node resource description table.

[0083] Specifically, in this embodiment, the thermal sensing scheduling module uses the node identifier NodeID. i Using the primary key, query the node resource description table to retrieve the preset temperature threshold field corresponding to that node. This threshold is the highest safe operating inlet air temperature allowed for the node, determined by the equipment hardware specifications or configured by maintenance personnel based on actual operating conditions. The output of step S104 is the preset temperature threshold for node i. (Unit: °C)

[0084] It should be noted that heterogeneous computing hardware from different manufacturers and of different models has different maximum safe operating temperature specifications. Preset temperature thresholds are stored in the node resource description table, thus decoupling the threshold configuration from the temperature calculation logic. Maintenance personnel can independently adjust the temperature thresholds of each node according to actual operating conditions without modifying the thermal risk calculation logic.

[0085] Step S105: Subtract the air inlet temperature data of the target node from the preset temperature threshold to calculate the temperature deviation value of the target node.

[0086] Specifically, in this embodiment, the thermal sensing scheduling module will determine the target node's air inlet surface temperature T. i (t) and preset temperature threshold Subtract, according to the formula Calculate the temperature deviation value. The output of step S105 is the temperature deviation value of the target node. (Unit: °C). When A value >0 indicates that the temperature of the node's air inlet surface has exceeded the safe threshold; the larger the positive value, the more severe the overheating. When the value is ≤0, it indicates that the node temperature is within a safe range.

[0087] It should be noted that temperature deviation is a fundamental indicator for judging the overheating state of a node, reflecting the degree to which the current temperature deviates from the safe threshold. Subtracting the threshold from the actual temperature, rather than directly using the absolute value of the temperature, makes nodes with different threshold settings comparable.

[0088] Step S106: Obtain the historical temperature deviation sequence of the target node at multiple consecutive sampling times, and calculate the time-series cumulative thermal effect value by weighting and accumulating the temperature deviation values ​​at each sampling time in the historical temperature deviation sequence according to the time decay weight.

[0089] In this embodiment, the heat sensing scheduling module calculates the cumulative heat effect value at the current moment, and then calculates it according to the formula. Where α is the forgetting factor, a dimensionless constant ranging from 0.7 to 0.95, with a typical value of 0.8 to 0.9. This formula uses an exponentially weighted moving average model: α controls the decay rate of historical thermal effects, and max(ΔT_i(t),0) ensures that only positive temperature deviations (overheating) produce cumulative thermal effects. The output of step S106 is the time-series cumulative thermal effect value H_i(t) (a dimensionless constant) of the target node; a larger value indicates more severe long-term thermal accumulation.

[0090] It's important to note that the thermal state of a node depends not only on the current temperature but also on historical heat accumulation. Nodes operating at high temperatures for extended periods experience a greater burden on their cooling systems and faster hardware aging, even if the current temperature doesn't exceed a threshold. The introduction of the forgetting factor α allows the heat accumulation effect to both accumulate continuously and decay slowly over time, better aligning with the physical laws of heat dissipation—the device gradually cools down after overheating stops. High-density racks (with at least 16 nodes) have high thermal inertia, so a larger α (0.9~0.95) is used to slow down the decay of historical effects; for ordinary-density racks, a smaller α (0.7~0.85) is used to accelerate the decay of historical effects.

[0091] Step S107: Multiply the temperature deviation value by the first weighting coefficient to obtain the first product, multiply the time-series cumulative heat effect value by the second weighting coefficient to obtain the second product, add the first product and the second product to calculate the comprehensive heat risk index.

[0092] Specifically, in this embodiment, the thermal sensing scheduling module monitors the temperature deviation value ΔT_i(t) and the time-series cumulative thermal effect value H. i (t) Nonlinear mapping is performed separately, using the sigmoid function σ(x) = 1 / (1 + e⁻ˣ) to map the input to the interval (0,1), and σ(β×ΔT_i(t)) and σ(γ×H_i(t)) are calculated respectively. Here, β and γ are scaling factors, dimensionless constants, with typical values ​​of β = 0.5 and γ = 0.2. Then, the two are weighted and summed according to the formula... Calculate the comprehensive thermal risk index R i (t). In this equation, σ(x) = 1 / (1 + e⁻ˣ) is the sigmoid function, β and γ are scaling factors, w1 is the first weighting factor, and w2 is the second weighting factor, all dimensionless constants satisfying w1 + w2 = 1. Typical values ​​are w1 = 0.6 and w2 = 0.4. This comprehensive thermal risk index is a dimensionless constant, ranging from 0 to 1. When the comprehensive thermal risk index is close to 1, it indicates that the node is in an extremely high thermal risk state; when it is close to 0, it indicates that the node is in an extremely low thermal risk state.

[0093] For example, the sigmoid function maps the range of temperature deviation and cumulative heat effect (theoretically any real number) to the (0,1) interval, forming a probabilistic risk score, which facilitates the setting of a uniform risk threshold. Weighting coefficients w1 and w2 balance the contribution of instantaneous overheating and long-term heat accumulation to the overall risk. w1 is increased when the operation and maintenance strategy focuses more on instantaneous overheating, and w2 is increased when focusing more on long-term heat accumulation. This R... i (t) is used as the input for step S10, and is used for the overheating risk determination in step S10.

[0094] The technical advantage of this method is that, by using a multi-dimensional thermal risk assessment model that integrates instantaneous temperature deviation, time-series cumulative thermal effect, and configurable weighting coefficients, it can more accurately identify two different thermal risk modes, namely continuous overheating and instantaneous temperature shock, compared to the single temperature threshold method. This avoids false triggering caused by instantaneous temperature fluctuations and missed triggering due to long-term thermal accumulation not being detected in time.

[0095] Some embodiments also provide a method for generating node resource description tables. Please refer to... Figure 3 The node resource description table is generated through the following steps, including steps S201 to S207. This process is a prerequisite for the scheduling method, triggered when a node first accesses the network, and can also be periodically re-executed to detect newly added nodes.

[0096] Step S201: Send probe messages to each target node within the preset network address range.

[0097] Specifically, in this embodiment, the node management module generates a list of IP addresses to be probed (IP_list) by traversing the preset IP address ranges StartIP~EndIP (e.g., 192.168.1.1~192.168.1.254) and the target subnet segment SubnetMask (e.g., 255.255.255.0). For each IP address in IP_list, probe packets are constructed according to each template in the preset set of multiple protocol discovery templates (Template_set). For example, for NVIDIA devices, an NVML protocol probe packet based on a specific UDP port is constructed; for Huawei Ascend devices, a custom CANN discovery frame based on Ethernet is constructed; and for Cambricon devices, a CNMON probe packet based on the PCIe link layer is constructed. Each probe packet is sent to the corresponding IP address, and a timeout timer T_timeout (default 500ms) is started. The output of step S201 is the probe packet sending record SendLog, waiting for each target node to return a response packet.

[0098] It should be noted that heterogeneous hardware from different manufacturers exposes different communication interfaces and message formats in the network. By constructing probe messages according to various protocol templates, the probe requirements of devices from different manufacturers can be covered. The probe message construction templates are pre-installed in the system. When adding support for a new manufacturer, only a new template needs to be added, without modifying the probe logic.

[0099] Step S202: Receive the response messages returned by each target node based on the probe messages, and extract protocol feature information from the response messages.

[0100] Specifically, in this embodiment, the node management module asynchronously listens to each network port and receives the raw response packets (containing binary data stream, source IP address, and response timestamp) returned by the target node. For each received response packet, it parses and extracts the packet format identifier FormatID, communication port parameter Port, protocol version information Version, vendor-specific field VendorField, and node base identifier NodeBaseID according to a predefined packet format specification. The extracted fields are then concatenated and encoded according to a preset encoding rule to generate a fixed-dimensional protocol feature vector V. probe =[v1, v2, ..., v n ] T , where n is the fixed dimension of the feature vector (typically n=128). The output of step S202 is the protocol feature vector V. probe (n-dimensional real vector).

[0101] It should be noted that response messages from different vendors' proprietary protocols exhibit varying numerical characteristics in terms of format identifiers, port numbers, version numbers, and proprietary fields. Encoding these unstructured binary message fields into fixed-dimensional real-number vectors is a crucial step in transforming the protocol identification problem into a mathematical similarity calculation problem. This fixed-dimensional design ensures that response messages from all devices can undergo uniform mathematical calculations.

[0102] Step S203: Match and identify the node protocol type of each target node by matching the protocol feature information with the pre-set protocol template feature library.

[0103] Specifically, in this embodiment, the node management module calculates the cosine similarity between the protocol feature vector output in step S202 and the feature vectors of each template in the preset protocol template feature library.

[0104] The formula for calculating cosine similarity is:

[0105]

[0106] in For real-time protocol feature vectors, This is the feature vector of the k-th template. The feature vectors of the k preset protocol templates have a preset threshold value ranging from 0.85 to 0.95.

[0107] The pre-built protocol template feature library contains K templates, each corresponding to a known vendor's communication protocol, and a standardized template feature vector is pre-stored. Thus, K cosine similarity values ​​{cos1, cos2, ..., cos...} can be calculated. K}, select the maximum value cos max and cos max Compare with the preset threshold value θ: if cos max If ≥ θ, then the match is successful, and cos max The protocol type corresponding to the protocol template is used as the protocol identification result for this node; if cos max If the value is less than θ, then the matching fails, and the protocol identification fails. The output of step S203 is the node protocol type or a protocol identification failure flag.

[0108] It should be noted that cosine similarity measures the degree of similarity between two vectors in a direction; the closer the value is to 1, the better the match. The advantage of this method is that it is insensitive to vector magnitude; even if the response message strengths of different devices differ, the directional similarity of their protocol feature vectors can still be effectively measured. The preset threshold θ (0.85~0.95) ensures the accuracy of the matching, accepting only protocol identification results that are highly similar to the standard template, thus avoiding misidentification.

[0109] Step S204: Load the corresponding protocol adapter according to the node protocol type.

[0110] Specifically, in this embodiment, the node management module uses the node protocol type ProtocolType output in step S203 as an index to search for a matching protocol adapter Adapter_match in the pre-built protocol adapter library Adapter_lib = {Adapter_NVML, Adapter_CANN, Adapter_CNMON, ...}. Once found, the adapter module is dynamically loaded—if the adapter is a dynamic link library, the system's dynamic loading interface (such as dlopen or LoadLibrary) is called to load and initialize it; if the adapter is a containerized microservice, its service endpoint is obtained through the service discovery mechanism. After successful loading, a communication session with the adapter is established. The output of step S204 is the loaded protocol adapter instance Adapter_handle.

[0111] It should be noted that the plug-in adapter architecture is one of the core designs of the hardware abstraction layer in this application. Each vendor's proprietary protocol corresponds to an independent adapter module, and the adapters are completely decoupled. The dynamic loading mechanism allows the system to load adapters on demand based on the protocol identification results at runtime, without preloading all adapters, thus reducing resource consumption. When adding support for a new vendor, only the new adapter needs to be added to the pre-built library, without modifying the core system code.

[0112] Step S205: Perform two-way authentication with each target node through the protocol adapter.

[0113] Specifically, in this embodiment, the node management module sends an encrypted authentication request to the target node via the Adapter_handle. Upon receiving the request, the target node returns its pre-defined, unique physical identifier NodeID_hw and a real-time dynamic verification code OTP. The Adapter_handle then performs authentication locally according to the following dual-verification logic:

[0114] First verification: The received NodeID_hw is compared with the NodeID_expected (the expected value of the target node's unique physical identifier) ​​in the local pre-set whitelist. If they match, the verification passes; otherwise, the node is determined to be unauthorized.

[0115] The second verification step involves decrypting the OTP using the preset encryption key Key_encrypt and verifying whether the decrypted OTP matches the expected verification code generated locally. If they match, the verification passes; otherwise, the authentication fails. The output of step S205 is the authentication result flag Flag_auth (True indicates that both verifications passed; False indicates that at least one verification failed).

[0116] It should be noted that two-way authentication ensures the legitimacy and security of access nodes. The unique physical identifier NodeID_hw is an immutable identifier fixed at the factory and used to verify the physical identity of the node; the real-time dynamic verification code (OTP) is generated based on time synchronization or challenge-response algorithms and used to verify the real-time legitimacy of the node at the communication layer. This dual authentication mechanism effectively prevents security threats such as MAC address spoofing and replay attacks.

[0117] Step S206: After identity authentication is successful, collect the basic node identification information and basic resource information of each target node.

[0118] Specifically, in this embodiment, after authentication, the node management module uses the resource acquirer built into the Adapter_handle to remotely read the target node's full-dimensional basic resource information according to the target node's hardware private protocol format. This includes: node device model (Model), hardware manufacturer (Vendor), number of AI computing cores (CoreCount), video memory capacity (MemSize), rated power consumption parameter (PowerRating), supported communication protocol type (SupportedProtocols), and physical deployment rack number (CabinetID). The resource acquirer performs preliminary formatting and standardization on the collected raw data. The output of step S206 is the node basic resource information set ResourceInfo = {Model, Vendor, CoreCount, MemSize, PowerRating, SupportedProtocols, CabinetID}.

[0119] It should be noted that hardware from different manufacturers differs in data format, field definitions, and unit systems for resource information. The resource acquirer, as a sub-component of the adapter, is specifically responsible for parsing and extracting resource information according to the manufacturer's proprietary protocol, converting non-standardized raw data into a standardized format recognizable by the system, thus laying the data foundation for subsequent unified management and scheduling.

[0120] Step S207: Generate a point resource description table that records at least the basic node identification information, node protocol type, basic resource information and preset temperature threshold of each node.

[0121] Specifically, in this embodiment, the node management module standardizes and inputs all the above data according to a predefined relational data table format, using the node identifier NodeID_i (generated from the NodeBaseID extracted in step S202, serving as a globally unique primary key) as an index. For example... Figure 7 As shown, the node resource description table includes: NodeID_i (unique node identifier), ProtocolType, Vendor, Model, CoreCount (number of compute cores), MemSize (memSize), PowerRating (rated power consumption), Temperature threshold T_th_i, CabinetID (physical rack number), and RegTime (registration timestamp). After all fields are standardized and organized, they are written into the ResourceTable with NodeID_i as the primary key.

[0122] It's important to note that the node resource description table is the core metadata of the hardware abstraction layer. It centralizes fragmented node information into a structured table, enabling efficient retrieval for subsequent operations such as protocol type lookup and temperature threshold reading. The existence of this table eliminates the need for scheduling modules to repeatedly read raw information from the hardware, thus improving overall system efficiency.

[0123] The technical advantages of this method are as follows: by actively probing and using cosine similarity template matching, the protocol type of heterogeneous nodes from multiple vendors can be automatically identified without manual configuration; the legitimacy and security of access nodes are guaranteed through a dual authentication mechanism; and the overall implementation of plug-and-play automatic access for heterogeneous nodes reduces the access time for a single node from 45 minutes in the traditional solution to 2.5 minutes.

[0124] The embodiment also provides an instruction translation step, namely, a method for the hardware abstraction layer to respond to API call requests initiated by upper-layer applications. Please refer to... Figure 4 The method includes steps S301 to S307. This instruction translation step is a parallel execution step of the scheduling method, which continuously listens for and processes computing task requests from upper-layer applications.

[0125] Step S301: Receive a standardized API call request initiated by the upper-layer application.

[0126] Specifically, in this embodiment, the instruction translation module listens to the standardized API service port 24 / 7 and receives standardized API call requests (APIReq) initiated by upper-layer applications. This request includes a request header (containing a call type identifier) ​​and a request payload (containing specific parameters). Upon receiving the request, the instruction translation module performs an integrity check: it checks whether the request format conforms to the standardized API specification and whether the request payload is complete. If the check passes, the request is added to the processing queue. The output of step S301 is a standardized API call request (APIReq_valid) that has passed the check.

[0127] It should be noted that the standardized API is a general calling interface specification defined in this application. Upper-layer applications request computing power services by calling these APIs without needing to know the specific model and protocol of the underlying hardware. The instruction translation module achieves decoupling from the application layer by listening on a standard port: the application layer does not need to know the internal logic of the instruction translation module, but only needs to send requests according to the specification.

[0128] Step S302: Parse the standardized API call request and extract the operator type identifier, tensor shape parameter, calculation precision identifier, and target node identifier from the standardized API call request.

[0129] Specifically, in this embodiment, the request parser of the instruction translation module performs deep parsing of APIReq_valid. For kernel function launch type requests (launch_kernel), the following fields are extracted sequentially from the request payload: operator type identifier OpType (e.g., "matmul" for matrix multiplication, "conv2d" for 2D convolution, "all_reduce" for full reduction), tensor shape parameter Shape (an array, e.g., [1024, 1024] for a 1024-row × 1024-column 2D matrix), computation precision identifier Prec (e.g., "FP32", "FP16", "BF16", "INT8", "INT32", etc.), and target node identifier NodeID_target (empty if not specified by the upper layer). For other types of APIs such as device query and memory allocation, the corresponding request parameter fields are extracted. The output of step S302 is the parsed parameter field set {OpType, Shape, Prec, NodeID_target}.

[0130] It's important to note that deep parsing deconstructs standardized API request parameters into independent fields, allowing each field to participate in different processing logic in subsequent steps. Operator types are used for instruction mapping, tensor shapes for parameter transformation, and node identifiers for protocol lookup. This deconstructive processing approach is more flexible than overall forwarding, facilitating differentiated adaptation and transformation for different parameters.

[0131] Step S303: Query the node resource description table based on the target node identifier to obtain the target communication protocol type corresponding to the target node identifier.

[0132] Specifically, in this embodiment, the instruction translation module uses NodeID_target as the primary key to query the node resource description table ResourceTable. If NodeID_target is not empty, it directly retrieves the ProtocolType field corresponding to the node and reads the hardware vendor information Vendor; if NodeID_target is empty, it selects available nodes from ResourceTable whose current load is below a preset threshold (typically 80%) according to a load balancing strategy, such as a round-robin algorithm or a least-task-first algorithm, and reads their protocol type and hardware vendor information, using these nodes as the target nodes. Finally, the communication protocol type ProtocolType_target corresponding to the target node is obtained. The output of step S303 is the target communication protocol type ProtocolType_target.

[0133] It should be noted that the node resource description table records the protocol type information of each node, which is the basis for selecting or confirming the target node. When the user specifies a target node, its protocol type is queried to select the correct instruction mapping table; when the user does not specify a target node, the load balancing strategy automatically selects the optimal node and determines its protocol type.

[0134] Step S304: Query the preset instruction mapping table according to the operator type identifier and the target communication protocol type to obtain the target hardware native instruction sequence.

[0135] Specifically, in this embodiment, the instruction translation module combines OpType and ProtocolType_target into a single encoding to generate a combined retrieval key Key_combined = OpType + "|" + ProtocolType_target (e.g., "matmul|CANN"). Using Key_combined as the query key, the module searches the instruction mapping table InstrMap, which is pre-installed within the protocol adapter. The instruction mapping table is persistently stored in a key-value pair structure. The primary key of the mapping table is a combination encoding of "operator type identifier + hardware communication protocol type." The InstrEntry key contains the following fields: the corresponding native instruction sequence NativeInstrSeq (the sequence of binary instructions or function calls executable by the target hardware), the parameter format definition ParamFormat (the order, data type, and byte alignment requirements of each parameter), the data type constraints TypeConstraints (the allowed data type range for each parameter), and the call timing description TimingSeq (the sequential dependencies between multiple instructions). The primary key of the mapping table is matched with Key_combined; if a match is found, the corresponding complete InstrEntry is extracted as the mapping result. The output of step S304 is the native instruction mapping entry InstrEntry = {NativeInstrSeq,ParamFormat, TypeConstraints, TimingSeq}.

[0136] It's important to note that the same operator requires calling different native instructions with different names and formats on different vendors' hardware. For example, matrix multiplication is called `cublasSgemm` on NVIDIA and `aclnnMatMul` on Huawei Ascend. The instruction mapping table establishes a one-to-one mapping relationship through a combination key of "operator type + protocol type," mapping standardized semantics to vendor-specific execution instructions. The combined encoding design allows the mapping table to support retrieval along any dimension, providing good scalability.

[0137] Step S305: According to the parameter format required by the native instruction sequence, convert the tensor shape parameters and calculation precision identifier into a parameter dimension form compatible with the target node, and assemble to generate the target hardware native instructions.

[0138] Specifically, in this embodiment, the instruction translation module performs the following conversions in sequence according to ParamFormat and TypeConstraints in InstrEntry: (1) Precision level conversion: Based on the list of precision levels supported by the target hardware defined in TypeConstraints, Prec (which may be FP32, FP16, BF16, INT8 or INT32) is adaptively converted to the precision level encoding Prec_native supported by the native driver of the target hardware. For example, if the target hardware is Huawei Ascend, Prec="FP16" is converted to "aclnnFloat16" encoding; if the target hardware is NVIDIA, Prec="FP16" is converted to "CUDA_R_16F" encoding; (2) Dimension format alignment and step parameter conversion: Based on the tensor dimension arrangement format (such as row-major or column-major) defined in ParamFormat, the multidimensional tensor dimension arrangement parameters and step parameters in Shape are converted to the array format Shape_native and memory layout structure MemLayout that can be recognized by the target hardware computing core. The converted Prec_native, Shape_native, and MemLayout are filled into the parameter slots of NativeInstrSeq according to the parameter arrangement order, data type, and byte alignment requirements defined in ParamFormat, completing the assembly of the target hardware native instruction NativeInstr. The output of step S305 is the target hardware native instruction NativeInstr (binary format, containing opcode and parameter data).

[0139] It's important to note that different hardware manufacturers have varying requirements for parameter formats, including data type naming conventions, tensor dimension arrangement (row-major or column-major), and memory alignment. The parameter converter's role is to "translate" standardized parameters into a hardware-recognizable format, freeing upper-layer applications from understanding these underlying differences. The instruction assembler, on the other hand, concatenates the opcode and parameter data into executable instructions according to the native instruction's binary format specifications.

[0140] Step S306: Send the native command to the target node for execution.

[0141] Specifically, in this embodiment, the instruction translation module encapsulates the NativeInstr into a data packet conforming to the target hardware's private communication protocol format via a protocol adapter. It adds a protocol header (including instruction type identifier and sequence number), performs encryption signing (to ensure transmission security), and adds a verification field (to ensure data integrity). After encapsulation, the packet is sent to the target heterogeneous hardware via the communication link between the hardware abstraction layer and the target node. The output of step S306 is the execution request result ReqResult (sent / failed to send). If the sending is successful, the process proceeds to step S307 to receive the execution result; if the sending fails, a call exception status code is returned to the upper-layer application.

[0142] It's important to note that sending native commands involves the encapsulation capabilities of the protocol adapter. Different vendors' proprietary protocols vary in header format, encryption methods, and verification algorithms. The protocol adapter encapsulates these differences, making the command sending process transparent to other sub-components of the command translation module.

[0143] Step S307: Receive the execution result returned by the target node, encapsulate the execution result into a standard format, and return it to the upper layer application.

[0144] Specifically, in this embodiment, the result encapsulator of the instruction translation module receives the raw execution result Result_raw (binary data stream, format defined by the target hardware manufacturer's proprietary protocol) returned after the target hardware executes the native instruction. It then encapsulates this result according to the unified return format of the standardized API, including data type conversion (converting hardware-specific data types to standardized data types), field normalization (extracting valid fields from the result data), and exception status code adaptation (converting hardware-specific error codes to unified status codes). For example, it converts the cudaError_t returned by NVIDIA to a unified status code (0 indicates success, non-zero indicates an error type) and encapsulates the computation result tensor into a unified data handle. After encapsulation, the standardized result Result_std is synchronously returned to the upper-layer application that initiated the call through the standardized API response channel. The output of step S307 is the standardized execution result Result_std, which the upper-layer application can directly use without being aware of the differences in the underlying heterogeneous hardware.

[0145] It should be noted that the execution results returned by different hardware manufacturers vary in terms of data type, error code definition, and result format. The reverse conversion function of the result wrapper is symmetrical to the parameter conversion in step S305. S305 converts the standardized parameters into the hardware-specific format, and S307 converts the hardware-specific results into the standardized format.

[0146] Through a standardized API-to-vendor native instruction translation mechanism, complete decoupling between upper-layer applications and underlying heterogeneous hardware is achieved, eliminating the need for upper-layer applications to write different code for different hardware vendors. Simultaneously, this instruction translation mechanism provides the technical prerequisite for task migration in step S40. The target node after migration may be hardware from different vendors; standardized API calls can be automatically translated into the corresponding hardware's native instructions, ensuring that cross-vendor task migration is completely transparent to upper-layer applications.

[0147] The embodiments also provide a method for generating resource description files. Please refer to [link / reference]. Figure 5 The method includes steps S401 to S404. This process is a supporting step of the scheduling method, responsible for collecting multi-level hardware attributes of each node and generating standardized resource description files for the upper-layer computing power scheduler to perform resource awareness and node status evaluation.

[0148] Step S401: Obtain all node identifiers in the node resource description table and generate a global node identifier list.

[0149] Specifically, in this embodiment, the resource description module reads the node identifier field NodeID_i of all online nodes from the node resource description table ResourceTable, and generates a global node traversal list NodeID_list = {NodeID_1, NodeID_2, ..., NodeID_M}, where M is the total number of currently online nodes. This list is sorted by node registration time and supports parallel collection to improve efficiency. The output of step S401 is the global node identifier list NodeID_list.

[0150] It should be noted that the node resource description table is the index source for all nodes in the system. By traversing this table, a complete list of currently online nodes can be obtained, avoiding omissions or duplicate data collection. The independence of this step decouples the attribute collection logic from the node registration logic.

[0151] Step S402: For each node identifier in the global node identifier list, call the resource acquirer built into the corresponding protocol adapter to collect the original data of the multi-level hardware attributes of the node corresponding to that node identifier.

[0152] Specifically, in this embodiment, the resource description module traverses each node identifier NodeID_i in NodeID_list, calls the resource acquirer of the corresponding protocol adapter, and collects the original hardware attribute data according to four levels: (1) Device layer: node rated power consumption PowerRating_i (unit W), safe temperature threshold T_th_i (unit °C), working voltage range VoltRange_i (unit V), device online operating status Status_i (online / offline / fault), hardware firmware version FirmwareVer_i; (2) Computation layer: operator throughput Throughput_i (unit TFLOPS) at each precision, single operator computation latency Latency_i (unit ms), hardware supported operator type complete set SupportedOps_i (enumeration list), AI computing core real-time utilization Util_i (unit 1000 TFLOPS). (3) Memory layer: Total bandwidth of video memory Bandwidth_i (unit GB / s), physical capacity MemCap_i (unit GB), average memory access latency MemLatency_i (unit ns), real-time memory utilization rate MemUtil_i (percentage), memory error correction capability parameter ECCCap_i; (4) Interconnect topology layer: High-speed communication link topology connection relationship TopoLink_i (such as the adjacency list between node A and node B with NVLink direct connection), link protocol type LinkProto_i (NVLink / InfiniBand / RoCE / PCIe), link currently available remaining bandwidth LinkBw_i (unit GB / s), unique identifier of the neighboring node connected to the other end of the link NeighborID_i, link fault status identifier LinkStatus_i (normal / degraded / fault). The output of step S402 is the multi-level hardware attribute raw dataset AttrRaw_i ={DeviceLayer_i, ComputeLayer_i, MemLayer_i, InterconnectLayer_i} of node i.

[0153] It should be noted that the resource acquirer is built into the corresponding protocol adapter of each manufacturer, and has the ability to parse hardware attribute data according to the manufacturer's proprietary protocol. The four-layer division reflects the different dimensions of hardware attributes—the device layer represents physical attributes, the computing layer represents computing power attributes, the memory layer represents storage attributes, and the interconnect topology layer represents network attributes. Categorized collection facilitates differentiated data processing and storage in subsequent steps.

[0154] Step S403: The original data of multi-level hardware attributes is structured and encapsulated according to the standardized format of the preset unified resource description language to generate a node resource description file.

[0155] Specifically, in this embodiment, the resource description module categorizes AttrRaw_i into four levels according to a preset Unified Resource Description Language Schema (JSON Schema specification definition): The device layer includes node rated power consumption, safe temperature threshold, operating voltage range, device online operating status, and hardware firmware version; the computation layer includes operator throughput at various precision levels, single operator computation latency, the complete set of hardware-supported operator types, and real-time utilization of the AI ​​computing core; the memory layer includes total video memory bandwidth, physical capacity, average memory access latency, real-time memory occupancy, and memory error correction capability parameters; and the interconnection topology layer includes high-speed communication link topology connections, link protocol type, currently available remaining bandwidth of the link, unique identifiers of adjacent nodes connected to the other end of the link, and link fault status identifiers. Then, according to the field name mapping, data type conversion rules, and enumeration value standardization dictionary defined in the Schema, the original data is converted into standardized fields. Finally, using the node identifier NodeID_i as the root object identifier, the four-level standardized fields are encapsulated into a JSON-formatted node resource description file ResDescFile_i. The data structure of this file is as follows:

[0156] json

[0157] { "node_id": "NodeID_i", "device_layer": {"power": PowerRating_i, "temp_threshold": T_th_i, ...}, "compute_layer": {"fp32_throughput":Throughput_i, "supported_ops": SupportedOps_i, ...}, "memory_layer": {"bandwidth": Bandwidth_i, "capacity": MemCap_i, ...}, "interconnect_layer":{"links": [{"target": NeighborID_i, "protocol": LinkProto_i, "bandwidth":LinkBw_i}, ...]}}

[0158] It should be noted that the Unified Resource Description Language (URL) is a standard hardware description specification defined in this application, which functions similarly to a device's "standard instruction manual." Through this specification, heterogeneous hardware attributes from different manufacturers are converted into a unified JSON Schema data structure, enabling the upper-layer scheduler to obtain hardware information from all nodes using the same parsing method, completely breaking down information silos.

[0159] Step S404: Distribute the node resource description files to the computing power resource catalog and provide a query interface for querying the computing power resource catalog.

[0160] Specifically, in this embodiment, the resource description module binds each ResDescFile_i to a node identifier NodeID_i and writes it to the computing resource directory through a distributed storage client (such as an etcd cluster). Each record uses NodeID_i as the key and ResDescFile_i as the value, and also records the write timestamp UpdateTime. When the node's hardware attributes or operating status change, the resource description module automatically incrementally updates the corresponding ResDescFile_i and updates UpdateTime. The resource description module also exposes a standardized resource query interface to the outside world. This interface supports RESTful or gRPC protocols and supports various query methods such as precise query by node ID, query by computing power specification range, query by communication bandwidth threshold, query by temperature threshold, and combined retrieval by link protocol type. The output of step S404 is the stored set of node resource description files {ResDescFile_i} stored in the computing resource directory, as well as the standardized query interface.

[0161] It's important to note that the distributed storage architecture ensures high availability and consistency of the resource catalog. The standardized query interface enables the upper-layer computing scheduler to perform fine-grained resource selection and task allocation based on hardware attributes. For example, it can query nodes supporting FP16 precision or NVLink interconnected node clusters, achieving precise matching of computing tasks with hardware capabilities.

[0162] The technical advantages of this method are as follows: by modeling hardware attributes at four levels, fragmented heterogeneous hardware parameters are standardized, semanticized, and structured, breaking down information silos between hardware capabilities and interconnect topology. The upper-layer computing scheduler can accurately perceive high-speed interconnect topology relationships through query interfaces and prioritize scheduling communication-sensitive tasks to high-speed link clusters, reducing AllReduce communication latency by 35%.

[0163] Application Example 1: Automatic Connection of New Heterogeneous Nodes

[0164] The maintenance personnel connected a brand-new Huawei Ascend 910B NPU server to the intelligent computing center's management network and powered it on. The hardware abstraction layer node management module periodically sent probe packets according to the preset IP network segment. The Ascend server management network card returned response packets carrying private characteristic fields of the CANN protocol. The node management module extracted the protocol feature vector and calculated the cosine similarity with the feature vectors of three preset templates: NVIDIA, Huawei, and Cambricon. The similarity values ​​were 0.32, 0.96, and 0.28, respectively. The maximum similarity of 0.96 was greater than the matching threshold of 0.85, and it was automatically identified as the Huawei CANN protocol. The node management module dynamically loaded the Huawei CANN protocol adapter and completed two-factor authentication through a unique hardware identifier and a dynamic verification code. The adapter read the NPU device model, number of AI Cores, 32GB HBM memory capacity, 350W rated power consumption, temperature threshold, and other attribute parameters, and wrote them into the node resource description table in a standardized manner. The entire access process took less than 2 seconds and required no manual configuration intervention, achieving plug-and-play functionality.

[0165] Application Example 2: Transparent Migration of Tasks Across Vendors

[0166] The upper-layer computing scheduler initially assigned the large model training task to NVIDIA H800 GPU node A for execution; during high-load operation, the intake air temperature of node A's rack continued to rise, and the thermal sensing scheduling module collected the intake air surface temperature of node A. =39℃, preset temperature threshold for node A =35℃, calculate temperature deviation ΔTi=4℃; cumulative heat effect value at the previous moment. =0.2, forgetting factor α=0.8, calculate H i (t)=0.8×0.2+0.2×4=0.96; Taking β=0.5, γ=0.2, w1=0.6, w2=0.4, calculate σ(0.5×4)=0.88, σ(0.2×0.96)=0.55, the thermal risk index Ri(t)=0.6×0.88+0.4×0.55=0.748>0.7, exceeding the high-risk threshold, and node A is determined to be in an overheating risk state; the thermal sensing scheduling module generates a scheduling instruction SchedCmd={NodeID=A, T=39℃, T_th=35℃, R=0.748, OpType=task migration} and sends it to the computing power scheduling module; the computing power scheduling module receives and parses the scheduling instruction, determines the scheduling priority as high priority based on R=0.748, the scheduling operation type as task migration, selects all computing tasks to be migrated from node A based on the high priority, and schedules them until the comprehensive thermal risk index is lower than the preset safety threshold R. safeOn other nodes with a thermal risk index of 0.3 (such as Huawei Ascend 910B node B with a comprehensive thermal risk index of 0.18), execution continues. Upper-layer business applications only call standardized APIs to initiate matrix multiplication operator requests. The instruction translation module automatically completes protocol matching, instruction mapping, parameter conversion, and instruction distribution on node B. The entire task migration requires no modification to the business code, is completely transparent to upper-layer applications, and takes less than 5 minutes. After the migration, the load on node A decreases, the inlet air temperature drops, and R_i(t) gradually decreases to a safe range.

[0167] Application Example 3: Topology-Aware Optimized Scheduling

[0168] The hardware abstraction layer resource description module collects interconnect topology layer attributes, generates a node resource description table, and provides a query interface. Nodes A, B, and C have a high-speed NVLink direct connection topology (600GB / s bandwidth), while node D only supports low-speed PCIe interconnect (32GB / s bandwidth). When allocating AllReduce communication-intensive large model sharding tasks, the upper-layer computing scheduler obtains cluster interconnect topology information through the query interface, identifies the presence of high-speed NVLink links between nodes A, B, and C, and prioritizes scheduling tasks to the A / B / C node cluster, avoiding low-speed PCIe link communication. Actual measurements show a 35% reduction in inter-task card communication latency and a 22% reduction in total model training iteration time.

[0169] Application Example 4: Adaptive Temperature Threshold Adjustment

[0170] During the long-term operation of the intelligent computing center, the thermal sensing scheduling module continuously monitors the thermal risk index of each node. For a certain low-load node, the thermal risk index is below the low-risk threshold of 0.3 for eight consecutive sampling periods (30 seconds per period). The system then proceeds according to... The temperature threshold is linearly increased by δ=0.5℃, from 35℃ to 35.5℃, without exceeding the chip's maximum safe temperature of 85℃. For a certain high-load node, if the thermal risk index instantaneously exceeds the high-risk threshold of 0.75, the system will... The temperature threshold is lowered by η=0.98, from 35℃ to 34.3℃, triggering a more sensitive thermal protection mechanism in advance to avoid hardware overheating and shutdown.

[0171] To verify the actual effect of the technical solution of this application, 120 heterogeneous computing power nodes (80 NVIDIA H800 GPUs, 20 Huawei Ascend 910B NPUs, and 20 Cambricon MLU590s) were deployed in the intelligent computing center, and three control experiments were set up: control group 1 did not deploy the hardware abstraction layer of this application; control group 2 deployed the hardware abstraction layer of this application but disabled the thermal sensing scheduling function; and experimental group 3 fully deployed all functions of this application.

[0172] Experimental results are as follows Figure 8As shown: In terms of average access time per node, control group 1 was 45 minutes, while experimental group 3 was 2.5 minutes, representing an 18-fold improvement in access efficiency; in terms of cross-vendor task migration time, control group 1 was 4 hours, while experimental group 3 was less than 5 minutes, representing a 48-fold improvement in migration efficiency; in terms of local hotspot events, control group 2 experienced 27 occurrences, while experimental group 3 experienced 0 occurrences; in terms of overheat protection downtime, control group 2 experienced 6 occurrences, while experimental group 3 experienced 0 occurrences; in terms of effective utilization of computing power, experimental group 3 reached 96.5%; AllReduce communication latency was reduced by 35% compared to control group 2, and the total training iteration time was shortened by 22%; and the overall operating cost was reduced by approximately 25%.

[0173] Experimental data show that the technical solution of this application significantly improves the access efficiency, task migration flexibility, cluster operation stability and communication scheduling optimization capabilities of heterogeneous intelligent computing nodes, and is fully adaptable to large-scale intelligent computing center application scenarios with high altitude, high power density and mixed deployment of heterogeneous chips from multiple vendors.

[0174] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for scheduling heterogeneous intelligent computing center nodes, characterized in that, The intelligent computing center comprises an operating system layer, heterogeneous hardware, and a hardware abstraction layer connecting the operating system layer and the heterogeneous hardware. The heterogeneous hardware includes independently deployed heterogeneous computing power hardware units with computing capabilities, as well as end-point cooling devices that provide cooling for these heterogeneous computing power hardware units. Nodes are the logical representation of heterogeneous computing power hardware units within the hardware abstraction layer. Methods are applied to the hardware abstraction layer and include: When the comprehensive thermal risk index is detected to be greater than or equal to the preset risk threshold, the target node is determined to be in an overheating risk state, and a scheduling instruction is sent. Receive scheduling instructions and parse the node identifier of the target node, current temperature reading, preset temperature threshold, comprehensive thermal risk index and scheduling operation type carried in the scheduling instructions; Dispatch priority levels are determined based on the comprehensive thermal risk index; When the scheduling operation type is task migration, the computing task to be migrated is selected from the target node according to the scheduling priority level, and the computing task to be migrated is scheduled to other nodes with a comprehensive thermal risk index lower than the preset safety threshold for continued execution. When the scheduling operation type is frequency reduction, the computing frequency of the target node is reduced to the preset safety frequency level; When the scheduling operation type is cooling adjustment, a power increase command is sent to the terminal cooling equipment.

2. The method according to claim 1, characterized in that, The comprehensive heat risk index is calculated through the following steps: Establish a data communication channel with the terminal refrigeration equipment; The raw temperature data of each terminal cooling device is collected periodically according to the preset sampling interval; Based on the preset physical location binding mapping relationship, the original temperature data collected in a dispersed manner are associated and matched with each node one by one, and the temperature data after association and matching are fitted and corrected to obtain the air inlet surface temperature data of each node. Read the preset temperature threshold for each node from the node resource description table; The temperature deviation value of the target node is calculated by subtracting the air inlet temperature data of the target node from the preset temperature threshold. The historical temperature deviation sequence of the target node at multiple consecutive sampling times is obtained. The temperature deviation values ​​at each sampling time in the historical temperature deviation sequence are weighted and accumulated according to the time decay weight to calculate the time-series cumulative heat effect value. The temperature deviation value is multiplied by the first weighting coefficient to obtain the first product, and the time-series cumulative heat effect value is multiplied by the second weighting coefficient to obtain the second product. The first product and the second product are added together to calculate the comprehensive heat risk index.

3. The method according to claim 2, characterized in that, Also includes: Send probe messages to each target node within a preset network address range; Receive response messages returned by each target node based on the probe messages, and extract protocol feature information from the response messages; The node protocol type of each target node is determined by matching and identifying the protocol feature information with a pre-set protocol template feature library. Load the corresponding protocol adapter based on the node's protocol type; Two-way authentication is performed with each target node via a protocol adapter; After identity authentication is successful, basic node identification information and basic resource information of each target node are collected; Generate a point resource description table that records at least the basic node identification information, node protocol type, basic resource information and preset temperature threshold of each node; The node resource description table records at least the basic node identification information, node protocol type, basic resource information, and preset temperature threshold for each node.

4. The method according to claim 3, characterized in that, The system sends probe packets to each target node within a preset network address range, receives response packets from each target node based on the probe packets, extracts protocol feature information from the response packets, and matches and identifies the node protocol type of each target node based on the protocol feature information against a preset protocol template feature library. Specifically, this includes: Probe messages are periodically sent to each target node within the preset IP address range and target subnet segment. The probe messages are constructed according to preset discovery templates for various protocols. Asynchronously receive response messages returned by each target node based on the probe messages; Parse and extract message format identifiers, communication port parameters, protocol version information, vendor-specific fields, and node basic identifiers from the response message, and encode these message format identifiers, communication port parameters, protocol version information, vendor-specific fields, and node basic identifiers to generate a fixed-dimensional protocol feature vector; Calculate the cosine similarity between the protocol feature vector and the feature vectors of each preset protocol template; The protocol template with the highest cosine similarity and greater than the preset threshold is selected as the protocol recognition result.

5. The method according to claim 3, characterized in that, Two-way authentication is performed between the protocol adapter and each target node, specifically including: Send an encrypted authentication request to the target node via the protocol adapter; Receive the unique physical identifier and real-time dynamic verification code returned by the target node based on the encrypted authentication request; Verify the validity of the unique physical identifier of the hardware locally; After successful verification, the real-time dynamic verification code is decrypted using a preset encryption key, and the validity of the real-time dynamic verification code is verified. After both the unique physical identifier and the real-time dynamic verification code have been verified, the identity authentication and access authorization of the target node are completed.

6. The method according to claim 1, characterized in that, Also includes: Receive standardized API call requests initiated by upper-layer applications; Parse standardized API call requests and extract operator type identifiers, tensor shape parameters, computational precision identifiers, and target node identifiers from them. Query the node resource description table based on the target node identifier to obtain the target communication protocol type corresponding to the target node identifier; The target hardware native instruction sequence is obtained by querying the preset instruction mapping table based on the operator type identifier and the target communication protocol type. According to the parameter format required by the native instruction sequence, the tensor shape parameters and calculation precision identifiers are converted into a parameter dimension form compatible with the target node, and then assembled to generate the target hardware native instructions. Send the native command to the target node for execution; Receive the execution result returned by the target node, encapsulate the execution result into a standard format, and return it to the upper layer application.

7. The method according to claim 1, characterized in that, Also includes: Retrieve all node identifiers from the node resource description table and generate a global node identifier list; For each node identifier in the global node identifier list, the resource acquirer built into the corresponding protocol adapter is invoked to collect the original multi-level hardware attribute data of the node corresponding to that node identifier; The raw data of multi-level hardware attributes are structured and encapsulated according to the standardized format of the preset unified resource description language to generate node resource description files. The node resource description files are distributed and stored in the computing resource catalog, and a query interface is provided for querying the computing resource catalog.

8. The method according to claim 7, characterized in that, The raw data of multi-level hardware attributes is categorized and organized into four levels: device layer, compute layer, memory layer, and interconnect topology layer. The device layer includes node rated power consumption, safe temperature threshold, operating voltage range, device online operating status, and hardware firmware version; The computation layer includes operator throughput at various precision levels, single operator computation latency, the complete set of operator types supported by the hardware, and the real-time utilization of the AI ​​computing core. The memory layer includes parameters such as total video memory bandwidth, physical capacity, average memory access latency, real-time memory utilization, and memory error correction capability. The interconnection topology layer includes the high-speed communication link topology connection relationship, link protocol type, currently available remaining bandwidth of the link, unique identifier of the adjacent node connected to the other end of the link, and link fault status identifier.

9. A device for scheduling heterogeneous intelligent computing center nodes, characterized in that, The intelligent computing center comprises an operating system layer, heterogeneous hardware, and a hardware abstraction layer built between the operating system layer and the heterogeneous hardware. The heterogeneous hardware includes independently deployed multiple heterogeneous computing power hardware units with computing capabilities, as well as end-point cooling devices that provide cooling for the heterogeneous computing power hardware units. Nodes are the logical representations of the heterogeneous computing power hardware units in the hardware abstraction layer. Devices are located in the hardware abstraction layer and include: The thermal sensing scheduling module is used to determine that the target node is in an overheating risk state when the comprehensive thermal risk index is detected to be greater than or equal to the preset risk threshold, and to generate a scheduling instruction. The scheduling instruction carries the node identifier of the target node, the current temperature reading, the preset temperature threshold, the comprehensive thermal risk index and the scheduling operation type. The computing power scheduling module receives scheduling instructions from the thermal sensing scheduling module, parses the node identifier of the target node, current temperature reading, preset temperature threshold, comprehensive thermal risk index, and scheduling operation type carried in the scheduling instructions, and determines the scheduling priority level based on the comprehensive thermal risk index. When the scheduling operation type is task migration, it selects the computing task to be migrated from the target node according to the scheduling priority level and schedules the computing task to be migrated to other nodes with a comprehensive thermal risk index lower than the preset safety threshold for continued execution. When the scheduling operation type is frequency reduction, it reduces the computing frequency of the target node to the preset safety frequency level. When the scheduling operation type is cooling adjustment, it sends a power increase instruction to the terminal cooling equipment.

10. The apparatus according to claim 9, characterized in that, Also includes: The node management module is used to detect each node and determine the node protocol type of each node. After two-way identity authentication, it collects the basic node identification information and basic resource information of each node and generates a node resource description table. The instruction translation module is used to receive standardized API call requests initiated by upper-layer applications, map the standardized API call requests into native instructions corresponding to the target node and send them for execution, and encapsulate the execution results into a standard format and return them. The resource description module is used to collect the original data of multi-level hardware attributes of each node, encapsulate it into a resource description file and store it in the computing power resource catalog, and provide a query interface for querying the computing power resource catalog.

Images