Contract recursion method for distributed tensor data updating
By employing dynamic adaptive design of global and local contracts and real-time state awareness, combined with reinforcement learning and historical log compensation, the efficiency and consistency issues of distributed tensor data updates in dynamic cluster environments are resolved, achieving efficient and stable tensor state maintenance.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- MINASH (SHANGHAI) ROBOT TECHNOLOGY CO LTD
- Filing Date
- 2026-01-29
- Publication Date
- 2026-05-08
AI Technical Summary
Existing distributed tensor data update methods suffer from low communication efficiency, uneven resource utilization, and difficulty in maintaining state consistency in dynamic and heterogeneous cluster environments, lacking flexibility and intelligence.
It adopts a two-layer dynamic adaptive contract with global and local layers, combined with real-time cluster state awareness, dynamically adjusts the synchronization mode and aggregation strategy, uses reinforcement learning agents to optimize contract parameters, resolves conflicts through version tags, and uses historical logs for fault tolerance compensation.
It realizes intelligent adaptive recursion for distributed tensor data updates, improves the efficiency and stability of large-scale distributed training, ensures the consistency of state updates, and reduces the impact of communication bottlenecks and failures.
Smart Images
Figure CN121998001A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer data processing technology, and in particular to a contract recursion method for updating distributed tensor data. Background Technology
[0002] Distributed tensors are commonly used in large-scale machine learning training, especially deep learning. Due to the massive number of model parameters (such as a language model with hundreds of billions of parameters) or the sheer volume of data, a single node cannot handle all the data or perform efficient computation. Therefore, tensor sharding is necessary to store the tensors across multiple nodes, or to distribute the processing through data parallelism (multiple nodes replicating the same model) or model parallelism (single model splitting across multiple nodes). In this case, tensor updates (such as adjusting parameters based on gradients) need to be coordinated and completed in a distributed environment.
[0003] Distributed tensor data update refers to the process of modifying or adjusting tensors (multidimensional arrays, commonly used in deep learning for model parameters and intermediate features) stored on multiple nodes (such as servers, GPUs, TPUs) in a distributed computing environment. Its core objective is to efficiently and consistently maintain the latest state of tensors in multi-node collaborative computing to support distributed training, inference, or other large-scale data processing tasks.
[0004] Based on existing technologies, current distributed tensor data update methods, such as asynchronous updates based on parameter servers or AllReduce with fixed synchronization domains, typically employ static, pre-defined strategies for gradient aggregation and synchronization. These methods lack the ability to perceive and respond to dynamic cluster conditions during runtime (such as network fluctuations, node heterogeneity, and data access hotspots), leading to problems like communication congestion and uneven resource utilization in complex network environments. Furthermore, their fault tolerance mechanisms are often crude (e.g., simple rollback), resulting in wasted computational resources and impacting convergence speed; conflict resolution also relies heavily on simple rules, making it difficult to maintain state consistency while ensuring efficiency. In summary, existing distributed tensor data update methods lack flexibility and intelligence, failing to achieve an optimal balance of efficiency, consistency, and robustness in dynamic, heterogeneous distributed environments. Therefore, this invention proposes a contract recursion method for distributed tensor data updates to address the problems existing in current technologies. Summary of the Invention
[0005] To address the aforementioned problems, the present invention aims to propose a contract recursion method for distributed tensor data updates. This method solves the problems that existing distributed tensor data update methods often employ statically preset update strategies, which are difficult to adapt to dynamic and heterogeneous cluster environments, often resulting in low communication efficiency, uneven resource utilization, crude fault tolerance mechanisms, and difficulties in maintaining state consistency.
[0006] To achieve the objectives of this invention, the invention is implemented through the following technical solution: a contract recursion method for distributed tensor data updates, comprising the following steps:
[0007] Step 1: Load and instantiate the global layer contract and the local layer contract as dynamic adaptive contracts. The global layer contract defines the basic rules for cross-node collaboration. The local layer contract customizes the corresponding tensor sharding management strategy and local recursive calculation rules according to the node type. Based on the preset tensor sharding rules, the initial tensor state is allocated to each node in the cluster, and an initial version vector is created for each tensor shard.
[0008] Step 2: Periodically collect runtime status indicators of each node in the cluster, including node computing load, network communication quality between nodes, and access pattern indicators of each tensor fragment, and aggregate them to generate a cluster status vector.
[0009] Step 3: Dynamically adjust contract parameters based on cluster state vector. Each node calculates local tensor update amount according to its local layer contract and generates version tag containing node identifier and logical timestamp. According to the rules defined by global layer contract, aggregate local tensor update amount in cluster, resolve conflicts based on version tag, generate globally consistent new tensor state and update each node replica.
[0010] Step 4: Continuously record the recursive path log during the update process. When a node failure or communication anomaly is detected, backtrack to the most recent consistent state point based on the recursive path log, and use historical log data to predict and compensate for the missing update amount.
[0011] Step 5: If the current recursive process meets the preset convergence condition or triggers an abnormal termination condition, the process is terminated and the final tensor state is output; otherwise, return to step 2 to continue iterating.
[0012] Further improvements are made in the following steps: In step two, when collecting runtime status indicators, computing power indicators are periodically collected through node agents, including tensor operation calculation time, memory utilization and processor utilization. The bidirectional latency and available bandwidth between nodes are measured through network probes. The counters in the tensor sharding management module are used to count the sharding update frequency and query dependency count to calculate the sharding access popularity.
[0013] Further improvements are made in the following steps: In step three, the specific steps for dynamically adjusting the contract parameters are as follows: Based on the network latency index in the cluster state vector, the cluster synchronization mode is dynamically switched. When the average latency between nodes exceeds the first threshold, it is switched to asynchronous or hybrid mode. When the latency is lower than the second threshold, it is switched back to synchronous mode. The hybrid mode refers to synchronous aggregation within a subset of computing nodes and asynchronous communication between subsets.
[0014] A further improvement is made in step three, when dynamically adjusting contract parameters, a reinforcement learning agent is used to construct a reward function based on cluster iteration efficiency and state consistency, and dynamically outputs and executes the adjustment actions for the learning rate and aggregation frequency parameters in the contract.
[0015] A further improvement lies in the fact that the training mechanism of the reinforcement learning agent includes:
[0016] The state space is a normalized representation of the cluster state vector;
[0017] Action space refers to instructions for adjusting adjustable parameters in the contract;
[0018] The reward function R is designed as follows:
[0019] R = w1*E + w2*(1-D) - w3*C
[0020] Where E is the reciprocal of the iteration efficiency, D is the maximum difference between the cluster tensor state versions, C is the network communication overhead, and w1, w2, and w3 are weight coefficients.
[0021] A further improvement is made in step three, when aggregating local tensor update amounts within the cluster, a gradient compression strategy is dynamically selected based on the network bandwidth and fragment access frequency in the cluster state vector. Sparse compression is used for high-frequency update fragments, while quantization or low-rank approximation compression is used for low-frequency update fragments.
[0022] A further improvement is that the compression ratio r in the gradient compression strategy is adaptively determined. The target compression ratio is calculated according to the formula r = r_base * f(h) * g(b), where r_base is the base compression ratio, f(h) is a decreasing function of the fragment access popularity h, and g(b) is a decreasing function of the available bandwidth b. After decompression at the receiving end, the compression error is calculated and accumulated, and the accumulated error is added as a correction amount to the gradient calculated locally in the next round.
[0023] A further improvement is made in step three, when resolving conflicts based on version tags, a version vector is maintained for each tensor fragment. When a new update is received, a version comparison is performed. If there are concurrent conflicts, arbitration is conducted according to the rules defined in the local layer contract. Strong consistency arbitration based on the latest timestamp is used for critical fragments, and eventual consistency arbitration based on node priority or merging algorithm is used for non-critical fragments.
[0024] A further improvement is made in step four, when using historical log data to predict and compensate for missing update amounts, the historical update sequence of the N consecutive rounds before the failure of the fault node is obtained from the distributed storage recursive path log, input into the pre-trained recurrent neural network prediction model, outputting the predicted value of the update amount of the missing rounds, and incorporating the predicted value as the compensation amount into the aggregation process of the current round.
[0025] The beneficial effects of this invention are as follows: By constructing a global and local two-layer dynamic adaptive contract and combining it with real-time cluster state awareness, this invention realizes intelligent and adaptive recursion of distributed tensor data updates, which can significantly improve the efficiency and stability of large-scale distributed training. Furthermore, by dynamically switching the synchronization mode, adjusting the aggregation strategy and compression rate through the sensing network and computing power status, it effectively reduces communication bottlenecks and waiting time.
[0026] Secondly, this invention ensures strong consistency of state updates in complex asynchronous environments, accurately resolves conflicts using version vectors and contractual arbitration mechanisms, and gracefully tolerates faults by using intelligent prediction compensation based on historical logs, which greatly reduces the impact of faults on overall convergence accuracy and progress.
[0027] Finally, this invention has a high degree of adaptability. By optimizing contract parameters online through reinforcement learning or heuristic rules, the system can automatically adapt to dynamically changing cluster load and network conditions, reducing the cost of manual tuning and providing robust and efficient underlying support for distributed machine learning. Attached Figure Description
[0028] Figure 1 This is a flowchart illustrating the contract recursion method for distributed tensor data updates according to the present invention. Detailed Implementation
[0029] 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.
[0030] In this embodiment, "system" refers to the entire hardware and software complex driven and coordinated by the contract execution engine deployed on the distributed computing cluster management node. The steps performed by "system" below refer to the contract execution engine acting as the control core, coordinating the various hardware nodes and software modules in the distributed computing cluster to complete the task together.
[0031] It should be noted that the technical means not described in detail in the following embodiments are all conventional means in the art, are not the key points of the invention, and will not be elaborated upon.
[0032] See Figure 1 This embodiment provides a contract recursion method for updating distributed tensor data. This method is executed by a contract execution engine deployed on a distributed computing cluster management node, and includes the following steps:
[0033] Step 1: Initialize the dynamic adaptive contract cluster
[0034] Load and instantiate the global layer contract and the local layer contract as dynamic adaptive contracts. The global layer contract defines the basic rules for cross-node collaboration, while the local layer contract is customized according to the node type. For each type of node, it defines the corresponding tensor sharding management strategy and local recursive calculation rules. Based on the preset tensor sharding rules, the initial tensor state shards are distributed to each node in the cluster, and an initial version vector is created and recorded for each tensor shard.
[0035] This step completes the basic system configuration. The "Dynamic Adaptive Contract," as the core control hub, adopts a two-layer "global-local" design. The global layer contract defines the basic collaborative rules that all nodes must follow, such as communication protocols (e.g., gRPC), security authentication mechanisms, and basic fault-tolerance frameworks. The local layer contracts are customized based on different node types, such as compute-intensive, storage-intensive, or edge-intensive, defining a unique tensor sharding management strategy and local recursive computation rules for each type of node. Subsequently, according to preset tensor sharding rules such as model parallelism or data parallelism, the initial tensor state (e.g., neural network weights) is sharded and distributed to each node in the cluster, and an initial version vector is created and recorded for each tensor shard to accurately track the causal order of all updates in subsequent steps.
[0036] Step 2: Real-time sensing and aggregation of cluster dynamic status
[0037] Periodically collect runtime status metrics for each node in the cluster, including node computing load, network communication quality between nodes, and access patterns for each tensor fragment. The collection method is as follows:
[0038] The agent is a lightweight daemon deployed on each node that periodically collects the computing power metrics of the node, including tensor operation computation time, memory utilization, and processor utilization. The agent is a lightweight daemon deployed on each node that is responsible for collecting local hardware metrics.
[0039] Cluster network probes measure bidirectional network latency and available bandwidth between nodes. A network probe is a tool that actively sends test packets to measure latency and bandwidth.
[0040] By using a counter embedded in the tensor fragmentation management module, the frequency of update operations and the number of query dependencies for each tensor fragment within a unit of time are counted to calculate the fragment access popularity. The "fragment access counter" is a software module that quantifies the "popularity" of a fragment by accumulating the number of operations. These are typical and feasible ways to achieve comprehensive and low-overhead state awareness.
[0041] The collected status indicators are then aggregated and processed to generate a cluster status vector to guide contract adjustments.
[0042] This step provides real-time data input for the system's dynamic decision-making. The system periodically collects three types of key indicators:
[0043] Node computing load: Collect metrics such as tensor operation computation time, memory utilization, and processor utilization through lightweight agents deployed on each node;
[0044] Network communication quality: Actively measure bidirectional network latency and available bandwidth between nodes using cluster network probes;
[0045] Tensor-based sharding access mode: By using counters embedded in the sharding management module, the update frequency and query dependency count of each shard are counted to calculate its access popularity;
[0046] The system aggregates and normalizes the collected raw state indicators to generate a structured cluster state vector. This vector is the sole basis for dynamically adjusting contract behavior and selecting optimization strategies in subsequent steps.
[0047] Step 3: Execute the contract-based recursive update loop
[0048] Based on the cluster state vector generated in step two, the execution parameters of the dynamic adaptive contract are dynamically adjusted. Specifically, based on the network latency index in the cluster state vector, the cluster's synchronization mode is dynamically switched. When the average latency between nodes exceeds a first threshold, the update mode is switched from synchronous mode to asynchronous or hybrid mode. When the latency is below a second threshold, it is switched back to synchronous mode. Hybrid mode refers to using synchronous aggregation within a subset of computing nodes and asynchronous communication between subsets, thereby achieving adaptive switching of the synchronization mode. The switching logic is as follows:
[0049] When network conditions deteriorate (latency > first threshold, e.g., 100ms), to avoid slowing down the overall speed due to synchronous waiting, it automatically degrades to the more efficient asynchronous or hybrid mode; when the network recovers well (latency < second threshold, e.g., 50ms), it switches back to the more consistent synchronous mode. The hybrid mode is a compromise, maintaining synchronization within a small subset of nodes (such as servers within the same rack) to ensure efficiency, while using asynchronous operations between subsets to tolerate cross-domain latency.
[0050] In this embodiment, when dynamically adjusting the execution parameters of the dynamically adaptive contract, a reinforcement learning agent is used. A reward function is constructed based on the cluster's iterative efficiency and state consistency. The agent dynamically outputs and executes adjustments to the learning rate and aggregation frequency parameters within the contract. The training mechanism of the reinforcement learning agent includes:
[0051] The state space is a normalized representation of the cluster state vector generated in step two;
[0052] The action space consists of discrete or continuous adjustment instructions for adjustable parameters in the contract;
[0053] The reward function R is designed as follows:
[0054] R = w1*E + w2*(1-D) - w3*C
[0055] Where E is the reciprocal of the iteration efficiency, D is the maximum difference between the cluster tensor state versions, C is the network communication overhead, and w1, w2 and w3 are weight coefficients.
[0056] Each node independently calculates the local tensor update based on its local layer contract and local data, and generates a version tag containing the node identifier and logical timestamp for this calculation event. The specific steps are as follows: Based on the network bandwidth and shard access popularity in the cluster state vector, a gradient compression strategy is dynamically selected. For high-frequency update shards, sparse compression is used, and for low-frequency update shards, quantization or low-rank approximation compression is used. The selection of the compression ratio r in the dynamic gradient compression strategy is adaptive.
[0057] The target compression ratio is calculated using the formula r = r_base * f(h) * g(b), where r_base is the base compression ratio, f(h) is a decreasing function of the fragment access popularity h, and g(b) is a decreasing function of the available bandwidth b.
[0058] After decompressing the compressed gradient at the receiving end, the error introduced by this compression is calculated and accumulated, and the accumulated error is added as a correction amount to the gradient calculated locally in the next round to reduce the impact of compression on the model convergence accuracy.
[0059] According to the aggregation rules and synchronization strategies defined by the global layer contract, local tensor updates are aggregated within the cluster, and conflicts are resolved based on version tags to generate a globally consistent new tensor state to update the local tensor copies of each node. During conflict resolution, each tensor shard maintains a version vector; when a new shard update is received, the version vector is compared; if concurrent conflicts exist, they are resolved according to the arbitration rules defined by the local layer contract. For critical shards, strong consistency arbitration based on the latest timestamp is used, and for non-critical shards, eventual consistency arbitration based on node priority or merging algorithm is used.
[0060] By maintaining a version vector for each tensor fragment, the chronological order ("causality") or concurrency relationship ("conflict") of two update events can be clearly determined. For concurrent conflicts, the arbitration rules are defined by the local layer contract based on the criticality of the fragment. For example, for critical fragments such as the model output layer, strong consistency arbitration is used (only accepting the latest timestamp update to ensure absolute correctness); for certain internal layers or non-critical parameters, eventual consistency arbitration can be used (such as merging by node role priority or taking the average, prioritizing availability and speed). This differentiated processing balances consistency and performance.
[0061] This step completes one iteration. First, the contract parameters are dynamically adjusted based on the state vector from step two (e.g., automatically relaxing synchronization requirements when network latency is high). Then, each node independently calculates local updates (such as gradients) based on its local contract and generates versions with time-series labels. Next, aggregation and conflict resolution are performed according to global contract rules: hierarchical aggregation may be used during aggregation; during conflict resolution, the version vector created in step one is used to compare the order of update events. Finally, a globally consistent new state is generated and all replicas are updated synchronously. By tightly integrating static contract rules with dynamic runtime states, automation of the "perception-decision-execution" process is achieved.
[0062] Step 4: Fault Tolerance and State Repair in the Recursive Process
[0063] During the update process of the local tensor replica, a recursive path log containing version evolution, node contributions, and causal relationships is continuously recorded. When a node failure or communication anomaly is detected, the recursive path log is used to backtrack to the most recent consistent state point. Historical log data is then used to predict and compensate for the missing update amounts due to the failure. The specific steps are as follows: The historical update amount sequence of the failed node in the N consecutive rounds prior to the failure is obtained from the distributed storage of the recursive path log; this sequence is input into a pre-trained recurrent neural network prediction model, which outputs a predicted value for the update amount in the missing rounds; this predicted value is then incorporated as compensation into the update amount aggregation process of the current round. By extracting the actual update amounts of the failed node in the N consecutive rounds (e.g., 5 rounds) prior to the failure from the log, a time series is formed. This series is then input into a pre-trained recurrent neural network (RNN, such as LSTM) model. This model can learn the historical update patterns and trends of the node and predict the update amounts that may occur during the failure period. Using this predicted value as compensation allows the system state to return to normal more smoothly, which is superior to simply ignoring or recalculating the entire update.
[0064] During step three, the system continuously records the version evolution, node contributions, and causal relationships of each update round in the recursive path log. This log is stored in a distributed consensus manner to ensure reliability. When a node failure is detected, the system first backtracks to the most recent state point where all healthy nodes have reached a consensus based on the log. Then, using the historical update sequence of the failed node for N consecutive rounds before the failure as input, a pre-trained recurrent neural network (such as LSTM) prediction model is used to generate a predicted value for the update amount of the missing rounds. Finally, this predicted value is incorporated as compensation into the aggregation process of the current round, thereby achieving graceful degradation and rapid recovery, minimizing the impact of failure on the overall training.
[0065] Step 5: Iteration Termination Judgment
[0066] The system continuously monitors the recursive process to determine whether the preset convergence conditions are met (such as the loss function changing below a threshold) or abnormal termination conditions are triggered (such as reaching the maximum number of iterations). If the conditions are met, the process terminates and the final tensor state is output; otherwise, it returns to step two and starts a new round of "perception-update" loop based on the latest cluster state.
[0067] In this embodiment, before the contract is loaded in step one, formal modeling languages such as TLA+ can be used to model and verify the contract rules to ensure that they meet key attributes such as no deadlock and state consistency, thus ensuring system reliability from the design source.
[0068] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, 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 contract recursive method for updating distributed tensor data, characterized in that, Includes the following steps: Step 1: Load and instantiate the global layer contract and the local layer contract as dynamic adaptive contracts. The global layer contract defines the basic rules for cross-node collaboration. The local layer contract customizes the corresponding tensor sharding management strategy and local recursive calculation rules according to the node type. Based on the preset tensor sharding rules, the initial tensor state is allocated to each node in the cluster, and an initial version vector is created for each tensor shard. Step 2: Periodically collect runtime status indicators of each node in the cluster, including node computing load, network communication quality between nodes, and access pattern indicators of each tensor fragment, and aggregate them to generate a cluster status vector. Step 3: Dynamically adjust contract parameters based on cluster state vector. Each node calculates local tensor update amount according to its local layer contract and generates version tag containing node identifier and logical timestamp. According to the rules defined by global layer contract, aggregate local tensor update amount in cluster, resolve conflicts based on version tag, generate globally consistent new tensor state and update each node replica. Step 4: Continuously record the recursive path log during the update process. When a node failure or communication anomaly is detected, backtrack to the most recent consistent state point based on the recursive path log, and use historical log data to predict and compensate for the missing update amount. Step 5: If the current recursive process meets the preset convergence condition or triggers an abnormal termination condition, the process is terminated and the final tensor state is output; otherwise, return to step 2 to continue iterating.
2. The contract recursion method for distributed tensor data update according to claim 1, characterized in that: In step two, when collecting runtime status indicators, computing power indicators are periodically collected through node agents, including tensor operation calculation time, memory utilization and processor utilization. The bidirectional latency and available bandwidth between nodes are measured through network probes. The counters in the tensor sharding management module are used to count the sharding update frequency and query dependency count to calculate the sharding access popularity.
3. The contract recursion method for distributed tensor data update according to claim 1, characterized in that: In step three, the specific steps for dynamically adjusting contract parameters are as follows: dynamically switch the cluster synchronization mode based on the network latency index in the cluster state vector. When the average latency between nodes exceeds the first threshold, switch to asynchronous or hybrid mode. When the latency is lower than the second threshold, switch back to synchronization mode. The hybrid mode refers to synchronous aggregation within a subset of computing nodes and asynchronous communication between subsets.
4. The contract recursion method for distributed tensor data update according to claim 1, characterized in that: In step three, when dynamically adjusting contract parameters, a reinforcement learning agent is used to construct a reward function based on cluster iteration efficiency and state consistency, and dynamically outputs and executes the adjustment actions for the learning rate and aggregation frequency parameters in the contract.
5. The contract recursion method for distributed tensor data update according to claim 4, characterized in that: The training mechanism for the reinforcement learning agent includes: The state space is a normalized representation of the cluster state vector; Action space refers to instructions for adjusting adjustable parameters in the contract; The reward function R is designed as follows: R = w1*E + w2*(1-D) - w3*C Where E is the reciprocal of the iteration efficiency, D is the maximum difference between the cluster tensor state versions, C is the network communication overhead, and w1, w2, and w3 are weight coefficients.
6. The contract recursion method for distributed tensor data update according to claim 1, characterized in that: In step three, when aggregating local tensor update quantities within the cluster, a gradient compression strategy is dynamically selected based on the network bandwidth and fragment access frequency in the cluster state vector. Sparse compression is used for high-frequency update fragments, while quantization or low-rank approximation compression is used for low-frequency update fragments.
7. The contract recursion method for distributed tensor data update according to claim 6, characterized in that: In the gradient compression strategy, the compression ratio r is adaptively determined. The target compression ratio is calculated according to the formula r = r_base * f(h) * g(b), where r_base is the base compression ratio, f(h) is a decreasing function of the fragment access popularity h, and g(b) is a decreasing function of the available bandwidth b. After decompression at the receiving end, the compression error is calculated and accumulated, and the accumulated error is added as a correction amount to the gradient calculated locally in the next round.
8. The contract recursion method for distributed tensor data update according to claim 1, characterized in that: In step three, when resolving conflicts based on version tags, a version vector is maintained for each tensor fragment. When a new update is received, a version comparison is performed. If there are concurrent conflicts, arbitration is conducted according to the rules defined in the local layer contract. For critical fragments, strong consistency arbitration based on the latest timestamp is used, and for non-critical fragments, eventual consistency arbitration based on node priority or merging algorithm is used.
9. The contract recursion method for distributed tensor data update according to claim 1, characterized in that: In step four, when using historical log data to predict and compensate for missing update amounts, the historical update sequence of the N consecutive rounds before the failure of the fault node is obtained from the distributed storage recursive path log, input into the pre-trained recurrent neural network prediction model, outputs the predicted value of the update amount of the missing rounds, and incorporates the predicted value as the compensation amount into the aggregation process of the current round.