Vertical federated learning system task scheduling method and device based on multi-entity collaboration and storage medium

Abstract

The invention discloses a vertical federated learning system task scheduling method and device based on multi-entity collaboration and a storage medium, and the method comprises the steps: obtaining the registration information of a plurality of suppliers, selecting task processing suppliers, carrying out the protocol adaption of each task processing supplier according to each registration information, and carrying out the task scheduling. And unifying the format of the federated learning model for each task processing supplier, and allocating a to-be-processed task to each task processing supplier. According to the method, through a dynamic protocol adaptation and model format unification mechanism, the problem of heterogeneity among multiple supplier nodes is solved, and the distribution efficiency and cooperation performance of the to-be-processed tasks in the vertical federal learning system composed of the multiple supplier nodes are remarkably improved; therefore, the same to-be-processed task can be selectively allocated to more suppliers to be processed, or the same to-be-processed task can be decomposed into more sub-tasks to be processed by different suppliers respectively, and dynamic task scheduling and heterogeneous compatible support are achieved. The method is widely applied to the technical field of communication.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a method, device and storage medium for scheduling tasks in a vertical federated learning system based on multi-entity collaboration. Background Art

[0002] With the rise of federated learning technology, vertical federated learning has gradually become an important model for achieving multi-party collaborative computing. In a vertical federated learning environment, different suppliers hold different dimensions of data, and the system achieves the goal of data sharing through joint model training. However, in a multi-supplier environment, the heterogeneity of supplier nodes (such as computing power, network characteristics, and protocol types) significantly increases the complexity of task allocation and execution. Summary of the invention

[0003] In view of the technical problems such as low task allocation and execution efficiency, poor collaboration and compatibility caused by the heterogeneity of the current vertical federated learning system, the purpose of the present invention is to provide a task scheduling method, device and storage medium for a vertical federated learning system based on multi-entity collaboration.

[0004] On the one hand, an embodiment of the present invention includes a vertical federated learning system task scheduling method based on multi-entity collaboration, and the vertical federated learning system task scheduling method based on multi-entity collaboration includes the following steps:

[0005] Obtaining registration information of each of a plurality of suppliers; each of the suppliers is in the same vertical federated learning system;

[0006] selecting at least some of the suppliers as task processing suppliers;

[0007] According to each of the registration information, protocol adaptation is performed on each of the task processing providers;

[0008] Unifying the format of the federated learning model for each of the task processing providers;

[0009] Allocate tasks to be processed to each of the task processing providers.

[0010] Further, the selecting at least some of the suppliers as task processing suppliers includes:

[0011] Obtaining the respective historical task processing records of each of the suppliers;

[0012] According to the historical task processing records, a task execution capability score is predicted;

[0013] Scoring and stratifying the suppliers according to their respective task execution capability scores;

[0014] According to the tasks to be processed, the supplier in the corresponding layer is determined as the task processing supplier.

[0015] Furthermore, performing protocol adaptation on each of the task processing providers according to each of the registration information includes:

[0016] According to each of the registration information, obtaining the respective scenario information of each of the task processing providers;

[0017] Determining the protocol type of the task processing provider according to the scenario information;

[0018] Dynamically load cross-protocol mapping rules to uniformly convert each of the protocol types into a standardized protocol.

[0019] Furthermore, the format of the federated learning model for each of the task processing providers is unified, including:

[0020] Invoke the model exchange tool;

[0021] The model exchange tool is used to convert the formats of the federated learning models run by each of the task processing providers into a standardized format.

[0022] Furthermore, the allocating the tasks to be processed to each of the task processing suppliers includes:

[0023] Decomposing the task to be processed into multiple subtasks;

[0024] Determining the allocation priority of the task processing supplier according to the layer in which the task processing supplier is located;

[0025] According to each of the allocation priorities, each of the subtasks is allocated to each of the task processing providers.

[0026] Furthermore, the vertical federated learning system task scheduling method based on multi-entity collaboration also includes:

[0027] After each of the task processing providers completes the execution of the task to be processed, obtaining user evaluation information;

[0028] Performing sentiment analysis on the user evaluation information to obtain sentiment information;

[0029] Based on the emotional information, each allocation priority is adjusted.

[0030] Furthermore, the allocating the tasks to be processed to each of the task processing suppliers includes:

[0031] Performing future load forecasting on the federated learning model run by the task processing provider to obtain a future load forecast value;

[0032] The allocation priorities are adjusted according to the future load prediction values.

[0033] Furthermore, the allocating the tasks to be processed to each of the task processing suppliers includes:

[0034] Obtaining privacy requirement information of the task to be processed;

[0035] According to the privacy requirement information, performing noise processing on the task to be processed; wherein the noise intensity added by the noise processing is positively correlated with the level of the privacy requirement information;

[0036] According to the privacy requirement information, container resources are allocated to the task to be processed; wherein the amount of the container resources is positively correlated with the level of the privacy requirement information.

[0037] On the other hand, an embodiment of the present invention also includes a computer device, including a memory and a processor, the memory is used to store at least one program, and the processor is used to load at least one program to execute the vertical federated learning system task scheduling method based on multi-entity collaboration in the embodiment.

[0038] On the other hand, an embodiment of the present invention also includes a computer-readable storage medium, which stores a program executable by a processor. When the program executable by the processor is executed by the processor, it is used to execute the vertical federated learning system task scheduling method based on multi-entity collaboration in the embodiment.

[0039] The beneficial effects of the present invention are as follows: the vertical federated learning system task scheduling method based on multi-entity collaboration in the embodiment solves the heterogeneity problem among multi-supplier nodes through dynamic protocol adaptation and model format unification mechanism, and significantly improves the allocation efficiency and collaboration performance of pending tasks in the vertical federated learning system composed of multi-supplier nodes, so that the same pending task can be selected to be assigned to more suppliers for processing, or can be decomposed into more subtasks for different suppliers to process, thereby realizing dynamic task scheduling and heterogeneous compatibility support. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 It is a schematic diagram of a communication system to which a vertical federated learning system task scheduling method based on multi-entity collaboration can be applied in an embodiment;

[0041] Figure 2 A schematic diagram of the steps of a vertical federated learning system task scheduling method based on multi-entity collaboration in an embodiment;

[0042] Figure 3 It is a schematic diagram of a task scheduling system of a vertical federated learning system based on multi-entity collaboration in an embodiment;

[0043] Figure 4 Schematic diagram of the process of a vertical federated learning system task scheduling method based on multi-entity collaboration in an embodiment. DETAILED DESCRIPTION

[0044] Terminology explanation:

[0045] 1. VFL (Vertical Federated Learning): Vertical federated learning, also known as longitudinal federated learning, is a federated learning model in which data is distributed among multiple participants in a vertical dimension. The parties only share model parameters to protect data privacy while achieving joint training.

[0046] 2.NRF (Network Repository Function): Core network function module, responsible for storing and managing supplier capability information, supporting dynamic query and task allocation.

[0047] 3.NWDAF (Network Data Analytics Function): Network data analysis function module, used to collect and analyze network performance data and task history data, and provide trend prediction and optimization suggestions.

[0048] 4.NEF (Network Exposure Function): Network exposure function module, responsible for supplier protocol adaptation, interface verification and model compatibility processing, ensuring seamless connection of multi-supplier collaboration.

[0049] 5. PCF (Policy Control Function): Policy control function module, responsible for task allocation, resource optimization and load balancing, dynamically adjusting task allocation strategy according to supplier capabilities and real-time network status.

[0050] 6.UPF (User Plane Function): User plane function module, which supports privacy protection, resource monitoring and containerized task management, and is the core support module for task execution.

[0051] 7.ONNX (Open Neural Network Exchange): Open neural network exchange format, used to unify the model formats of different deep learning frameworks and support cross-platform reasoning and training.

[0052] 8. Differential Privacy: A technology for protecting data privacy that ensures that the information of a single data point cannot be inferred by adding noise to the model parameters.

[0053] 9. Secure Multi-Party Computation (SMPC): Data encryption computing technology allows multiple parties to perform joint computing without sharing data, ensuring data privacy.

[0054] 10. Blockchain Evidence Storage: Use blockchain technology to store data records to ensure that the data cannot be tampered with and is traceable, and is used for trusted storage of supplier registration information and resource allocation logs.

[0055] 11. Task hierarchical management: Supplier nodes are divided into high priority, medium priority and backup levels according to supplier capability scores to adapt to different task demand scenarios.

[0056] 12. Dynamic load balancing: Adjust the task allocation strategy according to the real-time load status of the node to ensure maximum resource utilization and task execution efficiency.

[0057] 13. Time series analysis: Use models (such as ARIMA or LSTM) to analyze the time-varying trends of data to predict load fluctuations and resource requirements.

[0058] 14. Feedback-driven closed-loop optimization: Generate optimization suggestions based on user feedback and system logs, verify and improve optimization strategies, and form a dynamically adjusted closed-loop process.

[0059] 15. Multi-node collaboration: Decompose complex tasks into subtasks and assign them to different nodes to ensure synchronous management of data flow and task dependencies and improve task execution efficiency.

[0060] In this embodiment, the vertical federated learning system task scheduling method based on multi-entity collaboration can be applied to Figure 1 In the communication system shown. Figure 1 The communication system includes a 5G core network, a user terminal, and multiple federated learning model service providers such as provider 1, provider 2, ... provider n. The 5G core network includes network element modules such as NRF, NWDAF, NEF, PCF, UPF, and AF. In the communication system, the user terminal can request the 5G core network to establish a pending task, which can be a federated learning model training task, a data processing task performed using a trained federated learning model, etc. Figure 1 Each supplier in the same vertical federated learning system, that is, each supplier runs a federated learning model separately, and these federated learning models have been or will be trained in the same vertical federated learning. The 5G core network can assign the tasks to be processed to one or more suppliers.

[0061] In this embodiment, a supplier is also referred to as a node, which specifically refers to a device such as a server operated by the supplier.

[0062] The current federated learning technology has obvious deficiencies in heterogeneity management and dynamic support in a multi-vendor environment. For example, since the supplier nodes may use different communication protocols (such as RESTful, WebSocket, gRPC) and deep learning frameworks (such as TensorFlow, PyTorch), the system lacks an effective protocol adaptation and model compatibility verification mechanism, resulting in low cross-node collaboration efficiency. In addition, the current federated learning technology mainly relies on static resource allocation strategies, which makes it difficult to respond to changes in the resource status of supplier nodes in real time. It lacks dynamic task migration and load balancing methods, which reduces the system performance and flexibility in high-load or emergency scenarios. In terms of privacy protection and feedback optimization, the current federated learning technology has weak dynamic adjustment capabilities, and privacy protection methods (such as differential privacy and secure multi-party computing) lack dynamic support for the balance between protection strength and performance. At the same time, supplier registration information and task logs are mostly stored in a centralized manner, which is vulnerable to tampering or attack and lacks credibility. In addition, there is a lack of a closed-loop optimization mechanism based on user feedback. The system cannot dynamically adjust the task allocation strategy based on user subjective evaluation and actual operation results, and it is difficult to meet complex task requirements and changing network environments.

[0063] For example, Figure 1 In federated learning, different vendors may adopt multiple communication protocols such as RESTful, WebSocket or gRPC, and the model format may also rely on different deep learning frameworks (such as TensorFlow, PyTorch). These differences lead to huge challenges in the implementation of model compatibility and cross-vendor collaboration. At the same time, the dynamic volatility of vendor resources (such as bandwidth and computing power) further affects the efficiency of task allocation and execution stability. In addition, how to ensure the authenticity and security of vendor registration information and task execution logs and prevent data tampering or illegal use is also a key problem in the design of federated learning systems. If the task scheduling system is designed based on a static resource allocation mechanism, it will not be able to dynamically respond to changes in vendor capabilities or sudden high-load demands. At the same time, there is a lack of effective user feedback collection and closed-loop optimization mechanisms, and it is impossible to adjust the task allocation strategy according to the actual use effect. In addition, the increase in privacy protection requirements requires the use of more secure privacy computing technologies (such as differential privacy and secure multi-party computing) during task execution, which brings new challenges to resource utilization and task performance.

[0064] To address the above issues, we can design a dynamic task scheduling and resource optimization solution that supports a multi-supplier environment, use blockchain to ensure data credibility, use AI models to predict supplier capabilities and load trends, and combine dynamic protocol adaptation, containerized management, and user feedback optimization to build a federated learning system that is efficient, flexible, and secure.

[0065] Based on the above principles, in this embodiment, a vertical federated learning system task scheduling method based on multi-entity collaboration is provided. Figure 2 ,The task scheduling method of vertical federated learning system based on multi-entity collaboration includes the following steps:

[0066] S1. Obtain the registration information of multiple suppliers;

[0067] S2. selecting at least some of the suppliers as task processing suppliers;

[0068] S3. According to each registration information, protocol adaptation is performed for each task processing provider;

[0069] S4. Unify the format of federated learning models for each task processing provider;

[0070] S5. Allocate pending tasks to each task processing provider.

[0071] Figure 2 The vertical federated learning system task scheduling method based on multi-entity collaboration shown in Figure 3 In the vertical federated learning system task scheduling system shown in Figure 1, refer to Figure 3 The system includes supplier registration and capability management module, protocol adaptation and model compatibility module, task scheduling and resource optimization module, privacy protection and container management module, user feedback and closed-loop optimization module, and trend analysis and prediction module. The functions of each module are as follows:

[0072] Supplier registration and capability management module: This module is responsible for the registration, storage, scoring and dynamic management of supplier information, and provides support for task allocation. It includes four sub-modules: information collection, capability certification, capability scoring and stratification, and dynamic monitoring. First, the supplier's VFL client submits a unique supplier ID, computing power (CPU / GPU performance), network characteristics (bandwidth, latency), and model type (CNN, random forest, etc.) through NRF. Secondly, NWDAF uses blockchain technology to store supplier information to ensure the authenticity and non-tamperability of registration information. After that, NRF combines the AI ​​model with historical task data to score suppliers, and stratifies them into high priority, medium priority, and backup levels. Finally, NRF monitors resource utilization status through real-time communication with suppliers, and triggers dynamic adjustment of stratification status and alarm notifications.

[0073] Protocol adaptation and model compatibility module: This module ensures the compatibility of multi-vendor protocols and the standardization of model formats, and provides technical support for task execution. It includes four sub-modules: protocol adaptation, protocol verification, model conversion, and compatibility verification. NEF receives vendor protocol types (such as RESTful, gRPC), loads adaptation rules, and implements cross-protocol mapping. NEF verifies interface performance, reliability, and compatibility in an isolated test environment, and feeds the results back to NRF. NEF collaborates with edge computing nodes and calls the ONNX tool to convert the vendor model format into ONNX. NEF verifies the converted model, including core metadata checks and hardware compatibility tests, and generates reports that are synchronized to NRF and PCF.

[0074] Task scheduling and resource optimization module: This module dynamically allocates supplier nodes according to task requirements and optimizes resource usage. It includes four sub-modules: task allocation, load balancing, multi-node collaboration, and resource monitoring. PCF calls NRF to query capability information and allocates the optimal node based on priority, delay, and task complexity. PCF monitors the load status of supplier nodes in real time, dynamically adjusts task allocation, and triggers task migration when necessary. Complex tasks are decomposed and assigned to multiple nodes, and data flows and dependencies are managed through the synchronization scheduling module. UPF monitors CPU / GPU utilization, bandwidth and other indicators, and synchronizes resource status to NRF and PCF in real time to ensure the accuracy of resource allocation.

[0075] Privacy protection and container management module: This module ensures privacy protection and container management of task execution. It includes three sub-modules: privacy protection, container adjustment, and fault recovery. UPF dynamically adjusts differential privacy parameters or enables secure multi-party computing according to task requirements to protect data security. UPF dynamically adjusts container resource configuration according to task load to improve task processing efficiency. When an exception occurs in the container, UPF quickly restarts the task through the snapshot recovery function to reduce interruption time.

[0076] User feedback and closed-loop optimization module: Drive task optimization through user feedback to achieve closed-loop management. It includes four sub-modules: feedback collection, optimization suggestions, strategy verification, and self-learning. AF collects user subjective evaluations and system log data to extract high-priority issues. AF generates optimization suggestions based on log anomalies and feeds back to PCF and NRF. AF and NWDAF verify the effectiveness of the optimization strategy and analyze changes in user experience and performance data. Based on the strategy verification results, AF dynamically improves the optimization logic through a self-learning model.

[0077] Trend analysis and prediction module: This module provides forward-looking support for task allocation by predicting supplier load trends and resource requirements. It includes three sub-modules: load prediction, standby deployment, and log storage. NWDAF uses time series models (such as LSTM, ARIMA) to predict future load changes and notify PCF in advance to optimize the allocation strategy. NWDAF triggers UPF to deploy standby nodes in combination with predictions to expand task execution capabilities. NWDAF stores prediction and resource allocation logs in the blockchain to provide trusted data for system optimization and policy auditing.

[0078] In this embodiment, Figure 3 The vertical federated learning system task scheduling system shown can itself be a 5G core network, or the functions of each module therein can be implemented by calling a 5G core network to execute corresponding steps.

[0079] In this embodiment, the Figure 3 The vertical federated learning system task scheduling system shown in Figure 3 The structure of the 5G core network called by the vertical federated learning system task scheduling system and the process executed by its network elements are shown in Figure 4 shown. Figure 4 The process in is equivalent to executing Figure 2 The steps in the task scheduling method of the vertical federated learning system based on multi-entity collaboration are shown, and the processes executed by each network element in the 5G core network.

[0080] In this embodiment, step S1 corresponds to Figure 4 The process 1-2 in .

[0081] Reference Figure 4 In process 1, when the system starts, the supplier's VFL client first completes the registration process through NRF. Specifically, the supplier's VFL client submits registration information, which includes the unique supplier ID and its computing capability information (CPU / GPU performance, storage capacity), network characteristics (bandwidth, latency), supported model types (such as CNN, random forest), the type of protocol used (such as RESTful, WebSocket or gRPC) and its interface definition (such as JSON, Protobuf data format), etc. NRF can standardize this registration information into JSON format, store it in the NRF capability database, and support dynamic query.

[0082] Reference Figure 4In process 2, NWDAF uses blockchain technology to store the supplier ID and capability information in the registration information. Supplier registration triggers the smart contract, which records each registration and capability update operation and adds a timestamp to it to ensure that the data cannot be tampered with and is traceable. By executing process 2, the authenticity and reliability of supplier capability information can be guaranteed.

[0083] In this embodiment, when executing step S2, that is, selecting at least some suppliers as task processing suppliers, the following steps may be specifically performed:

[0084] S201. Obtain each supplier's respective historical task processing records;

[0085] S202. Based on the historical task processing records, predict the task execution capability score;

[0086] S203. Score and stratify suppliers according to their respective task execution capability scores;

[0087] S204. According to the tasks to be processed, determine the suppliers in the corresponding layer as the task processing suppliers.

[0088] In this embodiment, steps S201-S204 correspond to Figure 4 Process 3 in the NRF introduced a supplier capability stratification scoring and management mechanism to conduct multi-dimensional comprehensive scoring and dynamic stratification of registration information, thereby improving the accuracy of task allocation.

[0089] Reference Figure 4 In process 3, first, NRF can convert the capability information in the registration information provided by the supplier into a feature vector, input it into the AI ​​model to predict the supplier's task execution capability, and generate a prediction score (S AI , 0-100); secondly, NWDAF executes step S201 to obtain the historical task processing records of each supplier. The historical task processing records include task success rate (whether the task was completed on time in the past, with a weight of 50%), resource utilization rate (the actual utilization rate of CPU and bandwidth during the task, with a weight of 30%), and failure rate (the number of times the task failed or the performance did not meet the standard, with a weight of 20%). NWDAF can calculate the comprehensive performance of the supplier (S 历史 ). Finally, NRF executes step S203, combining the AI ​​model score and the historical data score to calculate the task execution capability score S (weight parameter:):

[0090] S=ω 1 *S AI +ω 2 *S 历史

[0091] Among them, ω 1 and ω 2 is the default weight parameter, ω 1 and ω 2 The value of can be adjusted dynamically according to the task requirements. For example, it can be set to ω 1 =0.6 and ω 2 =0.4.

[0092] Since each supplier has a task execution capability score S, when NRF executes step S203, it can classify suppliers into different levels according to the task execution capability score S. For example, if a supplier's task execution capability score S>80, then the supplier is classified as a high priority level; if a supplier's task execution capability score is between 60-80, then the supplier is classified as a medium priority level; if a supplier's task execution capability score <60, then the supplier is classified as a backup level.

[0093] When NRF executes step S204, it can determine the supplier in the corresponding layer as the task processing supplier according to the relationship between the supplier's layer and the attributes of the task to be processed. For example, for critical or urgent tasks to be processed, PCF can select a supplier in the high priority layer as the task processing supplier by calling the capability query interface provided by NRF; for regular tasks to be processed, a supplier in the medium priority layer can be selected as the task processing supplier; for tasks to be processed in non-critical or load balancing scenarios, a supplier in the backup layer can be selected as the task processing supplier.

[0094] By executing steps S201-S204, i.e., process 3, factors such as delay, computing power, network bandwidth, and task complexity of different suppliers can be comprehensively considered, and the most suitable supplier can be selected as the task processing supplier.

[0095] In addition, in steps S201-S204, i.e., process 3, the supplier's capability status can be continuously and dynamically monitored through real-time communication between NRF and the VFL client. When the supplier's resource utilization exceeds the threshold (such as GPU utilization > 90%), NRF can trigger a re-scoring and adjust the supplier's capability score and tiered status based on the latest data. At the same time, NRF combines the AI ​​model to regularly predict future changes in supplier capabilities (such as computing resource expansion or network bandwidth fluctuations) to optimize its tiered status and task priority. If the supplier's capabilities decline significantly (such as bandwidth reduction exceeding the threshold), NRF can trigger an alarm to notify PCF to adjust the allocation strategy to ensure the stability and success rate of task execution.

[0096] In this embodiment, when executing step S3, that is, performing protocol adaptation for each task processing provider according to each registration information, the following steps may be specifically performed:

[0097] S301. According to each registration information, obtain the scenario information of each task processing provider;

[0098] S302. Determine the protocol type of the task processing provider based on the scenario information;

[0099] S303. Dynamically load cross-protocol mapping rules to uniformly convert various protocol types into standardized protocols.

[0100] In this embodiment, steps S301-S303 correspond to Figure 4 Process 4 in Figure 4. NEF introduces a dynamic protocol adaptation rule loading and priority matching mechanism. According to the vendor's protocol type, it dynamically loads the adaptation rules and adjusts the priority in real time to adapt to the multi-protocol environment.

[0101] Reference Figure 4 In process 4, for each task processing supplier screened out by step S2, step S301 is executed to determine the scenario information of the registration information based on the registration information of each task processing supplier. For example, some task processing suppliers are in a high concurrency scenario, while other task processing suppliers are in a compatibility scenario, etc.

[0102] In step S302, the protocol type of the task processing provider can be determined based on the scenario information. For example, for a task processing provider whose scenario information is a high-concurrency scenario, the efficient gRPC can be preferentially selected as its protocol type; for a task processing provider whose scenario information is a compatibility scenario, the RESTful adaptation rule can be loaded as its protocol type; for a task processing provider whose scenario information is a network load peak, the more efficient gRPC can be switched to as its protocol type; for a task processing provider whose scenario information is a low-load scenario, the more compatible RESTful can be switched to as its protocol type.

[0103] If the task to be processed involves multiple suppliers using different protocols, for example, one task processing supplier uses RESTful as its protocol type and another task processing supplier uses WebSocket as its protocol type, NEF can execute step S303 to dynamically load cross-protocol mapping rules, thereby converting the respective protocol types of each task processing supplier into a standardized protocol, where the standardized protocol can specifically be a 5GC interface format (JSON-LD), etc., thereby achieving seamless collaboration between different task processing suppliers.

[0104] In this embodiment, when executing step S303, the NEF can trigger the protocol test linkage mechanism while the supplier's capabilities are exposed, and automatically trigger the protocol test process when the supplier registers its protocol interface through the NEF. NEF fully verifies the function, reliability and performance of the interface in an isolated test environment, including latency, throughput and compatibility testing. The test results are fed back to the NRF in the form of a report and serve as an important basis for task allocation and priority decision-making, further improving the accuracy and reliability of the system.

[0105] In this embodiment, when executing step S303, in terms of model compatibility, NEF collaborates with the edge computing node to convert the model formats of different suppliers (such as PyTorch, TensorFlow) into ONNX format by calling the ONNX conversion tool. At the same time, NEF extracts the core metadata information of the model (such as input / output shape, number of parameters, operator type, model size and hardware support), and verifies the compatibility of the converted model, including integrity check (whether the number of parameters is consistent), functional test (whether the output result error is within an acceptable range), and hardware support analysis (whether it is compatible with the target hardware platform). The verification results generate a compatibility report, which includes changes in model accuracy, performance comparisons and potential problems. The report is synchronized to NRF and PCF to provide data support for task scheduling and resource allocation.

[0106] In this embodiment, when executing step S303, NEF provides a multi-version management mechanism. When the model is updated, a unique identifier is generated for each version, and the metadata information of the model (including version number, update time, input / output shape, performance indicators, and compatibility verification results) is stored in the version library of NRF. When the task is executed, NEF dynamically selects the most appropriate model version according to the task requirements, such as using the best performance version for low-load scenarios and using a fully verified stable version for high-compatibility scenarios. In addition, NEF supports on-demand switching, which allows instant switching to the backup version according to actual performance or failure conditions during task operation to ensure the continuity and reliability of the task.

[0107] In this embodiment, when executing step S4, that is, unifying the format of the federated learning model for each task processing provider, the following steps may be specifically performed:

[0108] S401. Calling the model exchange tool;

[0109] S402. Use the model exchange tool to convert the formats of the federated learning models run by each task processing provider into a standardized format.

[0110] In this embodiment, steps S401-S402 correspond to Figure 4 Process 5 in .

[0111] Reference Figure 4 In process 5, NEF executes step S401 to coordinate the edge computing node to call the model exchange tool such as the ONNX conversion tool, and then executes step S402 to convert the format of the supplier's federated learning model into a standardized format such as the ONNX format, complete compatibility verification, and store the results in NRF.

[0112] By executing steps S401-S402, i.e., process 5, the vendor model format can be unified and hardware compatibility can be ensured, thereby improving the efficiency of cross-platform model reasoning and training.

[0113] Step S5 corresponds to Figure 4 In process 6 of Figure 1, NRF allocates pending tasks to each task processing provider. For example, latency-sensitive pending tasks can be preferentially allocated to provider nodes with low latency and high bandwidth, while computationally intensive pending tasks tend to be allocated to provider nodes with powerful GPUs or multi-core CPUs. To enhance scheduling accuracy, PCF uses a dynamic priority task scheduling strategy that combines historical task data with real-time resource status to ensure that tasks are always allocated to the optimal resource pool. In terms of resource optimization, PCF uses network slicing technology to allocate independent slice resources to high-priority tasks, isolating resource competition between critical tasks and ordinary tasks.

[0114] In this embodiment, by executing steps S1-S5, the heterogeneity problem among multi-supplier nodes is solved through dynamic protocol adaptation and model format unification mechanism, and the allocation efficiency and collaborative performance of pending tasks in the vertical federated learning system composed of multi-supplier nodes are significantly improved, so that the same pending task can be selected to be assigned to more suppliers for processing, or can be decomposed into more sub-tasks for different suppliers to process, thereby realizing dynamic task scheduling and heterogeneous compatibility support.

[0115] In this embodiment, when executing step S5, that is, the step of allocating tasks to be processed to each task processing supplier, the following steps may be specifically performed:

[0116] S501A. Decompose the task to be processed into multiple subtasks;

[0117] S502A. Determine the priority of the task processing supplier according to the layer in which the task processing supplier is located;

[0118] S503A. Allocate each subtask to each task processing supplier according to each allocation priority.

[0119] Steps S501A-S503A are the first execution mode of step S5.

[0120] In step S501A, for complex tasks to be processed (for example, tasks to be processed with a data volume greater than a threshold, etc.), PCF decomposes the tasks to be processed into multiple subtasks, executes steps S502A-S503A, and preferentially assigns the subtasks to high-priority task processing suppliers. When the high-priority task processing suppliers are underloaded, the subtasks are preferentially assigned to medium-priority task processing suppliers. When the medium-priority task processing suppliers are underloaded, the subtasks are preferentially assigned to backup-level task processing suppliers, and the data flow and dependencies of the subtasks are managed through the synchronous scheduling module.

[0121] In this embodiment, when executing step S5, that is, the step of allocating tasks to be processed to each task processing supplier, the following steps may be specifically performed:

[0122] S501B. Perform future load forecasting on the federated learning model run by the task processing provider to obtain a future load forecast value;

[0123] S502B. Adjust each allocation priority according to each future load prediction value.

[0124] Steps S501B-S502B are the second execution mode of step S5. Steps S501B-S502B correspond to Figure 4 Processes 7, 8 and 12 in.

[0125] Specifically, when executing step S501B, NWDAF uses a time series analysis model (such as ARIMA or LSTM) to combine historical task loads and real-time network data to predict the future load trends of each task processing provider node and obtain the future load forecast value of each task processing provider.

[0126] When executing step S502B, during holidays or traffic peaks, NWDAF recommends PCF to adjust the task allocation strategy in advance based on the prediction results, and reserve bandwidth and computing resources for critical tasks to ensure high-quality execution of services; for sudden task demands, NWDAF combines short-term load fluctuation predictions to trigger the UPF mechanism to dynamically deploy backup components; when potential task peaks are detected, NWDAF automatically recommends expanding computing nodes or bandwidth resources to quickly respond to sudden task allocation demands.

[0127] During the execution of step S502B, PCF continuously monitors the load status of the supplier node and adjusts the task allocation in combination with the dynamic load balancing algorithm (such as Least Connection). When the number of connections of the optimal node is lower than the preset threshold (80% of the maximum number of connections), the task is directly allocated; if all nodes are close to the load limit, PCF enables the dynamic migration mechanism to balance the task to the backup node. For complex tasks that require the collaboration of multiple supplier nodes, PCF first decomposes the task into subtasks and allocates the most suitable node for each subtask (selecting different nodes based on computing power, bandwidth or delay requirements). PCF creates a dependency graph of subtasks, clarifies the data flow and execution order between subtasks, and monitors the task progress of each node in real time. Through the synchronous scheduling module, PCF ensures that all subtasks complete data exchange and processing within the specified time window, and adjusts the task priority or reallocates resources for delayed or resource-deficient nodes in a timely manner to avoid overall task failure. This mechanism ensures the efficient execution of collaborative tasks and the synchronization between nodes through unified progress management and dynamic scheduling, and provides strong support for complex task collaboration in a multi-supplier environment.

[0128] In addition, after NWDAF completes the task load forecast each time after executing steps S501B-S502B, it compares the predicted value with the actual load data, calculates the error index (such as mean square error or mean absolute percentage error), and feeds these errors back to the model optimization module. For scenarios with large errors, NWDAF automatically adjusts the time series model (such as ARIMA parameters) or switches to a model that is more suitable for the scenario (such as LSTM), and trains a new model version based on historical data and current scenario characteristics to further enhance its adaptability. In order to ensure the credibility of the forecast and allocation data, after generating the task load forecast or resource allocation plan, NWDAF packages key information (such as forecast model, parameter configuration, forecast results, allocation strategy and execution feedback) into blockchain transactions and stores them in distributed blocks between nodes. These logs include not only the detailed data of the forecast, but also the effect indicators after the resource allocation is executed (such as task success rate and delay reduction). During the load forecasting process, NWDAF uses the time series analysis model to predict the trend of resource usage (such as CPU / GPU utilization and bandwidth occupancy) of each node. When it is detected that the load of a node is about to exceed the set threshold (such as CPU utilization exceeding 85% or bandwidth occupancy approaching saturation), NWDAF triggers the early warning mechanism, marks the node as high risk, and sends the early warning information to PCF (Policy Control Function) in real time. PCF adjusts the task allocation strategy based on the early warning, assigns new tasks to nodes with lower loads first, and evaluates the migration needs of high-load nodes at the same time, actively transferring some tasks to balance the overall resource pressure.

[0129] In this embodiment, when executing step S5, that is, the step of allocating tasks to be processed to each task processing supplier, the following steps may be specifically performed:

[0130] S501C. Obtain the privacy requirement information of the task to be processed;

[0131] S502C. According to the privacy demand information, the task to be processed is subjected to noise processing; wherein the noise intensity increased by the noise processing is positively correlated with the level of the privacy demand information;

[0132] S503C. Allocate container resources to the tasks to be processed according to the privacy requirement information; wherein the amount of container resources is positively correlated with the level of the privacy requirement information.

[0133] Steps S501C-S503C are the third execution mode of step S5. Steps S501C-S503C correspond to Figure 4 Process 9 in .

[0134] In step S501C, the privacy requirement information of the task to be processed may be set by the user terminal and other aspects, and the level of the privacy requirement of the task to be processed may be determined according to the privacy requirement information.

[0135] When the task privacy requirement is high, UPF can execute step S502C to increase the noise intensity of the task to be processed to improve the privacy protection effect; when the task privacy requirement is low, if the task to be processed will have a significant impact on the convergence effect of the federated learning model, UPF executes step S502C to dynamically reduce the noise intensity of the task to be processed to optimize the model performance. This mechanism combines the model gradient changes and training errors federated by real-time feedback, and ensures that the noise adjustment is performed within the global privacy budget through differential privacy budget management. In addition, UPF generates a privacy report at each noise adjustment, including the current noise level, privacy loss (ε value) and model performance indicators, and the report is synchronized to NRF to provide data support for subsequent task optimization.

[0136] In step S503C, UPF dynamically allocates container resources according to the computational and privacy requirements of the task. For example, if the privacy requirement information indicates that the task to be processed is a computationally intensive task (the level of privacy requirements is low), UPF automatically expands the container resources (such as increasing CPU cores and memory allocation) to ensure high-performance processing; if the privacy requirement information indicates that the task to be processed is a privacy task (the level of privacy requirements is high), UPF provides a container environment with a higher isolation level to avoid resource interference between tasks and potential data leakage. During the execution of step S503C, UPF monitors the resource usage of the container in real time. When it detects that resources are tight or the task load is too high, it triggers the dynamic adjustment mechanism of the container, such as merging containers of low-priority tasks to release resources, or migrating containers to other nodes to ensure the stability of critical tasks. In addition, UPF supports snapshot-based task fault recovery. When an abnormality occurs in the container, the task container can be quickly restarted from the backup node to minimize the interruption time.

[0137] In this embodiment, if the privacy requirement information indicates that the task to be processed belongs to a privacy task (the level of privacy requirement is high), the UPF can first encrypt the task to be processed (or the subtasks decomposed into the task to be processed) locally, and synthesize the preliminary encryption results into intermediate aggregated data through local aggregation to reduce the amount of data transmission; then, the UPF uploads the encrypted intermediate results to the PCF to complete the final aggregation operation at the global level. PCF can assign each encrypted subtask to the corresponding task processing supplier for processing, and the UPF combines key distribution and verification technology (such as secret sharing and homomorphic encryption) to distribute keys to the task processing supplier, so that the task processing supplier can decrypt and process each received subtask, and encrypt the processing results and send them back to the PCF, thereby ensuring the security and consistency of the data of the task to be processed in the entire aggregation process. In terms of resource management, UPF continuously monitors key indicators such as CPU / GPU utilization, memory usage, bandwidth usage, and network latency of the node, and synchronizes the resource status to NRF through lightweight protocols (such as gRPC). NRF performs standardized processing and aggregate analysis on the collected resource data, and provides a real-time query interface to PCF to support task allocation decisions. When node resources are close to the threshold (CPU utilization exceeds 85%), PCF adjusts the task allocation strategy based on the synchronized status information, assigning new tasks to nodes with lower loads or triggering task migration. This mechanism supports dynamic switching of privacy strengths at different levels: for tasks with higher privacy requirements, full local encryption and global aggregation modes are enabled; when privacy requirements are relatively low, local encryption operations can be reduced to improve computing efficiency.

[0138] In this embodiment, after executing steps S1-S5, the following steps may also be executed:

[0139] S6. After each task processing provider completes the execution of the pending tasks, obtain user evaluation information;

[0140] S7. Perform sentiment analysis on user evaluation information to obtain sentiment information;

[0141] S8. Adjust the priority of each allocation based on the emotional information.

[0142] Steps S6-S8 correspond to Figure 4 10 and 11 in FIG.

[0143] Reference Figure 4 In process 10, in step S6, AF is expanded to the central module for user feedback collection and closed-loop optimization. After the task is completed, multimodal data fusion is used to analyze user feedback and system performance to provide support for optimization decisions. In step S7, the user submits subjective user evaluation information (such as "task delay is too high" or "execution speed is slow") through AF, and the system log records the anomalies in task execution (such as timeout or failure rate). AF uses sentiment analysis and keyword extraction algorithms to parse the emotional intensity and expression content in the feedback, thereby identifying emotional information such as "task delay is too high" or "service is unavailable" that indicates high-priority issues.

[0144] Reference Figure 4 In process 11, step S8, for feedback with strong emotions or containing serious performance issues, AF automatically assigns a higher processing priority and marks the result as a critical issue to trigger optimization suggestions. To ensure accuracy, AF verifies the consistency of the feedback content in combination with log exceptions (such as task timeouts or failure records), and generates an analysis report containing priority annotations and synchronizes it to PCF and NRF. After the optimization strategy is implemented, AF jointly analyzes changes in user feedback (such as score improvement, latency reduction) and system performance indicators (such as task success rate, exception frequency) with NWDAF to verify whether the optimization has achieved the expected goals. AF uses these verification results to update the optimization rules, and at the same time trains the strategy generation algorithm through a self-learning model (such as reinforcement learning) to enable it to dynamically adjust the optimization suggestion generation logic. For example, when an optimization measure has a significant effect on improving the latency problem, the system automatically applies it to similar scenarios; if the effect is not ideal, the system will lower its priority and try other solutions.

[0145] pass Figure 4As shown in the process, the task scheduling method of the vertical federated learning system based on multi-entity collaboration in this embodiment solves the shortcomings of the current vertical federated learning system in heterogeneity management and dynamic support, and realizes seamless collaboration among multi-supplier nodes by introducing dynamic protocol adaptation and model format unification mechanism; unifies the model format through the ONNX tool, and combines the protocol verification module to ensure the compatibility of multiple protocol types (such as RESTful, gRPC) and model frameworks (such as TensorFlow, PyTorch); at the same time, monitors the resource status of the supplier nodes in real time, combines the AI ​​model prediction capability trend, optimizes the task allocation and migration strategy, and improves the system's responsiveness and flexibility in high load or emergency scenarios. In addition, the task scheduling method of the vertical federated learning system based on multi-entity collaboration in this embodiment also improves the security and privacy protection capabilities of the system through dynamic privacy protection and data trusted storage mechanism; proposes dynamic differential privacy adjustment and multi-party computing hierarchical aggregation mechanism to optimize task performance while ensuring data security; uses blockchain to store supplier registration information and task execution logs to ensure data authenticity and non-tamperability; at the same time, combined with user feedback and system log analysis, dynamically generates optimization suggestions and verifies the effects, continuously improves strategies through self-learning mechanisms, and builds a feedback-driven closed-loop optimization system to adapt to complex task requirements and improve user experience.

[0146] pass Figure 4 According to the process shown in FIG. 1 , the vertical federated learning system task scheduling method based on multi-entity collaboration and the vertical federated learning system task scheduling system based on multi-entity collaboration in this embodiment can implement the following mechanisms:

[0147] 1. Multi-dimensional supplier capability management and dynamic stratification mechanism: Propose a supplier capability scoring and stratification strategy based on AI models and historical task data to achieve dynamic management of supplier resources and accurate task allocation.

[0148] 2. Cross-protocol adaptation and unified interface mapping rule mechanism: Support dynamic adaptation of multiple protocol types (such as RESTful, gRPC), and achieve seamless collaboration among multiple suppliers through standardized interface formats (such as JSON-LD).

[0149] 3. Model format unification and compatibility verification mechanism: Use ONNX conversion tools and metadata verification mechanism to unify vendor model formats and ensure hardware compatibility, improving the efficiency of cross-platform model reasoning and training.

[0150] 4. Dynamic task scheduling and load balancing mechanism: Based on the supplier capability score and real-time load status, the task allocation strategy is dynamically adjusted, and the task execution efficiency is ensured through hierarchical scheduling and load balancing algorithms.

[0151] 5. Privacy protection and container management combination mechanism: Protect data security through differential privacy and secure multi-party computing technology, and combine containerization technology to achieve task isolation, dynamic resource allocation and fault recovery.

[0152] 6. User feedback-driven closed-loop optimization process mechanism: Combine user subjective evaluation with system logs to generate optimization suggestions and verify the optimization effect. Improve the strategy generation logic through self-learning mechanism to form a dynamic closed-loop optimization.

[0153] 7. Forward-looking resource management mechanism based on trend prediction: Use time series analysis models to predict future load changes, deploy backup resources in advance and optimize resource allocation strategies to ensure service stability under peak load scenarios.

[0154] 8. Blockchain-enhanced data trust storage mechanism: Blockchain technology is used to store supplier registration information, task prediction and allocation logs to ensure the authenticity and traceability of data, providing a reliable basis for optimization and auditing.

[0155] 9. Task decomposition and synchronous scheduling mechanism for multi-node collaboration: complex tasks are decomposed into subtasks, assigned to multiple nodes and managed uniformly through a synchronous scheduling module to ensure task execution efficiency and consistency of collaboration between nodes.

[0156] 10. Real-time resource status feedback and dynamic migration mechanism: By real-time monitoring of the supplier node resource status and combining dynamic migration strategies, tasks are balanced from high-load nodes to backup nodes to ensure the continuity and stability of task execution.

[0157] A computer program that executes the vertical federated learning system task scheduling method based on multi-entity collaboration in this embodiment can be written and written into a computer device or storage medium. When the computer program is read out and executed, the vertical federated learning system task scheduling method based on multi-entity collaboration in this embodiment is executed, thereby achieving the same technical effect as the vertical federated learning system task scheduling method based on multi-entity collaboration in the embodiment.

[0158] It should be noted that, unless otherwise specified, when a feature is referred to as being "fixed" or "connected" to another feature, it may be directly fixed or connected to the other feature, or it may be indirectly fixed or connected to the other feature. In addition, the descriptions of up, down, left, right, etc. used in the present disclosure are only relative to the relative positional relationship of the components of the present disclosure in the accompanying drawings. The singular forms of "a", "" and "the" used in the present disclosure are also intended to include the plural forms, unless the context clearly indicates other meanings. In addition, unless otherwise defined, all technical and scientific terms used in this embodiment have the same meaning as those generally understood by those skilled in the art. The terms used in the specification of this embodiment are only for describing specific embodiments and are not intended to limit the present invention. The term "and / or" used in this embodiment includes any combination of one or more related listed items.

[0159] It should be understood that, although the term first, second, third etc. may be adopted to describe various elements in the present disclosure, these elements should not be limited to these terms. These terms are only used to distinguish the same type of elements from each other. For example, without departing from the scope of the present disclosure, the first element may also be referred to as the second element, and similarly, the second element may also be referred to as the first element. The use of any and all examples or exemplary language ("for example", "such as" etc.) provided by the present embodiment is only intended to better illustrate embodiments of the present invention, and unless otherwise required, the scope of the present invention will not be limited.

[0160] It should be appreciated that embodiments of the present invention may be implemented or enforced by computer hardware, a combination of hardware and software, or by computer instructions stored in a non-transitory computer-readable memory. The method may be implemented in a computer program using standard programming techniques - including a non-transitory computer-readable storage medium configured with a computer program, wherein the storage medium so configured causes the computer to operate in a specific and predefined manner - according to the methods and drawings described in the specific embodiments. Each program may be implemented in a high-level procedural or object-oriented programming language to communicate with a computer system. However, if desired, the program may be implemented in assembly or machine language. In any case, the language may be a compiled or interpreted language. In addition, the program may be run on a programmed dedicated integrated circuit for this purpose.

[0161] In addition, the operations of the process described in this embodiment may be performed in any suitable order, unless otherwise indicated in this embodiment or otherwise clearly contradicted by the context. The process described in this embodiment (or variations and / or combinations thereof) may be performed under the control of one or more computer systems configured with executable instructions, and may be implemented as a code (e.g., executable instructions, one or more computer programs, or one or more applications) executed on one or more processors in common, by hardware or a combination thereof. A computer program includes a plurality of instructions that may be executed by one or more processors.

[0162] Further, the method can be implemented in any type of computing platform that is operably connected to a suitable computer, including but not limited to a personal computer, a minicomputer, a mainframe, a workstation, a network or distributed computing environment, a separate or integrated computer platform, or in communication with a charged particle tool or other imaging device, etc. Various aspects of the present invention can be implemented in machine-readable code stored on a non-transitory storage medium or device, whether removable or integrated into a computing platform, such as a hard disk, an optical read and / or write storage medium, a RAM, a ROM, etc., so that it can be read by a programmable computer, and when the storage medium or device is read by the computer, it can be used to configure and operate the computer to perform the process described herein. In addition, the machine-readable code, or part thereof, can be transmitted via a wired or wireless network. When such media includes instructions or programs that implement the above steps in conjunction with a microprocessor or other data processor, the invention of this embodiment includes these and other different types of non-transitory computer-readable storage media. When programmed according to the methods and techniques of the present invention, the present invention also includes the computer itself.

[0163] The computer program can be applied to input data to perform the functions of the present embodiment, thereby converting the input data to generate output data stored in a non-volatile memory. The output information can also be applied to one or more output devices such as a display. In a preferred embodiment of the present invention, the converted data represents a physical and tangible object, including a specific visual depiction of the physical and tangible object produced on the display.

[0164] The above are only preferred embodiments of the present invention. The present invention is not limited to the above embodiments. As long as the technical effects of the present invention are achieved by the same means, any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included in the scope of protection of the present invention. Within the scope of protection of the present invention, its technical solutions and / or implementation methods may have various modifications and changes.

Claims

1. A task scheduling method for a vertical federated learning system based on multi-entity collaboration, characterized in that: The vertical federated learning system task scheduling method based on multi-entity collaboration includes: Obtaining registration information of each of a plurality of suppliers; each of the suppliers is in the same vertical federated learning system; selecting at least some of the suppliers as task processing suppliers; According to each of the registration information, protocol adaptation is performed on each of the task processing providers; Unifying the format of the federated learning model for each of the task processing providers; Allocate tasks to be processed to each of the task processing providers.

2. The method for scheduling tasks in a vertical federated learning system based on multi-entity collaboration according to claim 1 is characterized in that: The selecting at least some of the suppliers as task processing suppliers comprises: Obtaining the respective historical task processing records of each of the suppliers; According to the historical task processing records, a task execution capability score is predicted; Scoring and stratifying the suppliers according to their respective task execution capability scores; According to the tasks to be processed, the supplier in the corresponding layer is determined as the task processing supplier.

3. The method for scheduling tasks in a vertical federated learning system based on multi-entity collaboration according to claim 1 is characterized in that: The step of performing protocol adaptation on each of the task processing providers according to each of the registration information includes: According to each of the registration information, obtaining the respective scenario information of each of the task processing providers; Determining the protocol type of the task processing provider according to the scenario information; Dynamically load cross-protocol mapping rules to uniformly convert each of the protocol types into a standardized protocol.

4. The method for scheduling tasks in a vertical federated learning system based on multi-entity collaboration according to claim 1 is characterized in that: The format of the federated learning model for each of the task processing providers is unified, including: Invoke the model exchange tool; The model exchange tool is used to convert the formats of the federated learning models run by each of the task processing providers into a standardized format.

5. The method for scheduling tasks in a vertical federated learning system based on multi-entity collaboration according to claim 2 is characterized in that: The allocating tasks to be processed to each of the task processing suppliers comprises: Decomposing the task to be processed into multiple subtasks; Determining the allocation priority of the task processing supplier according to the layer in which the task processing supplier is located; According to each of the allocation priorities, each of the subtasks is allocated to each of the task processing providers.

6. The method for scheduling tasks in a vertical federated learning system based on multi-entity collaboration according to claim 5 is characterized in that: The vertical federated learning system task scheduling method based on multi-entity collaboration also includes: After each of the task processing providers completes the execution of the task to be processed, obtaining user evaluation information; Performing sentiment analysis on the user evaluation information to obtain sentiment information; Based on the emotional information, each allocation priority is adjusted.

7. The method for scheduling tasks in a vertical federated learning system based on multi-entity collaboration according to claim 5 is characterized in that: The allocating tasks to be processed to each of the task processing suppliers comprises: Performing future load forecasting on the federated learning model run by the task processing provider to obtain a future load forecast value; The allocation priorities are adjusted according to the future load prediction values.

8. The method for scheduling tasks in a vertical federated learning system based on multi-entity collaboration according to claim 1, characterized in that: The allocating tasks to be processed to each of the task processing suppliers comprises: Obtaining privacy requirement information of the task to be processed; According to the privacy requirement information, performing noise processing on the task to be processed; wherein the noise intensity added by the noise processing is positively correlated with the level of the privacy requirement information; According to the privacy requirement information, container resources are allocated to the task to be processed; wherein the amount of the container resources is positively correlated with the level of the privacy requirement information.

9. A computer device, characterized in that: It includes a memory and a processor, the memory is used to store at least one program, and the processor is used to load at least one program to execute the vertical federated learning system task scheduling method based on multi-entity collaboration as described in any one of claims 1-8.

10. A computer-readable storage medium storing a program executable by a processor, characterized in that: The processor-executable program is used to execute the vertical federated learning system task scheduling method based on multi-entity collaboration as described in any one of claims 1-8 when executed by the processor.

Images