A multi-transport center-oriented edge computing power cloud edge collaboration management method and system

Abstract

The application discloses a multi-transport center-oriented edge computing power cloud edge cooperative management method and system, relates to the GPU computing power resource management technical field, and comprises the following steps: deploying a cloud management platform, establishing an edge management domain, dividing a state cycle, collecting edge node data, generating a resource state ledger, collecting edge application job parameters in the state cycle, analyzing edge application job pressure, generating an elastic computing power demand interval according to the edge application job pressure, constructing an application executable node set through the resource state ledger, dividing computing power tokens, analyzing application token allocation priorities, and allocating the computing power tokens, selecting a target transport center for the edge application allowed to be transported, selecting a target node based on the application executable node set of the target transport center, locking the target node, and creating an application instance to transport the edge application after the target node is locked. The application improves the multi-transport center GPU resource utilization efficiency, real-time application guarantee capability and edge application deployment stability.

Description

Technical Field

[0001] This invention relates to the field of GPU computing power resource management technology, and in particular to an edge computing power cloud-edge collaborative management method and system for multiple transfer centers. Background Technology

[0002] With the development of automated logistics sorting, intelligent video analytics, and edge AI technologies, transshipment centers are gradually deploying cameras, video decoding servers, and GPU edge nodes in loading and unloading areas, conveyor lines, and sorting slots. They are also utilizing edge applications such as forced sorting detection and package missorting detection to process on-site video in real time. Compared to centralized processing methods that continuously upload raw video to the cloud, edge computing can shorten video transmission paths, reduce central network bandwidth usage, and improve the real-time performance of on-site identification and alarm response. For logistics networks with multiple transshipment centers, cloud-edge collaborative management technology further centrally manages GPU nodes, application versions, and operational statuses at different geographical locations through a cloud management platform, while retaining video decoding, algorithm inference, and local task execution capabilities at the edge. Existing cloud-edge collaborative architectures typically employ technologies such as container image management, edge node registration, resource monitoring, and task scheduling, enabling edge applications to be deployed and run on different GPU servers, and obtaining node utilization, application operational status, and computation results uniformly through the cloud. With the continuous increase in the number of transit centers, video channels, and edge applications, GPU computing power management has evolved from a single-node resource allocation problem to a comprehensive resource management problem involving multi-transfer center status coordination, heterogeneous GPU capability conversion, application resource requirement estimation, and business priority assurance. However, existing multi-transfer center edge computing power management technologies typically allocate tasks based on GPU utilization, idle video memory, or fixed resource configuration, lacking joint analysis of package throughput, effective video input rate, algorithm input queue backlog, business event urgency, and image target density and motion intensity. Therefore, it is difficult to accurately determine the actual computing power requirements of edge applications before changes in transit workload. Summary of the Invention

[0003] In view of the aforementioned existing problems, the present invention is proposed.

[0004] Therefore, this invention provides a cloud-edge collaborative management method and system for edge computing power in multiple transfer centers, which solves the problem that existing technologies cannot accurately determine the actual computing power requirements of edge applications before changes in transfer operation load.

[0005] To solve the above-mentioned technical problems, the present invention provides the following technical solution: In a first aspect, the present invention provides a cloud-edge collaborative management method for edge computing power in multiple transit centers, comprising, Deploy a cloud management platform to establish an edge management domain and divide the state cycle to collect edge node data and generate a resource status ledger; During the state cycle, collect edge application job parameters to analyze the edge application job pressure, and generate elastic computing power demand range based on the edge application job pressure. Construct a set of application executable nodes using a resource status ledger; The computing power tokens are divided and the application token allocation priority is analyzed to allocate computing power tokens. For edge applications that are allowed to be transferred, a target transfer center is selected. Based on the set of application executable nodes of the target transfer center, a target node is selected. After locking the target node, an application instance is created to transfer the edge application.

[0006] As a preferred embodiment of the edge computing power cloud-edge collaborative management method for multiple transit centers described in this invention, the specific steps of deploying the cloud management platform to establish an edge management domain and dividing the state cycle to collect edge node data and generate a resource status ledger are as follows: Deploy a cloud management platform in the cloud; Establish an independent edge management domain within each transit center; The cloud management platform generates unique identifiers for each transit center, edge node, terminal device, edge application, application version, and application instance. A unified time service is set up, and each transit center initiates a time synchronization every 60 seconds. After the time synchronization is completed, the running time is divided into continuous state cycles. Within each state cycle, the edge node agent collects dynamic status at a 5-second sampling interval and uses the state cycle number as an index to form a multi-transfer center resource status ledger.

[0007] As a preferred embodiment of the edge computing power cloud-edge collaborative management method for multiple transit centers described in this invention, the step of collecting edge application job parameters and analyzing edge application job pressure within the state cycle specifically involves: Within each state cycle, collect operation-related parameters for edge applications in the transfer center, including parcel throughput, effective video input speed, algorithm input queue backlog, business event urgency, image target density, and image motion intensity. The edge application performs target detection on the video frames received within the state period, counts the number of valid targets in each frame, takes the average number of valid targets in each frame within the state period as the current number of targets, and divides it by the 95th percentile of the number of targets in the same application in the last seven full running days to obtain the normalized screen target density. Edge applications perform grayscale processing on adjacent extracted frames and calculate the absolute difference of corresponding pixels. The absolute difference of all pixels is averaged to obtain the degree of change of a single group of adjacent frames. The degree of change of all adjacent frames within the state cycle is averaged to obtain the amount of screen motion in the current cycle. The current amount of screen motion is divided by the 95th percentile of the screen motion of the same application in the last seven complete running days to obtain the normalized screen motion intensity. The normalized image target density and normalized image motion intensity are weighted by 1 to calculate the image complexity; For parcel throughput, effective video input rate, and algorithm input queue backlog, the 95th percentile of the corresponding data in the most recent seven complete operating days is calculated to obtain the parcel throughput benchmark, effective video input rate benchmark, and queue backlog benchmark. The benchmark values ​​are normalized to obtain normalized parcel throughput, normalized effective video input rate, and normalized queue backlog. These are then weighted by the urgency of business events and multiplied by the complexity of the image to obtain the operational pressure of the edge application within the state cycle. The predicted stress for the next state cycle is calculated using an exponential smoothing method.

[0008] As a preferred embodiment of the edge computing power cloud-edge collaborative management method for multiple transit centers described in this invention, the step of generating elastic computing power demand intervals based on edge application job pressure specifically refers to: The cloud creates resource description files for new versions of edge applications; Establish independent benchmark tasks for each edge application version and each supported GPU model; For edge applications in the transfer center, the input size is adjusted by calculating the product of the current number of access video channels, the single-channel frame extraction frequency, and the complexity of the image. The valid benchmark results of the same application version and the same GPU model are arranged in ascending order of the corrected input size to form multiple test points. Each test point includes the corrected input size and the corresponding GPU equivalent utilization. If the current corrected input size is between the corrected input sizes of adjacent test points, then the basic GPU requirement is calculated using linear interpolation of adjacent test points. The peak GPU memory values ​​at each test point are arranged according to the corrected input scale. For the current input scale located between adjacent test points, linear interpolation is performed using the adjacent peak memory values ​​to obtain the basic memory requirement. A memory safety margin is added to the basic memory requirement to generate the recommended memory requirement. Calculate the three corrected input scales based on the application resource description file, obtain the corresponding GPU requirements, and form the application elastic computing power requirement range.

[0009] As a preferred embodiment of the edge computing power cloud-edge collaborative management method for multiple transit centers described in this invention, the step of constructing a set of application executable nodes through a resource status ledger specifically involves: Within each state cycle, the operational data of each edge node of the transfer center is extracted from the resource state ledger and a node operational status record is generated; Calculate the basic state factors of the edge nodes, including heartbeat state factor, temperature state factor, error state factor, network state factor, and disk state factor; The overall health of the nodes is obtained by weighted fusion of the basic state factors of the edge nodes; The system considers the physical resources of the nodes, current resource usage, system reserved resources, and health status to calculate the effective GPU capacity and effective video memory capacity of the nodes. Establish compatibility state constraints and data locality state constraints between edge nodes and edge applications; Based on node health, effective GPU capacity, effective video memory capacity, compatibility status, and data locality status, construct a set of executable nodes for the application.

[0010] As a preferred embodiment of the edge computing power cloud-edge collaborative management method for multiple transit centers described in this invention, the step of dividing computing power tokens and analyzing the application token allocation priority to allocate computing power tokens, and selecting target transit centers for edge applications that are allowed to transit, specifically involves: Divide the equivalent capacity of a GPU into computing power tokens with fixed granularity, and calculate the number of tokens that the transfer center can use for new tasks and elastic adjustments based on the effective GPU capacity. Based on the GPU requirements corresponding to the three types of modified input scales, minimum guarantee tokens, recommended supplementary tokens, and burst supplementary tokens are generated respectively. Application business priorities are marked, and the application token allocation priority is obtained by weighting the business priority, normalized prediction pressure, and normalized queue backlog. The cloud management platform first allocates minimum guarantee tokens to all real-time applications within the transfer center. After the minimum guarantee is completed, it prioritizes replenishing recommended tokens for first-level applications. Then, it allocates recommended tokens to other applications according to the token allocation priority from high to low. If there are still remaining available tokens, it continues to allocate emergency tokens according to the same priority. Finally, the remaining tokens enter the non-real-time task shared resource pool. For non-real-time tasks marked as allowed to run across transit centers in the resource description file, the cloud management platform filters candidate centers with remaining tokens from other transit centers, calculates the receiving score of the candidate centers, and selects the transit center with the highest receiving score and a score not lower than 0.50 as the target center for the non-real-time task. The token allocation result and the cross-center task reception result are recorded as a complete computing power commitment token record.

[0011] As a preferred embodiment of the edge computing power cloud-edge collaborative management method for multiple transit centers described in this invention, the selection of target nodes based on the set of application executable nodes of the target transit center specifically involves: After receiving the computing power commitment token locally, the transit center verifies the token and binds the minimum guarantee token to the application in the token. It calculates the deployment cost of the candidate node after application deployment for each candidate node in the set of executable nodes of the transit center, and selects the candidate node with the minimum deployment cost as the target node.

[0012] As a preferred embodiment of the edge computing power cloud-edge collaborative management method for multiple transit centers described in this invention, wherein: after locking the target node, an application instance is created for edge application transit. Once the target node is locked, the local task scheduler checks whether the application image, model, and configuration file are already located on the node. After verification, the target node creates an application instance according to the GPU capacity and recommended video memory requirements corresponding to the token, mounts the video parsing SDK, model files and application configuration to the instance, and establishes an input channel with the video decoding server. After the instance starts, a preset test frame is first input to complete the model warm-up, and then a health check is performed every 10 seconds. After three consecutive health checks are passed, the official video stream is switched to the new instance. If any health check fails, the instance is stopped, the bound tokens and node resources are released, and the reason for the failure is written to the application instance status record. Then, the node with the lowest deployment cost is re-selected from the remaining candidate nodes. The deployment is redeployed at most once. If it fails again, an application deployment exception record is generated.

[0013] As a preferred embodiment of the edge computing power cloud-edge collaborative management method for multiple transit centers described in this invention, the application instance deployment results are organized into a complete application deployment relationship record and uploaded to the resource status ledger.

[0014] Secondly, this invention provides an edge computing power cloud-edge collaborative management system for multiple transit centers, comprising, The data processing module is used to deploy the cloud management platform, establish the edge management domain, divide the state cycle, collect edge node data, and generate a resource status ledger. The application computing power analysis module is used to collect edge application job parameters and analyze edge application job pressure during the state cycle, and generate elastic computing power demand range based on edge application job pressure. The node analysis module is used to construct a set of application executable nodes through a resource status ledger; The computing power allocation and transfer module is used to divide computing power tokens and analyze the application token allocation priority to allocate computing power tokens. For edge applications that are allowed to transfer, a target transfer center is selected. Based on the set of application executable nodes of the target transfer center, a target node is selected. After locking the target node, an application instance is created to transfer the edge application.

[0015] The beneficial effects of this invention are as follows: By establishing a resource status ledger for multiple transit centers, this invention achieves unified association and time-series recording of devices, nodes, applications, versions, and video channels, thereby improving the traceability of operational status; by integrating transit workload, video input, queue backlog, event level, and screen complexity to generate operational pressure, and combining it with measured response relationships to form elastic computing power requirements, this invention improves the scenario adaptability of GPU demand estimation; by constructing a set of executable nodes based on node health, effective resources, compatibility status, and data locality, this invention reduces the risk of deploying tasks to abnormal or incompatible nodes; by coordinating real-time scheduling between cloud resource boundaries and the edge through hierarchical computing power commitment tokens, and by utilizing deployment costs to select target nodes, complete image verification, and instance health checks, this invention ultimately improves the GPU resource utilization efficiency of multiple transit centers, the real-time application assurance capability, and the stability of edge application deployment. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart of the edge computing power cloud-edge collaborative management method for multiple transit centers in Example 1.

[0018] Figure 2 This is a structural diagram of the edge computing power cloud-edge collaborative management system for multiple transfer centers in Example 1. Detailed Implementation

[0019] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0020] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0021] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0022] Example 1, referring to Figure 1 and Figure 2 This is the first embodiment of the present invention, which provides a cloud-edge collaborative management method for edge computing power in multiple transit centers, including the following steps: S1. Deploy a cloud management platform to establish an edge management domain and divide the status cycle to collect edge node data and generate a resource status ledger; S1.1 Deploy a cloud management platform in the cloud. The cloud-edge collaborative management platform includes at least a transfer center registration unit, an edge node registration unit, a terminal device management unit, an edge application management unit, an application version management unit, an isolated image repository, a resource status ledger unit, a global computing power strategy unit, an application release control unit, an operation monitoring unit, and a result data management unit. The system comprises the following components: a transfer center registration unit for establishing basic information and management boundaries for each transfer center; an edge node registration unit for receiving and verifying GPU servers, video decoding servers, and other edge computing devices; a terminal device management unit for recording field devices such as cameras, warning lights, and conveyor counters; an edge application management unit for managing violent sorting identification, package missorting identification, and other video analysis applications; an application version management unit and an isolated image repository for storing container images, model files, configuration files, and version dependency information; a resource status ledger unit for continuously recording the status of multiple transfer centers at a unified time period; and a global computing power strategy unit for generating the computing power allocation limit and guarantee amount for each transfer center in subsequent steps. Establish an independent edge management domain within each transit center. Each edge management domain includes at least a video decoding server, one or more GPU edge nodes, an edge node agent, a local task scheduler, a local application image cache, a local policy cache, a local result cache queue, and a cloud-edge communication agent. S1.2 and the cloud management platform generate unique identifiers for the transit center, edge node, terminal device, edge application, application version, and application instance, respectively. The transit center identifier is generated according to the pre-registered center number. For example, the transit center identifier of the third transit center is set to "C003". The edge node identifier consists of the transit center identifier and the node sequence number. For example, "C003-N005" represents the fifth GPU edge node in the third transit center. The terminal device identifier consists of the transit center identifier, device category, and device sequence number. For example, "C003-CAM012" represents the twelfth camera in the third transit center. The application instance identifier includes at least the transit center identifier, edge node identifier, edge application identifier, application version identifier, and instance sequence number. For example, "C003-N005-SORT-V3.2-P01" represents the first running instance of the violent sorting application version 3.2 deployed on the fifth GPU node of the third transit center. When the cloud receives any identification result or running status, it can directly determine the corresponding transfer center, terminal device, execution node, edge application and application version of the data, avoiding duplicate numbering between different transfer centers, and also making it easier to trace the actual generation environment of the event results after application version upgrade or node migration. For each camera, the cloud or transit center access module records the camera identifier, transit center, video stream address, video encoding format, original resolution, original frame rate, installation area, corresponding conveyor line, and business purpose. For each video decoding server, it records the number of video channels it can decode simultaneously, supported video encoding formats, maximum output resolution, available frame extraction frequency range, and network connection relationship with GPU edge nodes. For each edge application, it records the business type it processes, allowed camera areas, input resolution, allowed frame extraction frequency, minimum business frame extraction frequency, recommended business frame extraction frequency, and event output type. It establishes the association relationship between camera, video channel, video decoding server, and edge application. When the same camera needs to be used by multiple edge applications simultaneously, the video decoding server performs one decoding and multiple distribution of the decoded image frames, instead of each application repeatedly pulling and decoding the original video. A unified time service is set up. The cloud-edge communication agent of each transit center initiates time synchronization every 60 seconds. The cloud-edge communication agent estimates the round-trip latency based on the request sending time, cloud response time, and local reception time, and corrects the local clock deviation. When the deviation between the local time and the cloud reference time does not exceed 500 milliseconds, no additional adjustment is performed. When the deviation exceeds 500 milliseconds, a gradual time synchronization is adopted to gradually eliminate the deviation in multiple time synchronization cycles, instead of directly jumping to the local system time. After the time synchronization is completed, the running time is divided into continuous state cycles. In each state cycle, the edge node agent collects dynamic status at a sampling interval of 5 seconds and forms a multi-transfer center resource status ledger with the state cycle number as the index. The dynamic status includes CPU utilization, system memory utilization, GPU computing utilization, GPU video memory utilization, GPU temperature, GPU power consumption, GPU error count, local disk utilization, network uplink and downlink bandwidth, number of currently running application instances, input queue length of each application instance, average inference latency of each application instance, 95th percentile inference latency of each application instance, and the node's most recent heartbeat time. For parameters that fluctuate continuously, such as CPU utilization, GPU utilization, and network bandwidth, the average of 6 samples within a state cycle is used as the periodic state. For parameters that may pose instantaneous operational risks, such as GPU temperature, GPU memory usage, application inference latency, and error count, the maximum value within the cycle is used as the periodic state.

[0023] S2. Collect edge application operation parameters and analyze edge application operation pressure within the state cycle, and generate elastic computing power demand range based on edge application operation pressure. S2.1. During each state cycle, collect operation-related parameters for edge applications in the transfer center, including parcel throughput, effective video input speed, algorithm input queue backlog, business event urgency, image target density, and image motion intensity. The package throughput represents the number of packages per unit time in the corresponding work area of ​​the edge application within the state cycle, preferably expressed in pieces / minute. This parameter is obtained by the conveyor counter, barcode scanning system, or sorting control system. The effective video input speed represents the number of image frames successfully decoded by the video decoding server and meeting the clarity requirements within the state cycle, divided by the cycle duration, in frames / second. The algorithm input queue backlog is read from the edge application input buffer and represents the number of image frames that have not been processed at the end of the state cycle. The urgency of the business event is determined according to the level of the on-site event and uses a three-level normalized assignment: 0 when there is no abnormal event, 0.5 when there is a common missorting, common equipment abnormality, or general business alarm, and 1 when there is a violent sorting, continuous missorting, safety risk, or event requiring immediate on-site linkage. Edge applications perform target detection on video frames received within a state cycle, counting the number of valid targets in each frame. For violent sorting applications, valid targets include personnel, packages, and loading / unloading tools. For misclassification recognition applications, valid targets include packages, conveyor belt areas, and sorting slots. The average number of valid targets in each frame within the state cycle is taken as the current target number, and then divided by the 95th percentile of the target number of the same application in the last seven full operating days to obtain the normalized screen target density. When the normalization result is greater than 1, it indicates that the current target number exceeds the historical normal high load level. To avoid the abnormal detection of a single frame leading to an infinite amplification of subsequent pressure, the normalized screen target density is limited to between 0 and 1.5. Edge applications perform grayscale processing on adjacent extracted frames and calculate the absolute difference of corresponding pixels. The absolute difference of all pixels is averaged to obtain the degree of change of a single group of adjacent frames. The degree of change of all adjacent frames within the state cycle is then averaged to obtain the amount of screen motion in the current cycle. The current amount of screen motion is divided by the 95th percentile of the screen motion of the same application in the last seven complete running days to obtain the normalized screen motion intensity, which is also limited to between 0 and 1.5. The normalized image target density and normalized image motion intensity are weighted by 1 to calculate the image complexity, with the preferred weights being 0.6 and 0.4. The target density influence coefficient is higher than the motion intensity influence coefficient because brute-force sorting and package misclassification algorithms usually require feature extraction, position regression, correlation tracking, or behavior determination for each target. Increasing the number of targets will directly increase the number of algorithm branches and post-processing. Image motion mainly affects inter-frame changes and tracking difficulty, and its influence is relatively secondary. For parcel throughput, effective video input rate, and algorithm input queue backlog, the 95th percentiles of the corresponding data within the most recent seven complete operating days were statistically analyzed to obtain the benchmarks for parcel throughput, effective video input rate, and queue backlog. These benchmark values ​​were then normalized to obtain normalized parcel throughput, normalized effective video input rate, and normalized queue backlog. These values ​​were then weighted by the urgency of the business event and multiplied by the image complexity to obtain the operational pressure of the edge application within the state cycle. The weighting weights were 0.3, 0.25, 0.25, and 0.2, respectively. Parcel throughput reflects the on-site business volume of the transfer center and is the main source of changes in personnel, parcels, and transportation behavior within the video, therefore it was assigned the highest weight of 0.30. Effective video input rate determines the number of images actually entering the algorithm per unit time, and queue backlog reflects the current algorithm processing lag. Both are directly related to computing power requirements and were assigned 0.25. Event urgency mainly changes resource priority and does not necessarily increase the computational load of all image frames, therefore it was assigned 0.20. To avoid frequent expansion and contraction of capacity due to resource adjustments based solely on the current cycle pressure, an exponential smoothing method is used to calculate the predicted pressure for the next state cycle. The smoothing coefficient is preferably set at 0.65, meaning that 65% of the predicted pressure for the next cycle comes from the current actual pressure and 35% comes from the prediction results of the previous cycle. This value allows the prediction results to quickly follow the changes in the operation waves of the transfer center, while retaining a certain historical trend to suppress single-cycle fluctuations.

[0024] S2.2 When a new version of an edge application enters the cloud-isolated image repository, the cloud creates a resource description file for the new version of the edge application, including the edge application identifier and application version identifier, container image summary, model file summary, supported GPU models, minimum GPU driver version, inference framework version, video parsing SDK version, supported input resolution, minimum frame sampling frequency, recommended frame sampling frequency, maximum frame sampling frequency, maximum allowed inference latency, maximum supported video channels, application business priority, whether cross-transfer center operation is allowed, and rollback version identifier. The minimum frame sampling frequency, recommended frame sampling frequency, and maximum frame sampling frequency are determined by the application verification video set. For example, for the violent sorting application, verification is performed at 1 frame / second, 2 frames / second, 3 frames / second, 5 frames / second, and 8 frames / second respectively. The minimum frame sampling frequency is the lowest frame rate at which the continuous behavior recognition rate reaches the application acceptance standard. The recommended frame sampling frequency is the frame rate at which the recognition rate continues to improve and tends to stabilize and the GPU consumption is reasonable. The maximum frame sampling frequency is the frame rate at which the recognition rate improvement is less than the preset increment after exceeding the limit. For each edge application version and each supported GPU model, establish independent benchmark tasks. During testing, ensure that the application image, model files, video parsing SDK, and GPU driver versions are consistent with the actual deployment environment. The content of the independent benchmark tasks is as follows: For 1080P video applications, the following test combination was determined: the number of video channels was set to 1, 2, 4, 8 and 16 channels respectively; the single-channel frame extraction frequency was set to the lowest frame extraction frequency, the recommended frame extraction frequency and the highest frame extraction frequency respectively; the inference batch size was set to 1, 2 and 4 respectively; the image samples included three types of video segments: low target density, medium target density and high target density. For each test combination, run continuously for 15 minutes. The first 3 minutes are used as the container startup, model loading and GPU cache warm-up phase, which are not included in the test statistics. The last 12 minutes are considered as the effective test phase. During the effective testing phase, the following parameters were recorded: average GPU utilization, peak GPU utilization, average GPU memory usage, peak GPU memory usage, average inference latency, 95th percentile inference latency, frames processed per unit time, maximum backlog of the input queue, number of abnormal container exits, and number of GPU errors. If a GPU error, container exits abnormally, or input video is interrupted during the test, the test combination is invalid and the test must be re-executed. For edge applications in the transfer center, the application correction input scale is calculated based on the product of the current number of access video channels, the single-channel frame extraction frequency, and the complexity of the image. The current number of access video channels is obtained by the configuration of the video decoding server and the application input channel. The single-channel frame extraction frequency is obtained by the statistics of the video decoding server. The product of the number of video channels and the single-channel frame extraction frequency represents the number of image frames input to the application per unit time. This is then multiplied by the complexity of the image to correct the difference in single-frame processing overhead under different image content. The valid benchmark results of the same application version and the same GPU model are arranged in ascending order of the corrected input size to form multiple test points. Each test point includes the corrected input size and the corresponding GPU equivalent utilization. The equivalent GPU utilization is determined by the average GPU utilization and the number of GPUs allocated. When an application fully utilizes a single GPU, the equivalent GPU utilization is recorded as 1. When the average utilization of a single GPU is 40%, the equivalent GPU utilization is recorded as 0.4. When the application uses two GPUs simultaneously and each GPU has an average utilization of 60%, the equivalent GPU utilization is recorded as 1.2. If the current corrected input size is between the corrected input sizes of adjacent test points, then the basic GPU requirement is calculated by linear interpolation of adjacent test points. If the current corrected input size is lower than the minimum test point, the basic GPU requirement is based on the value corresponding to the minimum test point. When it is higher than the maximum test point, it does not continue to linearly extrapolate outward, but instead marks the application as exceeding the single instance test range, and then handles it by adding application instances. The peak GPU memory values ​​at each test point are arranged according to the corrected input scale. For the current input scale located between adjacent test points, linear interpolation is performed using the adjacent peak memory values ​​to obtain the basic memory requirement. A memory safety margin is added to the basic memory requirement to generate the recommended memory requirement. Specifically, the recommended video memory requirements are expressed as follows:

[0025] in The recommended video memory requirements for edge application a in the transfer center c during the k-th state cycle. To meet the basic video memory requirements of edge application a, To correct the input size, For the safety factor of video memory, it is preferably 0.15, that is, 15% of video memory is reserved on the basis of the measured peak video memory. This margin is used to absorb the video memory fluctuations caused by dynamic batch changes, video preprocessing cache, intermediate features of the model and temporary allocation of the running framework. Based on the minimum frame sampling frequency, recommended frame sampling frequency, and maximum frame sampling frequency in the application resource description file, three types of corrected input scales are calculated respectively, and the corresponding GPU requirements are obtained to form the application elastic computing power requirement range. The minimum GPU requirement is used for the minimum resource guarantee in subsequent steps and must not be occupied by ordinary non-real-time tasks. The recommended GPU requirement is used for resource allocation under normal conditions. The maximum GPU requirement is not a long-term fixed allocation amount, but the upper limit of resources that can be requested when the prediction pressure increases, the queue backlog occurs, or advanced events occur.

[0026] S3. Construct a set of application executable nodes using a resource status ledger; Within each state cycle, the operational data of each edge node in the transit center is extracted from the resource state ledger, and a node operational status record is generated. This record stores the node identifier, its transit center identifier, total GPU equivalent capacity, currently occupied GPU equivalent capacity, total GPU memory capacity, current memory usage, highest GPU temperature in the cycle, number of new GPU errors in the last ten minutes, currently available network bandwidth, disk usage, time interval since the last heartbeat, and the currently running application instance and version. Total GPU equivalent capacity is defined as the full usable computing power of a single standard GPU. When a node is configured with one GPU, its total equivalent capacity is typically recorded as 1; when configured with two GPUs of the same model, it is recorded as 2. For different GPU models, the performance ratio relative to a standard GPU is first obtained through application benchmark testing, and then converted to equivalent capacity. Calculate the basic state factors of the edge nodes, including heartbeat state factor, temperature state factor, error state factor, network state factor, and disk state factor; The heartbeat status factor is obtained by subtracting the ratio of the time since the last received node heartbeat to the time when the node heartbeat completely fails from 1. If the result is less than 0, it is set to 0. The node heartbeat complete failure time is preferably set to 30 seconds. The temperature status factor is obtained by comparing the GPU temperature with the GPU safe temperature and the temperature at which new tasks are stopped. The GPU safe temperature is preferably 75℃, and the temperature at which new tasks are stopped is preferably 88℃. When the GPU temperature is less than or equal to the GPU safe temperature, the temperature status factor is 1. When the GPU temperature is greater than or equal to the temperature at which new tasks are stopped, the temperature status factor is 0. When the GPU temperature is between the GPU safe temperature and the temperature at which new tasks are stopped, the temperature status factor is the ratio of the difference between the temperature at which new tasks are stopped and the GPU temperature to the difference between the temperature at which new tasks are stopped and the GPU safe temperature. The error status factor is obtained by subtracting the ratio of newly added errors in the last ten minutes to the upper limit of the number of errors from 1. If the result is less than 0, it is set to 0. The upper limit of the number of errors is preferably 5. The network state factor is obtained by the ratio of the available bandwidth of a node in the current state period to the total bandwidth required for the existing video channels, result backhaul, and application to be deployed on the node. If the ratio exceeds 1, it is taken as 1. The total bandwidth required is obtained by summing the average data rate of each video channel, the application input method, and the result upload rate. The disk status factor is set by the disk utilization rate. When the disk utilization rate is not higher than 80%, the disk status factor is 1. When the disk utilization rate exceeds 80%, the disk status factor decreases linearly with the remaining disk space and drops to 0 when the disk utilization rate reaches 100%. The overall health of an edge node is obtained by weighting and fusing its basic state factors. The weights are 0.3, 0.25, 0.2, 0.15, and 0.1, respectively. The heartbeat status directly determines whether a node can still be managed, so it is given the highest weight. GPU temperature determines whether a node can continue to increase its computational load, so it is given the second highest weight. GPU errors reflect the stability of hardware, drivers, and the operating environment. Network status affects video input and result return. Disk status mainly affects images, models, and caches, so it has a relatively low weight. The system considers the physical resources of the nodes, current resource usage, system reserved resources, and health status to calculate the effective GPU capacity and effective video memory capacity of the nodes. Specifically, the effective GPU capacity of a node is expressed as:

[0027] in This indicates the effective GPU equivalent capacity that can be further allocated to the node. This represents the total equivalent capacity of the node's GPU. This indicates the actual GPU equivalent capacity used by existing applications. To assess the overall health of the nodes, The reserved ratio for the node system is preferably 0.15, that is, 15% of the node GPU capacity is reserved. The reserved capacity is used to absorb the short-term resource requirements caused by video input fluctuations, temporary model loading, application warm-up and node failure migration. The effective memory capacity of a node is represented as follows:

[0028] in The effective video memory capacity of the node. This indicates the total capacity of the GPU's video memory. Indicates the current video memory usage. This represents the node's reserved video memory ratio, preferably 0.10, which is mainly used for GPU drivers, shared runtime libraries, and temporary buffers. Establish compatibility and data locality constraints for edge nodes and edge applications. The compatibility constraint is set to 1 only when the node's GPU model, GPU driver version, inference framework version, video parsing SDK version, and container runtime environment all meet the requirements of the application version resource description file; otherwise, it is 0. The data locality constraint is differentiated according to the task type. For real-time tasks such as violent sorting, package missorting, and alarm light linkage, the locality constraint is set to 1 only when the node and the video source belong to the same transfer center; otherwise, it is 0. For non-real-time tasks such as historical video review, offline statistics, and model evaluation, if the corresponding data has been authorized for cross-center processing and the expected data transmission time does not exceed the remaining processing period of the task, the locality constraint of other transfer center nodes is allowed to be set to 1. Based on node health, effective GPU capacity, effective video memory capacity, compatibility status, and data locality status, an application executable node set is constructed. Edge nodes are added to the application executable node set only when the following conditions are met simultaneously: node health is greater than or equal to the health threshold, effective GPU capacity is greater than or equal to the minimum GPU requirement, effective video memory capacity is greater than or equal to the recommended video memory requirement, compatibility status constraint is 1, and data locality status is 1. The preferred health threshold is 0.65.

[0029] S4. Divide computing power tokens and analyze the application token allocation priority to allocate computing power tokens. Select target transfer centers for edge applications that are allowed to transfer. Select target nodes based on the set of application executable nodes of the target transfer center. After locking the target nodes, create application instances to transfer edge applications.

[0030] S4.1 Divide a GPU equivalent capacity into computing power tokens with fixed granularity. The GPU equivalent capacity corresponding to a single computing power token is preferably 0.05, that is, a complete GPU equivalent capacity corresponds to 20 computing power tokens. Choosing 0.05 as the token granularity can represent the resource differences between different applications with 5% of the GPU equivalent capacity, while avoiding excessively fine token granularity that would cause frequent changes in resource status and an excessive number of management records. Calculate the number of tokens that the transfer center can use for adding new tasks and elastic adjustments based on the effective GPU capacity. Specifically, sum the effective GPU capacity of all GPU edge nodes in the transfer center and calculate the ratio with the GPU equivalent capacity corresponding to a single computing power token, then round down to obtain the result. Based on the GPU requirements corresponding to the three types of corrected input scales, minimum guarantee tokens, recommended supplementary tokens, and burst supplementary tokens are generated respectively to mark the application business priority. First-level applications such as violent sorting, security alarms, and on-site alarm light linkage are assigned a priority of 1; second-level applications such as ordinary misclassification recognition are assigned a priority of 0.6; and third-level tasks such as historical review and report statistics are assigned a priority of 0.3. The application token allocation priority is obtained by weighting the business priority, normalized prediction pressure, and normalized queue backlog, where the preferred weights are 0.45, 0.35, and 0.2 respectively. The business priority is used to ensure that security and real-time applications obtain the minimum operating resources, so it is assigned the highest weight. Prediction pressure reflects the resource demand that may occur in the next state cycle and is the main basis for pre-allocating resources. Queue backlog indicates the current processing lag and is used to further correct the allocation order. The cloud management platform first allocates minimum guarantee tokens to all real-time applications within the transfer center to ensure that on-site operations such as violent sorting, package missorting, and alarm light linkage maintain the minimum frame sampling frequency. After completing the minimum guarantee, it prioritizes replenishing recommended tokens for primary applications, and then allocates recommended tokens to other applications according to the token allocation priority from high to low. If there are still remaining available tokens, it continues to allocate emergency tokens according to the same priority. Finally, the remaining tokens enter the non-real-time task shared resource pool. When the number of available tokens in the transfer center is insufficient to meet the minimum guarantee tokens for all applications, the cloud first stops allocating tokens for Level 3 non-real-time tasks, then limits Level 2 applications to the minimum frame sampling frequency, and prioritizes guaranteeing the minimum tokens for Level 1 applications. If the minimum requirements of Level 1 applications still cannot be met after the above processing, a resource gap record is generated, and the creation of new ordinary application instances is prohibited. At the same time, node fault checks or device expansion alarms are triggered. For non-real-time tasks marked as allowed to run across transit centers in the resource description file, the cloud management platform filters candidate centers with remaining tokens from other transit centers, calculates the receiving score of the candidate centers, and selects the transit center with the highest receiving score and a score not lower than 0.50 as the target center for the non-real-time task. The candidate center acceptance score is obtained by weighting five factors. The first factor is the ratio of the center's remaining GPU resources to its total GPU capacity. The second factor is the readiness of the task application image and model, which is 1 when both the image and model are in the target center's cache and 0 when they only exist in the cloud image repository. The third factor is the normalized result of the target center's available network bandwidth. The fourth factor is the data transmission cost, which is determined by taking the negative value of the ratio between the expected transmission time and the remaining processing period of the task. The expected transmission time is obtained by dividing the task data volume by the available bandwidth between the source center and the target center. When the expected transmission time reaches or exceeds the remaining period of the task, the data transmission cost is set to 1, and the center is excluded from the candidate range. The fifth factor is the negative value of the normalized result of the number of node failures in the target center in the past hour relative to the preset failure limit. The preferred weights are 0.35, 0.2, 0.2, 0.15, and 0.1. The remaining GPU resources are the main condition for the target center to accept the task, so they have the highest weight. The readiness of the application image and the network conditions jointly affect the task start time. The transmission cost affects whether the task can be completed on time. The failure rate is used to reduce the acceptance priority of recently unstable transit centers. The token allocation result and the cross-center task reception result are treated as a complete computing power commitment token record. The record stores the transfer center identifier, application identifier, application version, minimum guaranteed token quantity, recommended supplementary token quantity, emergency supplementary token quantity, token validity start and end time, business priority, whether cross-center operation is allowed, target transfer center, policy version number, and cloud digital signature within the same data object. The resource quantity, validity time, and version information of the same token are not stored separately.

[0031] S4.2 After receiving the computing power commitment token locally, the transit center verifies the token to check whether the transit center identifier in the token is consistent with the local identifier, whether the digital signature is valid, whether the current time is within the token's validity period, whether the application version has passed compatibility verification, and whether the policy version number is higher than the local current version number. It also binds the minimum guarantee token to the application in the token. When the local executable node has sufficient resources and has been allocated a recommended supplementary token, the application's computing power request is increased to the recommended GPU requirement. When the job pressure reaches the burst condition and a burst supplementary token has been obtained, it is increased to the highest GPU requirement. When the predicted pressure of the next state cycle reaches the 95th percentile of the job pressure of the corresponding application's most recent seven complete running days, the normalized queue backlog is greater than 1, or the business event urgency level is 1, it is determined that the job pressure has reached the burst condition. The deployment cost of the candidate node after application deployment is calculated for each candidate node in the transit center's executable node set, and the candidate node with the lowest deployment cost is selected as the target node. Specifically, the deployment cost of candidate nodes is calculated using five weighted factors. The first factor is the estimated GPU utilization rate, obtained by dividing the sum of the node's currently occupied GPU capacity and the application's actual requested GPU capacity by the node's total equivalent GPU capacity, and is limited to between 0 and 1. The second factor is the latency utilization rate, obtained by dividing the estimated 95th percentile inference latency under the requested computing power by the measured response relationship of the same application version and the same GPU model. The third factor is the node health complementarity number. The fourth factor is the node image preparation cost, which is 0 if the application image, model, and configuration file are already located on the target node, and 0 if they are located on the corresponding transit node. The central local image cache is weighted at 0.5 when it still needs to be transferred to the target node, and at 1 when it needs to be downloaded from the cloud isolated image repository. The fifth item is the task switching cost, which is 0 for newly created tasks, 0.5 for normal elastic scaling, and 1 for migrating applications that are processing real-time video from other nodes. The weighted weights are 0.35, 0.25, 0.2, 0.1, and 0.1, respectively. After deployment, the GPU load directly determines whether the node is prone to overload, so it is given the highest weight. The expected inference latency directly affects the on-site recognition response speed. The node health risk determines the stability of the application's continuous operation. Image preparation and task switching mainly affect the startup and migration process, so they have relatively low weights.

[0032] S4.3 After the target node is locked, the local task scheduler checks whether the application image, model, and configuration file are already located on the node. If they are not present, it prioritizes retrieving them from the local image cache in the transit center. Only if they are not present in the local cache will it download them from the isolated image repository in the cloud. After downloading, it verifies the container image digest, model digest, and cloud digital signature. If any verification fails, the deployment is terminated and the locked resources are released. After verification, the target node creates an application instance according to the GPU capacity and recommended video memory requirements corresponding to the token, mounts the video parsing SDK, model files and application configuration to the instance, and establishes an input channel with the video decoding server. After the instance starts, a preset test frame is first input to complete the model warm-up, and then a health check is performed every 10 seconds. After three consecutive health checks are passed, the official video stream is switched to the new instance. Health checks at least verify whether the application process is alive, whether the GPU call is successful, whether the test frame outputs results within the maximum allowed latency, and whether the input queue can be consumed normally. Three consecutive checks correspond to at least 30 seconds of stable running time, which can prevent the model from being connected to the formal video too early when it has just finished loading but has not yet stabilized. If any health check fails, the instance is stopped, the bound token and node resources are released, and the reason for the failure is written to the application instance status record. Then, the node with the lowest deployment cost is selected from the remaining candidate nodes. The deployment is redeployed at most once. If it fails again, an application deployment exception record is generated. Infinite loop retry is not performed.

[0033] S4.4 Organize the application instance deployment results into a complete application deployment relationship record and upload it to the resource status ledger. The deployment relationship record stores the transfer center identifier, edge application identifier, application version identifier, application instance identifier, target node identifier, number of binding tokens, actual GPU capacity, allocated video memory, accessed video channel, instance startup time, current running status, and the adopted strategy version number in the same data object.

[0034] This embodiment also provides an edge computing power cloud-edge collaborative management system for multiple transit centers, including: The data processing module is used to deploy the cloud management platform, establish the edge management domain, divide the state cycle, collect edge node data, and generate a resource status ledger. The application computing power analysis module is used to collect edge application job parameters and analyze edge application job pressure during the state cycle, and generate elastic computing power demand range based on edge application job pressure. The node analysis module is used to construct a set of application executable nodes through a resource status ledger; The computing power allocation and transfer module is used to divide computing power tokens and analyze the application token allocation priority to allocate computing power tokens. For edge applications that are allowed to transfer, a target transfer center is selected. Based on the set of application executable nodes of the target transfer center, a target node is selected. After locking the target node, an application instance is created to transfer the edge application.

[0035] In summary, this invention improves the traceability of operational status by establishing a resource status ledger across multiple transit centers, enabling unified association and time-series recording of devices, nodes, applications, versions, and video channels. It also enhances the scenario adaptability of GPU demand estimation by generating operational pressure through the fusion of transit workload, video input, queue backlog, event level, and image complexity, and combining this with measured response relationships to form elastic computing power requirements. Furthermore, it reduces the risk of deploying tasks to abnormal or incompatible nodes by constructing a set of executable nodes based on node health, effective resources, compatibility status, and data locality. Finally, it improves the efficiency of GPU resource utilization in multiple transit centers, enhances real-time application support capabilities, and increases the stability of edge application deployments by coordinating real-time scheduling between cloud resource boundaries and the edge through hierarchical computing power commitment tokens, and utilizing deployment costs to select target nodes, complete image verification, and perform instance health checks.

[0036] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A cloud-edge collaborative management method for edge computing power in multi-transfer-center scenarios, characterized in that: include, Deploy a cloud management platform to establish an edge management domain and divide the state cycle to collect edge node data and generate a resource status ledger; During the state cycle, collect edge application job parameters to analyze the edge application job pressure, and generate elastic computing power demand range based on the edge application job pressure. Construct a set of application executable nodes using a resource status ledger; The computing power tokens are divided and the application token allocation priority is analyzed to allocate computing power tokens. For edge applications that are allowed to be transferred, a target transfer center is selected. Based on the set of application executable nodes of the target transfer center, a target node is selected. After locking the target node, an application instance is created to transfer the edge application.

2. The edge computing power cloud-edge collaborative management method for multiple transit centers as described in claim 1, characterized in that: The deployment of the cloud management platform to establish an edge management domain and divide the state cycle to collect edge node data and generate a resource state ledger specifically involves: Deploy a cloud management platform in the cloud; Establish an independent edge management domain within each transit center; The cloud management platform generates unique identifiers for each transit center, edge node, terminal device, edge application, application version, and application instance. A unified time service is set up, and each transit center initiates a time synchronization every 60 seconds. After the time synchronization is completed, the running time is divided into continuous state cycles. Within each state cycle, the edge node agent collects dynamic status at a 5-second sampling interval and uses the state cycle number as an index to form a multi-transfer center resource status ledger.

3. The edge computing power cloud-edge collaborative management method for multiple transit centers as described in claim 2, characterized in that: The specific steps for collecting edge application job parameters and analyzing edge application job pressure within the state cycle are as follows: Within each state cycle, collect operation-related parameters for edge applications in the transfer center, including parcel throughput, effective video input speed, algorithm input queue backlog, business event urgency, image target density, and image motion intensity. The edge application performs target detection on the video frames received within the state period, counts the number of valid targets in each frame, takes the average number of valid targets in each frame within the state period as the current number of targets, and divides it by the 95th percentile of the number of targets in the same application in the last seven full running days to obtain the normalized screen target density. Edge applications perform grayscale processing on adjacent extracted frames and calculate the absolute difference of corresponding pixels. The absolute difference of all pixels is averaged to obtain the degree of change of a single group of adjacent frames. The degree of change of all adjacent frames within the state cycle is averaged to obtain the amount of screen motion in the current cycle. The current amount of screen motion is divided by the 95th percentile of the screen motion of the same application in the last seven complete running days to obtain the normalized screen motion intensity. The normalized image target density and normalized image motion intensity are weighted by 1 to calculate the image complexity; For parcel throughput, effective video input rate, and algorithm input queue backlog, the 95th percentile of the corresponding data in the most recent seven complete operating days is calculated to obtain the parcel throughput benchmark, effective video input rate benchmark, and queue backlog benchmark. The benchmark values ​​are normalized to obtain normalized parcel throughput, normalized effective video input rate, and normalized queue backlog. These are then weighted by the urgency of business events and multiplied by the complexity of the image to obtain the operational pressure of the edge application within the state cycle. The predicted stress for the next state cycle is calculated using an exponential smoothing method.

4. The edge computing power cloud-edge collaborative management method for multiple transit centers as described in claim 3, characterized in that: The specific definition of generating elastic computing power demand range based on edge application workload is as follows: The cloud creates resource description files for new versions of edge applications; Establish independent benchmark tasks for each edge application version and each supported GPU model; For edge applications in the transfer center, the input size is adjusted by calculating the product of the current number of access video channels, the single-channel frame extraction frequency, and the complexity of the image. The valid benchmark results of the same application version and the same GPU model are arranged in ascending order of the corrected input size to form multiple test points. Each test point includes the corrected input size and the corresponding GPU equivalent utilization. If the current corrected input size is between the corrected input sizes of adjacent test points, then the basic GPU requirement is calculated using linear interpolation of adjacent test points. The peak GPU memory values ​​at each test point are arranged according to the corrected input scale. For the current input scale located between adjacent test points, linear interpolation is performed using the adjacent peak memory values ​​to obtain the basic memory requirement. A memory safety margin is added to the basic memory requirement to generate the recommended memory requirement. Calculate the three corrected input scales based on the application resource description file, obtain the corresponding GPU requirements, and form the application elastic computing power requirement range.

5. The edge computing power cloud-edge collaborative management method for multiple transit centers as described in claim 4, characterized in that: The specific steps of constructing the application executable node set through the resource status ledger are as follows: Within each state cycle, the operational data of each edge node of the transfer center is extracted from the resource state ledger and a node operational status record is generated; Calculate the basic state factors of the edge nodes, including heartbeat state factor, temperature state factor, error state factor, network state factor, and disk state factor; The overall health of the nodes is obtained by weighted fusion of the basic state factors of the edge nodes; The system considers the physical resources of the nodes, current resource usage, system reserved resources, and health status to calculate the effective GPU capacity and effective video memory capacity of the nodes. Establish compatibility state constraints and data locality state constraints between edge nodes and edge applications; Based on node health, effective GPU capacity, effective video memory capacity, compatibility status, and data locality status, construct a set of executable nodes for the application.

6. The edge computing power cloud-edge collaborative management method for multiple transit centers as described in claim 5, characterized in that: The process of dividing computing power tokens and analyzing the application token allocation priority to allocate computing power tokens, and selecting target transit centers for edge applications that are allowed to transit, specifically involves: Divide the equivalent capacity of a GPU into computing power tokens with fixed granularity, and calculate the number of tokens that the transfer center can use for new tasks and elastic adjustments based on the effective GPU capacity. Based on the GPU requirements corresponding to the three types of modified input scales, minimum guarantee tokens, recommended supplementary tokens, and burst supplementary tokens are generated respectively. Application business priorities are marked, and the application token allocation priority is obtained by weighting the business priority, normalized prediction pressure, and normalized queue backlog. The cloud management platform first allocates minimum guarantee tokens to all real-time applications within the transfer center. After the minimum guarantee is completed, it prioritizes replenishing recommended tokens for first-level applications. Then, it allocates recommended tokens to other applications according to the token allocation priority from high to low. If there are still remaining available tokens, it continues to allocate emergency tokens according to the same priority. Finally, the remaining tokens enter the non-real-time task shared resource pool. For non-real-time tasks marked as allowed to run across transit centers in the resource description file, the cloud management platform filters candidate centers with remaining tokens from other transit centers, calculates the receiving score of the candidate centers, and selects the transit center with the highest receiving score and a score not lower than 0.50 as the target center for the non-real-time task. The token allocation result and the cross-center task reception result are recorded as a complete computing power commitment token record.

7. The edge computing power cloud-edge collaborative management method for multiple transit centers as described in claim 6, characterized in that: The selection of the target node based on the set of executable nodes of the target transit center specifically involves: After receiving the computing power commitment token locally, the transit center verifies the token and binds the minimum guarantee token to the application in the token. It calculates the deployment cost of the candidate node after application deployment for each candidate node in the set of executable nodes of the transit center, and selects the candidate node with the minimum deployment cost as the target node.

8. The edge computing power cloud-edge collaborative management method for multiple transit centers as described in claim 7, characterized in that: After locking the target node, an application instance is created for edge application transfer. Once the target node is locked, the local task scheduler checks whether the application image, model, and configuration file are already located on the node. After verification, the target node creates an application instance according to the GPU capacity and recommended video memory requirements corresponding to the token, mounts the video parsing SDK, model files and application configuration to the instance, and establishes an input channel with the video decoding server. After the instance starts, a preset test frame is first input to complete the model warm-up, and then a health check is performed every 10 seconds. After three consecutive health checks are passed, the official video stream is switched to the new instance. If any health check fails, the instance is stopped, the bound tokens and node resources are released, and the reason for the failure is written to the application instance status record. Then, the node with the lowest deployment cost is re-selected from the remaining candidate nodes. The deployment is redeployed at most once. If it fails again, an application deployment exception record is generated.

9. The edge computing power cloud-edge collaborative management method for multiple transit centers as described in claim 8, characterized in that: Organize the application instance deployment results into a complete application deployment relationship record and upload it to the resource status ledger.

10. An edge computing power cloud-edge collaborative management system for multiple transit centers, based on the edge computing power cloud-edge collaborative management method for multiple transit centers as described in any one of claims 1 to 9, characterized in that: include, The data processing module is used to deploy the cloud management platform, establish the edge management domain, divide the state cycle, collect edge node data, and generate a resource status ledger. The application computing power analysis module is used to collect edge application job parameters and analyze edge application job pressure during the state cycle, and generate elastic computing power demand range based on edge application job pressure. The node analysis module is used to construct a set of application executable nodes through a resource status ledger; The computing power allocation and transfer module is used to divide computing power tokens and analyze the application token allocation priority to allocate computing power tokens. For edge applications that are allowed to transfer, a target transfer center is selected. Based on the set of application executable nodes of the target transfer center, a target node is selected. After locking the target node, an application instance is created to transfer the edge application.

Images