Financial edge computing power dynamic scheduling and vertical model lightweight deployment system
Patent Information
- Application Number
- CN202611277745.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-21
- Publication Date
- 2026-11-03
Smart Images

Figure CN123030356A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of intelligent deployment technology, specifically to a system for dynamic scheduling of financial edge computing power and lightweight deployment of vertical models. Background Technology
[0002] In financial scenarios, tasks such as real-time risk control, intelligent marketing, and high-frequency trading have stringent requirements for low-latency response and high data security, while also involving the distributed operation of a large number of vertical domain models on heterogeneous edge nodes.
[0003] Existing scheduling solutions largely rely on centralized resource managers, using heuristic rules or simple threshold strategies to allocate tasks. This makes it difficult to comprehensively capture the dependencies between tasks, the network heterogeneity between edge nodes, and the reusability of deployed AI assets. Consequently, scheduling decisions lack global foresight, easily leading to node load imbalances and inference latency fluctuations. For model deployment, conventional containerization or virtualization methods distribute complete model images to edge nodes without fully considering the limitations of edge devices in terms of computing power, memory bandwidth, and storage capacity. Furthermore, they lack dynamic identification and trimming mechanisms for model structural redundancy. Simultaneously, model lightweighting often employs static offline methods, failing to adaptively adjust based on task priority, service level agreement constraints, and real-time memory hot / cold distribution.
[0004] In summary, there is an urgent need for a systematic solution that can achieve coordinated linkage between task scheduling, asset deployment, and lightweight modeling to address the technical problem of poor task coordination balance under limited edge resources, which makes it difficult to meet the financial-grade reliability requirements for overall resource utilization and task assurance. Summary of the Invention
[0005] This application provides a dynamic scheduling system for financial edge computing power and a lightweight deployment system for vertical models. It is designed to address the technical problem in existing technologies where poor task coordination and balance under limited edge resources leads to difficulties in meeting the overall resource utilization and task assurance requirements for financial-grade reliability.
[0006] In view of the above problems, this application provides a system for dynamic scheduling of computing power at the financial edge and lightweight deployment of vertical models.
[0007] This application provides a dynamic scheduling system for financial edge computing power and a lightweight deployment system for vertical models. The system includes: an extraction module: constructing a heterogeneous graph that integrates task dependencies, edge node resource attributes, and the distribution status of reusable AI assets; periodically executing multi-round structure-aware message passing; and extracting embedded representations of the execution feasibility of each task in the heterogeneous edge environment. A decision module: establishing a memory semantic awareness channel between the scheduler and edge nodes; obtaining the memory resource occupancy distribution and sharing type of each edge node in real time; and making task scheduling and asset deployment decisions within the scheduler based on the embedded representations to determine a scheduling scheme. The scheduling scheme includes an allocation scheme for tasks to edge nodes and a deployment scheme for AI assets to edge nodes. A deployment module: using the Contract Network protocol to schedule and configure the scheduling scheme. The Contract Network protocol optimizes the protocol using protocol requests and protocol-level metadata. If the protocol execution process meets the refactoring trigger conditions in the protocol, lightweight processing based on structured sparsity and differential privacy is performed on the AI assets to be deployed.
[0008] One or more technical solutions provided in this application have at least the following technical effects or advantages: The financial edge computing power dynamic scheduling and vertical model lightweight deployment system provided in this application embodiment constructs a heterogeneous graph that integrates task dependencies, edge node resource attributes, and the distribution status of reusable AI assets. It periodically executes multi-round structure-aware message passing, extracts embedded representations of the execution feasibility of each task in the heterogeneous edge environment, establishes a memory semantic awareness channel between the scheduler and edge nodes, and obtains the memory resource occupancy distribution and sharing type of each edge node in real time. Based on the embedded representations, the scheduler makes task scheduling and asset deployment decisions to determine the scheduling scheme. Using the Contract Network protocol, the scheduling scheme is scheduled and configured for management. This system addresses the technical problem in existing technologies where poor task coordination balance under limited edge resources leads to insufficient overall resource utilization and task assurance rates to meet financial-grade reliability requirements. It effectively improves overall resource utilization and task assurance rates. Attached Figure Description
[0009] Figure 1 This application provides a flowchart illustrating the dynamic scheduling of financial edge computing power and the lightweight deployment of vertical models.
[0010] Figure 2 This application provides a schematic diagram of the system structure for dynamic scheduling of financial edge computing power and lightweight deployment of vertical models.
[0011] Figure labeling: Extraction module 11, Decision module 12, Deployment module 13. Detailed Implementation
[0012] This application provides a dynamic scheduling system for financial edge computing power and a lightweight deployment system for vertical models to address the technical problem in existing technologies where task coordination and balance are poor under limited edge resources, resulting in the overall resource utilization and task assurance rate failing to meet financial-grade reliability requirements.
[0013] Example: Figure 1 , Figure 2 As shown, this application provides a system for dynamic scheduling of financial edge computing power and lightweight deployment of vertical models. The system includes: Extraction Module 11: Constructs a heterogeneous graph that integrates task dependencies, edge node resource attributes, and the distribution status of reusable AI assets, periodically executes multi-round structure-aware message passing, and extracts the embedded representation of the execution feasibility of each task in the heterogeneous edge environment.
[0014] In this embodiment of the application, when constructing the heterogeneous graph, all objects participating in the scheduling are first incorporated into a unified graph structure, specifically including three types of heterogeneous nodes: multiple task nodes to be scheduled, all edge nodes providing computing resources, and AI assets cached on each edge node.
[0015] Based on this, edge connections are established between any two nodes according to the actual existing relationships. Specifically, task nodes are connected through task dependency edges, which carry execution order constraint information to characterize the data or control dependencies between tasks. Task nodes and edge nodes are connected through inter-node edges, which carry network latency and available bandwidth information to quantify the communication overhead when a task migrates to the corresponding edge node. Task nodes or edge nodes and AI assets are connected through asset dependency edges, which carry cache residency status information to indicate whether the corresponding AI asset has been cached locally on the target edge node, thereby affecting the asset loading cost during task execution.
[0016] Through the above methods, a heterogeneous graph is formed that integrates task dependencies, edge node resource attributes, and the distribution status of reusable AI assets. This heterogeneous graph uses a unified data structure to fully depict the multi-dimensional heterogeneous information involved in scheduling decisions.
[0017] Subsequently, multi-round structure-aware message passing is periodically executed to extract embedded representations of the execution feasibility of each task in a heterogeneous edge environment.
[0018] Specifically, each round of message passing executes three different types of neighbor aggregation operations in a predefined order. The first aggregation transmits local information among nodes of the same type. Specifically, each task node aggregates information from its predecessor and successor task nodes on its dependent chain to obtain the overall execution progress and concurrency constraints of the task chain. At the same time, each AI asset node aggregates cached task node information to obtain the cache state distribution.
[0019] The second aggregation passes cache hit availability information through asset-dependent edges. Specifically, task nodes aggregate the dwell status of cached AI asset nodes along asset-dependent edges to perceive the distance and loading cost of available assets on each edge node.
[0020] The third aggregation transmits task migration cost information through physical edges between nodes. Specifically, task nodes aggregate the available computing resources and network latency of directly connected edge nodes along the edges between nodes to assess the transmission overhead of migrating tasks to different edge nodes.
[0021] After multiple rounds of the above triple aggregation iterations, message passing is fully diffused throughout the entire graph, and the embedding representations of each task node gradually converge. Finally, a quantitative embedding vector is output for the feasibility of each task node to execute on each edge node. The embedding vector integrates task dependency constraints, asset cache hit prediction, and network transmission cost, providing a quantitative basis for global awareness for subsequent scheduling decisions.
[0022] Furthermore, the extraction module 11 includes: Heterogeneous graph construction unit: Periodically reads multiple task nodes, all edge nodes, and all cached AI assets, and incorporates them into a unified graph as three types of heterogeneous nodes to obtain a heterogeneous graph. Among them, task-dependent edges carry execution order constraints, node-to-node edges carry network latency and bandwidth information, and asset-dependent edges carry cache residency status. Information extraction unit: Performs multiple rounds of information transmission analysis on the heterogeneous graph and outputs an embedded representation of the feasibility of each task node to execute on each edge node.
[0023] In this embodiment, the heterogeneous graph construction unit periodically reads multiple task nodes to be scheduled, all edge nodes, and the AI assets cached on each edge node, and incorporates these three types of heterogeneous nodes into a unified graph structure to obtain a heterogeneous graph.
[0024] The heterogeneous graph contains three types of edges: task-dependent edges, inter-node edges, and asset-dependent edges. Task-dependent edges connect two task nodes with a dependency relationship and carry execution order constraint information, specifically including the time constraint that the predecessor task must be completed before the successor task starts, to ensure the orderly execution of tasks. Inter-node edges connect task nodes and edge nodes, carrying network latency and available bandwidth information to quantify the communication overhead when a task migrates from its current location to the corresponding edge node. Asset-dependent edges connect task nodes and AI asset nodes, carrying cache residency status information.
[0025] Optionally, the cache residency status indicates whether the corresponding AI asset has been cached locally on the target edge node in the form of a binary identifier or timestamp. If the cache is not hit, the asset transmission cost will need to be added during subsequent deployment.
[0026] By constructing the above three types of nodes and three types of edges, the task dependencies on which scheduling decisions depend, the resource attributes of edge nodes, and the distribution status of reusable AI assets are integrated into the same graph structure.
[0027] Subsequently, after the heterogeneous graph is constructed, the information extraction unit performs multiple rounds of neighbor aggregation operations on the graph, with each round of aggregation following a fixed order of three transmissions. Specifically, this includes transmitting local information between nodes of the same type, transmitting cache hit availability information through asset dependency edges, and finally transmitting task migration cost information through physical edges between nodes.
[0028] After multiple rounds of the above triple aggregation iteration, the message is fully diffused throughout the entire graph, and the embedding representation of each task node gradually converges. Finally, the information extraction unit outputs an embedding vector for each task node to perform on each edge node. This embedding vector integrates task dependency constraints, cache hit prediction, and network transmission cost, providing a global quantitative feasibility basis for scheduling decisions.
[0029] Furthermore, the information extraction unit includes: Information transmission unit: transmits local information between nodes of the same type, then transmits cache hit availability information through asset dependency edges, and finally transmits task migration cost information through physical edges between nodes; wherein, the local information includes task dependency chains and cache status.
[0030] In this embodiment, the information transmission unit performs three-round structure perception message transmission in a predefined order.
[0031] First, local information transmission is performed between nodes of the same type, limited to nodes of the same type. That is, task nodes only communicate with task nodes, edge nodes only communicate with edge nodes, and AI asset nodes only communicate with AI asset nodes.
[0032] Specifically, each task node aggregates the execution status of its predecessor task node and the pending start constraints of its successor task node along the task dependency edge to determine the overall execution progress and concurrent dependency relationship of the task chain; each AI asset node aggregates the historical access records of task nodes that have loaded the asset to obtain cache status distribution statistics; each edge node aggregates the distribution density and load status of its adjacent task nodes to obtain the degree of task aggregation in the local area.
[0033] Through aggregation of similar types, the local information of each task node is updated into a comprehensive vector containing the complete task dependency chain topology and the cached state of directly associated AI assets.
[0034] Secondly, cache hit availability information is transmitted via asset dependency edges, with this transmission limited to task nodes and AI asset nodes. Each task node aggregates the cache residency status of all connected AI asset nodes along the asset dependency edge and the ownership identifier of the edge node where the asset resides to determine the hit probability and transmission cost of asset loading during task execution. If the asset dependency edge indicates a cache hit, the task node benefits from low loading cost; if it indicates a cache miss, the task node needs to additionally measure the time overhead of fetching the asset from the remote end.
[0035] Through this round of transmission, the embedded representation of each task node incorporates the distribution distance and loading cost of available AI assets on each edge node.
[0036] Furthermore, task migration cost information is transmitted via physical edges between nodes, with this round of transmission limited to the task node and the edge node. Each task node aggregates the available computing resources, current load rate, and network latency and bandwidth information of the directly connected edge node along the edges between nodes, comprehensively assessing the communication overhead and queuing time required to migrate the task from its current deployment location to that edge node.
[0037] Through this round of transmission, the quantified migration cost in the heterogeneous edge network environment is ultimately incorporated into the embedded representation of each task node.
[0038] After the above three rounds of sequential transmission are completed, the embedded representation of the task node has successively integrated the three layers of information: dependency chain context, cache hit availability, and migration cost, providing a complete basis for evaluating the execution feasibility of subsequent scheduling decisions.
[0039] Decision module 12: Establishes a memory semantic awareness channel between the scheduler and edge nodes, obtains the memory resource occupancy distribution and sharing type of each edge node in real time, and makes task scheduling decisions and asset deployment decisions within the scheduler based on the embedded representation to determine the scheduling scheme. The scheduling scheme includes the task allocation scheme to edge nodes and the AI asset deployment scheme to edge nodes.
[0040] Furthermore, the decision module 12 includes: Memory Awareness Unit: Establishes a memory status awareness channel between the scheduler and edge nodes to perceive memory status in real time. The memory status includes memory pool occupancy status and remote page sharing status. The memory pool occupancy status includes the distribution of hot and cold data. Type Differentiation Unit: The scheduler differentiates the data types required by the task, where the data type is shared read or exclusive borrow. Scheduling Decision Unit: The scheduler is embedded with the heterogeneous graph. Based on the periodically updated embedded representation, it executes scheduling decisions based on the memory status and data types to determine the scheduling scheme.
[0041] In this embodiment of the application, the decision module 12 is provided with a memory awareness unit. This unit establishes an independent memory semantic awareness channel between the scheduler and each edge node, and obtains the memory status of each edge node in real time through this channel.
[0042] The memory status comprises two dimensions: memory pool occupancy status and remote page sharing status. The memory pool occupancy status records the allocation and release of data pages in the local memory pool of each edge node, and further includes hot and cold data distribution information. This distribution is measured using the most recent access timestamp of a page, marking frequently accessed data as hot data and long-unaccessed data as cold data, to differentiate data retention priorities during scheduling decisions. The remote page sharing status records the page mapping relationships shared between edge nodes through direct remote memory access, including the source node identifier, target node identifier, and shared access count of the shared page, supporting memory reuse judgment in data sharing scenarios.
[0043] Subsequently, based on the type differentiation unit set in the decision module 12, the data types required for each scheduled task are identified and labeled on the scheduler side.
[0044] Specifically, the type differentiation unit classifies data types into two categories based on the data access patterns of the tasks: shared read data and exclusive borrow data. Shared read data refers to data that can be read simultaneously by multiple tasks without competition, including static feature data, pre-training parameters, and public knowledge bases. Exclusive borrow data refers to data that a single task needs to exclusively access during its execution, including intermediate results of the task, private state variables, and sensitive transaction records.
[0045] The type differentiation unit attaches the identification results as data access type labels to the task description, so that the scheduling decision can be made by combining the memory status to allocate resources differently.
[0046] Furthermore, the scheduling decision unit embeds the aforementioned heterogeneous graph and uses the periodically updated embedded representation of the feasibility of each task node to execute on each edge node as input. When the scheduling decision unit executes scheduling decisions, it integrates three types of information sources: first, the task dependency constraints, cache hits, and migration costs in the embedded representation; second, the memory pool occupancy distribution and hot / cold data layout of each edge node as fed back in real time by the memory awareness unit; and third, the task data access type labels marked by the type differentiation unit.
[0047] Based on the above three types of information sources, scheduling decisions are made according to the following strategies: For tasks with shared read access type, they are preferentially allocated to edge nodes where corresponding hot data already exists in the memory pool to achieve data reuse and reduce memory loading overhead; for tasks with exclusive borrow access type, the available memory block size and continuity of each edge node are evaluated, and the node that can meet the exclusive memory requirements and has the lowest migration cost is selected.
[0048] Simultaneously, based on the task allocation results, the deployment location of each AI asset is determined, incorporating AI assets required by the task but not yet cached locally on the edge nodes into the deployment plan. Finally, the scheduling decision unit outputs a complete scheduling plan, including the task allocation plan to edge nodes and the AI asset deployment plan to edge nodes. This scheduling plan is then passed to the subsequent execution module via decision module 12 to complete the entity distribution and asset deployment of the scheduled tasks.
[0049] Deployment Module 13: The Contract Network Protocol is used to schedule and configure the scheduling scheme. The Contract Network Protocol optimizes the protocol with protocol requests and protocol-level metadata. If the protocol execution process meets the reconstruction triggering conditions in the protocol, the AI assets to be deployed are subjected to lightweight processing based on structured sparsity and differential privacy.
[0050] In this embodiment, the execution module 13 uses the Contract Network protocol to schedule and configure the scheduling scheme output by the decision module 12. As a standardized communication framework for distributed task allocation and resource coordination, the Contract Network protocol in this application uses protocol requests and protocol-level metadata as its core optimization methods.
[0051] Specifically, the model ID and reconstruction trigger conditions in the cached AI assets are encoded into protocol requests; the task priority and SLO constraints are encoded into protocol-level metadata, which are embedded in the protocol message header and broadcast to the relevant edge nodes along with the request. After receiving the protocol request, the edge nodes respond to the bid based on their own resource reserves and the priority indication in the protocol-level metadata. The execution module 13 completes the final confirmation and distribution of the task based on the bidding results.
[0052] During the protocol execution process, the execution module 13 continuously monitors the protocol execution status, including the task confirmation response of each edge node, asset deployment progress, and task execution feedback. If the protocol execution process meets the predefined refactoring trigger conditions in the protocol, such as when the cache hit failure rate reported by the edge node exceeds a set threshold or the task execution latency approaches the SLO tolerance boundary, the execution module 13 triggers dynamic lightweighting processing of the currently deployed AI assets.
[0053] Specifically, this lightweight processing integrates structured sparsity and differential privacy: on the one hand, it uses a sliding window method to count the average activation frequency of each internal architecture node in the AI asset model architecture in the most recent N inferences, and marks architecture nodes with activation frequencies below a preset dormancy threshold as dormant nodes. At the same time, it identifies general knowledge nodes that are not sensitive to the current financial domain tasks, and selectively freezes the above dormant nodes and general knowledge nodes according to task type and hardware margin during the edge node adaptation stage to achieve structured sparsity.
[0054] On the other hand, by periodically organizing the task privacy features of task nodes and generating differential privacy constraints, differential samples and differential methods are reconstructed based on task privacy features during the model parameter update and fine-tuning process within the AI asset, thereby applying differential privacy protection to the lightweight AI asset after structured sparse processing.
[0055] After completing the lightweighting process, the execution module 13 deploys the compressed AI assets to the corresponding edge nodes and sends the deployment status back to the decision module 12, thereby realizing a collaborative closed loop of scheduling scheme distribution, asset deployment and dynamic lightweighting at the protocol execution level.
[0056] Furthermore, the deployment module 13 includes: Solution Deployment Unit: According to the scheduling scheme, the Contract Network Protocol is used to complete task scheduling and allocation and AI asset deployment; wherein, if the reconstruction trigger condition is met, dynamic lightweight processing is performed on the AI assets, wherein the lightweight processing method is differential privacy processing and structured sparsity processing.
[0057] In this embodiment of the application, after receiving the scheduling scheme output by the decision module 12, the scheme deployment unit performs scheduling allocation and asset deployment operations using the contract network protocol as the communication framework.
[0058] Specifically, each task allocation item and AI asset deployment item in the scheduling scheme is converted into a bidding task in the Contract Network Protocol. A protocol request message is broadcast to all relevant edge nodes, carrying the task identifier, the required AI asset identifier, the expected completion time, and service level agreement constraint parameters. Upon receiving the protocol request, each edge node responds with a bid based on its current load status, available storage space, and cached asset list. The scheme deployment unit collects all bid responses and matches them with the resource commitment values in the bids against the allocation priorities in the scheduling scheme, thus completing the binding confirmation between the edge node and the task / AI asset. Subsequently, specific task execution instructions and asset loading instructions are issued, realizing the physical implementation of scheduling allocation and asset deployment.
[0059] During the protocol execution process, the solution deployment unit continuously monitors the asset loading feedback and task startup status of each edge node. If the asset cache miss rate reported by the edge node exceeds a preset threshold, or the task loading latency approaches the service level protocol tolerance boundary, the refactoring trigger condition is deemed met, and the dynamic lightweight processing procedure for the AI assets to be deployed is initiated.
[0060] Specifically, this dynamic lightweight processing includes two parallel paths: differential privacy processing and structured sparsity processing. Regarding structured sparsity processing, a sliding window method is used to statistically analyze the average activation frequency of each computational architecture node in the model architecture of each model included in the AI asset during the most recent N inferences. Nodes with activation frequencies below a preset dormancy threshold are marked as dormant nodes. Simultaneously, general knowledge nodes that are not sensitive to the current financial domain task are identified. During the edge node adaptation phase, based on the task type and the hardware accelerator capacity of the target edge node, the aforementioned dormant nodes and general knowledge nodes are dynamically frozen, achieving adaptive pruning of the internal structure of the model in the AI asset during runtime.
[0061] In terms of differential privacy processing, the privacy features of the financial data involved in the current task node are periodically sorted out, including the data sensitivity level and field type, and corresponding differential privacy constraints are generated. In the further supervised training process after lightweight processing, the differential samples and differential method are reconstructed according to the privacy features, and noise perturbation is applied to the gradient of model parameter update to meet the differential privacy protection requirements.
[0062] Subsequently, the compressed AI assets, after being structured sparse pruning and differential privacy noise enhancement, are deployed to the target edge nodes, and the deployment completion status is sent back to the scheduler via the protocol-level metadata channel, so that the heterogeneous graph can update the cached residency status of the asset-dependent edges.
[0063] Furthermore, the solution deployment unit includes: The first encoding unit encodes the model ID and reconstruction trigger conditions in the cached AI assets into a protocol request through protocol-level instruction encoding; the second encoding unit encodes the task priority and SLO constraints into protocol-level metadata; the protocol optimization unit optimizes the contract network protocol according to the protocol request and protocol-level metadata to obtain the updated contract network protocol and configure it.
[0064] In this embodiment of the application, the first encoding unit is responsible for encoding the key attributes of the cached AI assets into the protocol request of the ContractNet protocol.
[0065] Specifically, the first encoding unit establishes an asset index table for the cached AI assets at each edge node. The asset index table contains the model ID, version number, storage location, and historical access frequency for each asset. When initiating a tender in accordance with the Contract Network protocol, the first encoding unit extracts the model ID of the target AI asset and the quantitative parameters of the aforementioned reconstruction triggering conditions. The reconstruction triggering conditions include values such as the cache hit failure rate threshold and the degree of proximity of task execution latency to the SLO boundary. The above information is converted into a binary instruction sequence according to the encoding specifications of the protocol-level instructions and embedded in the message payload of the protocol request.
[0066] In this preferred embodiment, the protocol request, when broadcast to each edge node, carries not only basic information about task allocation but also asset identification and reconstruction criteria. This allows edge nodes to predict locally whether lightweight processing needs to be triggered when receiving the request, without needing to query the scheduler, thereby reducing protocol interaction overhead.
[0067] Synchronously, the second encoding unit encodes the task priorities and service level protocol constraints of each task in the scheduling scheme into protocol-level metadata.
[0068] The task priority is an integer value assigned after assessing the urgency and importance of the task for business purposes. Service level agreement constraints include quantitative indicators such as the maximum allowable execution latency, minimum accuracy guarantee, and minimum available resources. By serializing the above multidimensional parameters according to a predefined metadata format, a compact set of key-value pairs is generated as protocol-level metadata. This protocol metadata is then appended to the header extension field of the protocol message and sent along with the protocol request.
[0069] In this preferred embodiment, by carrying metadata in the protocol header instead of embedding it in the message body, each edge node can prioritize extracting metadata for local resource adaptation judgment when parsing the protocol message, and filter out bidding requests that cannot meet the SLO constraints in advance, thereby reducing invalid bid responses.
[0070] Subsequently, based on the protocol request and protocol-level metadata, the execution process of the ContractNet protocol is optimized and the configuration is updated.
[0071] Specifically, the protocol optimization unit modifies the standard three-stage interaction logic of the Contract Network protocol—bidding, tendering, and confirmation—by adding a metadata-based fast filtering mechanism to each stage: In the bidding stage, the model ID embedded in the protocol request allows edge nodes to directly query the local cache index. If the query result is cached and the asset version matches, a hit flag is attached to the bid to obtain allocation preference weights; In the tendering stage, each edge node performs a fast feasibility check based on the SLO constraint value in the protocol-level metadata and its own real-time load, generating a tender response only for bidding tasks that meet the constraints, thereby reducing the number of tender messages; In the confirmation stage, priority is sorted based on the cache hit flag attached to the bid and the remaining resources to quickly confirm the successful bidder.
[0072] In addition, the protocol optimization unit dynamically adjusts the protocol timeout retransmission threshold and the bid deadline window length based on historical protocol interaction records, so that the updated protocol parameters are more in line with the current network environment and task load distribution.
[0073] Finally, the protocol optimization unit distributes the updated contract network protocol configuration to the scheduler and the protocol stacks of each edge node for unified use during subsequent scheduling task execution.
[0074] Furthermore, the solution deployment unit includes: Dormant Analysis Unit: For each AI asset to be deployed, the average activation frequency of the model architecture in the most recent N times is statistically analyzed using a sliding window method, and the architecture nodes with activation frequencies lower than the preset dormant threshold are marked as dormant nodes; Sensitivity Analysis Unit: Identifies general knowledge nodes that are not sensitive to the current financial domain tasks; Lightweight Deployment Unit: During the edge node adaptation phase, dormant nodes and general knowledge nodes are dynamically frozen according to task type and hardware margin, completing the lightweight deployment of AI assets on edge nodes.
[0075] After completing the lightweight deployment of AI assets on edge nodes, the hardware accelerator prioritizes sparse gradient decisions for active nodes.
[0076] In this embodiment, the dormancy analysis unit performs node activation frequency statistics for each AI asset to be deployed. Specifically, it uses a sliding window to capture the activation records of each computing node in the model architecture during the most recent N inference tasks. For each computing node in each architecture, it calculates the ratio of its activation count within the time window to the total number of inference counts in the window, obtaining the average activation frequency. This sliding window moves forward gradually as the inference task is executed, ensuring that the activation frequency statistics always reflect the recent operating status of the model rather than a historical global average.
[0077] Subsequently, the average activation frequency of each architecture's computing nodes is compared with a preset dormancy threshold. This preset dormancy threshold is pre-calibrated based on the model's architecture complexity and the target task's load type, with an exemplary range of 0.01 to 0.05. If the average activation frequency is lower than this preset dormancy threshold, the corresponding architecture's computing node is marked as a dormant node, indicating low activity in inference and structural redundancy. A list of dormant nodes is then output for subsequent lightweight deployment.
[0078] Synchronously, the sensitivity analysis unit is used to identify general knowledge nodes that are not sensitive to the current financial domain task. Specifically, it retrieves a financial domain knowledge sensitivity map, which records the contribution weights of each architectural node in the model across different financial sub-tasks, such as credit scoring and time series prediction. During lightweight processing, by obtaining the current task type identifier, it queries the contribution score of each architectural node under that task type in the knowledge sensitivity map. Nodes with contribution scores below a preset sensitivity threshold are identified as general knowledge nodes. The knowledge encoded by these nodes has cross-domain universality but limited benefit to the current specific financial task, and can be included in the freeze-able range.
[0079] In summary, the sensitivity analysis unit and the dormancy analysis unit work in parallel. The node sets output by the two units identify model redundancy from two independent dimensions: runtime activation sparsity and task semantic sensitivity, and together they form a candidate pool of freezeable nodes.
[0080] Furthermore, during the edge node adaptation phase, the lightweight deployment unit receives dormant nodes and general knowledge nodes, and performs a dynamic freeze operation based on the task type and hardware margin of the current target edge node, i.e. the edge node to be deployed.
[0081] Specifically, the hardware accelerator type, number of available computing cores, memory bandwidth, and current load rate of the edge nodes are read first to determine the hardware margin level. When the hardware margin is sufficient, the intersection nodes that are simultaneously marked as dormant nodes and general knowledge nodes are frozen first to minimize the loss of accuracy in exchange for compression benefits. When the hardware margin is tight, the marked dormant nodes, that is, nodes with low activation frequency during runtime but which may still contribute to some tasks, are further frozen.
[0082] Optionally, the freeze operation is achieved by setting the weight parameters of the corresponding nodes within the model architecture to zero and marking them as not participating in forward inference and gradient calculation, thus completing the lightweight deployment of AI assets at edge nodes.
[0083] After completing the lightweight deployment of AI assets on edge nodes, the hardware accelerator prioritizes sparse gradient decisions for active nodes. Specifically, the edge node hardware accelerator performs a sparsity scan of the gradient tensor, calculating only the gradient values corresponding to the architecture nodes that remain active after the lightweight deployment unit's freezing operation. For frozen nodes, gradient calculation is skipped, and zero gradients are output. Simultaneously, a sparse storage format is used to maintain only the gradient tensor indexes and values of active nodes. Limited computing resources are prioritized for allocation to critical nodes with high activation frequency and high task sensitivity, improving deployment availability.
[0084] Furthermore, the deployment unit of the solution includes: periodically organizing the task privacy features of task nodes and generating differential privacy constraints; reconstructing differential samples and differential methods based on the task privacy features, and performing supervised training on the lightweight AI assets.
[0085] In this embodiment, the input data sources and intermediate calculation results of all task nodes are scanned at fixed time intervals to extract privacy-related feature dimensions, including data field type, data sensitivity level, presence of user identifier field, and data aggregation granularity. These features are then quantified and encoded according to predefined privacy grading standards in financial business scenarios to generate a privacy feature vector for each task node. Each dimension in the privacy feature vector corresponds to a type of privacy attribute.
[0086] Based on this, a global differential privacy constraint term is generated according to the weighted combination of the privacy feature vectors of each task node. Optionally, the global differential privacy constraint term includes two parameters: privacy budget and sensitivity, which are used to regulate the noise injection intensity allowed by the model in subsequent AI assets, and ensure that the trained AI assets meet the differentiated privacy protection requirements in financial scenarios.
[0087] Further, the differential samples and differential methods are reconstructed based on task privacy features. Specifically, for the training sample set corresponding to each task node, the original samples are grouped according to the sensitivity level of the fields in the privacy features. Samples containing highly sensitive fields are marked as core privacy samples, and samples containing only low-sensitivity public fields are marked as ordinary samples. For core privacy samples, a sample-level differential method is used, adding privacy-budget-constrained Laplacian noise or Gaussian noise at the sample input level to prevent attackers from inferring individual sample information from the model output. For ordinary samples, a mini-batch gradient-level differential method is used, injecting noise during gradient aggregation to reduce computational overhead while ensuring privacy protection. Through the above differential processing, differential samples under different differential methods are obtained.
[0088] Subsequently, supervised training is performed on the AI asset after the aforementioned lightweight processing. Specifically, the reconstructed differenced samples are used as training inputs, and the labeled data corresponding to the task are used as supervision signals. Stochastic gradient descent is employed to optimize the model parameters. During each parameter update, corresponding noise is applied to the sample input or gradient according to the aforementioned difference method, and the gradient norm is pruned to meet sensitivity constraints, thereby ensuring that the entire training process satisfies differential privacy guarantees. This process continues until the difference between the model output and the differenced samples is less than a preset difference, at which point convergence is determined, and the parameter update process is completed.
[0089] Preferably, only the parameters of active nodes that have not been frozen are updated, while the weights of frozen dormant nodes and general knowledge nodes remain unchanged. This reduces the computational cost of training and avoids the structured sparsity effect from being destroyed by the accidental activation of frozen nodes due to fine-tuning.
[0090] Subsequently, the updated AI assets are sent back to the edge node cache for use in subsequent inference tasks, while the cache dwell status and version information of the corresponding asset-dependent edges in the heterogeneous graph are updated.
[0091] Furthermore, the system also includes: After the scheduling scheme is executed, the execution feedback information is determined, which includes the cache hit results of each edge node, task completion latency and resource utilization. The execution feedback information is then sent back to the scheduler via the protocol-level metadata channel to update the cache dwell status of the asset-dependent edges in the heterogeneous graph.
[0092] In this embodiment, execution feedback information is collected after the scheduling scheme is completed. Specifically, after each edge node completes the execution of the assigned task and the loading and running of the AI asset, it generates a local execution log. This log contains three core feedback metrics: cache hit result, which is the ratio of the number of hits to the number of misses of the AI asset required during task execution in the local cache; task completion latency, which is the time interval from task issuance to task completion; and resource utilization, which is the ratio of the actual usage of CPU, memory bandwidth, storage I / O, and hardware accelerators during task execution to the total capacity of the node. Through the established communication link between each edge node and the scheduler, the above execution log is periodically retrieved or received, and after being summarized and formatted, structured execution feedback information is formed.
[0093] Subsequently, it is transmitted back to the scheduler via the protocol-level metadata channel. Specifically, the protocol-level metadata channel is the reverse channel of the protocol message header extension field used by the first and second encoding units. The execution feedback information is encapsulated into feedback metadata in the same serialization format as the protocol-level metadata, embedded in the protocol response message header sent by each edge node to the scheduler, and transmitted to the scheduler side along with the message. There is no need to open an additional independent feedback link, thereby reducing communication overhead and maintaining the uniformity of the protocol stack.
[0094] Furthermore, after receiving the execution feedback information, the scheduler updates the cache dwell status of the asset-dependent edges in the heterogeneous graph based on the cache hit results.
[0095] Specifically, for asset dependency edges whose cache hit results indicate a hit, the cache dwell status field of the corresponding edge is marked as cached and the latest access timestamp is recorded; for asset dependency edges whose cache misses, if the number of misses exceeds a preset threshold consecutively, the cache dwell status field of the edge is marked as cache invalid, and a preloading scheduling instruction for the asset is triggered to complete the asset transfer in advance.
[0096] In addition, the task completion latency and resource utilization rate are used as historical statistical samples to update the dynamic performance profile of each edge node, which is then used by the decision module 12 as an additional input for embedding representation updates in subsequent scheduling cycles, thereby achieving closed-loop optimization of scheduling decisions.
[0097] Through the above feedback update mechanism, the cache dwell status of asset-dependent edges in the heterogeneous graph is always synchronized with the actual cache distribution of edge nodes, ensuring that the heterogeneous graph structure information on which the next round of scheduling decisions is based is timely and accurate.
[0098] The financial edge computing power dynamic scheduling and vertical category model lightweight deployment system provided in this application has the following technical effects: 1. Construct a heterogeneous graph integrating task dependencies, edge resources, and reusable AI assets. Through multi-round hierarchical neighbor aggregation and message passing, obtain an embedded representation of the execution feasibility of task-edge node operations. Achieve unified modeling of three types of heterogeneous objects: tasks, edge nodes, and AI assets, comprehensively representing the adaptability of task execution in complex edge environments. Establish a memory semantic awareness channel to perceive memory pool occupancy, hot and cold data, and remote page sharing status. Distinguish between shared reads and exclusive borrowed data types. Integrate memory dimension information into scheduling decisions to fully utilize edge memory sharing capabilities, reduce memory resource crowding for financial tasks, and improve edge memory utilization.
[0099] 2. The contract network protocol is optimized by extending and optimizing the protocol request and protocol-level metadata. The model identifier, reconstruction trigger condition, task priority, and SLO constraint are incorporated into the protocol interaction process, and the task scheduling configuration is integrated with the lightweight processing of AI assets. When the protocol execution triggers the reconstruction condition, the structured sparse node freezing and differential privacy processing are completed in conjunction. In the deployment stage, the vertical model is lightweighted, taking into account both financial inference performance and data privacy and security.
[0100] 3. By using a sliding window to statistically analyze activation frequency to filter dormant nodes and identify general knowledge nodes that are not sensitive to financial tasks, the corresponding nodes are dynamically frozen at the edge. Hardware accelerators prioritize processing sparse gradients of active nodes, effectively compressing the deployment overhead of vertical AI assets and adapting to edge hardware resource constraints. Periodically collecting task privacy features to generate differential privacy constraints, reconstructing differential samples to complete supervised training, further enhances the privacy protection capabilities of AI asset inference in financial scenarios.
[0101] Through the foregoing detailed description of the dynamic scheduling of financial edge computing power and the lightweight deployment system of vertical models, those skilled in the art can clearly understand the dynamic scheduling of financial edge computing power and the lightweight deployment system of vertical models in this embodiment.
[0102] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A system for dynamic scheduling of financial edge computing power and lightweight deployment of vertical models, characterized in that: The system includes: Extraction module: Constructs a heterogeneous graph that integrates task dependencies, edge node resource attributes, and the distribution status of reusable AI assets; periodically executes multi-round structure-aware message passing; and extracts the embedded representation of the execution feasibility of each task in the heterogeneous edge environment. Decision module: Establishes a memory semantic awareness channel between the scheduler and edge nodes, obtains the memory resource occupancy distribution and sharing type of each edge node in real time, and makes task scheduling decisions and asset deployment decisions within the scheduler based on the embedded representation to determine the scheduling scheme. The scheduling scheme includes the task allocation scheme to edge nodes and the AI asset deployment scheme to edge nodes. Deployment module: Uses the Contract Network protocol to schedule and configure the aforementioned scheduling scheme; The contract network protocol optimizes the protocol using protocol requests and protocol-level metadata. If the protocol execution process meets the reconstruction triggering conditions in the protocol, the AI assets to be deployed are subjected to lightweight processing based on structured sparsity and differential privacy.
2. The financial edge computing power dynamic scheduling and vertical model lightweight deployment system as described in claim 1, characterized in that, The extraction module includes: Heterogeneous graph construction unit: Periodically read multiple task nodes, all edge nodes and all cached AI assets, and incorporate them into a unified graph as three types of heterogeneous nodes to obtain a heterogeneous graph. Among them, task-dependent edges carry execution order constraints, node-to-node edges carry network latency and bandwidth information, and asset-dependent edges carry cache dwell status. Information extraction unit: Performs multi-round information transfer analysis on the heterogeneous graph and outputs an embedding representation of the feasibility of each task node to each edge node.
3. The financial edge computing power dynamic scheduling and vertical model lightweight deployment system as described in claim 2, characterized in that, The information extraction unit includes: Information transmission unit: transmits local information between nodes of the same type, then transmits cache hit availability information through asset dependency edges, and finally transmits task migration cost information through physical edges between nodes; The local information includes task dependency chains and cache status.
4. The financial edge computing power dynamic scheduling and vertical model lightweight deployment system as described in claim 1, characterized in that, The decision-making module includes: Memory Awareness Unit: Establishes a memory status awareness channel between the scheduler and edge nodes to perceive memory status in real time. The memory status includes memory pool occupancy status and remote page sharing status. The memory pool occupancy status includes the distribution of hot and cold data. Type differentiation unit: The scheduler differentiates the data types required by the task, where the data type is either shared read or exclusive borrow; Scheduling Decision Unit: The scheduler is embedded with the heterogeneous graph. Based on the periodically updated embedded representation, it executes scheduling decisions based on the memory state and data type to determine the scheduling scheme.
5. The financial edge computing power dynamic scheduling and vertical model lightweight deployment system as described in claim 1, characterized in that, The deployment module includes: Solution Deployment Unit: Based on the aforementioned scheduling scheme, the Contract Network protocol is used to complete task scheduling and allocation and AI asset deployment; If the reconstruction triggering conditions are met, dynamic lightweight processing is performed on the AI assets. The lightweight processing method is differential privacy processing and structured sparsity processing.
6. The financial edge computing power dynamic scheduling and vertical model lightweight deployment system as described in claim 5, characterized in that, The solution deployment unit includes: First encoding unit: Encode the model ID and reconstruction triggering conditions in the cached AI assets into a protocol request through protocol-level instruction encoding; The second encoding unit encodes the task priority and SLO constraints into protocol-level metadata. Protocol optimization unit: Based on the protocol request and protocol-level metadata, optimize the Contract Network protocol to obtain the updated Contract Network protocol and configure it.
7. The financial edge computing power dynamic scheduling and vertical model lightweight deployment system as described in claim 6, characterized in that, The solution deployment unit includes: Dormant Analysis Unit: For each AI asset to be deployed, the average activation frequency of the model architecture in the most recent N times is counted in a sliding window manner, and the architecture nodes with activation frequencies lower than the preset dormant threshold are marked as dormant nodes; Sensitive Analysis Unit: Identifies general knowledge nodes that are not sensitive to current financial tasks; Lightweight Deployment Unit: During the edge node adaptation phase, dormant nodes and general knowledge nodes are dynamically frozen based on task type and hardware availability to complete the lightweight deployment of AI assets on edge nodes.
8. The financial edge computing power dynamic scheduling and vertical model lightweight deployment system as described in claim 7, characterized in that, After completing the lightweight deployment of AI assets on edge nodes, the hardware accelerator prioritizes sparse gradient decisions for active nodes.
9. The financial edge computing power dynamic scheduling and vertical model lightweight deployment system as described in claim 8, characterized in that, The task privacy features of task nodes are periodically sorted out to generate differential privacy constraints; based on the task privacy features, differential samples and differential methods are reconstructed to perform supervised training on the lightweight AI assets.
10. The financial edge computing power dynamic scheduling and vertical model lightweight deployment system as described in claim 1, characterized in that, The system also includes: After the scheduling scheme is executed, the execution feedback information is determined, which includes the cache hit results of each edge node, task completion latency and resource utilization. The execution feedback information is sent back to the scheduler via the protocol-level metadata channel to update the cache residency status of the asset-dependent edges in the heterogeneous graph.
