A method for computing schedulable quantity of a dynamic resource specification pool for a computing power network

Abstract

A kind of adjustable quantity calculation method of dynamic resource specification pool for computing power network, the method is first by unified resource monitoring abstraction layer to the heterogeneous monitoring data of different manufacturer accelerator card is normalized, obtain standardized card level index and aggregation generation unified node resource model;Then with an accelerator card adds the number of CPU cores and adds system memory as the minimum scheduling unit, according to the two division strategy, the minimum scheduling unit in node is assembled into multi-level specification, and the same type specification is aggregated across nodes, to generate the view of site level resource specification pool;Finally, based on the unified node resource model, obtain the idle state array of each node accelerator card, use the improved Buddy System algorithm to scan the continuous idle card group of each node, calculate the schedulable quantity independently according to the specification level and update to the resource specification pool view.The invention eliminates the heterogeneous barriers of multi-manufacturer accelerator card in computing power network, improves the accuracy and utilization of resource scheduling.

Description

Technical Field

[0001] This invention relates to the fields of intelligent computing and cloud-native technology, and in particular to a method for calculating the schedulable quantity of a dynamic resource specification pool for computing power networks. Background Technology

[0002] With the explosive growth in demand for artificial intelligence, big data analytics, and distributed computing, computing networks (CNNs), as a new type of infrastructure that unifies and collaboratively supplies geographically dispersed computing resources, are becoming a research hotspot in both academia and industry. In a typical CNN environment, computing resources are no longer confined to a single data center but are aggregated in a distributed, heterogeneous manner across multiple computing centers or edge nodes to provide unified computing services to upper-layer applications. However, while this distributed, heterogeneous architecture brings massive computing power, it also presents significant challenges to the unified management and precise scheduling of resources.

[0003] First, the manufacturers and models of accelerator cards in computing networks are highly heterogeneous. In actual production environments, accelerator card types not only cover mainstream international NVIDIA GPUs (such as the H800, A100, and V100 series), but also include many domestic AI acceleration chips, such as Huawei's Ascend series, Hygon DCU, Cambricon MLU, Enflame, Biren, Moore Threads, and Baidu Kunlun XPU. These various accelerator cards differ significantly in terms of memory capacity, number of computing cores, interconnect topology, and granularity of partitioning, making it impossible to express them using a unified resource specification method.

[0004] Secondly, the monitoring interfaces of the aforementioned heterogeneous accelerator cards are incompatible. Different manufacturers provide their own independent monitoring tools: NVIDIA uses nvidia-smi, Huawei Ascend uses npu-smi, Hygon DCU uses hygon-smi, and Cambricon MLU provides the cnmon tool. These tools return different field names (such as memory fields and status fields), data formats (strings, JSON, or custom binary), and status semantics (the criteria for determining idle / busy status), making it impossible to directly compare or uniformly aggregate accelerator cards from different manufacturers. Therefore, an abstract model that can shield the underlying hardware differences is urgently needed.

[0005] Furthermore, the resource allocation granularity of accelerator cards varies. On a server equipped with multiple physical accelerator cards (e.g., an 8-card node), resources can be allocated to tasks at different granularities, such as 1 card, 2 cards, 4 cards, and 8 cards, forming multi-level specifications (1p, 2p, 4p, 8p). These specifications have complex "crowding relationships": allocating an 8p specification requires 8 consecutive cards to be idle simultaneously, while allocating several 1p specifications will sporadically occupy some card slots, thus disrupting the continuous high-specification intervals containing these card slots. Existing resource management systems (such as Kubernetes' Device Plugin framework, Slurm, etc.) typically only count the total number of physical cards or use a fixed-specification pre-allocation strategy, failing to reflect the impact of the aforementioned crowding effect on the schedulable amount of high-specifications. This leads to frequent misjudgments by the scheduler that "physical cards are idle but the required specifications are unavailable," reducing resource utilization and task scheduling success rate.

[0006] Therefore, there is an urgent need for a technical solution that can unify the abstraction of accelerator cards from multiple vendors, construct multi-level resource specification pools, and accurately calculate the schedulable quantity of each level in a heterogeneous computing power network environment. Summary of the Invention

[0007] The purpose of this invention is to provide a method for calculating the schedulable quantity of a dynamic resource specification pool for computing power networks, in order to solve at least some of the problems existing in the prior art.

[0008] Technical solution: A method for calculating the schedulable quantity of a dynamic resource specification pool for computing power networks, comprising the following steps:

[0009] The unified resource monitoring abstraction layer normalizes heterogeneous monitoring data from different vendors to obtain standardized card-level indicators and aggregates them to generate a unified node resource model.

[0010] Based on the unified node resource model, the smallest scheduling unit within a node is assembled into multi-level specifications according to the binary strategy, and the same type of specifications are aggregated across nodes to generate a site-level resource specification pool view.

[0011] Based on the unified node resource model, the idle status array of acceleration cards of each node is obtained. The improved BuddySystem algorithm is used to perform continuous idle card group scanning on each node, calculate the schedulable amount independently according to the specification level, and update the calculated schedulable amount to the site-level resource specification pool view.

[0012] Beneficial effects: This invention achieves accurate calculation of the schedulable amount of multi-vendor accelerator card resource specification pool in the computing power network by unifying the abstraction of heterogeneous resources, assembling the smallest scheduling unit, and improving the BuddySystem crowding relationship modeling. It eliminates the scheduling misjudgment of "physical card idle but specification unavailable" in the traditional solution, and improves resource utilization and the accuracy of scheduling decisions. Attached Figure Description

[0013] Figure 1 This is a flowchart of the overall solution of the present invention. Detailed Implementation

[0014] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0015] like Figure 1 As shown, this embodiment describes in detail the data processing flow of a method for calculating the schedulable quantity of a dynamic resource specification pool for computing power networks, specifically including:

[0016] S1: The unified resource monitoring abstraction layer normalizes heterogeneous monitoring data from different vendors, obtaining standardized card-level indicators and aggregating them to generate a unified node resource model, including:

[0017] S1-1: Concurrent acquisition of resources from multiple site nodes.

[0018] In this embodiment, the first step is to collect raw data from the heterogeneous node resources distributed across different sites in the computing power network. Specifically, this solution uses a fixed-size thread pool (e.g., configured with 16 threads) to initiate parallel resource collection tasks for the node lists of each site. Each node's collection task is encapsulated as an independent work unit and has an independent timeout (e.g., 15 seconds) to prevent slow response or failure of a single node from blocking the overall collection process.

[0019] For each online node, the data acquisition operation obtains raw data in the following dimensions: the node's CPU architecture identifier (e.g., x86_64, aarch64, or loongarch), the total number of CPU logical cores, the total system memory, and detailed status information of the accelerator cards mounted on the node. Accelerator card status information includes, but is not limited to, accelerator card model, total and used video memory per card, computational utilization per card, and running status per card (e.g., running or idle). The raw monitoring commands and returned field names provided by different manufacturers' accelerator cards differ significantly: for example, NVIDIA GPUs use the nvidia-smi command, Huawei Ascend uses the npu-smi command, Hygon DCUs use the hygon-smi command, and Cambricon MLUs use the cnmon command. This solution does not perform any conversion processing on these differences during the acquisition phase; instead, it collects the raw outputs from each manufacturer as raw strings or structured data.

[0020] S1-2: Mapping heterogeneous raw data to standardized card-level indicators.

[0021] In a preferred embodiment, the heterogeneous raw data collected above is input into a processing module called the "Unified Resource Monitoring Abstraction Layer". This module has pre-defined data parsing and mapping rules for accelerator cards from different vendors. For example, for data obtained from nvidia-smi, the parser extracts the "utilization.gpu" field; for npu-smi, it extracts the "utilization" or "status" field; and for hygon-smi, it extracts the "compute_util" field.

[0022] Furthermore, this solution transforms the raw data from each vendor into a set of vendor-independent standardized card-level metrics according to the following mapping rules:

[0023] Idle Status Mapping: If the computational utilization of an accelerator card is greater than 0, or its running status is marked as non-idle (e.g., running, busy), then the idle status boolean value of that card is assigned "false" (indicating it is occupied); otherwise, it is assigned "true" (indicating it is idle). This unified idle status field is denoted as "idle[cardIndex]", where cardIndex is the card number index.

[0024] Total video memory mapping: Extract the total video memory field from the original output of each manufacturer (NVIDIA corresponds to memory.total, Ascend corresponds to memory_size, Hygon corresponds to hbm_size, and Cambricon corresponds to mlu_memory_total), and convert it into a 64-bit integer value in bytes, denoted as vramTotalBytes.

[0025] Card number index normalization: The representation of card numbers in the original data of different manufacturers is different (e.g., UUID string, chip ID, serial number starting from 1, etc.). This solution uniformly maps them to a continuous integer index cardIndex starting from 0 (the value range is 0 to N-1, where N is the total number of accelerator cards in this node).

[0026] In addition, this solution calculates the number of CPU cores and system memory quota associated with each accelerator card. The specific calculation formulas are as follows: perCardCpu = logicalCores / cardCount; perCardMem = totalMemory / cardCount; where logicalCores is the total number of CPU logical cores in the node, cardCount is the total number of accelerator cards in the node, and totalMemory is the total system memory of the node. perCardCpu represents the number of CPU logical cores that can be obtained by each minimum scheduling unit, and perCardMem represents the amount of system memory that can be obtained by each minimum scheduling unit.

[0027] S1-3: Aggregation of unified node resource model.

[0028] After completing the standardization conversion of all accelerator cards, this solution aggregates all standardized card-level metrics (including idle[cardIndex], vramTotalBytes, perCardCpu, perCardMem, etc.) under the same node with the node-level CPU architecture identifier `arch` to form a unified node resource model for that node. This model exists in the form of a structure or class object in a programming language, and all its internal fields are vendor-independent standardized data types. Through the above processing, accelerator cards from different manufacturers and of different models are completely abstracted at the model level into a unified representation of "card number index + idle boolean value + number of bytes of video memory", thus providing a completely decoupled input for upper-level specification assembly and schedulable quantity calculation.

[0029] S2: Based on the unified node resource model, the smallest scheduling unit within a node is assembled into multi-level specifications according to a binary search strategy, and the same type of specifications are aggregated across nodes to generate a site-level resource specification pool view, including:

[0030] S2-1: Definition of the minimum scheduling unit and division of multi-level specifications.

[0031] According to one aspect of this application, after obtaining the unified node resource model generated by S1, the resources of each node are further standardized and partitioned. This scheme defines a minimum scheduling unit; specifically, a minimum scheduling unit consists of the following three parts: one physical accelerator card (corresponding to one cardIndex), perCardCpu CPU logical cores, and perCardMem bytes of system memory. This unit is the smallest atomic unit for resource allocation and scheduling and cannot be further divided.

[0032] For nodes with `cardCount` accelerator cards, this scheme uses a binary search strategy (the classic Buddy System approach) to assemble all `cardCount` minimum scheduling units into multiple tiers. Let the maximum tier size be `maxTier` = log2(cardCount), where log2 represents the logarithm to base 2. For a tier index `k` (where `k` ranges from 0, 1, 2, ..., `maxTier`), the corresponding tier configuration is defined as follows: Number of accelerator cards: `gpuCount` k =2 k ;Number of CPU cores: cpu k = perCardCpu × 2 k Memory size: mem k = perCardMem × 2 k The total number of spec instances that can be divided at this level: totalSpecs k = cardCount / 2 k .

[0033] For example, for an 8-card node (cardCount=8), maxTier = 3. k=0 corresponds to a 1-card specification (1p), k=1 corresponds to a 2-card specification (2p), k=2 corresponds to a 4-card specification (4p), and k=3 corresponds to an 8-card specification (8p). Each specification level contains all possible consecutive card combinations on that node, but this step only completes the mathematical description of the specification definition and does not involve the calculation of schedulable quantity.

[0034] S2-2: Generation of specification identifiers.

[0035] To uniquely identify each specification within the computing power network, this scheme employs a structured naming convention. Specifically, the identifier for each specification instance is generated according to the following format: {cpu}c.{mem}g.{gpuCount}p@pid={siteId}&p={gpuModel}&pm={perCardVramGB}; where the cpu field takes the value cpu. kThe value of the mem field is mem k (Unit: gigabytes in GB), gpuCount field value is 2 k `siteId` is a unique identifier for the computing power site, `gpuModel` is the accelerator card model string (e.g., "NVIDIA-A100-SXM4-80GB" or "Ascend-910B-64GB"), and `perCardVramGB` is the memory size of a single accelerator card (in gigabytes). This naming convention ensures that different sites, models, and tiers of specifications can all obtain globally unique identifiers, facilitating subsequent cross-node aggregation and scheduler queries.

[0036] S2-3: Generation of cross-node homogeneous aggregation and specification pool view.

[0037] In one optional implementation, this scheme horizontally merges the resources of all nodes within the same computing power site. Specifically, the nodes are first grouped according to their GPU Model, with nodes of the same model grouped together. Then, within each group, the schedulable quantity of instances with the same specification level k is accumulated; this accumulation only applies to the static metric of "total number of specification instances".

[0038] Ultimately, this solution generates a resource specification pool view for the entire site. This view is a multi-level data structure, with the top level indexed by accelerator card model, and each model indexed by specification level (1p, 2p, 4p, 8p, etc.). Each specification level records the following fields: total number of specification instances (total), current schedulable quantity (initially 0, pending S3 update), and a list of source nodes contributing to that specification. The scheduler can directly determine the availability of a specific model and specification level based on this view, without needing to know the specific distribution of the underlying cards.

[0039] S3: Based on a unified node resource model, obtain the idle status array of acceleration cards for each node. Use the improved BuddySystem algorithm to perform continuous idle card group scanning on each node, independently calculate the schedulable amount according to specification level, and update the calculated schedulable amount to the site-level resource specification pool view, including:

[0040] S3-1: Extract the idle state array from the unified node resource model.

[0041] According to a further improvement of this embodiment, after completing the static framework construction of the resource specification pool view, it is necessary to dynamically calculate the schedulable quantity of each specification level. This solution first extracts the idle state array idle[0..cardCount-1] of each node from the unified node resource model generated in S1. This array is a boolean sequence, where idle[i] = true indicates that the accelerator card at index i is currently completely idle (not occupied by any task), and idle[i] = false indicates that the card has been occupied; this array has been uniformly abstracted in step S1-2, and its idle semantics are completely consistent regardless of whether the underlying layer is NVIDIA GPU, Huawei Ascend, or Hygon DCU.

[0042] S3-2: Calculation of schedulable quantity based on continuous idle card group scanning.

[0043] This scheme employs an improved Buddy System algorithm to accurately calculate the schedulable quantity at each specification level: for specifications requiring consecutive decks (such as 2p, 4p, and 8p), the schedulable quantity equals the number of all consecutive idle decks that meet the conditions. The specific calculation process is as follows:

[0044] The schedulable quantity of the first specification level (1p, i.e., k=0): directly count the number of elements with a value of true in the idle state array, i.e.: available0 = count(idle[i] == true) for i = 0 to cardCount-1.

[0045] Scheduling capacity at level k (k ≥ 1): For each value of k, define the group size as groupSize = 2. k Then, starting from the initial index `start = 0`, traverse the entire array with a step size of `step = groupSize` until `start + groupSize - 1 < cardCount`. For each initial index, check if all accelerator cards within the continuous interval [start, start + groupSize - 1] are completely idle (i.e., `idle[start]` to `idle[start + groupSize - 1]` are both true). If the condition is true, then the available counter for the k-th level is updated. k Add 1.

[0046] According to one aspect of this application, the above scanning process can be efficiently implemented using nested loops. Preferably, the outer loop traverses the tiers from 1 to maxTier, with each tier corresponding to a group size of 2. tierThe inner loop iterates through all possible starting indices, with a fixed step size equal to the group size. This scanning method, which proceeds along continuous intervals rather than in combinations, is essentially a natural extension of the BuddySystem under resource continuity constraints.

[0047] S3-3: Manifestation of the crowding relationship and updating of schedulable quantity.

[0048] Based on the calculation results of S3-2, this scheme can clearly reveal the "crowding relationship" between multiple specification levels. Specifically, if a node has 1 schedulable 8p slot, it means there exists a consecutive interval of 8 idle cards. Within this interval, there must simultaneously exist 2 consecutive 4p intervals, 4 consecutive 2p intervals, and 8 1p slots: that is, the schedulability of a higher specification implicitly includes the schedulability of a lower specification, and vice versa. Conversely, if a task is assigned to a 1p slot (changing the card's idle status from true to false), all consecutive 2p, 4p, and 8p intervals containing that card's index will be disrupted, resulting in the availability of the corresponding higher specification slots. k The count decreased.

[0049] After calculating the availability of each node k Subsequently, this solution accumulates these schedulable resources into the corresponding specification level record in the site-level resource specification pool view generated by S2. Specifically, for schedulable resources of the same accelerator card model and the same specification level within a site, the available resources of all nodes are added. k The sums yield the final schedulable amount at the site level. This updated resource specification pool view can then be used directly by the compute scheduler to make accurate resource allocation decisions that take into account inter-card continuity constraints.

[0050] In a preferred embodiment, this solution also introduces a caching and incremental update mechanism to reduce frequent calls to the underlying monitoring interface and ensure near real-time data performance. Specifically, after the resource specification pool view data generated in S2 is calculated, it is stored in a local memory cache with a time-to-live (TTL) threshold set, such as 30 seconds. When the scheduler initiates a resource query request, it first checks whether there is any unexpired view data in the cache: if it exists, the cached view is returned directly; if the cache has expired or does not exist, the complete calculation process from S1 to S3 is automatically retried to generate the latest resource specification pool view, while updating the cache and resetting the TTL counter. According to a further improvement of this embodiment, the TTL value can be dynamically adjusted according to the scale of the computing network, but the default setting of 30 seconds can meet the real-time requirements of scheduling decisions in most actual production environments, that is, the recalculation of schedulable quantities and view updates can be completed within a maximum of 30 seconds after the accelerator card status changes.

[0051] In another embodiment, the following working process is also included:

[0052] Algorithm engineers need to apply for resources in the "Domestic Computing Power Center" for a distributed large-scale model training task. The task requires two 4p configurations (a total of 8 Huawei Ascend 910B accelerator cards, with each 4p configuration requiring 4 consecutive idle cards). Currently, the site has 4 Ascend 910B nodes (8 cards each): node-ascend-A occupies 3 cards with 5 cards remaining, node-ascend-B / C / D each occupy 5 cards with 3 cards remaining, for a total of 14 idle cards remaining.

[0053] 1. Misjudgment of initial resource requests compared to traditional methods:

[0054] The algorithm engineer opened the resource scheduling recommendation platform and filled in the following information in the requirement form: Number of specifications = 2, Specification level = 4p, Accelerator card model = Huawei Ascend 910B.

[0055] Traditional resource management methods calculate the total number of physical cards: The site has a total of 32 cards, of which 14 are idle (idle rate 43.75%), which is judged as "14 idle cards > demand of 8 cards, resources are sufficient and can be scheduled".

[0056] The problem with the traditional method is that it is unknown whether the 14 idle cards are distributed across 4 machines, and it is impossible to determine whether the condition of "4 consecutive idle cards" exists.

[0057] 2. Concurrent acquisition and unified abstraction of heterogeneous resources:

[0058] The system concurrently collects resource data from four nodes using a thread pool (16 threads). Taking node-ascend-A as an example, the system calls npu-smi to collect raw data: chip 0 / 1 / 2 is in running (occupied by a task), and chip 3 / 4 / 5 / 6 / 7 is in idle.

[0059] Through the unified resource monitoring abstraction layer, the system normalizes heterogeneous data into standard card-level indicators: idleCards[] = [false, false, false, true, true, true, true, true] for node-ascend-A, and idleCards[] = [false, false, false, false, false, true, true, true] for node-ascend-B / C / D.

[0060] 3. Modeling of crowding relationships and calculation of precise schedulable quantity:

[0061] The system is based on an improved Buddy System algorithm, scanning consecutive idle card groups for each node. node-ascend-A: 5 idle cards [3,4,5,6,7], 1p schedulable quantity = 5, 2p schedulable quantity = 2 (groups [3,4] and [6,7]), 4p schedulable quantity = 1 (4 consecutive cards exist), 8p schedulable quantity = 0. node-ascend-B / C / D: 3 idle cards each [5,6,7], 1p schedulable quantity = 3, 2p schedulable quantity = 1 (group [6,7]), 4p schedulable quantity = 0 (less than 4 consecutive idle cards), 8p schedulable quantity = 0.

[0062] Site-level aggregation: 1p schedulable quantity = 14, 2p schedulable quantity = 5, 4p schedulable quantity = 1, 8p schedulable quantity = 0.

[0063] 4. Recommended Decisions and Intelligent Optimization Suggestions:

[0064] The system determines that the requirement is for 2×4p specifications, but the actual number of 4p schedulable items is 1 (only node-ascend-A). The conclusion is "Unschedulable! One 4p specification is missing".

[0065] The system accurately diagnosed the root cause of the problem: node-ascend-B / C / D each occupied cards [0,1,2,3,4], and there were less than 4 consecutive free cards [5,6,7], resulting in 4p schedulable quantity = 0.

[0066] The system generates an intelligent optimization suggestion: migrate the two 1p tasks on card [0,1] of node-ascend-B to the idle card [4,5] of node-ascend-A (A has 5 idle cards, and after accommodating 2 1p tasks, there are still 3 cards left, which does not affect the 4p schedulable amount).

[0067] Post-migration effect: The idle cards of node-ascend-B become [0,1,5,6,7], forming a new 4p contiguous group. The schedulable 4p of the site increases from 1 to 2, meeting the requirements.

[0068] Through the above process, algorithm engineers do not need to worry about the distribution pattern and continuity constraints of the underlying accelerator cards. The system automatically identifies the hidden problem of "physical cards being idle but specifications being unavailable" by modeling the occupancy relationship, accurately locates the card occupancy status of specific nodes, and intelligently calculates the task migration scheme with the minimum migration cost. This avoids the problems of blind migration or ineffective waiting in the traditional way, and finally achieves a qualitative change from "total misjudgment" to "precise scheduling".

[0069] This invention constructs a unified resource monitoring abstraction layer to normalize heterogeneous monitoring data (including field names, data formats, and status semantics) from accelerator cards from different manufacturers such as NVIDIA, Huawei Ascend, Hygon DCU, and Cambricon into standard card-level indicators. This eliminates vendor barriers in computing power networks, allowing the addition of a new accelerator card to require only the addition of an adapter parser without modifying the core algorithm, thus exhibiting strong scalability. Furthermore, using "one accelerator card + evenly distributed CPU + evenly distributed memory" as the smallest scheduling unit, node resources are dynamically assembled into multi-level specifications such as 1p, 2p, 4p, and 8p according to a binary search strategy. A site-level resource specification pool view is generated across nodes, enabling the scheduler to directly query available resources by specification level, simplifying the resource management complexity of heterogeneous computing power networks. Furthermore, by employing an improved Buddy System algorithm, the schedulable quantity at each level is accurately calculated through continuous idle card group scanning. This correctly characterizes the "pollution effect" of low-specification allocation on the schedulability of high-specification tasks, avoiding the misjudgment of "physical cards being idle but high-specification tasks being unschedulable" in traditional solutions, thus improving scheduling accuracy and resource utilization. Furthermore, by combining a fixed-size thread pool for concurrent acquisition with short-cycle local caching (e.g., 30-second TTL), the schedulable quantity can be quickly updated after the accelerator card status changes, meeting the real-time requirements of scheduling decisions. In summary, this invention achieves a qualitative leap from "total quantity misjudgment" to "precise scheduling," providing complete technical support for the management and efficient scheduling of heterogeneous resources in a computing power network environment.

[0070] The preferred embodiments of the present invention have been described in detail above. However, the present invention is not limited to the specific details in the above embodiments. Within the scope of the technical concept of the present invention, various equivalent transformations can be made to the technical solutions of the present invention, and these equivalent transformations all fall within the protection scope of the present invention.

Claims

1. A method for calculating the schedulable quantity of a dynamic resource specification pool for computing power networks, characterized in that, include: The unified resource monitoring abstraction layer normalizes heterogeneous monitoring data from different vendors to obtain standardized card-level indicators and aggregates them to generate a unified node resource model. Based on the unified node resource model, the smallest scheduling unit within a node is assembled into multi-level specifications according to the binary strategy, and the same type of specifications are aggregated across nodes to generate a site-level resource specification pool view. Based on a unified node resource model, the idle status array of acceleration cards for each node is obtained. An improved Buddy System algorithm is used to perform continuous idle card group scanning on each node, and the schedulable amount is calculated independently according to the specification level. The calculated schedulable amount is then updated to the site-level resource specification pool view.

2. The method according to claim 1, characterized in that, Heterogeneous monitoring data is normalized to obtain standardized card-level indicators and generate a unified node resource model, including: By using a fixed-size thread pool to collect node resource data from multiple sites in parallel, we can obtain the CPU architecture, number of logical cores, total system memory, and raw monitoring data of accelerator cards from various manufacturers for each node. The raw monitoring data from different manufacturers is input into the unified resource monitoring abstraction layer, and normalized into standardized card-level indicators including card number index, Boolean idle status, and total video memory in bytes according to the preset mapping rules. The average number of CPU cores and system memory per card is also calculated. By aggregating all standardized card-level indicators and node-level attributes of the same node, a unified node resource model is generated.

3. The method according to claim 2, characterized in that, The raw monitoring data from different manufacturers is normalized into standardized card-level metrics, including: For monitoring data obtained from accelerator cards from various manufacturers, cards with utilization greater than zero or non-idle running status are mapped to occupied status (i.e., idle boolean value is false), otherwise they are mapped to idle status (i.e., idle boolean value is true). The total video memory field from each manufacturer will be uniformly converted into a standard field for total video memory in bytes. The card number indices from all manufacturers will be uniformly converted into consecutive integer indices starting from zero.

4. The method according to claim 1, characterized in that, Generate a site-level resource specification pool view, including: For each unified node resource model, extract the total number of accelerator cards and calculate the maximum slicing level; Define the resource group of the smallest scheduling unit, and divide it into two groups according to the binary search strategy. k The minimum scheduling units are assembled into the k-th level specification, where k ranges from 0 to the maximum segmentation level, and the k-th level specification contains 2 k Zhang accelerator card, corresponding CPU cores and system memory; A unique local specification identifier is generated according to the preset naming rules. This identifier includes the number of CPU cores, memory size, number of accelerator cards, site identifier, accelerator card model, and single card video memory. Aggregate the schedulable quantities of nodes with the same accelerator card model and the same specification level within the same site to generate a site-level resource specification pool view.

5. The method according to claim 1, characterized in that, An improved Buddy System algorithm is used to perform continuous idle card group scans on each node, and the schedulable amount is calculated independently according to the specification level, including: Extract the accelerator card idle status array of each node from the unified node resource model. This array is a Boolean sequence, where true indicates that the accelerator card at the corresponding index is idle, and false indicates that it is occupied. For the first specification level, the number of true values ​​in the idle state array is directly counted as its schedulable quantity. For the kth level, which is higher than the first specification level, set the group size to 2. k Starting from the initial card index zero, scan to the end with the group size as the step size, and count the number of groups in which all accelerator cards in consecutive groups are in the idle state of true, which is used as the schedulable quantity of the k-th level.

6. The method according to claim 5, characterized in that, Count the number of consecutive groups where all acceleration cards are in an idle state that is true, including: The initialization tier counter cycles through tiers from 1 to the maximum tier size, with each tier corresponding to a group size of 2. tier ; Within each level, initialize the starting index and traverse with a fixed step size of 2. tier ; For each starting index, determine the range from start to start+2. tier If all accelerator cards in the continuous interval of -1 are in the idle state, then the schedulable quantity counter of the current level is incremented by 1. After completing the scan of all levels, output the schedulable quantity counter value for each level.

7. The method according to claim 1, characterized in that, It also includes caching and incremental update steps: Set a short-term local cache for the generated site-level resource specification pool view and configure a lifetime threshold; In response to the scheduler's resource query request, resource specification pool view data is read from the local cache first. When the local cached data exceeds the time-to-live threshold, all steps in claim 1 are automatically re-executed to obtain the latest data, and the cache is updated before being returned to the scheduler.

8. The method according to claim 7, characterized in that, The survival time threshold is set to 30 seconds, so that the schedulable quantity can be updated in near real-time within a maximum of 30 seconds after the accelerator card status changes.

Images