Data center resource integrated scheduling and transaction platform facing ai computing power demand

Abstract

The application discloses an AI computing power demand-oriented data center resource integrated scheduling and transaction platform, and relates to the technical field of distributed computing and resource scheduling; comprising a resource access layer, a core platform layer, a blockchain network layer and an application interaction layer. The resource access layer contains a resource adapter; the core platform layer contains an AI job perception and analysis engine, a global intelligent scheduler, a blockchain middleware and a billing engine, wherein the AI engine adopts a domain fine-tuning large model to perform chain reasoning on natural language demand, generates a structured resource specification list, the scheduler generates a resource allocation scheme according to a multi-objective optimization algorithm, and the blockchain middleware realizes assetization evidence and trusted transaction of computing power NFT; the blockchain network layer is a permissioned chain network, used for storing power digital identity, usage proof and executing smart contracts, through the cooperation of each layer, an integrated closed-loop service process is formed, the AI computing power use threshold is significantly reduced, and the resource utilization is improved.

Description

Technical Field

[0001] This invention relates to the field of distributed computing and resource scheduling technology, specifically to an integrated data center resource scheduling and trading platform for AI computing power needs. Background Technology

[0002] With the rapid development of artificial intelligence technology, computing power has become a key infrastructure supporting the development of the digital economy. Currently, the supply and allocation of computing power resources mainly rely on the following technical models, all of which have significant shortcomings: 1. The static partition scheduling mode within a single data center adopts an independent resource management system with fixed scheduling strategies. It can only perceive basic indicators such as the number of CPU cores and memory size, and cannot understand the semantic meaning of AI tasks, resulting in generally low resource utilization and serious waste of computing power. 2. The public cloud on-demand leasing model is costly and difficult to sustain for long-term training; users rely on specific cloud platform technology stacks, leading to vendor lock-in; and the billing mechanism lacks transparency. 3. The basic computing power trading platform model only provides a simple resource list display. The trading parties need to communicate and negotiate prices, verify resources and settle accounts themselves, resulting in high transaction friction and low efficiency. It lacks technical guarantees for the authenticity of resources and the measurement of usage, and the trust mechanism is lacking. The functions are limited and it is not integrated with the underlying job scheduling, resulting in a fragmented user experience.

[0003] Existing intent parsing solutions require users to fill out formatted requirement forms, which cannot understand vague intents described in natural language. The scheduling optimization objectives are singular, and a multi-objective collaborative optimization model has not been formed. Existing blockchain computing power trading solutions focus on transaction record storage, do not involve large-scale model intent parsing, and have limited scheduling intelligence.

[0004] In summary, existing technologies suffer from the following core pain points: resource misallocation and waste lead to low computing power utilization efficiency; insufficient scheduling intelligence prevents intention-driven global optimization of resource matching; and lack of transaction trust and transparency restricts the formation and development of the computing power market.

[0005] Therefore, how to build a computing infrastructure operation platform that can realize semantic awareness of computing resources, cross-domain global optimization scheduling, and trusted automated transactions has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0006] The purpose of this invention is to provide an integrated scheduling and trading platform for data center resources that meets AI computing power requirements, in order to solve the problems mentioned in the background art.

[0007] To solve the above-mentioned technical problems, the present invention provides the following technical solution: An integrated data center resource scheduling and trading platform for AI computing power needs, including: The resource access layer includes resource adapters deployed at each computing power provider to shield the differences in heterogeneous infrastructure and achieve standardized access and state synchronization of computing power resources. The core platform layer includes an AI job perception and analysis engine, a global intelligent scheduler, blockchain middleware, and a billing and settlement engine, among which: The AI ​​job perception and parsing engine is used to parse the natural language computing power requirements submitted by users into a structured list of executable resource specifications. The global intelligent scheduler is connected to the AI ​​job perception and analysis engine and is used to generate a resource allocation scheme based on the list of executable resource specifications. The blockchain middleware is connected to the global intelligent scheduler, the billing and settlement engine, and the blockchain network layer, respectively, and is used to realize the asset-based storage and trading of computing resources. The billing and settlement engine is connected to the blockchain middleware and is used to complete fund transfers based on smart contracts. The blockchain network layer, a permissioned blockchain network, is used to store the digital identity of computing power resources, record proof of usage, and execute smart contracts. The application interaction layer is used to provide the user interface.

[0008] The resource access layer, core platform layer, blockchain network layer, and application interaction layer work together to form an integrated closed-loop service process, from natural language request submission, intelligent parsing, global scheduling, resource locking, automatic environment deployment, reliable job execution, usage on-chain storage, to automatic settlement of smart contracts.

[0009] Furthermore, the AI ​​task perception and analysis engine specifically includes: The domain fine-tuning large model module uses efficient parameter fine-tuning technology to fine-tune the instructions of the general large language model, and injects domain knowledge including hardware performance parameters, AI framework dependencies and task resource patterns into the general large language model to obtain the domain fine-tuning large model; The chained reasoning module is connected to the domain fine-tuning large model module. It calls the domain fine-tuning large model to perform step-by-step reasoning on natural language requirements, including task type identification, computational load estimation, parallel strategy planning, cost constraint fusion, and generation of an executable resource specification list.

[0010] Furthermore, the chain reasoning module includes: The requirement structuring and intent understanding unit is used to preprocess the natural language requirements input by users, including spelling correction, terminology unification, and entity and constraint extraction. It also categorizes the processed requirements into predefined task prototype categories and outputs the task type, the number of parameters of the target AI model, the dataset size, and user constraints. The computational load estimation unit, connected to the demand structuring and intent understanding unit, is used to estimate the total computational load of the task based on the number of parameters, dataset size, and task type of the target AI model output by the demand structuring and intent understanding unit, and by calling the hardware performance data and algorithm efficiency empirical coefficients stored in the internally integrated knowledge graph. A parallel strategy planning unit, connected to the computational load estimation unit, is used to automatically plan a parallel strategy based on the estimated total computational load and user constraints, specifically including: The memory constraint analysis subunit is used to estimate the minimum video memory requirement based on the number of parameters of the target AI model and the optimizer state. It is then compared with the available video memory of a single card in the knowledge graph. If the minimum video memory requirement exceeds the video memory of a single card, it is determined that model parallelism must be used, and the degree of model parallelism is determined. The time constraint analysis subunit is used to deduce the minimum data parallelism granularity required to meet the time constraints based on the total computational load, the user's expected time window, and the estimated effective computing power utilization of the cluster, and to determine the data parallelism. The communication requirements analysis subunit is used to calculate the minimum required inter-node interconnect bandwidth and network latency requirements based on the determined model parallelism and data parallelism, combined with the model fragment size of the target AI model, using the communication cost model. The resource quantification and specification generation unit is connected to the computational load estimation unit and the parallel strategy planning unit, respectively. It is used to reverse-calculate the required number and model of GPUs based on the total computational load, single-card computing power, expected completion time and cluster efficiency experience value. Combined with the model parallelism, data parallelism, interconnect bandwidth and network latency requirements output by the parallel strategy planning unit, it determines the memory, storage IOPS and software environment dependencies required for each node. Finally, it generates a structured executable resource specification list containing computing resources, software environment, storage requirements and service level agreement requirements.

[0011] A target AI model refers to a specific artificial intelligence model submitted by a user through natural language requirements, which needs to perform training or inference tasks on computing resources, such as a large language model or an image generation model. Domain-fine-tuned large model refers to a large language model deployed in the AI ​​job perception and parsing engine and fine-tuned by domain knowledge injection, used to understand user needs and generate resource specification lists; Model parallelism refers to the number of parts that the target AI model is divided into under a model parallel strategy; Data parallelism refers to the number of copies of the target AI model under a data parallelism strategy; Furthermore, the global intelligent scheduler specifically includes: The dynamic resource profiling module is used to maintain real-time profiling vectors for each computing power node, including static attributes, dynamic indicators, economic and environmental attributes, and data locality. in: The static attributes include at least the GPU model, number of GPUs, number of CPU cores, memory capacity, storage type and capacity, and network bandwidth; The dynamic indicators include at least real-time utilization, available capacity, and health status. The economic and environmental attributes include at least the unit time calculation cost, real-time electricity price, and carbon emission factor; The data locality includes at least the cache identifier of public datasets or user private data on that node or in adjacent storage.

[0012] The candidate resource set initial screening module, connected to the dynamic resource profile construction module, is used to screen eligible resource nodes or resource combinations from the global resource pool based on the hard constraints of the operation, forming a candidate set. in: The hard constraints include at least the minimum requirements for GPU model, number of GPUs, memory, and network bandwidth. For single-node tasks, select the single resource node that meets all hard constraints; For multi-node tasks, heuristic search or graph-based resource group search algorithms are used to find resource combinations from the initial screening nodes that meet the total resource requirements and the network performance between nodes meets the requirements for parallel communication.

[0013] The multi-objective optimization module, connected to the candidate resource set initial screening module, is used to evaluate each candidate scheme according to a preset multi-objective scoring function and generate a comprehensive score. The constraint checking module, connected to the multi-objective optimization module, is used to verify the resource conflict, data compliance and service level agreement satisfaction of candidate solutions. The decision output module, connected to the constraint checking module, is used to select the candidate scheme with the best comprehensive score from the candidate schemes that have passed the constraint check as the recommended scheduling scheme.

[0014] Furthermore, the multi-objective scoring function used by the multi-objective optimization module is: in, , , , Here, represents the weighting coefficients, and Normalize is the normalization function. Cost(c) is the total computing cost, which includes resource rental fees, electricity costs, and data transmission fees; Time(c) is the estimated job completion time, which includes computation time, data loading time, and queuing delay. Power(c) represents energy consumption; Carbon(c) represents carbon emissions.

[0015] Furthermore, the global intelligent scheduler also includes a weight configuration module, connected to the multi-objective optimization module, used to dynamically configure the weight coefficients in the multi-objective scoring function; the weight configuration module specifically includes: The strategy template unit stores preset weight configuration templates, including at least cost-priority mode, time-priority mode, green and low-carbon mode, and balanced mode. , , , It has predefined default values; The learning recommendation unit, connected to the strategy template unit, is used to collect the resource allocation schemes finally confirmed in the user's historical scheduling requests and construct a user preference dataset. Based on the user preference dataset, a collaborative filtering algorithm or reinforcement learning model is used to mine the user's preference features for four objectives: cost, time, energy consumption, and carbon emissions, and to provide a personalized recommendation weight coefficient combination for the current user. When using a reinforcement learning model, the task type, budget range, time requirement, and resource specifications of the user's historical requests are used as state features, the discrete values ​​or continuous adjustments of the weight coefficient combination are used as optional actions, and the user's final confirmation of the scheduling scheme is used as a positive reward signal. The weight recommendation strategy is trained based on historical interaction data. The state-aware driving unit is used to acquire real-time operational status information of the global resource pool, including fluctuations in node electricity prices, changes in carbon emission factors, and resource scarcity. It dynamically adjusts weight coefficients according to a preset state-weight mapping rule. This state-weight mapping rule uses a finite state machine model and includes at least the following: increasing the cost weight when a local grid electricity price is detected to be higher than a preset threshold. When the node's carbon emission factor exceeds a preset threshold, the carbon emission weight is increased. When the amount of interstitial resources in the global resource pool is lower than a preset threshold, the weights are adjusted to prioritize matching idle resources. The weight normalization unit, connected to the policy template unit, learning recommendation unit, and state-aware driving unit, is used to normalize the generated weight coefficient combination to ensure... + + + = 1, and output the normalized weight coefficients to the multi-objective optimization module; The constraint boundary unit, connected to the weight normalization unit, is used to set an adjustable safety range for each weight coefficient to prevent the weight coefficient from exceeding a reasonable range during dynamic adjustment.

[0016] Furthermore, the blockchain middleware specifically includes: The computing power NFT management module is used to encapsulate computing power resources into standardized computing power non-fungible tokens. The metadata of the computing power NFT includes standardized description information of computing power resources, available time period information and supplier digital signature, and the hash value of the metadata is stored on the blockchain. The evidence storage interface module is used to receive the usage proof generated by the resource adapter and forward it to the blockchain network layer for evidence storage; The smart contract triggering module is used to call smart contracts deployed in the blockchain network layer to perform resource locking, fund collateralization and settlement operations; The blockchain middleware, in collaboration with the AI ​​job perception and analysis engine, the global intelligent scheduler, and the resource access layer, realizes a complete data flow from natural language requirements to NFT locking, specifically including: After receiving the computing power request submitted by the user in natural language, the application interaction layer transmits the natural language request text to the AI ​​job perception and parsing engine; the AI ​​job perception and parsing engine performs chain reasoning on the natural language request to generate a structured executable resource specification list containing computing resource specifications, software environment dependencies, storage requirements and service level agreement requirements, and sends the structured executable resource specification list to the global intelligent scheduler. After receiving the structured executable resource specification list, the global intelligent scheduler synchronously obtains the real-time status data of the global resource pool from the resource access layer, and performs multi-objective optimization scheduling decisions based on the structured executable resource specification list to generate a resource allocation scheme that includes the target computing power resource identifier, the expected time period to be occupied, and the estimated cost; the global intelligent scheduler presents the resource allocation scheme to the user for confirmation through the application interaction layer. After receiving the user's confirmation instruction for the resource allocation scheme, the application interaction layer sends the confirmation information and the resource allocation scheme to the smart contract triggering module of the blockchain middleware. The smart contract triggering module parses the resource allocation scheme, extracts the target computing power resource identifier and the expected occupation period contained therein, and queries the computing power NFT management module for the corresponding computing power NFT and its current status based on the target computing power resource identifier. If the computing power NFT is tradable, the smart contract triggering module calls the locking smart contract deployed in the blockchain network layer, submitting the unique identifier of the computing power NFT, the demander's account address, the budget amount, and the occupation period as input parameters to the locking smart contract. After the locking smart contract is executed, the status of the computing power NFT is updated to locked, and the lock transaction hash is returned to the smart contract triggering module. After receiving the lock success response, the smart contract triggering module calls the fund collateral smart contract deployed in the blockchain network layer to transfer the demander's budget amount from the demander's account to the smart contract escrow account, and returns the collateral success information to the application interaction layer. After receiving the successful mortgage information, the application interaction layer sends the deployment instruction and the resource allocation scheme to the corresponding target computing power resource adapter in the resource access layer, triggering the automatic deployment of the job environment.

[0017] Furthermore, the resource adapter is also used for: During the execution of the operation, resource usage indicators are continuously collected, and usage proofs containing usage data, timestamps and resource identifiers are periodically generated. The usage proofs are digitally signed and then sent to the blockchain middleware.

[0018] Furthermore, the billing and settlement engine is specifically used for: By setting transaction prices and settlement rules through smart contracts, the system automatically reads the usage proof data stored on the blockchain after the operation is completed, transfers funds from the demand side's account to the supply side according to the actual usage and preset rules, and returns the remaining funds to the demand side.

[0019] Compared with the prior art, the beneficial effects achieved by the present invention are: This invention achieves the following beneficial effects through the collaborative work of the resource access layer, core platform layer, blockchain network layer, and application interaction layer: Based on a domain-fine-tuned large model, it performs semantic perception and chain-based reasoning on natural language computing power requirements, automatically generating a structured resource specification list, significantly reducing the threshold for AI computing power usage; Through a multi-objective optimization scheduling algorithm that comprehensively considers cost, time, energy consumption, and carbon emissions, combined with dynamic resource profiling and dynamic weight configuration, it achieves global collaborative scheduling of computing power resources across regions, effectively improving resource utilization; It utilizes computing power NFTs to realize fine-grained ownership confirmation and assetization of resources, and constructs a trusted transaction and settlement system through on-chain notarization using proof-of-use and automatic execution of smart contracts; Finally, it forms an integrated closed-loop service process from demand submission, intelligent parsing, global scheduling, resource locking, environment deployment, job execution, usage notarization to automatic settlement, realizing efficient, reliable, and automated circulation of computing power resources. Attached Figure Description

[0020] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof.

[0021] Figure 1 This is a schematic diagram of the structure of the integrated data center resource scheduling and trading platform for AI computing power needs, as described in this invention. Detailed Implementation

[0022] 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 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 are within the scope of protection of the present invention.

[0023] Please see Figure 1 This invention provides an integrated data center resource scheduling and trading platform for AI computing power needs, comprising a resource access layer, a core platform layer, a blockchain network layer, and an application interaction layer.

[0024] In this embodiment, the resource access layer is deployed on the nodes of each computing power provider, including large cloud data centers, edge data centers, enterprise private GPU clusters, etc. It includes resource adapters, which encapsulate the API differences of different underlying infrastructures, such as Kubernetes, Slurm, and OpenStack. Through a unified resource abstraction model and data reporting protocol, it enables standardized access and real-time status synchronization of heterogeneous computing resources. The resource adapters periodically collect resource status information of the nodes they are on, including GPU model and quantity, CPU core count and utilization, memory capacity and availability, storage type and capacity, network bandwidth, node health status, etc., and report this information to the global intelligent scheduler of the core platform layer.

[0025] The core platform layer is the core processing unit of this invention, which includes an AI job perception and analysis engine, a global intelligent scheduler, a blockchain middleware, and a billing and settlement engine. The modules communicate with each other through standardized API interfaces to realize data flow and business collaboration.

[0026] The blockchain network layer is a permissioned blockchain network, with nodes jointly maintained by the platform operator, core computing power providers, and regulatory agencies. The blockchain network layer deploys smart contracts for the minting, trading, locking, and settlement of computing power NFTs, and serves as a distributed ledger to store the digital identity and usage proof of computing power resources.

[0027] The application interaction layer provides a user portal for computing power demanders and an operator management backend for computing power providers. The user portal supports natural language demand input, scheduling scheme display, transaction confirmation, and job monitoring; the operator management backend supports resource registration, NFT creation, transaction management, and revenue inquiry.

[0028] In this preferred embodiment, the AI ​​job perception and parsing engine is the core entry module of the present invention. Its purpose is to solve the pain points in the prior art where the scheduling system cannot understand the semantic meaning of AI jobs and users need to have profound professional knowledge to manually write complex configuration files. Through this engine, the vague requirements submitted by users in natural language are transformed into a structured resource specification list that can be understood and executed by machines, realizing a fundamental shift from users telling the system how to do something to users telling the system what to do.

[0029] The purpose of setting up the domain fine-tuning large model module is to solve the technical problem that traditional intent parsing solutions rely on rule templates or formatted forms and cannot understand vague intents described in natural language. This module performs domain fine-tuning on a general large language model, enabling it to have the professional ability to understand the computing power requirements of AI.

[0030] In practical implementation, the domain fine-tuning large model module employs efficient parameter fine-tuning techniques to fine-tune the general-purpose large language model. Domain knowledge, including hardware performance parameters, AI framework dependencies, and task resource patterns, is injected into the general-purpose large language model to obtain a domain-fine-tuned large model. The base model can be an open-source large language model such as LLaMA-2-13B, ChatGLM3-6B, or Qwen-14B, which possess a strong foundation in natural language understanding. The fine-tuning technique uses efficient parameter fine-tuning techniques such as LoRA or QLoRA. While keeping most of the parameters of the base model frozen, only a small number of injected adapter parameters are trained. Taking LoRA as an example, a low-rank adapter is added to the attention layer weight matrix of the model, reducing the number of training parameters to only 0.1% to 1% of the original model, significantly lowering the fine-tuning cost.

[0031] The training data consists of three categories: First, pairing data between AI job descriptions and corresponding YAML configurations, such as training a GPT-3 175B model and its corresponding Kubernetes YAML configuration; second, hardware performance parameter data, including computing power, memory capacity, NVLink bandwidth, PCIe bandwidth, etc., for various GPU models; and third, AI framework dependency data, including the correspondence between frameworks such as PyTorch and TensorFlow and their CUDA versions, and empirical values ​​of optimal parallel strategies for common models. The fine-tuning method combines instruction fine-tuning and thought chain technology, explicitly including intermediate inference steps in the output of the training data, enabling the model to learn to decompose vague user requirements into explicit technical parameters step by step.

[0032] The resulting domain-fine-tuned large model is deployed in the AI ​​task perception and parsing engine and is called by the chained inference module through a RESTful API interface. The average response time for each inference is controlled within three seconds.

[0033] The purpose of the chained reasoning module is to address the issue that the output of large models is often unstructured text, making it difficult to use directly for subsequent automated scheduling. This module uses structured chained reasoning to transform the output of the domain-fine-tuned large model into a standardized resource specification list that can be directly parsed by the scheduler. The chained reasoning module is connected to the domain-fine-tuned large model module, calling upon the domain-fine-tuned large model to perform step-by-step reasoning on natural language requirements, including task type identification, computational cost estimation, parallel strategy planning, cost constraint fusion, and the generation of an executable resource specification list.

[0034] The purpose of setting up the demand structuring and intent understanding units is to address the problem that user input natural language demands contain a lot of redundant information, colloquial expressions, and implicit assumptions, which need to be preprocessed before they can be accurately understood by the model.

[0035] This unit preprocesses the natural language requirements input by the user, including spelling correction, terminology standardization, and entity and constraint extraction. It then categorizes the processed requirements into predefined task prototype categories and outputs the task type, the number of parameters of the target AI model, the dataset size, and the user constraints.

[0036] In practice, the preprocessing process first corrects the spelling of user input, such as correcting GP3 to GPT-3; secondly, it unifies terminology, unifying "large model," "large language model," and "LLM" into "large language model"; then, it uses a BERT-based named entity recognition model to extract entities, identifying numerical entities such as parameter count, dataset size, budget, and time, along with their units. Predefined task prototype categories include large language model pre-training, large language model fine-tuning, image classification model training, object detection model training, and scientific computing simulation. Classification uses a text classification model to assign the preprocessed requirements to the most matching category. For example, if a user inputs "I need to train a GPT-type model with 175 billion parameters, a dataset size of approximately 1TB, a budget of 50,000 yuan, and a completion time of no more than fourteen days," the output task type for this unit would be "large language model pre-training," with the target AI model having 175 billion parameters and a dataset size of 1TB. User constraints include a budget not exceeding 50,000 yuan and a completion time not exceeding fourteen days.

[0037] The purpose of the computational load estimation unit is to address the issue that accurate computational demand estimation relies on a deep understanding of model architecture, hardware performance, and algorithm efficiency. This unit transforms abstract model parameters into concrete computational load metrics by invoking empirical coefficients stored in the knowledge graph. Connected to the demand structuring and intent understanding unit, the computational load estimation unit estimates the total computational load of the task based on the number of parameters, dataset size, and task type of the target AI model output by the demand structuring and intent understanding unit, and by invoking hardware performance data and algorithm efficiency empirical coefficients stored in the internally integrated knowledge graph.

[0038] The internally integrated knowledge graph is stored in the form of a graph database, containing three types of nodes and relationships. Hardware nodes include GPU and CPU models, with attributes such as computing power, video memory, and bandwidth; algorithm nodes include model architecture types such as Transformer and CNN, with attributes such as FLOPs per parameter and video memory usage; task nodes include pre-training, fine-tuning, and inference, with attributes such as typical iteration count and data-to-token conversion ratio. The computational cost estimation logic is based on the target AI model being a GPT-type decoder architecture. It queries the knowledge graph for the FLOPs per parameter of the Transformer decoder layer. One forward propagation requires twice the number of parameters multiplied by the sequence length, and backpropagation is approximately two to three times that of the forward propagation. Assuming a sequence length of 2048 and a batch size of 1, the estimated computational cost per iteration is approximately 8.6 x 10^14 FLOPs. Based on a dataset size of 1 TB, the knowledge graph shows a common tokenization ratio of approximately 0.25 tokens per byte, estimating the total number of tokens to be approximately 250 billion. Based on the typical training rounds of a large language model pre-training task, we assume the total number of iterations is approximately 25,000. The total computational cost is the computational cost per iteration multiplied by the total number of iterations, approximately 2.15 x 10^19 FLOPs.

[0039] The purpose of setting up the parallel strategy planning unit is to solve the problem that large-scale AI training must adopt a distributed parallel strategy. However, how to choose the optimal combination of parallelism requires comprehensive consideration of memory constraints, time constraints and communication overhead.

[0040] This unit handles different types of constraints through three sub-units, ensuring that the generated parallel strategy is both feasible and efficient. The parallel strategy planning unit is connected to the computational cost estimation unit, and automatically plans the parallel strategy based on the estimated total computational cost and user constraints.

[0041] The purpose of setting up the memory constraint analysis sub-unit is to determine whether the target AI model can be loaded on a single card. If not, model parallelism needs to be used to split the model across multiple cards. This is the basic premise for determining the parallel strategy.

[0042] This sub-unit estimates the minimum GPU memory requirement based on the number of parameters in the target AI model and the optimizer state. It compares this to the available GPU memory on a single GPU in the knowledge graph. If the minimum GPU memory requirement exceeds the available GPU memory on a single GPU, model parallelism is deemed necessary, and the degree of model parallelism is determined. In specific implementation, the target AI model has 175 billion parameters, uses FP16 precision, and the model weights occupy 350 GB of GPU memory. Training with the Adam optimizer requires storing parameters, momentum, and variance, totaling three times the model weights, and the optimizer state occupies 1050 GB of GPU memory. Additionally, temporary storage for activation values, gradients, etc., needs to be considered, typically reserving 20% ​​buffer space, resulting in a total minimum GPU memory requirement of approximately 1260 GB. A search of the knowledge graph shows that 80 GB of available GPU memory for an NVIDIA A100 is available, confirming that model parallelism is necessary. Based on common model parallelism strategies, the model is divided into sixteen parts, each with approximately 11 billion parameters. The weights occupy approximately 22 GB of GPU memory, the optimizer state occupies approximately 66 GB of GPU memory, and the total memory occupied by the activation values ​​is approximately 72 GB, which can be accommodated on a single GPU. Therefore, the model parallelism is determined to be sixteen.

[0043] The purpose of setting up the time constraint analysis sub-unit is to determine the required level of data parallelism to meet the user's expected completion time, while satisfying memory constraints.

[0044] This subunit calculates the minimum data parallelism granularity required to meet the time constraints through reverse derivation, thus determining the data parallelism. In practical implementation, the total computation is 2.15 x 10^19 FLOPs, and the user's expected time window is 14 days, or 1.2 million seconds. The typical computational utilization (MFU) for large language model pre-training tasks on a 1000-calorie cluster is retrieved from the knowledge graph, and an empirical value of 20% is used. The required total computation is the total computation divided by the time window multiplied by the MFU, approximately 8.96 x 10^13 FLOPs per second. The FP16 computing power of an NVIDIA A100 with 80GB of memory is 312 TFLOPS, or 3.12 x 10^14 FLOPs per second. The required number of GPUs is the required computing power divided by the computing power per GPU, approximately 287. Combining the determined model parallelism of 16 based on memory constraint analysis, the data parallelism is the required number of GPUs divided by the model parallelism, approximately 18, rounded down to 18, for a total of 288 GPUs.

[0045] The purpose of setting up the communication requirements analysis subunit is to ensure that the communication capabilities between nodes can meet the synchronization requirements. It calculates the minimum required interconnect bandwidth based on the parallelism and model fragment size, which is used for network matching during subsequent resource screening.

[0046] This sub-unit calculates the minimum required inter-node interconnect bandwidth and network latency based on the determined model parallelism and data parallelism, combined with the model fragment size of the target AI model, using a communication cost model. In specific implementation, based on a model parallelism of 16, each model fragment contains approximately 11 billion parameters, and the weights occupy approximately 22GB of GPU memory. The Hockney model is used to estimate communication time. Assuming a typical iteration computation time of two seconds, and if the allowed communication time does not exceed 5% of the total training time, then the communication time must not exceed 0.1 seconds. The required bandwidth is the data volume divided by the allowed communication time; 22GB divided by 0.1 seconds equals 220GB per second. Considering that actual communication may require multiple All-Reduce operations, a conservative estimate suggests a required bandwidth of no less than 660GB per second. According to the Hockney model, the latency must not exceed the allowed communication time minus the data volume divided by the bandwidth. Given a bandwidth of 660GB per second, the latency should not exceed 0.067 seconds, or 67 milliseconds. Therefore, the inter-node network latency must not exceed 50 milliseconds to allow for a margin.

[0047] The purpose of setting up the resource quantification and specification generation unit is to transform the above reasoning results into a structured specification list that can be directly parsed by the scheduler, while ensuring that all resource requirements, including computing, storage, and software, are fully defined, laying the foundation for subsequent automated deployment.

[0048] This unit is connected to the computational load estimation unit and the parallel strategy planning unit respectively. Based on the total computational load, single-card computing power, expected completion time and cluster efficiency experience value, it reverse-engineers the required number and model of GPUs. Combined with the model parallelism, data parallelism, interconnect bandwidth and network latency requirements output by the parallel strategy planning unit, it determines the memory, storage IOPS and software environment dependencies required for each node. Finally, it generates a structured executable resource specification list containing computing resources, software environment, storage requirements and service level agreement requirements.

[0049] In practical implementation, based on the time constraint analysis, 288 GPUs are required, each a 80GB A100. Considering the mainstream configuration of eight GPUs per node, the number of nodes is determined to be 36. Based on the model fragment size of 22GB, plus activation values, temporary buffers, etc., the estimated peak memory usage is approximately 60GB. With eight GPUs per node, a total of 480GB of memory is required. To allow for margin, the memory per node is determined to be no less than 512GB. The dataset size is 1TB, and the training epochs are assumed to be three, resulting in a total data read volume of approximately 3TB. If the expected data loading time accounts for no more than 10% of the total training time (1.2 days), the required IOPS is 3TB divided by 1.2 days, approximately 30MB / s. Considering random reads and checkpoint writes, storage IOPS is required to be no less than 50,000. Given that the task type is large language model pre-training, the recommended software stack from the knowledge graph includes PyTorch 2.0 and above, CUDA 11.8, and the NVIDIA container image nvcr.io / nvidia / pytorch:22.12-py3. The service level agreement requires a maximum completion time of fourteen days and a budget of 50,000 yuan.

[0050] The final generated structured executable resource specification list includes the following computing resource specifications: GPU model A100-80G, 288 GPUs, 36 nodes, 8 GPUs per node, minimum memory of 512GB per node, interconnect requirements NVLink or InfiniBand, minimum bandwidth of 660GB per second, and maximum latency of 50 milliseconds; the software environment includes the framework PyTorch 2.0, CUDA version 11.8, container image nvcr.io / nvidia / pytorch:22.12-py3, parallelism strategy model parallelism of 16, and data parallelism of 18; storage requirements include a dataset size of 1TB, a required IOPS of 50,000, and NVMe SSD storage type; the service level agreement includes a maximum duration of 336 hours, a budget of 50,000 yuan, and priority cost optimization.

[0051] To clarify the core concepts in the technical solution, key terms are defined as follows: The target AI model refers to the specific artificial intelligence model submitted by the user through natural language requirements, which needs to perform training or inference tasks on computing resources, such as GPT-3, LLaMA, Stable Diffusion, etc. Domain-fine-tuned large model refers to a large language model deployed in the AI ​​job perception and parsing engine and fine-tuned by domain knowledge injection, used to understand user needs and generate resource specification lists; Model parallelism refers to the number of parts the target AI model is divided into under a model parallelism strategy, i.e., how many GPUs the model parameters are distributed across for computation. Data parallelism refers to the number of copies the target AI model is replicated under a data parallelism strategy, i.e., how many GPUs simultaneously process different batches of data with the same set of model parameters. Model partition size refers to the amount of GPU memory occupied by each model parameter after the target AI model is partitioned in parallel. Cluster effective computing power utilization refers to the proportion of actual effective computing time to the total time in distributed training, usually expressed as MFU or TFU.

[0052] Through the collaborative work of the above modules, the AI ​​job perception and parsing engine gradually transforms the vague requirements submitted by users in natural language into a precise, structured list of resource specifications that can be directly parsed by the scheduler. This greatly reduces the threshold for using AI computing power and lays a solid foundation for subsequent global optimization scheduling and trusted transactions.

[0053] In this preferred embodiment, the purpose of setting up a global intelligent scheduler is to break down the resource boundaries of a single data center, construct a logically centralized but physically distributed computing resource pool, and design an intelligent scheduling algorithm that comprehensively considers multiple objective factors such as computing cost, power cost, network latency, data locality, and carbon emissions to maximize global benefits. The scheduler receives a structured list of executable resource specifications from the AI ​​job perception and parsing engine and searches for the optimal physical resource matching solution in the global resource pool.

[0054] The purpose of the dynamic resource profiling module is to establish a comprehensive and real-time resource view for each connected computing node, providing an accurate data foundation for subsequent scheduling decisions. This module maintains a real-time profile vector for each computing node, including static attributes, dynamic indicators, economic and environmental attributes, and data locality.

[0055] Static attributes must include at least the GPU model, number of GPUs, number of CPU cores, memory capacity, storage type and capacity, and network bandwidth. For example, a node's static attributes might be: GPU model A100-80G, number of GPUs 8, number of CPU cores 64, memory capacity 512GB, storage type NVMe SSD, storage capacity 4TB, and network bandwidth 100Gbps. These attributes are entered during node registration and are only updated when the node configuration changes.

[0056] Dynamic metrics include at least real-time utilization, available capacity, and health status. Through the resource adapter at the resource access layer, real-time data from the nodes is collected every minute, including GPU utilization of 65%, number of available GPUs (3), CPU utilization of 40%, available memory of 200GB, network I / O, etc., and the node's health status is reported as normal. These dynamic metrics are updated in real time, reflecting the current load of the nodes.

[0057] Economic and environmental attributes include at least the computation cost per unit time, real-time electricity price, and carbon emission factor. The computation cost per unit time is set by the computing power provider, for example, 12.5 yuan per GPU-hour. The real-time electricity price is obtained from the electricity market API, for example, 0.8 yuan per kilowatt-hour. The carbon emission factor is obtained based on real-time data from the power grid where the node is located, for example, 0.4 kilograms of carbon dioxide per kilowatt-hour. These attributes affect the cost and environmental impact of the scheduling scheme.

[0058] Data locality includes at least the cache identifier of public datasets or user-owned private data on the node or adjacent storage. The resource adapter periodically scans the cached datasets on the node, recording the dataset name and version (e.g., ImageNet and COCO datasets are cached), as well as the data identifier of a specific user. During scheduling, nodes with cached data are prioritized to reduce data transfer overhead.

[0059] All profile data is stored in an in-memory database as key-value pairs, supporting fast querying and filtering.

[0060] The purpose of the candidate resource set initial screening module is to quickly remove nodes from the global resource pool that do not meet the basic requirements of the job, thereby narrowing the search space for subsequent fine-tuning and improving scheduling efficiency. This module is connected to the dynamic resource profile construction module and selects eligible resource nodes or resource combinations from the global resource pool based on the job's hard constraints to form a candidate set.

[0061] The hard constraints include minimum requirements for GPU model, number of GPUs, memory, and network bandwidth. Taking the aforementioned user requirements as an example, the job requires a GPU model of at least A100-80G, a total of at least 288 GPUs, at least 512GB of memory per node, and at least 660GB of interconnect bandwidth between nodes. For single-node tasks, the selection logic is to iterate through all nodes, check if each node meets all hard constraints, and if so, add it to the candidate set.

[0062] For multi-node tasks, the processing logic is more complex. First, nodes with suitable GPU models and at least eight usable GPUs per node are selected from the global resource pool, forming an initial node set. Then, a heuristic search algorithm, such as a greedy algorithm or a genetic algorithm, is used to select node combinations from the initial set, ensuring that the total number of GPUs in the combination is no less than 288, and that the network performance between nodes meets the requirements for parallel communication. Network performance is evaluated based on measured latency and bandwidth data between nodes, which are periodically detected and reported by the resource adapter. For candidate node combinations, it is also necessary to verify whether all nodes within the combination are in the same high-speed interconnect network domain, such as the same rack or the same POD, to avoid cross-domain communication becoming a bottleneck. Verified node combinations are added to the candidate set, with each combination serving as a candidate solution c.

[0063] The purpose of the multi-objective optimization module is to comprehensively evaluate the merits of candidate solutions from multiple dimensions, considering not only cost but also time, energy consumption, carbon emissions, and other factors to achieve the globally optimal decision. This module is connected to the candidate resource set initial screening module and evaluates each candidate solution according to a preset multi-objective scoring function to generate a comprehensive score.

[0064] The multi-objective scoring function is: Score(c) = w1·Normalize(Cost(c)) + w2·Normalize(Time(c)) + w3·Normalize(Power(c)) + w4·Normalize(Carbon(c)) Where w1, w2, w3, and w4 are weight coefficients, and Normalize is the normalization function.

[0065] The calculation methods for each indicator are as follows: Cost(c) represents the total computing cost, which includes resource rental fees, electricity costs, and data transfer fees. Resource rental fees are calculated based on the node's unit price and the estimated usage time. For example, if node A's unit price is 12.5 yuan per GPU hour and it is used for 200 hours, then the resource rental fee is 12.5 yuan multiplied by 200 multiplied by the number of GPUs. Electricity costs are calculated based on the node's typical power consumption, estimated utilization rate, and real-time electricity price. For example, if a node's typical power consumption is 300 watts, the estimated utilization rate is 80%, it is used for 200 hours, and the electricity price is 0.8 yuan per kilowatt-hour, then the electricity cost is 0.3 kilowatts multiplied by 0.8 multiplied by 200 hours multiplied by the utilization rate factor. Data transfer fees are calculated based on the dataset size and whether cross-domain transfer is involved. If the data is already local, the transfer fee is zero; otherwise, it is calculated at a certain fee per GB.

[0066] Time(c) represents the estimated job completion time, including computation time, data loading time, and queuing latency. Computation time is calculated by dividing the total computation load by the cluster's effective computing power, which is the sum of the nodes' GPU computing power multiplied by the estimated utilization. Data loading time is calculated by dividing the dataset size by storage or network bandwidth. Queuing latency is estimated based on historical load time-series predictions of the nodes or the current queue status. Time-series prediction models such as ARIMA are used to predict queuing times for the next 24 hours based on load data from the past week, or to estimate latency based on the size and resource requirements of the currently queued jobs.

[0067] Power(c) represents energy consumption. The total energy consumption is obtained by multiplying the typical power consumption of the node by the estimated utilization rate and then by the duration of occupation. Carbon(c) represents carbon emissions, which is energy consumption multiplied by the real-time carbon emission factor at the node's location. The normalization function Normalize uses linear normalization, with the formula Normalize(x) = (x - min(X)) / (max(X) - min(X)), where X is the set of all candidate solutions for that indicator. For indicators such as cost and time, where smaller values ​​are better, the normalized result can be used directly; for certain benefit-related indicators, the reciprocal can be taken before normalization.

[0068] The purpose of the weight configuration module is to dynamically adjust the weight coefficients in the multi-objective scoring function, enabling the scheduling strategy to adapt to changes in user preferences, task types, and global resource status, thereby improving scheduling flexibility and user satisfaction. This module, connected to the multi-objective optimization module, is used for dynamically configuring weight coefficients and specifically includes a strategy template unit, a learning recommendation unit, a state-aware driving unit, a weight normalization unit, and a constraint boundary unit.

[0069] The strategy template unit stores preset weight configuration templates, including at least cost-priority mode, time-priority mode, green and low-carbon mode, and balanced mode. In cost-priority mode, w1=0.7, w2=0.2, w3=0.05, w4=0.05, suitable for budget-sensitive users; in time-priority mode, w1=0.2, w2=0.7, w3=0.05, w4=0.05, suitable for urgent tasks with strict completion time requirements; in green and low-carbon mode, w1=0.1, w2=0.1, w3=0.2, w4=0.6, suitable for scenarios pursuing environmental benefits; in balanced mode, all weights are 0.25. Users can directly select a template or customize the weights.

[0070] The learning recommendation unit collects the finally confirmed resource allocation schemes from users' historical scheduling requests to construct a user preference dataset. Based on this dataset, collaborative filtering algorithms or reinforcement learning models are used to mine users' preference features for four objectives: cost, time, energy consumption, and carbon emissions, and to personalize the recommendation weight coefficient combination for the current user. The collaborative filtering algorithm calculates the similarity between the current user and other users, and performs a weighted average recommendation based on the historical weight preferences of similar users. The reinforcement learning model uses the task type, budget range, time requirement, and resource specifications of the user's historical requests as state features, the discretized values ​​of the weight coefficient combination as optional actions, and the user's final confirmation of the scheduling scheme as a positive reward signal. A deep Q-network is used to train the weight recommendation strategy. For example, when a user chooses the cost-first option three times consecutively, the model increases the probability of recommending the cost-first option.

[0071] The state-aware driving unit acquires real-time operational status information of the global resource pool, including node electricity price fluctuations, carbon emission factor changes, and resource scarcity. It dynamically adjusts weight coefficients according to preset state-weight mapping rules, defined using a finite state machine model. When a local grid electricity price exceeds a preset threshold of 1.2 yuan per kilowatt-hour, the cost weight w1 is increased by 0.1; when a node's carbon emission factor exceeds 0.6 kilograms of carbon dioxide per kilowatt-hour, the carbon emission weight w4 is increased by 0.15; when the interstitial resource inventory in the global resource pool is below 20%, weights are adjusted to prioritize matching idle resources—that is, the cost weight w1 is decreased by 0.1, and the time weight w2 is decreased by 0.1—to encourage the use of idle resources. The adjustment range can be dynamically calibrated based on historical system operational data.

[0072] The weight normalization unit is connected to the policy template unit, the learning recommendation unit, and the state-aware driving unit, respectively. It normalizes the generated weight coefficient combinations to ensure that w1 + w2 + w3 + w4 = 1. For example, if the original weights are (0.7, 0.2, 0.1, 0.1) and the sum is 1.1, then the normalized weights are (0.636, 0.182, 0.091, 0.091). The normalized weight coefficients are then output to the multi-objective optimization module.

[0073] The constraint boundary unit is connected to the weight normalization unit, setting an adjustable safety range for each weight coefficient to prevent the weight coefficients from exceeding a reasonable range during dynamic adjustment. For example, w1∈[0.1,0.8], w2∈[0.1,0.8], w3∈[0.05,0.5], w4∈[0.05,0.6]. If the adjusted weights exceed the range, they are truncated to the boundary value and re-normalized.

[0074] In this preferred embodiment, the constraint check module is set up to ensure that the recommended solution will not have resource conflicts, data compliance issues or violations of service level agreements during actual execution, thus ensuring the smooth operation of the job. This module is connected to the multi-objective optimization module and performs strict checks on high-scoring candidate solutions.

[0075] Resource availability conflict checks check the resource reservation system to confirm that the selected resource is not locked by other jobs during the expected usage period; if a conflict exists, the plan is excluded or the time period is adjusted.

[0076] Data compliance checks verify whether user data and the location of nodes comply with data security regulations. For example, if user data involves privacy, it cannot be deployed on overseas nodes; if the location of the node has data localization requirements, it must be confirmed that the user data is within that region.

[0077] Service Level Agreement (SLA) compliance verification ensures that the estimated completion time does not exceed the maximum duration required by the user, and the estimated cost does not exceed the budget. If the solution does not meet the SLA, it is excluded.

[0078] The purpose of the decision output module is to select the optimal solution from the candidate solutions that have passed the constraint checks and present it to the user as the final scheduling result. This module is connected to the constraint checking module, selects the candidate solution with the best comprehensive score from the candidate solutions that have passed the constraint checks as the recommended scheduling solution, and outputs solution details, including a list of target resources, estimated costs and time, carbon emissions, etc., for user confirmation.

[0079] For example, for a user's large model training needs, there might be two candidate solutions: Solution A is the Eastern Cloud Data Center, with 288 A100 on-demand instances, costing approximately 62,000 yuan, exceeding the budget; Solution B is the Western Data Center, with idle computing power listed as NFTs, offering 32 A100 instances available for 240 hours, but requiring phased operation, costing 28,000 yuan, which is within the budget and has a higher overall score. The scheduler recommends Solution B to the user.

[0080] Through the collaborative work of the above modules, the global intelligent scheduler achieves cross-regional, multi-objective, and dynamically optimized resource allocation, effectively improving the utilization efficiency of computing resources and meeting the diverse needs of users.

[0081] The purpose of setting up blockchain middleware is to leverage the immutability and traceability of blockchain technology to create a unique digital identity for computing power resources, to reliably measure the resource usage process, and to automate the execution of transaction rules through smart contracts, thereby solving the trust problem of computing power as a virtual commodity being difficult to measure and trade.

[0082] The computing power NFT management module encapsulates computing power resources into standardized non-fungible tokens, enabling fine-grained ownership and assetization of these resources. When computing power providers list idle computing power through the operator's management backend, they fill in information such as resource specifications, available time periods, and prices. Resource specifications follow a structured format output by the AI ​​job perception and analysis engine, ensuring consistency between supply and demand.

[0083] The computing power NFT management module generates metadata for the computing power NFT based on this information. This metadata includes standardized descriptions of the computing power resources, available time periods, and the provider's digital signature. Taking a western data center as an example, the metadata includes the GPU model A100-80G, the number of GPUs (32), the available time period (June 1, 2024, 8:00 AM to 12:00 PM), and the total price of 28,000 yuan. The provider uses their private key to digitally sign the metadata, ensuring its authenticity and non-repudiation. The SHA-256 hash value of the metadata is calculated, and the hash value, along with the resource identifier, provider address, and other information, is packaged into a transaction and submitted to the NFT minting smart contract at the blockchain network layer. After the smart contract is executed, the corresponding computing power NFT is generated and recorded in the distributed ledger. All state changes of this NFT are recorded on-chain, ensuring transparency and traceability.

[0084] The evidence storage interface module receives the usage proof generated by the resource adapter and forwards it to the blockchain network layer for evidence storage, ensuring the immutability and traceability of usage data. This module provides a RESTful API, endpoint / api / v1 / pou / upload, for the resource adapter to call.

[0085] Proof of usage includes a proof ID, NFT ID, job ID, usage data, timestamp, and digital signature. Usage data includes GPU hours, start and end times, and average utilization. Upon receiving the proof, the notarization interface module first verifies the signature's validity using the provider's public key, ensuring the proof has not been tampered with during transmission and was indeed generated by the resource adapter. After successful verification, the proof of usage data is submitted to the notarization smart contract at the blockchain network layer. The contract writes the proof's hash value to the on-chain notarization record and records the notarization timestamp.

[0086] The smart contract triggering module calls smart contracts deployed at the blockchain network layer to automatically execute resource locking, fund staking, and settlement operations. The smart contracts are written in Solidity and deployed on an Ethereum-compatible permissioned blockchain. The core contracts include an NFT locking contract, a fund staking contract, and a settlement contract.

[0087] The blockchain middleware works in conjunction with the AI ​​job perception and analysis engine, the global intelligent scheduler, and the resource access layer to achieve a complete data flow from natural language requirements to NFT locking, connecting the entire chain from requirement analysis, resource matching, asset locking, fund collateralization to environment deployment.

[0088] After receiving the computing power request submitted by the user in natural language, the application interaction layer transmits the request text to the AI ​​job perception and parsing engine. The engine performs chain-like reasoning to generate a structured list of executable resource specifications, which is then sent to the global intelligent scheduler. Based on the resource specification list and the real-time status of the global resource pool, the scheduler performs multi-objective optimization scheduling decisions, generating a resource allocation scheme that includes the target computing power resource identifier, the expected time period to be occupied, and the estimated cost, and presents it to the user for confirmation through the application interaction layer.

[0089] After user confirmation, the application interaction layer sends the confirmation information and resource allocation plan to the smart contract triggering module. The triggering module parses the plan, extracts the target computing power resource identifier and the expected time period, and queries the current status of the corresponding NFT from the computing power NFT management module. If the NFT status is tradable, the triggering module calls the locking smart contract, submitting the NFT's unique identifier, the requester's account address, the budget amount, and the time period as input parameters. After the locking smart contract is executed, the NFT status is updated to locked, and the lock transaction hash is returned.

[0090] After receiving the successful lock response, the triggering module invokes the fund collateral smart contract to transfer the demander's budget amount from the demander's account to the smart contract's escrow account, and returns collateral success information to the application interaction layer. Upon receiving the collateral success information, the application interaction layer sends deployment instructions and resource allocation plans to the corresponding target computing power resource adapter in the resource access layer, triggering the automatic deployment of the job environment.

[0091] The resource adapter continuously collects real-time resource usage metrics during job execution, generating unforgeable usage proofs. The resource adapter comprises a monitoring and data collection component and a usage proof generation component. The monitoring and data collection component collects resource usage metrics, including GPU utilization and memory usage, every five minutes by calling the underlying infrastructure's monitoring API. The usage proof generation component generates a usage proof every thirty minutes, containing information such as the job ID, NFT ID, cumulative GPU hours, and timestamp, and performs an ECDSA digital signature using the resource provider's private key. The signed proof is then sent via HTTPS to the blockchain middleware's notarization interface module.

[0092] The billing and settlement engine uses smart contracts to preset transaction prices and settlement rules. After the transaction is completed, it automatically reads the usage proof data stored on the blockchain and completes the fund transfer based on the actual usage and preset rules. When a transaction is completed, the buyer and seller write the agreed price and settlement rules into the smart contract.

[0093] After the job is completed, the billing and settlement engine performs a usage read, calling the blockchain network layer query interface to retrieve all on-chain usage proofs for the job and accumulating GPU hours. Based on the smart contract's preset rules, it calculates the actual amount due and calls the settlement smart contract to transfer the corresponding funds from the escrow account to the supplier's account; any remaining funds are returned to the demander's account. Upon completion of settlement, the billing and settlement engine sends settlement result notifications to both parties through the application interaction layer, displaying the final fee details and usage report.

[0094] Through the collaborative work of blockchain middleware, resource adapters, and billing and settlement engines, this invention realizes a complete trust chain from resource ownership confirmation and reliable measurement to automatic settlement, providing technical support for the market-oriented circulation of computing power resources.

[0095] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0096] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A data center resource integrated scheduling and trading platform for AI computing power needs, characterized in that: include: The resource access layer includes resource adapters deployed at each computing power provider; The core platform layer includes an AI job perception and analysis engine, a global intelligent scheduler, blockchain middleware, and a billing and settlement engine, among which: The AI ​​job perception and parsing engine is used to parse the natural language computing power requirements submitted by users into a structured list of executable resource specifications. The global intelligent scheduler is connected to the AI ​​job perception and analysis engine and is used to generate a resource allocation scheme based on the list of executable resource specifications. The blockchain middleware is connected to the global intelligent scheduler, the billing and settlement engine, and the blockchain network layer, respectively, and is used to realize the asset-based storage and trading of computing resources. The billing and settlement engine is connected to the blockchain middleware and is used to complete fund transfers based on smart contracts. The blockchain network layer, a permissioned blockchain network, is used to store the digital identity of computing power resources, record proof of usage, and execute smart contracts. The application interaction layer is used to provide the user interface.

2. The integrated data center resource scheduling and trading platform for AI computing power needs as described in claim 1, characterized in that, The AI-powered task perception and analysis engine specifically includes: The domain fine-tuning large model module uses efficient parameter fine-tuning technology to fine-tune the instructions of the general large language model, and injects domain knowledge including hardware performance parameters, AI framework dependencies and task resource patterns into the general large language model to obtain the domain fine-tuning large model; The chained reasoning module is connected to the domain fine-tuning large model module. It calls the domain fine-tuning large model to perform step-by-step reasoning on natural language requirements, including task type identification, computational load estimation, parallel strategy planning, cost constraint fusion, and generation of an executable resource specification list.

3. The integrated data center resource scheduling and trading platform for AI computing power needs as described in claim 2, characterized in that, The chain reasoning module includes: The requirement structuring and intent understanding unit is used to preprocess the natural language requirements input by users, including spelling correction, terminology unification, and entity and constraint extraction. It also categorizes the processed requirements into predefined task prototype categories and outputs the task type, the number of parameters of the target AI model, the dataset size, and user constraints. The computational load estimation unit, connected to the demand structuring and intent understanding unit, is used to estimate the total computational load of the task based on the number of parameters, dataset size, and task type of the target AI model output by the demand structuring and intent understanding unit, and by calling the hardware performance data and algorithm efficiency empirical coefficients stored in the internally integrated knowledge graph. A parallel strategy planning unit, connected to the computational load estimation unit, is used to automatically plan a parallel strategy based on the estimated total computational load and user constraints, specifically including: The memory constraint analysis subunit is used to estimate the minimum video memory requirement based on the number of parameters of the target AI model and the optimizer state. It is then compared with the available video memory of a single card in the knowledge graph. If the minimum video memory requirement exceeds the video memory of a single card, it is determined that model parallelism must be used, and the degree of model parallelism is determined. The time constraint analysis subunit is used to deduce the minimum data parallelism granularity required to meet the time constraints based on the total computational load, the user's expected time window, and the estimated effective computing power utilization of the cluster, and to determine the data parallelism. The communication requirements analysis subunit is used to calculate the minimum required inter-node interconnect bandwidth and network latency requirements based on the determined model parallelism and data parallelism, combined with the model fragment size of the target AI model, using the communication cost model. The resource quantification and specification generation unit is connected to the computational load estimation unit and the parallel strategy planning unit, respectively. It is used to reverse-calculate the required number and model of GPUs based on the total computational load, single-card computing power, expected completion time and cluster efficiency experience value. Combined with the model parallelism, data parallelism, interconnect bandwidth and network latency requirements output by the parallel strategy planning unit, it determines the memory, storage IOPS and software environment dependencies required for each node. Finally, it generates a structured executable resource specification list containing computing resources, software environment, storage requirements and service level agreement requirements.

4. The integrated data center resource scheduling and trading platform for AI computing power needs as described in claim 1, characterized in that, The global intelligent scheduler specifically includes: The dynamic resource profiling module is used to maintain real-time profiling vectors for each computing power node, including static attributes, dynamic indicators, economic and environmental attributes, and data locality. The candidate resource set initial screening module, connected to the dynamic resource profile construction module, is used to screen eligible resource nodes or resource combinations from the global resource pool based on the hard constraints of the operation, forming a candidate set. The multi-objective optimization module, connected to the candidate resource set initial screening module, is used to evaluate each candidate scheme according to a preset multi-objective scoring function and generate a comprehensive score. The constraint checking module, connected to the multi-objective optimization module, is used to verify the resource conflict, data compliance and service level agreement satisfaction of candidate solutions. The decision output module, connected to the constraint checking module, is used to select the candidate scheme with the best comprehensive score from the candidate schemes that have passed the constraint check as the recommended scheduling scheme.

5. The integrated data center resource scheduling and trading platform for AI computing power needs as described in claim 4, characterized in that, The multi-objective scoring function used by the multi-objective optimization module is: in, , , , Here, represents the weighting coefficients, and Normalize is the normalization function. Cost(c) is the total computing cost, which includes resource rental fees, electricity costs, and data transmission fees; Time(c) is the estimated job completion time, which includes computation time, data loading time, and queuing delay. Power(c) represents energy consumption; Carbon(c) represents carbon emissions.

6. The integrated data center resource scheduling and trading platform for AI computing power needs as described in claim 5, characterized in that, The global intelligent scheduler further includes a weight configuration module, connected to the multi-objective optimization module, for dynamically configuring the weight coefficients in the multi-objective scoring function; the weight configuration module specifically includes: The strategy template unit stores preset weight configuration templates, including at least cost-priority mode, time-priority mode, green and low-carbon mode, and balanced mode. , , , It has predefined default values; The learning recommendation unit, connected to the strategy template unit, is used to collect the resource allocation schemes finally confirmed in the user's historical scheduling requests and construct a user preference dataset. Based on the user preference dataset, a collaborative filtering algorithm or reinforcement learning model is used to mine the user's preference features for four objectives: cost, time, energy consumption, and carbon emissions, and to provide a personalized recommendation weight coefficient combination for the current user. When using a reinforcement learning model, the task type, budget range, time requirement, and resource specifications of the user's historical requests are used as state features, the discrete values ​​or continuous adjustments of the weight coefficient combination are used as optional actions, and the user's final confirmation of the scheduling scheme is used as a positive reward signal. The weight recommendation strategy is trained based on historical interaction data. The state-aware driving unit is used to acquire real-time operational status information of the global resource pool, including fluctuations in node electricity prices, changes in carbon emission factors, and resource scarcity. It dynamically adjusts weight coefficients according to a preset state-weight mapping rule. This state-weight mapping rule uses a finite state machine model and includes at least the following: increasing the cost weight when a local grid electricity price is detected to be higher than a preset threshold. When the node's carbon emission factor exceeds a preset threshold, the carbon emission weight is increased. When the amount of interstitial resources in the global resource pool is lower than a preset threshold, the weights are adjusted to prioritize matching idle resources. The weight normalization unit, connected to the policy template unit, learning recommendation unit, and state-aware driving unit, is used to normalize the generated weight coefficient combination to ensure... + + + = 1, and output the normalized weight coefficients to the multi-objective optimization module; The constraint boundary unit, connected to the weight normalization unit, is used to set an adjustable safety range for each weight coefficient to prevent the weight coefficient from exceeding a reasonable range during dynamic adjustment.

7. The integrated data center resource scheduling and trading platform for AI computing power needs as described in claim 1, characterized in that, The blockchain middleware specifically includes: The computing power NFT management module is used to encapsulate computing power resources into standardized computing power non-fungible tokens. The metadata of the computing power NFT includes standardized description information of computing power resources, available time period information and supplier digital signature, and the hash value of the metadata is stored on the blockchain. The evidence storage interface module is used to receive the usage proof generated by the resource adapter and forward it to the blockchain network layer for evidence storage; The smart contract triggering module is used to call smart contracts deployed in the blockchain network layer to perform resource locking, fund collateralization and settlement operations; The blockchain middleware, in collaboration with the AI ​​job perception and analysis engine, the global intelligent scheduler, and the resource access layer, realizes a complete data flow from natural language requirements to NFT locking, specifically including: After receiving the computing power request submitted by the user in natural language, the application interaction layer transmits the natural language request text to the AI ​​job perception and parsing engine; the AI ​​job perception and parsing engine performs chain reasoning on the natural language request to generate a structured executable resource specification list containing computing resource specifications, software environment dependencies, storage requirements and service level agreement requirements, and sends the structured executable resource specification list to the global intelligent scheduler. After receiving the structured executable resource specification list, the global intelligent scheduler synchronously obtains the real-time status data of the global resource pool from the resource access layer, and performs multi-objective optimization scheduling decisions based on the structured executable resource specification list to generate a resource allocation scheme that includes the target computing power resource identifier, the expected time period to be occupied, and the estimated cost; the global intelligent scheduler presents the resource allocation scheme to the user for confirmation through the application interaction layer. After receiving the user's confirmation instruction for the resource allocation scheme, the application interaction layer sends the confirmation information and the resource allocation scheme to the smart contract triggering module of the blockchain middleware. The smart contract triggering module parses the resource allocation scheme, extracts the target computing power resource identifier and the expected occupation period contained therein, and queries the computing power NFT management module for the corresponding computing power NFT and its current status based on the target computing power resource identifier. If the computing power NFT is tradable, the smart contract triggering module calls the locking smart contract deployed in the blockchain network layer, submitting the unique identifier of the computing power NFT, the demander's account address, the budget amount, and the occupation period as input parameters to the locking smart contract. After the locking smart contract is executed, the status of the computing power NFT is updated to locked, and the lock transaction hash is returned to the smart contract triggering module. After receiving the lock success response, the smart contract triggering module calls the fund collateral smart contract deployed in the blockchain network layer to transfer the demander's budget amount from the demander's account to the smart contract escrow account, and returns the collateral success information to the application interaction layer. After receiving the successful mortgage information, the application interaction layer sends the deployment instruction and the resource allocation scheme to the corresponding target computing power resource adapter in the resource access layer, triggering the automatic deployment of the job environment.

8. The integrated data center resource scheduling and trading platform for AI computing power needs as described in claim 1, characterized in that, The resource adapter is also used for: During the execution of the operation, resource usage indicators are continuously collected, and usage proofs containing usage data, timestamps and resource identifiers are periodically generated. The usage proofs are then digitally signed and sent to the blockchain middleware.

9. The integrated data center resource scheduling and trading platform for AI computing power needs as described in claim 1, characterized in that, The billing and settlement engine is specifically used for: By setting transaction prices and settlement rules through smart contracts, the system automatically reads the usage proof data stored on the blockchain after the operation is completed, transfers funds from the demand side's account to the supply side according to the actual usage and preset rules, and returns the remaining funds to the demand side.

Images