Computing power management platform, electronic equipment and readable storage medium

Abstract

The embodiment of the invention provides a computing power management platform, electronic equipment and a readable storage medium. The computing power management platform comprises a resource abstraction and portrait device, a resource segmentation controller and a strategy and scheduling mapper, the resource abstraction and portrait device is used for automatically determining a node resource portrait corresponding to a target node aiming at any target node managed in the computing power management platform; and the resource segmentation controller is used for dividing the node resources of the target node based on the node resource portrait to obtain a plurality of resource groups corresponding to the target node. And the strategy and scheduling mapper is used for matching and determining a target resource from a resource group corresponding to each target node housed and managed by the computing power management platform based on a segmentation share demand required by the target task, and allocating the target resource to the target task. The task can be ensured to obtain sufficient computing power support, the overall resource utilization rate can be improved, efficient sharing and flexible allocation of computing power resources within the platform management range are achieved, and the system operation efficiency and response capability are improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a computing power management platform, electronic device, and readable storage medium. Background Technology

[0002] With the rapid development of information technology, various computing platforms have emerged, but there are still many problems in platform management and resource allocation.

[0003] In related technologies, on the one hand, regarding node access management on platforms, most current platforms rely on manual configuration operations when adding nodes, making the node access process cumbersome, error-prone, and difficult to achieve efficient management of large-scale nodes. On the other hand, in the field of computing resource allocation, existing resource allocation methods are relatively extensive and cannot accurately and flexibly allocate resources according to the diverse business needs of different tenants, resulting in the underutilization of computing resources. Thus, the lack of a systematic computing power management method on the platform increases the complexity and difficulty of platform operation and maintenance, and reduces overall operation and maintenance efficiency. Summary of the Invention

[0004] To overcome the problems existing in related technologies, the present invention provides a computing power management platform, an electronic device, and a readable storage medium.

[0005] In a first aspect, the present invention provides a computing power management platform, which includes a resource abstractor and profiler, a resource partitioning controller, and a strategy and scheduling mapper. The resource abstractor and profiler is used to automatically determine the node resource profile corresponding to any target node managed in the computing power management platform. The resource partitioning controller is used to partition the node resources of the target node based on the node resource profile, thereby obtaining multiple resource groups corresponding to the target node; The strategy and scheduling mapper is used to match and determine target resources from the corresponding resource groups of each target node managed by the computing power management platform based on the required allocation share of the target task, and allocate the target resources to the target task.

[0006] In a second aspect, the present invention provides an electronic device comprising: a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the computing power management platform described in any one of the first aspects above.

[0007] Thirdly, the present invention provides a readable storage medium that, when the instructions in the storage medium are executed by the processor of an electronic device, enables the electronic device to execute a computing power management platform as described in any of the embodiments of the first aspect above.

[0008] In this embodiment of the invention, the computing power management platform includes a resource abstractor and profiler, a resource partitioning controller, and a policy and scheduling mapper. The resource abstractor and profiler automatically determines the node resource profile corresponding to any target node managed by the computing power management platform. The resource partitioning controller divides the node resources of the target node based on the node resource profile, obtaining multiple resource groups corresponding to the target node, thus structuring complex resources and enhancing the flexibility and controllability of resource management. The policy and scheduling mapper matches and determines target resources from the corresponding resource groups of each target node managed by the computing power management platform based on the partitioning share required by the target task, and allocates the target resources to the target task. In this way, by dynamically allocating resources according to the actual needs of the task, resource idleness or excessive occupation is avoided. This ensures that tasks receive sufficient computing power support, improves overall resource utilization, achieves efficient sharing and flexible allocation of computing resources within the platform's management scope, and enhances system operating efficiency and responsiveness. Attached Figure Description

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

[0010] Figure 1 This is a schematic diagram of a computing power management platform provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of another computing power management platform provided in an embodiment of the present invention; Figure 3 This is a structural diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

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

[0012] Figure 1 This invention provides a computing power management platform, which includes a resource abstractor and profiler 101, a resource partitioning controller 102, and a policy and scheduling mapper 103.

[0013] The resource abstractor and profiler 101 is used to automatically determine the node resource profile corresponding to any target node managed in the computing power management platform.

[0014] In this embodiment of the invention, the computing power management platform can manage multiple nodes. Once a node is managed by the computing power management platform, its resources can be incorporated into unified management. For any target node, after the target node is successfully managed by the computing power management platform, the platform can initiate a resource detection mechanism to determine the type of computing power possessed by the target node. The computing power type can include GPUs (Graphics Processing Units), NPUs (Neural Processing Units), etc. Correspondingly, node resources can include heterogeneous computing power such as GPUs or NPUs. Furthermore, the specific model of the computing power card is determined. Different models of computing power cards may differ in performance and functional characteristics; for example, some GPU models may have higher memory bandwidth or stronger computing core performance.

[0015] Furthermore, the computing power management platform performs unified profiling and abstraction operations on the resources of the target node to obtain the node resource profile corresponding to the target node. This operation aims to form a vendor-independent capability description, eliminating the differences in description methods between different hardware manufacturers, and making resource management more standardized and universal. The node resource profile is a comprehensive description and quantitative presentation of multi-dimensional information such as the characteristics, status, and performance of various resources of the target node. The node resource profile can include information such as resource model, resource quantity, resource capacity, resource version, and resource partitioning capability. Among them, the resource model is used to characterize the specific product type of the node resource, the resource quantity is used to count the total number of resources equipped on the target node, the memory capacity is used to reflect the space available for data storage, the resource version is used to indicate whether the resource can work normally and what functional features it supports. Different versions of drivers may bring performance optimizations or support for new features, and the resource partitioning capability is used to characterize whether hardware partitioning capability is available, such as whether it supports MIG, i.e., multi-instance GPU technology, which allows a single GPU to be divided into multiple independent instances.

[0016] Furthermore, target nodes can be tagged with rule labels. These labels can be of various types, such as "sharing mode," "number of segments," "overselling ratio," and "whether hardware partitioning is supported." To facilitate subsequent development and maintenance, a small number of example key names, such as `gpu_share_mode` and `gpu_slices`, can be retained. These key names serve only as implementation mapping descriptions, helping developers understand the correspondence between specification labels and actual code implementation, ensuring that the resource profiling process is clear, traceable, and easy to manage.

[0017] The resource partitioning controller is used to partition the node resources of the target node based on the node resource profile, thereby obtaining multiple resource groups corresponding to the target node.

[0018] In this embodiment of the invention, based on the node resource profile, the node resources of a target node can be divided. According to the detailed information contained in the node resource profile, and combined with preset division rules and strategies, the overall resources of the target node are decomposed and recombined to form multiple relatively independent resource groups with specific resource quotas. The preset division rules and strategies can be set according to different usage requirements, and this embodiment of the invention does not impose any restrictions on them. A resource group can refer to a set of related resources within the target node, such as a resource combination containing a specific number of vGPUs and video memory.

[0019] For example, assuming the target node's node resource is a GPU card, a single GPU card can be divided into multiple vGPU units according to a share. Each vGPU unit can correspond to a fixed amount of video memory and computing quota. For example, a single GPU card can be divided into N parts (such as 10 parts), and each part is a resource group with a clearly defined resource. This partitioning method does not rely on hardware partitioning and achieves fine-grained resource allocation through software algorithms.

[0020] During the allocation process, a controlled over-allocation mechanism can also be introduced. For example, upper limits (such as 1.5x and 1.2x) can be set for computing power and video memory respectively. This means that, while ensuring system stability, a certain degree of resource over-allocation is allowed to improve overall resource utilization. For instance, if the computing power of a GPU card is originally 100%, under a controlled over-allocation setting of 1.5x, the total computing power that can be allocated can reach 150%.

[0021] When a node first connects to the computing power management platform or when the resource allocation strategy changes, a readiness check is required. Based on the node's resource profile and pre-defined threshold matching rules, a rigorous check is performed to determine whether the partitioning parameters can be issued. For example, it checks whether there is sufficient video memory to ensure enough memory is available for the partitioned resource groups; whether resource utilization is within a reasonable range to avoid performance degradation due to excessive utilization; and whether the temperature is within a safe range to prevent hardware damage due to overheating. The partitioning parameters will only officially take effect after all check conditions are met; otherwise, the partitioning strategy needs to be adjusted until the check requirements are satisfied.

[0022] After the partitioning parameters are issued and node resources are allocated, the computing power management platform continuously monitors the usage of resource groups corresponding to each node managed by the platform. This monitoring can be done, for example, through the computing power monitoring module installed on the platform. If any abnormalities are detected, such as allocation failure (e.g., a resource group cannot obtain the required resources normally) or prolonged utilization congestion (e.g., the utilization rate of a resource group remains excessively high, affecting the normal use of other resource groups), the system can automatically roll back to the last stable parameter settings. Simultaneously, to avoid system oscillations caused by repeatedly issuing the same parameters, the system retains an idempotent flag to ensure that the same parameters do not cause unnecessary operations and impacts due to multiple issuances.

[0023] The multiple resource groups corresponding to the nodes managed by the computing power management platform are unified and measurable, providing a foundation for subsequent unified resource allocation. The platform can flexibly and rationally allocate resources from the resource groups corresponding to each node based on different user needs, task priorities, and resource usage strategies. This achieves efficient resource utilization and management, and enables stable resource allocation through software, providing a unified and measurable minimum resource unit for subsequent scheduling and user consumption. Correspondingly, some nodes managed by the platform can be grouped into node groups. The node resources within each node group can be uniformly allocated and collaboratively operated to achieve specific computing tasks or meet diverse business needs.

[0024] In summary, in this embodiment of the invention, the computing power management platform includes a resource abstractor and profiler, a resource partitioning controller, and a policy and scheduling mapper. The resource abstractor and profiler automatically determines the node resource profile corresponding to any target node managed by the computing power management platform. The resource partitioning controller divides the node resources of the target node based on the node resource profile, obtaining multiple resource groups corresponding to the target node, which can structure complex resources and enhance the flexibility and controllability of resource management. The policy and scheduling mapper matches and determines the target resources from the corresponding resource groups of each target node managed by the computing power management platform based on the partitioning share required by the target task, and allocates the target resources to the target task. In this way, by dynamically allocating resources according to the actual needs of the task, resource idleness or excessive occupation is avoided. This ensures that the task receives sufficient computing power support, improves the overall resource utilization rate, realizes efficient sharing and flexible allocation of computing power resources within the platform's management scope, and improves system operating efficiency and responsiveness.

[0025] Optionally, Figure 2 This invention provides a computing power management platform, which includes a resource abstractor and profiler 101, a resource partitioning controller 102, a policy and scheduling mapper 103, and a management instruction generator 104.

[0026] The management instruction generator 104 is used to generate management instructions based on the instruction template to be filled and the input parameters; the management instructions are used to run on the target node, so that the computing power management platform manages the target node.

[0027] In this embodiment of the invention, a user can initiate a management request to the computing power management platform and input parameters into the platform. These parameters may include node name, node type, authentication password, platform entry address, initial partitioning strategy, and required dependencies. The node name serves as a unique identifier within the computing power management platform. The node type can include cloud nodes and edge nodes, and the template to be used is determined based on the node type. The authentication password verifies the legitimacy of node access. The platform entry address can be the network address where the node accesses the platform. The initial partitioning strategy can include the initial method for partitioning node resources, which can be set according to requirements. For example, the initial partitioning method for GPUs can be specified as partitioning by memory ratio or number of computing cores. Required dependencies may include program or configuration dependencies related to node drivers or operation, such as specific versions of GPU drivers, computing power container runtime environments, and computing power monitoring. The computing power management platform can be a distributed resource management and task orchestration platform with capabilities for unified resource management, automated task scheduling, and unified service deployment, such as the Kubernetes container orchestration system.

[0028] The computing power management platform can pre-configure multiple sets of instruction templates to be filled. These templates can be pre-designed script frameworks containing variable parameter placeholders. For example, different initialization templates can be designed for cloud nodes and edge nodes. The instruction template for cloud nodes can focus on the interaction configuration with cloud service interfaces, while the template for edge nodes can focus on local network environment adaptation. Based on the node type in the input parameters, the corresponding instruction template is selected in the computing power management platform. The entry address and authentication password are injected into the corresponding placeholder positions of the instruction template. Furthermore, the entire instruction template after parameter filling is signed or encapsulated with a verification code. The signature can generate a unique identifier using an encryption algorithm, while the verification code is used to verify whether the instruction has been tampered with during transmission. After encapsulation, a directly executable managed instruction is generated. For example, the managed instruction can be a script obtained and executed via a network request using a `curl | bash` entry point, or an equivalent local script call instruction. The managed instruction includes a unique node identifier, access address, authentication information, registration steps, and optional partitioning strategy placeholders.

[0029] For example, the code content of the instruction template to be populated can be as follows: / / TemplateType defines the template type enumeration / / Node management script template used to differentiate between different deployment environments type TemplateType string const ( TemplateTypeCloud TemplateType = "cloud" / / Cloud node template: suitable for data center environments, includes complete system initialization and monitoring configuration. TemplateTypeEdgeTemplateType = "edge" / / Edge node template: suitable for edge computing environments, lightweight configuration, and optimized resource usage. ) / / TemplateManager struct / / Responsible for managing different types of script templates, providing template registration, search, and rendering functions. type TemplateManager struct { templates map[TemplateType]*template.Template / / Template map, keys are template types, values ​​are Go template objects } / / EnrollInput is the input body generated by the enroll command, which is ultimately embedded with the signature payload.

[0030] / / Includes all configuration parameters and options required for the managed node type EnrollInput struct { NodeName string `json:"node_name"` / / Unique name of the node (human / machine readable), used for identification and registration with the platform NodeType `json:"node_type"` / / Node type (cloud / edge), determines which management template to use. AuthToken string `json:"auth_token"` / / The authentication password issued by the platform, used for node registration and API call authentication. PlatformURL string `json:"platform_url"` / / Platform entry URL (can override global configuration), used for node registration and configuration download. SplitStrategy string `json:"split_strategy"` / / Initial splitting strategy preference (auto / high / off, etc.), affecting GPU resource allocation. Deps[]string `json:"deps"` / / List of dependencies to be installed (drivers, monitoring, storage, etc.), such as nvidia-driver, dcgm-exporter ExpireAfterSecint64`json:"expire_after_sec"` / / Command validity period (seconds). If <= 0, the default TTL is used to ensure the timeliness of the monitoring command. OneTimeNoncestring`json:"one_time_nonce"` / / One-time random string, preventing replay attacks and ensuring the uniqueness of managed commands. OSInitWantedbool`json:"os_init_wanted"` / / Whether to perform OS initialization, including system updates, kernel parameter optimizations, etc. InstallRuntime bool `json:"install_runtime"` / / Whether to install the container / computing runtime (Docker / containerd) for containerized application deployment. InstallMonitorbool `json:"install_monitor"` / / Whether to install monitoring components (such as NodeExporter) for system monitoring and metric collection. `joinK8sbool `json:"join_k8s"` / / Whether to join the Kubernetes cluster, used for container orchestration and resource management. `kubeAPIServer string `json:"kube_api_server"` / / The API server address for kubeadm join, used to join nodes to the cluster. KubeJoinToken string `json:"kube_join_token"` / / kubeadm join token, used for node authentication and authorization KubeDiscoveryCA string `json:"kube_discovery_ca"` / / discovery-token-ca-cert-hash, used to verify the API Server identity } / / EnrollPayload is a signed managed payload that contains metadata and business inputs.

[0031] / / All information used to encapsulate the management instructions, ensuring data integrity and security. type EnrollPayload struct { Versionstring `json:"version"` / / Payload version number (protocol evolution), used for compatibility management and version control. IssuedAtint64`json:"issued_at"` / / Issuance time (Unix seconds), used for auditing and timeliness verification. ExpiresAtint64`json:"expires_at"` / / Expiration time (Unix seconds), ensuring the timeliness of monitoring commands. EnrollBody EnrollInput `json:"enroll_body"` / / The enroll input body, containing all enroll configuration parameters. } / / SignedCommand is the one-click management command (including the original payload and signature) that is finally returned to the user.

[0032] / / Contains directly executable commands and related security verification information type SignedCommand struct { Commandstring `json:"command"` / / Executable shell commands that users can run on the target node. Payloadstring `json:"payload"` / / Base64 encoded JSON payload (for auditing / replay), used for tracing and debugging. Signature string `json:"signature"` / / Base64 encoded HMAC-SHA256 signature, used to verify the integrity and origin of the command. } It is understood that the above code content is only a code example for the template to be filled, and the specific code content can be adjusted according to actual needs. This embodiment of the invention does not limit the code content.

[0033] Executing the management command on the target node triggers the subsequent access, registration, and policy distribution processes automatically. The automated script corresponding to the management command runs on the target node, installing the necessary software or drivers as specified by the user, configuring the node's basic operating environment (such as network parameters and user permissions), initializing the operating system, registering the target node to the computing power management platform, and ultimately enabling the platform to manage the target node. The target node can be a server node, such as a physical or virtual server device deployed in different scenarios, including the cloud or edge.

[0034] In this embodiment of the invention, a node management instruction generator generates management instructions based on the instruction template to be filled and the input parameters, ensuring that the instructions are accurately adapted to the target node. This method automates the node management process, eliminating the need for manual configuration of each node, reducing potential errors and tediousness caused by manual operation, and improving management efficiency and accuracy, thereby achieving efficient node management.

[0035] Optionally, "matching and determining target resources from the corresponding resource groups of each target node managed by the computing power management platform based on the required allocation share for the target task" may include the following steps: Step 201: In response to the resource request operation of the target user, determine the share requirement corresponding to the target user based on the resource requirement indicated by the resource request operation.

[0036] In this embodiment of the invention, after the resources managed by the target platform are divided, they can be allocated to different users. Target users can send resource requests to the target platform. In response to the resource request operation of the target user, the resource requirement is mapped to a share allocation based on the resource demand indicated by the resource request operation, thus determining the share allocation requirement corresponding to the target user. Here, the target user refers to an individual or system entity that proposes resource usage requirements, such as the tenant administrator corresponding to the target platform. The share allocation requirement abstracts the user-side resource demand into a quantifiable allocation unit, enabling more precise processing in subsequent resource allocation processes.

[0037] For example, a user's resource request may include resource requirement information, such as "request 3 vGPUs" or "require 12GB of video memory." The system uses a parsing mechanism to identify and analyze this source requirement information, mapping it into a share allocation requirement. In other words, if the system sets each vGPU to correspond to a specific share allocation, then requesting 3 vGPUs will be converted into 3 corresponding share allocation requirements; for video memory requirements, the system will convert 12GB of video memory into the corresponding number of share allocations according to a preset conversion rule between video memory and share allocation.

[0038] Step 202: Based on the required allocation share and the node resource information of each node managed by the computing power management platform, perform resource matching to obtain the matching result.

[0039] In this embodiment of the invention, based on the share allocation requirements and the node resource information of each node managed by the target platform, a matching result is obtained according to a preset matching rule. A node can be an entity within the target platform with independent resources (such as computing resources, storage resources, etc.), and node resource information can include the quantity of various available resources on the node, resource status (such as whether it is occupied), and other related information. It is understood that the preset matching rule can be set according to actual needs, using factors such as the fairness of resource allocation and node load balancing as matching criteria. For example, the preset matching rule could be to select the node and resources that best match the available share and share allocation requirements and have the most stable historical allocation. Best matching of available share means that the remaining resource share of the node best matches the share allocation requirements of the target user; for example, most stable historical allocation means that the node has a low probability of experiencing failures or anomalies during past resource allocation processes.

[0040] Understandably, when the remaining resource share of a single node cannot meet the user's allocation requirements, the remaining resource shares of at least two nodes can be combined. Resource matching is then performed based on the combined remaining resource shares of these two nodes to obtain a matching result. This resource matching process yields a matching result, which may include information about one or more nodes that conform to preset matching rules, as well as the resources that node can provide.

[0041] Step 203: Based on the matching result, determine the target resources to be allocated to the target user; the target resources include at least one resource group in at least one node.

[0042] In this embodiment of the invention, the remaining resource share of at least one node indicated by the matching result is allocated as target resource to the target user. For example, based on the matching result, a corresponding resource group is allocated from the nodes selected in the matching result as target resource and allocated to the target user. For instance, exclusive permissions for the target resource can be granted to the target user through system instructions to complete the resource allocation and ensure that the target user can use the resource.

[0043] Furthermore, when allocating resources, allocation strategies can be set for the resource allocation process, such as "centralized" or "distributed" placement strategies, computing power isolation strategies, priority, preemption strategies, and computing power quotas. The "centralized" placement strategy prioritizes allocating tasks or data to the same node group, or grouping highly related tasks or data into specific resource groups. The "distributed" placement strategy distributes tasks or data evenly and dispersedly across different node groups or resource groups. Computing power isolation strategies isolate different tasks or user processes in different computing resource units to prevent mutual interference. For example, if user A is allocated 50% of the computing power of node A, and user B is allocated the other 50%, then users A and B can only use their respective allocated computing power resources and cannot use each other's. Priority strategies assign corresponding priority identifiers to each task or service within resource groups and node groups, prioritizing the needs of high-priority tasks when allocating computing resources. In other words, high-priority tasks have priority in acquiring resources; low-priority tasks are automatically queued when resources are insufficient. For example, the computing power management platform schedules tasks based on available resources and priority within the queue, and automatically generates corresponding task execution instances within the Kubernetes cluster. A specific scenario is that inference tasks, due to their high response latency requirements, are prioritized for scheduling when resources are scarce, and low-priority training tasks are paused to release resources when necessary. The preemption strategy refers to allowing high-priority tasks to forcibly acquire resources when those resources are currently occupied by low-priority tasks within resource and node groups. The computing power quota resource allocation strategy sets a fixed amount of computing resources for different users, businesses, or task groups within resource and node groups. Simultaneously, to ensure the security and performance requirements of certain specific tasks, resource exclusivity and resource sharing mechanisms can be introduced. Resource exclusivity mode allocates the entire node's resources (such as GPUs or NPUs) to a single task or tenant, ensuring stable performance. Resource sharing mode allocates resources (such as GPUs or NPUs) to multiple tasks at a granular level, with the platform scheduling to ensure resource isolation and utilization.

[0044] In this embodiment of the invention, in response to a resource request from a target user, resource matching is performed based on the share allocation requirements and the node resource information of each node managed by the target platform, and target resources are allocated to the target user. On the one hand, this allows for dynamic adjustment according to the user's actual needs and the node resource status, avoiding resource waste; on the other hand, it can quickly adapt to resource requests of different scales and types. When user needs change, resources can be quickly re-matched, efficiently meeting diverse user needs and improving resource utilization and user satisfaction.

[0045] Optionally, "matching and determining target resources from the corresponding resource groups of each target node managed by the computing power management platform based on the required allocation share for the target task" may further include the following steps: Step 301: Based on the task parameter requirements input by the target user, estimate the segmentation share requirement corresponding to the target user.

[0046] In this embodiment of the invention, when determining the resource allocation requirement for a target user, the target user may not directly indicate specific resource requirements. Instead, they can determine the resource allocation requirement by inputting task parameter requirements and having the computing power management platform estimate the required resource quantity. The task parameter requirements may include parameters such as task size (e.g., model size for a model training task), dataset size, number of iterations, and batch size. These task parameter requirements define the resource requirements of the task.

[0047] After determining the task parameter requirements, the computing power management platform can estimate the corresponding allocation share requirement for the target user based on the device parameter table (such as computing power, video memory, and bandwidth) and historical running data. The historical running data records the actual running conditions of similar tasks under different device configurations and parameter settings, including information such as the required amount of computing resources and running time. The allocation share requirement can include the amount of resources (such as the number of GPUs or NPUs) and the estimated running time.

[0048] The computing power management platform estimates computing resources based on the task parameters input by the target user, combined with equipment parameter tables and historical operating data, using specific algorithms and models. After completing the computing resource estimation, the platform determines the corresponding share requirement for the target user based on the estimation results.

[0049] For example, taking GPU / NPU number estimation as an example, the platform analyzes the impact of parameters such as model size, dataset size, number of iterations, and batch size on computational load and memory usage. It also refers to the computing power and memory capabilities of different GPUs / NPUs in the device parameter table, as well as the resource usage of similar tasks in historical running data, to comprehensively estimate the number of GPUs / NPUs required to complete the task. For instance, for a language model with 7 billion parameters and a batch size of 32, analysis shows that 4 GPUs are needed to meet its computational and memory requirements. For estimating the expected running time, the platform considers factors such as the performance of computing resources, the amount of data in the task, and computational complexity. It also refers to the running time of similar tasks under different resource configurations in historical running data to calculate the expected running time of the current task with the estimated number of GPUs / NPUs, such as an estimated 48 hours to complete training.

[0050] In one possible implementation, the computing power management platform can estimate resource requirements based on the number of parameters (total parameters QKV+MLP), key-value cache, number of resource devices, hidden layer size, and data bit width coefficient. For example, resource requirement estimation for a model inference and training scenario can be performed using the following code: function getPerformance( modelSpec: Misc.ModelSpec, gpuSpec: Misc.GPUSpec, stage: 'prefilling' | 'decoding', ): Misc.InferenceEstimationResult { / / Deconstruct all necessary parameters from the model specifications const { hiddenSize, / / Size of the hidden layer (the basic dimension of the model) seqLen, / / Sequence length (number of tokens in the input text) batchSize, / / Batch size (number of samples processed at once) intermediateSize, / / Size of intermediate layers in an MLP (hidden layer dimension of a feedforward network) llamaMlp, / / Whether to use Llama-style MLP (affects parameter calculation) nHeads, / / Number of attention heads (number of heads in a multi-head attention mechanism) nKvHeads, / / Number of attention heads in the KV cache (used for Grouped Query Attention (GQA)) slidingWindowSize, / / Sliding window size (limits the range of attention; 0 indicates no limit) dataWidth, / / Data width (1=int8, 2=fp16 / bf16, affecting memory and computation) nLayers, / / Number of Transformer layers (model depth) } = modelSpec; / / Deconstruct all necessary parameters from the GPU specification const { nDevices, / / Number of GPU devices (used for tensor parallelism) matmulFlops, / / Matrix multiplication computation power (TFLOPS, unit: times / second) vectorFlops, / / Vector operation computational power (TFLOPS, unit: operations per second) prefillingFlopsUtilization, / / Computational utilization rate during the prefilling phase (between 0 and 1) decodingFlopsUtilization, / / Computational utilization during the decoding phase (between 0 and 1) hbmUtilization, / / HBM (High Bandwidth Memory) utilization (between 0 and 1) nvlinkLatency, / / NVLink communication latency (seconds) hbmBandwidth, / / HBM bandwidth (TB / s, unit: bytes / second) nvlinkBandwidth, / / NVLink bandwidth (TB / s, unit: bytes / second) = gpuSpec; / / Calculate the MLP scaling ratio: intermediate layer size / hidden layer size const mlpExpansionRatio = intermediateSize / hiddenSize; / / Calculate MLP parameter ratios: Llama style uses 3x expansion (gate + up + down), standard style uses 2x (up + down) const mlpParamRatio = llamaMlp ? mlpExpansionRatio * 3 :mlpExpansionRatio * 2; / / Initialize the actual computing power as the base computing power let actualMatmulFlops = matmulFlops; let actualVectorFlops = vectorFlops; / / If int8 quantization is used (dataWidth=1), the computing power doubles (because int8 is twice as fast as fp16). if (dataWidth === 1) { actualMatmulFlops *= 2; actualVectorFlops *= 2; } / / Calculate the QKV projection parameters: 4 times the square of the hidden layer dimension (one copy each for Q, K, and V, and one copy for the output projection). const qkvProjParams = 4 * hiddenSize * hiddenSize; / / Calculate the number of MLP parameters: MLP parameter ratio * squared hidden layer dimension const mlpParams = mlpParamRatio * hiddenSize * hiddenSize; / / Calculate the total number of parameters for each layer (QKV + MLP) const totalParams = qkvProjParams + mlpParams; / / Calculate the compression ratio of GQA (Grouped Query Attention): number of query heads / number of key-value heads const gqaCompressionRatio = nHeads / nKvHeads; / / Calculate the actual sequence length used for attention: if a sliding window is used, take the minimum of the window size and the sequence length. const attentionSeqLen = slidingWindowSize ? Math.min(seqLen,slidingWindowSize) : seqLen; / / Calculate the sequence length required for the KV buffer: the pre-padding stage uses the complete sequence, and the decoding stage uses the attention sequence length. const kvSeqLen = stage === 'prefilling' ? seqLen : attentionSeqLen; / / Calculate KV cache size: Hidden dimension * KV sequence length * Batch size * 2 (one copy each for K and V) / GQA compression ratio const kvCacheSize = (hiddenSize * kvSeqLen * batchSize * 2) / gqaCompressionRatio; / / Calculate the length of the feature sequence: the decoding stage processes only 1 token at a time, while the pre-padding stage processes the entire sequence. const featureSeqLen = stage === 'decoding' ? 1 : seqLen; / / Calculate the total size of intermediate features (considering communication and activation storage in tensor parallelism) / / Formula explanation: Hidden dimension * Feature sequence length * Batch size * (1 + 3 / Number of devices + 1 + 4 / Number of devices) / / This includes: input activation (1) + attention intermediate results (3 / n) + attention output (1) + MLP intermediate results (4 / n) const featureSize = hiddenSize * featureSeqLen * batchSize * (1 + 3 / nDevices + 1 + 4 / nDevices); / / Communication overhead for Tensor Parallel Computation (TP): Hidden Dimension * Feature Sequence Length * Batch Size * 2 Communication Steps * (Number of Devices - 1) / Number of Devices / / The two communications include: gather before all-reduce and scatter after all-reduce. const tpCommunication = (hiddenSize * featureSeqLen * batchSize * 2 *(nDevices - 1)) / nDevices; / / MoE (Expert Hybrid) traffic is half that of TP traffic (defined here but not used) const moeCommunication = tpCommunication / 2; / / Initialize vector operations to 0 let vectorComputation = 0; / / The decoding stage requires vector operations (calculation of attention scores and softmax, etc.) if (stage === 'decoding') { / / Vector computation complexity = Hidden dimension * Attention sequence length * 4 types of operations * Batch size / / The four operations include: QK dot product, softmax, attention weight application, and subsequent normalization. vectorComputation = hiddenSize * attentionSeqLen * 4 * batchSize; } / / Declare variables for matrix multiplication computation let matmulComputation: number; / / Computational cost of the pre-filling stage if (stage === 'prefilling') { / / Pre-filling stage = Number of parameters * 2 (forward and backward) * Sequence length * Batch size + QK^T matrix multiplication of attention / / First item: Matrix multiplication of all linear layers (QKV projection + output projection + MLP) / / Second item: Q * K^T operation in the attention mechanism matmulComputation = totalParams * 2 * featureSeqLen * batchSize + hiddenSize * seqLen * attentionSeqLen * 4 * batchSize; } else { / / The decoding phase processes only one token; computational cost = number of parameters * 2 * batch size matmulComputation = totalParams * 2 * batchSize; } / / Select the corresponding computing power utilization rate based on the stage. const flopsUtilization = stage === 'decoding' ? decodingFlopsUtilization :prefillingFlopsUtilization; / / Calculate the pure computation time (excluding memory I / O) / / Computation time = (Matrix multiplication operations / (Utilization * Matrix computing power) + Vector operations / (Utilization * Vector computing power)) / Number of devices / / Dividing by the number of devices is because tensor parallelism is used. const computeTime = (matmulComputation / (flopsUtilization * actualMatmulFlops) + vectorComputation / (flopsUtilization * actualVectorFlops)) / nDevices; / / Calculate memory usage for a single GPU / / Memory usage = ((Number of parameters + KV cache) / Number of devices + Intermediate activation) * Data bit width coefficient / / Parameters and key-value caches are sharded across devices, and activations have a complete copy on each device. const memoryUsage = ((totalParams + kvCacheSize) / nDevices + hiddenSize * featureSeqLen* batchSize) * (dataWidth === 2 ? 2 : 1); In addition to estimating resource requirements, the computing power management platform can also estimate information such as HBM (High Bandwidth Memory) I / O time, NVLink communication time, total latency, and throughput. / / Calculate HBM (High Bandwidth Memory) I / O time / / IO time = ((parameters + KV cache) / number of devices + feature data * 2 (read + write)) / (HBM bandwidth * utilization) * data bit width coefficient const hbmIoTime = (((totalParams + kvCacheSize) / nDevices + featureSize * 2) / (hbmBandwidth * hbmUtilization)) * (dataWidth === 2 ? 2 : 1); / / Calculate NVLink communication time / / Communication time = (Data volume / NVLink bandwidth) * Data width factor + Communication delay let nvlinkTime = (tpCommunication / nvlinkBandwidth) * (dataWidth ===2 ? 2 : 1) + nvlinkLatency; / / Calculate total latency: (Computation time + Memory I / O time + Communication time) * Number of layers / / Each floor needs to go through these three steps, so multiply by the number of floors const latency = (computeTime + hbmIOTime + nvlinkTime) * nLayers; / / Calculate throughput: The initial value is the reciprocal of the latency (number of batches processed per second). Let throughput = 1 / latency; / / Adjust throughput units according to stage if (stage === 'prefilling') { / / Pre-population phase: Throughput = tokens / second (batch / second * number of tokens per batch) throughput *= seqLen; } else { / / Decoding phase: Throughput = tokens / second (batch / second * batch size, because 1 token is generated for each sample in each batch) throughput *= batchSize; } Finally, the computing resource platform can output the overall performance estimate results corresponding to the task input by the target user, for example: / / Return performance estimation results return { memoryUsage: memoryUsage / 1e9, / / Memory usage converted to GB computeTime: computeTime * 1000 * nLayers, / / Convert computation time to milliseconds and multiply by the number of layers hbmIoTime: hbmIoTime * 1000 * nLayers, / / HBM IO time converted to milliseconds and multiplied by the number of layers nvlinkTime: nvlinkTime * 1000 * nLayers, / / Convert NVLink time to milliseconds and multiply by the number of layers latency: latency * 1000, / / Total latency converted to milliseconds throughput, / / Throughput (tokens / second) }; } It is understood that the above code content is only a code example of the resource requirement estimation process, and can be adjusted according to actual needs. This embodiment of the invention does not limit the code content.

[0051] Step 302: Based on the required allocation share and the node resource information of each node managed by the computing power management platform, perform resource matching to obtain the matching result.

[0052] It is understandable that step 302 is implemented in a similar way to step 202, and will not be described in detail here.

[0053] Step 303: Based on the matching result, determine the target resources to be allocated to the target user; the target resources include at least one resource group in at least one node.

[0054] It is understandable that the implementation of step 303 is similar to that of step 203, and will not be repeated here.

[0055] In this embodiment of the invention, by estimating the corresponding share requirement of the target user based on the task parameter requirements input by the target user, and then determining the target resources according to the share requirement, it is possible to avoid R&D personnel blindly applying for too many resources due to insufficient experience or inadequate consideration. Resource estimation assists R&D personnel in scientifically applying for resources, thereby enabling the computing power management platform to efficiently allocate resources and greatly improving the utilization rate of resources in the computing power management platform.

[0056] Optionally, the strategy and scheduling mapper can also be used to: create a task queue corresponding to any subtask included in the target task; allocate specified resources to the task queue according to the priority of the subtask and the remaining available resources corresponding to the target task; the specified resources are used by the task processing personnel who execute the subtask.

[0057] In this embodiment of the invention, the target resources can be further divided based on the target resources. The target resources allocated to a target user can be used to execute multiple tasks. Accordingly, tasks can be classified according to attributes such as type, priority, and business domain, and a task queue corresponding to each task can be created. For example, in a model training and inference scenario, image recognition training tasks can be classified into one category, and natural language processing inference tasks into another category, with a corresponding task queue created for each category of tasks.

[0058] For each created task queue, designated resources can be assigned to it. These designated resources can be a portion or all of the target resources; the specific amount of resources allocated to a task queue depends on the size and requirements of the tasks within the queue. These designated resources are specifically for the task handlers executing the tasks corresponding to that task queue. These task handlers can be tenant personnel, developers, etc. When executing tasks, task handlers can directly access the resources allocated to their authorized task queues without needing to request additional resources, thus improving the efficiency and convenience of task execution.

[0059] In this embodiment of the invention, multiple task queues corresponding to different tasks are created based on target resources, enabling the categorized management of different tasks. Then, a designated resource is allocated to each task queue, allowing for stable computing power support for tasks through the target resources under a unified strategy, ensuring stable task scheduling and operation. This avoids resource allocation chaos, enables rapid and efficient utilization of dedicated resources, reduces operational fluctuations caused by resource contention, and improves overall task execution efficiency and service quality.

[0060] Optionally, the strategy and scheduling mapper can also be used to adjust the resource composition of the target resource when the target resource corresponding to the target task reaches the resource usage threshold.

[0061] In this embodiment of the invention, the usage of the target resource can be continuously monitored during its operation. Monitoring indicators may include, but are not limited to, resource utilization rate (the proportion of resources used within a specific time period), temperature (heat generated during resource operation), and failure rate (the frequency of failures when the resource performs tasks). When any monitoring indicator reaches a pre-set resource usage threshold, it can be determined that the target resource has reached the resource usage threshold.

[0062] Subsequently, the resource composition of the target resource can be adjusted according to preset adjustment rules and strategies. The preset adjustment rules and strategies can be set according to actual needs. For example, the adjustment methods can include scaling up or down, that is, increasing (expanding) or decreasing (shrinking) the number of certain components in the target resource, such as increasing the number of GPUs to improve computing power, or reducing idle GPUs to save resources; and relocation, that is, migrating some or all of the components in the target resource to other suitable nodes or locations to optimize resource layout and performance.

[0063] In this embodiment of the invention, when the resource usage threshold is reached, it indicates that the current resource composition is insufficient to meet the demand or that there is an operational risk. Flexible adjustment of the resource composition based on real-time conditions can promptly address various changes, avoid resource waste or insufficiency, ensure the stable and efficient operation of target resources, and adapt to business needs in different scenarios.

[0064] Optionally, "automatically determining the node resource profile corresponding to any target node managed in the computing power management platform" may include the following steps: Step 401: Obtain the resource type, resource quantity, resource capacity, resource version, and resource partitioning capability corresponding to the target node.

[0065] In this embodiment of the invention, assuming the target platform has already managed and controlled the target node, the target platform can automatically obtain the resource model, resource quantity, resource capacity, resource version, and resource partitioning capability corresponding to the target node. The target platform can collect relevant information about the target node through built-in detection tools and interaction interfaces with the node's hardware and software systems. For example, the target platform can obtain detailed information such as the GPU card model and memory capacity by calling the SDK (Software Development Kit) provided by the GPU card manufacturer.

[0066] Step 402: Based on the resource type, resource quantity, resource capacity, resource version, and resource partitioning capability corresponding to the target node, generate a description tag for the target node.

[0067] In this embodiment of the invention, after successfully obtaining relevant information such as the resource model, resource quantity, resource capacity, resource version, and resource partitioning capability corresponding to the target node, corresponding descriptive tags are generated for different preset dimensions. These preset dimensions are classification standards pre-defined according to actual management needs and application scenarios, such as performance dimensions, functional dimensions, and compatibility dimensions. Descriptive tags may include "sharing mode," "number of partitions," and "overselling ratio," etc.

[0068] Step 403: Determine the multiple description tags as the node resource profile corresponding to the target node.

[0069] In this embodiment of the invention, multiple descriptive tags are integrated and summarized to determine the node resource profile corresponding to the target node. The node resource profile is a comprehensive and structured description of the resource characteristics of the target node. The descriptive tags are interconnected and complementary, jointly representing the specific situation of the target node resources. For example, the node resource profile of the target node may include multiple descriptive tags such as "NVIDIA A100 model - 4 units - 40GB of video memory per unit - latest driver version supports 8 vGPU partitions".

[0070] In this embodiment of the invention, by using descriptive tags to abstract heterogeneous capabilities and shielding underlying differences, the target platform can clearly understand the resource status of the target node, providing a basis for subsequent resource allocation, scheduling and management decisions, and ensuring that resources can be used reasonably and efficiently.

[0071] Optionally, "based on the node resource profile, dividing the node resources of the target node to obtain multiple resource groups corresponding to the target node" may include the following steps: Step 501: Based on the node resource profile and threshold matching rules, determine the target segmentation parameters corresponding to the node resources of the target node.

[0072] In this embodiment of the invention, after obtaining the node resource profile of the target node, the node resources of the target node are divided. The threshold matching rule can be a pre-set set of conditions, which sets different rule standards for different indicators in the node resource profile. For example, for memory utilization, the threshold range can be set to 70%-90%. When the node resource profile shows that the memory utilization of the target node is within this range, it indicates that the current memory usage is relatively stable and there is a certain allocation space. Alternatively, different preset partitioning parameters are set according to the different resource models in the node resource profile. For example, the preset partitioning parameters for GPU model A are: 3 partitions, each partition corresponding to a memory quota of 2GB and a computing power quota of 10% of the original computing power; the preset partitioning parameters for GPU model B are: 5 partitions, each partition corresponding to a memory quota of 10GB and a computing power quota of 20% of the original computing power.

[0073] Based on node resource profiles and threshold matching rules, the system performs complex calculations and analyses. Taking GPU resources as an example, the system comprehensively considers factors such as the resource's computing power, memory capacity, temperature, and current utilization rate. For instance, if the node resource profile shows that a certain resource has strong computing power and its memory utilization rate is within a reasonable threshold, the system will issue target partitioning parameters for that GPU resource. Target partitioning parameters may include the number of partitions (e.g., dividing a single GPU into 8 parts), the corresponding memory quota for each part (e.g., allocating 2GB of memory to each part), and the computing power quota (e.g., allocating 10% of the original computing power to each part), etc.

[0074] In one possible implementation, the target segmentation parameter can also be flexibly assigned by the user. Specifically, the user-input segmentation parameter can be received and directly determined as the target segmentation parameter.

[0075] Step 502: Based on the target segmentation parameters, configure the node resources of the target node to obtain multiple resource groups.

[0076] In this embodiment of the invention, the system performs actual configuration operations on the node resources of the target node according to the number of partitions specified in the target partitioning parameters, thereby obtaining multiple resource groups. For each resource group, the system performs detailed configuration according to the video memory quota and computing power quota specified in the target partitioning parameters. For example, taking the target partitioning parameters specifying that the video memory of a GPU card is divided into 12 equal parts, each 4GB, as an example, the target platform can reorganize and allocate the GPU card resources according to the target partitioning parameters using resource management tools and algorithms. The physical GPU resources are virtualized into 12 independent virtual GPU (vGPU) units, each vGPU unit corresponding to a resource group, and each resource group has a fixed video memory and computing power quota. During the configuration process, the system ensures that the resource allocation meets the requirements of the target partitioning parameters, guarantees the independence and stability between each resource group, and ensures that the resource group can only run based on the specified video memory and computing power resources in actual operation.

[0077] In this embodiment of the invention, by using node resource profiling and threshold matching rules, it can be ensured that the segmentation parameters can fully utilize node resources without causing resource performance degradation or system instability due to excessive segmentation. Simultaneously, configuring node resources based on target segmentation parameters allows resource groups to be uniformly managed and allocated to different services or users, achieving refined resource management and efficient utilization.

[0078] In one possible implementation, the computing power management platform can be used to implement the following resource management method: generating a management instruction based on a template of instructions to be filled and input parameters; running the management instruction on a target node, causing the computing power management platform to manage the target node; automatically determining the node resource profile corresponding to any target node managed by the computing power management platform; dividing the node resources of the target node based on the node resource profile to obtain multiple resource groups corresponding to the target node; matching and determining target resources from the corresponding resource groups of each target node managed by the computing power management platform based on the required allocation share of the target task, and allocating the target resources to the target task. In this way, by automatically generating and running the management instruction based on the template of instructions to be filled and input parameters, one-click management of target nodes is achieved, eliminating the need for complex manual operations, reducing labor costs and experience barriers, and improving management efficiency. Meanwhile, based on the node resource profile, resources are divided into multiple fine-grained resource groups and incorporated into unified scheduling, avoiding resource waste caused by manual configuration errors, effectively improving resource utilization, and completing the entire process of resource "management-segmentation-scheduling-use" in a unified and efficient manner, thereby improving resource management efficiency and quality, and enhancing system stability and flexibility.

[0079] For example, the following is an example of resource allocation by a computing power management platform: Node Access: The new node node01 is equipped with 8 GPUs. After executing the access script, the node will automatically join the computing power cluster of the computing management platform and be assigned to resource group B.

[0080] Resource allocation: The tenant administrator sets resource group B to shared mode and assigns it to tenant A. Specifically, 3 GPUs are designated for model training, 1 GPU for model inference, and the remaining GPUs are dynamically allocated based on task requirements.

[0081] Task execution: Tenant A's R&D personnel submitted a BERT model training task. The computing power estimator recommended using two GPUs based on the task requirements, and the scheduler allocated GPU0 and GPU1 accordingly for the training task.

[0082] Meanwhile, the researchers submitted an inference task, requesting the use of one GPU. Because the inference task has a higher priority, the scheduler paused part of the training process and allocated GPU2 to the inference task.

[0083] Monitoring and Alerts: During task execution, the computing power management platform continuously collects various GPU metrics. When the GPU temperature exceeds 90°C, the system immediately issues an alert and recommends migrating the current task.

[0084] The present invention also provides an electronic device, see [link to relevant documentation]. Figure 3 It includes: a processor 601, a memory 602, and a computer program 6021 stored in the memory and executable on the processor. When the processor executes the program, it implements the computing power management platform of the foregoing embodiments.

[0085] The present invention also provides a readable storage medium, wherein when the instructions in the storage medium are executed by the processor of an electronic device, the electronic device is able to execute the computing power management platform of the foregoing embodiments.

[0086] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0087] The algorithms and displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, this invention is not directed to any particular programming language. It should be understood that the contents of the invention described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of the invention.

[0088] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0089] Similarly, it should be understood that, in order to simplify the invention and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof. However, this disclosure should not be construed as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into this detailed description, wherein each claim itself is a separate embodiment of the invention.

[0090] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0091] The various component embodiments of the present invention can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some or all of the components in the sorting device according to the present invention. The present invention can also be implemented as a device or apparatus program for performing part or all of the methods described herein. Such a program implementing the present invention can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0092] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

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

[0094] It should be noted that all actions involving the acquisition of signals, information, or data in this application are carried out in compliance with the relevant data protection laws and policies of the country where the application is located, and with the authorization granted by the owner of the relevant device. The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0095] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A computing power management platform, characterized in that, The computing power management platform comprises a resource abstraction and profiler, a resource segmentation controller, and a strategy and scheduling mapper. The resource abstraction and profiler is configured to automatically determine a node resource profile corresponding to any target node in the computing power management platform. The resource segmentation controller is configured to divide the node resources of the target node based on the node resource profile to obtain a plurality of resource groups corresponding to the target node. The strategy and scheduling mapper is configured to match and determine target resources from the corresponding resource groups of each target node in the computing power management platform based on the segmentation share requirement of a target task, and allocate the target resources to the target task.

2. The computing power management platform of claim 1, wherein, The computing power management platform further comprises a pipeline instruction generator. The pipeline instruction generator is configured to generate pipeline instructions according to a to-be-filled instruction template and input parameters, and the pipeline instructions are configured to run on a target node so that the computing power management platform pipelines the target node.

3. The computing power management platform of claim 1, wherein, The matching and determining of the target resources from the corresponding resource groups of each target node in the computing power management platform based on the segmentation share requirement of a target task comprises: In response to a resource request operation of a target user, determining a segmentation share requirement of the target user based on a resource requirement indicated by the resource request operation; Performing resource matching based on the segmentation share requirement and node resource information of each node in the computing power management platform to obtain a matching result; Determining target resources allocated to the target user based on the matching result; the target resources comprise at least one resource group in at least one node.

4. The computing power management platform of claim 1, wherein, The matching and determining of the target resources from the corresponding resource groups of each target node in the computing power management platform based on the segmentation share requirement of a target task further comprises: Estimating a segmentation share requirement of a target user based on a task parameter requirement input by the target user; Performing resource matching based on the segmentation share requirement and node resource information of each node in the computing power management platform to obtain a matching result; Determining target resources allocated to the target user based on the matching result; the target resources comprise at least one resource group in at least one node.

5. The computing power management platform of claim 1, wherein, The strategy and scheduling mapper is further configured to: Create a task queue corresponding to any subtask contained in the target task; Allocate specified resources to the task queue according to the priority of the subtask and the remaining available resources corresponding to the target task; the specified resources are used by a task handler for executing the subtask.

6. The computing power management platform of claim 1, wherein, The strategy and scheduling mapper is further configured to: Adjust the resource composition of the target resources if the target resources corresponding to the target task reach a resource usage threshold.

7. The computing power management platform of claim 1, wherein, The automatic determination of a node resource profile corresponding to any target node in the computing power management platform comprises: Obtaining a resource model, a resource quantity, a resource capacity, a resource version, and a resource segmentation capability corresponding to the target node; generating a description label for the target node based on the resource type, resource quantity, resource capacity, resource version, and resource splitting capability corresponding to the target node; determining the plurality of description labels as the node resource image corresponding to the target node. 8.The computing power management platform of claim 1, wherein, The dividing of the node resource of the target node based on the node resource image includes: determining a target splitting parameter corresponding to the node resource of the target node based on the node resource image and a threshold matching rule; configuring the node resource of the target node based on the target splitting parameter to obtain a plurality of resource groups.

9. An electronic device, comprising: including: a processor, a memory, and a computer program stored on the memory and executable on the processor, wherein the processor executes the program to implement the computing power management platform of any one of claims 1-8.

10. A readable storage medium, characterized by, When the instructions in the storage medium are executed by the processor of the electronic device, the electronic device can execute the computing power management platform of any one of claims 1-8.

Images