A heterogeneous computing load balancing and scheduling method based on a P2P network

Abstract

The application is particularly a heterogeneous computing power load balancing scheduling method based on a P2P network, and relates to the technical field of distributed computing, and comprises the following steps: based on a task demand profile and a node performance fingerprint of each candidate node, a matching degree score between the task and each candidate node is calculated, and the task is scheduled to a target node with the highest matching degree score for execution.In the application, a node performance fingerprint containing multi-dimensional performance indexes is generated for each node in the P2P network, a task demand profile containing resource demand characteristics is generated for each computing task, and a scheduling decision is established on the basis of quantitative matching of node capability and task demand, so that a random or polling distribution mode without distinguishing node differences and task demands is replaced.

Description

Technical Field

[0001] This invention relates to the field of distributed computing technology, and in particular to a heterogeneous computing power load balancing scheduling method based on P2P networks. Background Technology

[0002] P2P computing power networks consist of a large number of dispersed participating nodes. Each node has significant differences in hardware conditions such as the number of CPU cores, GPU floating-point performance, memory capacity, and network bandwidth, forming a heterogeneous computing power distribution pattern.

[0003] Existing P2P network load balancing schemes typically distribute computing tasks to nodes using random or round-robin methods. These schemes do not differentiate between nodes' hardware capabilities or the resource requirements of the tasks themselves, treating all nodes as equal execution units.

[0004] The aforementioned approach leads to a mismatch between resources: GPU-intensive tasks may be assigned to nodes lacking GPU resources, while I / O-intensive tasks may be assigned to nodes with insufficient disk performance. Simultaneously, high-performance nodes frequently become idle due to not being prioritized, while low-performance nodes become continuously overloaded due to handling tasks beyond their capacity, resulting in low overall computing power utilization of the P2P network. Furthermore, existing solutions lack the ability to respond to dynamic changes in node load during task execution, failing to migrate tasks to low-load nodes when one node is overloaded, further exacerbating the load imbalance problem. Summary of the Invention

[0005] The purpose of this invention is to propose a heterogeneous computing power load balancing scheduling method based on P2P networks in order to solve the above-mentioned problems.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: A heterogeneous computing power load balancing scheduling method based on P2P networks includes: Collect multi-dimensional performance indicators of each node in the P2P network, perform Z-score standardization on each performance indicator, summarize them into vector form, and generate node performance fingerprints. The computational tasks submitted to the P2P network are analyzed, resource requirement features are extracted, and the resource requirement features are standardized using the same Z-score as the node performance fingerprint to generate a task requirement profile. Based on the task requirement profile and the node performance fingerprint of each candidate node, calculate the matching score between the task and each candidate node, and schedule the task to the target node with the highest matching score for execution. The matching score is obtained by weighted summation of resource adequacy score and feature matching score. The resource adequacy score is determined based on the difference between the remaining available resources of each candidate node and the corresponding resource requirements in the task requirement profile. The feature matching score is obtained based on the cosine similarity between the task requirement profile and the node performance fingerprint of the candidate node.

[0007] Preferably, the resource sufficiency score Calculated using piecewise function form: ; in, The total number of resource dimensions. For the first The surplus of the resource. For candidate nodes in the th The remaining available amount of the resource. For the task to the first The demand for this resource This is the non-negative surplus after truncation. For the preset first Resource surplus saturation threshold; when the surplus reaches The time score no longer increases.

[0008] Preferably, the multidimensional performance indicators include computing power indicators, storage indicators, network indicators, and available resource indicators; the computing power indicators include at least one of CPU core count, CPU clock speed, GPU floating-point performance, and AI accelerator computing power; the storage indicators include at least one of memory capacity, memory bandwidth, and disk I / O performance; the network indicators include at least one of uplink bandwidth, downlink bandwidth, and network latency; and the available resource indicators are the ratio of the current remaining amount of each resource to the total amount.

[0009] Preferably, the resource requirement characteristics include a resource requirement vector and execution characteristics; the resource requirement vector includes at least one of estimated CPU computation, GPU requirement information, memory usage, storage space requirement, and network transmission volume; the execution characteristics include at least one of task type and task time limit, wherein the task type identifies that the task belongs to one of CPU-intensive, GPU-intensive, I / O-intensive, or network-intensive tasks.

[0010] Preferably, the matching score is further superimposed with a data locality score and a load balancing factor; wherein, when the task requirement profile contains data dependency information and the dataset pointed to by the data dependency information is stored locally on a candidate node, the matching score of the candidate node is superimposed with a preset data locality score; the load balancing factor is determined based on the current load rate of the candidate node, and the higher the load rate, the greater the negative correction of the matching score by the load balancing factor.

[0011] Preferably, the method further includes: monitoring the load changes of each node during task execution; when the migration triggering conditions are met, calculating the migration cost of migrating the task to each candidate low-load node, and selecting the candidate node with the lowest migration cost as the target migration node; saving the current computing state and intermediate data through checkpoint technology, and transmitting the checkpoint data to the target migration node; after loading the checkpoint data, the target migration node resumes task execution from the checkpoint position and updates the mapping relationship between the task and the node.

[0012] Preferably, the migration triggering condition includes at least one of an overload warning condition and an execution tailing condition; the overload warning condition is that the CPU utilization or GPU utilization of the execution node continuously exceeds a preset utilization threshold, and the number of queued tasks shows an increasing trend, and there is a low-load node among the neighboring nodes that meets the requirements of the task to be migrated; the execution tailing condition is that the execution time of the subtask exceeds a preset multiple of the average execution time of similar subtasks, and the progress increment in the most recent observation period is lower than a preset progress threshold.

[0013] Preferably, the method further includes: after the task is completed, collecting actual execution indicators, comparing the actual execution indicators with the predicted values ​​at the time of scheduling decision to generate a deviation report; based on the accumulated deviation reports, calibrating the node performance fingerprint parameters through online regression analysis; statistically analyzing the distribution of deviation reports according to task type, and adjusting the weight coefficients of resource sufficiency score and feature matching score in the matching score calculation.

[0014] Preferably, each node periodically broadcasts its own node performance fingerprint to neighboring nodes via the gossip protocol, and receives node performance fingerprints broadcast by neighboring nodes, updating the neighboring node performance fingerprint table maintained locally; the node performance fingerprint also includes historical operation statistics, which include average task processing time, task failure rate and reliability score, and are concatenated as additional dimensions to the performance index vector after Z-score normalization.

[0015] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are: 1. This invention generates a node performance fingerprint containing multi-dimensional performance indicators for each node in a P2P network and generates a task requirement profile containing resource requirement characteristics for each computing task. It establishes scheduling decisions on the basis of quantitative matching between node capabilities and task requirements, replacing the random or round-robin allocation method that does not distinguish between node differences and task requirements.

[0016] 2. This invention reduces execution efficiency losses caused by resource type mismatch by using resource sufficiency scores to filter out candidate nodes with insufficient resources and feature matching scores to direct tasks to nodes with the most suitable resource types during the matching score calculation. Data locality scores reduce network overhead for remote data transmission, and load balancing factors prevent high-load nodes from being repeatedly selected, reducing the risk of overloaded hotspot nodes. Attached Figure Description

[0017] Further details, features, and advantages of this application are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which: Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0018] Several embodiments of this application will now be described in more detail with reference to the accompanying drawings to enable those skilled in the art to implement this application. This application may be embodied in many different forms and for various purposes and should not be limited to the embodiments set forth herein. These embodiments are provided to make this application thorough and complete, and to fully convey the scope of this application to those skilled in the art. The embodiments described do not limit this application.

[0019] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It will be further understood that terms such as those defined in commonly used dictionaries shall be interpreted as having a meaning consistent with their meaning in the relevant field and / or the context of this specification, and shall not be interpreted in an idealized or overly formal sense unless expressly defined herein.

[0020] Example 1 Its specific implementation method is combined with the appendix Figure 1 Please provide a detailed explanation.

[0021] In this embodiment, it includes: In P2P computing networks, participating nodes vary significantly in terms of hardware capabilities such as computing power, memory capacity, and network bandwidth. Existing load balancing solutions often use random or round-robin allocation to distribute tasks to nodes, failing to fully consider the heterogeneity of nodes and the resource requirements of the tasks themselves. This results in high-performance nodes frequently being idle while low-performance nodes remain continuously overloaded, leading to low overall computing power utilization in P2P networks.

[0022] A heterogeneous load balancing scheduling method for P2P computing power networks according to an embodiment of the present invention includes the following steps: Step 1: Collect multi-dimensional performance indicators of each node in the P2P network and generate node performance fingerprints. Each node in a P2P network periodically collects its own performance metrics. These metrics include computing power, storage, network, and available resources. Computing power metrics include at least one of the following: CPU core count, CPU clock speed, GPU floating-point performance, and AI accelerator computing power. Storage metrics include at least one of the following: memory capacity, memory bandwidth, and disk I / O performance. Network metrics include at least one of the following: uplink bandwidth, downlink bandwidth, and network latency. Available resources are the current available percentage of each resource, i.e., the ratio of the remaining amount of total resources after deducting occupied portions to the total amount.

[0023] The above performance metrics are summarized into a vector form to generate the node performance fingerprint. Since the dimensions and numerical ranges of the various performance metrics differ significantly, Z-score standardization is applied to each metric before generating the node performance fingerprint vector to eliminate the impact of these dimensional differences on subsequent vector operations.

[0024] It should be noted that the node performance fingerprint mentioned above can also incorporate the node's historical operational statistics. Historical operational statistics include average task processing time, task failure rate, and reliability score. The reliability score is determined based on the proportion of tasks successfully completed by the node within a historical period. After undergoing Z-score normalization, the historical operational statistics are concatenated as an additional dimension to the performance metric vector, forming a comprehensive node performance fingerprint that includes both real-time capabilities and historical performance.

[0025] It should be noted that the above node performance fingerprint can be dimensionality reduced using principal component analysis (PCA). PCA takes the full performance index vector of each node as input and outputs the dimensionality-reduced principal component feature vectors, i.e., the dimensionality-reduced node performance fingerprint. The dimensionality-reduced node performance fingerprint retains the principal component dimensions that contribute most to the differences in node capabilities, reducing the data dimensionality of subsequent matching calculations.

[0026] In this embodiment, to enable each node to have near real-time awareness of the global resource distribution of the P2P network, each node maintains a neighbor node performance fingerprint table. Each node periodically broadcasts its own node performance fingerprint to its neighbors via the gossip protocol and receives the broadcast node performance fingerprints from its neighbors, updating its local neighbor node performance fingerprint table accordingly. Through multiple rounds of dissemination via the gossip protocol, each node can obtain the node performance fingerprint information of most nodes in the network within several broadcast cycles.

[0027] Step 2: Analyze the computing tasks submitted to the P2P network, extract resource requirement features, and generate a task requirement profile. When a computing task is submitted to a P2P network, the task is parsed to extract resource requirement features. These features include a resource requirement vector and execution characteristics.

[0028] The resource requirement vector includes at least one of the following: estimated CPU computation load, GPU requirement information, memory usage, storage space requirements, and network throughput. The GPU requirement information includes whether a GPU is needed, the required video memory size, and the required computing framework version.

[0029] Execution characteristics include at least one of task type and task deadline. Task type identifies whether the task is CPU-intensive, GPU-intensive, I / O-intensive, or network-intensive. Task deadline identifies the task's deadline and constraint strength, which is divided into hard constraints and soft constraints.

[0030] The resource requirement vector and execution features are encoded into a task requirement profile for the task. The values ​​in the resource requirement vector are then standardized using the same Z-score method as the node performance fingerprint in step 1, ensuring that the task requirement profile vector and the node performance fingerprint vector are in the same numerical space to support subsequent matching degree calculations.

[0031] It should be noted that the resource requirement characteristics mentioned above may also include data dependency information. Data dependency information identifies whether the task needs to access a specific dataset, the size of the dataset, and the node identifier where the dataset is currently stored. This data dependency information is also encoded into the task requirement profile for evaluating data transfer overhead during subsequent scheduling.

[0032] It should be noted that the above execution characteristics may also include parallelizable splitting attributes and priority attributes. The parallelizable splitting attribute indicates whether the task supports being split into multiple subtasks for parallel execution. The priority attribute indicates the priority level of the task in the scheduling queue; higher-priority tasks are processed first during scheduling.

[0033] In this embodiment, for repetitive tasks—that is, tasks with the same or similar task identifiers as historically completed tasks—actual resource consumption data for such tasks can be obtained from historical execution records. This actual resource consumption data is then used to replace or weight and correct the estimated resource demand vector obtained from the above analysis, generating a more accurate task demand profile and thus reducing scheduling inaccuracies caused by estimation bias.

[0034] Step 3: Calculate the matching score between each task and the candidate node, and schedule the task to the target node based on the matching score. Based on the task requirement profile and the node performance fingerprints of each candidate node, a matching score is calculated between the task and each candidate node. The matching score is obtained by a weighted sum of the resource sufficiency score and the feature matching score. Specifically, the matching score... The calculation formula is:

[0035] in, To score the matching degree, As a score for resource sufficiency, The feature matching score is the score. and These are the corresponding weight coefficients, satisfying... and .

[0036] Resource Availability Score The resource requirement is determined based on the difference between the remaining available resources of each candidate node and the corresponding item in the resource requirement vector of the task requirement profile. Let the candidate node be at the... The remaining available quantity of the resource is The task is for the first The demand for this resource is There are a total of Item resource dimension, The range of values ​​is to , If the total number of resource dimensions is [number], then [then...]. The calculation method is as follows: when all resource dimensions satisfy... hour, It is a positive value, and its value varies with the difference in each dimension. It increases with the increase in resources, but there is a growth cap to avoid assigning tasks to nodes with resources far exceeding demand, which would cause high-performance resources to be occupied by low-demand tasks; when any dimension exists hour, Takes a zero or negative value. Because... and Both have undergone the same Z-score standardization process as in steps 1 and 2, and are in the same numerical space, with consistent dimensions for the difference operation.

[0037] It should be noted that the above The specific calculation uses a piecewise function form. Let... For the first The surplus of the resource. This is the non-negative surplus after truncation. For the first The surplus saturation threshold of a resource. If the total number of resource dimensions is: ; in, The total number of resource dimensions. Indexed for resource dimensions, The range of values ​​is to , For the first The surplus of the resource. This is the non-negative surplus after truncation. For the preset first Resource surplus saturation threshold For the task to the first The demand for this resource. When the surplus reaches The time-minute value no longer increases and takes the value of When a resource shortage dimension exists, the score is the average of the relative gaps in each dimension, taking a value of zero or negative. It should be noted that in the resource shortage branch... As a normalization benchmark, it is used to map resource gaps in various dimensions to comparable relative dimensions. When a certain dimension At that time, the task has no requirement for that dimension, and the corresponding dimension's This will not trigger the resource shortage branch, therefore The case where resources are insufficient is not included in the calculation of the branch with insufficient resources, and there is no division by zero issue. Because... , and Both are defined within the same standardized space, and the division operations in the two branches above have the same dimensions.

[0038] Feature matching score The cosine similarity between the task requirement profile and the performance fingerprint of candidate nodes is used for calculation. To ensure that both the task requirement profile vector and the node performance fingerprint vector can participate in the cosine similarity calculation, they must be mapped to the same vector space and have the same dimensions. Specifically, resource dimensions corresponding to the task requirement profile vector are extracted from the node performance fingerprint vector, including CPU computing power, GPU computing power, memory, disk I / O, and network bandwidth. These dimensions are arranged in the same dimensional order as the task requirement profile vector, forming matching vector pairs with the same number of dimensions. The cosine similarity is then calculated, and the directional similarity score is output as the feature matching score. If principal component analysis was performed to reduce the dimensionality of the node performance fingerprint in step 1, then the task requirement contour vector needs to be projected to the same principal component space before performing cosine similarity calculation.

[0039] For each task, score all candidate nodes according to their matching degree. Nodes are sorted from highest to lowest score, and a number of top-ranked nodes are selected as a candidate set of target nodes. The size of the candidate set is dynamically determined based on the number of currently online nodes in the P2P network. The task is then scheduled to be executed on the node with the highest matching score in the candidate set.

[0040] It should be noted that the matching score mentioned above can also be combined with a data locality score. When the task requirement profile contains data dependency information, and the dataset pointed to by the data dependency information is stored locally on a candidate node, the matching score of that candidate node is combined with a preset data locality score. A positive data locality score is used to increase the matching priority of the node where the data resides, reducing the network overhead of transferring data from remote nodes to the execution node.

[0041] It should be noted that the matching score mentioned above can also be combined with a load balancing factor. The load balancing factor is determined based on the current load rate of the candidate nodes. The higher the load rate, the more negative the load balancing factor becomes, and the larger its absolute value, thus negatively correcting the matching score. The load balancing factor is used to prevent high-load nodes from being repeatedly selected, to distribute tasks more evenly, and to avoid the formation of hotspot nodes.

[0042] In this embodiment, when the matching score of all candidate nodes is lower than a preset matching threshold, it is determined that there is no suitable node in the current P2P network that meets the requirements of the task. At this time, if the task's parallel splitting attribute indicates that it supports splitting, the task is split into multiple subtasks, and the task requirement profile is regenerated for each subtask, with matching score calculation and scheduling performed. If the task does not support splitting, the task is submitted to a backup cloud resource pool for execution.

[0043] Step 4: Monitor the load changes of each node during task execution, and migrate the task to a low-load node when the migration trigger condition is met. In this embodiment of the application, in order to deal with the dynamic changes in node load during task execution, based on the task being scheduled to the target node for execution in step 3, the scheduling node continuously collects real-time load data and task progress data of each execution node.

[0044] The task migration decision is triggered when any of the following conditions are met: The first condition is the overload warning condition. When the CPU utilization or GPU utilization of an execution node continuously exceeds the preset utilization threshold, and the number of queued tasks waiting for the node shows an increasing trend, while there are low-load nodes among its neighboring nodes with remaining resources to meet the needs of the tasks to be migrated, the overload warning condition is determined to be met.

[0045] The second condition is the execution tailing condition. When the execution time of a subtask exceeds a preset multiple of the average execution time of similar subtasks, and the progress increment of the subtask in the most recent observation period is lower than a preset progress threshold, the execution tailing condition is determined to be met.

[0046] For tasks that trigger migration decisions, step 4 may specifically include: Step S401: Determine the target migration node based on migration cost assessment. Calculate the migration cost of migrating the task to each candidate low-load node. The migration cost comprehensively considers the amount of state data to be migrated, the available network bandwidth from the current node to the candidate node, and the estimated task interruption recovery time. Select the candidate node with the lowest migration cost as the target migration node.

[0047] Step S402: Save the current task's computation state and transmit it to the target migration node. For migrateable tasks (i.e., stateless tasks or tasks whose execution state supports serialization), save the current computation state and intermediate data using checkpointing technology. Transmit the checkpoint data and the remaining task code to be executed to the target migration node.

[0048] Step S403: Resume task execution on the target migration node and update the task-node mapping relationship. After receiving the checkpoint data, the target migration node loads the computation state and resumes task execution from the checkpoint location. After migration is complete, the scheduling node updates its locally maintained task-node mapping table and synchronizes the updated mapping relationship to neighboring nodes via the gossip protocol. The migration process is transparent to the upper-layer application that submitted the task.

[0049] Step 5: Collect the actual execution metrics after the task is completed, compare them with the predicted values ​​during scheduling, and calibrate the node performance fingerprint and matching degree weight based on the deviation.

[0050] In this embodiment of the application, to continuously optimize the scheduling strategy over time, the following steps are added to the above scheduling method: After each task is completed, the actual execution metrics of the task are collected, including the actual completion time, the actual utilization rate of various resources, network transmission time, and the number of migrations.

[0051] The actual performance indicators are compared with the predicted values ​​made during the scheduling decision in step 3 to generate a deviation report. The deviation report records the differences between the predicted and actual values ​​of each indicator and the direction of the differences.

[0052] Based on the accumulated deviation reports, step 5 may specifically include: Step S501: Calibrate node performance fingerprints. The node performance fingerprint parameters of each node are corrected using online regression analysis. The input to the online regression analysis is the historical deviation record sequence of each node, and the output is the corrected node performance fingerprint parameter values. When the actual processing capacity of a node is consistently higher than the level represented by its node performance fingerprint, the value of the corresponding dimension in the node performance fingerprint is adjusted upwards; conversely, if the actual processing capacity is consistently lower than the represented level, the value of the corresponding dimension is adjusted downwards.

[0053] Step S502: Adjust the matching degree weight coefficients. Analyze the distribution of deviation reports by task type. When a certain type of task frequently experiences scheduling inaccuracies due to weight deviations in specific matching factors, adjust the weight coefficients of each factor in the matching degree score calculation in Step 3. For example, if I / O-intensive tasks are frequently scheduled to nodes with insufficient disk performance, increase the weight of the feature matching degree score in the matching degree score; if tasks frequently time out due to remote data transmission, increase the weight of the data locality score.

[0054] Step S503: Optimize the migration triggering strategy. Record the cost and benefit data for each task migration in Step 4. Cost data includes migration time and network transmission volume, while benefit data includes the reduction in task completion time and the change in target node load after migration. Use the cost and benefit data as training samples for reinforcement learning. The input to reinforcement learning is migration context features, including the load status of the source node and candidate target nodes, as well as the current progress status of the task; the output is the optimized migration triggering threshold and target node selection strategy; the optimization objective is to maximize the expected value of the difference between migration benefit and migration cost, and cumulative discounted reward is used as the reward signal for training. The output migration triggering threshold directly replaces the corresponding threshold parameters used in the overload warning condition and execution tailing condition in Step 4, and the target node selection strategy replaces the principle of minimizing migration cost in Step S401, and is used for migration determination in subsequent scheduling cycles.

[0055] All calibrated node performance fingerprint parameters, adjusted weight coefficients, and optimized migration strategy parameters are disseminated to other nodes in the P2P network via the gossip protocol, making the network-wide scheduling strategy tend to be consistently optimized.

[0056] Example 2 This invention also proposes a heterogeneous load balancing scheduling system for P2P computing power networks, comprising: The performance fingerprint generation module is used to collect multi-dimensional performance indicators of each node in the P2P network and generate node performance fingerprints. The task profile extraction module is used to parse computing tasks submitted to the P2P network, extract resource requirement features, and generate task requirement profiles. The matching and scheduling module is used to calculate the matching score between each task and the candidate node, and to schedule the task to the target node based on the matching score. The dynamic migration module is used to monitor the load changes of each node during task execution and migrate the task to a low-load node when the migration trigger conditions are met.

[0057] The feedback calibration module is used to collect the actual execution indicators after the task is completed, compare them with the predicted values ​​during scheduling, and calibrate the node performance fingerprint and matching degree weight based on the deviation.

[0058] By way of example, the system proposed in this invention may also include various features and combinations thereof in the method embodiments, which will not be elaborated here.

[0059] Using a distributed AI inference service platform as a specific application scenario, this paper demonstrates the complete operation process of a heterogeneous load balancing scheduling method for P2P computing power networks. The platform consists of a P2P computing power network composed of heterogeneous computing nodes distributed across multiple regions. These nodes include inference servers equipped with high-end GPUs, general-purpose servers with only CPU computing power, and hybrid nodes combining medium-sized GPU computing power and large-capacity storage. The platform undertakes diverse computing tasks, including large language model inference, image recognition batch processing, and vector retrieval. On a weekday morning in 20XX, the platform received a batch of concurrent computing tasks. The execution process of each core step is shown below.

[0060] Execution process of step 1 The performance fingerprint generation module collects multi-dimensional performance metrics for each node in the network. Taking four representative nodes as an example: Node A is a GPU inference server, Node B is a CPU general-purpose server, Node C is a hybrid node, and Node D is a lightweight edge node. After collection, Z-score standardization is performed on each metric to eliminate differences in dimensions, and historical reliability scores are added as an additional dimension to generate the node performance fingerprint for each node.

[0061] Table 1 Original node performance indicators and standardized node performance fingerprints

[0062] Each node broadcasts its performance fingerprint to its neighboring nodes via the gossip protocol. The neighboring nodes then update their local neighboring node performance fingerprint tables, enabling all nodes in the network to obtain the performance fingerprint information of most nodes within a few broadcast cycles.

[0063] Execution process of step 2 The task profile extraction module analyzes three representative computing tasks received by the platform in the morning of 20XX to extract resource requirement features. Task A is a large language model inference task, which is GPU-intensive; Task B is a vector database batch retrieval task, which is I / O-intensive; and Task C is a text classification batch processing task, which is CPU-intensive. The resource requirement vectors for each task undergo the same Z-score normalization process as in step 1, ensuring that the task requirement profile vector and the node performance fingerprint vector are in the same numerical space.

[0064] Table 2. Original Resource Requirements and Task Requirements Outline

[0065] There are similar inference tasks in the historical execution records of Task A. Obtain the actual GPU memory consumption data from the historical records, and perform weighted correction on the estimated value to make the task requirement profile of Task A closer to the actual resource consumption.

[0066] Step 3 execution process The matching and scheduling module calculates the matching score between each task and each candidate node based on the task requirement profile and the node performance fingerprint of each candidate node. .in As a score for resource sufficiency, The feature matching score is the score. and These are the weighting coefficients.

[0067] Extract the resource dimension corresponding to the task requirement contour vector from the node performance fingerprint vector, form matching vector pairs with the same dimension, and calculate the cosine similarity as... The resource sufficiency score is calculated using a piecewise function based on the difference between the available resources at each node and the task requirements. After combining the data locality score and the load balancing factor, the final matching score is obtained and ranked.

[0068] Table 3 Summary of matching scores between each task and candidate node

[0069] Task A is affected because node B lacks GPU resources. Negative values ​​are filtered out. Task B's score is improved by adding a data locality score because node C locally stores the vector dataset it depends on, thus avoiding the overhead of remote data transmission. Task C is scheduled to node B, which has the most CPU cores.

[0070] Step 4 execution process The dynamic migration module continuously collects real-time load data from each execution node. When Task A is executing on node A for 47 seconds, it detects that the GPU utilization of node A continues to exceed the preset utilization threshold, and the number of queued tasks is increasing. At the same time, during the execution of a subtask of Task B on node C, the execution time of a certain subtask exceeds a preset multiple of the average execution time of similar subtasks, and the progress increment in the most recent observation period is lower than the preset progress threshold, triggering the execution tailing condition.

[0071] Table 4. Migration Triggering Events and Migration Cost Assessment

[0072] After selecting the candidate node with the lowest migration cost, the current computation state and intermediate data of task A are saved using checkpointing technology, and the checkpoint data is transferred to node C. Node C resumes the execution of task A from the checkpoint location, the scheduling node updates the task-node mapping table, and synchronizes the updated mapping relationship to neighboring nodes via the gossip protocol. The entire migration process is transparent to the upper-layer application.

[0073] Step 5 execution process After all three tasks are completed, the feedback calibration module collects the actual performance indicators, compares them with the predicted values ​​during the scheduling decision in step 3, and generates a deviation report.

[0074] Table 5 Task Execution Deviation Report

[0075] Based on the deviation reports, online regression analysis was used to calibrate the GPU performance fingerprint parameters of node A and the disk I / O parameters of node C upwards, making the node performance fingerprints more accurately reflect actual processing capabilities. Statistical analysis of the deviation report distribution revealed significant deviations in the completion time of I / O-intensive tasks; therefore, the weight of the feature matching score in the overall matching score was increased accordingly. The cost and benefit data from this migration are used as training samples for reinforcement learning. The expected value of the difference between the migration benefit and the migration cost is used as the optimization objective to update the migration trigger threshold and target node selection strategy, replacing the corresponding parameters in step 4. All calibrated parameters are propagated to all nodes in the network via the gossip protocol.

[0076] The data flow throughout the scheduling process exhibits strict logical coherence. Step 1 collects raw performance metrics, which are then standardized using Z-scores to form node performance fingerprints. These fingerprints are shared across the entire network via the gossip protocol, providing the node-side data foundation for the matching degree calculation in Step 3. Step 2 parses the original resource requirements of the task and generates a task requirement profile through the same standardization process, ensuring it resides in the same numerical space as the node performance fingerprints and supporting dimensional consistency for the difference and cosine similarity calculations in Step 3. The scheduling decision output in Step 3 directly determines the initial execution node of the task. Step 4 continuously monitors the execution process; when load fluctuations trigger migration conditions, task checkpoint data is transmitted from the source node to the target node, ensuring execution continuity. Step 5 collects actual execution metrics to generate a deviation report. The calibrated node performance fingerprint parameters and weight coefficients are fed back to Steps 1 and 3, while the optimized migration strategy parameters are fed back to Step 4, forming a complete closed loop from data collection, task parsing, matching scheduling, dynamic migration to feedback calibration. This ensures that the platform's scheduling accuracy continuously improves with the accumulation of tasks.

[0077] The foregoing has only described certain exemplary embodiments of the present invention by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the foregoing drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

[0078] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

Claims

1. A heterogeneous computing power load balancing scheduling method based on P2P networks, characterized in that, include: Collect multi-dimensional performance indicators of each node in the P2P network, perform Z-score standardization on each performance indicator, summarize them into vector form, and generate node performance fingerprints. The computational tasks submitted to the P2P network are analyzed, resource requirement features are extracted, and the resource requirement features are standardized using the same Z-score as the node performance fingerprint to generate a task requirement profile. Based on the task requirement profile and the node performance fingerprint of each candidate node, calculate the matching score between the task and each candidate node, and schedule the task to the target node with the highest matching score for execution. The matching score is obtained by weighted summation of resource sufficiency score and feature matching score. The resource sufficiency score is determined based on the difference between the remaining available resources of each candidate node and the corresponding resource requirements in the task requirement profile. The feature matching score is obtained based on the cosine similarity between the task requirement profile and the node performance fingerprint of the candidate node.

2. The heterogeneous computing power load balancing scheduling method based on P2P network according to claim 1, characterized in that, Resource Availability Score Calculated using piecewise function form: ； in, The total number of resource dimensions. For the first The surplus of the resource. For candidate nodes in the th The remaining available amount of the resource. For the task to the first The demand for this resource This is the non-negative surplus after truncation. For the preset first Resource surplus saturation threshold; when the surplus reaches The time score no longer increases.

3. The heterogeneous computing power load balancing scheduling method based on P2P network according to claim 1, characterized in that, The multidimensional performance metrics include computing power metrics, storage metrics, network metrics, and available resource metrics; the computing power metrics include at least one of the following: number of CPU cores, CPU clock speed, GPU floating-point performance, and AI accelerator computing power; the storage metrics include at least one of the following: memory capacity, memory bandwidth, and disk I / O performance; the network metrics include at least one of the following: uplink bandwidth, downlink bandwidth, and network latency; and the available resource metrics are the ratio of the current remaining amount of each resource to the total amount.

4. The heterogeneous computing power load balancing scheduling method based on P2P network according to claim 1, characterized in that, The resource requirement characteristics include a resource requirement vector and execution characteristics; the resource requirement vector includes at least one of estimated CPU computation, GPU requirement information, memory usage, storage space requirement, and network transmission volume; the execution characteristics include at least one of task type and task time limit, wherein the task type identifies whether the task is CPU-intensive, GPU-intensive, I / O-intensive, or network-intensive.

5. The heterogeneous computing power load balancing scheduling method based on P2P network according to claim 1, characterized in that, The matching score is also superimposed with the data locality score and the load balancing factor; wherein, when the task requirement profile contains data dependency information and the dataset pointed to by the data dependency information is stored locally on a candidate node, the matching score of the candidate node is superimposed with the preset data locality score; the load balancing factor is determined based on the current load rate of the candidate node, and the higher the load rate, the greater the negative correction of the matching score by the load balancing factor.

6. The heterogeneous computing power load balancing scheduling method based on P2P network according to claim 1, characterized in that, Also includes: Monitor the load changes of each node during task execution. When the migration triggering conditions are met, calculate the migration cost of migrating the task to each candidate low-load node and select the candidate node with the lowest migration cost as the target migration node. The current computation state and intermediate data are saved using checkpoint technology, and the checkpoint data is then transmitted to the target migration node. After loading the checkpoint data, the target migration node resumes task execution from the checkpoint location and updates the mapping relationship between the task and the node.

7. A heterogeneous computing power load balancing scheduling method based on a P2P network according to claim 6, characterized in that, The migration triggering conditions include at least one of overload warning conditions and execution tailing conditions; the overload warning condition is that the CPU utilization or GPU utilization of the execution node continuously exceeds a preset utilization threshold, the number of queued tasks shows an increasing trend, and there are low-load nodes among the neighboring nodes that meet the requirements of the task to be migrated; the execution tailing condition is that the execution time of the subtask exceeds a preset multiple of the average execution time of similar subtasks, and the progress increment in the most recent observation period is lower than a preset progress threshold.

8. The heterogeneous computing power load balancing scheduling method based on P2P network according to claim 1, characterized in that, Also includes: After the task is completed, the actual execution indicators are collected, and the actual execution indicators are compared with the predicted values ​​at the time of scheduling decision to generate a deviation report. Based on the accumulated deviation reports, the node performance fingerprint parameters are calibrated through online regression analysis. The distribution of deviation reports is statistically analyzed according to task type, and the weight coefficients of resource sufficiency score and feature matching score in the matching score calculation are adjusted.

9. A heterogeneous computing power load balancing scheduling method based on a P2P network according to claim 1, characterized in that, Each node periodically broadcasts its own node performance fingerprint to neighboring nodes via the gossip protocol, and receives node performance fingerprints broadcast by neighboring nodes, updating the neighboring node performance fingerprint table maintained locally. The node performance fingerprint also includes historical operation statistics, which include average task processing time, task failure rate and reliability score. After Z-score standardization, these are concatenated as additional dimensions to the performance index vector.

Images