A cloud training edge inference collaborative scheduling method based on a custom lightweight protocol

Abstract

The application provides an edge computing and artificial intelligence collaborative technology field, a cloud training edge inference collaborative scheduling method based on a self-defined lightweight protocol, which comprises the following steps: a lightweight collaborative protocol defines a message structure containing fields such as business types and model versions, is used for heartbeat interaction between the cloud and the edge node, collects network and load parameters and generates a situation assessment; the cloud dynamically issues an incremental model package or an inference instruction according to the situation assessment; the edge node parses the message, checks the integrity and superimposes the incremental update model, or executes the inference task, and returns the result to the cloud for optimized training after completion; at the same time, the system dynamically adjusts the cloud-edge interaction mode according to the situation assessment, and realizes efficient collaboration. The application has the advantages that the protocol semantic efficiency in cloud-edge collaboration, the linkage real-time performance of cloud model updating and edge inference deployment, the transmission adaptive capacity and the file fault tolerance checking reliability are greatly improved.

Description

Technical Field

[0001] This invention relates to the field of edge computing and artificial intelligence collaborative technology, and in particular to a cloud training and edge inference collaborative scheduling method based on a custom lightweight protocol. Background Technology

[0002] With the rapid development of artificial intelligence (AI) technology and its widespread application in fields such as industrial internet, autonomous driving, and smart cities, the "cloud training-edge inference" collaborative paradigm, which deploys the powerful computing power required for deep model training in the cloud and sinks the trained model to edge nodes close to the data source for real-time inference, has become the mainstream architecture in the current edge intelligence field.

[0003] In existing technical solutions, to achieve data interaction, task scheduling, and state synchronization between the cloud and edge nodes, common internet protocols such as HTTP / 2, MQTT (Message Queuing Telemetry Transport Protocol), and TCP (Transmission Control Protocol) are widely used. Meanwhile, relying on open-source cloud-edge collaboration frameworks such as KubeEdge, OpenYurt, and EdgeX Foundry, the industry has been able to implement basic functions such as model distribution from the cloud to edge nodes, inference result feedback, and node status reporting. These common protocols and frameworks provide the communication foundation for cloud-edge collaboration, supporting the implementation of routine AI training and inference operations. Cloud servers are responsible for performing computationally intensive large-scale model iterative training, parameter aggregation, and version management, while edge nodes are responsible for performing real-time inference tasks, collecting on-site data, and reporting inference results, thus forming a basic division of labor and collaboration system.

[0004] However, in complex edge computing scenarios with extremely high requirements for real-time performance, reliability, and bandwidth efficiency, such as industrial visual quality inspection, assisted driving, and real-time security monitoring, edge nodes generally exhibit characteristics such as strong heterogeneity in computing power, large fluctuations in network environment, and complex data dimensions. These scenarios place higher demands on cloud-edge collaboration, and current solutions based on general protocols reveal the following technical shortcomings when addressing these challenges: 1. Lack of semantics in general protocols leads to low interaction efficiency. General protocols such as MQTT and HTTP / 2 were not designed for cloud-edge collaborative AI scenarios. Their message formats are fixed and lack dedicated fields to distinguish specific business functions such as model parameters, inference instructions, result data, and heartbeat synchronization. This results in protocol header overhead being much greater than the payload when transmitting small data packets, leading to low bandwidth utilization and unstable cloud-edge interaction latency.

[0005] 2. Lack of an efficient linkage mechanism between cloud model updates and edge inference deployment. Existing frameworks mostly implement a one-way, fixed process of "cloud delivery, edge execution." After the cloud completes iterative training, there is a lack of efficient means to connect the cloud model version update with the deployment of edge inference tasks. Specifically, this manifests in two ways: First, existing solutions mostly use a full model delivery approach. When the model size is large, each update requires the transmission of a large number of redundant parameters, severely consuming bandwidth resources and taking a long time. Second, the cloud cannot flexibly adjust the model delivery strategy according to the real-time load status and network conditions of the edge nodes, resulting in untimely model updates. Edge nodes use old versions of the model for inference for a long time, leading to a decrease in inference accuracy. In addition, after the edge nodes complete inference, the feedback link between the inference results and cloud training is not efficient enough, making it difficult to form a rapid closed loop.

[0006] 3. Lack of Adaptive Transmission Strategies. General protocols typically employ fixed transmission rates and fragmentation strategies, failing to dynamically adjust transmission strategies based on real-time changes in network bandwidth, latency, and packet loss rates between the cloud and edge. During network congestion, model delivery suffers severe delays or data loss; conversely, during network downtime, transmission resources are underutilized, resulting in bandwidth waste. Furthermore, existing solutions lack the ability to dynamically adjust the delivery pace based on the edge node's own computing load and inference task queue length, easily causing edge nodes to consume inference service resources while receiving model updates.

[0007] 4. Lack of lightweight verification and fault tolerance mechanisms. The general protocol itself does not have dedicated verification, breakpoint resumption, and anomaly rollback functions for model files. When edge nodes receive incomplete model files or data anomalies occur during transmission, the system cannot detect and repair them in a timely manner, which can easily lead to incorrect inference results and inconsistencies between cloud and edge states. In weak network environments, model delivery tasks often need to be retransmitted from scratch, further exacerbating bandwidth waste and latency issues.

[0008] In summary, although existing general protocols and open-source frameworks provide basic support for cloud-edge collaboration, their inherent limitations in protocol semantics, the efficiency of linkage between model updates and inference deployment, adaptive network and load transmission, and system fault tolerance make it difficult to meet the deployment requirements of high-precision, low-latency, and high-reliability industrial-grade edge intelligence applications. Therefore, how to provide a cloud training-edge inference collaborative scheduling method based on a custom lightweight protocol to improve protocol semantic efficiency, real-time linkage between cloud model updates and edge inference deployment, adaptive transmission capabilities, and file fault tolerance and reliability has become an urgent technical problem to be solved. Summary of the Invention

[0009] The technical problem to be solved by this invention is to provide a cloud training and edge inference collaborative scheduling method based on a custom lightweight protocol, which improves the protocol semantic efficiency, the real-time linkage between cloud model updates and edge inference deployment, the transmission adaptive capability, and the reliability of file fault tolerance and verification in cloud-edge collaboration.

[0010] This invention provides a cloud training and edge inference collaborative scheduling method based on a custom lightweight protocol, comprising the following steps: Step S1: Define a lightweight collaborative protocol for cloud training and edge inference. The message structure of the lightweight collaborative protocol includes a service type field, a model version field, a transmission attribute field, a verification and fault tolerance field, and a device status field. Step S2: Based on the lightweight collaboration protocol, the cloud and edge nodes periodically send protocol heartbeat packets to each other, collect real-time network status parameters and edge node load parameters, and generate cloud-edge collaboration situation assessment results. Step S3: After the cloud completes the iterative training of the deep learning model, it generates an incremental model data packet. Based on the cloud-edge collaborative situation assessment results, it dynamically adjusts the distribution strategy, encapsulates the incremental model data packet through the lightweight collaborative protocol, and distributes it to the edge node. At the same time, the cloud distributes inference scheduling instructions to the edge node through the lightweight collaborative protocol according to business needs. Step S4: The edge node listens to and receives the messages corresponding to the lightweight collaboration protocol in real time, and parses the business type field in the message to distinguish the task type; when receiving the incremental model data packet, it verifies the data integrity through the verification fault tolerance field. After verification, the incremental parameters are superimposed on the local old model to complete the model iteration update; when receiving the inference scheduling instruction, it executes the corresponding inference task. Step S5: After completing each round of inference tasks, the edge node sends the inference results back to the cloud via the lightweight collaborative protocol; the cloud optimizes the model training parameters based on the sent-back inference results. Step S6: Dynamically adjust the cloud-edge interaction mode based on the cloud-edge collaborative situation assessment results.

[0011] Furthermore, in step S1, the service type field is used to distinguish between incremental model distribution, full model update, inference task scheduling, edge result feedback, cloud-edge heartbeat synchronization, and abnormal alarm service scenarios; the model version field is used to record the model version number, accuracy parameters, and update time of the cloud-trained model; the transmission attribute field includes data priority, fragment sequence number, incremental transmission identifier, and verification identifier; the verification fault tolerance field carries the model hash value, data verification code, and breakpoint resume flag; the device status field records the computing load, network status, and inference task remaining capacity of the edge node. The lightweight collaborative protocol has a single-frame protocol header length of 16 bytes, and the service type field, model version field, transmission attribute field, verification and fault tolerance field, and device status field are encapsulated in the single-frame protocol header.

[0012] Furthermore, step S2 specifically includes: Based on the aforementioned lightweight collaboration protocol, the cloud and edge nodes periodically exchange protocol heartbeat packets to collect real-time network status parameters and edge node load parameters; the real-time network status parameters include real-time network bandwidth, link latency, and packet loss rate; the edge node load parameters include edge node computing power load and inference task queue length. The real-time network status parameters and edge node load parameters collected are denoised using a sliding window algorithm to generate a cloud-edge collaborative situation assessment result. The cloud-edge collaborative situation assessment result includes network status level and edge load status level. The network status level is divided into four levels: stable, slight fluctuation, congestion, and disconnection. The edge load status is divided into four states: heavy load, medium load, light load, and no load.

[0013] Furthermore, in step S3, the incremental model data package is generated by comparing the parameters of the old and new model versions in the cloud, calculating the weight difference of the iterative update, and generating the incremental model data package.

[0014] Furthermore, in step S3, the dynamic adjustment of the distribution strategy based on the cloud-edge collaborative situation assessment results specifically includes: Obtain the model update urgency parameter of the currently issued task. The model update urgency parameter is generated quantitatively based on the priority of the business scenario and the accuracy improvement between the old and new cloud model versions. Based on the network status level, edge load status level, and model update urgency parameter, a three-dimensional decision matrix is ​​constructed, and a distribution strategy is determined according to the three-dimensional decision matrix. The distribution strategy specifically includes: (1) When the network state level is stable and the edge load state level is lightly loaded or unloaded: If the urgency parameter of the model update exceeds the preset urgency threshold, the full-speed delivery mode is adopted to transmit the incremental model data packet with the maximum available bandwidth of the current link. If the urgency parameter of the model update does not exceed the preset urgency threshold, a rate-limited delivery mode is adopted, which limits the delivery bandwidth to a predetermined proportion of the real-time idle bandwidth of the current link, so as to prioritize the normal inference services of the edge nodes. (2) When the network status level is slightly fluctuating and the edge load status level is medium or heavy: A fragmented background silent delivery mode is adopted. Specifically, the incremental model data packet is divided into multiple fragments according to the fragment sequence number in the transmission attribute field. The inference task margin in the device status field is used as reverse pressure to dynamically adjust the delivery time interval of each fragment to achieve fragmented peak transmission. The delivery time interval is inversely proportional to the inference task margin. When the inference task margin is greater than the preset high water level, the delivery time interval is increased. When the inference task margin is lower than the preset low water level, the delivery time interval is decreased. (3) When the network status level is congested: The incremental model data packets are paused from being sent, and the breakpoint resume flag and the confirmed fragment sequence number of the currently transmitted incremental model data packets are written into the verification fault tolerance field. At the same time, link prediction monitoring is enabled, and the link recovery time window is calculated based on the real-time packet loss rate and round-trip delay. After entering the link recovery time window, the transmission is resumed from the next fragment after the confirmed fragment sequence number through the breakpoint resume flag. The full-speed delivery mode, the rate-limited delivery mode, and the fragmented background silent delivery mode all carry the corresponding delivery strategy identifier through the transmission attribute field in the lightweight collaborative protocol, so that the edge node can adjust the write strategy of the receiving buffer accordingly when receiving.

[0015] Furthermore, in step S3, encapsulating the incremental model data packet includes: marking this transmission as an incremental model delivery through the service type field in the lightweight collaboration protocol, writing the model version number of the current iteration through the model version field, writing the model hash value, data checksum, and breakpoint resume flag of the incremental model data packet through the verification and fault tolerance field, and writing the fragment sequence number of the incremental model data packet through the transmission attribute field.

[0016] Furthermore, in step S4, after the edge node parses the received incremental model data packet, it verifies the data integrity through the model hash value and data check code in the verification fault tolerance field; if the verification passes, the incremental parameters are superimposed on the local old model to complete the iterative update; if the verification fails, it requests the cloud to retransmit the corresponding fragment data. When edge nodes perform inference tasks, they set high priority for urgent inference tasks and high-precision detection tasks by using the data priority in the transmission attribute field of the lightweight collaboration protocol, and prioritize the scheduling of computing power and transmission resources.

[0017] Furthermore, in step S5, the cloud extracts inference bias data from the inference results returned by the edge nodes as sample data, performs reverse optimization on the loss function and weight distribution of the cloud-trained model, iteratively generates an updated model version, and forms a closed-loop collaboration of cloud training iteration, edge landing inference, edge data feedback, and cloud precise optimization. When the cloud detects a model update failure, inference anomaly, or link interruption, it automatically triggers mechanisms to roll back the old model, retry the task, or reconnect the link.

[0018] Furthermore, in step S6, dynamically adjusting the cloud-edge interaction mode based on the cloud-edge collaborative situation assessment result specifically includes: For model data whose data volume exceeds the preset fragmentation threshold, a fragmented parallel transmission method is adopted. For instruction and result data whose data volume does not exceed the preset fragmentation threshold, a single-frame direct encapsulation and transparent transmission method is adopted. When the edge node is in a light-load state and the network is idle, it actively completes model iteration and data synchronization. When the edge node is in a heavy-load state or the network is congested, non-real-time inference business interaction is suspended and inference business is prioritized.

[0019] Furthermore, the method is deployed based on the KubeEdge cloud-edge collaboration framework. The lightweight collaboration protocol is adapted and extended at the protocol interface layer of the KubeEdge framework. The KubeEdge framework manages the container scheduling and resource management of the edge nodes, and the lightweight collaboration protocol executes cloud-edge business interaction and scheduling control. The advantages of this invention are: 1. By abandoning the common heavy protocol and instead defining a custom lightweight protocol with a single frame header of only 16 bytes, specific semantics such as business type, model version, and transmission attributes are embedded in the header. This achieves real-time recognition of cloud-edge interaction intentions with minimal communication overhead, thus significantly improving protocol semantic efficiency. Regarding real-time linkage, instead of full model distribution, incremental data packets are generated by calculating the weight difference between the old and new models. A three-dimensional decision matrix integrating network status level, edge load status level, and model update urgency is introduced. Based on this, a refined distribution strategy such as full-speed, rate-limited, or fragmented silent distribution is dynamically determined. This ensures that model updates closely match the real-time carrying capacity of edge nodes and the urgency of business needs. Simultaneously, cloud parameters are optimized in reverse based on the feedback of inference results, forming a "training-distribution-inference-feedback" process. Highly efficient closed-loop; In terms of transmission adaptability, by real-time monitoring of bandwidth, latency, packet loss rate, and edge computing queue length, the protocol dynamically adjusts the fragment transmission interval using inference task margin as reverse pressure, and proactively pauses transmission and predicts link recovery time windows when the network is congested, achieving precise matching between transmission rhythm and dynamic network and load environment; For fault tolerance and reliability verification, the protocol incorporates model hash value, data checksum, and breakpoint resume flag in the fault tolerance verification field. Edge nodes strictly verify integrity upon reception, and if verification fails, only request retransmission of the corresponding fragment. After network interruption recovery, transmission resumes from the breakpoint based on the breakpoint resume flag, supplemented by automatic rollback of the old model when model update fails and reconnection mechanism when link is abnormal, thus comprehensively ensuring data transmission consistency and system robustness in weak network environments.

[0020] 2. A lightweight collaborative protocol is designed specifically for cloud training and edge inference scenarios. Its message structure accurately carries multiple business semantics such as model distribution, inference scheduling, result feedback, heartbeat synchronization, and anomaly alarms through fields such as business type, model version, transmission attributes, verification and fault tolerance, and device status. The protocol header of a single frame occupies only 16 bytes, which greatly reduces communication overhead. This allows both cloud and edge parties to quickly identify task types and extract key status information without parsing complex general messages, effectively improving the transmission efficiency of each byte of data. It is especially suitable for edge intelligence scenarios with bandwidth sensitivity and high real-time requirements.

[0021] 3. By periodically exchanging protocol heartbeat packets between the cloud and edge nodes, parameters such as network bandwidth, latency, packet loss rate, edge computing load, and task queue length are collected in real time. Sliding window noise reduction is used to generate network status level and edge load status level, forming an accurate cloud-edge collaborative situation assessment. Based on this, the cloud only calculates the difference in weights between the old and new models to generate incremental model data packets, significantly reducing the amount of data transmitted. At the same time, the distribution strategy is dynamically selected based on the collaborative situation assessment results, so that the model update rhythm is precisely matched with the actual edge carrying capacity and real-time network conditions, avoiding redundant transmission of full updates, ensuring that edge nodes can obtain the latest model parameters in a timely manner, and effectively guaranteeing the continuous optimization of inference accuracy.

[0022] 4. A three-dimensional decision matrix is ​​constructed based on network status level, edge load status level, and model update urgency to flexibly switch between transmission modes such as full-speed delivery, rate-limited delivery, silent background delivery in fragmented segments, or pause and wait. When the network fluctuates slightly and the edge load is high, the fragmented delivery interval is dynamically adjusted using the inference task margin as reverse pressure to achieve peak-shifting transmission and avoid competing for resources with inference services. When the network is congested, delivery is automatically paused and a breakpoint resumption marker is recorded. Based on the real-time packet loss rate and round-trip delay, the link recovery time window is predicted, and transmission resumes from the breakpoint after recovery. This mechanism enables the transmission process to make full use of idle bandwidth and recover smoothly in harsh network environments, significantly improving transmission reliability.

[0023] 5. The fault tolerance field incorporates the model hash value, data checksum, and breakpoint resume flag. After receiving incremental model data packets, edge nodes first verify their integrity. If verification fails, only the corresponding fragment is retransmitted, significantly reducing retransmission overhead in weak network environments. Simultaneously, after each round of inference, edge nodes transmit the inference results back to the cloud. The cloud extracts inference bias data, reverse-engineers the loss function and weight distribution of the training model, and iteratively generates a new model, forming a complete closed loop of "training—inference—feedback—tuning." Furthermore, the system incorporates mechanisms for rolling back old models, retrying tasks, and reconnecting links, further ensuring cloud-edge state consistency and the continuous and stable operation of inference tasks.

[0024] 6. The cloud-edge interaction mode is dynamically adjusted based on the collaborative situation assessment results. Large-volume model data is transmitted in fragments in parallel, while instruction and result data are directly encapsulated and transmitted in single frames. When the edge is lightly loaded and the network is idle, the model iteration synchronization is actively completed. When the edge is heavily loaded or the network is congested, non-real-time interaction is suspended to prioritize inference services, giving the system a high degree of operational flexibility. At the same time, it can be deployed based on mainstream cloud-edge collaboration frameworks such as KubeEdge. Only the lightweight collaboration protocol is adapted and extended at the protocol interface layer. The framework manages container scheduling and resources, while the protocol of this invention executes business interaction and scheduling control. It inherits the resource management capabilities of mature frameworks and enhances the professional collaborative scheduling function, with good industry compatibility and practical application value.

[0025] 7. In addition to focusing on the delivery strategy from the cloud to the edge, it also endows edge nodes with localized intelligent scheduling capabilities. Through the data priority identifier in the transmission attribute field, edge nodes can accurately identify urgent inference tasks and high-precision detection tasks, and prioritize the allocation of scarce local computing power resources and uplink transmission bandwidth accordingly. This mechanism ensures that when edge nodes are simultaneously handling multiple mixed loads such as model updates, regular inference, and high-priority detection, critical services can obtain deterministic resource guarantees, avoiding latency jitter or accuracy degradation in core inference tasks due to model downloads or background tasks preempting resources, and significantly improving the service quality and reliability of the edge side in complex business concurrency scenarios.

[0026] 8. The limitations of storage and memory resources at edge nodes are fully considered. When receiving data, edge nodes can proactively adjust the write strategy and memory management logic of the receive buffer according to the transmission strategy identifier (full speed, rate limiting, or fragmented silent mode) carried in the protocol header. Combined with fragment-level integrity verification and on-demand retransmission mechanism, it can effectively avoid receive buffer overflow and write conflicts caused by high-speed data burst injection or fragmented fragment arrival. This transmit-receive linked buffer management scheme ensures that model parameter fragments written to local storage are continuous, orderly, and complete, greatly optimizing the input-output performance and data persistence reliability of edge devices with limited storage space.

[0027] 9. The closed-loop feedback mechanism is not simply data feedback, but has a clear intelligent optimization orientation. The cloud extracts "inference bias data" as samples from the inference results fed back from the edge nodes, and performs targeted optimization of the loss function and weight distribution of the cloud model. This bias-driven targeted optimization strategy enables cloud training to accurately focus on the weak links of the model in real-world edge scenarios, rather than learning indiscriminately from all samples. This accelerates the model convergence speed and improves the effectiveness of each iteration, realizing a training paradigm upgrade from "passively receiving all results" to "actively mining difficult samples", significantly reducing the number of iterations and computational overhead required to achieve the target accuracy.

[0028] 10. It abandons the traditional approach of obtaining edge status through independent channel polling, and achieves deep integration of control flow and data flow. Dynamic parameters such as edge node computing load, network status, and inference task margin are embedded in the device status field of each protocol message. The cloud can obtain real-time situation information simultaneously while receiving business data, without the need to send additional status query requests. This "in-band" status transmission mechanism not only eliminates the additional handshake and message round-trip overhead caused by separate monitoring, but also ensures strict alignment of situation assessment data and business data in terms of timestamps. It provides accurate and low-latency decision-making basis for the three-dimensional decision matrix, and greatly improves the system's response speed to network jitter and sudden changes in edge load.

[0029] 11. Model update urgency parameter (quantified by integrating business scenario priority and accuracy improvement magnitude): The system can clearly distinguish between different types of model distribution tasks, such as urgent security patch updates, critical accuracy repairs, and routine performance optimizations. Combined with the dynamic switching between fragmented parallel transmission and single-frame transparent transmission modes based on data volume thresholds, it ensures that when bandwidth or edge resources are limited, the most critical and urgent business updates can obtain transmission and deployment resources first, rather than mechanically allocating resources based solely on network quality or load. This gives the cloud-edge collaborative system a highly flexible adaptability in complex industrial scenarios (such as sudden security threats or emergency production line modifications). Attached Figure Description

[0030] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0031] Figure 1 This is a flowchart of a cloud training and edge inference collaborative scheduling method based on a custom lightweight protocol according to the present invention. Detailed Implementation

[0032] The technical solution in this application embodiment follows the following general approach: It abandons the traditional model of general heavy protocols and full model distribution, and instead defines a custom lightweight protocol with only a 16-byte single-frame protocol header. This embeds specific semantics such as service type, model version, transmission attributes, verification and fault tolerance, and device status into the message, achieving accurate identification of cloud-edge interaction intent with extremely low overhead. Simultaneously, it uses heartbeat packets to collect network and load parameters in real time and generate a situation assessment. The cloud generates incremental data packets based on the weight difference between the old and new models, and integrates network status, edge load, and model update urgency to construct a three-dimensional decision matrix. This dynamically determines distribution strategies such as full-speed, rate-limited, or fragmented silent distribution. Edge nodes verify the integrity of protocol fields and add incremental data to complete iterations. The inference results are fed back to drive reverse optimization in the cloud, forming a highly efficient closed loop of "training-distribution-inference-feedback." Furthermore, it incorporates breakpoint resumption, exception rollback, and adaptive adjustment of interaction modes to comprehensively improve the protocol semantic efficiency, transmission adaptability, and system fault tolerance reliability of cloud-edge collaboration.

[0033] Please refer to Figure 1 As shown, a preferred embodiment of the cloud training and edge inference collaborative scheduling method based on a custom lightweight protocol of the present invention includes the following steps: Step S1: Define a lightweight collaborative protocol for cloud training and edge inference. The message structure of the lightweight collaborative protocol includes a service type field, a model version field, a transmission attribute field, a verification and fault tolerance field, and a device status field. The lightweight collaborative protocol replaces traditional common protocols such as MQTT and TCP, and the single-frame protocol header length is compressed to 16 bytes, which is far lower than the protocol header overhead of more than 40 bytes of common protocols, greatly reducing transmission redundancy.

[0034] Step S2: Based on the lightweight collaboration protocol, the cloud and edge nodes periodically send protocol heartbeat packets to each other, collect real-time network status parameters and edge node load parameters, and generate cloud-edge collaboration situation assessment results. This invention relies on custom protocol-specific fields to achieve synchronous transmission of situational data along with messages, eliminating the need to build additional sensing links, reducing system resource consumption, and realizing the integration of sensing, transmission, and scheduling.

[0035] Step S3: After the cloud completes the iterative training of the deep learning model, it generates an incremental model data packet. Based on the cloud-edge collaborative situation assessment results, it dynamically adjusts the distribution strategy, encapsulates the incremental model data packet through the lightweight collaborative protocol, and distributes it to the edge node. At the same time, the cloud distributes inference scheduling instructions to the edge node through the lightweight collaborative protocol according to business needs. Step S4: The edge node listens to and receives the messages corresponding to the lightweight collaboration protocol in real time, and parses the business type field in the message to distinguish the task type; when receiving the incremental model data packet, it verifies the data integrity through the verification fault tolerance field. After verification, the incremental parameters are superimposed on the local old model to complete the model iteration update; when receiving the inference scheduling instruction, it executes the corresponding inference task. Step S5: After completing each round of inference tasks, the edge node sends the inference results back to the cloud via the lightweight collaborative protocol; the cloud optimizes the model training parameters based on the sent-back inference results. Step S6: Dynamically adjust the cloud-edge interaction mode based on the cloud-edge collaborative situation assessment results.

[0036] In step S1, the service type field is used to distinguish between incremental model distribution, full model update, inference task scheduling, edge result feedback, cloud-edge heartbeat synchronization, and abnormal alarm service scenarios; the model version field is used to record the model version number, precision parameters, and update time of the cloud-trained model; the transmission attribute field includes data priority, fragment sequence number, incremental transmission identifier, and verification identifier; the verification and fault tolerance field carries the model hash value (used for final verification of the complete model after full reception to prevent overall errors after fragment splicing), data verification code (used for verification while receiving to ensure the correctness of each fragment during transmission), and breakpoint resume flag; the device status field records the computing load, network status, and inference task remaining capacity of the edge node. The lightweight collaborative protocol has a single-frame protocol header length of 16 bytes, and the service type field, model version field, transmission attribute field, verification and fault tolerance field, and device status field are encapsulated in the single-frame protocol header.

[0037] In this embodiment, the single-frame protocol header is a fixed 16 bytes, and its fields are allocated as follows: Business type field (Byte0): Encoded with enumerated values, for example, 0x01 represents incremental model distribution, 0x02 represents full model update, 0x03 represents inference task scheduling, 0x04 represents edge result feedback, 0x05 represents cloud-edge heartbeat synchronization, and 0x06 represents anomaly alarm.

[0038] Model version field (Byte1-4): Byte1-2 stores the major version number and minor version number, Byte3 stores the precision parameter (such as the integer part of the mAP value), and Byte4 stores the lower 8 bits of the iteration timestamp.

[0039] Transmission attribute fields (Byte5-8): Defined using a bitmap method. Bits 0-2 indicate data priority (levels 0-7), Bits 3-4 indicate the high-order bits of the fragment sequence number, Bit 5 indicates whether it is an incremental transmission, and Bit 6 indicates whether it contains check information.

[0040] Verification fault tolerance field (Byte9-12): Used to carry the lower 32 bits of the CRC32 checksum or model hash value, as well as the breakpoint resume flag.

[0041] Device status fields (Byte13-15): Byte13 indicates the percentage of computing load, Byte14 indicates the network signal strength or bandwidth utilization, and Byte15 indicates the number of inference tasks currently pending.

[0042] Step S2 specifically involves: Based on the aforementioned lightweight collaboration protocol, the cloud and edge nodes periodically exchange protocol heartbeat packets to collect real-time network status parameters and edge node load parameters; the real-time network status parameters include real-time network bandwidth, link latency, and packet loss rate; the edge node load parameters include edge node computing power load and inference task queue length. The real-time network status parameters and edge node load parameters collected are denoised using a sliding window algorithm to generate a cloud-edge collaborative situation assessment result. The cloud-edge collaborative situation assessment result includes network status level and edge load status level. The network status level is divided into four levels: stable, slight fluctuation, congestion, and disconnection. The edge load status is divided into four states: heavy load, medium load, light load, and no load.

[0043] In step S3, the incremental model data package is generated by comparing the parameters of the old and new model versions in the cloud, calculating the weight difference of the iterative update, and generating the incremental model data package.

[0044] In a specific embodiment, assume the global model weight tensor trained in the cloud is W_old, and the updated weight tensor obtained after a new round of training is W_new. The cloud calculates the weight difference ΔW = W_new - W_old, which is the original data of the incremental model data packet. To further compress the transmission volume, the cloud uses sparse coding technology: it scans all elements in ΔW, retains only the weight differences whose absolute values ​​are greater than a preset threshold (e.g., the threshold is 0.01), and performs run-length encoding or direct encoding on these non-zero differences and their index coordinates in the tensor to generate the final incremental model data packet. Simultaneously, the cloud uses a hash algorithm (such as SHA-256) to calculate the digest value of the incremental data packet and fills it into the verification and fault tolerance field for integrity verification after reception by the edge nodes.

[0045] In step S3, the dynamic adjustment of the distribution strategy based on the cloud-edge collaborative situation assessment results specifically includes: Obtain the model update urgency parameter of the currently issued task. The model update urgency parameter is generated quantitatively based on the priority of the business scenario and the accuracy improvement between the old and new cloud model versions. Based on the network status level, edge load status level, and model update urgency parameter, a three-dimensional decision matrix is ​​constructed, and a distribution strategy is determined according to the three-dimensional decision matrix. The distribution strategy specifically includes: (1) When the network state level is stable and the edge load state level is lightly loaded or unloaded: If the urgency parameter of the model update exceeds the preset urgency threshold, the full-speed delivery mode is adopted to transmit the incremental model data packet with the maximum available bandwidth of the current link. If the urgency parameter of the model update does not exceed the preset urgency threshold, a rate-limited delivery mode is adopted, which limits the delivery bandwidth to a predetermined proportion of the real-time idle bandwidth of the current link, so as to prioritize the normal inference services of the edge nodes. (2) When the network status level is slightly fluctuating and the edge load status level is medium or heavy: A fragmented background silent delivery mode is adopted. Specifically, the incremental model data packet is divided into multiple fragments according to the fragment sequence number in the transmission attribute field. The inference task margin in the device status field is used as reverse pressure to dynamically adjust the delivery time interval of each fragment to achieve fragmented peak transmission. The delivery time interval is inversely proportional to the inference task margin. When the inference task margin is greater than the preset high water level, the delivery time interval is increased. When the inference task margin is lower than the preset low water level, the delivery time interval is decreased. (3) When the network status level is congested: The incremental model data packets are paused from being sent, and the breakpoint resume flag and the confirmed fragment sequence number of the currently transmitted incremental model data packets are written into the verification fault tolerance field. At the same time, link prediction monitoring is enabled, and the link recovery time window is calculated based on the real-time packet loss rate and round-trip delay. After entering the link recovery time window, the transmission is resumed from the next fragment after the confirmed fragment sequence number through the breakpoint resume flag. The full-speed delivery mode, the rate-limited delivery mode, and the fragmented background silent delivery mode all carry the corresponding delivery strategy identifier through the transmission attribute field in the lightweight collaborative protocol, so that the edge node can adjust the write strategy of the receiving buffer accordingly when receiving.

[0046] In a specific embodiment, the calculation of the link recovery time window may adopt a prediction method based on historical data. Specifically, the cloud end maintains the records of packet loss rate (P_loss) and round-trip time (RTT) of the latest N heartbeat periods (e.g., N=10). The cloud end uses a linear regression or exponentially weighted moving average method to predict the time length t_recover required for the packet loss rate to drop to a preset transmittable threshold (e.g., the packet loss rate is lower than 5%). The cloud end sets a timer according to the calculated t_recover. After the timer expires, it is determined that the link recovery time window is entered. At this time, the cloud end retransmits the probe packet. If the network condition has improved, the data transmission is resumed according to the resume transmission from break point flag.

[0047] The specific judgment logic for constructing the three-dimensional decision matrix according to the network state level (A), the edge load state level (B) and the model update urgency (C) is as follows (assuming the preset urgency threshold is Th): 1. Logic priority rule: The model update urgency C has the highest priority. When C exceeds Th, no matter what level the network and load are at, as long as the network is not disconnected, the system preferentially attempts to issue the model to ensure the timeliness of security patches or critical accuracy fixes.

[0048] 2. Combined decision example: When A is stable, B is light load / no load, and C<Th, the system periodically acquires the current link idle bandwidth value X, and the predetermined proportion is set to 60% of X, so as to implement rate-limited issuing and ensure that conventional inference services are not affected.

[0049] When A is slight fluctuation, B is heavy load, and C<Th, the system splits the incremental model data packet into N fragments (for example, each fragment has a size of 64KB), and the calculation formula of the issuing time interval T is: T=T_base+(Q_current / Q_max)*T_delta; where T_base is the minimum interval (e.g., 50ms), Q_current is the current inference task queue length, Q_max is the maximum queue threshold, and T_delta is the dynamic adjustment coefficient (e.g., 200ms). The longer the inference task queue is, the larger the interval is, thereby effectively avoiding resource contention.

[0050] When A is congested, the calculation method of the link recovery time window is: based on the packet loss rate P_loss and round-trip time RTT of the past 10 periods, predict the time t_recover required for network recovery through linear regression or exponential smoothing method, set a timer, and attempt retransmission after the time t_recover elapses.

[0051] In step S3, encapsulating the incremental model data packet includes: marking this transmission as an incremental model delivery through the service type field in the lightweight collaboration protocol, writing the model version number of the current iteration through the model version field, writing the model hash value, data checksum and breakpoint resume flag of the incremental model data packet through the verification and fault tolerance field, and writing the fragment sequence number of the incremental model data packet through the transmission attribute field.

[0052] In step S4, after the edge node parses the received incremental model data packet, it verifies the data integrity through the model hash value and data check code in the verification fault tolerance field; if the verification passes, the incremental parameters are superimposed on the local old model to complete the iterative update; if the verification fails, it requests the cloud to retransmit the corresponding fragment data. When edge nodes perform inference tasks, they set high priority for urgent inference tasks and high-precision detection tasks by using the data priority in the transmission attribute field of the lightweight collaboration protocol, and prioritize the scheduling of computing power and transmission resources.

[0053] The specific processing flow for edge nodes receiving fragmented data is as follows: 1. Cache Management: The edge node receive buffer adopts a double buffering mechanism. While one buffer is writing received fragment data, the other buffer is used to process the completed fragment, preventing data write conflicts.

[0054] 2. Verification and Retransmission: Upon receiving each fragment, the edge node concatenates it into a local temporary file based on the fragment sequence number in the protocol header. After all fragments have been received, the hash value of the entire file is calculated and compared with the model hash value in the verification fault tolerance field. If they do not match, the edge node sends a retransmission request to the cloud containing a "list of failed fragment sequence numbers," retransmitting only the specific fragments, not the entire model file.

[0055] 3. Fault recovery: When the edge node restarts and the reception is interrupted due to a restart or network disconnection, it first sends the "confirmed fragment sequence number" and "breakpoint resume flag" that it has saved locally to the cloud. The cloud then continues to transmit the remaining fragments from the breakpoint without having to start from the beginning.

[0056] In step S5, the cloud extracts inference bias data from the inference results returned by the edge nodes as sample data, performs reverse optimization on the loss function and weight distribution of the cloud-trained model, iteratively generates an updated model version, and forms a closed-loop collaboration of cloud training iteration, edge landing inference, edge data feedback, and cloud precise optimization. When the cloud detects a model update failure, inference anomaly, or link interruption, it automatically triggers mechanisms to roll back the old model, retry the task, or reconnect the link.

[0057] In a specific industrial vision quality inspection application scenario, the inference results returned by the edge nodes include images of workpieces judged as "defective" and their corresponding confidence scores. Upon receiving this data, the cloud identifies samples with confidence scores within a preset ambiguity range (e.g., between 0.4 and 0.6) and incorrectly judged samples as "inference bias data." The cloud utilizes this bias data to specifically calculate its gradient contribution to the model's loss function and assigns higher loss weights to these samples during backpropagation. This allows for targeted correction of the model's weight distribution on these problematic samples, enabling the model trained in the next iteration to more accurately handle such ambiguous samples in edge scenes. Ultimately, this achieves rapid convergence and precise tuning of the bias-driven model.

[0058] In step S6, dynamically adjusting the cloud-edge interaction mode based on the cloud-edge collaborative situation assessment results specifically includes: For model data whose data volume exceeds the preset fragmentation threshold, a fragmented parallel transmission method is adopted. For instruction and result data whose data volume does not exceed the preset fragmentation threshold, a single-frame direct encapsulation and transparent transmission method is adopted. When the edge node is in a light-load state and the network is idle, it actively completes model iteration and data synchronization. When the edge node is in a heavy-load state or the network is congested, non-real-time inference business interaction is suspended and inference business is prioritized.

[0059] The method is deployed based on the KubeEdge cloud-edge collaboration framework. The lightweight collaboration protocol is adapted and extended at the protocol interface layer of the KubeEdge framework. The KubeEdge framework manages the container scheduling and resource management of the edge nodes, and the lightweight collaboration protocol executes the cloud-edge service interaction and scheduling control.

[0060] Specifically, when deployed on the KubeEdge framework, the lightweight collaboration protocol of this invention does not replace the underlying WebSocket or gRPC communication mechanism of KubeEdge, but is carried on top of it as an application-layer business protocol. Adaptation development is performed at the interface layer of KubeEdge's CloudCore and EdgeCore modules, mapping the business type fields and fault tolerance fields of this protocol to the "Data" field in the KubeEdge message body for transparent transmission. When EdgeCore receives a message, it parses the business type field and distributes the message to the corresponding data processing function. For example, if it is identified as "incremental model delivery," the model update processor of the edge node is triggered; if it is identified as "inference task scheduling," the inference task executor is triggered. In this way, this invention fully utilizes KubeEdge's powerful underlying node management and container orchestration capabilities, while also endowing it with efficient and semantic cloud-edge business collaboration scheduling capabilities.

[0061] Taking an industrial vision quality inspection system as an example, a defect detection model is trained in the cloud. When the cloud detects a 2% improvement in model accuracy (medium urgency), and the edge nodes are under heavy load (processing a large number of real-time images) with unstable network signals (slight fluctuations), the system, based on a 3D decision matrix, adopts a "sharded background silent delivery mode." This involves dividing the incremental model into multiple 1MB shards and delivering them sequentially during the processing intervals of industrial quality inspection tasks (200ms intervals). The entire process does not affect the normal operation of the production line. After the edge nodes receive the data, they verify the hash value, add the incremental model to the old model, and perform hot-loading of the model during the next idle inference task (such as during production changeovers), achieving a smooth model upgrade without any impact on the business.

[0062] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the present invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A cloud training and edge inference collaborative scheduling method based on a custom lightweight protocol, characterized in that, Includes the following steps: Step S1: Define a lightweight collaborative protocol for cloud training and edge inference. The message structure of the lightweight collaborative protocol includes a service type field, a model version field, a transmission attribute field, a verification and fault tolerance field, and a device status field. Step S2: Based on the lightweight collaboration protocol, the cloud and edge nodes periodically send protocol heartbeat packets to each other, collect real-time network status parameters and edge node load parameters, and generate cloud-edge collaboration situation assessment results. Step S3: After the cloud completes the iterative training of the deep learning model, it generates an incremental model data packet. Based on the cloud-edge collaborative situation assessment results, it dynamically adjusts the distribution strategy, encapsulates the incremental model data packet through the lightweight collaborative protocol, and distributes it to the edge node. At the same time, the cloud distributes inference scheduling instructions to the edge node through the lightweight collaborative protocol according to business needs. Step S4: The edge node listens to and receives the messages corresponding to the lightweight collaboration protocol in real time, and parses the business type field in the message to distinguish the task type; when receiving the incremental model data packet, it verifies the data integrity through the verification fault tolerance field. After verification, the incremental parameters are superimposed on the local old model to complete the model iteration update; when receiving the inference scheduling instruction, it executes the corresponding inference task. Step S5: After completing each round of inference tasks, the edge node sends the inference results back to the cloud via the lightweight collaborative protocol; the cloud optimizes the model training parameters based on the sent-back inference results. Step S6: Dynamically adjust the cloud-edge interaction mode based on the cloud-edge collaborative situation assessment results.

2. The cloud training and inference collaborative scheduling method based on a custom lightweight protocol as described in claim 1, characterized in that, In step S1, the service type field is used to distinguish between incremental model distribution, full model update, inference task scheduling, edge result feedback, cloud-edge heartbeat synchronization, and abnormal alarm service scenarios; the model version field is used to record the model version number, accuracy parameters, and update time of the cloud-trained model; the transmission attribute field includes data priority, fragment sequence number, incremental transmission identifier, and verification identifier; the verification fault tolerance field carries the model hash value, data verification code, and breakpoint resume flag; the device status field records the computing power load, network status, and inference task remaining capacity of the edge node. The lightweight collaborative protocol has a single-frame protocol header length of 16 bytes, and the service type field, model version field, transmission attribute field, verification and fault tolerance field, and device status field are encapsulated in the single-frame protocol header.

3. The cloud training and inference collaborative scheduling method based on a custom lightweight protocol as described in claim 1, characterized in that, Step S2 specifically involves: Based on the aforementioned lightweight collaboration protocol, the cloud and edge nodes periodically exchange protocol heartbeat packets to collect real-time network status parameters and edge node load parameters; the real-time network status parameters include real-time network bandwidth, link latency, and packet loss rate; the edge node load parameters include edge node computing power load and inference task queue length. The real-time network status parameters and edge node load parameters collected are denoised using a sliding window algorithm to generate a cloud-edge collaborative situation assessment result. The cloud-edge collaborative situation assessment result includes network status level and edge load status level. The network status level is divided into four levels: stable, slight fluctuation, congestion, and disconnection. The edge load status is divided into four states: heavy load, medium load, light load, and no load.

4. The cloud training and inference collaborative scheduling method based on a custom lightweight protocol as described in claim 1, characterized in that, In step S3, the incremental model data package is generated by comparing the parameters of the old and new model versions in the cloud, calculating the weight difference of the iterative update, and generating the incremental model data package.

5. The cloud training and inference collaborative scheduling method based on a custom lightweight protocol as described in claim 3, characterized in that, In step S3, the dynamic adjustment of the distribution strategy based on the cloud-edge collaborative situation assessment results specifically includes: Obtain the model update urgency parameter of the currently issued task. The model update urgency parameter is generated quantitatively based on the priority of the business scenario and the accuracy improvement between the old and new cloud model versions. Based on the network status level, edge load status level, and model update urgency parameter, a three-dimensional decision matrix is ​​constructed, and a distribution strategy is determined according to the three-dimensional decision matrix. The distribution strategy specifically includes: (1) When the network state level is stable and the edge load state level is lightly loaded or unloaded: If the urgency parameter of the model update exceeds the preset urgency threshold, the full-speed delivery mode is adopted to transmit the incremental model data packet with the maximum available bandwidth of the current link. If the urgency parameter of the model update does not exceed the preset urgency threshold, a rate-limited delivery mode is adopted, which limits the delivery bandwidth to a predetermined proportion of the real-time idle bandwidth of the current link, so as to prioritize the normal inference services of the edge nodes. (2) When the network status level is slightly fluctuating and the edge load status level is medium or heavy: A fragmented background silent delivery mode is adopted. Specifically, the incremental model data packet is divided into multiple fragments according to the fragment sequence number in the transmission attribute field. The inference task margin in the device status field is used as reverse pressure to dynamically adjust the delivery time interval of each fragment to achieve fragmented peak transmission. The delivery time interval is inversely proportional to the inference task margin. When the inference task margin is greater than the preset high water level, the delivery time interval is increased. When the inference task margin is lower than the preset low water level, the delivery time interval is decreased. (3) When the network status level is congested: The incremental model data packets are paused from being sent, and the breakpoint resume flag and the confirmed fragment sequence number of the currently transmitted incremental model data packets are written into the verification fault tolerance field. At the same time, link prediction monitoring is enabled, and the link recovery time window is calculated based on the real-time packet loss rate and round-trip delay. After entering the link recovery time window, the transmission is resumed from the next fragment after the confirmed fragment sequence number through the breakpoint resume flag. The full-speed delivery mode, the rate-limited delivery mode, and the fragmented background silent delivery mode all carry the corresponding delivery strategy identifier through the transmission attribute field in the lightweight collaborative protocol, so that the edge node can adjust the write strategy of the receiving buffer accordingly when receiving.

6. The cloud training and inference collaborative scheduling method based on a custom lightweight protocol as described in claim 1, characterized in that, In step S3, encapsulating the incremental model data packet includes: marking this transmission as an incremental model delivery through the service type field in the lightweight collaboration protocol, writing the model version number of the current iteration through the model version field, writing the model hash value, data checksum and breakpoint resume flag of the incremental model data packet through the verification and fault tolerance field, and writing the fragment sequence number of the incremental model data packet through the transmission attribute field.

7. The cloud training and inference collaborative scheduling method based on a custom lightweight protocol as described in claim 1, characterized in that, In step S4, after the edge node parses the received incremental model data packet, it verifies the data integrity by using the model hash value and data check code in the verification fault tolerance field. If the verification passes, the incremental parameters will be added to the local old model to complete the iterative update; If the verification fails, request the cloud to retransmit the corresponding fragment data; When edge nodes perform inference tasks, they set high priority for urgent inference tasks and high-precision detection tasks by using the data priority in the transmission attribute field of the lightweight collaboration protocol, and prioritize the scheduling of computing power and transmission resources.

8. The cloud training and inference collaborative scheduling method based on a custom lightweight protocol as described in claim 1, characterized in that, In step S5, the cloud extracts inference bias data from the inference results returned by the edge nodes as sample data, performs reverse optimization on the loss function and weight distribution of the cloud-trained model, iteratively generates an updated model version, and forms a closed-loop collaboration of cloud training iteration, edge landing inference, edge data feedback, and cloud precise optimization. When the cloud detects a model update failure, inference anomaly, or link interruption, it automatically triggers mechanisms to roll back the old model, retry the task, or reconnect the link.

9. The cloud training and inference collaborative scheduling method based on a custom lightweight protocol as described in claim 1, characterized in that, In step S6, dynamically adjusting the cloud-edge interaction mode based on the cloud-edge collaborative situation assessment results specifically includes: For model data whose data volume exceeds the preset fragmentation threshold, a fragmented parallel transmission method is adopted. For instruction and result data whose data volume does not exceed the preset fragmentation threshold, a single-frame direct encapsulation and transparent transmission method is adopted. When the edge node is in a light-load state and the network is idle, it actively completes model iteration and data synchronization. When the edge node is in a heavy-load state or the network is congested, non-real-time inference business interaction is suspended and inference business is prioritized.

10. The cloud training and edge inference collaborative scheduling method based on a custom lightweight protocol as described in claim 1, characterized in that, The method is deployed based on the KubeEdge cloud-edge collaboration framework. The lightweight collaboration protocol is adapted and extended at the protocol interface layer of the KubeEdge framework. The KubeEdge framework manages the container scheduling and resource management of the edge nodes, and the lightweight collaboration protocol executes the cloud-edge service interaction and scheduling control.

Images